----- "Suno Ano" <> wrote:
> Currently (January 2010) mainline is in development for the .33
> release, .32 is stable and used by most Linux Distributions like for example
> Debian, Ubuntu, Suse, etc.
> From what it looks now Debian and Ubuntu are going into freeze for
> their next stable release in March 2010. Will there be an up-to-date OpenVZ
> kernel patch available by then? Debian is targeting to ship .32 with
> their next stable release called squeeze.
> In case OpenVZ will not be available on at least one of the major
> Linux distributions and its offsprings, no need to mention how horrid that
> would be ...
> I would love to see OpenVZ be available in Debian's next stable
> release since I am with no doubt an OpenVZ fanboy

I'm not someone who can give an "official" answer to your question (because I 
don't work for Parallels) but given how long I've been involved with the 
project, I don't feel too silly rendering a guess.  I think that the current 
OpenVZ stable branches are going to remain and I don't see any newer branches 
be marked as stable any time soon.  From a look at the stable branches it is 
obvious that they have been targeting the kernels used by Red Hat.  RHEL 6 has 
not been released although it is thought it might be released in the first half 
of 2010.  That remains to be seen.  I do not know if OpenVZ is still going to 
follow that pattern but it is the current pattern.

What does that mean?  Well as is obvious to you, as time passes, the number of 
distributions that are appropriate to use as an OpenVZ host node is reduced... 
and it appears that RHEL and CentOS truly are the best distros to recommend for 
the host node.  As the type of fanboy I am, that does not frustrate me at all 
but I realise how frustrating that can be to others.  I would indeed call that 
a limitation.

The good news is that narrowing of appropriate host node distros seems to have 
had little impact on what distributions one can have inside of a container.  
While there have been a few bugs with some newer distributions, mainly with 
running newer glibc versions on older kernels... to the best of my knowledge 
OpenVZ has done a reasonably good job of fixing those situations with mostly 
community supplied patches... because Red Hat wasn't interested in patching the 
RHEL kernel for that situation because their customers don't run into it.  I 
imagine more bugs like that may appear in the future and I hope the current 
pattern (that they get fixed in the OpenVZ kernel even if they aren't fixed 
upstream) continues.

I do believe that the OpenVZ stable kernel branches, being older, are making OS 
Template creation of newer distributions slightly more difficult for a small 
handful of the more cutting edge distros.  Well, maybe not... that is probably 
more of a vzctl needing to continuously evolve over time situation that caused 
by the kernel. While I've done some OS Template creation it is been in a 
limited scope.  Anyone have any comments on that?  vzctl seems to have about 
the right amount of development activity although there have been one or maybe 
more community provided patches that weren't picked up for which I haven't seen 
a good explanation for.  I'm thinking mainly of the Proxmox VE guys patch for 
adding server startup messages to a log file.

Of course I could be wrong with my assessment but if I'm not and you are stuck 
what what you see as an unfortunate situation... I wouldn't fault you for 
switching away from OpenVZ.  The only thing that even comes close to a suitable 
candidate that I'm aware of is Linux-VServer.  I haven't really been keeping up 
with Linux-VServer development but I believe that while they aren't interested 
in working with the mainline (they always want to be an out of tree patch), 
they do seem to be adapting Linux-VServer to each mainline kernel that comes 
out.  The only problem is a new mainline kernel comes out every 3 months and 
I'm not sure exactly how they balance that nor how successful they are at that. 
 If anyone would like to provide a summary that explains exactly where 
Linux-VServer developement is (or a link to such), I don't think a few emails 
about Linux-VServer on the OpenVZ Users mailing list is going to hurt 
anything... but of course if anyone complains, feel free to email me!
  the info directly (

Now having said all of that I have to clarify with a few more points:

1) We would have been in a much worse situation now if OpenVZ had not chosen 
RHEL-based kernels for their stable branches.  Red Hat is the most successful 
commercial distribution with very good market penetration in the enterprise 
world.  They have the kernel talent to support their kernels for a long time 
and they do.  They have frequent releases (about every 6 months on schedule and 
often more frequent for security and bug fixes) and they back-port a lot of 
drivers and some features.

2) When they were picking, I'm not sure Ubuntu would have been a reasonable 
choice.  While Ubuntu has gone to a combo model of rapid release cycle and LTS 
release, I wonder how their support of the LTS kernel stacks up to that of RHEL 
specifically with regards to hardware support.  I don't have a definitive 
answer to that.

3) Outside (of Parallels) developers could probably help the situation but such 
is the life of a large, complex out-of-tree kernel patch.  It is hard for 
outsiders to get past the steep learning curve... and it is questionable how 
co-operative Parallels would be.

Suno, I do appreciate you raising your concern and asking the question. It 
certainly is a valid one.  I wonder if Kir will have a good answer for you or 
not.  I hope he does rather than avoiding the question which is what I'd be 
tempted to do if I was him. :)  I recognise your contributions to our (the 
OpenVZ) community and would prefer not to lose you.

Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]

Users mailing list

Reply via email to