Live migrate a running Hyper-V VM between failover cluster hosts

Problem and outcome

You need to move a running Hyper-V virtual machine from one failover cluster node to another—for example, to patch or replace the source host—without shutting the VM down or dropping its network connections. A live migration copies the VM’s memory and device state to the target host while the VM keeps running, then briefly pauses execution to hand off control.

The useful takeaway is simple: live migration succeeds only when both hosts belong to the same failover cluster, run the same Hyper-V version, and can access the VM’s virtual hard disks from the same shared storage, typically a Cluster Shared Volume (CSV). A CSV is a shared storage volume that all nodes in the failover cluster can access simultaneously. Verify those conditions before you start the move; discovering a missing CSV or mismatched virtual switch halfway through wastes time and can leave the VM in a paused state.

Prerequisites

• Two Hyper-V hosts joined to the same Windows failover cluster.
• Identical Hyper-V version and build on both hosts.
• The VM’s virtual hard disks (.vhdx) stored on a CSV or other shared storage visible to both hosts.
• A virtual switch with the same name on both hosts, or equivalent VLAN and network configuration.
• An account with local Administrator rights on both hosts, or domain permissions to administer the cluster.

1. Verify cluster membership and host versions

Run PowerShell as Administrator on either cluster node. These commands confirm that both servers are nodes in the same cluster.

Get-Cluster
Get-VMHost | Select-Object Name, State

Where to run: any node in the failover cluster. Required permissions: local Administrator or a domain account with cluster read access. Compare the Hyper-V role version reported on each host; mismatched builds can block migration. Risk: if one host is missing the Hyper-V role or the servers are in different clusters, stop and correct the cluster configuration before migrating.

2. Confirm shared storage and disk placement

Live migration moves memory and processor state, not the virtual hard disks. The disks must remain accessible to the target host after the move.

Get-ClusterSharedVolume

Then confirm the target VM’s disks live under a cluster volume path, such as C:\ClusterStorage\Volume1\, rather than a local drive on the source host only:

Get-VM -Name "VM01" | Select-Object Name, State, Generation, Path
Get-VMHardDiskDrive -VMName "VM01"

Where to run: any cluster node with the Hyper-V and Failover Clustering PowerShell modules. Required permissions: Administrator. Expected check: every VHDX path for the VM should resolve to a CSV mount point. Risk: if a disk is on local storage, the migration will fail or the VM will lose access to its disks on the target host.

3. Confirm network switch continuity

The VM’s virtual network adapter must connect to a switch that exists on the target host with the same name. A name mismatch leaves the VM without network connectivity after migration.

Get-VMSwitch -Name "Production" | Select-Object Name, NetAdapterInterfaceDescription

Run this on both hosts. If the switch name differs, rename it or update the VM’s network adapter settings before migrating. "Enable virtual machine queue" is an optional performance setting on the virtual NIC; it is not required for migration to work.

4. Start the live migration

You can use Hyper-V Manager or PowerShell. In Hyper-V Manager, right-click the running VM, choose Move, and select the target host. In PowerShell:

Move-VM -Name "VM01" -DestinationHost "HOST02"

Where to run: a machine with the Hyper-V module and permissions to administer both hosts, often one of the cluster nodes. Required permissions: Administrator on source and target. Placeholders: replace VM01 with your VM name and HOST02 with the target host name.

If the hosts use different CPU generations, enable processor compatibility mode on the VM before migrating, or the target may refuse the memory state. This setting is found in the VM processor settings under migrate options for different processor versions.

5. Confirm the migration succeeded

Immediately after the move, check where the VM is running:

Get-VM -Name "VM01" | Select-Object Name, State, ComputerName

ComputerName should show the target host, and State should be Running. Then verify connectivity from inside the VM or from another machine on the same network. Open Event Viewer and check the Hyper-V-VMMS and FailoverClustering logs around the migration time for successful state-transfer events; do not assume success from the PowerShell prompt alone.

Recovery if migration stalls or fails

Live migration changes the VM’s running state, so have a recovery path ready.

• Migration fails before handoff: the VM usually remains on the source host. Check the error, correct the storage or switch issue, and retry.
• VM pauses after migration: open Hyper-V Manager on the target host, right-click the VM, and choose Resume. Investigate why the handoff paused; common causes are insufficient target memory or CPU compatibility blocks.
• VM is unreachable on the network: confirm the VM is attached to the correct virtual switch on the target host and that the switch name matches the source.

Avoid forcing a shutdown of the VM while a migration is in progress; let the operation complete or fail cleanly first.

Limitations

• Live migration does not move local storage. If the VM’s VHDX files are not on shared storage, you must perform a separate storage migration first.
• A brief pause of a few seconds is normal during the final state handoff; applications sensitive to sub-second timing may notice.
• Generation 1 and Generation 2 VMs both support live migration, but firmware-related settings must be compatible with the target host.
• This procedure requires a failover cluster. Standalone Hyper-V hosts use a different migration path and typically require export/import or shared storage configured outside a cluster.

Practical verification checklist

Check	Command	Expected result
Cluster membership	Get-Cluster	Both hosts listed as nodes
Host version parity	Get-VMHost	Same Hyper-V build on both hosts
Shared storage	Get-ClusterSharedVolume	CSV online and accessible to both nodes
VM disk location	Get-VMHardDiskDrive	VHDX path under CSV mount point
Switch match	Get-VMSwitch on both hosts	Same switch name on source and target
Post-migration location	Get-VM	ComputerName shows target host