How to Configure Hyper-V Generation 2 Virtual Machines on Windows Server 2022

Introduction to Hyper-V Live Migration

Live Migration is one of Hyper-V’s most important features for high availability and workload management. It allows a running virtual machine to be moved from one Hyper-V host to another with no downtime — users connected to services inside the VM experience only a very brief pause (typically less than a second) while the final memory pages are transferred. Windows Server 2022 Hyper-V supports several live migration configurations: clustered migration using Windows Server Failover Clustering with shared storage, and shared-nothing live migration between standalone hosts using no shared storage at all. This guide covers both scenarios, authentication configuration, performance options, and troubleshooting common migration failures.

Live Migration Prerequisites

Before configuring live migration, both the source and destination Hyper-V hosts must meet a set of prerequisites. The most fundamental requirement is processor compatibility — both hosts must have processors from the same manufacturer (Intel or AMD) and ideally the same processor family. Hyper-V uses processor compatibility mode to partially abstract CPU feature differences between hosts, but the processors must still share a compatible instruction set. Enable processor compatibility mode on a VM to expand its migration compatibility:

Set-VMProcessor -VMName "WebServer01" -CompatibilityForMigrationEnabled $true

Both hosts must be running the same version of Windows Server (or a supported version combination — migration from Server 2019 to 2022 is supported, but not the reverse). Both hosts must be members of the same Active Directory domain, or in domains with a trust relationship, when using Kerberos authentication. For non-domain or cross-domain scenarios, CredSSP authentication is available as an alternative, though it has different security implications.

The hosts must have network connectivity on the network interface designated for live migration traffic. In production environments, it is strongly recommended to use a dedicated high-bandwidth, low-latency network for live migration to avoid impacting VM workload traffic during migrations. A 10 GbE or faster dedicated migration network is recommended for VMs with large memory allocations.

Enabling Live Migration on Standalone Hosts

For shared-nothing live migration between standalone (non-clustered) Hyper-V hosts, configure each host using Set-VMHost. Run these commands on both the source and destination hosts:

Set-VMHost -VirtualMachineMigrationEnabled $true `
           -VirtualMachineMigrationAuthenticationType Kerberos `
           -VirtualMachineMigrationPerformanceOption SMBTransport

Verify the live migration settings are applied:

Get-VMHost | Select-Object Name, VirtualMachineMigrationEnabled, `
             VirtualMachineMigrationAuthenticationType, `
             VirtualMachineMigrationPerformanceOption, `
             MaximumVirtualMachineMigrations

To limit the number of simultaneous live migrations (default is 2, maximum is 10), configure the host setting:

Set-VMHost -MaximumVirtualMachineMigrations 4

Also specify which network interfaces the host should use for live migration traffic. This prevents live migration from consuming bandwidth on the management or VM networks:

Set-VMHost -VirtualMachineMigrationEnabled $true
Add-VMMigrationNetwork -Server "HYPERV-HOST01" -Subnet "10.10.50.0/24" -Priority 1

List configured migration networks:

Get-VMMigrationNetwork

Authentication Types: Kerberos vs CredSSP

Kerberos authentication is the preferred method for live migration in domain-joined environments. It uses the machine accounts of both Hyper-V hosts to authenticate the migration connection, meaning no explicit credential delegation is required and the connection is encrypted end-to-end. For Kerberos to work, you must configure constrained delegation in Active Directory, authorising each host’s computer account to delegate credentials to the CIFS and Microsoft Virtual System Migration Service on the other host. This delegation is configured through the computer account properties in Active Directory Users and Computers, or with PowerShell on a domain controller:

# Run on a Domain Controller
$sourceHost = Get-ADComputer -Identity "HYPERV-HOST01"
$destHost = Get-ADComputer -Identity "HYPERV-HOST02"

Set-ADComputer $sourceHost -Add @{
    'msDS-AllowedToDelegateTo' = @(
        "cifs/$($destHost.DNSHostName)",
        "Microsoft Virtual System Migration Service/$($destHost.DNSHostName)"
    )
}

Set-ADComputer $destHost -Add @{
    'msDS-AllowedToDelegateTo' = @(
        "cifs/$($sourceHost.DNSHostName)",
        "Microsoft Virtual System Migration Service/$($sourceHost.DNSHostName)"
    )
}

Also enable the “Trust this computer for delegation to specified services only – Use Kerberos only” option in the computer account Delegation tab in ADUC.

CredSSP authentication delegates credentials from the console session of the source host to the destination host. It does not require Active Directory delegation configuration, making it simpler to set up. However, CredSSP requires you to be logged on locally (or via RDP) to the source host to initiate the migration — you cannot perform CredSSP-based live migration from a remote management console. Configure CredSSP authentication:

Set-VMHost -VirtualMachineMigrationAuthenticationType CredSSP

Performance Options for Live Migration

Windows Server 2022 Hyper-V provides four performance options that control how VM memory is transferred during live migration. The option is configured at the host level and applies to all migrations from that host:

TCP/IP transport is the baseline option. It transfers VM memory over a standard TCP connection. It works over any network but offers the lowest throughput and highest latency compared to newer options:

Set-VMHost -VirtualMachineMigrationPerformanceOption TCPIP

Compression compresses VM memory pages in software before transmitting them over TCP. This reduces the amount of data transferred, which is beneficial when the migration network is slower than 10 GbE or is shared with other traffic. Compression uses CPU cycles on the source host:

Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

SMB transport uses SMB Direct (RDMA) when the network adapters support Remote Direct Memory Access (RDMA), such as iWARP or RoCE adapters. SMB Direct transfers VM memory at near line rate with minimal CPU overhead by having the network adapter DMA memory directly without OS involvement. This is the highest-performance option and is the default recommendation for 10 GbE and faster networks with RDMA capability:

Set-VMHost -VirtualMachineMigrationPerformanceOption SMBTransport

Even without RDMA adapters, SMB transport performs well on fast Ethernet because it leverages SMB Multichannel to use multiple network paths simultaneously if multiple migration-capable adapters are available.

Performing a Live Migration

With live migration configured on both hosts, move a running VM from the current host to a destination host. The simplest command migrates both the VM state and its storage to the destination host’s default paths:

Move-VM -Name "WebServer01" -DestinationHost "HYPERV-HOST02"

To specify exact destination paths for the VM configuration and VHDX files:

Move-VM -Name "WebServer01" `
        -DestinationHost "HYPERV-HOST02" `
        -DestinationStoragePath "D:HyperVVMsWebServer01"

When the source and destination hosts share access to the same storage (SAN, SMB file share, or CSV in a cluster), you can perform a live migration of just the VM compute without copying the storage, making it much faster:

Move-VM -Name "WebServer01" -DestinationHost "HYPERV-HOST02" -IncludeStorage:$false

Monitor the migration progress:

while ((Get-VM -Name "WebServer01").Status -eq "Migrating") {
    $vm = Get-VM -Name "WebServer01"
    Write-Host "Migration progress: $($vm.OperationMode) - Status: $($vm.Status)"
    Start-Sleep -Seconds 2
}

Storage Live Migration

Storage live migration moves the VHDX files of a running VM from one storage location to another without downtime, even when the VM is not being moved to a different host. This is useful for rebalancing storage load, evacuating a failing disk, or moving VM storage to faster media. Migrate all storage for a VM to a new path on the same host:

Move-VMStorage -VMName "WebServer01" -DestinationStoragePath "E:FastStorageWebServer01"

Move a specific VHD to a different path while leaving others in place:

$vhd = Get-VMHardDiskDrive -VMName "WebServer01" -ControllerType SCSI -ControllerNumber 0 -ControllerLocation 0
Move-VMStorage -VMName "WebServer01" -Vhds @(@{SourceFilePath=$vhd.Path; DestinationFilePath="E:FastStorageWebServer01OS.vhdx"})

Shared-Nothing Live Migration

Shared-nothing live migration is the capability to live migrate a VM between two hosts that have no shared storage whatsoever. Both the VM memory and the VHDX files are migrated simultaneously: memory pages are iteratively copied while the VM continues running (dirty pages are re-sent in subsequent rounds), and the VHDX is copied in the background over the migration network. The VM is only briefly paused when the final memory delta is transferred. This makes it possible to migrate VMs between physically separate locations as long as there is sufficient network bandwidth for both memory and storage transfer. The command syntax is the same as a standard Move-VM with a destination storage path specified — Hyper-V automatically detects there is no shared storage and performs the copy:

Move-VM -Name "WebServer01" `
        -DestinationHost "HYPERV-HOST02" `
        -DestinationStoragePath "D:HyperVVMsWebServer01" `
        -Verbose

Live Migration in a Failover Cluster

When Hyper-V hosts are members of a Windows Server Failover Cluster with shared storage (SAN LUNs or Scale-Out File Server), live migration occurs within the cluster context. The cluster manages resource ownership and the live migration is triggered either manually through Failover Cluster Manager or automatically during drain operations. Initiate a live migration within a cluster using the Failover Cluster PowerShell module:

Move-ClusterVirtualMachineRole -Name "WebServer01" -Node "HYPERV-HOST02"

To drain all VMs from a cluster node (for patching or maintenance), put the node into maintenance mode:

Suspend-ClusterNode -Name "HYPERV-HOST01" -Drain -ForceDrain

Resume the node and allow VMs to be migrated back:

Resume-ClusterNode -Name "HYPERV-HOST01" -Failback Immediate

Troubleshooting Live Migration Failures

Live migration failures typically fall into four categories: authentication failures, network connectivity problems, insufficient resources on the destination, and storage access issues. Check the Hyper-V event logs on both source and destination hosts:

Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-VMMS/Admin" -MaxEvents 30 | 
    Where-Object { $_.LevelDisplayName -eq "Error" -or $_.LevelDisplayName -eq "Warning" } |
    Select-Object TimeCreated, Id, Message

For Kerberos authentication failures, verify that constrained delegation is correctly configured. The error “Virtual machine migration operation failed at migration source” combined with event ID 21111 typically indicates a delegation issue. Test credential delegation by running a remote command from the source host to the destination using the machine account context:

Invoke-Command -ComputerName "HYPERV-HOST02" -ScriptBlock { Get-VMHost } -Authentication Kerberos

For network connectivity issues, verify the migration network is reachable and that the Windows Firewall rules for Hyper-V migration are enabled on both hosts:

Get-NetFirewallRule -DisplayGroup "Hyper-V" | Where-Object Enabled -eq True | Select-Object Name, DisplayName, Direction

If the destination host has insufficient memory, the migration will fail with a resource unavailability error. Check available memory on the destination:

Invoke-Command -ComputerName "HYPERV-HOST02" -ScriptBlock {
    Get-VM | Measure-Object -Property MemoryAssigned -Sum
    Get-WmiObject Win32_OperatingSystem | Select-Object FreePhysicalMemory, TotalVisibleMemorySize
}

Conclusion

Hyper-V Live Migration on Windows Server 2022 provides a robust mechanism for moving workloads between hosts with no service interruption, supporting both clustered and standalone deployment models. Configuring Kerberos constrained delegation correctly, choosing the right performance option for your network infrastructure, and understanding the difference between storage migration and shared-nothing live migration are the key skills needed to operate live migration effectively in production. Combined with the Failover Cluster integration for automated failover and drain operations, live migration makes Windows Server 2022 Hyper-V a competitive enterprise virtualisation platform.