When a Hyper-V live migration fails, capture the exact error code or Event ID first, then run Compare-VM against the destination host. The common failure categories are destination vSwitch mismatch, authentication or delegation, processor compatibility, VM configuration version, destination memory, migration network problems, and VM state issues. If the VM is a clustered role, cluster and CSV health belong on the list too, but only as one check among several, not the starting assumption.
This guide covers domain-joined Hyper-V hosts on Windows Server 2019, 2022, and 2025, including live migration both inside a failover cluster and without one. Cluster-specific steps are marked conditional throughout – failover clustering is not a prerequisite for most of this troubleshooting.
This page is about diagnosing a failed Hyper-V live migration. For failover cluster architecture, quorum design, witness selection, CSV incident response, or cluster database recovery, see the dedicated Hyper-V Failover Clustering guide linked in the cluster section below. Those topics require a broader cluster troubleshooting workflow than a migration failure alone.
- Capture the exact error code or Event ID before acting. The progress percentage is an investigation hint, not a documented root-cause code
- Run
Compare-VMagainst the destination host before trusting the failure percentage - Verify the destination vSwitch exists with a matching name, type, and teaming design
- Separate authentication errors by code:
0x8009030Eand0x8009030Dpoint to Kerberos delegation or CredSSP execution context;0x80070569points to a local user right on the destination, not delegation - For
0x800705AA, check destination memory and VMMS events, not free disk space - Only if the VM is a clustered role and cluster/CSV events are present, check cluster health next
Quick reference for the error codes and Event IDs behind a failed Hyper-V live migration, in the order they’re worth checking:
| Error / Event | Meaning | First check |
|---|---|---|
| 0x8009030E (SEC_E_NO_CREDENTIALS) | No credentials available for the security package | Authentication mode, execution host |
| 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS) | Credentials presented but not accepted | Kerberos configuration on both hosts, then setspn -L |
| 0x80070569 | User has not been granted the requested logon type | gpresult /h on the destination |
| 0x800705AA | Insufficient system resources on the destination | VMMS events, destination memory counters |
| Event 21502 | Generic live migration failure event; the full message identifies the actual cause | Read the complete event message and underlying error code |
| Event 21501 | Migration concurrency limit reached | Get-VMHost, cluster-wide migration limit if applicable |
If the failed migration coincides with FailoverClustering events such as 5120, or a degraded CSV state, use the cluster-health section near the end of this guide instead of troubleshooting authentication or vSwitch issues in isolation.
Hyper-V Live Migration Failed: Start With the Exact Error
The progress percentage at which a migration fails is a clue, not a root-cause code. Where it lands depends on the Windows Server version, migration transport, and whether the VM is clustered – it narrows where to look, it does not name the cause by itself.
Run Compare-VM
# From the source Hyper-V host, or specify -ComputerName from a management host
Compare-VM -ComputerName "HV01" -Name "VMName" -DestinationHost "HV02"Run this on the source host, or specify -ComputerName explicitly. Without it, the cmdlet looks for the VM on whichever computer you’re actually typing from, not the host that owns it.
Compare-VM reports incompatibilities before or after a failed attempt, including processor feature mismatches, missing virtual switches, and configuration version problems. Treat it as a compatibility pre-check, not a full explanation – it doesn’t confirm Kerberos/SPN health, network throughput, destination memory pressure, storage latency, or the concurrent-migration limit.
Check Hyper-V VMMS and Worker Logs
Pair Compare-VM with the two logs that record what happened during the attempt:
$source = 'HV01'
$destination = 'HV02'
$start = (Get-Date).AddMinutes(-30)
$logs = 'Microsoft-Windows-Hyper-V-VMMS-Admin', 'Microsoft-Windows-Hyper-V-Worker-Admin'
foreach ($node in $source, $destination) {
foreach ($log in $logs) {
Get-WinEvent -ComputerName $node -FilterHashtable @{
LogName = $log
StartTime = $start
} -ErrorAction SilentlyContinue |
Select-Object @{Name='Node';Expression={$node}}, TimeCreated, Id, LevelDisplayName, Message
}
}Remote event-log access needs the Windows Event Log firewall rule and sufficient permissions on both nodes. Without -ComputerName, this reads the management host’s own logs, not the source or destination Hyper-V events you actually need. See Microsoft’s live migration troubleshooting guidance for the fuller diagnostic sequence this is based on.
Check the Destination Virtual Switch
Event ID 21502 is a generic live migration failure event covering many different underlying causes, from a missing vSwitch to socket errors to hardware incompatibility – the full event message and error code identify what actually happened, not the ID alone. A missing destination vSwitch is one documented Event 21502 scenario and can fail migration below 10 percent, per Microsoft’s live migration troubleshooting guidance. This is one of the highest-priority early checks, and it isn’t only about the name matching.
Compare switch names, type, SET or LBFO teaming design, VLAN handling, and network mappings on every node, not just the name string:
# Compare host switches explicitly across both nodes
Get-VMSwitch -ComputerName HV01,HV02 |
Select-Object ComputerName, Name, SwitchType, EmbeddedTeamingEnabled, NetAdapterInterfaceDescriptions
# Read the VM's current adapter configuration from the source host
Get-VMNetworkAdapter -ComputerName "HV01" -VMName "VMName" |
Format-List Name, SwitchName, MacAddress, DynamicMacAddressEnabledIf the switch is present but migration still fails at this stage, check SET versus LBFO mismatch, VLAN configuration, and a missing uplink before assuming the switch name is the only variable. For virtual switch design and naming standards, see Hyper-V Networking: Virtual Switches, VLANs, and SET Explained.
Hyper-V Live Migration Authentication Errors
Several authentication failures can look similar during live migration, but they require different fixes. Separate them by the full error message and code first.
Error 0x8009030E: No Credentials Are Available in the Security Package
When 0x8009030E (SEC_E_NO_CREDENTIALS) appears with the live migration message “No credentials are available in the security package,” start with the authentication mode and execution context: CredSSP initiated from the wrong host, or Kerberos constrained delegation that is missing or incomplete between the two computer accounts.
Check first:
Get-VMHost -ComputerName HV01,HV02 |
Select-Object ComputerName, VirtualMachineMigrationAuthenticationTypeThen review the VMMS/Admin log on both hosts for the exact failure around the attempt. The CredSSP-versus-Kerberos section below covers the execution requirements, including Windows Server 2025 Credential Guard behavior.
Verify: re-run the migration from the correct execution context and confirm no new 0x8009030E entries appear in the VMMS/Admin log.
Source: Set up hosts for live migration, Microsoft Learn.
Error 0x8009030D: Credentials Were Not Recognized
Error 0x8009030D (SEC_E_UNKNOWN_CREDENTIALS) means the credentials supplied to the security package were not recognized. In a Hyper-V live migration failure, first verify that both hosts use Kerberos for migration and that constrained delegation is configured correctly between the two computer accounts – Microsoft’s live migration troubleshooting guidance directs this as the primary path before anything else.
If delegation appears correct, make SPN inspection a secondary diagnostic step, checking specifically for duplicates, since a duplicate SPN across two accounts breaks delegation silently:
$hosts = 'HV01','HV02'
foreach ($hostName in $hosts) {
Get-ADComputer -Identity $hostName -Properties msDS-AllowedToDelegateTo |
Select-Object Name, @{Name='AllowedToDelegateTo';Expression={$_.'msDS-AllowedToDelegateTo'}}
}
setspn -L HV01
setspn -L HV02
setspn -XFix: add any missing delegation entries to Microsoft Virtual System Migration Service for the opposite host on each computer account, and correct any duplicate SPN that setspn -X reports. Confirm delegation first, then use SPN findings to narrow the remaining authentication problem.
Verify: re-run setspn -L on both hosts to confirm no duplicates remain, then retry the migration.
Source: Troubleshoot live migration issues, Microsoft Learn.
Hyper-V Live Migration Error 0x80070569
Error 0x80070569, “the user has not been granted the requested logon type at this computer,” is frequently misdiagnosed as a Kerberos delegation problem during live migration. It is not – it is a local user-rights problem on the destination host.
What it means: the special identity Hyper-V uses for migration, NT VIRTUAL MACHINE\Virtual Machines, does not have the local logon right it needs on the destination.
Check first: verify Log on as a service for that identity on the destination host – this is the primary documented cause. Run gpresult locally on the destination; a report generated on the source host or a management workstation does not prove the destination’s effective policy:
# Run locally on the destination host (HV02 in this example)
gpresult /h C:\Temp\gpresult.htmlFix: add NT VIRTUAL MACHINE\Virtual Machines to Log on as a service in the applicable GPO, under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
The “Create symbolic links” GPO trap. If Log on as a service is correct and the error persists, also verify Create symbolic links for the same identity, in the same GPO location. A restrictive GPO can break migration even with the primary right configured correctly.
Verify: re-run gpresult on the destination to confirm both rights apply, then retry the migration.
This same error also appears in standalone VM startup failures for the same underlying reason, per Microsoft’s documented fix. For the standalone startup path, see Hyper-V VM Won’t Start.
CredSSP vs Kerberos on Windows Server 2019, 2022, and 2025
Kerberos constrained delegation. The recommended path for migrations initiated from a management host. Configure constrained delegation to Microsoft Virtual System Migration Service between the participating hosts’ computer accounts. Add cifs delegation only when the workflow also moves VM storage or storage is SMB-backed – it is scenario-dependent, not a universal pair with the migration service.
CredSSP. Avoids configuring Kerberos delegation, but the command must execute inside a signed-in session on the source host itself – local console, RDP, or a remote PowerShell session on that host all count. Running the command from a management workstation against the source host does not; that’s a different authentication path.
Windows Server 2025 and Credential Guard. Windows Server 2025 enables Credential Guard by default on domain-joined non-DC servers unless explicitly disabled. CredSSP-based live migration can fail when it’s enabled. Kerberos constrained delegation is the recommended path on 2025, and generally the safer default on earlier versions too. See Microsoft’s Credential Guard known issues for the documented CredSSP interaction.
Hyper-V Compatibility Failures
Processor Compatibility
CPU compatibility failures appear as: “The virtual machine cannot be moved because the processor on the destination computer is not compatible.” Live migration requires the source and destination to use processors from the same manufacturer – compatibility mode cannot live migrate between an Intel host and an AMD host, and that limitation is a hard boundary, not a config option.
# VM must be powered off before changing this setting
# Windows Server 2019/2022, or as a safe minimum on any supported version -
# fixed minimum feature set
Set-VMProcessor -ComputerName "HV01" -VMName "VMName" `
-CompatibilityForMigrationEnabled $true
# Windows Server 2025 cluster, VM configuration version 10.0 or later -
# maximum feature set common to all cluster nodes, not a fixed minimum
Set-VMProcessor -ComputerName "HV01" -VMName "VMName" `
-CompatibilityForMigrationEnabled $true `
-CompatibilityForMigrationMode CommonClusterFeatureSetStandard compatibility uses a fixed minimum feature set for mobility across same-manufacturer hosts. Windows Server 2025 dynamic compatibility instead uses the maximum feature set common to all cluster nodes. Both modes can reduce guest-visible features, so test performance-sensitive workloads before standardizing cluster-wide. Neither mode enables Intel-to-AMD or AMD-to-Intel migration. See Microsoft’s processor compatibility mode documentation and configuration guidance.
VM Configuration Version Mismatch
A VM configuration version mismatch is a separate failure family from processor compatibility, not a second cause of the same processor error. It commonly appears during a rolling Windows Server upgrade, or when migration works toward a newer host but not back to an older one.
# Confirm destination support before assuming a version mismatch
Get-VMHostSupportedVersion -ComputerName "HV02"
Get-VM -ComputerName "HV01" -Name "VMName" | Select-Object Name, VersionConfig version upgrades through Update-VMVersion are one-way and require the VM to be off. If cluster nodes are at mixed Windows Server versions, hold off on version upgrades until every node is at the target version. See Hyper-V VM Configuration: Generation, vCPU, Memory, and Integration Services for planning beyond the migration failure itself.
Hyper-V Live Migration Error 0x800705AA
For the documented live migration 0x800705AA scenario, Microsoft’s troubleshooting guidance identifies insufficient RAM on the destination node as the cause. Administrators may also see the alternate wording “Not enough storage is available to complete this operation” – despite that phrasing, confirm destination memory and Hyper-V Worker/VMMS events before changing storage or network settings.
# What the VM currently thinks it needs
Get-VM -ComputerName "HV01" -Name "VMName" |
Select-Object Name, State, MemoryAssigned, MemoryDemand, DynamicMemoryEnabled
# What the destination actually has available
Get-Counter -ComputerName "HV02" '\Memory\Available MBytes', '\Memory\Committed Bytes', '\Memory\Commit Limit'Fix options: migrate other VMs off the destination first, or free RAM directly. Dynamic Memory can help, but enabling it doesn’t guarantee the VM lands with less RAM at the moment of migration – check current assigned memory rather than assuming it alone solves the shortfall.
Check the Live Migration Network and Transport
Confirm reachability and identify the configured transport before treating the failure as a generic network problem:
# TCP/IP or Compression transport
Test-NetConnection -ComputerName "HV02" -Port 6600
# SMB transport
Test-NetConnection -ComputerName "HV02" -Port 445Use Test-WSMan only to verify management-plane connectivity – it does not confirm the migration data path itself. If the hosts use SMB transport, check SMB Multichannel and RDMA health during an actual controlled migration rather than as a standalone pre-flight test; an empty result with no migration running just means no qualifying session is active, not that Multichannel is broken. Confirm DNS resolution and firewall rules between source and destination match the transport actually in use, not a single port assumed to cover every configuration.
If the full event message contains 0x8007274D (connection refused), 0x80072746 (connection reset), or 0x8007274C (connection timed out), prioritize the live migration listener, firewall rules, the selected migration network, and the source-to-destination transport path over other diagnostic branches.
VM State, Checkpoint, vTPM, and Storage Issues
Saved state, checkpoint, or backup state. If the migration fails while the VM is in Backing up, creating a checkpoint, merging a checkpoint, or working with saved-state files, inspect that operation and the VMMS/Worker events before retrying. Let a conflicting operation finish, or resolve a stuck state, before treating the migration as a separate network or authentication failure. For the deeper checkpoint diagnostic path, see Hyper-V Checkpoint & AVHDX Troubleshooting.
Mounted ISO or DVD. If the VM has an ISO attached from a local path, or a path the destination cannot access, live migration can fail when the destination tries to restore the virtual DVD attachment. Microsoft documents 0xC03A0014 (ERROR_VIRTDISK_PROVIDER_NOT_FOUND) as one such case. Eject the ISO when it isn’t required, or confirm the destination can reach the required media path.
vTPM or shielded VM. Relevant only when the failure explicitly points to a key protector, shielding certificate, or protected-VM migration – most failures have nothing to do with vTPM.
Shared or clustered storage. Relevant only when the VM uses a shared-disk configuration needing cluster-specific handling; see the cluster/CSV section below.
Live Migration Limit Reached
Event ID 21501 indicates the configured concurrent-migration limit was reached.
Get-VMHost -ComputerName HV01,HV02 |
Select-Object ComputerName, MaximumVirtualMachineMigrationsWait for another migration to finish, or raise the limit carefully with attention to host performance under concurrent load. On Windows Server 2022 (September 2022 cumulative update or later) and Windows Server 2025, a cluster-wide MaximumParallelMigrations property can override the per-host value; Windows Server 2019 uses only the host-level setting. Before retrying, confirm no stuck migration from a previous attempt is still holding a slot.
Live Migration Stuck or Stalled
A migration that stops progressing can point to the management plane, the migration data path, destination resource pressure, or storage contention. Work through these checks in order:
- Check the VMMS and Worker admin logs on both hosts, filtered to the incident window
- Verify WinRM connectivity as a management-plane check only:
Test-WSMan -ComputerName "HV02" - Test the transport actually configured for migration, not a fixed port assumption
- If clustered, confirm the cluster’s view of the operation:
Get-ClusterGroup | Where-Object GroupType -eq 'VirtualMachine' | Select-Object Name, State, OwnerNode– the group name doesn’t always match the VM’s display name - If started as a PowerShell background job (
-AsJob), check and cancel it:Get-JobthenStop-Job - Review network bandwidth – live migration competes with other cluster traffic if a dedicated migration network isn’t configured
Avoid restarting VMMS or the cluster service as a generic first step – either can affect other VMs on the same host. A migration that stalls after several minutes, rather than failing immediately, more often points to transport or infrastructure contention than a Hyper-V configuration error.
If the VM Is Clustered: Check Cluster and CSV Health
If the failed migration coincides with degraded cluster nodes or CSV events, the migration failure may be a downstream symptom rather than a migration-specific problem. Run a baseline check before assuming authentication, vSwitch, or VM-state symptoms explain it in isolation:
Get-ClusterNode
Get-ClusterGroup | Where-Object GroupType -eq 'VirtualMachine' | Select-Object Name, State, OwnerNode
Get-ClusterSharedVolumeState |
Select-Object Name, Node, State, RedirectedIOReason, VolumeFriendlyNameA node showing Isolated, or a VM role stuck in Pending or Failed, is a strong cluster-health signal. A CSV state other than Direct also needs correlation with RedirectedIOReason, FailoverClustering events, and the incident timeline. Redirected I/O can be intentional during approved maintenance or backup, or it can indicate a degraded path; by itself, it does not prove the cluster caused the migration failure.
Full diagnosis of Event 5120, quorum recovery, witness configuration, and cluster database issues is out of scope for this page. For that deeper workflow, see Hyper-V Failover Clustering Explained: Quorum, CSV, and Live Migration.
Verification Checklist
Compare-VM no longer reports the blocking incompatibility
Destination vSwitch exists and matches on name, type, and teaming design
Authentication mode matches the execution path used
No new 0x8009030E, 0x8009030D, 0x80070569, or 0x800705AA entries in the VMMS/Admin log
Destination has enough free memory for the VM's assigned RAM
VM configuration version is supported on the destination
Migration network/transport path is confirmed reachable
If clustered, node state, CSV state, and cluster group state are all healthy
Retry one controlled migration and confirm clean VMMS/Worker logs on both hostsFAQ
Why does Hyper-V live migration fail?
The main categories are destination vSwitch mismatch, authentication or delegation failure, processor or VM configuration compatibility, insufficient destination resources, a network/transport problem, or a VM state issue like a stuck checkpoint or mounted ISO. If the VM is clustered, a degraded cluster or CSV state can also be the underlying cause.
How do I fix Hyper-V error 0x8009030E?
Confirm the migration’s authentication mode and where the command was actually executed – CredSSP only works from a signed-in session on the source host itself. For migrations run from a management workstation, configure Kerberos constrained delegation instead. On Windows Server 2025, Credential Guard is enabled by default and can block CredSSP outright.
How do I fix error 0x80070569 during Hyper-V live migration?
Check Log on as a service for NT VIRTUAL MACHINE\Virtual Machines on the destination host first. Use gpresult run locally on the destination. If that’s correct and the error persists, also check Create symbolic links for the same identity.
What causes Hyper-V error 0x800705AA?
Microsoft’s documented cause is insufficient RAM on the destination node, despite wording that can read as a storage error. Check the destination’s memory counters and the VMMS/Admin log before assuming disk space is the issue.
Why does live migration fail below 10 percent?
A missing or mismatched destination vSwitch is one documented scenario under Event 21502, but the event covers many other causes too – authentication and CPU compatibility failures can also surface early. Confirm with Compare-VM and Get-VMSwitch, and read the full event message, rather than assuming the switch by percentage alone.
Does Hyper-V live migration require Kerberos?
Not strictly – CredSSP is a valid alternative, but only when started from a signed-in session on the source host itself. Kerberos constrained delegation is the recommended path from a management workstation, and required on Windows Server 2025 when Credential Guard blocks CredSSP.
Why does live migration work one way but not the other?
Asymmetric failures usually trace back to VM configuration version support, a processor feature mismatch that only blocks migration in one direction, or an authentication configuration set up on only one of the two computer accounts.
Hyper-V Series
14 articles – Windows Server 2025 · Requirements · Licensing · Networking · Storage · Backup · Clustering