Hyper-V live migration failures and the delegation behind them

Live migration either works or it does not, and when it does not the error message is frequently about something other than the cause. The classic presentation — migration succeeds when you are signed in at the host’s console and fails when you drive it remotely from a management machine — is not a Hyper-V fault at all. It is Kerberos.

The symptom, and the question that splits it

“Live migration failed” needs one question before anything else: where were you when you started it?

• At the host’s console, or in a session on the host — and it works. Then the issue is almost certainly the authentication configuration, not Hyper-V.
• From a remote management machine — and it fails. Same conclusion.
• Fails everywhere, including from the console. Now it is a genuine migration problem: compatibility, networking, storage or resources.

That single question saves a great deal of time, so ask it first.

The architecture: two hops, and why that matters

When you sit at MGMT01 and tell HOST01 to migrate a virtual machine to HOST02, three machines are involved. Your credential authenticates you to HOST01. HOST01 then has to authenticate to HOST02 on your behalf, to move the virtual machine’s files and state.

That second step is a delegation problem — the classic Kerberos double hop. HOST01 has your service ticket, which is valid only for HOST01, and it needs a ticket to HOST02.

Hyper-V offers two ways to resolve it, and the choice has consequences.

CredSSP forwards your credentials to the host, which then uses them for the second hop. It requires no directory configuration, which is why it is the default, and it works only when you are signed in on the source host — hence the console-works-remote-fails pattern. It also means your credential is delivered to the host in a reusable form, which is a meaningful security consideration for a credential that administers virtualisation hosts.

Kerberos with constrained delegation configures the directory so that each host is trusted to delegate to the others for specific services. It works remotely, and it does not hand your credential to the host. It requires directory configuration, which is the only reason people avoid it.

For anything beyond a small lab I would use Kerberos. A Hyper-V host is Tier 0-adjacent — it runs the virtual machines, possibly including domain controllers, as noted in administrative tiering — and CredSSP delivering administrative credentials to it is a poor trade for saving a configuration step.

Diagnosis

1. Confirm the authentication configuration

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

If VirtualMachineMigrationAuthenticationType is CredSSP and you are migrating remotely, that is your answer.

2. Confirm the delegation, if using Kerberos

Each host must be trusted to delegate to every other host it might migrate to, for two services: cifs — for the file transfer — and Microsoft Virtual System Migration Service.

# What HOST01 is currently permitted to delegate to.
Get-ADComputer -Identity HOST01 -Properties 'msDS-AllowedToDelegateTo' |
    Select-Object -ExpandProperty 'msDS-AllowedToDelegateTo'

Two mistakes are common and both produce the same failure:

• Only one of the two services configured. cifs alone is the usual half-done case, and it fails at the migration service step.
• Delegation configured in one direction only. HOST01 can delegate to HOST02 but not the reverse, so migrations work one way and fail the other. Configure both directions for every pair that migrates.

Note that this is the classic constrained delegation model, which requires directory administrator rights to configure and does not cross domains. The alternative, resource-based constrained delegation, inverts the configuration onto the target — the comparison is in Kerberos delegation, and for Hyper-V live migration specifically, follow Microsoft’s documented configuration for your version rather than assuming the two are interchangeable here.

3. Rule out the non-authentication causes

If it fails from the console too, work through these:

# Is migration enabled, and on which networks?
Get-VMMigrationNetwork

# Processor compatibility — the usual cause of "not compatible with the hardware".
Get-VM -Name 'SampleVM' | Get-VMProcessor |
    Select-Object VMName, CompatibilityForMigrationEnabled, Count

Processor compatibility. Migrating between hosts with different processor generations fails unless processor compatibility mode is enabled on the virtual machine. Enabling it requires the virtual machine to be off, which is why this is a design decision rather than a fix in the moment.

Storage. For a clustered migration, the virtual machine’s files must be on storage both hosts can reach. For a shared-nothing migration, the destination needs the path and the capacity. A path that exists on the source and not the destination is a frequent and undramatic cause.

Virtual switch names. The destination must have a virtual switch with the same name. A typo, or a switch renamed on one host, produces a failure that reads as a configuration error rather than a naming one.

Resources. Insufficient memory on the destination, or a static memory assignment that does not fit.

Migration networks. Live migration uses specific networks; if none is configured or reachable, migration fails regardless of everything else being correct.

4. Read the actual event

The Hyper-V-VMMS operational log carries the real error, usually with more specificity than the interface shows:

Get-WinEvent -LogName 'Microsoft-Windows-Hyper-V-VMMS-Admin' -MaxEvents 40 |
    Where-Object { $_.LevelDisplayName -in 'Error', 'Warning' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

Check it on both hosts. The destination frequently logs the informative error while the source logs only that the operation failed.

Resolution

For the authentication case, the change is on the hosts plus the directory:

# On each host.
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

Then configure constrained delegation for both services, in both directions, for every host pair. Allow for replication and for existing tickets — a delegation change is not always immediate on a host holding a cached ticket, so testing straight away can produce a misleading failure.

For processor compatibility, enable it on the virtual machine while it is off. Accept that it presents a lower common feature set to the guest, which is the trade.

For the remainder, the fix follows the finding: create the virtual switch with the matching name, present the storage, configure the migration network, free the memory.

Validation

• Migrate a low-value virtual machine remotely, from a management machine, not from the host console. This is the test that actually exercises delegation.
• Migrate it back, which exercises the reverse delegation direction.
• Test every host pair that must work, not just one. Delegation configured for some pairs and not others is the most common partial state.
• Confirm the virtual machine keeps its network connection throughout — a successful migration that drops connectivity points at switch or VLAN differences between hosts.
• Repeat after adding a host to the cluster. A new host needs delegation configured in both directions with every existing host, and forgetting this is why migrations start failing weeks after an expansion.

Operations

Add delegation configuration to the host build process. It is the step that gets forgotten when a node is added, and the failure appears much later.

Prefer cluster-aware updating for patching, which drains nodes properly and exercises live migration as part of routine work — so a delegation problem surfaces during maintenance rather than during an incident.

Watch migration duration. A migration that takes much longer than usual points at the migration network, or at a virtual machine whose memory is changing faster than it can be copied.

Verification and limits

The CredSSP and Kerberos authentication options, the double-hop requirement, the two service principal names required for constrained delegation, processor compatibility mode and the Hyper-V-VMMS logging were checked against current Microsoft documentation on 20 September 2026.

Nothing here was executed in a lab for this article. Changing delegation is a directory change with security consequences and should follow Microsoft’s documented configuration for your Windows Server version — record the existing attribute values before changing them, and test on a non-production pair first. The read-only diagnostic commands are safe to run.

References

• Set up hosts for live migration without failover clustering
• Live migration overview
• Set-VMHost
• Kerberos constrained delegation overview