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.RHEL6 kernel needs an appropriate (i.e. recent) Linux distribution. If you don't want latest Fedora releases, can't afford RHEL6, and tired of waiting for CentOS 6, I suggest you go with Scientific Linux 6 (SL6). This is yet another RHEL6 clone developed and used by CERN, Fermilabs and other similar institutions.
While SL6 is still at its infancy (they have recently released alpha 3 and plan to release beta 1 at Jan 7 2011), it it worth trying since it's based on a very stable set of sources from RHEL6. Repositories and stuff are available from http://ftp.scientificlinux.org/linux/scientific/6rolling/
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/
The bad news are the exploit is pretty serious and causes Denial of Service. It looks like most kernels are indeed vulnerable.
The good news is OpenVZ is not vulnerable. Why? Because of user beancounters.
( All the gory detailsCollapse )
Of course, if you set all beancounters to unlimited, exploit will work. So don't do that, unless your CT is completely trusted. Those limits are there for a reason, you know.
You might have noticed that we have announced a new kernel branch named rhel5-testing a while ago (back in July, to be more specific). The idea is pretty simple: at the same time as giving the new kernel to our internal QA we are releasing it to rhel5-testing.
Although this change imposes some more work on me (more kernels to release, scripts to run, changelogs to prepare), I'm pleased to say that this model works very well. First, vendors who use our kernels as a base for theirs (for example, OWL) now enjoy earlier access to the sources. Second, new kernels get more testing coverage due to OpenVZ users who choose to use this branch. Finally, it works as a “technology preview”.
Now, let me explain why we have so strange version numbers in the recent rhel5-testing kernels — kernels 028stab07x are intermixed with 028stab070.y. The thing is, we still keep updating 028stab070.y with new fixes and upstream (RHEL) updates, while 028stab07x is a newer “sub-branch” which adds a few new features:
- live migration of containers with NFS and AutoFS mounts
- iotop working in containers and the host system
Because of these new features, these kernels haven't reached the stability yet so we keep releasing those in rhel5-testing. Hopefully soon it will end up being stable enough and we will abandon 028stab070.y in favor of 028stab078 (or so).
Update: this post was mostly written yesterday. Today we have just released 028stab078.1 kernel.
Update 7 Oct 2012: comments disabled due to spam
I performed everything in pretty short time, about 3 hours, but it was only possible because before starting the actual procedure I did a lot of experimenting (on a cloned container) for couple of days, so I already knew all the rough edges (yes, there were some). For now I hope I have resolved anything outstanding (like a non-working search or garbled Cyrillic in message titles), but in case you see something strange please report back to me. Non-outstanding task is to make the forum look a bit better -- for now I just put in OpenVZ logo which doesn't look all that great...
The reason for upgrade was to stop spam. FUDforum 3.0.1 have a feature to moderate user's first N posts -- this one should prevent those bastards to post "Sell CVV", "Unlocked iPhone 4G" and other crap. Before now I had to deal with that manually, i.e. by removing the crap. Now, instead, I will moderate the first post of all new users. In addition, users with only a few posts (currently less than 10) are not able to use links in their posts -- that should also help in our eternal spam fighting.
Update: comments disabled due to spam.
As you may know, Parallels / OpenVZ has a 2.6.32 "devel" branch and a goal of making it the next "stable" branch. They have had several 2.6.32 releases and have been putting a lot of work into it. This work has also lead to 29 patches so far that have made their way into the mainline 2.6.32 kernel updates. This ranks Parallels the 9th top updates contributor (or 11th if you count "None" and "Unknown"). It should be noted that these mainline contributions benefit everyone and are not OpenVZ specific... just in case someone were to get confused and wrongly think the patches were an attempt to get OpenVZ into the mainline.
Want to read about it for yourself? It is currently subscriber-only content that should becoming freely available on September 9th. I've been an LWN reader since the beginning and a paying subscriber since they went to a subscription model. I can provide a "subscriber-link" that will allow non-subscribers to read the article as an enticement to become a subscriber. Once it is freely released, I'll try and remember to update this post with a new link.
To the Parallels / OpenVZ developers I say... Thanks for the continuing hard work on 2.6.32, your contributions are appreciated... and I look forward to the upcoming "stable" 2.6.32 OpenVZ kernel.
They had to locate a venue for the meetings, set a date and time, etc... and I will be presenting "Introduction to OpenVZ" for their first new meeting. For details see their website... which has only recently been redone and is still in the beginnings stage.
Before the topic was picked I gave them 5 or 6 potential topics to pick from and they voted and selected OpenVZ. Seems that OpenVZ is not well known in Memphis but I hope to change that.
I am in Ottawa since last night, despite all the challanges on the way -- ( really, click here if you want to read the whole storyCollapse )
The big problem is I caught a cold during the first flight, and now I feel strange. I can not listen to the talks (except for the keynote), I am taking pills ( a story about pills, way smallerCollapse ) and such, gargling the NaCl solution, and all that. So far it helps a little -- I either have a fever or feel like a slowpoke under the drugs.
My talk is moved from Wednesday evening to Thursday morning (not because of me, and I only found it while getting a badge). I hope I will be less of a hot vegetable by that time. I need to make it because I already did most of it.
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.
- Current Mood:awake

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