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.
