Server 2022 Hyper-V VM fails with 0x80070005 on live migration

You're trying to live migrate a running VM from one Windows Server 2022 Hyper-V host to another. Everything looks good—both nodes are in the same cluster, network is up, storage is CSV. But the migration fails with error 0x80070005 (Access denied). The event log shows Event ID 21102: "Virtual machine migration operation failed at source host."

I've seen this one bite people after patching or when moving hosts between domains. The root cause is almost always Kerberos delegation. Hyper-V live migration uses Kerberos to authenticate between hosts. If the computer accounts aren't trusted for delegation, or if constrained delegation isn't configured properly, the migration bombs.

The fix is to set up constrained delegation for the Hyper-V hosts' computer accounts. This lets them impersonate each other for the migration. Skip the old "unconstrained delegation" approach—that's a security risk. Use constrained delegation with Kerberos only.

What triggers this

This error shows up most often after you:

• Add a new Hyper-V host to an existing cluster
• Patch hosts with a cumulative update that resets security settings
• Migrate VMs between hosts in different sites or subnets
• Use a service account for migration instead of computer accounts

Root cause: Kerberos delegation isn't configured

Hyper-V live migration relies on the Microsoft Virtual System Migration Service (VSMS) running under the SYSTEM context. When Host A tries to connect to Host B, it uses Kerberos to authenticate. If Host A's computer account isn't allowed to delegate credentials to Host B's CIFS and Microsoft Virtual System Migration Service, you get 0x80070005.

Some admins try enabling CredSSP or setting up the hosts with a shared local account. Those workarounds are brittle and insecure. The real fix is constrained delegation.

Fix: Configure constrained delegation for Hyper-V hosts

1. Open Active Directory Users and Computers on a domain controller. Make sure both Hyper-V host computer accounts exist here: HYPERV-HOST1 and HYPERV-HOST2.
2. Find the first host's computer account. Right-click it, select Properties, then the Delegation tab. If you don't see the Delegation tab, the account might not be in AD (check DNS registration), or you need to run as Domain Admin.
3. Select "Trust this computer for delegation to specified services only". Then choose "Use Kerberos only". Don't pick the "use any protocol" option—that opens up broader delegation.
4. Click Add. In the dialog, click Users or Computers and type the second host's name (e.g., HYPERV-HOST2). Click OK.
5. Select two services from the list:
   • cifs (Common Internet File System) — needed for SMB traffic during migration
   • Microsoft Virtual System Migration Service (sometimes listed as vsms)
   Hold Ctrl to pick both. Click OK.
6. Repeat the same steps for the second host's computer account. Add the first host as the target with the same two services.
7. Wait for AD replication (or force it with repadmin /syncall). Then reboot both Hyper-V hosts to pick up the new delegation settings.
8. Test the migration again. Right-click a VM, select Move, choose Live move. If it succeeds, you're done.

If it still fails

Check these three things:

• DNS: Both hosts must resolve each other by FQDN and short name. Run nslookup HYPERV-HOST2 from Host1 and vice versa. If it fails, add A records manually.
• Firewall: Hyper-V live migration uses port 6600 TCP by default. Make sure Windows Firewall or your third-party firewall allows inbound/outbound on that port between the host subnets.
• Cluster validation: If these hosts are in a Failover Cluster, run Test-Cluster -Node HOST1,HOST2 from PowerShell. Pay attention to the Hyper-V migration tests. They'll spit out specific errors if something else is wrong.

One more thing—if you're using a dedicated migration network (which you should), verify that the subnet mask and gateway are correct on both ends. I've seen a typo in a subnet mask cause this same error because the Kerberos ticket couldn't route properly.

That's it. Constrained delegation is the cleanest fix for 0x80070005 on live migrations. It works on Server 2022, 2019, and even 2016. Just remember to do both hosts in both directions.