Hyper-V Live Migration: Preflight, Kerberos Delegation, and Failure Diagnosis

Hyper-V live migration moves a running virtual machine from one Hyper-V host to another with service interruption intended to be minimal. A successful move depends on more than a reachable destination: the hosts need compatible configuration, a valid authentication path, accessible VM storage, suitable virtual switch and processor capabilities, sufficient memory and network capacity, and permission to perform the operation. A live-migration error may surface as a generic credentials failure, transport error, VM configuration mismatch, or timeout even when the underlying cause is different.

Separate live migration from Hyper-V Replica and failover clustering. Live migration moves the running VM’s execution state between hosts. Hyper-V Replica asynchronously replicates VM changes to a recovery host; failover clustering coordinates a highly available VM role. These designs can coexist, but their networks, authentication, storage, and recovery objectives are distinct. This runbook focuses on the migration transaction and its evidence, not on converting an unplanned outage into a failover operation.

Define the migration path and invariants

Record source and destination host names, OS versions and patch levels, CPU vendor and feature exposure, VM generation and configuration version, memory state, virtual switch names and VLANs, storage paths, checkpoint state, cluster membership, migration network, expected downtime, and rollback owner. Identify whether the move is inside a failover cluster, between standalone hosts, or across administrative boundaries. These modes have different orchestration and authentication requirements; do not apply a standalone-host procedure to a cluster role without checking the cluster’s supported workflow.

Confirm that every VM network adapter can attach to an equivalent destination virtual switch with the intended VLAN, QoS, isolation, and management-plane behavior. The switch name may be referenced in VM configuration, but a same-named switch does not guarantee identical uplinks or policies. Validate host vNICs, SET or NIC team design, physical switch configuration, jumbo-frame policy if used, routing, and firewall rules. A migration can complete while the guest becomes isolated if the destination’s virtual network differs.

Determine whether storage is shared or will be moved as part of the migration. Shared storage still needs consistent access and permissions from both hosts. Storage migration requires additional capacity and bandwidth and can substantially lengthen the operation. Confirm that destination volumes have space for the VM configuration, VHDX files, checkpoints, smart paging, and any temporary copy. Verify that antivirus, backup, or storage controls will not lock or rewrite files during the move.

Collect host configuration before changing anything

Use read-only PowerShell inventory on both source and destination. The Hyper-V module’s Get-VMHost properties help compare migration settings; query the VM and virtual switch as separate objects:

$hosts = 'HV01.contoso.com', 'HV02.contoso.com'

foreach ($hostName in $hosts) {
    Get-VMHost -ComputerName $hostName |
        Select-Object @{Name='Host';Expression={$hostName}},
            VirtualMachineMigrationEnabled,
            VirtualMachineMigrationAuthenticationType,
            VirtualMachineMigrationPerformanceOption,
            VirtualMachineMigrationMaximum

    Get-VMSwitch -ComputerName $hostName |
        Select-Object @{Name='Host';Expression={$hostName}},
            Name, SwitchType, NetAdapterInterfaceDescription,
            AllowManagementOS
}

Confirm property names against the installed Hyper-V module and version. Capture the VM’s current state with Get-VM, its adapters with Get-VMNetworkAdapter, and its disks with Get-VMHardDiskDrive. Check destination CPU compatibility settings, dynamic memory limits, VM configuration version support, storage access, and the source and destination’s free memory. A successful host query is not a compatibility certification; compare the actual VM settings and supported Windows Server versions.

For cluster migrations, run the supported cluster validation tests in a maintenance window and inspect cluster networks, CSV health, storage paths, and role ownership. For standalone hosts, explicitly test destination authorization and storage access. Ensure both hosts’ clocks and DNS are healthy; authentication failures can result from time skew, stale computer accounts, name resolution, or constrained-delegation configuration.

Configure authentication for the actual topology

Hyper-V supports CredSSP and Kerberos authentication for live migration in documented scenarios. CredSSP delegates the initiating user’s credentials to the source host and is generally appropriate only when migration is initiated directly from that host. Kerberos supports remote management workflows but requires correctly configured constrained delegation for the source host to use the destination migration service. Configure the delegation target SPNs and service class according to Microsoft’s current setup guide; do not grant unconstrained delegation as a shortcut.

Pay special attention to Windows Server 2025. Microsoft’s current documentation states that after upgrading to Windows Server 2025, CredSSP-based Hyper-V live migration cannot be used because Credential Guard is enabled by default on domain-joined servers that are not domain controllers. Use the documented Kerberos constrained-delegation workflow and test it before the upgrade or cutover. Do not rely on an old runbook that selects CredSSP by default for Server 2025.

Check that the source and destination computer accounts are in the expected domain, secure channels are healthy, SPNs resolve uniquely, and the chosen delegation model matches how operators initiate the move. For a remote management console, the “double hop” can make CredSSP appear to work locally but fail remotely. Kerberos delegation is security-sensitive: constrain it to the specific migration service on approved destination hosts and review the account settings after host additions or renames.

Validate migration networking and performance

Choose whether migration traffic may use any available network or is limited to designated networks. Microsoft’s guidance recommends isolating live-migration traffic on trusted, private networks because the migration data is not encrypted in transit. Use a physically isolated network or a trusted network segmentation technology, restrict host-to-host communication, and monitor throughput. Do not assume that a VLAN alone is a complete confidentiality control.

For SMB-based migration, validate SMB bandwidth, signing/encryption requirements, NIC capabilities, and network policy on both hosts. SMB Multichannel or RDMA may improve throughput only when the hardware, drivers, switch fabric, and configuration support it. Test under representative load. Set migration concurrency to fit host CPU, memory, and network capacity; more simultaneous moves can slow all moves and affect production workloads.

Estimate the transfer time for memory and storage based on measured throughput and change rate, not link speed alone. A high write workload can dirty memory pages faster than they can be copied, prolonging migration or preventing convergence. Consider scheduling heavy write workloads separately, using an approved performance option, and monitoring source and destination resources. Keep application-level health checks running during the move; a completed hypervisor task is not proof that the guest application recovered.

Execute a canary move and observe the transaction

Before a critical workload, move a representative low-risk VM with the same network and storage pattern. Record the initiating account and host, exact PowerShell or UI workflow, start/end timestamps, task status, bytes transferred, VM state, event logs, and guest application checks. Verify DNS registration and network reachability from the intended client segments after the move. Confirm backups and monitoring still target the VM regardless of host location.

For a planned PowerShell migration, use the supported Hyper-V cmdlet for the topology and include an explicit destination. For example, an operator on the source host can start a move to an authorized destination:

Move-VM -Name 'AppVM01' `
    -ComputerName 'HV01.contoso.com' `
    -DestinationHost 'HV02.contoso.com'

This is a state-changing example, not a generic command to run without a change window. Confirm the cmdlet parameter set for the installed Hyper-V module and use the cluster’s supported role-migration interface for clustered VMs. For storage migration, specify the documented storage destination and validate the path and capacity first. Do not combine host migration, storage relocation, virtual switch changes, and identity changes in one opaque operation unless the plan explicitly tests all of them.

Observe Hyper-V VMMS operational events on both hosts and correlate them with System, FailoverClustering, SMBClient/SMBServer, and security logs as applicable. Preserve full error text and status codes. If the move fails, determine whether it failed before authentication, during VM state transfer, while accessing storage, or after destination registration. A generic “credentials not available” error points toward authentication and delegation evidence; a timeout points toward network path, firewall, performance, or resource evidence. Avoid repeating the move until you know whether a partial operation or destination registration remains.

Diagnose common migration failures

For authentication errors, compare the configured authentication type on both hosts, delegation configuration, initiating account, host SPNs, and whether the move was initiated remotely. Check Secure Channel, DNS, time, Credential Guard, and the relevant Kerberos events. On Server 2025, replace CredSSP assumptions with the documented Kerberos path. Do not disable Credential Guard or loosen domain-wide policy simply to make one migration pass.

For network failures, validate the migration network selection, routes, firewall rules, DNS names, and TCP connectivity from source to destination. A successful ping is not proof that the Hyper-V migration service path is available. Inspect firewall logs and packet traces narrowly around the failure. Verify that selected migration networks are not carrying guest traffic unexpectedly and that network adapters are not overloaded by backup or storage workloads.

For storage or VM configuration failures, compare the source VM’s paths, configuration version, processor compatibility, checkpoints, and destination free space. Check that destination storage is accessible with correct ACLs and has no stale files from an earlier failed attempt. Never delete a destination VM folder solely because a migration reported failure; first identify whether files are still referenced by the source, a replica, backup job, or cluster role.

For performance failures, collect throughput, CPU, memory, disk latency, dirty-page rate, and concurrent migration counts. A “slow” migration may be correct but underprovisioned, while a guest outage after a quick migration may point to a network mismatch. Compare the same VM under a controlled low-load test and change one variable at a time. Keep application transaction health as the final success measure.

Acceptance, rollback, and lifecycle

Acceptance requires a completed VM move; expected destination host and storage; matching virtual network, VLAN, and security policy; successful guest and application probes; working backup, monitoring, and management; no unexplained Hyper-V or cluster errors; and documented owner signoff. Retain a rollback path to the prior host or a separately approved recovery workflow. Do not treat a live-migration rollback as equivalent to failover from a Hyper-V Replica recovery point.

Revisit host compatibility, delegation, network isolation, and capacity after Windows Server upgrades, host renames, domain policy changes, NIC replacement, virtual switch redesign, certificate or Kerberos changes, and changes to backup or storage. Keep a tested Server 2025 migration procedure and update older CredSSP-based documentation. Include the exact host pair, authentication method, VM workload class, measured migration time, validation results, and rollback conditions in the operational record.

Related:

Sources: