Virtualization Shootout: Hyper-V vs. ESX Server 3.5

Virtualization is steadily making its way into the SQL Server world for use in server consolidation scenarios as well as for development and testing. VMware’s ESX Server 3.5 is the established leader in the server virtualization market. However, Windows Server 2008’s Hyper-V has an architecture that mounts a serious challenge to ESX Server 3.5.

In this article, I compare Hyper-V to ESX Server 3.5. I explore the architectural differences between the two products and compare the products’ overall feature sets. Next, I discuss my management and setup experiences. Then I compare the products’ performance. For Hyper-V, a newcomer to the virtualization market, performance is a real question mark, whereas ESX Server 3.5 has proven that it can deliver enterprise-class performance. Can Hyper-V meet the virtualization standards set by ESX Server 3.5? To find out, I ran basic performance tests on both platforms with some revealing results. All of the testing in this article was performed using the beta version of the Hyper-V code that was shipped with Server 2008.

Thick vs. Thin Hypervisor
ESX Server 3.5 and Hyper-V both utilize hypervisor-based architectures. Hypervisor-based virtualization performs better than older, hosted virtualization technologies. Hosted virtualization products, such as Microsoft Virtual Server 2005 R2, run the virtualization software on top of the host OS, which adds significant overhead and a longer code execution path for the virtual machines (VMs) that run in the hosted virtualization environment. In contrast, hypervisor-based products, such as ESX Server 3.5 and Hyper-V, are designed to run the hypervisor directly on the system hardware. There’s no OS between the hypervisor and the system hardware. Although ESX Server 3.5 and Hyper-V both share a similar hypervisor-based architecture, there are significant differences in the way the products are designed, as you can see in Web Figure 1 (www.sqlmag.com, InstantDoc ID 99218).

One of the biggest differences between ESX Server 3.5’s hypervisor and Hyper-V’s hypervisor is the way they handle device drivers. With ESX Server 3.5, the hardware drivers are part of the hypervisor, which increases the size of the hypervisor and limits the hardware that ESX Server 3.5 can run on. That said, ESX Server 3.5 is supported on most of the server systems made by all the tier-one vendors such as HP, Dell, and IBM. These vendors also sell system configurations with ESX Server 3.5 preloaded. To see a list of ESX Server–compatible systems, go to www.vmware.com/pdf/vi35_systems_guide.pdf.

In contrast, Hyper-V uses a microkernel hypervisor that doesn’t contain any device drives. The hypervisor contains the minimum amount of code required to schedule and share hardware resources between the active VMs. This architecture ensures that the hypervisor has the best possible performance and reduces the potential attack surface of the hypervisor. Hyper-V leverages the native Windows device-driver model utilizing the device drivers in the guest VMs. Hyper-V also includes a new high-performance VM architecture that enables Server 2008, Windows Vista, Winders Server 2003, and Xen-enabled Linux to pass hardware requests along a new memory pipeline called the VMBus.

Both products are managed using the first VM partition. ESX Server 3.5’s VM partition is based on a Linux shell and is command-line oriented. In addition, ESX Server includes an easy-to-use Windows-based management console called the Virtual Infrastructure Client, which can be downloaded from ESX Server 3.5’s Web console. Likewise, Hyper-V is managed using the VM running in the first partition. For Hyper-V, this partition is called the parent partition. Other VMs run in child partitions. Hyper-V’s parent partition is also used to run VMs with legacy OSs, such as Windows 2000 and Windows NT, that can’t utilize Hyper-V’s VMBus architecture and must run using the older hardware model.

Feature Parity
Unlike Virtual Server 2005 R2, Hyper-V’s new architecture and 64-bit host system bring its feature set into parity with ESX Server 3.5. You can see a comparison of the products’ features in Web Table 1.

The primary differences between the products begin with the hypervisor itself. As I said earlier, ESX Server 3.5 includes a hypervisor that contains device drivers. In contrast, Hyper-V includes a hypervisor that contains no device drivers. Both products provide support for 32-bit x86 and 64-bit x64 guest OSs and large VMs with as much as 64GB of RAM per VM. Booting VMs from either an iSCSI or Fibre Channel SAN is also supported by both products. For Hyper-V, the physical host server supports only hardware-based virtualization (e.g., Intel-VT or AMD-V), and virtualization must be enabled in the BIOS.

One area in which ESX Server 3.5 excels is in support for Live Migration (i.e., moving running VMs from one host to another). However, this feature requires VMware’s VirtualCenter, which comes at an additional cost. VirtualCenter is included with the VMware Infrastructure Enterprise product. VMware’s Live Migration capability (called VMotion) also requires a SAN. Hyper-V doesn’t support Live Migration, but when combined with failover clustering Hyper-V does support what Microsoft calls Quick Migration (i.e., saving the state of a running VM and moving that VM to another host where it can be quickly restarted). ESX Server 3.5 is limited to 128 active VMs (which is probably more than enough for most people), and Hyper-V is limited only by the available system resources. Unlike desktop virtualization products, neither product provides support for guest audio or USB.

Overall, the feature set provided by each product is comparable. ESX Server 3.5, in combination with VirtualCenter, offers Live Migration, but Hyper-V supports larger host systems and more active VMs. Both products support 64-bit guests with large memory addressability.

Setup and Management
Setting up both systems was relatively easy. However, setting up ESX Server 3.5 was much faster and easier than the Hyper-V installation. Although the ESX Server 3.5 installation was character-based, the screens were easy to follow, and I had a functional server running in about 20 minutes. The setup itself prompted for all the necessary networking and configuration information and there was no need to reboot the server. In fact, I never needed to reboot the ESX Server system during the entire testing process, which is a statement I can’t make about Server 2008 and Hyper-V. Although ESX Server 3.5 is natively managed using a Linux-based command shell, I never really needed to deal with the command shell during my tests. The Virtual Infrastructure Client, which is shown in Figure 1, enabled me to create and manage all the VMs that were required.

I downloaded and installed the Virtual Infrastructure Client by pointing my browser to ESX Server 3.5’s IP address. The Virtual Infrastructure Client management console connected and worked right away with no hassles. I found its management layout to be very professional and usable. It provides both VM management and host performance information. Although the management console doesn’t let you perform many server reconfiguration functions, in my testing, no server reconfigurations were required.

I had a good deal of trouble getting Hyper-V set up and running. However, I’m sure that much of my trouble occurred because I was using a beta version of Hyper-V. To perform the SQL Server testing, I originally attempted to install Hyper-V using Server Core but found the process hamstrung by Hyper-V’s nonfunctional remote management. (Remote management is mandatory for Server Core, which doesn’t provide a graphical interface.) I then tried John Howard’s (a senior program manager for Hyper-V) 17-step process for getting Hyper-V remote management to work, which can be found at blogs.technet.com/jhoward/archive/2008/03/30/part-3-hyper-v-remote-management-you-do-not-have-the-requested-
permission-to-complete-this-task-contact-the-administrator-of-the-authorization-policy-for-the-computer-computername.aspx. However, this process didn’t work for me. This convoluted installation process could be a real showstopper for Hyper-V and will obviously have to be fixed before the final release of the feature. Running Hyper-V on Server Core would be advantageous because of its lower overhead and reduced attack surface. The fact that I couldn’t make Hyper-V work on Server Core really made me appreciate ESX Server 3.5’s simple and functional delivery of the management client.

Continue on Page 2