Hyper-V Live Migration Fails at 80–90% Due to Kerberos Constrained Delegation Misconfiguration After Security Hardening

Indicators

• Live Migration progress stalls and fails at 80–90% completion
• Event ID 21502 in Microsoft-Windows-Hyper-V-High-Availability log indicating Virtual Machine Migration Service authentication failure
• Event ID 22038 in Microsoft-Windows-Hyper-V-High-Availability log indicating Virtual Machine Migration Service authentication failure
• Error messages indicating security context negotiation failures during migration
• Access denied errors returned during Live Migration attempts between cluster nodes
• Administrators unable to drain hypervisor hosts for monthly patching without downtime to guest workloads

Likely causes

• Stricter default Kerberos constraint requirements introduced by recent platform security hardening updates invalidate previously working delegation configurations on cluster host computer objects
• Delegation validation mechanics tightened across active cluster schemas in recent hardening updates, causing the Virtual Machine Migration Service to fail authentication negotiation
• Constrained Delegation not explicitly configured (or previously configured via unconstrained delegation which is now blocked) for host computer objects in Active Directory for the Microsoft Virtual System Migration Service principal

Diagnostic steps

1. Open Event Viewer on the source cluster node and navigate to Applications and Services Logs > Microsoft > Windows > Hyper-V-High-Availability. Filter for Event ID 21502 and 22038 to confirm authentication failure as the cause of migration failure.
   Confirms that the Live Migration failure is caused by Virtual Machine Migration Service authentication failure rather than network, storage, or resource issues.
2. Repeat Event ID 21502/22038 log review on the destination cluster node to determine whether the authentication failure originates at source, destination, or both ends of the migration.
   Determines directionality of the Kerberos delegation failure — both source and destination hosts require correct delegation configuration.
3. In Active Directory Users and Computers (enable Advanced Features view), locate each Hyper-V cluster node computer object. Open Properties > Delegation tab and review the current delegation type (None, Trust for any service, or Trust for specified services only).
   Identifies whether Constrained Delegation is absent or misconfigured on the host computer objects, confirming the root cause.
4. Review Windows Update history on cluster hosts and check for any hardening-related Group Policy changes affecting Kerberos delegation to correlate the onset of failure with security updates.
   Correlates the onset of the failure with the security hardening update, confirming the likely cause and ruling out unrelated configuration drift.
5. Attempt a test Live Migration between two affected cluster nodes while monitoring Event Viewer in real time on both source and destination nodes, confirming that Event ID 21502 or 22038 fires at the 80–90% mark.
   Reproduces the failure in a controlled manner and precisely correlates the event log entries to the migration stall point for documentation and escalation if needed.

Resolution path

• 1. Open Active Directory Users and Computers, enable Advanced Features view (View menu), and locate the computer object for the source Hyper-V cluster node.
• 2. Open the computer object Properties, navigate to the Delegation tab, and select 'Trust this computer for delegation to specified services only' (Constrained Delegation). Select 'Use Kerberos only' (or 'Use any authentication protocol' if protocol transition is required in the environment).
• 3. Click Add, then Users or Computers, and add the destination Hyper-V cluster node computer object. From the available services list, select 'Microsoft Virtual System Migration Service' and click OK.
• 4. Repeat steps 1–3 for the destination Hyper-V cluster node computer object, adding the source node and selecting 'Microsoft Virtual System Migration Service' — delegation must be configured bidirectionally on both source and destination hosts.
• 5. Repeat steps 1–4 for every cluster node pair that participates in Live Migration to restore full cluster high availability.
• 6. After completing AD changes, allow sufficient time for Kerberos ticket caches to expire (default up to 10 minutes) or run 'klist purge' on the affected hosts, then retry Live Migration to confirm resolution.

Prevention

• Before applying security hardening updates to Hyper-V cluster hosts or Active Directory schema, audit and document existing Kerberos delegation configuration on all cluster node computer objects, and explicitly configure Constrained Delegation for the Microsoft Virtual System Migration Service as a pre-hardening step.
• Incorporate a post-hardening validation runbook that includes a test Live Migration between each cluster node pair immediately after security updates are applied, so delegation regressions are caught before the next maintenance window rather than during it.
• Maintain a baseline AD configuration export (e.g., via Get-ADComputer with delegation properties) for all Hyper-V cluster nodes as part of change management, enabling rapid detection of delegation drift after updates.

Tools

• Active Directory Users and Computers (ADUC) — configure Constrained Delegation on cluster node computer objects
• Active Directory Administrative Center (ADAC) — alternative GUI for delegation configuration
• Event Viewer — review Microsoft-Windows-Hyper-V-High-Availability log for Event IDs 21502 and 22038
• Failover Cluster Manager — initiate and monitor Live Migration and host drain operations
• klist — purge Kerberos ticket cache on hosts after AD delegation changes

References

• Hyper-V VM Live Migration Failures Post-Security Hardening — The Triage Manual