Ready or Not, VMware, Here Comes Hyper-V

With its June 26 release of Hyper-V, Microsoft presented x86 server virtualization leader VMware with what may prove its toughest challenge to date.

That's because while Hyper-V trails VMware's ESX Server in core features, management options and guest operating system support, Microsoft's new virtualization offering boasts a pair of significant—and familiar—advantages.

Hyper-V is bundled with Windows Server 2008, and carries no additional charge. Microsoft will, however, sell you a version of Server 2008 sans Hyper-V. The estimated MSRP of Windows Server 2008 Standard is $999. The same server without Hyper-V is $971.

At the very least, the entrance of Microsoft and Hyper-V into a market in which Xen-based offerings are already giving VMware a run for its money means that the days of VMware as the "no-brainer" option for server consolidation and similar virtualization-based tasks are over.

Based on eWEEK Labs' tests, Hyper-V is worthy of consideration as a virtualization option at sites of all sizes, and particularly those already running or planning on upgrading to Windows Server 2008. Hyper-V does require server hardware powered by x86-64 processors with hardware virtualization extensions, so companies that wish to use older x86 hardware as hosts for virtualization must stick with ESX Server, or opt for Microsoft's lower-performance Virtual Server product.

This first version of Hyper-V, which eWEEK Labs previously tested in beta form, currently lacks some of the scalability offered by VMware's ESX Server. For instance, Quick Migration, where a virtual machine is moved from one physical host to another, is nowhere near as sophisticated—nor as quick—as the analogous function in VMware.

However, based on Microsoft's track record for overcoming scalability issues, as in Exchange Server and Active Directory, I expect that Microsoft will manage to make up scalability ground as it revs through subsequent Hyper-V versions.

Less clear is whether Microsoft will close the gap between Hyper-V and ESX Server in the breadth of guests that Hyper-V hosts effectively. As matters now stand, Microsoft's support for operating systems beyond Windows is characteristically poor. While pretty much any x86-based operating system will run under Hyper-V, the so-called "enlightened" drivers required for full performance are available for most Windows versions and for Novell's SUSE Linux Enterprise Server.

Hyper-V in the lab

I installed Windows Server 2008 with Hyper-V on an HP ProLiant ML115 server with an AMD Athlon dual-core 4450 B processor. The server was equipped with 4GB of RAM and a single 1GB NIC (network interface card). Hyper-V is treated in Windows Server 2008 as a server role, but since the version of Hyper-V that shipped with Server 2008 RTM was a beta, I had to download the updated Hyper-V code from Microsoft's Web site.

I set about creating some virtual machines by firing up Microsoft's Hyper-V Manager, with which I built four virtual machines: VM One ran Windows Server 2003 with service pack 1; Two and Three were W2K3SP2 (Windows Server 2003 with Service Pack 2) and VM Four was Novell's SUSE Linux Enterprise Server 10 with SP2.

I also tried my hand at importing a few VMs that I'd created, but the fact that I'd built those VMs using the beta version of Hyper-V frustrated those import efforts.

As with VMware's ESX server, the first order of business after installing a guest operating system is installing helper files to optimize guest performance in the hypervisor environment. In the case of Hyper-V, Microsoft currently supplies helper utilities called "integration services" (sometimes referred to as "integration components") for a limited range of guest operating systems. I was able to use the virtual integration services setup disk on my W2K3SP2 virtual machines but was met with an "unsupported operating system" error message when I attempted the same thing on my Windows Server 2003 SP1 machine.

Hyper-V's management interface made it easy to adjust the attributes of my VMs, including their assigned memory, processor type, IDE controller type, network adapters and other hardware components. I also used the interface to change the VM name, install integration services, and change the snapshot file locations.

The Hyper-V Manager is quite simple to use and IT managers should have little trouble training staff to use the system to create and maintain VMs. The system provided me with useful error messages when I attempted illegal actions. For example, I directed two VMs to use the DVD drive at the same time. It was easy to manually remediate the problem, although I'd like to see Microsoft automate remediation of device contention so that the Hyper-V Manager handles physical device delegation based on requests without manual configuration changes.

I found virtual networking simple to set up and easy to use in Hyper-V. There are only three kinds of networks that can be created: external, internal and private. I used external networks to enable my VMs to access the Internet and internal networks so that the VMs could provide services on my local network. Private networks are used to isolate traffic to VMs installed on a physical host. I didn't try this type of network, but for workloads that must be securely contained from the rest of the network it's a handy feature.

As in VMware's management environment, I was able to accomplish certain configuration tasks while my VMs were turned on and running, such as installing integration services. Other actions, such as modifying my network hardware, required that I shut down my VMs.

The Hyper-V Manager sits at the core of a larger management portfolio that includes the optional SCVMM (System Center Virtual Machine Manager) 2007, which is suitable for controlling larger Hyper-V deployments. I'm looking forward to the release of SCVMM 2008, which will add support for managing non-Microsoft hypervisors as well, and should enable Microsoft shops to work around the guest limitations of Hyper-V by bringing more cosmopolitan hypervisors into the mix.

During my tests, I was able to abuse one test server while other virtual machines on the same physical host quietly processed away on their workloads. My VMs ran with very little contention and did not interfere with each other. In subsequent tests I'll be stressing CPU, disk and network I/O more rigorously to see how Hyper-V handles the load.

Hyper-V, in conjunction with Windows Server 2008, provides for failover clustering. The clusters can use SAS (serial-attached SCSI) or Fibre Channel to network the clustered servers and mass storage devices. There are several limitations on setting up failover clusters that have more to do with the underlying Windows OS than Hyper-V. IT managers should carefully consider these factors, such as the use of identical NICs and no parallel iSCSI, when making a decision about using Hyper-V to construct a failover compute cluster.

eWEEK Labs Technical Director Cameron Sturdevant can be reached at csturdevant@eweek.com, or through his blog, here.