What Are the Requirements for VMware vMotion?

What are the requirements for VMware vMotion?

Start with four gates: CPU compatibility, a usable vMotion network, a storage decision, and the right migration entitlement. A live move fails when one gate is closed.

Each source and target host needs at least one interface configured for vMotion traffic. Broadcom's vMotion networking requirements set a floor of 250 Mbps of dedicated bandwidth for each concurrent vMotion session. Count simultaneous moves, not only total uplink speed.

Storage changes the shape of the move. With shared storage, compute vMotion moves the running workload between hosts while both hosts can reach its files. vMotion without shared storage also sends virtual-disk contents over the network. Storage vMotion is the fit when the host stays put and the VM's files need a new datastore.

For routed vMotion across IP subnets, Broadcom requires the vMotion TCP/IP stack. The same source sets the supported long-distance round-trip ceiling at 150 milliseconds when the appropriate license is applied. Routing is not a substitute for a tested path.

Write the intended source, target, datastore, port group, and vCenter before opening the migration wizard. The discipline is the same one used to turn an automation expo demo into a measurable AI pilot: name the dependency before the change exposes it.

Why does vMotion work when the VM is powered off but fail when it is running?

A powered-off VM does not need to preserve the CPU feature set it received at power-on. A running VM does.

Broadcom's CPU compatibility guidance states that the destination host must provide every CPU feature available to a powered-on or suspended VM before migration. Clock speed, cache size, and core count can differ. Required instructions cannot.

This explains the common split result. The cold move places files and configuration on another host. When the VM next powers on, it receives CPU features from that host. The live move must carry forward the feature set already visible to the guest.

EVC masks selected CPU features so different CPU generations from the same vendor can share a compatible baseline. Check the cluster EVC mode before the maintenance window. If the hosts cannot share the needed baseline, power off the VM for the move or keep it on a compatible host set.

Network faults can show the same broad symptom: cold works, live fails. Separate the tests. First read the compatibility check. Then test the vMotion VMkernel path. One success does not erase the other requirement.

Can I vMotion a VM between different clusters or vCenters?

Yes, if the target satisfies the VM's compute, storage, network, version, time, and licensing requirements. A new boundary adds checks; it does not remove the old ones.

For traditional cross-vCenter vMotion in Enhanced Linked Mode, the vCenter instances must be in the same Single Sign-On domain. Broadcom also requires vCenter and ESXi versions 6.0 or later, plus time synchronization between the two vCenters for token verification. A compute-only cross-vCenter move needs shared storage available to both vCenters.

Broadcom documents Advanced Cross vCenter vMotion for different SSO domains when the initiating vCenter is version 7.0 Update 1c or later. A powered-on move requires vSphere Enterprise Plus. A powered-off move requires vSphere Standard.

Network mapping deserves its own review. Broadcom's cross-vCenter network checks cover several switch and MAC compatibility cases, yet they do not confirm that source and target distributed switches share a broadcast domain. If they do not, the VM loses network connectivity after the move. An unchanged guest IP is useful only when the destination network can carry it.

Move the workload in the smallest safe scope. Compute-only when storage is already shared. Storage vMotion when files need a new datastore. Cross-vCenter only after the target network and control-plane conditions are explicit.