I thought that Monday is a good day to release a new version of vzctl which was worked on for the last six months. There are a few important changes in this release, let me go through it.
First, we have finally removed all the cronscripts trickery required for CT reboot. The thing is, if the container owner issues 'reboot' command from inside, the container just stops. Now, something needs to be done on the host system to start it again. Until this release, this was achieved by a hackish combination of vzctl (which adds an initscript inside container to add a reboot mark) and a cron script (which checks for the stopped containers having that reboot mark and starts those). Yet another cron script takes care about a situation when a CT is stopped from the inside -- in this case some cleanup needs to be done from the host system, namely we need to unmount the CT private area, and remove the routing and ARP records for the CT IP.
There are a few problems with this cron-based approach. First, initscript handling can be different in different distributions, and it's really hard to support all of the distros. Second, cron script is run every 5 minutes, which means a mean time to reboot (or clean up network rules) is 2.5 minutes. To say it simple, it's all hackish and unreliable.
Now, this hairy trickery is removed and replaced by a simple and clean daemon called vzeventd, which listens to CT stop and reboot events, and runs clean and simple scripts. No more trickery, no more waiting for reboot. The only catch is this requires support from the kernel (which comes in a form of vzevent kernel module).
Second, new vzctl is able to start Fedora 14 containers on our stable (i.e. RHEL5-2.6.18) kernels. The thing is, Fedora 14 have glibc patched to check for specific kernel version (>=2.6.32 in this case) and refuse to work otherwise. This is done to prevent glibc from using the old kernels with some required features missing. We patch our kernels to have those features, but glibc just checks the version. So, our recent kernels is able to set osrelease field of uname structure to any given value for a given container. Now, vzctl 3.0.25 comes with a file (/etc/vz/osrelease.conf) which lists different distros and their required kernel version, which it sets during start and exec.
I want to briefly mention yet another feature of recent vzctl (which, again, needs kernel support) -- an ability to delegate a PCI device into a container. It is only supported on RHEL6 kernel at the moment, and the only devices that we have tried are NVidia GPUs.
Besides these three big things, there are a lot of improvements, fixes, and documentation updates all over the tree. I don't know of any known regressions in this release but I guess it's not entirely Bug Free. Fortunately there's a way to handle it -- if anything really bad appears in this version, it will be fixed by a quick 3.0.25.1 update. This worked pretty well for vzctl-3.0.24, should work fine this time, too.
As always, please report all the bugs found to http://bugzilla.openvz.org/
First, we have finally removed all the cronscripts trickery required for CT reboot. The thing is, if the container owner issues 'reboot' command from inside, the container just stops. Now, something needs to be done on the host system to start it again. Until this release, this was achieved by a hackish combination of vzctl (which adds an initscript inside container to add a reboot mark) and a cron script (which checks for the stopped containers having that reboot mark and starts those). Yet another cron script takes care about a situation when a CT is stopped from the inside -- in this case some cleanup needs to be done from the host system, namely we need to unmount the CT private area, and remove the routing and ARP records for the CT IP.
There are a few problems with this cron-based approach. First, initscript handling can be different in different distributions, and it's really hard to support all of the distros. Second, cron script is run every 5 minutes, which means a mean time to reboot (or clean up network rules) is 2.5 minutes. To say it simple, it's all hackish and unreliable.
Now, this hairy trickery is removed and replaced by a simple and clean daemon called vzeventd, which listens to CT stop and reboot events, and runs clean and simple scripts. No more trickery, no more waiting for reboot. The only catch is this requires support from the kernel (which comes in a form of vzevent kernel module).
Second, new vzctl is able to start Fedora 14 containers on our stable (i.e. RHEL5-2.6.18) kernels. The thing is, Fedora 14 have glibc patched to check for specific kernel version (>=2.6.32 in this case) and refuse to work otherwise. This is done to prevent glibc from using the old kernels with some required features missing. We patch our kernels to have those features, but glibc just checks the version. So, our recent kernels is able to set osrelease field of uname structure to any given value for a given container. Now, vzctl 3.0.25 comes with a file (/etc/vz/osrelease.conf) which lists different distros and their required kernel version, which it sets during start and exec.
I want to briefly mention yet another feature of recent vzctl (which, again, needs kernel support) -- an ability to delegate a PCI device into a container. It is only supported on RHEL6 kernel at the moment, and the only devices that we have tried are NVidia GPUs.
Besides these three big things, there are a lot of improvements, fixes, and documentation updates all over the tree. I don't know of any known regressions in this release but I guess it's not entirely Bug Free. Fortunately there's a way to handle it -- if anything really bad appears in this version, it will be fixed by a quick 3.0.25.1 update. This worked pretty well for vzctl-3.0.24, should work fine this time, too.
As always, please report all the bugs found to http://bugzilla.openvz.org/


Comments
Now to build an updated Fedora 14 OS Template for contrib.
Thanks for the removal of the cron stuff. Making this stuff cleaner is an important step for OpenVZ. I will be testing 3.0.25 and if it goes well with our changes, I will have some patches for you to get vzctl supporting Funtoo by default.
Best Regards,
Daniel
root@13 ~]# vzctl restart 1034
Removing stale lock file /vz/lock/1034.lck
Restarting container
Stopping container ...
Container was stopped
Container is unmounted
Starting container ...
Container is mounted
Adding IP address(es): ***********
Setting CPU limit: 200
Setting CPU units: 1000
Setting CPUs: 2
Setting devices
Segmentation fault
And vzctl log:
2010-12-23T11:03:25-0500 vzctl : CT 1034 : Removing stale lock file /vz/lock/1034.lck
2010-12-23T11:03:25-0500 vzctl : CT 1034 : Restarting container
2010-12-23T11:03:25-0500 vzctl : CT 1034 : Stopping container ...
2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container was stopped
2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container is unmounted
2010-12-23T11:03:34-0500 vzctl : CT 1034 : Starting container ...
2010-12-23T11:03:34-0500 vzctl : CT 1034 : Container is mounted
2010-12-23T11:03:35-0500 vzctl : CT 1034 : Adding IP address(es): ***********
2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPU limit: 200
2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPU units: 1000
2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting CPUs: 2
2010-12-23T11:03:35-0500 vzctl : CT 1034 : Setting devices
2010-12-23T11:04:29-0500 vzeventd : Child 2261 failed with exit code 79
A rollback to the previous version fixes it.
The problems ive seen so far is that the container will boot but the container is allocated the whole host memory.
Merry Christmas btw!
"vzctl 3.0.25-1 (OpenVZ Container Management Tool), has for some reason made it into the stable branch of the OpenVZ repository without being fully tested. If you have this version installed, your containers may have access to the full amount of host memory and tun/tap will not function within the container. We have only found these two issues so far, however the bug has only just been reported."
Apparently there's a bug in it , not only the segfaults, but also allowing a container full host memory access, so they sent out an email not that long ago advising everyone to downgrade if they got 3.0.25-1 (when I went to update yum in CentOS 5.5 sure enough 3.0.25-1 is being deployed, I opted not to upgrade)
Is an entry on the wiki or anywhere else with some information on this (awesome) feature ?