The Linux Link Tech Show

I will be a guest on The Linux Link Tech Show this evening (Wednesday, Dec. 17th) representing the OpenVZ Project so check it out. It will be streamed live starting at 8:30PM Eastern Standard Time and here are links for your favorite audio application that can stream over http:

At some point after the live show, it will be archived and available for download as an .mp3 or .ogg.

Updated Introduction to OpenVZ screencast

Since the last intro video I made was over 1.5 years ago, I thought I’d make a new one.

Screencast: vzpkg2 & pkg-cacher

Robert Nelson released updated versions of vzpkg2 and pkg-cacher… as well as updated OS Template metadata packages for Fedora, CentOS, Debian and Ubuntu. In all there are 48 different OS Templates that can easily be built using his software. I’m hoping to get more people in the community interested/involved so I made a screencast. If more people get involved, do more testing, and provide feedback… hopefully at some point in the not too distant future Robert’s new software can replace the stock vzpkg that the OpenVZ Project provides.

New vzctl and vzquota

Today is definitely a day of releases.

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. :)

OpenVZ is running on an ARM (Gumstix Overo)!

When my colleague Pavel Emelyanov returned from the 2008 Linux kernel summit back in September he brought a small present for me — a Gumstix Overo (every LKS participant got one for free; yet another reason to become a high-profile kernel developer!). Overo is a computer (well, actually a set of boards and cables) with a CPU board the size of a gum stick, featuring TI OMAP3 CPU, 128 megs of RAM and a microSD slot. It also has 802.11g Wi-Fi and Bluetooth but those happens to be completely dead as this the first beta release of hardware.

For the last few days I was digging into a project to make OpenVZ running on this Overo thing. That involved patching OpenVZ kernel to support ARM architecture, building vzctl package (.ipk) for ARM using bitbake, and creating a template.

It was amazingly easy to port the OpenVZ kernel to ARM; you can see here that besides a big-all-in-one-openvz-for-2.6.27 patch I only had to add 4 tiny ARM-specific patches (1, 2, 3, 4). For vzctl, it was even easier — all I had to do is to add openvz syscall numbers for ARM which were added, and create a bitbake recipe file.

Creating a template for ARM architecture was tougher but I managed to win that fight, too — you can find a Debian Lenny template here.

Here is an except from a terminal session showing OpenVZ on Overo:

root@overo:~# uname -a
Linux overo 2.6.27-omap1 #1 Tue Oct 21 21:19:40 MSD 2008 armv7l unknown unknown GNU/Linux

root@overo:~# cat /proc/vz/version
037test001

root@overo:~# vzlist
CTID NPROC STATUS IP_ADDR HOSTNAME
777 5 running - -

root@overo:~# vzctl enter 777
entered into CT 777
-bash-3.2# ps axf
Unknown HZ value! (0) Assume 100.
PID TTY STAT TIME COMMAND
310 ? Ss 0:00 vzctl: pts/0
311 pts/0 Ss 0:00 \_ -bash
313 pts/0 R+ 0:00 \_ ps axf
1 ? Ss 0:00 init [2]
208 ? Sl 0:00 /usr/sbin/rsyslogd -c3
227 ? Ss 0:00 /usr/sbin/cron

Please note that all this is still in very alpha stage — there are errors, bugs, ugly warnings, you have to modify some things in place etc. But it’s working. If someone is interested in running OpenVZ on ARM hardware, please let me know — leave a comment here or email kir (A) openvz (.) org.

2.6.26 kernel and Russian writers

We are going to release first 2.6.26-based kernel soon — it went to testing today and hopefully will be released next week.

We are also changing the versioning scheme — instead of boring numbers like 001, 002, 003 etc., every 2.6.26 OpenVZ kernel will be named after one or another great Russian writer. We will do it in alphabetical order so there will be no upgrade pain.

As you can see here, first 2.6.26 is named after Mikhail Afanasievich Bulgakov. I personally enjoy his The Master and Margarita (it’s truly a masterpiece; although I’m afraid a lot is lost in translation) and Heart of a Dog.

And yes, we are doing that just for fun.

Interview with vzpkg2 and pkg-cacher creator Robert Nelson

Robert Nelson was kind enough to agree to an email-based interview which readers of the OpenVZ Users mailing list will have already seen. Robert has written a replacement for vzpkg (currently named vzpkg2) and has greatly enhanced it with the addition of a package named pkg-cacher. For an introduction to OS Templates and the tools used to manage them as well as Robert’s fantastic answers, see:

Interview with vzpkg2 and pkg-cacher creator Robert Nelson

Obligatory quote:

ML: You have added a number of features / capabilities to vzpkg. Could you give us an overview of what’s new?

Robert: I think the most significant change over the stock version of vzpkg is the separation of the packager specific code from the higher level code. This allows scripts to be written to support other package managers like apt which is used on Debian and Ubuntu.

The other slightly less significant change is the introduction of the concept of a hierarchical structure to the template meta data. Information which is the same for all versions and platforms of a distribution need only be specified once. If there is a need for separate settings for a specific version it can be overridden by a file lower in the template meta data tree.

Also new packager-independent commands have been added for managing packages in installed containers.

One thing worth mentioning is that while the number of OS Template Metadata packages provided by the OpenVZ Project is quite limited, Robert has created new metadata packages for vzpkg2 that allow for easily building CentOS, Debian, Fedora, and Ubuntu OS Templates. If I counted correctly, Robert’s new metadata packages make it easy to build 44 different OS Templates. Wow!

It might take a few more weeks before vzpkg2 and pkg-cacher are finalized and added to the OpenVZ Project repositories. If you don’t want to wait and would like to help out with testing, Robert has posted some instructions to the OpenVZ Users mailing list and here is a link to the archive for the time period in question:

http://openvz.org/pipermail/users/2008-September/thread.html

Net "beta" OS Templates

Just wanted to mention that Kir created a new directory at the top level of the download site named beta. Inside of it you’ll find a directory structure that you can eventually drill down into to find a number of new, beta OS Templates that Kir has built. Here’s a list:

centos-4-x86_64.tar.gz, centos-4-x86.tar.gz, centos-5-x86_64.tar.gz, centos-5-x86.tar.gz, debian-3.1-x86.tar.gz, debian-4.0-x86_64.tar.gz, debian-4.0-x86.tar.gz, fedora-7-x86_64.tar.gz, fedora-7-x86.tar.gz, fedora-8-x86_64.tar.gz, fedora-8-x86.tar.gz, fedora-9-x86_64.tar.gz, fedora-9-x86.tar.gz, suse-10.3-x86_64.tar.gz, suse-10.3-x86.tar.gz, ubuntu-7.10-x86_64.tar.gz, ubuntu-7.10-x86.tar.gz, ubuntu-8.04-x86_64.tar.gz, ubuntu-8.04-x86.tar.gz

Sorry SUSE fans, no openSUSE 11 yet. :(

One big difference is that the Fedora and CentOS OS Templates now include yum which will make a number of people happy. No more fumbling around trying to download a bunch of rpm packages an using rpm to install yum.

The CentOS 5 OS Template

Oddly enough an OpenVZ “official” pre-created OS Template for CentOS 5 did not previously exist although there have been a number of builds posted in the “contrib” section. So far, I’ve tested out the CentOS 5 x86 and x86_64 OS Templates and they are a bit different from the contrib releases. For one thing, udevd is installed and running and the vzdev package puts files in /etc/udev/devices/ rather than /dev. This is good, because on previous CentOS Templates udev was not installed and if it happened to get installed as a dependency for something else, it would prevent future container starts from working… until udev was removed or the starting of udev was commented out from /etc/rc.d/rc.sysinit. Perhaps including udev will make migrating physical servers to OpenVZ containers a little more easy.

There are a number of updated vz packages installed that include:

vzdummy-kernel-el5, vzdummy-jre-fc6, vzdummy-glibc, vzdummy-apache, vzdev

The CentOS 5 OS Template is quite light-weight resource wise as a container made from initially only takes up about 14MB of RAM. The vzdummy-apache package helps there because it offers a modification to the stock Apache configuration (/etc/httpd/conf.d/swtune.conf) that changes the StartServers value to 1.

Community, please test these out and report any bugs you find!

how free software works: Red Hat and OpenVZ

Here is an example of how things are working in the free software world.

We at OpenVZ use kernels from Red Hat Enterprise Linux as a base for our OpenVZ kernels. This is because vendors such as Red Hat invest a lot of work into making their kernels really stable. The usual recipe for a super-stable kernel is to pick a mainstream kernel and marinate it in QA for at least half a year (more for the best results), doing bugfixing and cherry-picking of fixes and driver updates from the mainstream. This way one have enough time to test it, plus (at least in theory) one get new fixes but do not get new bugs slipped into one’s kernel. This is what Red Hat (and other guys such as Novell/SUSE) does for their kernels, and believe me it’s quite a lot of work to do, and the end result is of great value.

Here comes the beauty of free software: now everybody can use the result of Red Hat’s work. Yes, this is exactly what we do. At this point you might stand up saying: all right, Red Hat invested a lot of resources into something you use for free, this does not look like a fair deal.

Fortunately I have a good answer. Here is the list of bug (i.e. software defect) reports that were fixed in Red Hat Enterprise Linux kernels thanks to OpenVZ team (in some way): #405521, #247379, #205335 , #210852, #168659, #243252, #207463, #228461, #243263, #224541, #232209, #232211, #239767, #220971, #400651, #214778, #203894, #212144, #215715, #241096, #241096, #439670. These 22 bugs are all kernel bugs, most are security-related (and therefore quite serious). Almost all the bug reports from the list include patches (i.e. changes to code to fix a problem reported), so those are not like “hey, you have a problem”, but rather “you have a problem and here’s the solution”.

The majority of those bugs were found while testing OpenVZ kernels. This is what we contribute back. This is also a lot of work and of great value — some of those bugs were really hard to find and/or fix.

The latest (23rd) addition to the above list is bug #454865, which is actually a regression in a new version of RHEL4 kernel. Again, this report not only includes a clear description of what’s wrong, but also a test case program which reproduces the bug, and a patch to fix it. Clear test cases are very important because those can be included into a validation test suite, to make sure bugs are not popping out for the second time (which sometimes happens in the real world).

This is just one example, a close-up picture. The big picture is free software developers and users helping other developers and users. Unus pro omnibus, omnes pro uno.

Is anyone aware of a distro which supports its running in OpenVZ?

I mean, in case you’re doing a physical to VE migration, you’re to remember turning some things off and doing other tuning («rat-file works»). And it’s easy to miss something. At the other hand, the distro-devs know their rc-system perfectly (at least some of them should) and direct support of distro run inside VE would be really great. But I’m afraid there’re no such distros, am I wrong?