Comparing vSphere and Hyper-V

Microsoft Platform Guide

Audience
Public
Source Type
Documentation

Technical Feature Comparison

Type 1 Hypervisor: Both VMware ESXi and Microsoft Hyper-V are Type 1 hypervisors. This may seem counterintuitive because Windows Server is installed first, and Hyper-V the Role is installed second. The bare metal Windows Server becomes the root partition above the Hypervisor, and all VMs are child partitions above the Hypervisor. A type 1 Hypervisor has direct access to the hardware, which Hyper-V does. For more information see Hyper-V architecture.

Both hypervisors have guest operating system services; Hyper-V Integration Services and VMware Tools.

Virtual Machine Shared Storage: Both hypervisors support shared storage that can house VM configuration and virtual disk files. VMware calls this a datastore, and in Hyper-V it is Cluster Shared Volume (CSV). Think of CSV as being an NTFS Datastore instead of an VMFS Datastore in VMware.

USB devices: Hyper-V supports USB Storage devices, whereas VMware will support any USB device.

File Systems: Hyper-V supports both NTFS and ReFS, whereas VMware will support VMFS. In a FlashArray context, only NTFS will support Offloaded Data Transfer (ODX) which enables offloading file copy from 1 disk on a FlashArray to another in seconds because the file copy is offloaded to the storage, and the FlashArray just has to update metadata. This is unsupported with PODs, but it is supported regardless of whether the source or target is a disk in Windows, or within a VM or across an SMB connection.

Examples: (All volumes must be on the same FlashArray)

If the source or target Pure Volume is within a Pure POD, ODX is disabled. PODs are used for ActiveCluster and ActiveDR.

If the source is a disk on a Hyper-V server, and the target is inside a VHDX file on a CSV on the server or vice versa, ODX is enabled.

If the source is a disk on a Hyper-V server, and the target is an SMB share on another server, or vice versa, ODX is enabled.

Space Reclamation: Free space reclamation of thin disks is an issue for Hyper-V particularly on Cluster Shared Volumes (CSV). VMware handles this natively on VMFS. This becomes an issue when moving a significant number of VM from one CSV to another. The blocks consumed on the original CSV will not be released.

The mechanism to release the storage on the FlashArray involves using the Microsoft Sysinternals tool, sdelete, or creating a new CSV and moving the remaining VMs from the fragmented CSV and then removing it. In the case of Pure Volumes without PODs, Microsoft ODX will be involved and even petabytes of remaining virtual hard disks on the CSV will copy off in seconds to minutes to the new CSV. Then the empty CSV with trapped data in the filesystem can be deleted on the FlashArray.

VM snapshots: Both VMware (snapshot) and Hyper-V (production checkpoint) support VM snapshots when the VMs only have virtual disks. These snapshots are copy-on-write snapshots that create new child virtual disks for each virtual disk on the VM.

The existence of these snapshots impacts performance, and each additional existing snapshot will further erode performance. This is why both Hypervisors limit the number of snapshots; 32 for VMware and 50 for Hyper-V. If the snapshot has existed for some time, and there are many changes to the virtual disk, the act of deleting the snapshot incurs a significant performance impact to the storage subsystem because the child virtual disk must be merged to the parent virtual disk.

Whenever possible, Pure recommends utilizing hardware storage snapshots. Most solutions that utilize software VM snapshots attempt to reduce the performance impact by quickly removing the snapshot after backup leveraging Vmware’s change block tracking or Hyper-V’s resilient change tracking.

Take a Pure Volume snapshot that is crash consistent. Tools available to initiate a crash consistent snapshot on a FlashArray include: RestApi, FlashArray CLI, FlashArray GUI, PowerShellSDK, BackupSDK, and Everpure’s extension for Windows Admin Center. In the case of Everpure’s FlashArray snapshots 2 options are available.

  • On a Hyper-V CSV, no quiescing occurs, so rarely a VM may not boot. This is no different than if the power was removed from either the FlashArray or the Hyper-V host. For added protection, some customers automate the creation of a production checkpoint, then a crash consistent Pure Volume snapshot, and finally the removal of the production checkpoint. This automation can occur in seconds to minutes. Should one VM not be able to boot from a recovered or cloned Pure Volume snapshot, simply revert to the production checkpoint that occurred seconds before the hardware snapshot. For an example see FA-HyperV-Scripts.

  • Volume Shadow-copy Service (VSS). Everpure’s VSS Hardware Provider can be utilized with the Windows built-in DiskShadow VSS Requestor, or a 3rd party Requestor (Backup Application). Simply take an application consistent snapshot of the Cluster Shared Volume (CSV) and all the VMs will be quiesced ensuring an application consistent snapshot.

VM Migration: Both hypervisors support moving a VM to a new host in the cluster, and moving the storage to a new location without incurring downtime for the VM. VMware calls this vMotion and Storage vMotion, whereas Hyper-V calls it Live Migration and Storage Migration.

Clusters: Both hypervisors can belong to a cluster which enables high availability for the VMs and load balancing. VMware enabled availability for VMs with HA or High Availability. VMware’s DRS or Dynamic Resource Scheduler is used to load balance VMs across the cluster. VMware’s FT or Fault Tolerance creates a shadow VM that can be automatically failed over should the primary VM become unavailable.

Hyper-V VMs that are Highly Available become cluster roles in the Failover Cluster and will automatically failover in the event of a Hypervisor failure. Dynamic Memory and Resource Metering can help optimize resource utilization, and with SCVMM both load balancing and VM placement based on Hypervisor resource utilization is available.

Licensing/Packaging Comparison

VMware administrators are familiar with the licensing of vCenter and the various add-on services within the vSphere environment. Since VMware’s acquisition by Broadcom, the licensing structure has changed significantly. For more detailed information see Licensing and Subscription in vSphere.

Hyper-V is a Windows Server Role that is not licensed separately. Windows Server has two versions, standard and datacenter, available either with a desktop or server core edition. Windows Server is licensed per core, and that cost depends on whether the version is Standard or Datacenter. The Windows Server Standard license includes 2 Operating System Environments (OSE), or VMs. Depending on the region, a multiple of the standard license can be applied to the same server before switching to a Datacenter license becomes advantageous. The Windows Server Datacenter license includes an unlimited number of OSEs or VMs.

Many customers have moved to the Datacenter license because it is more cost effective than applying multiple Standard licenses to a single host. These customers find that moving from VMware is a huge reduction in cost, since they have already licensed all of the cores on the Server with the Datacenter license. For these customers, migrating to Hyper-V and removing VMware is a net reduction in business cost with no additional Microsoft licensing costs. Customers that have a single or multiple Windows Server Standard licenses will have to evaluate what additional licensing, if any, will be required.

Windows Admin Center is a modern tool used to manage Windows Servers. Windows Admin Center has no additional cost beyond Windows.

System Center Virtual Machine Manager is licensed in the System Center suite. System Center Standard license includes a license to manage up to 2 physical servers. System Center Datacenter license includes a license to manage an unlimited number of physical servers. Both licenses are sold in multiples of 2-core pack licenses with a minimum of 16 cores licensed. This is different from vCenter licensing, which is either a Solution License or licensed with a per-instance capacity.