Virtualization Shootout, Part 1

With the release of Windows Server 2008 and its all-new Hyper-V virtualization support, Microsoft has finally mounted a serious challenge to VMware’s mature and robust ESX Server, the established leader in the enterprise virtualization market. In this twopart article I’ll compare Microsoft’s Hyper-V to VMware’s ESX Server 3.5. In part 1 of this two-part comparative review, I’ll compare the different architecture and feature sets of each product. In part 2, I’ll do some basic performance testing of the two products to see if Hyper-V can deliver comparable performance to ESX Server.

A Tale of Two Architectures
Both VMware’s ESX Server 3.5 and Microsoft’s Hyper-V are built using a hypervisorbased architecture. This architecture gives both platforms bare-metal performance that significantly outperforms older hosted virtualization products such as Microsoft Virtual Server 2005 and VMware’s Virtual Server 2.0. Hosted virtualization products run the virtualization software on top of the host OS, which introduces additional 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 and Hyper-V are designed to run the hypervisor directly on the system hardware. Although ESX Server 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 Figure 1.

In both cases, the hypervisor runs directly on the system hardware. However, with ESX Server the hardware drivers are all part of the hypervisor, which significantly increases the size of the hypervisor. In addition, the device drivers are created by the hardware vendors, which introduces third-party code into the hypervisor and limits the hardware that ESX Server supports. Even so, ESX Server is supported on most of the server systems made by all the tier-one vendors, such as HP, Dell, and IBM. Many of these vendors also sell systems configurations with VMware ESX Server preloaded.

In contrast, Hyper-V uses a microkernel hypervisor in which the hypervisor contains the minimal amount of code required to schedule and share hardware resources between the active VMs. The Hyper-V hypervisor has no device drivers and no third-party code, which ensures the best possible performance and reduces security exposure. Hyper-V leverages the native Windows device driver model, utilizing the device drivers in the guest VMs. For more information about the Hyper-V architecture, see “A First Look at Windows Server 2008 Hyper-V” (February 2008, InstantDoc ID 97857).

Both products are managed from the first VM partition. In ESX Server this VM partition, typically called the service console, is based on the Linux shell and is managed via the command line. However, you can download an easier-to-use Windowsbased management client, called the Virtual Infrastructure Client, from ESX Server’s Web console. Hyper-V is also managed using the VM running in the first partition. In Hyper-V this partition is called the parent partition. In addition to VM management, the parent partition is also used to run VMs with legacy OSs such as Windows NT and Windows 2000 that can’t utilize Hyper-V’s new VMBus architecture and must use the older emulated hardware model.

Pound for Pound
Unlike the earlier version of Virtual Server 2005 R2, Hyper-V’s new architecture and 64-bit foundation bring its feature set into parity with the features that are present in VMware’s ESX Server. Table 1 shows a feature-by-feature comparison of VMware’s ESX Server 3.5 and Microsoft’s Server 2008 Hyper-V.

The primary differences begin with the hypervisor itself. As I explained previously, the ESX Server hypervisor is a heavyweight hypervisor that contains device drivers. In contrast, the Hyper-V hypervisor is a thin hypervisor that contains no drivers and no thirdparty code. Hyper-V’s device drivers are in the guest OSs, which makes the Hyper-V hypervisor smaller and more secure. Both platforms provide support for 32-bit x86 and 64-bit x64 guest OSs and large VMs with up to 64GB of RAM per VM. For more efficient memory usage, ESX Server provides a shared memory feature that lets VMs share common memory blocks. Although this feature can enable more simultaneously active VMs, it generates additional performance overhead. Hyper-V doesn’t support shared memory between VMs. Both platforms support booting VMs from either an iSCSI or Fibre Channel SAN. One area where VMware excels is in support for live migration (i.e., moving running VMs from one host to another). However, this feature requires the VMware Virtual- Center Server product. Hyper-V doesn’t support live migration, but when coupled with Windows Server 2008 Enterprise Edition and Microsoft System Center Virtual Machine Manager, it does provide support for what Microsoft calls quick migration— quickly saving the state of a running VM and then moving that VM and saved state to another host. Quick migration requires the use of failover clustering. ESX Server is limited to 128 active VMs (probably enough for anyone), whereas Hyper-V is limited only by the available system resources. Unlike the desktop virtualization products, neither product provides support for guest audio or USB. ESX Server supports guest VM backup using the integrated Consolidated Backup feature, which takes a snapshot image of the VM and writes it to a backup server. Hyper-V supports live backup of VMs using Volume Shadow Copy Service (VSS).

Are You Experienced?
Setting up both systems was relatively easy. The basic setup for ESX Server was actually easier than the Hyper-V installation. Although the ESX Server installation was character based, the screens were easy to follow and I had a completely functional server in about 20 minutes.

For Hyper-V the actual installation process was easy but the subsequent system setup on Windows Server Core was a manual piecemeal process that required a good deal of Windows command-line knowledge to complete. The Hyper-V virtualization role can be installed on either a full Server 2008 installation or on a minimal Server Core installation. Server Core is the better choice for a virtualization server host because it has all the extraneous Windows components stripped out (e.g., the graphical shell, Internet Explorer—IE, Outlook). This bare-metal approach gives Server Core less overhead and makes it more efficient. Server Core is also more secure because of the reduced attack surface area, as well as more reliable because of the smaller number of components that might need patching. Installing the Server Core OS took about 15 minutes; running the subsequent system configuration commands took about 20 more minutes and a couple of reboots. For more information about the commands to configure a Server Core system and add the Hyper-V virtualization role, see Top 10, “Essential Server Core Setup Commands.”

To manage the system, I needed to attach to it remotely using the Hyper-V management console, which Figure 2 shows. You can run this console from a Server 2008 system with Hyper-V installed or from a Windows Vista system with the update installed that’s discussed in the Microsoft article “Availability of the Windows Vista Service Pack 1 management tools for the Hyper-V release candidate” (support.microsoft.com/?kbid=949758). Any Windows administrator will feel right at home with this Microsoft Management Console (MMC) 3.0–based interface.

You can manage multiple Hyper-V server instances in the console’s left pane. Selecting a server instance displays that server’s VMs in the center Virtual Machines pane. You can then manage the VMs by right-clicking them and selecting options from the context menu. All Hyper-V management tasks can be performed using the Hyper-V Management Console.

Managing ESX Server is another story. ESX Server uses a Linux-based command shell—this command line might be comfortable to a Linux administrator, but I’m not one. (In fact, I rarely need to deal with Linux.) Fortunately, the VMware Virtual Infrastructure Client is a graphical tool that you can download by pointing your browser to the server’s URL. Figure 3 shows the VMware Virtual Infrastructure Client.

The VMware Virtual Infrastructure Client lets you create and manage VMs. However, it doesn’t let you perform server management functions such as adding and removing network cards. You need to use the command line to perform those types of functions.

Using built-in management consoles to manage a few servers is just one aspect of virtual server management. But if you have more than just a few virtual server host platforms to manage, you’ll need more powerful management tools. Both VMware and Microsoft offer such tools. To find out more about the virtualization management tools offered by each company, see “Virtualization Management.”

Continue to page 2