Virtualization Rematch

Earlier this year, Windows IT Pro published my head-tohead comparison of Microsoft’s Hyper-V virtualization platform and VMware’s market-leading ESX Server. In that two-part series, I compared the feature sets, licensing, and performance of both products. I found ESX Server to have a notably better installation and management story, as well as a slight performance edge. However, for a pre-release product, Hyper-V fared well and proved itself to be a viable virtualization platform.

Since that first round of reviews, much has changed in the virtualization market. First, the RTM version of Hyper-V is now available: Microsoft has made its final performance enhancements to the product. Second, Microsoft has released a standalone version of Hyper-V called Hyper-V Server 2008. For more information about this incarnation, see the web-exclusive sidebar “The Standalone Hyper-V Server 2008” (www.windowsitpro.com, InstantDoc ID 100574). Third, both companies have altered the licensing for their respective products. Hyper-V Server 2008 and VMware ESXi are free downloads. For more information about VMware ESXi, see the webexclusive sidebar “ESXi vs. ESX Server” (InstantDoc ID 100575).

Considering these changes, I’ve decided to retest these products’ management and performance aspects, as well as address some particular concerns about each product that readers—and Microsoft and VMware representatives—have brought up since my first tests. Now, let’s jump back into the ring with ESX Server and Hyper-V.

Hypervisor Differentiation
Both ESX Server and Hyper-V are hypervisor-based, but not all hypervisors are created equal. The architectures of these products differ significantly. And many IT pros have been confused by Hyper-V, mistakenly assuming that because it’s shipped with Windows Server 2008, it’s a hosted virtualization product that runs on top of the Server 2008 OS. That’s not the case. Like ESX Server, hypervisor-based Hyper-V runs directly on the system hardware.

Figure 1 provides an architecture comparison. As you can see, one of the biggest differences between the products is the way each handles hardware device drivers. ESX Server implements the drivers as a part of the hypervisor itself—a method that results in a comparatively large hypervisor. This approach also adds third-party code to the hypervisor. VMware tests and certifies these drivers, but they’re developed by system hardware vendors. (For a list of systems that support ESX Server 3.5 and ESXi, see the Learning Path.) Hyper-V implements the drivers in the parent partition, outside the hypervisor. Table 1 provides the pros and cons of each approach.

The implementations of the hypervisor itself also differ. The ESX Server hypervisor uses a 32-bit kernel, allowing it to run on both 32-bit and 64-bit systems. However, that doesn’t limit it to running only 32-bit guests; ESX Server also supports 64-bit guests if it’s running on a 64-bit hardware platform. With its next ESX Server release, VMware plans to move to a 64-bit hypervisor. By contrast, Hyper-V already uses a 64-bit hypervisor, which promises improved performance and scalability. Also, Hyper-V requires that the system you install it on possess processor-assisted virtualization (e.g., AMD processors that support AMD-V, Intel processors that support Intel-VT). Hyper-V requires that the processor have either AMD’s No Execute (NX) or Intel’s Execute Disable (XD) features, and the system needs to offer BIOS support for virtualization. These features are standard in most of today’s server systems, but they aren’t in all systems.

Guest Support
To some extent, the differences between the products’ hypervisor implementations are academic. Both products have proven to be good performers and scale well with multiple workloads. However, the difference in guest OS support is much clearer. In this respect, ESX Server is a much more mature product: VMware supports a wide array of guest OSs. Web Table 1 provides a list of guest OSs that ESX Server supports. (For a complete list of the guest OSs that the product supports, see the Learning Path.)

As you might expect, the list of guest OSs that Hyper-V supports includes all the recent Microsoft OSs but few others. Web Table 2 provides a list of guest OSs that Hyper-V supports. (For a complete list of the guest OSs that the product supports, see the Learning Path.) The list of OSs that Hyper-V supports is dominated by Microsoft, with the exception of SUSE Linux—but this Linux implementation is limited to a single virtual CPU, far short of the Linux support that ESX Server offers. Microsoft marketing states that Hyper-V runs other OSs, such as multiple Linux distributions, but actually Hyper-V doesn’t support any distribution other than SUSE, for which Microsoft has an agreement with Novell. Microsoft has made the code for the Linux Hyper-V integration components available but has left its adoption to other vendors—a significant development because the VMBus-aware drivers that provide the best Hyper-V performance are installed as a part of the integration components. Without them, the guest must run in slower legacy-emulation mode. Currently, no integration components are available for other Linux implementations, but you can run other Linux distributions as unsupported legacy guests.

Built-In Management
This review is focused solely on the virtualization platforms themselves, and I won’t touch on the management suites that either vendor provides as separate products. The distinction can be confusing: Many VMware-supporting readers have opined that VMware’s VMotion is the single biggest difference between the products; however, although VMotion is an important feature, it’s not a part of ESX Server but rather a component of the VMware Infrastructure 3 (VI3) management suite. A forthcoming Windows IT Pro article will compare VI3 and Microsoft’s management suite, System Center Virtual Machine Manager (SCVMM). Let’s take a look at the products’ inherent management functionality.

ESX Server. You use the Virtual Infrastructure Client to manage ESX Server. To download the client to your local system, you simply point your web browser to your ESX Server system, then click the Download VMware Infrastruture Client link. The entire process takes a couple minutes. The Virtual Infrastructure Client offers a fullfeatured, functional interface for managing multiple VMware virtual machines (VMs) for one ESX Server host. You can create and control VMs, and you can control a number of host settings, such as the configuration of virtual switches, the host time, the DNS server, and VMs’ automatic start and stop actions. Also, you can use the Virtual Infrastructure Client to set up users and groups, along with their associated permissions.

The most noticeable missing feature is the ability to easily copy VMs among hosts. There’s no built-in Windows Explorer, and no connections to remote hosts. However, free third-party tools such as Veeam and WinSCP can fill this gap. One of the best features of the client is its ability to track performance data at both the host and the VM level. It provides a storage summary, as well as CPU, memory, network, and disk usage. Figure 2 shows the Virtual Infrastructure Client’s Performance tab.

Although the Virtual Infrastructure Client provides a good management interface in the absence of the VI3 management suite, it’s limited. For example, it doesn’t provide the ability to import and convert VMs, as the other VMware virtualization products do. And it doesn’t let you copy or clone VMs. These options are present only if VI3 and VirtualCenter Server are available. Finally, I’ve found that I often need to drop back into the Linux management console to perform many tasks. For example, if I copy a VM to ESX Server, I don’t get a graphical option to register the VM—I need to use the Vmwarecmd command.

Hyper-V. In the arena of management, Hyper-V stumbles. Management for Hyper-V with a full Server 2008 installation is a good experience: When you install the Hyper-V role, the Hyper-V Manager is present and you can use it from the full Server 2008 installation to manage Hyper-V. Such is not the case for the Server Core version. Server Core has no built-in GUI and requires remote management. However, unlike ESX Server, the remote client is a separate download, and I had difficulty getting it connected. I used Server 2008 and a Vista client. I first tried it in a workgroup, then in a domain. Although it eventually worked, it wasn’t a good experience— certainly not on par with the easy Virtual Infrastructure Client installation and connection. During my first round of testing, I attributed the difficulty to Hyper-V’s prerelease code. Unfortunately, I was dismayed to find that the problem remains unresolved in the final release version.

Continue on Page 2

   Previous  [1]  2  3  Next