VM Migration Failed: Insufficient Resources on Host Fix

Quick answer for experienced folks

Reduce CPU or memory reservations on the VM to zero or match the host's available capacity. Otherwise, manually migrate the VM to a host with enough free resources.

Why this happens

The error "VM migration failed due to insufficient resources on host" pops up when the destination host can't guarantee the resources your VM requires. What's actually happening here is that the hypervisor checks if the host has enough free CPU, memory, and any reserved resources before it starts the migration. If the host doesn't have those resources available right now, the migration stops cold.

This usually happens in VMware vSphere or Hyper-V environments. Real-world trigger: you got a Friday afternoon alert that a host's memory is at 90%. You try to move a VM to another host, and bam — the error. The destination host has plenty of total memory, but it's already running other VMs. The VM you're migrating has a 2GB memory reservation. The host only has 1.5GB free. No go.

Fix steps

Check the destination host's free resources. In vSphere, go to the host's summary tab. Look at CPU and memory usage right now. Not the total capacity — the free amount. If free memory is below 512MB, you're out of luck for any migration.
Review the VM's resource reservations. Edit the VM settings. Go to the Resources tab (vSphere) or Memory/CPU section (Hyper-V). Look for Reservation values. If CPU is set to 2GHz but the host only has 1GHz free, that's your problem.
Set reservations to zero. Change both CPU and memory reservations to 0. This tells the hypervisor: "I take whatever is free." The VM might run slower during peak loads, but it lets the migration happen.
```
PowerCLI command: Get-VM "YourVM" | Set-VM -CpuReservationMhz 0 -MemoryReservationGB 0
```
Retry the migration. Right-click the VM, select Migrate, and choose the destination host again. The migration should start right away. If it still fails, the host truly has zero free resources — move to alternative fixes.
Use vMotion with a swap file location. In vSphere, you can set a swap file location to a shared datastore. This lets the VM use disk space as temporary memory. Not ideal for performance, but it gets the VM moved. Go to VM settings → VM Options → Swap file location → Set to "Datastore default".

Alternative fixes if the main one fails

Migrate to a different host

Sometimes the problem isn't your VM — it's the destination host. Check all hosts in the cluster. Pick one with at least 20% free memory and CPU. Right-click the VM, select Migrate, and pick that host instead.

Disable resource pools or limits

If your cluster uses resource pools with shares or limits, those also block the migration. Go to the destination host or resource pool. Right-click → Edit Settings → Change CPU/Memory limits to Unlimited. This only helps if the pool itself is the bottleneck.

Power off the VM first

I know, this isn't a live migration anymore. But if the migration keeps failing, shut down the VM. Then move it. Power it back on after. The reason step 3 works is that the hypervisor's resource check is bypassed — a powered-off VM doesn't need any resources on the host. This is a solid fallback for non-critical VMs.

Prevention tip

Set all VM reservations to zero unless you have a specific reason not to. Reservations are a trap. They sound good — "guarantee performance" — but they cause exactly this migration failure. The better way to handle performance is with shares. Set CPU shares to High or Normal. Memory shares same. That way, the VM gets priority during contention but can still be moved anywhere.

Also monitor your cluster memory usage. I use vRealize Operations or even a simple script that emails me when any host hits 85% memory usage. If a host is always near full, add another host or reduce VM memory allocations. A cluster with 20% headroom rarely sees this error.

One more thing: check the host's advanced settings for vMotion. In vSphere, go to Host → Configure → System → Advanced System Settings. Look for Migrate.BindHostPolicy. Set it to 1 (allow any host). Some environments lock this down and cause false resource errors.

That's it. The error is almost always about reservations or a host that's too full. Fix those two things, and migrations work again.