One of the biggest trends moving through the IT industry at the moment is the concept of virtualisation. Running multiple operating systems on a single piece of hardware is seen as a way of reducing costs while at the same time getting better utilisation of your existing hardware. A single server becomes host to multiple platforms which in turn perform multiple tasks. You might, for example, run a database server on the same hardware you run your mail server on, but while your database might be Oracle running on Solaris, your mail could be Zimbra running on RHEL.

Virtualisation isn’t entirely new. The big box companies have had similar technology for quite a while. It was not uncommon to take a p-Series system running AIX and run multiple “partitions” so that resources could be spread around a little. Each partition would be independent of the others, but all would be running on top of the same AIX platform. This wasn’t limited to AIX and IBM, but is the first example that springs to mind.

With the introduction of Xen into the Linux kernel, this is made possible for the Linux platforms out there. Xen runs in hypervisor mode inside the kernel of your host platform. The Xen host is called Dom0 and is used to manage and allocate the resources to the other Xen based hosts that run on top in virtual machines. Using para-virtualisation, Xen allows for some pretty impressive performance improvements over technologies like VMWare. A Xen aware guest is actually able to talk directly to the hardware of the host rather than through an abstraction layer as is the case with most other full virtualisation products. There are limitations, but essentially the guest asks the Dom0 host for time with the hardware and then the host gives it that time.

This was a great step forward for Linux based platforms. It essentially gives them the partitioning capabilities of the big box companies and their traditional UNIX based platforms. But this did limit you to only being able to install Xen aware platforms such as Linux, Solaris and so on. What if you wanted to run Windows?

We’ve come to see virtualisation from VMWare as the benchmark of where virtualisation is at this point in time. There are a lot more contenders now than there was only a few years ago. Originally on the Mac we saw VirtualPC making impressive strides on the PowerPC until Microsoft bought them and made them a Windows only product. The new generation of VirtualPC is being incorporated into Windows 2008 and newer platforms as a primary feature. We’ve also seen technology such as Parallels starting to extend its capabilities significantly as well.

We have also seen it come to Linux in the form of HVM using Xen + QEMU technologies to provide a fully virtualised environment, not all that different from VMWare. However, some companies are using VirtualBox or BOCHS or other virtualisation technology to achieve much the same result, but without the Xen Hypervisor. This returns much more to the traditional methods we are used to that were popularised by VMWare and its like. My guess is that this is probably going to be the path more people take in the future.

There are still a lot of unfortunate side effects of using Virtualisation at the moment.

If you do not have a very recent Intel or AMD CPU that runs with the specialised Virtual Technologies extensions, such as the Intel Vanderpool or the AMD Pacifica based chips, then chances are you will need to use Para-virtualisation of the likes of Xen or you will suffer a severe performance hit. If you do have these newer CPUs, you will find that you do not suffer quite the same performance hit on your systems that has traditionally occurred in the past.

Regardless, virtualisation is still going to take its toll on your hardware. The general rule is that you need a minimum of 1 CPU for the host and then a minimum of 1 CPU for each guest. Another general rule is that you need a minimum of 1GB + the OS memory requirements for the host, and then enough memory on top for each OS + the apps they will run. If your Dom0 host is going to be running solely as a Xen hypervisor host, you can get away with only 1GB of RAM set aside for that host. Its not ideal, but it is possible.

For my most recent Xen system build, I am running 16GB of RAM per Blade. Each blade is running 8x 3GHz cores across 2 sockets. Each Blade is running a RHEL Xen Hypervisor and then at least 5 virtual machines on top. The hypervisor gets 1GB to 2GB of RAM (depending on availability) and the 4 or 5 Windows based VMs get 2GB and 1 CPU core each. The remainder goes to the Linux guests that are running a database. Eventually, the Windows VMs will be moved elsewhere and the Linux database hosts will have all 7 spare cores dedicated to them, as well as the remaining 14GB of RAM.

Virtualised hosts absolutely need to be run from an extremely fast, fibre channel SAN. This allows for many advantages, the least of which is live migration, but also helps alleviate the biggest bottleneck you will otherwise have. Hard drives.

Even a RAID1+0 system comprised of dual channel SAS drives at 10K RPM will grind to very slow throughputs when you run more than a couple of disk intensive queries or processes. I learned this the hard way. Trust me, hosting your virtual machines on a SAN will make your life a whole lot easier.

I have barely scratched the surface of virtualisation. In the future I hope to start getting a lot more specific about virtualisation. This includes how it works, what it actually means for your applications and the real advantages of virtualisation. Even beyond the marketing hype about “Total Cost of Ownership.” For now, trust that virtualisation is a good thing and where relevant, it is a most useful technology.