Suno, ----- "Suno Ano" <suno....@sunoano.org> 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 > http://sunoano.name/ws/public_xhtml/openvz.html
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 (dow...@montanalinux.org). 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. TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] _______________________________________________ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
