Virtualization Management Shootout: Microsoft System Center VS. VMware vSphere

Confirming what most people already know, an IDC study from October 2008 showed that VMware was the clear leader in the enterprise virtualization marketplace, with 78 percent of the market. However, since the release of Windows Server 2008, Microsoft has been making a strong push in the enterprise virtualization market with Hyper-V.

Last year, I compared VMware’s ESX Server 3.5 and Windows Server 2008 Hyper-V. I concluded that while Hyper-V was a strong challenger to ESX Server and definitely a cost-effective solution, ESX Server was a more mature product that offered several management advantages and held a slight performance lead over Hyper-V. (See “Virtualization Shootout, Part 1”  and “Virtualization Shootout, Part 2.")

Several VMware proponents were quick to point out that ESX Server supports VMotion, while Hyper-V at that time had only Quick Migration. That contention was true, but the original comparison was between the virtualization platforms themselves—not the management frameworks provided by each vendor. VMotion is not a feature of ESX Server: It’s a part of VMware’s virtualization management platform and was beyond the scope of our original comparison. This article is a follow-up to the original ESX versus Hyper-V comparison.

However, this time I focus on the virtualization management platforms offered by VMware and Microsoft. A lot has changed in a year: VMware has totally revamped its virtualization management line and rebranded it as vSphere. Likewise, Microsoft has updated Server 2008, Hyper-V, and System Center Virtual Machine Manager 2008 (VMM) with new R2 releases.

At first I decided to compare VMM to vSphere, but it soon became apparent that the scope of these two products isn’t equal. VMware’s vSphere is a complete management platform. (See Sidebar 1 for a list of its components.)

The closest comparison isn’t to VMM but rather to Microsoft System Center Enterprise Management Suite (for a list of its components, see Sidebar 2). So instead, I compared how VMware’s vSphere and Microsoft System Center Enterprise Management Suite match up when addressing some of the important issues faced by IT administrators.

Virtual Infrastructure Management: VMM and vSphere Client
First, I compared management interfaces. Microsoft’s offering for VM management is VMM, which provides a completely different management experience than the Spartan interface offered by Microsoft’s Hyper-V Manager. VMware offers the vSphere Client.

The VMM administrative console, which Figure 1 shows, lets you manage virtual machines (VMs) from multiple hosts—including ESX Server—for mixed virtualization management. VMM is cluster aware, in that it automatically adds all nodes in a cluster and can perform cluster configuration for high availability and live migration for you.

It also enables you to manage other virtual assets including creating and storing templates, ISO images, sysprep answer files, and different standard hardware configurations. In addition to managing VMs, the VMM console can also perform physical to virtual (P2V) migration and virtual to virtual (V2V) migration for VMware VMs.

One of the best features in VMM 2008 R2 is its integration with Windows PowerShell, so almost all of the actions can be easily scripted into PowerShell commands. However, one problem I ran into while managing VMs with both Hyper-V Manager and VMM was that I occasionally wound up with orphaned VM entries in the VMM console.

VMM requires access to a Microsoft SQL Server system on the back end to store its information. VMM2 2008 R2 does require Windows Server 2008 R2 x64 and it can use SQL Server 2005 SP3 and SQL Server 2008.

VMware’s management interface, vSphere Client, provides a broader management scope, unlike the VMM administrative console, which focuses on VMs. VMware vSphere Client includes the ability to manage host and VM performance data as well as user and role management. You can see the vSphere Client in Figure 2.

The vSphere Client enables you to perform the full range of VM management functions. When you’re running the vSphere Client with a vCenter Environment, the menu options in the vSphere Client are populated with more advanced options, including the ability to clone VMs and perform VMotion transfers between hosts. (More information about VMotion is presented later in this article.)

Overall, I preferred the vSphere Client to the VMM console. I found it easier to use and more efficient with important performance information close at hand. I had little need to go to other tools. However, some important features such as Datastore management were hard to find, being buried under the Summary tab.

Planned Downtime: Live Migration and VMotion
Without a doubt, VMotion was the feature that most readers commented on in my previous comparison review. VMotion is a ground-breaking technology that enables VMs to be moved between ESX Server hosts with no downtime and no interruption of end-user services.

VMotion does require compatible CPUs on the ESX Server hosts. In other words, both hosts must use processors from the same manufacturer, and they must be part of the same processor family.

VMotion isn’t part of vSphere Standard edition, but it’s in vSphere Advanced, Enterprise, and Enterprise Plus editions. VMotion also requires vCenter Server.

The original release of Server 2008 and Hyper-V didn’t include capabilities equivalent to VMotion. The first release of Hyper-V did have a feature called Quick Migration, which wasn’t really all that quick. Quick Migration essentially saves a VM’s state, then moves all of the VM files to a different storage location and restores the VM state.

The release of Server 2008 R2 introduced the new Live Migration feature for Hyper-V. Comparable to VMotion, Live Migration enables VMs to be moved between Hyper-V hosts with no downtime and no interruption of end-user services.

Live Migration is enabled by a new Server 2008 technology called Clustered Shared Volumes (CSV). Live Migration requires Windows Server 2008 R2, and the Hyper-V hosts must also be a part of Windows Failover Cluster. The advent of Live Migration has given Microsoft feature-parity with VMware in the area of planned downtime.

However, Live Migration isn’t identical to VMotion. The maturity of the VMware platform shows: ESX Server can perform multiple concurrent VMotions while Hyper-V is limited to one Live Migration at a time.

Unplanned Downtime: Windows Failover Clustering and HA/FT
Addressing unplanned downtime is the other half of the high availability question. For a Microsoft implementation, a virtual IT infrastructure uses Windows Failover Clustering to address the issue of unplanned downtime. Failover Clustering allows up to 16 servers to work together to provide redundant hardware services. (Though not available in Server 2008 Standard edition, it’s supported in the Server 2008 Enterprise and Datacenter Editions.)

Windows Failover Clustering also requires an isCSI or Fibre Channel SAN for shared storage.

Failover Clustering can be used at both the virtualization host and guest levels. At the host level, Failover Clustering provides protection from the potential single point of failure of the Hyper-V server. If a Hyper-V server that’s part of a Windows Failover Cluster fails, then all of the VMs running on that server will be restarted on another node.

Similarly, VMs themselves can act as nodes in a failover cluster and the different nodes can be running on multiple Hyper-V hosts. With Failover Clustering, the failover process is completely automatic, with minimal downtime as services are restarted on alternate nodes. The actual amount of downtime depends on the services themselves and the capabilities of the hardware platform.

VMware vSphere has two options for addressing unplanned downtime: High Availability and Fault Tolerance.

High Availability is in all the editions of vSphere. It supports up to 32 node clusters on the vSphere Enterprise Plus edition and up to 16 nodes on the other editions. Like Failover Clustering, High Availability provides protection at both the server level and VM level.

Also like Failover Clustering, VMware High Availability incurs some downtime as VMs are restarted on backup servers. High Availability is able to take advantage of DRS to optimize the placement of VMs to be restarted. More information about DRS is presented in the next section.

Fault Tolerance is a new feature in vSphere 4. Unlike High Availability, Fault Tolerance works only between two systems, but it provides protection from system failure with no downtime.

Fault Tolerance uses a VMware technology called vLockStep. The vLockStep technology keeps the virtual processors of two VMs in synch at the instruction level. If one VM fails, the other VM steps in instantly as it’s running at the exact same processor instruction and has an exact copy of the RAM that’s in the primary VM. Fault Tolerance is limited to two VMs, and each VM is limited to a single virtual processor.