VMware ESXi and vSphere Cluster Management

How vSphere vMotion Works: Live Virtual Machine Migration Process

Learn how VMware vSphere vMotion moves a running VM between ESXi hosts, including memory pre-copy, dirty pages, switchover, network continuity, requirements, and troubleshooting.

vMotion is a VMware vSphere capability that live-migrates a powered-on virtual machine from one ESXi host to another. During most of the operation, the guest operating system and its applications continue running. The VM's compute execution moves to the destination host while the VM keeps its logical identity, including its virtual hardware configuration and network identity.

This lesson follows the complete migration sequence, explains memory pre-copy and dirty-page tracking, and shows how to validate and troubleshoot a migration.

What vMotion Moves

A running VM is more than a collection of virtual disk files. To continue execution on another host, vMotion transfers or recreates the VM's active runtime state, including:

Active guest memory contents.
Virtual CPU execution state, such as registers and other information needed to resume instruction execution.
Virtual device and firmware-related state, including relevant BIOS or firmware state.
Virtual device connections and runtime information required by the destination host.
The VM configuration needed to present compatible virtual hardware on the destination.
The existing virtual network identity, including the VM's MAC address.

Changing physical hosts does not automatically give the VM a new MAC address or IP configuration. The guest normally continues using the same network identity after the move.

Participants and Migration Paths

A vMotion operation has both a coordination path and a data path.

Migration initiator: An administrator in the vSphere Client, a script, or an automation system requests the move.
vCenter Server: Coordinates the operation, checks compatibility, selects or validates hosts, and reports task progress. The ESXi hosts perform the runtime work.
Source host: The ESXi host currently executing the VM.
Destination host: The ESXi host that prepares to receive and execute the VM.
VMkernel adapters: ESXi interfaces configured with the vMotion service.
Physical network: Switches, links, and possibly routed paths that carry vMotion traffic between the VMkernel interfaces.

The management plane coordinates the request and state of the task. The data path carries memory pages and runtime state from the source host to the destination over the configured vMotion network. Keeping these concepts separate helps troubleshooting: a vCenter task can be healthy while the vMotion data path has insufficient bandwidth or broken reachability.

End-to-End vMotion Process

The exact implementation details vary by vSphere version and VM configuration, but the operational sequence follows these phases.

Migration initiation: The administrator or automation system selects a destination host and starts a migration task.
Prechecks: vCenter evaluates host CPU compatibility, licensing and feature support, VM networking, storage accessibility, device dependencies, and destination capacity.
Destination preparation: The destination reserves resources and creates the required execution context for the VM. It prepares compatible virtual devices, memory structures, and network connections without taking over execution yet.
Initial memory pre-copy: The source copies the VM's memory pages to the destination while the VM continues running.
Dirty-page iterations: Pages changed after earlier copy passes are tracked and copied again. Multiple rounds reduce the amount of memory still different between the hosts.
Quiesce and switchover: The source briefly stops VM execution and request servicing. This is commonly called the stun or quiesce phase.
Final state transfer: Remaining changed memory pages and final CPU, virtual device, and runtime state are transferred.
Destination execution: The destination activates the VM and resumes guest execution.
Network announcement: The destination sends a network notification, including RARP behavior where applicable, to help upstream devices learn the VM's new physical path.
Source cleanup: After the destination is confirmed to be running the VM, the source releases the VM's consumed memory and other runtime resources.

Migration Phases at a Glance

Phase — Primary action — VM availability — State transferred or updated — Result

Migration initiation — A user or automation system requests the move — Available — Request and target information — A migration task begins.

Destination preparation — The target builds a compatible execution context and reserves resources — Available — Virtual hardware, memory structures, and connections are prepared — The target is ready for incoming state.

Initial memory pre-copy — Memory pages are copied while the source continues execution — Available — Current memory contents — The destination receives the first memory image.

Dirty-page copy iterations — Changed pages are recopied — Available — Pages identified by dirty-memory tracking — Source and destination memory differences shrink.

Quiesce and final state transfer — The source pauses execution briefly and sends remaining state — Brief interruption — Final memory changes, CPU state, and virtual device state — A consistent handoff point is established.

Destination execution — The target starts the VM — Available after resume — Execution continues from the transferred state — The destination becomes the active host.

Network announcement — The VM's new physical location is announced — Available, with possible brief packet effects — Forwarding information is refreshed — Traffic is directed toward the destination path.

Source resource cleanup — The source discards its active runtime allocation — Available — Source-side memory and execution resources — The VM no longer runs on or consumes active runtime resources from the source.

Memory Pre-Copy and Dirty-Page Tracking

Memory pre-copy is the initial and repeated transfer of VM memory while the workload is still executing on the source host. The guest continues running because stopping it for the entire memory transfer would not be a live migration.

Suppose a VM has memory pages A, B, C, and D. The source copies all four pages. While the guest continues running, it modifies B and D. Those pages are now dirty pages: memory pages changed after they were copied. The source records changed-page information in a memory bitmap, or an equivalent tracking structure, and sends B and D again in a later iteration.

The source copies an initial set of memory pages.
The VM continues executing and writing to memory.
The source marks modified pages in its dirty-page tracking data.
The source recopies the marked pages.
The process repeats until the remaining changed state is small enough for the final switchover, or until vMotion cannot converge efficiently.

Migration duration depends on the VM's configured memory size, the guest's memory write rate, and the effective vMotion bandwidth. A large VM that continuously changes memory can generate dirty pages as quickly as the network copies them. More bandwidth, less competing traffic, or a quieter workload can improve convergence.

Quiescing, Switchover, and Stun Time

Quiescing in this context means briefly stopping VM execution or request servicing so the source can create a consistent final state. The interruption is normally short, but it is not guaranteed to be zero. The period is often called stun time.

The VM must pause because the source cannot safely send a final CPU state, device state, and memory image while those values are changing indefinitely. During the switchover, vMotion transfers remaining dirty pages and final virtual CPU and virtual device state. Once the destination has all required state, it can safely resume execution.

Excessive dirty-page generation, packet loss, congestion, or inadequate bandwidth can make the final set of pages difficult to transfer. The result may be longer stun time, a migration that takes many iterations, or a migration that fails before cutover.

How the Destination Completes Memory

The destination cannot safely execute the VM until it has the memory contents required for the transferred execution state. Dirty-memory tracking identifies addresses associated with pages that changed or remain outstanding.

The source determines which pages are still different or required.
The destination requests, or the source sends, those remaining page contents over the vMotion data path.
The source transfers the final page set while execution is paused.
The destination validates or assembles the completed memory state with the transferred CPU and device state.
The destination starts the VM only after the required state is available.

Network Continuity After Host Movement

The VM normally keeps its same MAC address and IP configuration. The logical interface remains the same even though its traffic now exits through a different ESXi host and physical switch port.

After the VM starts on the destination, vSphere and the virtual networking stack issue a network announcement. This can include a Reverse Address Resolution Protocol (RARP) notification. The objective is to refresh switch MAC-learning information and relevant neighbor or ARP forwarding information so traffic is sent toward the destination uplink rather than the old source path.

There can still be short-lived effects. A switch may briefly retain a stale MAC table entry, a security policy may reject a MAC move, or a packet may be lost during forwarding convergence. These effects should normally be brief, but they must be considered for latency-sensitive applications.

Requirements and Environmental Dependencies

Requirement area — What must be available or compatible — Why it matters

vCenter and host management — Source and destination ESXi hosts should be managed in a supported vCenter configuration — vCenter coordinates checks and the migration task.

vMotion-enabled VMkernel networking — Each host needs a VMkernel adapter with vMotion enabled — This supplies the migration data path.

Network reachability and MTU — VMkernel addresses must communicate through a correctly configured Layer 2 or Layer 3 path, with consistent MTU — Broken routing, VLANs, firewalls, or MTU settings can stop or slow the transfer.

Destination port group access — The target host must see compatible virtual networks and port groups — The VM must be able to connect to its intended network after cutover.

Storage accessibility — With standard compute vMotion, required datastores are generally accessible from both hosts — The destination must access the VM's virtual disks and related files. Storage migration options can move storage when shared access is not the design.

CPU and EVC compatibility — Host CPUs must be compatible, or a suitable Enhanced vMotion Compatibility configuration must mask supported differences — The destination must be able to resume the VM's instruction set safely.

Destination capacity — The target needs sufficient CPU, memory, reservations, and admission capacity — The destination must run the VM without violating resource constraints.

Feature and licensing support — Hosts, vCenter, VM features, and licenses must support the selected migration operation — Unsupported features or licensing can fail prechecks.

DRS, or Distributed Resource Scheduler, may recommend or automate vMotion based on cluster placement and load. DRS is not required for a manually initiated vMotion.

Standard vMotion and Related Features

Feature — Primary item moved — Typical storage expectation — Typical use case

vMotion — Running VM compute state, including memory and execution state — VM storage is normally accessible from both hosts — Move a running VM for maintenance, balancing, or placement.

Storage vMotion — VM virtual disk files and related storage placement — Storage is relocated between supported datastores — Change datastore placement while the VM remains available.

Combined compute and storage migration — Compute state and storage placement — Source and destination storage paths may differ — Move a running VM to another host and datastore in one workflow when supported.

Cross-vCenter vMotion — A running VM across vCenter boundaries — Storage and networking depend on the selected cross-vCenter design — Move workloads between vCenter environments or sites.

Operational Planning

Use a dedicated or appropriately isolated vMotion network when possible. Isolation reduces competition with management, guest, and storage traffic.
Provide sufficient bandwidth for the VM memory footprint and workload write rate. Check link speed, uplink utilization, errors, and packet loss.
Keep latency and routing predictable. A Layer 3 vMotion design can work when supported and correctly routed; it still requires end-to-end reachability.
Use jumbo frames only when every hop supports the selected MTU. A single lower-MTU link can cause fragmentation, drops, or failed tests.
Maintain CPU and memory headroom on the destination. A host that technically has capacity but is under heavy pressure may produce poor operational results.
Expect high-memory-write workloads, such as busy databases, to require more iterations or a quieter migration period.
Before migration, verify the selected destination, compatibility results, datastore visibility, port group access, and destination resources.
During migration, monitor the vCenter task, iteration progress, transfer rate, stun time, and any warnings.
After migration, verify VM power state, guest heartbeat where available, application connectivity, DNS or gateway reachability, and expected switch forwarding.

vSphere Client Configuration and Validation

Create or identify a VMkernel adapter on each participating ESXi host.
Enable the vMotion service on the relevant VMkernel adapters.
Place the adapters on networks with end-to-end reachability between hosts.
Ensure consistent MTU values across VMkernel interfaces, virtual switches, distributed switches, physical switches, and routed links when jumbo frames are used.
Confirm that the destination host can access required port groups and datastores.
Use the vSphere Client's Migrate workflow to choose the destination, review compatibility checks, and monitor the task.

Example ESXi validation commands:

esxcli network ip interface list

Lists VMkernel interfaces and their addressing and interface configuration.

esxcli network ip interface tag get -i vmkX

Shows services enabled on a selected VMkernel interface. Replace vmkX with the actual interface.

vmkping <destination-vmkernel-ip>

Tests VMkernel reachability between ESXi hosts.

vmkping -d -s 8972 <destination-vmkernel-ip>

Tests a non-fragmented jumbo-frame path when an end-to-end 9000-byte MTU design is intended. Replace the destination address with an actual VMkernel IP.

esxcli network nic list

Reviews physical NIC link state and speed for the relevant network.

Factors Affecting Duration and Stun Time

Factor — Effect on migration — Typical symptom — Planning or remediation action

VM configured memory — More memory requires more data to transfer — Longer initial copy — Schedule appropriately and provide enough bandwidth.

Guest memory write rate — More writes create more dirty pages — Many iterations or failure to converge — Reduce workload activity temporarily or migrate during a quieter period.

vMotion bandwidth — Higher effective throughput transfers pages faster — Slow progress or prolonged stun — Increase link capacity and reduce competing traffic.

Network congestion or packet loss — Retransmissions reduce effective throughput — Unpredictable duration and task warnings — Check uplinks, errors, queues, and competing traffic.

MTU mismatch — Frames may fragment or be dropped — Failed jumbo tests or slow migration — Make MTU consistent end to end or use standard MTU.

Destination resource pressure — Preparation and activation may be delayed or rejected — Admission or capacity errors — Select a host with adequate CPU and memory headroom.

CPU compatibility — Unsupported instructions prevent safe resume — Precheck failure — Use a compatible host or configure appropriate EVC.

Limitations and Failure Safety

Not every running VM can migrate under every combination of host hardware, networking, storage, devices, and configuration. Common blockers include attached physical devices, host-local resources, incompatible CPU features, unavailable destination networks, inaccessible datastores, unsupported VM features, and connectivity failures.

Read the detailed compatibility result rather than relying only on the general task status. If a migration fails before successful cutover, the expected safety behavior is that the VM remains running on the source host. The source should not release active state until the destination is confirmed to be executing the VM.

Troubleshooting Common Problems

vMotion Networking Is Unavailable

Likely causes: vMotion is not enabled on one or both VMkernel adapters, the VMkernel addresses cannot reach each other, or VLAN, routing, firewall, or TCP/IP stack settings are incorrect.

List VMkernel interfaces and verify service tags.
Run vmkping from the source to the destination VMkernel address.
Validate VLAN membership, physical uplinks, routing, and permitted traffic.
Correct the VMkernel service configuration and restore end-to-end reachability.

Jumbo-Frame Migration Is Slow or Fails

Compare MTU values on both VMkernel adapters, virtual switches, distributed switches, physical switches, and every routed link. Run a non-fragmented vmkping test with a payload appropriate for the intended MTU. Either provide consistent support end to end or return the vMotion path to standard MTU.

The Migration Takes a Long Time or Cannot Converge

Check the VM's memory write activity, migration task timing, vMotion throughput, uplink utilization, errors, and packet loss. A large memory footprint combined with a high write rate can continually recreate dirty pages. Increase available bandwidth, remove congestion, reduce competing traffic, or migrate during a lower-activity period.

The Destination Host Is Incompatible

Review the detailed vCenter compatibility message. Check CPU generation and EVC settings, destination port group access, datastore visibility, and host-specific device dependencies. Select a compatible host or correct the CPU, network, storage, or device dependency.

Connectivity Is Inconsistent Immediately After Migration

Verify the VM is connected to the expected destination port group. Review switch MAC tables, port-security settings, uplink configuration, and network policies. Test guest connectivity and upstream gateway reachability. Correct switch or port-group configuration so the VM MAC move can be learned.

Practical Examples

Planned ESXi Host Maintenance

An administrator moves a running application VM from esx01 to esx02 before placing esx01 into maintenance mode. Memory is copied over the vMotion network, the VM pauses briefly for final cutover, and client traffic resumes through the same MAC and IP identity on esx02.

Memory-Intensive Workload

A large database VM continuously modifies memory. Initial pre-copy completes, but many pages become dirty during every round. Additional vMotion bandwidth, reduced write activity, or migration during a quieter period can improve convergence.

Shared-Storage Compute Migration

The VM's virtual disks remain on a datastore visible to both hosts. vMotion moves the active compute, memory, CPU, and runtime state while storage files stay in place.

Destination Compatibility Failure

A precheck fails because the destination cannot access the VM's configured port group or because CPU compatibility requirements are not met. The VM remains on the source until the dependency is corrected.

Exam-Relevant Summary

vMotion is live migration of a powered-on VM between ESXi hosts.
Memory pre-copy occurs while the VM continues running.
Dirty pages are modified after an earlier copy and must be recopied.
The source briefly quiesces or stuns the VM for final state transfer.
The destination starts execution only after required memory and runtime state are complete.
The VM normally retains its MAC address and IP configuration.
A network announcement helps update forwarding information after host movement.
The source releases runtime resources only after successful destination activation.
Shared storage is normally expected for standard compute vMotion; Storage vMotion moves disk files.
DRS can automate or recommend vMotion but is not required for a manual migration.
If cutover does not succeed, the VM should remain running on the source.

For a related reference, see vSphere vMotion Process.