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