If you’re looking to virtualize a server of your own or to pick up a VPS, you’ll probably be picking between these two staples of the virtualized world.  Each technology has its pros and cons, and your decision may change based on your needs as a sysadmin or a user (Spoilers: We chose OpenVZ).  Xen and OpenVZ differ in how they virtualize servers, manage memory, and more!  I’ll try to give a little more in-depth analysis of the differences to help you decide which method is right for you.

The first big difference comes right down to fundamental design goals.  They are different down to the core!  Neither system is full virtualization (virtualized bios, hardware, os, everything). Xen is a hypervisor (or paravirtualization), OpenVZ is container (or OS level) virtualization.  The simple explanation is that a Xen hypervisor runs an OS that knows it’s being virtualized.  Each user is seperated and running their own OS/system, all on top of the master virtual controller (or Hypervisor).  OpenVZ uses the same underlying OS for each of the users.  The containers are all isolated and separated from each other, but using the same underlying OS.  It creates a kind of OS level ‘jail’.  If you’re unfamiliar with these concepts, don’t worry, it’s not as bad as it sounds!

This intro is getting wordy.  Time to break out some headers!

Virtualization (The Underbelly):

Xen’s hypervisor basically sits over the hardware, and acts like a hardware virtual manager.  The ‘guest systems’ that run on the hypervisor know they’re on a virtualized system, but are still able to function as wholly separate entities.  This means you can run just about any OS or setup regardless of what the base level system is running.  This lets you do fun stuff like running a Windows VM on a Linux box, or run a different kernel in each guest.

OpenVZ containers don’t try to virtualize the hardware.  Instead, it uses a special kernel to isolate processes and resources.   Every guest runs on top of the same identical system, but they are fully separated from each other (still have their own filesystems/processes).  Everyone has the same kernel, and you can’t run different OS types on the same machine (can’t support both Linux and Windows VMs).

From this limited information, Xen is clearly more versatile.  But wait, I don’t use Xen.  ‘Why not?’, you ask in a haughty voice.   I’m getting to it.

Overhead (Isolation vs Ease of Use):

To keep things simple (and relevant), I’ll just be talking about 64-bit systems.  Xen does some pretty complicated stuff to make sure x86 architecture works just the way they wanted it to, and it’s impressive enough, but it adds more overhead to the process.  Not wanting to hold that against them, I’ll keep my discussions relevant to x86_64!  Oh, you only care about 64-bit architecture?  Good on you, mate!

Here personal preference is king.  Xen is much more virtualized, which comes with some nice pros to its cons.   It isolates its resources for you (more on this later).  This also allows custom/different kernels, since each guest is basically a wholly different environment.

But there is a cost in doing all of this.  Xen uses significantly more resources in overhead to create/maintain seperate instances for each VM.  OS level virtualization means many basic components exist once on the machine, and are used by all guests (like the identical kernel).  OpenVZ also uses one filesystem with chrooted environments, instead of fully separated Xen file systems.

If you’ll need a system with a custom kernel or want to load kernel modules,  stop reading now.  That decision pretty much makes itself, you’re a Xen fanboy now.  Get your hat on your way out of the lecture.

But with a single kernel, and a more manageable file system making backup/recovery easier, I find OpenVZ more manageable as a sysadmin.

Memory Management (The Gamble):

Here is the real meat and potatoes of this debate.  Xen’s dedicated memory and swap space, versus OpenVZ’s density and burstable memory.

It comes down to Xen’s swap space use versus OpenVZ killing processes.

With Xen’s isolation, you get your own section of memory.  It is quartered off for you, and nobody else has write privileges to it.  If you max out your memory, it’ll dump over into swap space so nothing crashes.  The problem on a shared server is that even though disk filesystems and swap spaces are isolated, disk I/O is not.  When people start bursting into swap space, it can cause the exact problem that Xen was intended to isolate around; bad VMs affecting the performance of other VMs.  Sure, your Apache will keep on kicking, but it’s going to run terribly, and may cause problems for the rest of the machine.

With OpenVZ, you are given a guaranteed amount of memory.  Since it’s not fully isolated, it’s a part of shared memory on the server.  Everyone has their guaranteed memory in the same pool.  There’s also (typically) burstable memory.  If memory isn’t being utilized, others who need it for a short time can burst up into extra memory.  If guaranteed memory is required somewhere else, this optional burst memory will fail away, and the memory will be allocated to fill a guaranteed quota.  But if you suddenly have no memory where memory once was, things die.  The problem is, they sometimes don’t die nicely.   No swap space with OpenVZ, so things die, and you don’t get a lot of control over what dies.

So we have a stability versus performance issue!  Or do we….

Conclusions (tl;dr):

I like OpenVZ.  I like the low overhead on containers and the performance is great.  The problem with OpenVZ is over-allocating memory.  You may notice on our VPS plan descriptions that we don’t talk about burstable memory.  That’s because we don’t allocate burstable memory.  We take a stability approach to our VPS.  OpenVZ won’t allocate memory it doesn’t have.  It’ll throw an error and stop new processes from spawning, but you will know about the problem before it accidently kills off Apache or MySQL.  It won’t bring down the whole house of cards, nor will it put the burden on everyone.

As an admin, I like using OpenVZ for it’s natural performance benefits, and managing memory with a more Xen approach.  It’s served me, and our customers, very well.

As a user, I suggest two good options.

• Use Xen because you need it (custom kernel, different OS, etc)
• Find an OpenVZ vendor who doesn’t oversell their resources (I suggest The Linux Fix!)