vMotion fails: telling CPU compatibility, device dependencies and the vMotion network apart

Direct answer: almost every vMotion failure falls into one of three classes, and the error text tells you which. "The target host does not support the virtual machine's current hardware requirements" is CPU feature compatibility, usually fixed with an EVC baseline. "Currently connected device ... uses backing ..., which is not accessible" is a device or file the destination host cannot reach, usually an ISO on local storage, a client-side device or a USB device not enabled for vMotion. "The ESX hosts failed to connect over the vMotion network", "Timeout", "Connection refused" or the misleading "amount of changing memory ... greater than the available network bandwidth" point to the vMotion vmkernel path, tested with vmkping at the configured MTU with don't-fragment set. Read the compatibility check result in the migration wizard first. It is the cheapest evidence you have and it costs nothing to rerun.

Why it matters

vMotion underpins maintenance mode, DRS balancing and host patching. When it fails, the usual symptom is a host that will not evacuate or a patch window that overruns. The temptation is to change the most visible thing: enable EVC, change the MTU, or power off the VM. Each of those has side effects. Lowering EVC can force power-offs. Changing an MTU can break other traffic on the same switch. Classifying the failure first means you change only the layer that is actually wrong.

New hosts are the commonest trigger. A newer CPU generation joins a cluster without EVC, VMs powered on there pick up features the old hosts lack, and they can no longer move back.

How it works

CPU compatibility. A running VM sees a set of CPU features determined when it powered on. vMotion requires the destination host to offer at least those features. Broadcom KB 318962 lists the kinds of features that commonly appear in the compatibility result across hardware generations: AVX-512 variants, XSAVES/XSAVEC, PKU and speculative-execution mitigation bits such as MDS_NO and IBRS_ALL. It notes that hosts with different microcode can differ even within one cluster.

Enhanced vMotion Compatibility (EVC) masks every host in a cluster down to a chosen baseline, so all VMs see the same features. The Broadcom EVC FAQ (KB 313545) is explicit about timing: a VM determines its features at power-on, and does not get the features of a higher EVC mode until it is cold power-cycled. A guest reboot is not enough.

The vSphere documentation sets out the power requirements for cluster EVC changes:

The same page warns about snapshots: if you snapshot a running VM before an EVC downgrade, reverting to that snapshot afterwards fails and leaves the VM suspended. A snapshot taken before an EVC upgrade can be reverted either side of the upgrade. It also documents vmx.reboot.powerCycle, which makes a guest-initiated reboot become a full power cycle so a raised mode takes effect at the next reboot.

Per-VM EVC makes the EVC mode a property of the VM rather than the cluster, which helps with a single VM that must move between clusters of different generations. KB 318962 offers it as one of two options, next to cluster EVC, and notes that any EVC change takes effect on a VM only after a full power-cycle (power off, then power on). This article does not set out the per-VM configuration procedure; follow the vSphere 8 documentation for your build. Treat it as a scoped exception, not a cluster design.

Device dependencies. KB 324829 explains the "currently connected device uses backing which is not accessible" error: a connected CD-ROM, floppy, serial or parallel device whose backing is not reachable from the destination, typically an ISO on a datastore the destination does not mount. KB 307455 covers USB passthrough: a connected USB device must have been added with "Support vMotion while device is connected", or migration fails.

vMotion network. Each host needs a vmkernel adapter tagged for vMotion with a unique IP. Broadcom KB 1030264 (troubleshooting vMotion network errors) lists the error variants above, notes that vMotion listens on TCP port 8000, that "Network Unreachable" suggests source and destination on different subnets (not allowed in default configurations), and that enabling vMotion on more than one adapter, such as management and vMotion, can cause the hosts to pick mismatched interfaces. It also states that network misconfiguration can cause random vMotion failures where a retry succeeds. A retry that works is not evidence that the network is fine.

Read-only checks

None of these was run for this article. They read state or send test packets on the vMotion network only.

1. Compatibility check. Start the migration wizard to the intended destination and stop at the compatibility step. Copy the full text of any error or warning. Note whether it names CPU features, a device and backing path, or the network.

2. Task error and events. In the failed task's details and the VM's events, record the exact message and migration ID. On the hosts, /var/log/hostd.log (and the VM's vmware.log) carry the same migration ID.

3. EVC state. For the cluster: Configure > VMware EVC shows the current mode. For a VM: the Summary or the cluster's VMs view shows the VM's EVC mode. A VM showing a higher mode than the destination supports explains why it cannot move to an older host. A VM with no EVC mode is not proof of incompatibility on its own: what matters is the CPU feature set it actually powered on with, and the compatibility result the migration wizard reports for the chosen destination.

4. CPU generations. Note each host's CPU model and look up its supported EVC modes in the Broadcom Compatibility Guide (CPU series > Enhanced vMotion Capability Modes), as KB 318962 describes. The highest baseline common to every host is the candidate cluster mode.

5. Connected devices. In the VM's Edit Settings, check CD/DVD, floppy, serial and parallel devices for "connected" status and datastore paths, and any USB devices for the vMotion option.

6. vMotion vmkernel path. Per KB 344313, identify on each host the vmkernel adapter tagged for vMotion and its MTU (Configure > VMkernel adapters), the uplink carrying it (esxtop, then n) and, where available, the physical switch port via CDP/LLDP. Then, from an SSH session on the source host:

vmkping -I vmkN <destination vMotion IP> -s <MTU minus 28> -d -c 3

Add -S vmotion if the adapter uses the vmotion TCP/IP stack. For a 9000-byte MTU the payload is 8972; for 1500 it is 1472. Test in both directions, and repeat for every host pair involved.

Interpreting the results

Decision guidance

Device class. This is the lowest-risk fix. Disconnect the CD/DVD device or switch it to a client device, or place the ISO on a datastore shared by every host. For USB, follow KB 307455: eject in the guest, remove the device, and re-add it with vMotion support. Rollback is reconnecting the device.

Network class. Fix the specific mismatch: a VLAN missing on a switch port, a vmkernel IP conflict, vMotion tagged on an adapter that was never meant to carry it or on endpoints that do not match between hosts, or an MTU that differs between vmkernel adapter, virtual switch and physical switches. A deliberately designed multi-NIC vMotion layout, with several adapters tagged on purpose and consistent on every host, is not a fault; remove a tag only where it was unintended. Change MTU only after confirming the whole path supports it; an MTU change on a shared virtual switch affects every port group on it. Verify with vmkping -d at the full payload in both directions, then a test migration of a non-critical VM.

CPU class, cluster EVC.

• Enabling or raising EVC when all hosts support the target baseline can be done with VMs running. VMs keep their current feature set until they are cold power-cycled, so plan power cycles (or set vmx.reboot.powerCycle) if the goal is for VMs to use new features.
• Lowering EVC, or enabling it for the first time at a baseline below the CPU features some running VMs already expose, requires those VMs to be powered off. Enabling EVC at a baseline that every running VM's current feature set fits within is the online case above. That is an outage. Snapshots of running VMs taken before the downgrade cannot be reverted afterwards.
• Adding a newer host to an EVC cluster is the normal way to mix generations: the new host is masked to the cluster mode.

Before any EVC change, record the current mode and the per-VM modes. Rollback for a raise is lowering again, which brings back the power-off requirement for any VM that has been power-cycled into the higher mode.

CPU class, per-VM EVC. Consider it for a specific VM that must cross between clusters of different generations, as KB 318962 suggests, and plan the full power-cycle any EVC change needs. Confirm the configuration steps and prerequisites in the vSphere 8 documentation for your build. Document why, because it outlives the migration.

What not to do

• Do not power-cycle or migrate production VMs to "test" before reading the compatibility result.
• Do not lower a cluster EVC mode on a running cluster without a power-off plan for every VM above the new mode.
• Do not revert a running-VM snapshot taken before an EVC downgrade.
• Do not change the MTU on one side only, or on a shared switch, to make vmkping pass.
• Do not enable vMotion on the management adapter as a workaround for a broken vMotion network.
• Do not treat a successful retry as proof the network is healthy.

Limitations

This article covers vMotion between hosts managed by one vCenter. Cross-vCenter migration, encrypted vMotion requirements, vGPU and passthrough PCI devices, and long-distance migration timeouts are out of scope, and default vMotion timeouts were not verified for this article. This article does not describe how per-VM EVC is configured or how it interacts with cluster EVC, because that documentation could not be retrieved in full for this article. EVC baselines change with each processor generation; always use the current Broadcom Compatibility Guide rather than a list in an article.

Acceptance checklist

• [ ] Compatibility check and task error text captured in full
• [ ] Failure assigned to CPU, device or network class from that evidence
• [ ] Device class: device disconnected, backing moved to shared storage, or USB re-added with vMotion support
• [ ] Network class: vmkping -d -s <MTU−28> succeeds both ways between every relevant host pair
• [ ] CPU class: common baseline chosen from the Compatibility Guide; power-off needs listed per VM before any EVC lowering
• [ ] No snapshots of running VMs being relied on across an EVC downgrade
• [ ] Test migration of a non-critical VM succeeds before production moves

References

All accessed 2 November 2026. Broadcom article update dates were not displayed.

• Broadcom KB 313545, "VMware EVC and CPU Compatibility FAQ": https://knowledge.broadcom.com/external/article/313545/vmware-evc-and-cpu-compatibility-faq.html
• Broadcom KB 318962, "The target host does not support the virtual machine's current hardware requirements": https://knowledge.broadcom.com/external/article/318962/the-target-host-does-not-support-the-vir.html
• Broadcom TechDocs, vSphere 7.0, "Change the EVC Mode for a Cluster": https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vcenter-and-host-management/migrating-virtual-machines-host-management/cpu-compatibility-and-evc-host-management/change-the-evc-mode-for-a-cluster-host-management.html
• Broadcom KB 344313, "Testing VMkernel network connectivity with the vmkping command": https://knowledge.broadcom.com/external/article/344313/testing-vmkernel-network-connectivity-wi.html
• Broadcom KB 1030264 (legacy ID), "Troubleshooting vMotion Network related errors": https://knowledge.broadcom.com/external/article?legacyId=1030264
• Broadcom KB 324829, "VMotion fails with the compatibility error: Currently connected device uses backing which is not accessible": https://knowledge.broadcom.com/external/article/324829/vmotion-fails-with-the-compatibility-err.html
• Broadcom KB 307455, "vMotion fails when USB passthrough devices reside on the virtual machine": https://knowledge.broadcom.com/external/article/307455/vmotion-fails-when-usb-passthrough-devic.html

Related articles

• How to design and troubleshoot VMware networking
• How to build and validate a VMware private-cloud cluster

• How to find and fix ESXi CPU and memory bottlenecks

• ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause

Learning notes

1. The compatibility check names the failing class; read it before changing anything.
2. A VM's CPU features are fixed at power-on; only a cold power cycle changes them.
3. Raising EVC is online; lowering it needs affected VMs powered off.
4. Test the vMotion path with vmkping -d at MTU minus 28, in both directions, on the vMotion adapter and stack.
5. Device errors are usually an ISO or USB device, the cheapest class to fix.