We are going to release first 2.6.26-based kernel soon -- it went to testing today and hopefully will be released next week.
We are also changing the versioning scheme -- instead of boring numbers like 001, 002, 003 etc., every 2.6.26 OpenVZ kernel will be named after one or another great Russian writer. We will do it in alphabetical order so there will be no upgrade pain.
As you can see here, first 2.6.26 is named after Mikhail Afanasievich Bulgakov. I personally enjoy his The Master and Margarita (it's truly a masterpiece; although I'm afraid a lot is lost in translation) and Heart of a Dog.
And yes, we are doing that just for fun.
We are also changing the versioning scheme -- instead of boring numbers like 001, 002, 003 etc., every 2.6.26 OpenVZ kernel will be named after one or another great Russian writer. We will do it in alphabetical order so there will be no upgrade pain.
As you can see here, first 2.6.26 is named after Mikhail Afanasievich Bulgakov. I personally enjoy his The Master and Margarita (it's truly a masterpiece; although I'm afraid a lot is lost in translation) and Heart of a Dog.
And yes, we are doing that just for fun.
Robert Nelson was kind enough to agree to an email-based interview which readers of the OpenVZ Users mailing list will have already seen. Robert has written a replacement for vzpkg (currently named vzpkg2) and has greatly enhanced it with the addition of a package named pkg-cacher. For an introduction to OS Templates and the tools used to manage them as well as Robert's fantastic answers, see:
Interview with vzpkg2 and pkg-cacher creator Robert Nelson
Obligatory quote:
It might take a few more weeks before
http://openvz.org/pipermail/users/2008-September/thread.html
Interview with vzpkg2 and pkg-cacher creator Robert Nelson
Obligatory quote:
ML: You have added a number of features / capabilities to vzpkg. Could you give us an overview of what's new?One thing worth mentioning is that while the number of OS Template Metadata packages provided by the OpenVZ Project is quite limited, Robert has created new metadata packages for
Robert: I think the most significant change over the stock version of vzpkg is the separation of the packager specific code from the higher level code. This allows scripts to be written to support other package managers like apt which is used on Debian and Ubuntu.
The other slightly less significant change is the introduction of the concept of a hierarchical structure to the template meta data. Information which is the same for all versions and platforms of a distribution need only be specified once. If there is a need for separate settings for a specific version it can be overridden by a file lower in the template meta data tree.
Also new packager-independent commands have been added for managing packages in installed containers.
vzpkg2 that allow for easily building CentOS, Debian, Fedora, and Ubuntu OS Templates. If I counted correctly, Robert's new metadata packages make it easy to build 44 different OS Templates. Wow!It might take a few more weeks before
vzpkg2 and pkg-cacher are finalized and added to the OpenVZ Project repositories. If you don't want to wait and would like to help out with testing, Robert has posted some instructions to the OpenVZ Users mailing list and here is a link to the archive for the time period in question:http://openvz.org/pipermail/users/2008-September/thread.html
Just wanted to mention that Kir created a new directory at the top level of the download site named beta. Inside of it you'll find a directory structure that you can eventually drill down into to find a number of new, beta OS Templates that Kir has built. Here's a list:
centos-4-x86_64.tar.gz, centos-4-x86.tar.gz, centos-5-x86_64.tar.gz, centos-5-x86.tar.gz, debian-3.1-x86.tar.gz, debian-4.0-x86_64.tar.gz, debian-4.0-x86.tar.gz, fedora-7-x86_64.tar.gz, fedora-7-x86.tar.gz, fedora-8-x86_64.tar.gz, fedora-8-x86.tar.gz, fedora-9-x86_64.tar.gz, fedora-9-x86.tar.gz, suse-10.3-x86_64.tar.gz, suse-10.3-x86.tar.gz, ubuntu-7.10-x86_64.tar.gz, ubuntu-7.10-x86.tar.gz, ubuntu-8.04-x86_64.tar.gz, ubuntu-8.04-x86.tar.gz
Sorry SUSE fans, no openSUSE 11 yet. :(
One big difference is that the Fedora and CentOS OS Templates now include yum which will make a number of people happy. No more fumbling around trying to download a bunch of rpm packages an using rpm to install yum.
The CentOS 5 OS Template
Oddly enough an OpenVZ "official" pre-created OS Template for CentOS 5 did not previously exist although there have been a number of builds posted in the "contrib" section. So far, I've tested out the CentOS 5 x86 and x86_64 OS Templates and they are a bit different from the contrib releases. For one thing, udevd is installed and running and the vzdev package puts files in /etc/udev/devices/ rather than /dev. This is good, because on previous CentOS Templates udev was not installed and if it happened to get installed as a dependency for something else, it would prevent future container starts from working... until udev was removed or the starting of udev was commented out from /etc/rc.d/rc.sysinit. Perhaps including udev will make migrating physical servers to OpenVZ containers a little more easy.
There are a number of updated vz packages installed that include:
vzdummy-kernel-el5, vzdummy-jre-fc6, vzdummy-glibc, vzdummy-apache, vzdev
The CentOS 5 OS Template is quite light-weight resource wise as a container made from initially only takes up about 14MB of RAM. The vzdummy-apache package helps there because it offers a modification to the stock Apache configuration (/etc/httpd/conf.d/swtune.conf) that changes the StartServers value to 1.
Community, please test these out and report any bugs you find!
centos-4-x86_64.tar.gz, centos-4-x86.tar.gz, centos-5-x86_64.tar.gz, centos-5-x86.tar.gz, debian-3.1-x86.tar.gz, debian-4.0-x86_64.tar.gz, debian-4.0-x86.tar.gz, fedora-7-x86_64.tar.gz, fedora-7-x86.tar.gz, fedora-8-x86_64.tar.gz, fedora-8-x86.tar.gz, fedora-9-x86_64.tar.gz, fedora-9-x86.tar.gz, suse-10.3-x86_64.tar.gz, suse-10.3-x86.tar.gz, ubuntu-7.10-x86_64.tar.gz, ubuntu-7.10-x86.tar.gz, ubuntu-8.04-x86_64.tar.gz, ubuntu-8.04-x86.tar.gz
Sorry SUSE fans, no openSUSE 11 yet. :(
One big difference is that the Fedora and CentOS OS Templates now include yum which will make a number of people happy. No more fumbling around trying to download a bunch of rpm packages an using rpm to install yum.
The CentOS 5 OS Template
Oddly enough an OpenVZ "official" pre-created OS Template for CentOS 5 did not previously exist although there have been a number of builds posted in the "contrib" section. So far, I've tested out the CentOS 5 x86 and x86_64 OS Templates and they are a bit different from the contrib releases. For one thing, udevd is installed and running and the vzdev package puts files in /etc/udev/devices/ rather than /dev. This is good, because on previous CentOS Templates udev was not installed and if it happened to get installed as a dependency for something else, it would prevent future container starts from working... until udev was removed or the starting of udev was commented out from /etc/rc.d/rc.sysinit. Perhaps including udev will make migrating physical servers to OpenVZ containers a little more easy.
There are a number of updated vz packages installed that include:
vzdummy-kernel-el5, vzdummy-jre-fc6, vzdummy-glibc, vzdummy-apache, vzdev
The CentOS 5 OS Template is quite light-weight resource wise as a container made from initially only takes up about 14MB of RAM. The vzdummy-apache package helps there because it offers a modification to the stock Apache configuration (/etc/httpd/conf.d/swtune.conf) that changes the StartServers value to 1.
Community, please test these out and report any bugs you find!
Here is an example of how things are working in the free software world.
We at OpenVZ use kernels from Red Hat Enterprise Linux as a base for our OpenVZ kernels. This is because vendors such as Red Hat invest a lot of work into making their kernels really stable. The usual recipe for a super-stable kernel is to pick a mainstream kernel and marinate it in QA for at least half a year (more for the best results), doing bugfixing and cherry-picking of fixes and driver updates from the mainstream. This way one have enough time to test it, plus (at least in theory) one get new fixes but do not get new bugs slipped into one's kernel. This is what Red Hat (and other guys such as Novell/SUSE) does for their kernels, and believe me it's quite a lot of work to do, and the end result is of great value.
Here comes the beauty of free software: now everybody can use the result of Red Hat's work. Yes, this is exactly what we do. At this point you might stand up saying: all right, Red Hat invested a lot of resources into something you use for free, this does not look like a fair deal.
Fortunately I have a good answer. Here is the list of bug (i.e. software defect) reports that were fixed in Red Hat Enterprise Linux kernels thanks to OpenVZ team (in some way): #405521, #247379, #205335 , #210852, #168659, #243252, #207463, #228461, #243263, #224541, #232209, #232211, #239767, #220971, #400651, #214778, #203894, #212144, #215715, #241096, #241096, #439670. These 22 bugs are all kernel bugs, most are security-related (and therefore quite serious). Almost all the bug reports from the list include patches (i.e. changes to code to fix a problem reported), so those are not like "hey, you have a problem", but rather "you have a problem and here's the solution".
The majority of those bugs were found while testing OpenVZ kernels. This is what we contribute back. This is also a lot of work and of great value -- some of those bugs were really hard to find and/or fix.
The latest (23rd) addition to the above list is bug #454865, which is actually a regression in a new version of RHEL4 kernel. Again, this report not only includes a clear description of what's wrong, but also a test case program which reproduces the bug, and a patch to fix it. Clear test cases are very important because those can be included into a validation test suite, to make sure bugs are not popping out for the second time (which sometimes happens in the real world).
This is just one example, a close-up picture. The big picture is free software developers and users helping other developers and users. Unus pro omnibus, omnes pro uno.
We at OpenVZ use kernels from Red Hat Enterprise Linux as a base for our OpenVZ kernels. This is because vendors such as Red Hat invest a lot of work into making their kernels really stable. The usual recipe for a super-stable kernel is to pick a mainstream kernel and marinate it in QA for at least half a year (more for the best results), doing bugfixing and cherry-picking of fixes and driver updates from the mainstream. This way one have enough time to test it, plus (at least in theory) one get new fixes but do not get new bugs slipped into one's kernel. This is what Red Hat (and other guys such as Novell/SUSE) does for their kernels, and believe me it's quite a lot of work to do, and the end result is of great value.
Here comes the beauty of free software: now everybody can use the result of Red Hat's work. Yes, this is exactly what we do. At this point you might stand up saying: all right, Red Hat invested a lot of resources into something you use for free, this does not look like a fair deal.
Fortunately I have a good answer. Here is the list of bug (i.e. software defect) reports that were fixed in Red Hat Enterprise Linux kernels thanks to OpenVZ team (in some way): #405521, #247379, #205335 , #210852, #168659, #243252, #207463, #228461, #243263, #224541, #232209, #232211, #239767, #220971, #400651, #214778, #203894, #212144, #215715, #241096, #241096, #439670. These 22 bugs are all kernel bugs, most are security-related (and therefore quite serious). Almost all the bug reports from the list include patches (i.e. changes to code to fix a problem reported), so those are not like "hey, you have a problem", but rather "you have a problem and here's the solution".
The majority of those bugs were found while testing OpenVZ kernels. This is what we contribute back. This is also a lot of work and of great value -- some of those bugs were really hard to find and/or fix.
The latest (23rd) addition to the above list is bug #454865, which is actually a regression in a new version of RHEL4 kernel. Again, this report not only includes a clear description of what's wrong, but also a test case program which reproduces the bug, and a patch to fix it. Clear test cases are very important because those can be included into a validation test suite, to make sure bugs are not popping out for the second time (which sometimes happens in the real world).
This is just one example, a close-up picture. The big picture is free software developers and users helping other developers and users. Unus pro omnibus, omnes pro uno.
I mean, in case you're doing a physical to VE migration, you're to remember turning some things off and doing other tuning («rat-file works»). And it's easy to miss something. At the other hand, the distro-devs know their rc-system perfectly (at least some of them should) and direct support of distro run inside VE would be really great. But I'm afraid there're no such distros, am I wrong?
I am currently standing at the OpenVZ booth at LinuxWorld Conference and Expo, San Francisco. Today is the first day of the show, the traffic is pretty good. The only bad thing is Delta lost my bag with booth banners and rollups so the booth looks a bit empty.
Marc Perkel, Scott Dowdle and Adeel Nazir are all manning the booth, talking to existing and (I hope) future OpenVZ users. So I was able to release a new RHEL5-based kernel right from here.
Tomorrow morning at 10:15 I will be giving a talk titled "Containers, Virtualization, and Live Migration".
Marc Perkel, Scott Dowdle and Adeel Nazir are all manning the booth, talking to existing and (I hope) future OpenVZ users. So I was able to release a new RHEL5-based kernel right from here.
Tomorrow morning at 10:15 I will be giving a talk titled "Containers, Virtualization, and Live Migration".
While I am writing this, people are discussing the future of containers in the Linux Kernel at the containers mini-summit which is happening in Ottawa at the moment. You can check some rough notes from the event here. Three guys from OpenVZ team are there: Pavel Emelyanov, Denis Lunev, and Andrey Mirkin.
If you are attending Linux Symposium in Ottawa, note that this Friday, 25th, Andrey Mirkin will talk about containers checkpointing and live migration (12:00, Rockhopper room). It's going to be an interesting talk, do not miss it.
Also, this Wednesday, 23rd, Balbir Singh will lead a BoF on Memory Controller (17:45, Fiordland room). Memory controller is quite important for containers, and while some stuff are already in the mainline kernel, there's still lots to be discussed and developed in the area. You can think of this BoF as an extension to containers mini-summit.
If you are attending Linux Symposium in Ottawa, note that this Friday, 25th, Andrey Mirkin will talk about containers checkpointing and live migration (12:00, Rockhopper room). It's going to be an interesting talk, do not miss it.
Also, this Wednesday, 23rd, Balbir Singh will lead a BoF on Memory Controller (17:45, Fiordland room). Memory controller is quite important for containers, and while some stuff are already in the mainline kernel, there's still lots to be discussed and developed in the area. You can think of this BoF as an extension to containers mini-summit.
I discovered three major issues in the usage scenarios of OpenVZ in the enterprise market:
Now we have the virtualization platform for the enterprise, licensed under GNU GPLv2.
Proxmox VE is the only virtualization platform which can do all of the following on one physical host:
Feel free to get in contact with me directly - martin@proxmox.com.
- Installation takes time and needs Linux knowledge
- The missing GUI management
- And the inability to run unmodified guests like Windows on an OpenVZ host
Now we have the virtualization platform for the enterprise, licensed under GNU GPLv2.
Proxmox VE is the only virtualization platform which can do all of the following on one physical host:
- Container Virtualization (OpenVZ)
- Full virtualization (KVM)
- Para-virtualization (KVM)
Feel free to get in contact with me directly - martin@proxmox.com.
Linus has released 2.6.26-rc1 yesterday. Here rc1 means this is the first "release candidate" for 2.6.26, and the merge window is now closed, so for the next two months or so before final 2.6.26 release only bugfixes will be accepted.
And I just can't resist the temptation to post my new favorite image here, so you can enjoy it too:

Click to get the hi-res image and the scripts used to produce it.
The majority of these 299 changesets that made it to 2.6.26-rc1 is about network namespaces.
And I just can't resist the temptation to post my new favorite image here, so you can enjoy it too:
Click to get the hi-res image and the scripts used to produce it.
The majority of these 299 changesets that made it to 2.6.26-rc1 is about network namespaces.
At this years Linuxfest Northwest 2008 show in Bellingham, Washington I gave a presentation entitled OS Virtualization vs. Hardware Virtualization. LFNW takes place at Bellingham Technical College and the BTC had video cameras setup in two of the presentations rooms. I was lucky enough to have my presentation streamed live as well as archived for playback anytime.
I doubt there is any new material in my presentation for readers of this blog, because it was basically an Introduction to OpenVZ. The room was full and only a couple of people had used OpenVZ before so I was presenting to a lot of potential users.
It is also available on ustream.tv. I believe the BTC folks will be offering all of the presentations for download in the near future.
Feel free to check out my slides in PDF format. Unfortunately I didn't get to the last 5 slides which are about the inclusion of cgroups/containers in the mainline kernel, the contributions made by OpenVZ/Parallels, and future uses of containers. If you look at those slides you'll see I borrow from some recent material here on this blog. Near the end, when answering someone's question I mention offline migration and mistakenly refer to checkpointing and restoring from a checkpoint... which is obviously part of online migration. Other than that mistake I was fairly happy with the presentation.
I also wrote an article entitled Linuxfest Northwest 2008 Report which includes links to all of the available presentation videos. I really recommend the Linuxfest Northwest conference... and it's free.
I doubt there is any new material in my presentation for readers of this blog, because it was basically an Introduction to OpenVZ. The room was full and only a couple of people had used OpenVZ before so I was presenting to a lot of potential users.
It is also available on ustream.tv. I believe the BTC folks will be offering all of the presentations for download in the near future.
Feel free to check out my slides in PDF format. Unfortunately I didn't get to the last 5 slides which are about the inclusion of cgroups/containers in the mainline kernel, the contributions made by OpenVZ/Parallels, and future uses of containers. If you look at those slides you'll see I borrow from some recent material here on this blog. Near the end, when answering someone's question I mention offline migration and mistakenly refer to checkpointing and restoring from a checkpoint... which is obviously part of online migration. Other than that mistake I was fairly happy with the presentation.
I also wrote an article entitled Linuxfest Northwest 2008 Report which includes links to all of the available presentation videos. I really recommend the Linuxfest Northwest conference... and it's free.

Comments
Do you still stand by your opinions above now in 2016?…