Top.Mail.Ru
? ?

cpulimit is back in RHEL6 based kernel

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.
We have just released a new RHEL6-based kernel, 042test005. It is shaping up pretty good — as you can see from the changelog, it's not just bug fixes but also performance improvements. If you haven't tried it yet, I suggest to do it today! Do not postpone this until 2011 — after all, this is what will become the next stable OpenVZ kernel.

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/

vzctl 3.0.25 released today, woo-hoo!

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/

Tags:

Yesterday a guy with his name written in Cyrillic letters ("Марк Коренберг") and a @gmail.com email address posted a kernel exploit to the Linux kernel mailing list (aka LKML). This morning one brave guy from our team tried to run it on his desktop -- and had to reboot it after a few minutes of total system unresponsiveness.

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.

On RHEL5 kernel releases

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

Forum upgrade

I have just finished upgrading all the software that runs forum.openvz.org. This one is run in a separate container which I have to update to CentOS 5 first, in order to get PHP5 and MySQL 4. Then I have updated fudforum from the last 2.x release up to 3.0.0 and then 3.0.1.

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.
Jon Corbet wrote a piece yesterday that will be in next week's Linux Weekly News entitled, "Some numbers and thoughts on the stable kernels". The point of the article is to review the last five years of stable mainline kernel releases and the updates to them.

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.

OpenVZ Presentation for GOLUM

I'm on vacation in Memphis, Tennessee visiting family. A couple of weeks before going on vacation I looked for a Linux Users Group in Memphis to see if I could attend or even possibly present at one of their meetings. The Group of Linux Users Memphis (GOLUM) has been around for well over a decade and continues to have an active mailing list... but their website was outdated and they hadn't had a meeting in the last two years. My inquiry lead to a resurgence of GOLUM with a desire to start having monthly meetings again.

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.

hello from Ottawa

When I have a high temperature, i.e. fever, I am very talkative. I just measured it up to 39.6deg;C (103.3°F). Now I don't have anyone to talk to verbally, so I'm blogging. You have been warned. But no, this post is not contageous.

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.

Just in case you missed it

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.

Tags:

Latest Month

July 2016
S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      

Syndicate

RSS Atom

Comments

Powered by LiveJournal.com
Designed by Tiffany Chow