Out-of-tree project has been doing checkpointing and restore for some time

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 a 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 surly 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?  Or 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.