From Out There

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:

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, either. Convoluted configuration is 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.

It’s the beauty of Free Software once again.

WINE is an implementation of the Win32 API on Linux, so that you can run programs written for Windows on your GNU/Linux installation. It normally reeks of office applications, spreadsheets and polka-dotted ties. Cedega, then, is a commercial version of WINE optimized for games. It runs a larger library of Windows games than plain WINE can. So far, so good, right? Now, common sense might dictate that the games should run slower in WINE or Cedega, because those things are busy translating the Windows-nonsense the games speak into something that GNU/Linux can understand, and that surely costs performance, no?

Common sense is wrong. These benchmarks say that GNU/Linux with Cedega or WINE runs the tested games 33 – 40% faster than Windows Vista. 40%! That’s not just the fraction of fps that the hardcore crowd lusts for, that’s a significant number.

So the best modern platform to play Windows games on is not Windows but GNU/Linux? Creepy.