We're currently evaluating solutions for virtualizing GNU/Linux servers at the HGKZ. 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:
[... comparison table omitted, doesn't quite make sense to me ...]
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.
documented on: 13 April 2007, rca