Live Migration Failed: 'Unexpected Interruption' Fix
Your live migration failed mid-transfer? This is a common Hyper-V issue. We'll fix it from quick check to full solution.
Quick Fix (30 seconds) – Check Network Connectivity
I know this error is infuriating – you're moving a VM, and suddenly it stops. No clear reason. The first thing I check every time: network connectivity between the source and target hosts.
- On the source host, open Command Prompt as Admin.
- Ping the target host's live migration IP address. Run:
ping -n 4 [TargetHostIP]
If you get timeouts or packet loss, there's your problem. Live migration is picky about network drops. Even 1% packet loss can kill a migration.
Real trigger I've seen: A network team changed a switch port speed mid-migration. The VM hung. Took us 2 hours to find that. So check your switch logs too, if you can.
If ping works fine, move to the moderate fix.
Moderate Fix (5 minutes) – Verify Migration Settings
This tripped me up the first time too. Hyper-V has a specific network for live migration, and if it's set wrong, you'll get interrupted transfers.
Step 1: Check the migration network
- Open Hyper-V Manager on the source host.
- Right-click the host name, choose Hyper-V Settings.
- Go to Live Migrations.
- Click Add under available networks. Select the correct network adapter for migration.
Don't use the same network as your VM traffic. That's asking for trouble. Use a dedicated VLAN for live migration if possible.
Step 2: Set authentication type
In the same Live Migrations settings, check Use CredSSP (credential security support provider) or Use Kerberos. For most clusters, Kerberos works better. But if you're not in a domain, use CredSSP.
One thing I always check: Make sure both hosts have the same authentication protocol selected. Mixing them causes the interruption error.
Step 3: Check firewall rules
Live migration uses port 6600 (TCP) by default. Check Windows Firewall on both hosts:
Get-NetFirewallRule -DisplayName *Live Migration*
If the rule is missing, create one:
New-NetFirewallRule -DisplayName 'Live Migration' -Direction Inbound -LocalPort 6600 -Protocol TCP -Action Allow
I've seen host firewalls block this after an update. It's sneaky.
Advanced Fix (15+ minutes) – Timeout and Registry Tuning
If the quick and moderate fixes didn't work, you've likely got a timeout issue. Live migration has a default timeout of 30 seconds. For large VMs or slow networks, that's too short.
Increase the migration timeout
- Open Registry Editor on the source host.
- Navigate to:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization
If you don't see a key named MigrationTimeout, create a new DWORD (32-bit). Name it MigrationTimeout.
Set the value to 120 (that's 2 minutes – I use 300 for large VMs). Decimal. This gives the migration more time before it gives up.
Restart the Hyper-V Virtual Machine Management service:
Restart-Service vmms
Check for storage issues
Live migration also moves the VM's storage if you chose to move it. If your storage is slow or has high latency, that's another common trigger.
- Run Performance Monitor on both hosts.
- Check Avg. Disk sec/Read and Avg. Disk sec/Write. Anything over 50ms is trouble.
For storage migration, I use this command instead of the GUI – it gives better error messages:
Move-VM -Name VMName -DestinationHost TargetHost -MigrateVirtualHardDisks -IncludeStorage -Timeout 300
Note the Timeout 300. That's your safety net.
Check cluster health (if in a failover cluster)
If you're using a cluster, run this to see if any node is misbehaving:
Get-ClusterNode | Select-Object Name, State
If a node shows Down or Paused, that's your culprit. Fix the node first, then retry migration.
Pro tip from my help desk days: Always test live migration with a small VM first. If that works, move the big ones. Saves you hours of head-scratching.
When all else fails – regen the cluster
I've used this trick twice in 5 years. If you're in a cluster and nothing works, delete and recreate the live migration settings on all nodes:
- On each node, open PowerShell as Admin.
- Run:
Get-VMMigrationNetwork | Remove-VMMigrationNetwork
Then re-add the migration network:
Add-VMMigrationNetwork -Subnet 192.168.1.0/24
Replace the subnet with your migration network. This clears any corrupted network bindings.
One last thing: Check if you're running Windows Server 2016 or 2019. Server 2016 had a known bug with live migration on certain network drivers. Update to the latest Cumulative Update. That fixed it for a client of mine who was stuck for a week.
I hope this helps. You're not alone – this error drives everyone crazy. Start with the network check, work your way up. You'll get it sorted.
Was this solution helpful?