I posted the video footage I took at LinuxWorld. Basically it is 36 minutes of mish-mash video although there is about 10 minutes of Carla from SWsoft talking about Virtuozzo as well as some footage from the OpenVZ booth.
Also included are some brief interviews from folks at the following booths: Fedora, Pentaho, Joomla, The Linux Foundation, and Ubuntu. I am NOT the person doing the interviews... but I mention that in the accompanying text.
http://www.montanalinux.org/linuxworld-expo-2007-videoclips.html
Comments, questions? Leave a comment.
Also included are some brief interviews from folks at the following booths: Fedora, Pentaho, Joomla, The Linux Foundation, and Ubuntu. I am NOT the person doing the interviews... but I mention that in the accompanying text.
http://www.montanalinux.org/linuxworld-expo-2007-videoclips.html
Comments, questions? Leave a comment.
I noticed a blog posting by Daniel Veillard on Fedora People about initial support for OpenVZ being added to libvirt. If you aren't familiar with libvirt, it is an underlying library/API that can be used by higher level tools to create, manage, and monitor virtual machines. libvirt is trying to be technology agnostic by supporting several virtualization technologies. They started off with Xen and QEMU but have since added KVM. libvirt is used by the GUI tool Virtual Machine Manager which first appeared in Fedora Core (now Fedora) but became part of Red Hat Enterprise Linux 5.
Looking at some of the postings in the libvirt mailing list archive for this month, it is mentioned that adding OpenVZ support is a bit different than previous technologies because the OpenVZ tools are already GPLed, "simple and straight forward", and than OpenVZ additions to libvirt "ends up looking very close to the original". I don't know how far away complete support for OpenVZ is in libvirt nor when it will show up in Virtual Machine Manager but I definitely look forward to it... although I doubt it would completely replace vzctl and the other OpenVZ tools for me.
Red Hat has tentatively promised OpenVZ support for RHEL6 but it sure would be nice to see it sooner... say in RHEL5 Update 2 or so. While the OpenVZ project is doing a fantastic job supporting RHEL, I would imagine that OpenVZ adoption will skyrocket once it is part of the stock RHEL and CentOS kernels.
Looking at some of the postings in the libvirt mailing list archive for this month, it is mentioned that adding OpenVZ support is a bit different than previous technologies because the OpenVZ tools are already GPLed, "simple and straight forward", and than OpenVZ additions to libvirt "ends up looking very close to the original". I don't know how far away complete support for OpenVZ is in libvirt nor when it will show up in Virtual Machine Manager but I definitely look forward to it... although I doubt it would completely replace vzctl and the other OpenVZ tools for me.
Red Hat has tentatively promised OpenVZ support for RHEL6 but it sure would be nice to see it sooner... say in RHEL5 Update 2 or so. While the OpenVZ project is doing a fantastic job supporting RHEL, I would imagine that OpenVZ adoption will skyrocket once it is part of the stock RHEL and CentOS kernels.
A few days ago one of OpenVZ kernel team members, Pavel Emelyanov, posted a one-line patch to fix a bug in Linux kernel. He received the following reply from Andrew Morton, one of the upstream kernel maintainers:
Andrew added later:
So, here is the story behind that bug.
A few months ago, in the course of OpenVZ kernel testing, our QA (Quality Assurance) team found a strange issue. The thing is, every container (VE) in OpenVZ has a set of resource usage counters (and limits) called beancounters. All the usage counters should be zero when a VE is stopped, since naturally then all the resources are released. The issue was that a resource called kmemsize (a kernel memory used on behalf of given VE) had a usage counter of 78 bytes after the VE was stopped -- which effectively means 78 bytes of kernel memory were lost (or leaked, as programmers say).
Who cares about 78 bytes, especially on a server with 16 gigabytes (17,179,869,184 bytes) of RAM? We do. Pavel checked the beancounters debug information which showed that one struct user object has leaked. He then tried to reproduce that but with no luck.
Bugs that can not be reproduced are tough. The only option left was to audit the kernel source code. That involved finding all the places where struct user object is referenced, and checking the code correctness (the term "correctness" in this context means that every object that is allocated must later be released). It took him 4 hours to do the audit, and he found one place where the reference to an object might be lost (which means it could not later be released). It's the same as if you lend a book to your friend and later forgot whom you gave it to -- you lost the reference and you can't get the book back.
In this case, after the problem was found, fixing it was pretty straightforward. So Pavel wrote a fix and a demo code to trigger the bug, tested the fix and sent it to Linux kernel mailing list.
Why is this particular incident so important?
* It's OpenVZ code (beancounters) which helped to detect the leak in the first place -- as the bug is very hard to trigger (unless you know how) and the leak is small enough that it might not be discovered at all.
* It demonstrates OpenVZ developers dedicated attitude. They never dismiss real bugs as "works for me" or "invalid", and work to find the root cause and fix the problem.
* This bug is in fact a security issue. An ordinary user (actually two users are needed in this case) could exploit the bug and eat all the kernel memory, thus bringing the whole system down. Worse scenarious are possible as well.
* Incidentally, OpenVZ is protected from this security issue -- because kmemsize beancounter (which helped to found it) limits kernel memory usage per Virtual Environment.
Most important of all, this is just one out of 305 kernel patches by our team which were accepted into the mainstream Linux kernel during a one-year period. Almost one patch a day, excluding weekends and holidays. And we are not going to stop! :-)
I'm curious. For the past few months, people@openvz.org have discovered (and fixed) an ongoing stream of obscure but serious and quite long-standing bugs.
How are you discovering these bugs?
Andrew added later:
hm, OK, I was visualising some mysterious Russian bugfinding machine or something.
Don't stop ;)
So, here is the story behind that bug.
A few months ago, in the course of OpenVZ kernel testing, our QA (Quality Assurance) team found a strange issue. The thing is, every container (VE) in OpenVZ has a set of resource usage counters (and limits) called beancounters. All the usage counters should be zero when a VE is stopped, since naturally then all the resources are released. The issue was that a resource called kmemsize (a kernel memory used on behalf of given VE) had a usage counter of 78 bytes after the VE was stopped -- which effectively means 78 bytes of kernel memory were lost (or leaked, as programmers say).
Who cares about 78 bytes, especially on a server with 16 gigabytes (17,179,869,184 bytes) of RAM? We do. Pavel checked the beancounters debug information which showed that one struct user object has leaked. He then tried to reproduce that but with no luck.
Bugs that can not be reproduced are tough. The only option left was to audit the kernel source code. That involved finding all the places where struct user object is referenced, and checking the code correctness (the term "correctness" in this context means that every object that is allocated must later be released). It took him 4 hours to do the audit, and he found one place where the reference to an object might be lost (which means it could not later be released). It's the same as if you lend a book to your friend and later forgot whom you gave it to -- you lost the reference and you can't get the book back.
In this case, after the problem was found, fixing it was pretty straightforward. So Pavel wrote a fix and a demo code to trigger the bug, tested the fix and sent it to Linux kernel mailing list.
Why is this particular incident so important?
* It's OpenVZ code (beancounters) which helped to detect the leak in the first place -- as the bug is very hard to trigger (unless you know how) and the leak is small enough that it might not be discovered at all.
* It demonstrates OpenVZ developers dedicated attitude. They never dismiss real bugs as "works for me" or "invalid", and work to find the root cause and fix the problem.
* This bug is in fact a security issue. An ordinary user (actually two users are needed in this case) could exploit the bug and eat all the kernel memory, thus bringing the whole system down. Worse scenarious are possible as well.
* Incidentally, OpenVZ is protected from this security issue -- because kmemsize beancounter (which helped to found it) limits kernel memory usage per Virtual Environment.
Most important of all, this is just one out of 305 kernel patches by our team which were accepted into the mainstream Linux kernel during a one-year period. Almost one patch a day, excluding weekends and holidays. And we are not going to stop! :-)
Ok, I decided to slap together a quick (48 minutes is quick?) video that gives the basics of what OpenVZ is... and then I spend more time actually doing a hands on demo which includes:
1) Installing OpenVZ from scratch
2) Creating a CentOS 4 template cache
3) Create two VPSes
4) Examine the VPSes
5) Examine things from the host machine view
6) Examine things from the VPS view
7) Do an offline migration
This is a draft and suggestions are welcome although I think it is pretty darn good for a first attempt... although I did go quite fast.
Opps, almost forgot the URL:
http://www.montanalinux.org/openvz-intro-video.html
1) Installing OpenVZ from scratch
2) Creating a CentOS 4 template cache
3) Create two VPSes
4) Examine the VPSes
5) Examine things from the host machine view
6) Examine things from the VPS view
7) Do an offline migration
This is a draft and suggestions are welcome although I think it is pretty darn good for a first attempt... although I did go quite fast.
Opps, almost forgot the URL:
http://www.montanalinux.org/openvz-intro-video.html
Last week we finalized the upgrade of our Proxmox Mail Gateway from Debian Sarge to Debian Etch. This was quite challenging due to the number of changed packages.
The easiest part was the migration and update of the Proxmox OpenVZ template – and that’s why we all love OpenVZ. Now, the Mail Gateway 2.0 can run on OpenVZ and Virtuozzo with just a few clicks, see the Wiki
For doing a backup of a running VPS, we use vzdump, which is now production ready and available in version 1.0.
I remember the dark days where we did Linux distribution upgrades on production machines on the weekend and in long nights, always with high risk of service interruption, without the use of OS virtualization. Now, the weekends are back again ;-)
OpenVZ will not save the world, but makes life much easier.
The easiest part was the migration and update of the Proxmox OpenVZ template – and that’s why we all love OpenVZ. Now, the Mail Gateway 2.0 can run on OpenVZ and Virtuozzo with just a few clicks, see the Wiki
For doing a backup of a running VPS, we use vzdump, which is now production ready and available in version 1.0.
I remember the dark days where we did Linux distribution upgrades on production machines on the weekend and in long nights, always with high risk of service interruption, without the use of OS virtualization. Now, the weekends are back again ;-)
OpenVZ will not save the world, but makes life much easier.
We're very excited that this year OpenVZ will have exhibit space in the dot-org pavillion of LinuxWorld in San Francisco, August 6-9. We will be showing and demoing OpenVZ server virtualization, answering questions and so on.
Here is the best news of all. We can have up to 7 people at our exhibit. While a few OpenVZ developers will come, it will definitely be less than 7. We do not want to stall OpenVZ development. :)
We would like the community to participate with us in the event. If you live in California (or can come to this LinuxWorld), are an OpenVZ user and would like to be a part of our team at the OpenVZ exhibit -- you are very welcome to join us! Please email me (kir@openvz.org) your details and we'll discuss arrangements.
Here is the best news of all. We can have up to 7 people at our exhibit. While a few OpenVZ developers will come, it will definitely be less than 7. We do not want to stall OpenVZ development. :)
We would like the community to participate with us in the event. If you live in California (or can come to this LinuxWorld), are an OpenVZ user and would like to be a part of our team at the OpenVZ exhibit -- you are very welcome to join us! Please email me (kir@openvz.org) your details and we'll discuss arrangements.
I had the opportunity to talk about OpenVZ at this years Linuxtag in Berlin, Germany. For some reason the slot for the talk was 90 minutes (not 60 minutes, as for the other talks at Linuxtag) - maybe because Alan Cox had a parallel session. So I thought this will be a hard job, keeping the audience from falling asleep after lunch. But OpenVZ seems to be so fascinating, that even when I mentioned after 50 minutes that I have told the most important things, but I have some slides left with more details for those who still want more information, only two people left, and the remaining 70 - 80 stayed!
I shot a photo of the audience after the live demo. As the flash of my camera did not work the first time, I took a second snapshot. I said, "It seems that taking a picture with a digicam needs more time than OpenVZ needs to start a Virtual Environment", and the whole audience started laughing ;-)
So, here is the pic:

You can find the description of the talk at the Linuxtag website, and the slides on my private website. Thanks to Kir, he had prepared most of the slides!
I shot a photo of the audience after the live demo. As the flash of my camera did not work the first time, I took a second snapshot. I said, "It seems that taking a picture with a digicam needs more time than OpenVZ needs to start a Virtual Environment", and the whole audience started laughing ;-)
So, here is the pic:
You can find the description of the talk at the Linuxtag website, and the slides on my private website. Thanks to Kir, he had prepared most of the slides!
Recently, I had the opportunity to present at a session of the Gelato Itanium Conference and Expo in San Jose. It was a good fit because they had a special track on virtualization, and OpenVZ (and the Virtuozzo product) is the only stable virtualization technology available now for Itanium servers.
Once again, I was able to talk with Andrew Morton (a kernel hacker, the right hand of Linus Torvalds) and was encouraged about the prospect of OS virtualization and OpenVZ in the Linux kernel. That is something we would really like to see and have been working towards. This article summarizes Andrew’s remarks noting “OpenVZ already has thousands of systems out there” and “as far as containerization standard in mainline goes, ‘most of the stakeholders are playing together quite nicely’”.
Yes, we are and we’ll keep at it so we can realize our goal.
Once again, I was able to talk with Andrew Morton (a kernel hacker, the right hand of Linus Torvalds) and was encouraged about the prospect of OS virtualization and OpenVZ in the Linux kernel. That is something we would really like to see and have been working towards. This article summarizes Andrew’s remarks noting “OpenVZ already has thousands of systems out there” and “as far as containerization standard in mainline goes, ‘most of the stakeholders are playing together quite nicely’”.
Yes, we are and we’ll keep at it so we can realize our goal.
HP labs has performed and published a performance evaluation of OpenVZ and Xen for server consolidation. The 14 pages PDF can be viewed here: HPL-2007-59R1.pdf (418K). Update: links to the paper updated.
I wrote about a Xen/OpenVZ comparison last month here -- the one that was done by a German student as his thesis. I am really glad to see another third party evaluation. (I would never ever trust any comparisons done by or sponsored by vendors.) I also like the level of details provided. Here are quotes from the last section:
For all the configurations and workloads we have tested, Xen incurs higher virtualization overhead than OpenVZ does, resulting in larger difference in application performance when compared to the base Linux case.
<...>
For all the cases tested, the virtualization overhead observed in OpenVZ is limited, and can be neglected in many scenarios.
For all configurations, the Web tier CPU consumption for Xen is roughly twice that of the base system or OpenVZ.
Does that mean OpenVZ is better for scenarios such as Linux servers consolidation? Yes, much better. Does that mean Xen is not good? No, not really. Xen has its applications as well (say when you also want to run Windows on the same piece of hardware), and in fact OpenVZ and Xen can nicely and happily co-exist.
I wrote about a Xen/OpenVZ comparison last month here -- the one that was done by a German student as his thesis. I am really glad to see another third party evaluation. (I would never ever trust any comparisons done by or sponsored by vendors.) I also like the level of details provided. Here are quotes from the last section:
For all the configurations and workloads we have tested, Xen incurs higher virtualization overhead than OpenVZ does, resulting in larger difference in application performance when compared to the base Linux case.
<...>
For all the cases tested, the virtualization overhead observed in OpenVZ is limited, and can be neglected in many scenarios.
For all configurations, the Web tier CPU consumption for Xen is roughly twice that of the base system or OpenVZ.
Does that mean OpenVZ is better for scenarios such as Linux servers consolidation? Yes, much better. Does that mean Xen is not good? No, not really. Xen has its applications as well (say when you also want to run Windows on the same piece of hardware), and in fact OpenVZ and Xen can nicely and happily co-exist.
Just in case you are anywhere near the Northwest corner of the United States (I live in Montana), I wanted to mention the Linuxfest Northwest 2007 that is this coming weekend (April 28-29) in Bellingham Washington. OpenVZ will be represented both days by John Blanford in a presentation entitled, "Linux Virtualization with OpenVZ". I plan on attending the session on Saturday. Be sure and stop by and say hello if you can.

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