Leaving VMware for Hyper-V: failover clustering, CSV and live migration in depth

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Moving from vSphere to Hyper-V is a redesign of three things: who holds quorum, which node owns each volume, and how running VMs are allowed to move. Copying the disks is the easy part. A cluster built as a like-for-like vSphere copy can pass a quick test and still go down when one node and a witness fail together, send a whole volume's I/O over a network, or migrate one VM at a time without anyone having chosen that.

Names and addresses are examples.

Interpretations are editorial; no lab testing was performed.

Why it matters

Microsoft's support position depends on validation. It only supports cluster solutions where the complete configuration passes all validation tests and uses hardware certified for that Windows Server version. A design carried over from vSphere has to meet that test on its own terms.

How it works

Nearest equivalents

This table is our own mapping. These are nearest equivalents, and none behaves identically.

Quorum: which nodes keep running

A failover cluster stays up only while a majority of votes is present. When a partition loses quorum, the cluster service stops in the minority, and those nodes rejoin automatically later.

Microsoft publishes this survival table. W means a witness is configured.

The 50/50 entries come from dynamic quorum, which removes one node's vote when the count is even. With two nodes and no witness, the cluster survives if the node without the vote fails. It goes down if the node holding the vote dies unexpectedly. A graceful shutdown hands the vote over first, so a planned reboot test will not reveal this.

That table page is written for Storage Spaces Direct and says a witness isn't needed at five or more nodes. The general witness guidance is to always configure one on Windows Server 2012 R2 and later. Dynamic witness means it only votes when the node votes are even.

Do not put a file share witness on DFS or other replicated storage. Microsoft says this is unsupported because it can cause partition-in-time and data loss. A CSV cannot be the witness disk.

Set-ClusterQuorum -CloudWitness -AccountName <storageaccount> -AccessKey <key>
Set-ClusterQuorum -FileShareWitness \\witness01\cluster1
Get-ClusterQuorum

The second form is composed from Microsoft's documented parameter, which is shown with -Cluster and -Credential for a non-domain device. Run the Validate Quorum Configuration test afterwards.

Cluster Shared Volumes: one owner per volume

CSV gives every node read and write access to the same LUN, but each volume has a coordinator node that owns the physical disk. Metadata changes are synchronised through it over SMB 3.0.

A node doing disk I/O normally communicates directly with the storage, which Microsoft calls Direct I/O. Two kinds of redirection replace it:

• File system redirection works per volume. Causes include a CSV snapshot taken by a backup and manually set redirected mode.
• Block redirection works at file-block level, for example after a node loses its storage connection. It is the faster of the two.

Both send I/O across a cluster network to the coordinator. If the coordinator itself fails, I/O is queued briefly while ownership moves.

The state is visible per node:

Get-ClusterSharedVolumeState
Get-ClusterSharedVolume

The first command shows whether I/O is direct, redirected or unavailable on each node, and the reason when redirected. If one node reports redirection while its peers report direct, we would check that node's storage path first. If every node reports it, check the file system and any running backup.

Format choice is the trap. Microsoft's guidance is to format SAN-attached volumes with NTFS. ReFS on a SAN runs in redirected mode, with writes sent to the coordinator, and won't use Direct I/O regardless of other conditions. Reserve ReFS for Storage Spaces Direct. An engineer who picks ReFS for a SAN because it sounds newer has put every write from every non-owner node through one server's network path.

Other CSV rules to design around:

• On Windows Server 2016 and later, a CSV disk must be basic, use a supported partition layout, and be formatted with NTFS or ReFS, and the disk resource must be Physical Disk type. Pass-through disks cannot be CSVs.
• Paths sit under C:\ClusterStorage. Rename a mount point before VMs use it, not while handles are open.
• All nodes need the same system drive letter.
• Microsoft advises at least one CSV per node, so ownership can spread. It states no limit on VMs per CSV and refers you to the storage vendor.
• Do not disable Client for Microsoft Networks or File and Printer Sharing on cluster networks. CSV traffic uses SMB.

The CSV read cache needs a check on each system. The management page says it is on with 1 GiB on Windows Server 2016 and later, while the same page's table gives BlockCacheSize a default of 0. Read the real value with Get-ClusterSharedVolume | Select Name, BlockCacheSize, and do not assume either.

Networks: isolate them, then say so

A Hyper-V cluster carries six traffic types: management, cluster, live migration, storage, replica and VM access. Microsoft recommends these settings. VM networks should not appear as cluster networks at all.

(Get-ClusterNetwork -Name "Management Network").Role = 3

Three details cause most surprises:

• A node is recognised with only one IP address per subnet. A dedicated network needs its own subnet.
• The virtual switch needs Switch Embedded Teaming (SET). Microsoft's feature list says it "no longer has the capability to be bound to an LBFO team", and that LBFO stays supported outside Hyper-V. Microsoft's pages differ: the network recommendations still show New-NetLbfoTeam under a virtual switch, and the hardware page still mentions LBFO. We follow the feature list. LBFO also disables RDMA.
• Switch Embedded Teaming needs identical adapter, driver and firmware on each node.

Our example, using the documented parameter:

New-VMSwitch -Name SETswitch -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true

By default, live migration chooses from the cluster network topology. To confine it to one network, as in Microsoft's example:

Get-ClusterResourceType -Name "Virtual Machine" | Set-ClusterParameter -Name MigrationExcludeNetworks -Value ([String]::Join(";",(Get-ClusterNetwork | Where-Object {$_.Name -ne "Migration_Network"}).ID))

Heartbeat timing is shorter than many expect. A 2019 Microsoft engineering post gives Windows Server 2016 defaults of a 1-second delay with 10 missed heartbeats on the same subnet, and 20 across subnets. That is 10 and 20 seconds of tolerance. Check yours with get-cluster | fl *subnet*. The post says raising thresholds only masks a network fault, and advises generally not going above about 20 seconds.

Live migration: limits, authentication and CPU

Parallel limit. On a standalone host the default is two simultaneous migrations. In a cluster, the cluster property takes precedence. A January 2023 Microsoft post says the property defaulted to 1 when the update introduced it. So Set-VMHost -MaximumVirtualMachineMigrations 10 may change nothing that matters. Read the value that does:

(Get-Cluster).MaximumParallelMigrations

Microsoft recommends testing reliability on your own hardware before raising it. One at a time means a node drain can take far longer than a vSphere team expects.

Bandwidth with SMB. Live migration over SMB can delay or drop storage and cluster traffic if it takes too much. Installing the SMB Bandwidth Limit feature (FS-SMBBW) applies a default limit of 25% of the node's total bandwidth, so installation alone changes behaviour. Each node needs the 2022-09 Cumulative Update or later.

Encryption. Microsoft states that live migration traffic isn't encrypted on the wire and advises isolating it on trusted private networks. VM memory crosses that network, so a shared or routed migration VLAN is a security decision.

Authentication outside a cluster. That same page covers moves between non-clustered hosts, which matters during a staged build or a move between clusters. Kerberos needs constrained delegation for the cifs and Microsoft Virtual System Migration Service services, in both directions. CredSSP, the default for Windows Server 2022 and earlier, needs you signed in to the source host. On Windows Server 2025, Credential Guard is on by default for domain-joined servers that aren't domain controllers, so CredSSP-based live migration can't be used after upgrading. The documented failure text is:

Failed to establish a connection with host computer name: No credentials are available in the security package 0x8009030E.

Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Move-ClusterVirtualMachineRole also cannot run remotely without CredSSP on the server, so we would run it on a node.

CPU differences. A migration is cancelled at the start if the target lacks the VM's processor features. Processor compatibility mode hides newer instructions, and is set per VM rather than per cluster. It is off by default. Microsoft recommends enabling it only during the migration process and then disabling it, so the VM can use the host's full capabilities.

Set-VMProcessor TestVM -CompatibilityForMigrationEnabled $true

The VM must be shut down first. Windows Server 2025 adds a dynamic mode using the common feature set across the cluster, for configuration version 10.0 or later. No mode moves a running or saved VM between Intel and AMD.

Load balancing. The cited page says three things: balancing is periodic by default, every 30 minutes; the Windows Admin Center setting defaults to Never; and AutoBalancerMode 1, balance on node join only, is the Windows Server default. Mode 2 adds the 30-minute run. Trust the live value: Get-Cluster | fl AutoBalancer*.

Getting the VMs across

Microsoft documents two routes.

An IDE-attached source disk is a screening question; BIOS firmware alone does not determine the source disk controller. The VMM column follows the VMM 2025 edition of the page. The extension requires exactly VDDK 8.0.3 in C:\Program Files\WindowsAdminCenter\Service\VDDK, a Windows Admin Center gateway at build 2.4.12.10 or later, PowerCLI, and the Visual C++ 2013 and 2015 redistributables. Its FAQ says Resync is not supported. The user must stay signed in with an active browser session, or the migration may pause. There is no cancel button. Stopping a job means stopping the service and editing status files.

If VMs live on vSAN, neither route reads them. A move to another datastore comes first, and that is a Storage vMotion, which the troubleshooting page lists as a cause of invalid Change ID errors. Do it before the first sync.

What does not carry over cleanly:

Invalid Change ID errors: listed causes are changed block tracking off, snapshots, independent disks, physical RDMs, Storage vMotion, resize and restore. The logs are in C:\Program Files\WindowsAdminCenter\Service\VMConversion_log.txt and the WindowsAdminCenter event log, source WebREST, Event ID 422.

What to choose and why

Choose NTFS on SAN CSVs unless you are running Storage Spaces Direct. Direct I/O is the point of the design.

Choose a witness in a third failure domain. For most sites that means a cloud witness when every node has outbound 443, otherwise a file share elsewhere. A witness in the same rack as the nodes does not survive what you built it for.

Choose VMM when you already run it and can power VMs off for the copy. Choose the extension for a short cutover only with test VMs first and a fallback, since it is preview software.

A safe order:

1. Inventory each VM's firmware, disk count, snapshots, vSAN use, independent disks, RDMs and static addressing.
2. Install the same Windows Server version on all nodes, in the same domain, with Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools.
3. Validate, then create without taking storage: powershell Test-Cluster –Node Server1, Server2 New-Cluster –Name MyCluster –Node Server1, Server2 –StaticAddress 192.168.1.12 -NoStorage
4. Set the witness and confirm with Get-ClusterQuorum.
5. Set network roles and live migration networks.
6. Add storage formatted NTFS, then Add-ClusterSharedVolume -Name "Cluster Disk 1".
7. Test with a throwaway VM: drain a node, fail a node, read Get-ClusterSharedVolumeState.
8. Convert a pilot. Make the VM highly available if it isn't already, with Add-ClusterVirtualMachineRole -VirtualMachine VM1.
9. Move the remaining VMs in batches, keeping the source powered off but intact until validated.

To drain for maintenance:

Suspend-ClusterNode -Name "node1" -Drain -WhatIf
Suspend-ClusterNode -Name "node1" -Drain
Resume-ClusterNode node1 -Failback Immediate

Pausing suits software updates. For extensive maintenance, Microsoft suggests stopping the Cluster service on that node instead. After any unexplained event, Get-ClusterLog -Destination . collects logs from each node.

Risks and limits

Do not use -ForceDrain as a routine. Any workload that can't be moved safely is stopped and moved as a failed role, and the node is paused anyway.

Warning: validating a live cluster. Test-Cluster skips storage tests on online disks in use unless the role is stopped with Stop-ClusterGroup. Stopping a role stops its VMs. A clean report on a running cluster is not a full storage test, and getting one by stopping roles is an outage.

Do not run production VMs and their source at once. Two copies of one identity on the same network cause conflicts. Keep the VMware VM isolated through acceptance. After target writes begin, return to the source requires a proven reverse path or reconciliation; retaining the old disk alone is not a current rollback. Our recommendation; the length depends on your retention needs.

Backup behaviour changes. Windows Server Backup is crash-consistent only for VMs on CSV, and a CSV snapshot can place the volume in file system redirection. Confirm how your backup product uses CSV before go-live.

Active Directory dependency. Nodes need the same domain and time zone, and a domain controller must not run on a cluster machine in the standard design. The same page documents an Active Directory-detached cluster, PowerShell only, which we do not cover. Windows Server 2025 also documents workgroup Hyper-V clusters, and live migration in them relies on identical local accounts and self-signed certificates. Read its limits separately before choosing it for a site with no domain.

What we did not confirm. The failover clustering "what's new" URL serves the Windows Server 2019 page. The extension's vCenter 9 position is unstated. The default of 1 for MaximumParallelMigrations is from a 2023 post, so read the live value. Exact field names in Get-ClusterSharedVolumeState output were not listed on the pages opened.

Sources

Opened 2026-11-10.

• Use Cluster Shared Volumes in a failover cluster
• Manage Cluster Shared Volumes
• Deploy a quorum witness
• Understanding quorum
• Failover clustering hardware requirements
• Create a failover cluster
• VM load balancing
• Network recommendations for Hyper-V in a failover cluster
• Live Migration SMB bandwidth control
• Tuning failover cluster network thresholds
• New cluster-wide control for live migrations
• Set up hosts for live migration without failover clustering
• Live migration with workgroup clusters

• Processor compatibility mode

• Generation 1 or 2

• Convert VMware VMs with VMM
• VM Conversion extension overview, procedure, FAQ, troubleshooting
• What's new in Windows Server 2025
• Features removed or no longer developed
• Configure processor compatibility mode
• New-VMSwitch
• PowerShell references: Test-Cluster, Suspend-ClusterNode, Resume-ClusterNode, Move-ClusterVirtualMachineRole, Add-ClusterVirtualMachineRole, Get-ClusterSharedVolumeState, Get-ClusterLog, Set-VMHost, Set-VMProcessor

This article was originally published on 10 November 2026.