Xen Part 2: Hardware Requirements for Xen

You've selected Xen as your hypervisor - so far so good. But before we get ahead of ourselves, let's take a moment to understand what will be required for this to function. Can you run Xen on the hardware you already have? If not, how much would it cost?

Again, it comes down to your requirements. There are a couple of considerations:

1. Which Operating Systems will you be installing as guests?
2. What will you want to do with them? (For most people, read: do you want to play 3D games?)

I'll address these points in turn.

1) Guest Operating Systems

You don't need special hardware to install Xen on Linux and then add some Linux virtual machines on top. But if you want to run a Windows VM too, then I'm afraid you do need special hardware. To understand why, you'll need to understand one of the fundamentals of OS virtualisation: Paravirtualisation and Full Virtualisation. Let me briefly explain (or skip to the section titled "Xen" if you want to jump to the chase).

Full Virtualisation

To run a guest operating system, Xen can take one of two paths. It can try to "emulate" normal computer hardware, such that the guest operating system is completely unaware that it's being run on a virtual machine. So, Xen can present the guest OS with a fake processor (let's call it MyVirtualIntelCPU, and let's tell the guest it has 100MB of L2 cache for kicks!), and a fake hard disk (let's call it XenDisk), etc. 

Since Xen handles all the interaction with the guest, it can present whatever fake interface it likes, and so long as the guest sees it as compatible hardware, it'll be okay. The problem is, since we're emulating hardware in software, this is slow. Very slow. 

What I've described is known as Full Virtualisation. You'll typically see the acronym HVM, which stands for Hardware Virtual Machine.

Paravirtualisation

Thankfully, there is another option. Imagine if the guest OS knew it was running on a hypervisor. The hypervisor and guest OS could agree on a set of parameters each should operate within, and then the guest OS could be free, to some extent, to run by itself - without the need to run everything through the hypervisor, with fake emulated hardware. Obviously, things are rather more complex, but in simple terms, paravirtualisation (you'll often see the acronym PV) allows the guest OS to run without all the emulation that HVMs require. Properly configured, PV can be pretty close to native speed. 

At the heart of PV is the concept of a "hypercall", which is a way for the guest OS to communicate with the hypervisor. This presents an obvious gotcha: the guest OS needs to have virtualisation support built-in.

Xen

Xen supports both PV and Full Virtualisation (you don't often see the acronym "FV"). When it's possible run a guest OS with paravirtualisation, you'll typically want to do so. The following operating systems support paravirt-ops, which is the standard for paravirtualisation, originally created by Xen:

• All Linux distributions (with kernel version >= 2.6.23)
• FreeBSD
• NetBSD
• OpenSolaris (now OpenIndiana)

Some others might too - let me know of any I've missed - but typically speaking, if it isn't on the list, it isn't going to run in Paravirtualised mode, in which case you'll need to run it as a HVM, and this is where the hardware requirement comes in.

Hardware Requirement

To run OSs with Full Virtualisation (HVM), you'll need a CPU which supports either:

• AMD-V
• Intel VT-x

To see if your processor has the necessary support, I advise you check the processor's data sheet on the manufacturer's website. These days, most new CPUs I've seen support hardware virtualisation, but you will still need to check. For more information on processor virtualisation, read the Wikipedia article. 

So, the bottom line is that to run Windows (and some others) as a guest OS, you need your CPU to support VT-x for Intel or AMD-V for AMD.

2) Gaming and other special requirements

This mainly applies to HVM guests again, so we're primarily talking about Windows here.

If you want to have a Windows guest (HVM) to play 3D games, this adds an extra layer of complexity. Modern games are highly computationally demanding, and place a lot of strain on graphics cards. The emulated Cirrus card provided by QEMU isn't going to begin to cut the mustard. You're going to need to "pass through" your graphics card hardware to the guest OS.

In other words, instead of showing Windows a (virtual) antiquated graphics card from the Paleolithic era, you need to give your Windows guest access to a real graphics card - that ATi HD6850 sitting in your box, or whatever it happens to be. You need for the host OS to ignore it, and the guest OS to use it. This case is a subset of PCI Passthrough, dubbed VGA Passthrough.

There are other cases when you'll need similar support - if you want to expose a special piece of hardware to your HVM guest, such as a particular network card or sound card, you will have to use PCI Passthrough.

Hardware Requirement

To get this working on a HVM guest such as Windows, you're going to need support for either:

• AMD-Vi
• Intel VT-d

These are processor extensions for Directed I/O - in other words, routing devices to particular guests. You will need to check your processor data sheet to ensure that it supports one of these extensions. These are much less widely supported than basic Vt-x/AMD-V virtualisation, so don't assume that your CPU will have it, even if it's a high end CPU. For example, Intel's Sandy Bridge i7 2600 supports VT-d, whilst the i7 2600k (the slightly more expensive, unlocked version) doesn't support VT-d. Be careful.

Unfortunately, it isn't quite that simple. For VT-d to work, you also need your motherboard to support it too, and this seems to be a bit of a minefield. I hope that by the time you read this, motherboard support for VT-d will have improved substantially. Make sure you buy a motherboard which has been recommended as VT-d (or AMD-Vi) capable, and if you can, verify that it has an option to enable VT-d in the BIOS. 

I would advise going further, given that some which claim to support VT-d have turned out to require additional hacks (or worse) to get it working. For the wary, I suggest picking a motherboard which has already been tested by the community and verified as working with VT-d. Xen has a list of compatible motherboards. Additionally, Paul Braren has a short list of motherboards that he has kindly taken the time and effort to verify.

For those who are interested, I picked a motherboard on Paul's list - the ASRock Z68 Extreme4 Gen3 - and coupled it with an i7 2600. Based on my testing so far, I seem to be able to configure a graphics card passthrough successfully with this combination. 

3) Other Considerations

Okay, I know I didn't have a point 3 in my original list, but this is just a general piece of advice which shouldn't need stating. With a hypervisor, you're going to be running multiple operating systems simultaneously. You have a host OS, and at least one guest OS (or else, why bother?)

Given this, you'd be well advised to base the system on some reasonably powerful hardware, crucially with a sufficient quantity of RAM. If you plan to run 3 guest OSs and have 4GB of RAM, you're going to be very restricted in terms of what you can run on each guest. Let's say you allocated 1GB of RAM to each OS - the host, and the three guests. 1GB only just meets the minimum recommended requirements for Ubuntu desktop edition. Things would get sluggish awfully quickly.

You're well advised to kit out your box with plenty of RAM - upwards of 8GB would be preferable.

Next > Part 3: Installing the Host OS