olemskoi.ru

Current versions of vzdump has dependency for cstream and perl-LockFile-Simple, both available via rpmforge. Below is how I got it to install and run on CentOS-5.5 x86_64 architecture.

It's necessary to export the location of the PVE libraries that vzdump requires. This can be added to «.bash_profile»:

read more

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 — our flight from Moscow was delayed by about half an hour, and in Washington there was a huge queue to the passport officers. And it was a queue for transfer passengers, who obviously have a connecting flight in a few. Airport personnel was of no help, they basically say that everyone is in the same situation. Well, I guess, it might have made sense to check the next flight take-off time of complaining passengers and move some of them to «US citizens» queue which was 6x smaller. They did that, but in random manner, i.e. for some passengers who already made it to the first row. I guess a CFQ scheduler would be a nice addition to that system.

Anyway, after more than 1 hour in a queue I reached the office and was allowed to enter the USA. This was only needed for immediately taking the plane to Canada (where there is another border and another officer and I have another visa in my passport). It is a bit strange to me that there is no direct way for transfer passengers going to other countries. When I said «thank you, sir, bye» to the USA officer, it was exactly 5:20pm — the take-off time of my flight.

So I ran to the baggage check out, then to the security control, then to the gate (a helpful lady said the plane is still there). It took me 10 minutes to go from the officer to the gate, including the time to go back to pick one bag which I forgot at security check. OK, I am sweating and breating hard, but I am in the place.

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 (how paracetamol is named acetaminophen here, and all the other drugs are either absent, not OTC, or have different names is yet another story I won't tell here to save Internet bandwidth and LJ.com storage) 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.

I am still at the OpenVZ booth at LinuxTag 2010 in Berlin. At least two people asked me about the status of OpenVZ kernel for the upcoming Debian Squeeze. Specifically, they said, there is no openvz kernel in «testing» repository (i.e. what will become Squeeze when it will be released). My guess is some more people interesting in that, so here's the public answer.

We are working pretty close with the Debian kernel team, you can see some traces of that on either debian-kernel AT lists.debian.org or debian AT openvz.org mailing lists. Specifically, we work together to bring good quality OpenVZ kernel to Squeeze, and this was one of the main reasons for us to port to 2.6.32.

But yesterday we tried to search for openvz linux-image on packages.debian.org and it gave us no results for testing. I then emailed Max Attems (who maintains our kernels in Debian) and this is his response:

it should be there now, the switch to libata did uphold testing
transition of linux-2.6 for quite some time, so testing had an
outdated linux-2.6 for quite some while

Indeed, the kernel is now there. So yes, Squeeze will have OpenVZ kernel, and I guess it can also be used by people who switched to Ubuntu 10.4.

I am standing here at the LinuxTag 2010 event, so if you are in Berlin this week come to our booth to say hello (and maybe recommend a local beer place to go).

One visitor asked me if it's possible to run Firefox inside a container (with the main purpose to browse insecure sites). Yes, it is possible, there are two ways — using Xvnc and SSH's X forwarding. I just implemented it here (using the latter way), and want to share the experience, because there are a few rough edges here and there.

We start with the «vanilla» Fedora 12 template:
vzctl create 777 --ostemplate fedora-12-x86<br />vzctl start 777

Next thing to do is to make the container access the network. It can be done in different ways, here I used the NAT technique described in wiki, so I am skipping this part here. Just do not forget to set up the nameserver entry in container's /etc/resolv.conf.

At this point you already have an Internet available in container, let's check it:
vzctl exec 777 ping -c 1 openvz.org

OK, now it's time to install firefox and other needed stuff. Besides firefox itself and its dependcies, you need xauth (for ssh forwarding to work) and some fonts that firefox will use:
vzctl exec 777 yum install firefox xauth liberation\*fonts
This command will result in downloading and installing about 100 packages or so, thus it's a perfect time to enjoy some tea.

Next thing to do is to enable X forwarding inside the container:
vzctl exec 777 sed 's/^.*X11Forwarding .*$/X11Forwarding yes/'<br />vzctl exec 777 /etc/init.d/sshd restart

Now, set up a user account in CT to run firefox:
vzctl set 777 --userpasswd ffox:mysecpass

All right, time to actually run firefox. But first make sure you do not have it runnng locally, because if you do, remote firefox will just open up a new window of your already running firefox instance. So,
killall -TERM firefox<br />ssh -Y x.x.x.x dbus-launch firefox

Oh yes, we need dbus-launch here because otherwise firefox complains that it is not able to find machine uuid or something — apparently nowdays Firefox can't be happy without dbus.

That's pretty much it. Enjoy.

We have just announced that we stop making new releases for OpenVZ kernel branches 2.6.24, 2.6.26, and 2.6.18. So, from now on we only have 2.6.27, 2.6.32, RHEL4-2.6.9 and RHEL5-2.6.18. Removing the number of parallel kernel branches we have to maintain really helps to concentrate on supporting the remaining ones and moving to mainline. I hope that doesn't affect anyone too much — from where I stand most users run either stable (i.e. RHEL5-2.6.18) or bleeding edge (2.6.32, before it used to be 2.6.27). In any case, we are not dropping support for vendor kernels, such as OpenVZ kernels in Debian and Ubuntu — those are still supported from us for the lifetime of the distributions that carry it, we will help with OpenVZ bugs in those kernels through the usual channel.

On the remaining branches. Last Thursday we did an update to 2.6.32 kernel fixing some nasty bugs found in the first public version, and today we updated 2.6.27 kernel as well. Speaking of 2.6.27, it will eventually be dropped as well, but we will keep maintaining it for at least a few more months.

Stable kernel update (RHEL5.5 based, 028stab069...) is currently in testing, but don't expect it to be released real soon now — previous experience tells us that .y updates are not that easy. We also anticipate to open RHEL6-2.6.32 branch soon, since Red Hat already shooted a beta of their upcoming release.

Today I came across the page which compares OpenVZ to KVM to Xen. Leaving Xen aside, from that one it looks like KVM is ways better, it got all the green pluses, while OpenVZ got all the dull minuses, except for a few features where it says «limited support».

For example, from the author's POV, KVM supports cool features such as «Independent kernel» and «Independent kernel modules» , while OpenVZ lacks all that. I am not mentioning «Full control on sockets and processes» — definitely, such things as sockets and processes are completely out of control when you use OpenVZ, to the extent that you can not distinguish between a process, a socket, and a potato! (Was that sarcasm? Yes, in fact I don't have an idea of what do they mean by that statement...)

But such a comparison is inspiring, so I invested 15 minutes of my time and made my own, titled Car vs bike. It clearly states that a car is better than a bike — its capacity is higher and it doesn't require lots of muscle power. After all, it has powered steering wheel (not mentioning powered windows) and can come with an automatic gearbox, air conditioning and even a sunroof! A bike, from the other side, is missing a lot of features — even windshield wipers are absent which are standard for every car since about 1925!

Actually, I didn't stop there and made yet another comparison, titled Bike vs car. Now it's perfectly clear that a bike is a better choice than a car, since it's cheaper, ecologically clean, and you can even take it with you on a train! A car is big and heavy, it requires periodical refuelling and a parking spot.

Both comparisons are on the openvz wiki, so feel free to edit and add more features!

OpenVZ will have a booth at the upcoming SCALE8x conference in Los Angeles, California, USA.

I want to design a new t-shirt for the conference (and other future events). So far we have two designs (about which I wrote before here): first «container lifecycle» and then «kernel classics» (you can see both at the shop). Now I want to have something as geeky as the first design, which looks like a screenshot from a terminal, but using a dark-colored t-shirt (I think dark green will fit well).

If you have any suggestions for the design, or yet better can draw it (or a mock-up) — please speak up here or email me (kir at openvz org). If OpenVZ will take your design I promise to post two t-shirts to you.

Some of you may recall that last December I did an experiment where I created 638 OpenVZ containers on an HP Proliant DL380 G5 machine with dual quad-core CPUs and 32GB of RAM. I stopped there because I ran into an error. Well, one of the OpenVZ / Parallels developers suggested a fix back in July both as a comment to my article and as a comment to the bug report... but somehow I overlooked it until I ran across it again the other day when cleaning out my email.

I finally got a chance to give it a try and sure enough it removed the limit I had run into (the sysctl kernel.pid_max default setting being too low) and I verified it by creating 700 containers.

At first I decided to stop there but then I got an email from Kir asking if disk space was going to end up being my real limitation. I'm wondering if Kir has seen other experiments that go to this extreme or if he is simply a good guesser (with some inside information)? Anyway, I decide to bump it up to 1,000 containers. Sure enough, the machine is handling it just fine.

I didn't do a completely new write up, I just wrote a few more comments to the original article and you can find it here:

An OpenVZ Experiment — How many containers?
http://www.montanalinux.org/openvz-experiment.html

Для того, чтобы в контейнере OpenVZ под CentOS заработала блокировка iptables вида (разрешается не больше 4 соединений для порта 22 в течение 180 секунд):

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name DEFAULT --rsource

Необходимо в файле /etc/vz/vz.conf разрешить следующие iptables-модули:

IPTABLES="iptable_filter ipt_multiport ip_conntrack ipt_REJECT"

По-умолчанию ip_conntrack отсутствует в этом списке, iptables при добавлении приведенных выше правил не ругается, но и ничего не работает.

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 of my attitute to fix even minor things thenever I notice them — known as code refactoring. The simplest example is when you open a C file in vim (or Emacs, whatever) and see that there are spaces instead of tabs. When you notice it, there are three ways to go: (A) leave it as is; (B) fix it in place, keep working on what you've planned, commit; © fix it, make a separate commit, then continue working on what you've planned.

Way A is not that bad, actually, it's definitely better than B, because the result of B is a spaghetti of a functional (e.g. a new feature or a bugfix) and non-functional (e.g. whitespace cleanup) changes. Mixing apples and oranges is a bad thing to do: it makes patch review harder, it makes porting between branches harder, and in case you'll want to revert the patch (say because of a bug in new code) you will also revert those cleanups (which are not buggy). So, if you are not a perfectionist, better follow way A but please not B.

Unfortunately I just can't ignore the bad things I see, so I follow the way C. Sometimes this is very annoying, because instead of implementing a new feature you keep refactoring your code for hours, sometimes even days. No, it's not only whitespace cleanups or fixing typos in comments. Sometimes you see that there are a few identical snippets of code and you put that code into a new function. Sometimes you notice that some function arguments are unused (or always the same) and you remove those. Sometimes you just read the code and see there is a bug in it, and you fix it. Oh, the text of error message is not clear enough — you fix it. The typesetting of a man page is wrong (e.g. bold is used instead of italic for variable argument) — you fix it. You see that a function is not used outside of the source file — you make it static and remove its prototype from a header file. You notice a typo in the function name (and of course also in every place that calls it, since otherwise that code won't compile) — you fix it. A typo in a comment — fix it! And so on, and so forth...

Every single thing from the above paragraph (and some more) happened to me when I was working on the boot order priority feature (the subject of OpenVZ bug #1300). So I ended up with 22 (twenty two) code commits, from which 3 implement the actual feature, 1 documents it, and the other 18 are all code refactoring, preparation and minor bugfixing.

The way to perfection is never easy. That doesn't mean we shouldn't try.