Containers in mainline Linux kernel when?

I'm a long time reader and subscriber to LWN (Linux Weekly News). LWN is probably the best Linux news site out there with regards to covering kernel development and I often find myself eating up considerable amounts of time sifting through their articles. This week they had an article covering some recent progress in the mainline kernel on checkpointing and restoring of processes and containers of processes... and I wrote a somewhat lengthy response that I decided to share here. I would link to the LWN's original article but it won't be anonymously accessible until next week.

Out-of-tree project has been doing checkpointing and restore for some time
Posted Aug 14, 2008 4:17 UTC (Thu) by dowdle (subscriber, #659)

One word...errr name... OpenVZ.

As you probably already know, in 2005 OpenVZ was spun off as a FOSS project from SWsoft's commercial Virtuozzo product and as a result a free, complete implementation of containers has been available for Linux for over three years. Then a little over a year ago OpenVZ added checkpointing with restore and live migration features. OpenVZ is definitely a well tested and widely deployed out-of-tree patch for the Linux kernel... although strangely enough, none of the "enterprise" distributions have picked it up yet.

Linux-VServer is also an out-of-tree, FOSS containers project of high quality and wide deployment... that has been around for some time... but it doesn't include checkpointing. Linux-VServer does have some unique and interesting features that OpenVZ doesn't but I'll not get into those. The Linux-VServer developers have decided, for reasons I'll not get into, to stay an out-of-tree patch and are not directly involved in the effort to move containers into the mainline kernel... as far as I can tell.

The OpenVZ developers are (probably) the top contributors of new code going into the mainline kernel relating to containers (starting with 2.6.24). It is my understanding that all of their additions to mainline have been written completely from scratch and do not borrow from the OpenVZ code at all. Given the nature of mainline kernel development... small, slow, incremental steps that are judged by all of the stake holders... I imagine it was impossible to reuse the existing, fully implemented OpenVZ patch. OpenVZ is a largish patch which contains significant changes to many kernel subsystems to make them container aware and since it is feature complete and mature... it is more work to break it back down into code suitable for mainline... than it is to write completely new code.

I do wonder how long it is going to take before a complete implementation of containers appears in the mainline kernel. A year ago, conventional wisdom said about one year. A year has passed and although significant progress has been made, it sure seems a long, long way off. I've heard informed people revise their guess to be three to five years. That sounds kind of sad because other forms of virtualization are ready now and are growing in popularity and deployments. I have to wonder if starting over from scratch and adapting to the slow, methodical staging method required by the mainline kernel developers is going to have an impact on the viability of containers in the long run. One hope is that starting from scratch will potentially lead to a much cleaner / more maintainable, better implementation of containers... but will it? I'm not sure.

I understand that it is not possible to simply plop the huge patch that is OpenVZ into the mainline kernel... and there are (always) those who have serious complaints about designs not their own. The mainline kernel developers would surely question why SWsoft (merged with Parallels and renamed to Parallels, Inc.) developed Virtuozzo / OpenVZ outside of mainline to begin with and say that it is Parallels' own fault that the current process is going to progress as it is.

Where was I going to go with all of this? Oh yeah... anyhoo...

It reminds me of the tragic story of some file systems that have yet to make it into mainline... and probably countless other projects I'm less familiar with. It would be nice if there was a way to somehow automate the slicing up and incrementalization (a new word I just made up) of a large existing codebase so it could become acceptable to reasonable people like the mainline kernel developers.

Jon, any comments into this sort of situation? Is starting from scratch and having a lot of other developers involved, each working on the particular feature(s) that most interests them... perhaps without as strong of an overall vision that OpenVZ and Linux-VServer had toward a complete containers solution... could it possibly result in as good or an even better container implementation than we already have with OpenVZ and Linux-VServer? Are the odds in our favor or not?

It is a little comical to see you report on the baby steps that are being taken... when the two complete and mature solutions have existed for a long time... but I am definitely glad to see you cover container related kernel development and strongly encourage you to keep it up.