Virtualisation is the buzzword of the moment, but us Linux users have been doing it for years now, using VMware and QEMU to run Windows in a box on their desktop. Being able to run multiple operating systems on a desktop can be great for productivity, but it's in the server space that it's set to change the way we run our services.
Sysadmins have been replacing proprietary big-iron with commodity Linux systems for many years, but 64-bit computing, dual-core CPUs, and AMD's Direct Connect Architecture have boosted commodity hardware to the point where many systems are more powerful than they really need to be. Consolidating multiple virtual servers on to the one physical system makes better use of your existing resources, saving on hardware costs.
With all of your servers running virtualised, a new range of management possibilities opens up. New servers can be commissioned immediately, with no up-front hardware purchase, or at worst just the incremental costs of adding disks or RAM to your existing server. Once your physical server is finally pushed to full utilisation, you can just commission another and shift some of the virtual systems over to it.
This reduces the cost of new servers dramatically, and you can use existing ones for all sorts of purposes that you'd never thought of before. For web hosting, for instance, virtual hosts that would have been placed into separate directories under a single Apache install could instead be placed into completely separate virtual systems, which can be administered and modified individually. Not only does this isolate each server from potential failures in others, but it also eliminates the possibility of clients updating their website remotely and accessing files outside their own site -- perfect for sites maintained by third parties.
Virtualising x86
All of this sounds great in theory, but at the end of the day, someone has to write the software to make it happen. Unfortunately, the x86 architecture that underlies the vast majority of our systems is a bit of a hack job, with legacy support for features introduced nearly 30 years ago with the original 8086. Intel and AMD have managed minor miracles to stop the architectural flaws getting in the way of performance, but those flaws do get in the way of some tasks, and virtualisation is one of them.
The problem lies in the several low-level instructions in the x86 instruction set that run outside the processor's ability to isolate their operation. User-space code in a modern OS runs in 32-bit protected mode, which the OS can fully control the execution of, but kernel-level code needs to use those lower-level instructions, and there's no way for software to control their operation.
VMware's innovation was to analyse code and dynamically re-write calls to the forbidden low-level instructions, executing that code in an emulated environment in order to retain complete control of the outcome. QEMU uses a similar approach when using the KQEMU module. It's ostensibly an emulator which dynamically translates blocks of code, but if a block of code is determined to consist only of safe user-mode instructions, it's run directly on the CPU instead of being translated. Kernel-level code safely falls through to the emulator.
All of this analysing and emulation of code comes at a cost of course, and while the x86 virtualisers have done well to minimise that cost, there's only so far they can go. There's an old phrase about dancing bears, which Dan Rutter (one of my favourite tech writers from way back in his Amiga Review days, and now writing for PC Authority's sister mag, Atomic) likes to use that seems fitting: the wonder is not how gracefully it dances, but that it dances at all. If you've used VMware or QEMU you know they work well enough for running the odd Windows app, but for consolidating performance-critical servers, we need to get around these inherent bottlenecks.
One technique is to avoid the problematic instructions altogether. By re-writing critical parts of the OS kernel to know that it's running inside a virtual machine, and to call out to the host system when needed, there's no need for any emulation overhead. This technique is called paravirtualisation, and it's been greatly popularised by an open-source project called Xen. It's fast and robust, making it perfect for server consolidation. The only drawback is that it can't run unmodified operating systems, so Windows is immediately out, and even Linux systems can be tricky to install, since few include Xen-compatible kernels out-of-the-box.
Intel's VT and AMD's Pacifica technologies are finally tackling the problem at the hardware level. These two similar but incompatible extensions both serve the same purpose -- to allow software control of the CPU's code execution down to the very lowest levels. This not only eliminates most of the performance bottlenecks inherent to virtualisation on x86, but it also makes it easier for developers to implement, so we should hopefully see quite a bit of action in the virtualisation marketplace. In fact, the recently-released Xen 3.0 already has support for Intel's VT extension, which allows it to run unmodified operating systems, including Windows, with similar performance to its standard paravirtualisation.