Before 'the cloud' was cool: Virtualising the un-virtualisable

Making the virtual indistinguishable from the real

The snag is, for this to be any use, you have to be able to do it invisibly. A VM has to be indistinguishable from a real machine. Unless the fakery is perfect, you cannot run an unmodified OS under it.

VMware's clever innovation was to find a way round this, by faking the functionality in software. The technique is related to the way that emulation of old computers makes it possible to, say, run an Amiga game on your PC. Emulators like WinUAE are a bit like reading a book in a language you don't speak by looking up every single word in a dictionary.

It works, and with a good enough dictionary, you can understand it – this is how online translators like Google Translate work. It's no substitute for understanding the language natively, though. When a computer runs an emulator, every single instruction of the emulated program is looked up and translated. The program runs, but slowly – tens of times more slowly than native code that doesn't need to be translated.

What VMware did was find a way to examine executing PC code, isolate out the bits that run in ring 0 and run them and only them through an x86 emulator. Code in lower rings runs natively.

Oddly enough, it's possible to write a very efficient x86 emulator for the x86, as the chip is a very close architectural match to itself. Thus, x86-on-x86 emulation is much faster than, say, the inefficient process of emulating an Amiga's Motorola 68000 on an x86 chip, which only works because modern PCs are hundreds of times faster than mid-1980s computers.

Yes We Can

Like PowerQuest's PartitionMagic, once one company proved it could do something previously thought impossible, others realised that they could do it, too. For years, Connectix sold a Mac program called VirtualPC: a complete PC emulator for MacOS. VirtualPC let you run Windows – or any other PC OS – in a window on your non-x86-compatible PowerPC-based Mac. It worked, but it was slow.

After VMware, though, Connectix produced a PC version, aping VMware's separation of safe and unsafe code. Once you work out how to do it quickly, a PC emulator for the PC can be handy for all sorts of reasons – testing out new OSs, deploying "the right one for the job" even when you've got lots of jobs to do and there's no single "right" or "best" choice. For instance, running Windows on an Intel Mac under Mac OS X – or on a Linux PC.

This product is why Microsoft bought Connectix and it's the core technology behind "Windows XP Mode" on Windows 7 and Hyper-V on Windows Server.

The closest you could do on x86 without the software-emulation "cheat" was paravirtualisation, as done by the open-source Xen hypervisor. If the hardware doesn't have facilities to trap unsafe instructions, then you just trap what you can and modify the guest OSs not to use unsafe instructions. This is fine for open source OSs like Linux and the BSDs, but no use for commercial off-the-shelf stuff unless its makers cooperate with you and do special versions.

Once PC virtualisation took off, in 2005 the big x86 processor makers belatedly noticed which way the wind was blowing and added special instructions for hypervisors to their CPUs, creating a ring below ring 0: "ring minus-one."

This powers Linux's KVM, and Xen added support for it too, allowing Xen to run Windows in a VM – so long as you have a VT-capable processor. Sadly, VT is one of the features disabled in a lot of budget models of CPU. VMware still eschews it, feeling that its software virtualisation engine is more efficient.

Now, virtualisation is everywhere. There's a wide choice of hypervisors for the x86. Parallels offers commercial ones, VMware offers both freeware and commercial options, and Microsoft gives away a range of them. For Linux, Xen and KVM offer a choice of free open-source hypervisor modules.

The thing is that they all do the same thing: split a system up into multiple independent subsystems, each of which can run its own complete OS – what's called "full-system virtualisation". This is not the only way to do it, and on more mature virtualisation platforms, it is a relatively rare method, because it is rife with inefficiencies and weaknesses – but if you know nothing else, they are hard to spot.

The problems only become apparent when you compare the way virtualisation is done on the PC with the ways that other systems perform it. ®

In the next part of this series, we'll look at the invention of virtualisation – 40 years ago, on IBM mainframes.