Next-gen virtualization from Microsoft

It’s been a rough week for virtualization beta testing, at least for me. Last week, I took a look at a late beta of VMware’s VI3 update (with ESX Server 3.5 and VirtualCenter 2.5), and was impressed overall, but found more than a few bugs and saw more than my share of host crashes. This week, I looked at Microsoft’s next-generation hypervisor, dubbed Hyper-V, which will be released as a component of Windows Server 2008. Hyper-V is a whole new virtualization platform for Microsoft, going beyond Virtual Server and adding new management features, expanded snapshot support, and hopefully better performance. After my brief look at the beta release, I can confirm that this is truly beta, and it has a long way to go to be production-ready.

[ See also: Preview: VMware Infrastructure 3 update builds on the base" ]

The basis of Hyper-V is the new Windows Server 2008 platform that carries with it a host of new features and a vaguely Vista-esque look and feel. Love it or hate it, Vista-ness is apparently here to stay. Installation of Hyper-V on Windows Server 2008 is as straightforward as you would think, requiring only that an admin add the Hyper-V role to the server and designate which network interfaces to use for virtual machines. After installation, the server reboots and Hyper-V is ready for action.

I installed the beta on a solid, middle-of-the-road server, a Dell PowerEdge 2950 with two dual-core 3GHz Intel CPUs, 4GB of RAM, and a single 72GB U320 SCSI drive. I had newer and more powerful hardware in the lab, but I wanted to run the beta on hardware that was virtually guaranteed to have built-in driver support. I wasn’t disappointed -- everything worked right out of the box. From there, I had the system ready to handle virtual machines in a matter of minutes. A few minutes later, I ran into problems.

Disk Manager lockup drill
I first created a Windows Server 2003 VM by running through the simple wizard. Aside from the fact that Hyper-V wanted to create a 127GB virtual disk on a fictitious 2TB file store instead of the actual 70GB local disk, the process was quick and easy. Then I tried to boot the VM from an ISO located on a network share, much like I’ve done for countless VMware installations. Unfortunately, although my user account had rights to the share, Hyper-V requires the system account to have read/write access to the share to read the ISO image. Rather than reconfigure network sharing security preferences, I copied the ISO to the local system and proceeded to install the new VM that way. While the Windows VM setup was running, I built another VM to run Linux, and configured it for PXE boot, again like I’ve done on many, many VMware installations. The VM successfully PXE booted and the installation proceeded normally.