Helpdesk: "Since we added the two new hosts last week, moving VMs to them fails. Hyper-V Manager says the migration operation failed at migration source, and the cluster logged Event 21502. One VM moves fine, three don't, and one we moved last month won't go back to the old host either. A forum post says to turn on processor compatibility for every VM, switch every host to CredSSP, allow live migration on any network, and turn off the firewall on the new hosts. Can we do that?"
Not yet. "Hyper-V live migration failed" is almost never one setting. Event 21502 is the summary Hyper-V logs when a live migration fails (you'll see it most on clustered hosts), and the reason is in the message text under it: a virtual switch name that doesn't exist on the destination, processor features the destination can't offer, a configuration version it doesn't support, migration settings that don't match, an authentication path that can't delegate, a connection to TCP 6600 that never opens, or a destination that can't hold the VM (memory, storage path, ISO, owners). Microsoft says it directly: "live migration can fail due to a wide array of factors", and its troubleshooting page lists about twenty different messages under the single heading Event ID 21502. Turning on processor compatibility for every VM hides CPU features from workloads that didn't need it (and needs each VM shut down), switching to CredSSP trades a delegation problem for a sign-in problem (and stops working on Windows Server 2025 with Credential Guard), any-network migration sends unencrypted VM memory over networks you didn't choose, and turning off the host firewall proves nothing about why the listener on 6600 isn't answering. Work through it as a chain: which VM, which hosts, which inner message → what does the full error say on both hosts? → what does Compare-VM report? → do the virtual switches, adapters, and attached media exist on the destination? → can the destination offer the VM's processor features? → does the destination support the VM's configuration version? → are migration settings and networks the same on both sides? → can the source authenticate to the destination? → does TCP 6600 connect? → can the destination hold the VM? Get-WinEvent on the Hyper-V logs of both hosts, Compare-VM, Get-VMNetworkAdapter, Get-VMSwitch, Get-VMProcessor, Get-VM, Get-VMHostSupportedVersion, Get-VMHost, Get-VMMigrationNetwork, Get-ADComputer, Test-NetConnection, and the failover cluster cmdlets are the sources for that chain. Change processor compatibility, authentication, and networks at once and you'll never know which one was broken.
If the inner message is "The target principal name is incorrect", The Target Principal Name Is Incorrect covers the Kerberos side of that error. If the VM won't move because a checkpoint or its AVHDX chain is broken, Hyper-V Checkpoint Operation Failed covers that side. This post covers "a running Hyper-V VM won't live migrate between Windows Server hosts, clustered or not: Event 21502 in the cluster, 'failed at migration source' or 'failed at migration destination' in Hyper-V Manager, a processor or hardware compatibility error, a failed-to-authenticate or no-credentials error, a failed-to-establish-a-connection error, or a failure that happens one way only, and you need a read-first path before you change processor compatibility, authentication, migration networks, or firewall rules."
TL;DR
-
Event 21502 is the envelope, not the letter. Read the inner message and its hex code on both hosts before you change anything (Step 2). Microsoft's first check is a compatibility report: run
Compare-VMagainst the destination (Step 3). - Switch names must match exactly. Microsoft: "The virtual switch must have the same name on all nodes." (Step 4).
- Processor compatibility is per VM, needs the VM off, and has limits. "Even when processor compatibility is enabled, you can't move VMs between hosts with different processor manufacturers." (Step 5).
- One way only usually means version. A VM upgraded on a newer host can't go back: "This action can't be rolled back." (Step 6).
- Authentication is a choice with consequences. "Kerberos lets you avoid signing in to the server, but requires you to set up constrained delegation." CredSSP needs a sign-in on the source and breaks with Credential Guard on Windows Server 2025 (Step 8).
- Read the listener before the firewall. Microsoft's checklist: "Check whether the TCP Port 6600 and 3343 (for clustering) are listening on both sides." (Step 9).
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which VM, which source and destination, clustered or not, started from where, the full message, since when | "Live migration is broken" with no VM, host pair, or time written down |
| 2. Full error read | The inner message and hex code are known, on both the source and the destination | Event 21502 quoted alone; the actual reason never read |
| 3. Compatibility report |
Compare-VM from the source against the destination returns no incompatibilities |
The report names a missing switch, a processor, or a version the destination can't take |
| 4. Switches and media | Every switch the VM uses exists with the same name on the destination; attached ISOs are reachable there | Fails at less than 10%; a switch that "doesn't exist on the destination node"; an ISO or virtual disk provider error |
| 5. Processor | The destination offers the processor features the running VM was started with | "processor-specific features not supported"; "hardware on the destination computer isn't compatible" |
| 6. Configuration version | The destination supports the VM's configuration version | Moves one way, fails the other; Event 10698 with 21502 |
| 7. Settings and networks | Migration enabled, same authentication protocol, a reachable migration network on both sides, limits not hit | Event 21501 (limit reached); traffic on the wrong network; 0x000013AB in a cluster |
| 8. Authentication | CredSSP with a sign-in on the source, or Kerberos with constrained delegation both ways | 0x8009030E "No credentials are available"; 0x8009030D; 0x80090322 |
| 9. Connection | The destination's listener on TCP 6600 answers the source (and 3343 between cluster nodes) | 0x8007274D refused; 0x8007274C timed out; 0x8007271D access forbidden; listener disabled |
| 10. Destination capacity | Enough memory, a writable storage path, the right possible owners, no leftover state | 0x800705AA or 0x8007000E memory; Event 20413 path; 0x80071398 owner; folder errors |
| 11. Change | Only after Steps 1-10 agree: one link, one change | Every VM in compatibility mode, every host on CredSSP, same failure |
Step 1: Capture the symptom (read-only)
Write these on the ticket first:
| Fact | Why it matters |
|---|---|
| Which VM, and how many | One VM, every VM to one host, or every VM everywhere. One VM points at its own settings (Steps 4-6); one destination points at that host (Steps 4, 7, 9, 10) |
| Source and destination host | Exact names, Windows Server version and build of each, CPU vendor and generation of each. Different versions point at Step 6; different CPUs at Step 5 |
| Clustered or not | A clustered VM moved in Failover Cluster Manager, a standalone move in Hyper-V Manager, a Move-VM, or System Center Virtual Machine Manager. The settings that apply differ (Step 7) |
| Started from where | Signed in on the source host, on the destination, or from a management server or jump box. With CredSSP it matters a lot (Step 8) |
| Full message and percentage | The inner lines, the hex code, and roughly how far it got. Microsoft ties "fails at < 10%" to a missing switch and "90%~100%" to a path problem (Steps 4 and 10) |
| Since when, and what changed | New hosts, a Windows Server upgrade, BIOS or firmware updates, a VM configuration upgrade, a new switch, a GPO or security baseline, an AD delegation change |
| Time of one failing attempt | So you can match it to events on both hosts and in the cluster log (Step 2) |
Then branch on what you see:
| What you see | What it usually means (our reading unless noted) | Start at |
|---|---|---|
| a virtual switch that "doesn't exist on the destination node", or failure under 10% | The switch name differs on the destination (Microsoft's 21502 entry) | Step 4 |
| "processor-specific features not supported" or "hardware on the destination computer isn't compatible" | CPU features, BIOS settings, or microcode differ between hosts | Step 5 |
| Works one way, fails coming back | The VM's configuration version was upgraded on the newer host | Step 6 |
| "please wait for completion of an ongoing migration operation" (Event 21501) | Too many simultaneous migrations for the current limit | Step 7 |
| 0x8009030E "No credentials are available in the security package" | CredSSP without a sign-in on the source, or Kerberos delegation missing or blocked | Step 8 |
| 0x80090322 "The target principal name is incorrect" | Kerberos reached the wrong host or name; Microsoft's example is a cross-cluster move on the wrong network | Steps 7 and 8 |
| 0x8007274D, 0x8007274C, 0x80072746, or 0x8007271D | The connection to TCP 6600: refused, timed out, reset, or blocked | Step 9 |
| "disabled the listener for Virtual Machine migration connections" | Group Policy processing on the destination failed | Step 9 |
| 0x800705AA, 0x8007000E, 0x80071398, Event 20413, or a folder error | The destination can't hold the VM, can't own it, or can't reach its path | Step 10 |
Step 2: Read the full error on both hosts (read-only)
Event 21502 is a summary. The reason is in the lines under it, and often in a second event on the other host. Microsoft's own list for Event ID 21502 runs from a missing virtual switch to processor features, Kerberos errors, memory, ISO files, and storage oplocks, and in Failover Cluster Manager it points you to the VM's Information details > Show details for the full text.
Find the Hyper-V and clustering logs that have events on each host, then pull the migration events around the failed attempt from both the source and the destination:
# On the source and on the destination: which Hyper-V and cluster logs have events here
Get-WinEvent -ListLog '*Hyper-V*', '*FailoverClustering*' -ErrorAction SilentlyContinue |
Where-Object { $_.RecordCount -gt 0 } |
Sort-Object LogName |
Format-Table LogName, RecordCount -AutoSize
# The migration events from the last hour, oldest first, with the full message text
$logs = (Get-WinEvent -ListLog '*Hyper-V*' -ErrorAction SilentlyContinue |
Where-Object { $_.RecordCount -gt 0 }).LogName
Get-WinEvent -FilterHashtable @{
LogName = $logs
Id = 21502, 21501, 21125, 21024, 20413, 20417, 10698
StartTime = (Get-Date).AddHours(-1)
} -ErrorAction SilentlyContinue |
Sort-Object TimeCreated |
Format-List TimeCreated, MachineName, LogName, Id, Message
The event IDs in that filter are the ones Microsoft's live migration troubleshooting pages describe: 21502 (the failure itself), 21501 (migration limit), 21125 (configuration setup failed on the destination), 21024 (lost network after migration), 20413 (configuration registration failed on the destination), 20417 (long blackout time), and 10698 (listed with 21502 for configuration version problems). Widen the time window or drop the Id filter if nothing comes back; the inner error is often logged under a different ID on the other host. Microsoft's data collection list also names the worker log ("Microsoft-Windows-Hyper-V-Worker-Admin") and, for clusters, Get-ClusterLog -UseLocalTime -Destination <Path>:
# Clustered hosts only: write the cluster log for every node, in local time, to one folder
Get-ClusterLog -UseLocalTime -Destination C:\Temp\ClusterLogs
Read the hex code first. Microsoft's 21502 entries map them like this:
| Code or text in the message | Microsoft's meaning | Start at |
|---|---|---|
| "a virtual switch used by the VM doesn't exist on the destination node" | Switch name missing or different on the destination | Step 4 |
| 0xC03A0014 "A virtual disk support provider for the specified file was not found." | An attached ISO the destination can't open | Step 4 |
| "processor-specific features not supported on host" | CPU features differ | Step 5 |
| "The hardware on the destination computer isn't compatible with the hardware requirements of this virtual machine" | Processor compatibility off, or microcode differs | Step 5 |
| "please wait for completion of an ongoing migration operation" (Event 21501) | Simultaneous migration limit | Step 7 |
| 0x000013AB "A cluster Network isn't available for this operation." | No usable cluster network for the move | Step 7 |
| 0x8009030E "No credentials are available in the security package" | No credentials to delegate | Step 8 |
| 0x8009030D "The credentials supplied to the package were not recognized" | Source can't authenticate to the destination | Step 8 |
| 0x80090322 "The target principal name is incorrect." | Wrong host or network for Kerberos; cross-cluster network order | Steps 7 and 8 |
| 0x8007274D, 0x80072746, 0x8007274C | Connection refused, reset, or timed out | Step 9 |
| 0x8007271D "An attempt was made to access a socket in a way forbidden by its access permissions." | Firewall or antivirus | Step 9 |
| "The Virtual Machine Management Service disabled the listener for Virtual Machine migration connections." | Group Policy failure on the host | Step 9 |
| 0x800705AA, 0x8007000E | Not enough memory on the destination | Step 10 |
| 0x80071398 "the specified cluster node isn't the owner of the group, or the node isn't a possible owner of the group" | Possible owners don't include the destination | Step 10 |
| 0x80070569 "Logon failure: the user has not been granted the requested logon type at this computer." | User rights for the virtual machine accounts | Step 10 |
Step 3: What does Compare-VM report? (read-only)
Microsoft's basic checklist says to "Check compatibilities issues by running a Compare-VM command." The cmdlet doesn't move anything: "The Compare-VM cmdlet compares a virtual machine and a virtual machine host for compatibility, returning a compatibility report." Run it on the source host, against the destination, for the VM that failed:
# On the source host: compare the running VM with the destination host
$report = Compare-VM -Name APP01 -DestinationHost HV02
# Each incompatibility has a message, an ID, and the object it came from
$report.Incompatibilities | Format-Table Message, MessageId, Source -AutoSize -Wrap
# If the move includes storage, compare that move instead
$report = Compare-VM -Name APP01 -DestinationHost HV02 -IncludeStorage -DestinationStoragePath D:\VMs\APP01
$report.Incompatibilities | Format-Table Message, MessageId, Source -AutoSize -Wrap
Message, MessageId, and Source are the columns Microsoft's own Compare-VM example shows, where the report says "Could not find Ethernet switch 'Production'." for a VM whose adapter used a switch the host didn't have. An empty Incompatibilities list means the destination can take the VM's configuration, so look at Steps 7-10 (settings, authentication, connection, capacity). A non-empty list usually tells you which of Steps 4-6 to read next (our reading). If Compare-VM itself fails with a credentials or connection error, that's the same problem the migration has: go to Steps 8 and 9.
Step 4: Do the switches, adapters, and attached media exist on the destination? (read-only)
The first entry under Event ID 21502 on Microsoft's live migration page is a switch: "Live migration of VM failed. VM failed to live migrate because a virtual switch used by the VM doesn't exist on the destination node". The action is short: "The virtual switch must have the same name on all nodes." Microsoft also notes "If a virtual machine is connected to a virtual switch that doesn't exist on the destination node, then live migration fails at < 10%."
# On the source: which switch each of the VM's adapters uses
Get-VMNetworkAdapter -VMName APP01 | Format-Table VMName, Name, SwitchName -AutoSize
# On both hosts: the switches that exist, by exact name and type
Get-VMSwitch | Sort-Object Name | Format-Table Name, SwitchType -AutoSize
Get-VMSwitch -ComputerName HV02 | Sort-Object Name | Format-Table Name, SwitchType -AutoSize
# On the source: anything attached to the VM's DVD drives
Get-VMDvdDrive -VMName APP01 | Format-Table VMName, ControllerType, ControllerNumber, Path -AutoSize
What to look for:
| Finding | What it means (our reading unless noted) |
|---|---|
A SwitchName on the source that isn't in the destination's list |
The cause Microsoft lists first; names must match exactly |
Same name, different SwitchType
|
The name matches but it's Internal or Private on one side and External on the other; the VM loses its network or the cluster check fails |
| Adapter on an Internal or Private switch, VM clustered | Microsoft: "You can't live migrate a VM across nodes in a cluster if that VM is connected to an internal or private virtual switch." The message says "the destination has disconnected VM switch(s)" |
A Path to an ISO on a local disk or a share the destination can't read |
Microsoft's 0xC03A0014 entry: an ISO the destination can't open fails the move; the fix is to set the DVD drive to None |
| Event 21125 "Configuration setup for live migration failed on the destination node." | The same switch problem seen from the destination; Microsoft's action is to make the virtual network names match and refresh the VM configuration in Failover Cluster Manager |
| Event 21024 after a successful move | The move worked but the VM lost its network: different subnets or VLANs on the destination switch, not a migration failure |
In a cluster, after you rename or create a switch, Microsoft's steps end with Failover Cluster Manager > the VM role > More Actions > Refresh virtual machine configuration before you retry. That refresh is a change (Step 11), not a check.
Microsoft's broader checklist adds team consistency: "Validate network teaming (SET or LBFO) consistency." A switch with the right name bound to a team with a different configuration is worth a second look (our reading).
Step 5: Can the destination offer the VM's processor features? (read-only)
A running VM sees the features of the host it started on. Microsoft explains why that blocks a move: "If software in the VM detects and starts using a particular processor capability, and then the VM is moved to a new virtualization host without that capability, the software can fail." So "Hyper-V performs initial checks whenever a VM live migration or save/restore operation is initiated", and "If these feature sets don't match, the migration or restore operation is canceled."
# On the source: is processor compatibility turned on for this VM, and in which mode
Get-VMProcessor -VMName APP01 | Format-List VMName, Count, CompatibilityFor*
# Same check for every VM on the host
Get-VM | Get-VMProcessor | Format-Table VMName, Count, CompatibilityForMigrationEnabled -AutoSize
# Does the VM have checkpoints (Microsoft ties this to the hardware-not-compatible error)
Get-VMSnapshot -VMName APP01 | Format-Table VMName, Name, SnapshotType -AutoSize
Read the result against the messages:
| Finding | What it means |
|---|---|
CompatibilityForMigrationEnabled False, hosts with different CPU generations |
Expected failure. Microsoft: "If a virtual machine doesn't have processor compatibility turned on and has one or more snapshots, the move fails if the hosts have different processor versions." |
| Compatibility True, still "processor-specific features not supported" | Microsoft's checks: "Make sure the BIOS of the host has the same settings." and "Run the Get-SpeculationControlSettings cmdlet and check the results. It should be the same on all nodes." |
| Intel source, AMD destination (or the reverse) | No setting fixes it: "Even when processor compatibility is enabled, you can't move VMs between hosts with different processor manufacturers." Shut down and move, or rebuild on the other platform |
| New hosts got a microcode or firmware update the old ones didn't | Microsoft's guidance for side channel mitigations: "the best option is to live migrate VMs only from old to new microcode (uCode) revisions" |
Windows Server 2025 cluster, CompatibilityForMigrationMode shown |
Dynamic processor compatibility (CommonClusterFeatureSet) needs configuration version 10.0 or later; MinimumFeatureSet is the standard mode Microsoft says to use toward older processors outside the cluster |
Two rules from Microsoft keep this from turning into a fleet-wide change. First, "You don't need to enable processor compatibility mode if you plan to stop and restart the VMs", because the guest reads the new host's features at boot. Second, "Processor compatibility mode can't be enabled or disabled while the VM is running." So for a running VM that has to move now, the choice is a short shutdown either way; the guide's tip is "Always start VMs for the first time on the oldest (least capable) CPU host." The CompatibilityFor* wildcard is our form; it shows CompatibilityForMigrationMode only where the host's Hyper-V module has it.
Step 6: Does the destination support the VM's configuration version? (read-only)
Microsoft's troubleshooting guide describes the pattern exactly: "Migration works one way but not in reverse (especially after moving to a newer OS)." with Event IDs 10698 and 21502. The VM's configuration version decides which hosts can run it:
# On the source: configuration version of every VM (Microsoft's form)
Get-VM * | Format-Table Name, Version
# On the destination: which configuration versions it can run, and its default
Get-VMHostSupportedVersion -ComputerName HV02
Get-VMHostSupportedVersion -ComputerName HV02 -Default
# On the source: integration services that report a version mismatch
Get-VMIntegrationService -VMName APP01 |
Format-Table VMName, Name, SecondaryOperationalStatus -AutoSize
| Finding | What it means |
|---|---|
The VM's Version isn't in the destination's Get-VMHostSupportedVersion list |
The destination is an older Windows Server than the version needs. You can't fix this from the VM side; move it to a host that supports it |
| Same version on both lists, moves one way only | Look at Steps 5 and 7-9 instead; the version isn't the blocker (our reading) |
SecondaryOperationalStatus ProtocolMismatch |
Out-of-date integration services; Microsoft's checklist says to "Confirm VM integration services are up-to-date." |
Don't upgrade a VM's configuration version to make a mixed-version move work. Microsoft's guidance is not to upgrade until "You upgrade your Hyper-V hosts to the latest version of Windows or Windows Server.", "You upgrade the cluster functional level.", and "You're sure that you won't need to move the virtual machine back to a Hyper-V host that runs a previous version of Windows or Windows Server." The troubleshooting guide adds: "This action can't be rolled back. VMs with the upgraded version can't be migrated back to older hosts." During a rolling upgrade, keep VMs at the version the oldest host supports until the last old host is gone (our reading).
Step 7: Are migration settings and networks the same on both sides? (read-only)
Microsoft's basic checklist has two lines for this: "Check whether the migration is authorized on each side." and "Check whether the protocol used is identical on each side." Read the host settings on both hosts, then the networks each one accepts migrations on:
# On both hosts: every live migration setting (the wildcard is our form)
Get-VMHost | Format-List Name, *Migration*
Get-VMHost -ComputerName HV02 | Format-List Name, *Migration*
# Networks each host accepts incoming live migration on
Get-VMMigrationNetwork
Get-VMMigrationNetwork -ComputerName HV02
# Clustered hosts: cluster networks and their role, the cluster-wide limit,
# and which networks the Virtual Machine resource type excludes from migration
Get-ClusterNetwork | Format-Table Name, Role, Address -AutoSize
(Get-Cluster).MaximumParallelMigrations
Get-ClusterResourceType -Name "Virtual Machine" | Get-ClusterParameter -Name MigrationExcludeNetworks
What the settings mean, from Microsoft's Set-VMHost reference:
| Setting | What to compare |
|---|---|
VirtualMachineMigrationAuthenticationType |
"The acceptable values for this parameter are: Kerberos and CredSSP." Both hosts should use the same one (Step 8) |
UseAnyNetworkForMigration |
"If set to $False, incoming live migration traffic is transmitted only on the networks specified in the MigrationNetworks property of the host." The destination must list a network the source can reach |
MaximumVirtualMachineMigrations |
The per-host limit. In a cluster, the cluster property wins: Microsoft says to check it with (Get-Cluster).MaximumParallelMigrations
|
VirtualMachineMigrationPerformanceOption |
TCP/IP, Compression, or SMB. "Compression is the default setting." SMB moves memory over SMB 3.0 instead of a plain TCP stream |
Read the result:
| Finding | What it means (our reading unless noted) |
|---|---|
| Migration not enabled on the destination | Microsoft's setup step is Hyper-V Settings > Live Migrations > Enable incoming and outgoing live migrations, on each host |
| Kerberos on one host, CredSSP on the other | The source can't authenticate the way the destination expects; pick one (Step 8) |
UseAnyNetworkForMigration False and no shared subnet in Get-VMMigrationNetwork
|
The destination only accepts migrations on a network the source isn't on; the connection fails (Step 9) |
| Event 21501, "please wait for completion of an ongoing migration operation" | The limit was hit. Microsoft: "Wait to finish other live migrations or increase the number of simultaneous live migrations." |
| Cluster, 0x000013AB | Microsoft: "Make sure the cluster network is configured and Allow cluster network communication on this network is selected." A Role of 0 means "Do not allow cluster network communication" |
MigrationExcludeNetworks lists the only network both nodes share |
The cluster has nothing left to migrate over |
| Cross-cluster move, 0x80090322 | Microsoft: "Migration was cross-cluster but as per Live Migration Network order, the private Network was selected." |
| Event 20417, "unexpectedly long blackout time" | The move worked but slowly. Microsoft: "Make sure there's enough bandwidth available for the live migration." |
Microsoft's cluster network guidance sets the rule for every host involved: "All Hyper-V hosts that can initiate or receive a live migration must have connectivity to a network that is configured to allow live migrations." It also explains why "allow any network" is not a free fix: "live migration traffic isn't encrypted when sent over the network", so isolate it "onto trusted, private networks". In a cluster, "By default, live migration traffic uses the cluster network topology to discover available networks and to establish priority." The order and exclusions you set in Failover Cluster Manager (right-click Networks > Live Migration Settings) are what MigrationExcludeNetworks shows.
Step 8: Can the source authenticate to the destination? (read-only)
The source host opens the migration connection to the destination, so it needs credentials it can present there. Microsoft's setup page gives the two options and their cost: "Kerberos lets you avoid signing in to the server, but requires you to set up constrained delegation." and "CredSSP lets you avoid setting up constrained delegation, but requires you to sign in to the source server." When neither works you get this, from the same page:
Virtual machine migration operation failed at migration Source.
Failed to establish a connection with host computer name: No credentials are available in the security package 0x8009030E.
Read which protocol each host uses, what each host may delegate to in AD, and what the account starting the move allows:
# Which protocol each host uses for live migration
Get-VMHost -ComputerName HV01, HV02 |
Format-Table Name, VirtualMachineMigrationAuthenticationType -AutoSize
# Kerberos: what each host may delegate to (Microsoft's blog form; run for both hosts)
Get-ADComputer -Identity HV01 -Properties msDS-AllowedToDelegateTo |
Select-Object -ExpandProperty msDS-AllowedToDelegateTo
Get-ADComputer -Identity HV02 -Properties msDS-AllowedToDelegateTo |
Select-Object -ExpandProperty msDS-AllowedToDelegateTo
# Protocol transition ("Use any authentication protocol") on each host's account
Get-ADComputer -Identity HV01 -Properties TrustedToAuthForDelegation |
Format-Table Name, TrustedToAuthForDelegation -AutoSize
# The admin account that starts the move: marked sensitive, or in Protected Users?
Get-ADUser -Identity jsmith-adm -Properties AccountNotDelegated |
Format-Table Name, AccountNotDelegated -AutoSize
Get-ADGroupMember -Identity "Protected Users" | Format-Table Name, SamAccountName -AutoSize
REM SPNs registered on each host (Microsoft's data collection form)
setspn -L HV01
setspn -L HV02
Read the result:
| Finding | What it means |
|---|---|
| CredSSP, move started from a management server, Failover Cluster Manager on another node, or a remote console | Expected 0x8009030E. Microsoft: "To fix this problem, sign in to the source server and try the move again." Moving back means signing in to the other host first |
| Source host is Windows Server 2025, CredSSP | Microsoft: "Starting with Windows Server 2025, Credential Guard is enabled by default on all domain-joined servers that aren't domain controllers." and "If the source machine of a Live Migration uses CredSSP for delegation with Credential Guard enabled, the Live Migration fails." |
Kerberos, but a host's msDS-AllowedToDelegateTo lacks the other host |
Delegation is missing, or set one way only. Microsoft's steps set it on the source for the destination and then "repeat the process" on the destination for the source |
| The list has Microsoft Virtual Console Service, not Migration Service | Microsoft's blog warns "don't mix up the Microsoft Virtual System Migration Service with the Microsoft Virtual Console Service" in Active Directory Users and Computers |
| No cifs entry for the other host | Moves of the VM alone may work; moves that include storage need it: "Add cifs (required to migrate storage) and Microsoft Virtual System Migration Service (required to migrate virtual machine)." |
TrustedToAuthForDelegation False ("Use Kerberos only") |
Microsoft's blog: on Windows Server 2016 and later, live migration started from a remote system needs "Use any authentication protocol", because it uses protocol transition (paraphrased) |
The admin account has AccountNotDelegated True, or is in Protected Users |
Its credentials can't be delegated, so remotely started moves fail even with correct delegation. Microsoft: "check the setting and group membership when you troubleshoot delegation issues" |
| 0x8009030D "The credentials supplied to the package were not recognized" | Microsoft's text: "Make sure the operation is initiated on the source host of the migration, or the source host is configured to use Kerberos for the authentication of migration connections and constrained delegation is enabled for the host in active directory." |
setspn -L shows no Microsoft Virtual System Migration Service SPN |
Microsoft's guide: "Ensure the required Service Principal Names (SPNs) are registered." |
| 0x80090322 within one cluster or between standalone hosts | Kerberos got a ticket for a different machine than the one that answered: check name resolution and SPNs the way the Target Principal Name post does (our reading) |
Two timing notes. Delegation changes take effect after "The changes replicate to the domain controllers that the servers running Hyper-V are logged into." and "The domain controller issues a new Kerberos ticket." Microsoft's 0x8009030D fix says to "Wait up to 15 minutes for Keberos tickets to time out" (sic) or purge the computer's tickets (Step 11). A fix that "didn't work" five minutes after the change may simply not have reached the host yet (our reading). Microsoft's blog also confirms that Hyper-V Manager and Move-VM fail the same way, so switching tools doesn't help.
Step 9: Does TCP 6600 connect from the source to the destination? (read-only)
Microsoft's checks use TCP 6600 for the Hyper-V migration listener and 3343 for clustering. Microsoft's form of the check is netstat -ano | findstr /I /C:"6600". The same reading in PowerShell, plus a test from the source:
# On the destination: is the Hyper-V Virtual Machine Management service running and listening
Get-Service -Name vmms | Format-Table Name, Status, StartType -AutoSize
Get-NetTCPConnection -LocalPort 6600 -State Listen -ErrorAction SilentlyContinue |
Format-Table LocalAddress, LocalPort, State, OwningProcess -AutoSize
# Clustered nodes: the cluster service port
Get-NetTCPConnection -LocalPort 3343 -State Listen -ErrorAction SilentlyContinue |
Format-Table LocalAddress, LocalPort, State -AutoSize
# From the source: does 6600 answer by name and on the migration network address
Test-NetConnection -ComputerName HV02 -Port 6600
Test-NetConnection -ComputerName 192.168.10.12 -Port 6600
# On both hosts: the Hyper-V firewall rules and their state (the wildcard is our form)
Get-NetFirewallRule -DisplayName '*Hyper-V*' |
Format-Table DisplayName, Enabled, Direction, Action -AutoSize
Read the result:
| Finding | What it means |
|---|---|
| Nothing listening on 6600 on the destination | Migration isn't enabled there (Step 7), the service is stopped, or Group Policy disabled the listener |
| "The Virtual Machine Management Service disabled the listener for Virtual Machine migration connections." | Microsoft's fix starts with gpupdate /force; if that reports that "The processing of Group Policy failed", the local policy file is suspect: "The file must start with the PReg signature." The Group Policy Not Applying post covers the rest of that path |
Listening, but Test-NetConnection fails from the source |
A firewall between the hosts or on the destination. 0x8007274C means the connection attempt timed out; Microsoft also lists a corrupt Registry.pol for it |
| 0x8007274D "No connection could be made because the target machine actively refused it" | The source reached an address where nothing listens on 6600: often a different network than the one in the destination's Get-VMMigrationNetwork list (our reading) |
| 0x80072746 "An existing connection was forcibly closed by the remote host." | The connection opened and then dropped: Microsoft points to the listening ports and the cluster network metrics |
| 0x8007271D | Microsoft: "Check Firewall settings and Antivirus exclusion." Its Hyper-V antivirus guidance lists process exclusions for vmms.exe and vmwp.exe |
| Events 20406 and 280, "The client cannot connect to the destination specified in the request" | WinRM between the hosts. Microsoft: "Ensure hosts can resolve and reach each other via hostname/IP (test with ping)." and use winrm quickconfig
|
Test-NetConnection -Port tests TCP only. The listener answering by name but not on the migration address (or the reverse) is the most useful split you can get here: it tells you whether the problem is the path or the host (our reading).
Step 10: Can the destination hold the VM? (read-only)
The last group of 21502 messages is about the destination itself: memory, the storage path, cluster ownership, user rights, and leftover state.
# On the source: the VM's memory settings
Get-VMMemory -VMName APP01 | Format-List *
# On the destination: what's already running and how much memory it holds
Get-VM -ComputerName HV02 | Where-Object { $_.State -eq 'Running' } |
Format-Table Name, State, MemoryAssigned -AutoSize
# Where the VM's disks live, and whether the destination path exists
Get-VMHardDiskDrive -VMName APP01 | Format-Table VMName, ControllerType, Path -AutoSize
Invoke-Command -ComputerName HV02 -ScriptBlock { Test-Path -Path 'D:\VMs' }
# Clustered: which nodes may own the VM and its configuration (Microsoft's form)
Get-ClusterResource -Name "Virtual Machine APP01" | Get-ClusterOwnerNode
Get-ClusterResource -Name "Virtual Machine Configuration APP01" | Get-ClusterOwnerNode
Get-ClusterNode | Format-Table Name, State -AutoSize
Read the result:
| Finding | What it means |
|---|---|
| 0x800705AA "Insufficient system resources exist to complete the requested service." or 0x8007000E "Ran out of memory" | Microsoft: "Reduce the memory assigned to the virtual machine or turn off some virtual machines on the destination node." |
0x80071398, destination missing from Get-ClusterOwnerNode
|
Microsoft: "The owner node must have all cluster nodes." Check both the Virtual Machine and the Virtual Machine Configuration resource |
| Event 20413, fails at 90% to 100% | Microsoft: the nodes have different system drive letters, and the destination can't register the configuration at its path |
| Folder errors on the destination, or the path test returns False | Microsoft's checklist: "Compare permissions on the folders containing the virtual machines files with a working host with the same operating system level." Storage moves also need cifs delegation (Step 8) |
| 0x80070569 logon type not granted | Microsoft's checklist: under User Rights Assignment, Create symbolic links should list Administrators and NT VIRTUAL MACHINE\Virtual Machines, and Log on as a service should list NT SERVICE\ALL SERVICES and NT VIRTUAL MACHINE\Virtual Machines. A security baseline GPO that rewrites those lists breaks this |
| Shared VHDX attached | Microsoft: "Shared virtual disks can only be used in clustered VM roles and can't be migrated using standard methods." |
| vTPM or shielded VM, "The key protector for the virtual machine could not be unwrapped." | The destination doesn't have the key protector certificates; Microsoft's fix is to export them from the source and import them on the destination |
| Saved state that can't be read, a VM stuck in "Backing up", or a broken checkpoint chain | Fix the VM's state first; the Hyper-V Checkpoint Operation Failed post covers checkpoints and AVHDX chains |
| 0x800705B4 timeout after a node crashed | Microsoft's entry: symbolic links for the VM left on the destination; its workaround is quick migrations in both directions or a configuration version upgrade |
MemoryAssigned, Path, and the other property lists above are our forms; Microsoft's own wording for the memory case is simply "Check the available memory on the destination host."
Common false starts
| Tempting move | Why it's premature (our reading) |
|---|---|
| Turn on processor compatibility for every VM | Hides CPU features from every workload, needs each VM shut down, and doesn't help with a switch, version, authentication, or connection failure. Microsoft recommends it "only during the migration process" |
| Switch every host to CredSSP | Trades a delegation problem for a sign-in-on-the-source problem, and fails on Windows Server 2025 sources with Credential Guard |
Set UseAnyNetworkForMigration to $true |
Sends unencrypted VM memory over networks you didn't pick, and doesn't fix a listener or delegation problem |
| Turn off the host firewall | Proves nothing about a listener that isn't there, and leaves the host open while you test |
| Upgrade the VM configuration version | Can't be undone, and blocks the VM from every older host |
| Rename the switch on the source | Breaks every other VM on that host that uses the old name; match the destination to the source or both to a standard |
| Unconstrained delegation for the hosts | Wider than Hyper-V needs, and Credential Guard blocks Kerberos unconstrained delegation |
| Restart VMMS or reboot the destination | Clears the evidence (the listener state, the events) without changing the setting that caused it |
| Quick migration "because live migration is broken" | Works for some causes because it saves and restores the VM, but hides which link was broken; the next live migration fails the same way |
| Evict and re-add the cluster node | Changes ownership, networks, and possibly the cluster log you needed, before anyone read the inner error |
Step 11: Change one link, then prove it
Before any change, write down what you're about to change: the Get-VMHost migration settings, the switch list, the VM's processor and version settings, and the delegation lists from Steps 4-8. Then change only the link Steps 1-10 pointed to.
Switches and media (Step 4). Create or rename the switch on the destination so it matches the name the VM uses, with the same type and uplink, following Microsoft's resolution: "If the virtual switch doesn't exist, create or rename it with the same name and settings such as in other hosts." In a cluster, refresh the VM configuration in Failover Cluster Manager afterward. For an ISO the destination can't open, eject it:
# On the source: remove the ISO from the VM's DVD drive (Microsoft's fix is to select None)
Get-VMDvdDrive -VMName APP01 | Set-VMDvdDrive -Path $null
For a clustered VM on an Internal or Private switch, Microsoft's workaround is to clear the adapter's Protected network option, which in PowerShell is Set-VMNetworkAdapter -NotMonitoredInCluster $true for that adapter. That stops the cluster from checking that adapter's connectivity, so use it only for adapters that are meant to be host-local (our reading).
Processor (Step 5). Shut the VM down, turn on compatibility for that VM only, start it, and move it:
# Microsoft's forms; the VM must be off
Stop-VM -Name APP01
Set-VMProcessor -VMName APP01 -CompatibilityForMigrationEnabled $true
# Windows Server 2025 cluster, configuration version 10.0 or later: dynamic mode instead
# Set-VMProcessor -VMName APP01 -CompatibilityForMigrationEnabled $true -CompatibilityForMigrationMode CommonClusterFeatureSet
Start-VM -Name APP01
After the hardware refresh is done, Microsoft recommends turning it back off so the VM can use the full processor; that's another short shutdown. If BIOS settings or Get-SpeculationControlSettings results differ between hosts, fix the host that's out of line instead of masking it on every VM. Across microcode levels, move old to new.
Configuration version (Step 6). Don't downgrade; you can't. Keep the VM on hosts that support its version, or, once every host in its path runs the newer Windows Server and the cluster functional level is raised, upgrade it with Microsoft's Update-VMVersion <vmname> (VM shut down, one-way).
Settings and networks (Step 7). Enable migration on the host that's missing it, make the authentication protocol the same on both hosts, and add the shared migration network to the destination. Microsoft's PowerShell form:
# On each host that needs it (Microsoft's three-cmdlet example)
Enable-VMMigration
Set-VMMigrationNetwork 192.168.10.1
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Raise the simultaneous migration limit only if the host and the network can take it; Microsoft's note on that setting is "Consider host performance when changing this number." In a cluster, change the live migration network order in Failover Cluster Manager (Networks > Live Migration Settings) or the MigrationExcludeNetworks parameter, not each host. For a cross-cluster move that picked a private network, Microsoft's fix is "Change the Live Migration Network order for cross-cluster and change it back after the migration."
Authentication (Step 8). Prefer Kerberos with constrained delegation. With a Domain Admins account, on the source host's computer object in Active Directory Users and Computers: Delegation tab > Trust this computer for delegation to the specified services only > Use any authentication protocol > Add the destination host, and select cifs and Microsoft Virtual System Migration Service. Then repeat on the destination for the source. Set both hosts to Kerberos (Step 7 example). Then let the change take effect, either by waiting or, on each host, with Microsoft's ticket purge for the computer account's logon session:
REM Purge the host's own (SYSTEM, 0x3e7) Kerberos tickets so it requests new ones with the delegation change
klist purge -li 0x3e7
Microsoft's klist reference warns: "Purging tickets destroys all tickets that you have cached, so use this attribute with caution." On Windows Server 2025, don't disable Credential Guard to bring CredSSP back; Microsoft's resolution is that "Kerberos Constrained Delegation and Resource-Based Kerberos Constrained Delegation are recommended" instead. If the admin account is in Protected Users or marked sensitive, start the move while signed in on the source host, or use an account meant for that, rather than removing the protection (our reading). If the Microsoft Virtual System Migration Service SPN is missing, Microsoft's guide registers it with setspn -s Microsoft Virtual System Migration Service/<FQDN> <ComputerName>.
Connection (Step 9). If the listener was disabled by Group Policy, run gpupdate /force on that host and read the result; if Registry.pol is corrupt, Microsoft's fix is to restore it from a backup or copy the GroupPolicy folder from a working server. Open TCP 6600 between the hosts on the migration network (and 3343 between cluster nodes) in whatever firewall sits between them. Add Microsoft's Hyper-V process exclusions to third-party antivirus.
Destination capacity (Step 10). Free memory on the destination or pick another one; add the missing node to the possible owners of both cluster resources; give the destination the same system drive letter as the other nodes; restore the default user rights for the NT VIRTUAL MACHINE\Virtual Machines group in the GPO that removed them; fix the folder permissions on the destination path to match a working host.
Then prove it. Run Compare-VM -Name APP01 -DestinationHost HV02 again and confirm the Incompatibilities list is empty, then move the VM the way the user did (same tool, same host it was started from):
# Standalone hosts (Microsoft's Move-VM form; add -IncludeStorage for a storage move)
Move-VM -Name APP01 -DestinationHost HV02
# Clustered VM (Microsoft's form)
Move-ClusterVirtualMachineRole -Name "APP01" -Node HV02 -MigrationType Live
Pass criteria (our reading): the move completes, Get-VM -ComputerName HV02 shows the VM Running there, no new 21502 or worker errors on either host for that time, the VM's network works on the destination (no Event 21024), and the move back to the source works too. Then retry the other VMs from the ticket.
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Switch name missing on the destination | Create or rename it to the standard name, same type and uplink | Renaming the source switch and breaking its other VMs |
| Processor features differ, same vendor | Compatibility on for the VMs that must move live, then off again | Compatibility on for every VM permanently |
| Intel to AMD (or back) | A planned shutdown and cold move | Hoping a setting makes it live-migratable |
| Configuration version newer than the destination | Keep the VM on newer hosts until the old ones are retired | Upgrading versions mid-migration, then needing to go back |
| CredSSP failing from a remote console | Kerberos with constrained delegation, both directions | CredSSP everywhere with "sign in first" as the process |
| Windows Server 2025 source, CredSSP | Kerberos constrained or resource-based constrained delegation | Turning off Credential Guard |
| No shared migration network | Add a dedicated, isolated migration network to both hosts |
UseAnyNetworkForMigration set to $true |
| Nothing listening on 6600 | Re-enable migration, fix the GPO, open the port between hosts | Turning off the host firewall |
| Destination out of memory | Move other VMs off it or choose another host | Shrinking the VM's memory without asking its owner |
FAQ
What is Event ID 21502 in Hyper-V?
It's the summary event Hyper-V logs when a live migration fails (most often seen on clustered hosts), and the real reason is in its message text. Microsoft lists about twenty different causes under that one ID, from "a virtual switch used by the VM doesn't exist on the destination node" to processor features, Kerberos errors, memory, and ISO files. Read the full message on both hosts and run Compare-VM (Steps 2 and 3).
Why does Hyper-V live migration fail with a processor compatibility error?
The destination can't offer every CPU feature the running VM saw when it started. Turn on processor compatibility for that VM (it has to be off to change the setting), make the hosts' BIOS settings and speculation control results match, and move from older to newer microcode. It won't help between Intel and AMD hosts (Step 5).
Should I use CredSSP or Kerberos for live migration?
Kerberos with constrained delegation, set on both hosts for each other with cifs and Microsoft Virtual System Migration Service. CredSSP only works when you're signed in on the source host, and Microsoft says "you can't use CredSSP-based live migration with Hyper-V after upgrading to Windows Server 2025" with Credential Guard on (Step 8).
Why does live migration fail with 0x8009030E "No credentials are available in the security package"?
Either CredSSP is in use and the move was started from somewhere other than the source host, or Kerberos is in use and delegation is missing, one-way, set to "Kerberos only", pointed at the wrong service, or blocked because the admin account can't be delegated (Protected Users or sensitive). Read msDS-AllowedToDelegateTo for both hosts (Step 8).
Why does live migration work one way but not the other?
Usually the VM's configuration version was upgraded on the newer host, or the newer host has CPU features or microcode the older host lacks. Compare Get-VM versions with Get-VMHostSupportedVersion on the older host and check processor compatibility (Steps 5 and 6). With CredSSP, it can also be because you're signed in on one host but not the other.
Related posts
- The Target Principal Name Is Incorrect (when the migration fails with 0x80090322 and the Kerberos name is the problem)
- Hyper-V Checkpoint Operation Failed (when a broken checkpoint, saved state, or AVHDX chain blocks the move)
- Group Policy Not Applying (when the migration listener is disabled because policy processing failed)
- Active Directory Replication Error 1722 (the same name, port, and firewall reading for RPC between servers)
Free checklist
Turning on processor compatibility, CredSSP, and any-network migration on every host before anyone read the inner error is a change made everywhere at once. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=hyper-v-live-migration-failed
Admin Pack Studio; not affiliated with Microsoft. Steps 1-10 favor read-only checks: Get-WinEvent, Get-ClusterLog, Compare-VM, Get-VMNetworkAdapter, Get-VMSwitch, Get-VMDvdDrive, Get-VMProcessor, Get-VMSnapshot, Get-VM, Get-VMHostSupportedVersion, Get-VMIntegrationService, Get-VMHost, Get-VMMigrationNetwork, Get-ClusterNetwork, Get-Cluster, Get-ClusterParameter, Get-ADComputer, Get-ADUser, Get-ADGroupMember, setspn -L, Get-Service, Get-NetTCPConnection, Test-NetConnection, Get-NetFirewallRule, Get-VMMemory, Get-VMHardDiskDrive, Test-Path, Get-ClusterResource, Get-ClusterOwnerNode, and Get-ClusterNode. Writing the cluster log creates files on every node. Changing switches, DVD media, processor compatibility, configuration versions, migration settings and networks, cluster network order, AD delegation, SPNs, Kerberos tickets, Group Policy, firewall rules, antivirus exclusions, user rights, cluster owners, or VM memory, and stopping, starting, or moving VMs, are deliberate changes. Change one link at a time, prove it with Compare-VM and a move in both directions, and check current Microsoft Learn for version-specific behavior.
Top comments (0)