From Zero to Virtualization: Linux-Vserver vs. OpenVZ

We’re currently evaluating solutions for virtualizing GNU/Linux servers at the HGKZ in order to replace seriously aging hardware (700 MHz P3’s!). At the same time, we can be hip like you and use important-sounding words such as “machine consolidation”, “hypervisor” and “cuttlefish”.

Gino is evaluating OpenVZ while I’m looking at Linux-Vserver. Both solutions have a similar approach: Don’t create virtual machines. Instead, create virtual servers that are sealed away from each other, but running on the same kernel. This has its own set of advantages and disadvantages, but I won’t go into that, you can read about it elsewhere.

Here’s a handy comparison table of what we found out so far:

Linux-Vserver OpenVZ
Kernel Pre-patched kernel included with Debian Need to patch your own or rely on outside sources for binaries
Networking Networking for guests works out of the box Needs IP forwarding on the host, custom network config on the guest
Developers Funny Austrians Creepy Russians
Documentation Horrible mess in six different states of rebuild and decay Well-structured, organized and maintained
Affiliation Snuggles a bit with RPM-based systems sometimes Spends entire weekends in RPM-based systems’ beds and refuses to leave come Monday
Debian Is treated like a leper, but a very friendly one Is the enemy
Guest configuration Implicit but convoluted Explicit but straightforward

There, that’s hard scientific facts for you.

After all of this probing, compiling, tickling, testing and general mayhem, we have decided to go with OpenVZ. To reach that decision, we of course evaluated both solutions on many levels (don’t let that table fool you). There are clear philosophical and architectural differences between the two solutions, but one key factor in our decision was that for the administrator, both systems are almost too similar.

Yes, OpenVZ takes a more complicated approach to networking, but Linux-Vserver takes a more complicated approach to configuration. Yes, a Linux-Vserver host’s default config is mostly what you want and just seems to work out of the box, but this lowers your motivation for learning the details of the resource management system. And details, as you surely know, are nearly always ugly.

With OpenVZ, you are forced to learn these things up front, which presents a steeper learning curve but gifts you with a more solid grasp of the technology. You get to flex your math muscle to fit virtual servers into your actual hardware’s limitations without creating an impossible physical paradoxon that rips a hole into space-time, and that’s quite handy. With Linux-Vserver, these things might come back to haunt you later, when you’re trying to put vserver no. 22 onto your machine and discover your 16 GB of memory are already spent, and that’s when details bite a tasty chunk right out of your lower backside. The decrepit state of Linux-Vserver’s documentation does nothing to ease your fears in this department. Convoluted configuration would otherwise be okay, as long as it’s well-documented convoluted configuration.

Now what if we are wrong, and within the next 8 months someone writes The Linux-Vserver Bible (Illustrated Swimsuit Edition) and SWSoft decides to pull the plug on support for OpenVZ, leaving us without any burly Russian engineers to take care of the code? That may seem sad, but it paves the way for such a beautiful pink-colored fluffy thought that it nearly makes my skull burst: We would still be fine. Both of the solutions are open. No proprietary formats. No secrets. We can migrate from one to the other at any time.

Dell Germany Refunds Vista/Works Price to Swiss Customer

Hurrah! “mad” from TheAlternative.ch created a fantastic precedent for us silly Swiss people: He sent one e-mail to Dell and immediately got a refund for both the unwanted Vista and the copy of MS Works included with his new laptop. He saved 15% on the laptop’s price this way, as well as getting rid of software he doesn’t use. Read his story in English or German.

How to get a refund for the unused copy of Windows that is chained to your new laptop

Serge Wroclawski tells us how to get the Windows tax back that you pay with almost any laptop on the market, whether you want Windows or not. I’m not sure if this strategy only works for the USA, though.

I have a few personal experiences with this problem. I have tried several times to get my money back for unused Windows licenses, and every time I was told it’s impossible. One afternoon, I insisted enough to be put through to Microsoft Switzerland’s licensing person, and he himself told me it’s impossible to get your money back, even though Windows’ very own license agreement says you will get cash back if you don’t need Windows. It’s a horrible situation. They sell you a product you don’t need and then trap you in legalese when you want to exercise your right of returning it for a refund.

Sometimes they claim they don’t even need to stick to their own license because of “differing contractual obligations between Microsoft and the OEM.” But so what? Any ties between OEM and Microsoft are not the customer’s problem. The customer is only bound by the EULA, not by any contracts between MS and the OEM. Did the OEM let itself be bullied by MS’ scare tactics like a spineless jellyfish? So what, that’s not my problem.

A friend of mine and I once spoke to one of the largest IBM resellers in the germanophone part of Europe about this. Their answer? “No, you can’t return your copies of Windows, but if you buy more than 50 laptops we can downgrade the XP Pro that’s included to a cheaper XP Home.” Friendly, but completely useless and against your very own license agreement.

This makes me angry because it’s very clearly in illegal territory, and it’s one of the ways Microsoft makes much of its money. And even though it is illegal, it is tolerated because no one has so far challenged Microsoft in court about it (in Switzerland).

Article is at linux.com, found via Slashdot.

PS: “Just don’t buy a laptop with Windows preinstalled” is not an argument, by the way. Most laptops are not available without Windows. Consumers should not be restricted in their choice of laptops by the Microsoft tax.

Some brainlessness in rsnapshot

I love rsnapshot, for the most part. It’s one of the most efficient and straightforward incremental backup solutions I’ve ever used — much more reliable than some of the commercial solutions I’ve tried. It leverages the power of GNU cp, your filesystem, rsync and others and smashes them all together into a big happy chunk of reliability.

However, it must contain some idiocy, and I guess it’s somewhere in parse_config_file. I just set up another server, the same way I usually do, but it needed a slightly different rsnapshot.conf. So I edited the one that was there and known to work because it automatically comes off my server images. Afterwards I wanted to do a test run of each of the backup intervals, because that’s what you do. But rsnapshot didn’t agree. It didn’t disagree either. It didn’t do *anything*.

The next step was to increase its logging verbosity and look for hints in syslog. Interesting: It seems to read its config file successfully and it even writes a pid file. Next, it checks for stale backup directories it might have to rotate. That means it parsed its config file and is happy, no? No! The thing wouldn’t copy anything into the backup. Not a single file!

As a last resort, I straced one of those test runs but forgot to include the tracing of child processes. That probably would have given me more of a clue — the way it was, it just added to my confusion.

In the end I decided to unpack a fresh, distribution-approved config file from /usr/share/doc/rsnapshot/examples and to make the required changes by hand. I retested while already preparing to submit a bug report, when… It worked! The thing performed all the backups reliably, packed up and went to sleep until cron wakes it up tomorrow.

There must have been **some** character **some**where in my config file that deeply confused rsnapshot, confused it so much that it claimed the config file syntax was OK but silently refused to work.

Perhaps config file parsing in rsnapshot has to be rethought. The way I see it, this is sad indeed. It’s the least reliable bit in an otherwise very reliable package, but it’s always the weakest link that breaks the chain, and other assorted age-worn sayings.