If you read my September column, you know that I've been doing a fair amount of experimenting with Windows Server 2008's new Hyper-V Server virtualization tool. (Mention that you're playing with Hyper-V and notice that everyone around you pricks up their ears.) When talking to clients about Hyper-V, I'm often surprised to find that although folks know some of the product's basics—it requires a virtualization-friendly 64-bit chip (as I discussed in September), it's essentially a free competitor to industry big dog VMware ESX, and it doesn't yet include an analogous tool to VMware's indispensable VMotion tool (but will when Server 2008 R2 arrives)—they typically stare at me blankly when I mention the importance of "enlightened" virtual machines (VMs). So, here are a few words on what might be the single most important thing to understand about getting the most out of Hyper-V.
In the past ten years, several vendors have successfully tackled the large job of writing virtual machine manager (VMM) software such as VMware ESX and Microsoft's Virtual Server. Those two tools are different in many ways, but they share one important similarity: They're masters in the art of deceiving software. What I mean is that when you install an OS such as Windows 2000 or Windows 98 on a VM created under ESX or Virtual Server, that OS has no idea whatsoever that it's not running on real hardware. The VMware and Microsoft folks had to be excellent at hardware mimicry because, if they hadn't, those OSs—and many others—would never have successfully run on those VMMs.
However, while VMware and Microsoft toiled at top-notch hardware simulation, some other smart folks were working on a different approach to VMM design. The designers of Xensource—an open-source VMM project eventually acquired by Citrix—included a number of developers active in the Linux design world, and those designers attacked the hardware simulation/compatibility problem by basically saying, "Why raise the bridge when you can lower the river?" Because they had access to Linux source code, they decided that rather than making the VMM OS-friendly, they'd just modify the OS to make it VMM-friendly. Quirky as it sounds, this approach worked well for Xensource and probably has a lot to do with why Citrix acquired it.
What does this have to do with Hyper-V? Simple: Hyper-V's designers looked at Xensource and liked what they saw. Therefore, Hyper-V is a sort of hybrid VMM, acting a bit like ESX/Virtual Server and a bit like Xensource. If you install just about any kind of relatively modern OS on Hyper-V, then Hyper-V will do a good job of making that OS believe it's sitting atop actual hardware, and you can use that VM to get a job done. But for some OSs, that's not the end of the story.
If you take the time to modify your VMs' OSs a bit, you'll find that they run faster and offer a wider array of management tools under Hyper-V. You can perform that modification by installing Installation Services on the VM. (In the VM's window menu, click Action, then Insert Integration Services Setup Disk, and follow the onscreen prompts. By the way, you needn't look for an actual physical disk to insert. The command actually connects the VM to an ISO of the disk, sort of like adding VMware Tools to a VMware VM or Virtual Server Additions to a Virtual Server 2005 VM.)
Now, installing Integration Services is similar to adding VMware Tools or Virtual Server Additions, but it does a lot more, modifying the OS's kernel and adding new virtual devices that speed VM-to-hardware communication. Such modified OSs are called "enlightened" OSs (as in Zen enlightenment, get it?). The upside to enlightenment is that you get better VM performance, but there's a downside: Microsoft offers enlightenment software for only four Windows versions: Server 2008 RTM/SP1, Windows Vista SP1, Windows 2003 SP2, and Windows XP SP3. (I'm told that there's also code to enlighten SuSE Linux Enterprise Server 10 SP1, but I haven't had time to try it out.) It troubled me, then, to read about a set of benchmarks that purported to show that Hyper-V was quite a bit slower than ESX. What troubled me wasn't the conclusion that Hyper-V is slower than ESX, but rather the fact that, as far as I can see, the testers never bothered to enlighten the VMs that they were using for their benchmarks. (As a wise man once paraphrased, "There are three kinds of lies: lies, damned lies, and benchmarks.")
The bottom line? Enlighten your OSs, grasshopper, and software satori may follow. Happy holidays, everyone—see you next year!