Hard CPU limit (ability to specify that you don't want this container to use more than X per cent of CPU no matter what) is back in latest RHEL6-based kernel, 042test006.1, which has just been released.
The feature was only available for the stable (i.e RHEL4 and RHEL5-based) kernels, and was missing from all of our development kernels from 2.6.20 to 2.6.32. So while it was always there in stable branches, the feeling is like it's back.
In order to use CPU limit feature, set the limit using vzctl set $CTID --cpulimit X, where X is in per cent of one single CPU. For example, if you have single 2 GHz CPU and want container 123 to use no more than 1 GHz, use vzctl set 123 --cpulimit 50. If you have 2 GHz quad-core system and want to use no more than 4 GHz, use vzctl set 123 --cpulimit 200. Well, in the second case it might be better to just use --cpus 2. Anyways, see vzctl man page.
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.
Just wanted to mention a few news items from the OpenVZ Project.
Updated vzctl - vzctl 3.0.24 has been released. Even though the version number only changed from 3.0.23 to 3.0.24 there are a ton of changes, fixes and some feature additions. Of special interest is the --swappages option as well as being able to refer to a container by its name rather than requiring the CTID with vzmigrate. Overall it was a long overdue, much appreciated update.
Updated Official OS Templates - The last wiki notice is dated April 27th but looking today at the dates on the OS Templates they appear to have been updated May 27th. One thing to note is that there are now OS Templates for Ubuntu 10.04 which I'm sure Ubuntu folks will be happy about.
Beta Fedora 13 OS Templates - And speaking of OS Templates, Kir just released Beta OS Templates for Fedora 13. The day Fedora 13 was released I tried creating my own OS Templates by taking Fedora 12 containers and upgrading them but ran into a snag. With Fedora 13 a lot of new stuff has been added to the init setup and some of it causes a container to just hang during init. I was glad to see the beta OS Templates released. I created containers from them, made my own changes, and then uploaded those to the contrib section.
As luck would have it, later in the afternoon the Fedora Project release a whole bunch of updates and among them was a new initscripts package. I suspected that when I upgraded my container whatever changes the OpenVZ folks had made to the init setup that made it work in a container would be wiped out and I was correct as upgrading the initscripts package did indeed make the container get stuck in the init process upon container reboot. I ended up filing two bugs: 1566 and 1567 and await their joyful resolution.
*** Please note*** Any URLs mentioned (and the information they contain) in this posting are time sensitive and will surely be outdated not long after posting.
Long time no see. It's 11pm here now and I'm still in the office. Just though about why not to post to the blog right before I drive home. Really, why not?
I'm mostly working on new vzctl release lately (you can see the progress in vzctl's git web interface here). The ultimate task is to fix most of bugs opened for vzctl in OpenVZ bugzilla (some are dated back to 2007 -- no, they are not critical or even major, but anyway). So far the list of vzctl bugs yet opened are down to one singe page (i.e. scroll bar has disappeared from the browser window) which is a big improvement.
The process is somewhat slow because ( why?Collapse )
The way to perfection is never easy. That doesn't mean we shouldn't try.
There is a nice feature in vzctl (well, technically not in vzctl binary itself; it just comes in vzctl package) that many people don't know about -- completion. This basically makes it able to save a few keystrokes when typing.
Say you want to create a container. You type vzct and press <TAB> -- it completes that to vzctl and a space after. This is usual feature of bash -- it looks all the binaries available in $PATH and tries to complete their names.
Now let's see the vzctl completion: # vzctl cr<TAB> completes to # vzctl create and then after yet another <TAB> it suggests a CT ID which is the MAX+1 (i.e. if you have containers 101, 102 and 105 it will suggest 106): # vzctl create 106 Now we want to specify an OS template: # vzctl create 106 --os<TAB> will get you to # vzctl create 106 --ostemplate and then you press <TAB> again twice to see the list of available OS templates: # vzctl create 106 --ostemplate <TAB><TAB> centos-5-x86 centos-5-x86-devel fedora-9-x86 suse-11.1-x86 Now you type in the first few characters of the OS template you want to use: # vzctl create 106 --ostemplate f<TAB> and it will complete that to # vzctl create 106 --ostemplate fedora-9-x86 Now, unless you want to specify --config or some other parameters, just press Enter.
This completion is smart -- say, if you want to start a container, type in # vzctl start <TAB><TAB> and it will give you the list of container IDs that can be started (i.e. all the stopped containers).
And so on and so forth. Well, you say, it doesn't work! In that case you have to enable it, here's how.
On a RHEL, CentOS or Fedora system run yum install bash-completion and then relogin (i.e. log out and log in again). If your host system is Gentoo, run emerge bash-completion and then eselect bashcomp enable vzctl. I hope someone will comment on how to enable this for Debian/Ubuntu/SUSE or whatever your favorite distro is.
OpenVZ project has released both new vzctl and vzquota tools today.
New vzctl has a handful of new small features and a bunch of bugfixes, including compatibility with recent glibc, bash, and kernel headers.
New vzquota has only one (but quite useful) new feature -- an ability to explain what's wrong when it can not turn container's disk quota on or off. Recent OpenVZ kernels have a feature to report open files in container's private area, and now with the new vzquota the feature is finally available for mere mortals.
In the meantime Parallels has released Parallels Desktop for Mac 4.0 -- and that's just a coincidence, I'm sure they do not sync their release cycles with OpenVZ. Or maybe it's not a coincidence... We're sitting in the same office and for the last few weeks they've been providing free late dinners because of their release, that maybe made me leave the office later and thus maybe gave more time to work on OpenVZ tools. :)
I tried it and was able to migrate a CentOS 7 container... but the Fedora 22 one seems to be stuck in the "started" phase. It creates a /vz/private/{ctid} dir on the destination host (with the same…
The fall semester is just around the corner... so it is impossible for me to break away for a trip to Seattle. I hope one or more of you guys can blog so I can attend vicariously.
Comments
Do you still stand by your opinions above now in 2016?…