vMotion Failures: Network, Storage and Compatibility — in the Order They Bite
A failed vMotion always leaves its cause in three places: the migration task's error text, the destination host's vmkernel log, and the compatibility report. Read all three before changing anything.
The three families of failure
- Pre-check failures — the migration never starts: compatibility errors, mounted ISOs, suspended state, features the destination lacks.
- Network/transfer failures — starts, then fails or crawls: vmotion portgroup, MTU, routing, bandwidth.
- Storage failures — storage vMotion stalls or aborts: datastore accessibility, snapshots, latency.
Pre-check errors and their fixes
| Error | Cause and fix |
|---|---|
| CPU features incompatible / EVC violation | Destination host has older CPU generation or EVC mode lower than the VM's current instruction set; raise cluster EVC in a maintenance window or migrate within matching generations |
| VM has devices backed by a client (mounted ISO, serial port to client) | Disconnect the console device; connected CD-ROMs are the classic blocker |
| Feature not supported by destination (e.g. vGPU, SR-IOV passthrough) | PCI passthrough and shared-nothing vMotion limits; the VM must stay with capable hosts — use DRS affinity instead |
| Destination cannot access network 'x' | The VM's portgroup/distributed portgroup has no counterpart on the destination; map the network in the wizard or standardise names |
Network path: MTU is the usual suspect
vMotion traffic needs an unbroken vmkernel path between hosts. Jumbo frames configured at one end but not on a switch in between produce failures that look intermittent — small control packets pass, the bulk transfer dies.
# on each ESXi host, test the vmotion vmk with the don't-fragment bit: esxcli network diag ping --vmk=vmk1 --host=<dest-vmotion-ip> -s 8972 -d # and confirm MTU end to end: esxcli network ip interface list | grep -A2 vmk1
Also verify: the vmk is tagged for vMotion traffic, both hosts route to each other's vmotion subnet (a missing route fails only vMotion, never management), and no ACL change blocked TCP 8000 between hosts.
Slow or stalling migrations
vMotion copies memory at the rate the vmotion link allows while the VM keeps dirtying pages. A memory-intensive VM on a slow link never converges: the task shows a percentage crawling for an hour then fails with a switchover timeout. Remedies: more vmotion bandwidth (10G+), enable multiple-NIC vMotion, temporarily raise allowed concurrency, or quiet the workload. Watch esxtop on the source for NET utilisation during the attempt.
Storage vMotion stalls are usually the destination datastore: check its latency and queue depth during the task. A datastore at 100% utilisation by other workloads turns a 20-minute SvMotion into a failed two-hour one.
Where the truth lives
# destination host, during/after a failed attempt: tail -200 /var/log/vmkernel.log | grep -i -E 'vmotion|migrate' tail -200 /var/log/hostd.log | grep -i migrate # vCenter: the task's "recent tasks" pane keeps the exact pre-check that failed
The vmkernel log names the failed connection (IP and port); hostd names the admission decision. Pair them with the task message and you rarely need a support ticket.
Long-distance and cross-vCenter moves
Stretched-cluster and long-distance vMotion add latency as a failure source: check the documented RTT limit for your vSphere version before blaming configuration, and measure with a real TCP test between vmotion interfaces, not ICMP to management IPs. Cross-vCenter (XVM) migrations fail mostly on identity and naming: both vCenters must trust via the same or paired SSO domain, the VM's networks need explicit mapping when portgroup names differ, and certificate validity between the two vCenters shows up as opaque "connection" errors in the task. Treat an XVM failure as three questions in order: can the vCenters authenticate, do the networks map, does the destination pass the same pre-checks as an intra-cluster move?
What to watch so the next one pages early
Alarm on vmotion vmk interface errors and on vmk ping-RTT between hosts; track datastore latency p99 (SvMotion inherits it); and keep DRS recommendations visible — a cluster where DRS cannot place anything is a cluster whose vMotion path is about to be "tested" during an incident. After every switch firmware or port change, rerun the jumbo ping matrix; MTU regressions love change windows.
Grep targets in the vCenter and host logs
On the vCenter side, the task chain keeps the pre-check verdicts; on the host, these patterns separate the families quickly:
grep -i 'vmotion' /var/log/vmkernel.log | tail -50 grep -iE 'migrate|relocate' /var/log/hostd.log | tail -50 # vCenter: Recent Tasks → the failed migration → "Events" tab, # or ops logs: grep the task id in /var/log/vmware/vpxd/
A failed migration leaves the VM untouched — vMotion is transactional — so the cost of a failure is time and noise, not data. Treat repeated failures from one source host as a host problem (NIC, vmk, storage path) and failures to one destination as a destination problem; the matrix localises it in three attempts.
Prevention checklist
- Standardise vmotion MTU and test with the DF-bit ping after every switch change.
- Keep EVC mode deliberate; document which CPU generations may coexist.
- Alert on datastore latency so SvMotion doesn't inherit someone else's incident.
- Before maintenance-window mass migrations, run one test migration from each source host — pre-check failures discovered at 2 a.m. are a planning bug.