VMware ESXi and vSphere Cluster Management

vSphere vMotion Explained: Live Migration Between ESXi Hosts

Learn how vSphere vMotion moves running virtual machines between ESXi hosts, including prerequisites, migration phases, use cases, limitations, validation, and troubleshooting.

vMotion is VMware vSphere’s live migration capability. It moves the compute execution of a powered-on virtual machine from one ESXi host to another while the workload remains available.

An ESXi host is a physical server running the VMware hypervisor. vCenter Server is the centralized vSphere management platform that coordinates operations such as vMotion across managed hosts.

What vMotion Does

During a successful vMotion, the VM’s execution state moves from a source ESXi host to a destination ESXi host. The guest operating system and its applications continue running during most of the operation.

The migration transfers important runtime information, especially the VM’s in-memory state. The VM’s configuration identity remains consistent, including its virtual hardware settings, virtual devices, and network identity such as its MAC address. The virtual machine remains the same logical VM in vCenter; only its compute host location changes.

Users and applications should normally experience no planned outage. There is a brief final cutover, called the stun time, when execution pauses and resumes on the destination. Existing network sessions are intended to remain connected because the VM retains its network identity and the virtual networking environment continues to provide connectivity.

“No downtime” is a design goal, not an unconditional guarantee. Success and minimal interruption depend on compatible hosts, healthy vMotion networking, sufficient destination resources, accessible storage, and a supported VM configuration.

How a vMotion Migration Works

Phase	What occurs	VM execution status	Administrator consideration
Compatibility validation	vCenter checks host CPU compatibility, resources, storage, networks, VM devices, and other requirements.	Running on the source	Resolve reported errors before starting a production migration.
Destination preparation	The destination host prepares CPU, memory, virtual devices, networking, and access to required VM resources.	Running on the source	Confirm capacity and port-group and datastore availability.
Initial memory copy	VM memory pages are copied from the source to the destination while the VM continues executing.	Running on the source	Bandwidth and latency affect copy speed.
Iterative dirty-page copying	Pages changed during copying are copied again. These changes are called memory dirtying.	Running on the source	High memory write rates can prevent the migration from converging.
Final switchover	The VM is briefly stunned, final state is transferred, and execution switches to the destination.	Briefly paused, then running on the destination	Monitor task progress and expected application sensitivity.
Source cleanup	After the destination resumes the VM, temporary source-side state is released.	Running on the destination	Verify host placement, connectivity, and application health.

Pre-copy and memory dirtying

The main transfer phase is called pre-copy. vMotion copies memory while the VM continues to run. Because the guest OS and applications keep changing memory, some pages become modified after they were copied. vMotion tracks and recopies those dirty pages.

If the VM changes memory faster than the network can transfer it, repeated copying can take a long time or fail to converge. This is more likely for workloads with high memory write activity, such as some databases, analytics systems, and busy application servers.

The final switchover

When the remaining changed pages and execution state can be transferred quickly enough, vMotion briefly pauses the VM. This is the stun time. The destination takes over execution, network processing resumes there, and the source host cleans up its temporary state.

Migration Types and Scope

Method	VM power state	What moves	Typical storage requirement	Typical use case	Expected service impact
vMotion	Powered on	Compute execution state, including active memory and runtime state	Both hosts typically need access to the same shared datastore	Host maintenance or workload balancing	Normally no planned outage; brief switchover
Storage vMotion	Powered on	Virtual disks and VM files between datastores	Source and destination storage must be accessible through the supported workflow	Storage maintenance, tiering, or datastore balancing	Normally no planned outage
Cold migration	Powered off	VM placement and, where selected, storage	Depends on the selected destination and migration options	Moving unsupported or stopped workloads	Requires downtime while powered off
Compute and storage migration	Powered on when supported	Running compute state plus virtual disks or files	Does not require the same shared datastore in every supported design, but needs suitable storage and migration networks	Moving a running VM between hosts and storage locations	Normally brief switchover; has greater network and storage demands

Compute-only vMotion moves the running execution state while virtual disks remain on shared storage. A shared datastore is a datastore accessible by both the source and destination ESXi hosts, such as a supported VMFS or NFS datastore.

Some supported workflows move compute and storage together. These are often discussed with Storage vMotion or shared-nothing migration. Availability depends on the vSphere version, licensing, storage design, hardware, and configuration.

vMotion is different from Storage vMotion. vMotion primarily relocates running compute execution between hosts; Storage vMotion relocates virtual disks and files between datastores. Cross-vCenter and long-distance migration features extend migration scenarios, but their support and requirements depend on the current vSphere version and configuration.

vMotion Prerequisites

Requirement	Why it matters	How to verify	Common failure symptom
vCenter management	Standard vMotion workflows are coordinated through vCenter Server-managed ESXi hosts.	Confirm both hosts are connected and managed in the appropriate vCenter inventory.	Migration action is unavailable or host coordination fails.
vMotion-enabled VMkernel connectivity	Hosts need reachable VMkernel endpoints for transferring runtime state.	Check the vMotion service on a VMkernel adapter and test host-to-host reachability.	No usable vMotion network path.
Destination CPU and memory capacity	The destination must be able to run the VM without unsafe overcommit or resource failure.	Review cluster and host capacity, reservations, limits, and current contention.	Insufficient resources or failed destination preparation.
CPU compatibility or EVC	The destination must expose a compatible CPU feature set to the guest.	Review CPU families and cluster Enhanced vMotion Compatibility (EVC) settings.	CPU feature mismatch or compatibility warning.
Shared datastore access when required	Compute-only vMotion requires both hosts to access the VM’s files.	Compare datastore visibility, paths, permissions, and storage health.	Destination cannot access VM files.
Destination VM network and port group	The VM must retain access to the required virtual network.	Confirm standard or distributed port group, VLAN, uplinks, and host membership.	Network loss after migration or unavailable destination network.
MTU, routing, latency, and bandwidth consistency	Reliable transport is needed for rapid memory transfer.	Check end-to-end switch configuration, routes, MTU, packet loss, and utilization.	Slow migration, timeout, or failed network validation.
Supported VM device configuration	Passthrough hardware and special virtual devices can restrict mobility.	Review compatibility messages and attached hardware settings.	Unsupported device or VM configuration error.

Host management and networking

Both ESXi hosts should be reachable and correctly managed by vCenter Server. Each participating host needs a VMkernel adapter with the vMotion service enabled. A VMkernel adapter is an ESXi networking interface used for host services such as management, storage, or vMotion.

Layer 3 routing can support vMotion between subnets when the vSphere and network design support it. The vMotion VMkernel endpoints still require reliable bidirectional connectivity, appropriate firewall rules, correct routes, and consistent MTU behavior.

A common design uses a dedicated or appropriately isolated vMotion network. Separating vMotion traffic from management, VM production traffic, and storage traffic reduces contention and limits the effect of a problem in one traffic class. Isolation can use separate VLANs, physical or logical uplinks, traffic policies, or other supported network controls.

CPU compatibility and EVC

Different processor generations may expose different CPU features. A VM started on one host might therefore be unable to run on another host unless the exposed feature set is compatible.

Enhanced vMotion Compatibility (EVC) provides a common CPU feature baseline to VMs across hosts with differing processor generations. EVC must be planned and configured according to supported host and cluster combinations. Always read the exact vCenter compatibility result before changing CPU or EVC settings.

Storage and virtual networking

For traditional compute-only vMotion, both hosts need access to the VM’s datastore and files. Verify datastore presentation, mounts, permissions, storage paths, and multipathing health.

The destination must also provide the VM’s required port group. Check standard or distributed switch membership, VLAN availability, physical uplinks, trunking, and any distributed switch compatibility requirements. Consistent network and storage presentation across cluster hosts makes mobility predictable.

Version, licensing, and hardware constraints

vMotion capabilities vary with vSphere version, product edition, licensing, host hardware, virtual hardware version, storage type, network design, and attached devices. Verify current VMware compatibility and licensing documentation for the exact environment, especially for cross-vCenter, long-distance, shared-nothing, encryption, passthrough, and special device scenarios.

Network and Storage Design Considerations

Bandwidth: Size vMotion links for the memory footprint and expected migration concurrency. Multiple simultaneous migrations can compete for the same link.
Latency and packet loss: Low, predictable latency and minimal packet loss help memory-copy rounds complete efficiently.
MTU: If jumbo frames are intentionally used, configure and test the MTU consistently across VMkernel interfaces, switches, routing, and physical uplinks. A mismatch can cause failures or inefficient traffic.
Redundancy: Use supported redundant uplinks and paths so a single adapter, cable, or switch failure does not remove vMotion connectivity.
VLAN and port-group consistency: Required VM and VMkernel networks must exist and be correctly mapped on every possible destination host.
Storage accessibility: Traditional vMotion depends on shared datastore access. Migrations without shared storage add storage-transfer traffic and require adequate source and destination storage performance.
Traffic separation: Separate vMotion from management, production VM, and storage traffic when practical. If sharing infrastructure is necessary, use capacity planning and supported traffic controls.

Operational Use Cases

Planned host maintenance

Before replacing hardware, applying firmware, or shutting down an ESXi host, an administrator can evacuate its running VMs with vMotion. After the host is empty, it can enter maintenance mode. Once work is complete, VMs may be migrated back, but returning them is an operational choice rather than a requirement.

Cluster balancing and DRS

If one host has sustained CPU pressure while another has available CPU and memory, an administrator can move a selected running VM to improve distribution. Distributed Resource Scheduler (DRS) can recommend or automate VM placement and vMotion-based balancing when enabled and licensed.

Early hardware or capacity concerns

Moving workloads away from a host that shows early hardware warnings, thermal concerns, failing components, or capacity pressure can reduce operational risk while the issue is investigated. This does not replace repairing the host or maintaining resilient applications.

Limitations and Planning Cautions

vMotion is not a backup. It does not provide point-in-time recovery or protect against accidental deletion.
vMotion is not replication or disaster recovery. A destination host in the same environment does not protect against a site-wide outage.
vMotion is not the same as vSphere High Availability (HA). HA restarts VMs after certain host failures; vMotion moves a running VM during a planned or controlled operation.
CPU incompatibility, missing networks, insufficient destination capacity, inaccessible storage, and unsupported devices can block a migration.
Passthrough hardware, certain virtual device configurations, and special workload requirements can restrict or prevent live migration.
High memory dirtying can make pre-copy slow or prevent it from converging.
Compatibility validation should be completed before a production migration. Do not rely on a generic retry when vCenter provides a specific reason.

How to Perform a Manual Migration

Check source and destination host health, alarms, maintenance state, CPU and memory capacity, and current contention.
Confirm vMotion-enabled VMkernel connectivity between the hosts. Verify routes, VLANs, MTU, bandwidth, packet loss, and firewall or switch configuration.
Confirm datastore access for the selected migration type. For compute-only vMotion, verify that both hosts can access the VM’s files.
Confirm destination access to the VM’s port group, VLAN, distributed switch configuration, and physical uplinks.
In the vSphere Client, select the powered-on VM and choose the migration action.
Select the appropriate migration type: compute-only, storage-only, or a combined compute-and-storage option supported by the environment.
Select the destination host or cluster and choose destination resources as requested by the wizard.
Review compatibility checks and resolve all blocking errors. Warnings should be understood before proceeding.
Finish the wizard and monitor Recent Tasks until the migration completes.

When introducing new hosts, processors, datastores, or network designs, first test with a noncritical workload. A controlled test validates the complete path without exposing a critical application to an unproven configuration.

Verification After Migration

Confirm the VM’s current ESXi host in vCenter Server.
Check guest operating system connectivity, including gateway and essential network services.
Perform an application-level test, such as a transaction, health check, or service query.
Review Recent Tasks, Events, and alarms for completion messages or warnings.
Confirm that expected datastore, port-group, virtual device, and policy assignments remain present.
Review host and VM performance if the migration was performed to address contention.

Command-Line Network Checks

These ESXi commands help verify VMkernel networking. Run them with appropriate privileges and substitute the destination VMkernel address for the placeholder.

esxcli network ip interface list

Lists VMkernel network interfaces and their addressing information.

esxcli network ip interface ipv4 get

Displays IPv4 configuration associated with VMkernel interfaces.

vmkping <destination-vmotion-vmkernel-ip>

Tests reachability between VMkernel interfaces. Use the appropriate source interface and MTU options for the environment when validating a routed or jumbo-frame design.

Troubleshooting Common Failures

Destination host is incompatible

Likely causes include a CPU feature mismatch, an unsupported virtual device, or missing destination network or datastore access. Read the specific vCenter compatibility message, compare CPU families, evaluate EVC requirements, and verify the destination’s port groups, datastores, and VM device support. Correct the reported incompatibility, choose a compatible host, or adjust EVC or VM configuration using supported procedures.

No usable vMotion network path

Check whether vMotion is enabled on a VMkernel adapter on both hosts. Inspect IP addressing, VLANs, switch trunking, routing, firewall rules, and MTU settings. Use vmkping to test VMkernel reachability. Restore valid connectivity before retrying the migration.

Migration is slow or does not complete

Possible causes include insufficient bandwidth, packet loss, high latency, a VM with a high memory write rate, or CPU and memory contention on either host. Review vMotion task details, host performance, network counters, and VM activity. Improve network capacity or reliability, choose a better destination, reduce workload churn where feasible, or schedule the migration during lower activity.

Destination cannot access VM files

Compare datastore visibility and storage paths between hosts. Check storage connectivity, permissions, presentation, and multipathing. If the destination cannot access the shared datastore, restore that access or select a supported workflow that also relocates storage.

VM loses network connectivity after migration

Confirm the VM’s port-group assignment and destination host membership. Validate VLAN availability, distributed switch settings, uplinks, and physical switch configuration. Test guest gateway and application connectivity, then correct the network mapping before using the destination for production workloads.

Exam-Relevant Notes

vMotion is live migration of a powered-on VM’s compute execution between ESXi hosts.
Pre-copy transfers memory while the VM runs; dirty pages may need repeated copying.
Stun time is the brief final pause during cutover to the destination.
Compute-only vMotion commonly requires shared datastore access from both hosts.
CPU compatibility, often managed with EVC, is separate from available CPU capacity.
vMotion networking uses VMkernel adapters, not the VM’s ordinary guest network interface.
Storage vMotion moves virtual disks and files; vMotion primarily moves running compute state.
Cold migration requires the VM to be powered off.
DRS can recommend or automate placement and vMotion, while HA addresses restart behavior after certain host failures.

Summary

vSphere vMotion relocates a running VM from one ESXi host to another while preserving workload availability. It prepares the destination, copies memory iteratively, transfers final state during a short switchover, and then cleans up the source. Reliable VMkernel networking, compatible CPUs, sufficient destination resources, accessible storage, and consistent virtual networking are the foundation of a successful migration.

Use vMotion for planned maintenance, workload balancing, and controlled host evacuation. Validate compatibility before production use, test unfamiliar designs with noncritical VMs, and remember that live migration complements rather than replaces backup, replication, disaster recovery, and high availability planning.