Many Hyper-V features have VMware equivalents, making it easier for admins to augment their vSphere infrastructures with Microsoft’s virtualization platform. The following terms are Hyper-V features that VMware admins should get familiar with before deploying Hyper-V.
VCenter Server = Virtual Machine Manager
VMware and Microsoft have their own management toolsets. In vSphere, the management platform is vCenter Server (along with the vCenter Client). The Hyper-V management equivalent is System Center Virtual Machine Manager (SCVMM), which includes both a server and client component.
You can accomplish many basic Hyper-V management tasks without SCVMM, including cluster management. If you aren’t licensed for SCVMM, you can use Hyper-V Manager, which is available on the server’s console or as a part of Microsoft’s downloadable Remote Systems Administration Tools (RSAT) for Windows 7. You can even manage Windows Failover Clusters (one of the most important Hyper-V features) with the Failover Cluster Manager tool, which is also on each host and available through the RSAT.
VMware cluster = Windows Failover Cluster
Virtual server clustering is the first step toward high availability. Both vSphere and Hyper-V require hosts to connect to shared-storage logical unit numbers (LUNs), which hold the disk files for each virtual machine (VM). Clustering allows VMs to fail over within cluster boundaries in the case of a host failure, and also facilitates VM load balancing.
But there’s an important difference between VMware and Hyper-V features for clustering. VSphere’s clustering technology is solely for the purpose of clustering, whereas Hyper-V relies on its general-purpose Windows Failover Clustering feature. Hyper-V management of host clusters, therefore, requires some extra care. Windows Failover Clustering is designed to support all kinds of services -- DHCP, file server, SQL Server and other application types -- so many of its configurations require careful tuning. SCVMM 2012 (currently in beta) may eliminate some of this clustering complexity for Hyper-V management.
VMware vMotion = Hyper-V Live Migration
When hosts are clustered atop shared storage, you can migrate VMs among them without downtime. This no-downtime migration, called VMware vMotion in vSphere, is referred to as Live Migration in Hyper-V. This Hyper-V management feature was first available with the release of Windows Server 2008 R2. The actual migration process on both platforms is basically the same.
VMware HA = High-availability virtual machines
Both platforms offer high-availability clustering techniques, and they function very similarly. Both VMware HA and high availability in Hyper-V (though its clusters are a bit more difficult to build) provide VM failover with limited or no downtime. More important, however, are the differences in the two vendors’ failover calculations.
When a host fails in either vSphere or Hyper-V, so do its VMs. Determining where the failed VMs should restart is therefore an important decision. VSphere and Hyper-V features handle this decision quite differently.
In the current version of Hyper-V and SCVMM, VM restarts are based on configurations assigned in Windows Failover Clustering. Admins can influence placement by suggesting potential hosts for each restarted VM, but these settings can be challenging to configure manually.
SCVMM also does not use cluster-wide calculations for VM placement, as vSphere does. These calculations facilitate the proactive placement of VMs and are a capability vSphere clusters have long enjoyed. SCVMM 2012 is expected to add similar support for Hyper-V high availability calculations.
Distributed Resource Scheduler = Performance and Resource Optimization
VMware HA and Distributed Resource Scheduler (DRS) use cluster-wide calculations of resource entitlements and utilization to balance VM workloads. DRS measures resource usage across an entire cluster to load-balance VMs among hosts, and you can use its calculations to restart VMs after a failure.
The Hyper-V features for load balancing are notably limited in comparison. Rather than taking into account cluster-wide conditions, SCVMM focuses on individual host overutilization with its Performance and Resource Optimization (PRO) feature. This Microsoft TechNet article (PDF) explains the approach in detail. Hyper-V recognizes a host is overloaded when memory utilization is greater than "physical memory on the host minus the host reserve value for memory on the host." It recognizes CPU overutilization when use is greater than "100% minus the host reserve for CPU on the host."
Another important distinction between PRO and DRS is that Hyper-V load balancing requires the coordination of two Hyper-V management toolsets: SCVMM for managing VM actions and System Center Operations Manager (SCOM) for monitoring assets and triggering actions. SCOM again represents Microsoft’s more general-purpose approach toward accomplishing this Hyper-V management task.
Virtual Machine File System = Cluster Shared Volumes
A server cluster requires multiple hosts to access the same files, so you need a file system that can support such access. VMware’s Virtual Machine File System (VMFS) is designed for multiple-server access. Microsoft, however, did not originally design its New Technology File System (NTFS) with this use case in mind.
Prior to Windows Server 2008 R2, the native limitations in NTFS forced all VMs on the same LUN to fail over together. Hyper-V required this linked failover because of Windows Failover Cluster’s approach to storage, where only a single host could access a particular LUN at a time.
Microsoft improved on Hyper-V management in R2 by adding Cluster Shared Volumes (CSV), which allow VMs on the same LUN to fail over independently. This approach eliminates the need to create one LUN per VM to support independent failover, but the CSV technology still suffers from limited vendor support for activities such as backup and recovery. Plus, it’s not fair to make a direct comparison between VMFS and CSV, because VMFS contains additional functionality specifically designed for supporting VMs.
Storage vMotion = Quick Storage Migration
VMware vSphere includes Storage vMotion, which can move VM disk files between data stores. Hyper-V’s equivalent is Quick Storage Migration. Both features achieve the same goal, but VMware’s technology can accomplish the task without powering down or pausing the VM. Hyper-V, on the other hand, suspends the VM’s activities during the transfer.
VMware and Hyper-V features: Ever-changing
VMware and Hyper-V features will always be changing as products evolve. In fact, VMware has changed those gaps with vSphere 5.[SC9] The new version improved high availability and added Storage Distributed Resource Scheduler, which improves upon automated storage management. Still, Microsoft’s improvements in SCVMM 2012 will likely narrow many of the gaps in Hyper-V management explained above.
If you are considering adding Hyper-V to your existing vSphere environment, pay careful attention to where those Hyper-V feature gaps exist.