vSphere vMotion Migration Process Explained

Learn how vSphere vMotion moves a powered-on VM between ESXi hosts through memory pre-copy, dirty-page tracking, quiescing, final state transfer, destination resume, RARP, and cleanup.

What Is vSphere vMotion?

vSphere vMotion is a live migration mechanism that moves a powered-on virtual machine from one ESXi host to another. An ESXi host is the VMware hypervisor server that runs virtual machines.

The purpose of vMotion is to relocate where the VM executes while preserving its running state and minimizing service interruption. During most of the migration, the VM continues running and serving connected clients on the source host.

This lesson focuses on moving the VM's powered-on compute state between hosts. It is not a storage migration. Storage-related operations concern the VM's virtual disks and datastore placement, whereas vMotion primarily changes the ESXi host responsible for execution.

Participants and Migration Path

Administrator: Starts the vMotion task through vSphere.
Source ESXi host: Initially runs the powered-on VM.
Destination ESXi host: Receives the VM state and later starts execution.
vMotion network: Carries migration traffic, including memory and execution-state data.
Connected clients: Continue sending requests to the VM during the long pre-copy portion.

Connected clients
       |
       | application and network traffic
       v
+----------------------+       vMotion network       +----------------------+
| Source ESXi host    | ===========================> | Destination ESXi host|
| VM executes here    |  memory, changed pages,      | VM resumes here      |
|                     |  device and final state     |                      |
+----------------------+                              +----------------------+
       |                                                        |
       +------------------- brief handoff ---------------------+
                         RARP notification

The migration path is coordinated by vSphere, but the source and destination ESXi hosts perform the runtime state transfer.

What Makes Up Virtual Machine State?

Virtual machine state is the running information required to continue the same VM on another host. It includes memory contents, execution context, virtual hardware state, and identity-related information.

State component	Why it must be preserved	When it is transferred or used
Memory contents	Contains the guest operating system, applications, caches, and active workload data.	Copied during the initial and iterative pre-copy phases, then synchronized during handoff.
Modified-page bitmap	Identifies memory pages changed after they were copied.	Maintained by the source host to guide repeated copying and final synchronization.
Virtual device state	Allows virtual CPUs, disks, network adapters, and other virtual hardware to continue consistently.	Transferred with the final execution state before destination startup.
Virtual machine identity information	Ensures the destination continues the existing VM instead of creating a different instance.	Preserved throughout the handoff.
MAC address	Retains the VM's virtual network identity after the host changes.	Retained by the VM; the network is notified after destination startup.

The virtual BIOS configuration and virtual hardware context are examples of information that must remain consistent. The destination must receive enough memory and device state to resume the same execution, not merely boot a new VM.

Ordered vMotion Migration Process

1. The Administrator Initiates Migration

An ESXi or vSphere administrator starts a vMotion task and selects a destination host. At this point, vSphere validates the move and begins coordinating the source host, destination host, VM, and vMotion network.

Compatibility and configuration checks are separate operational concerns. For example, CPU compatibility can affect whether a destination is suitable; see CPU compatibility for vMotion and Enhanced vMotion Compatibility.

2. The Source Performs the Initial Memory Copy

The source host copies the VM's memory contents to the destination over the configured vMotion network. A memory page is a unit of memory tracked and transferred during synchronization.

The VM remains powered on and continues serving users during this phase. However, the first copy cannot be sufficient by itself: the guest operating system and applications continue changing memory while the copy is in progress.

3. Changed Pages Are Tracked and Recopied

The source maintains a memory bitmap, a record of memory pages modified during migration and still requiring synchronization. A modified, or dirty, page is a page changed after it was copied to the destination.

vMotion uses iterative copy, also called pre-copy. The source repeatedly copies dirty pages to the destination while the VM remains active:

Copy a set of VM memory pages.
Record pages changed during that copy.
Copy the changed pages in another pass.
Repeat until the remaining changes are small enough for a short handoff.

Migration convergence depends on the relationship between the VM's dirty-page rate and available vMotion bandwidth. A busy VM that modifies memory rapidly may require more passes. If the VM changes memory faster than the network can transfer it, the migration takes longer or may struggle to reach the handoff stage.

4. The Source VM Is Quiesced

After enough memory has been synchronized, the source VM is briefly quiesced. In this context, quiescing means stopping the VM from servicing client requests while the remaining execution state is finalized.

The VM remains resident in source memory during this transition, but it is no longer actively processing requests there. This is the short cutover window, not the entire migration duration.

5. Final Memory and Device State Are Transferred

During the handoff, the source transfers the remaining memory-change tracking information and the VM's virtual device state. Device state is the state associated with virtual hardware, such as virtual CPUs and virtual network adapters.

Device state must accompany memory state so the destination can continue the same VM with the same hardware context. Without it, the destination could not safely resume the VM's current execution.

6. The Destination Retrieves Outstanding Memory

The destination uses the bitmap information to identify memory addresses whose current contents are still needed. It requests the outstanding page contents from the source host and completes memory synchronization.

This dependency is important: the destination cannot safely resume execution until it has the required final memory and device state.

7. The Destination Resumes Execution

Once the final state is available, the destination host starts running the VM. The VM retains its identity, including its existing virtual MAC address, so it continues as the same network endpoint rather than appearing as a newly created machine.

Connected clients may experience a brief interruption around the handoff. They do not normally experience that interruption throughout the initial and iterative memory-copy phases.

8. A RARP Notification Updates the Network

After the VM starts on the destination, a Reverse Address Resolution Protocol (RARP) notification is sent. Its purpose is to inform the local network or subnet that the VM's MAC address is now reachable through a different physical switch port.

The MAC address stays the same, but the physical connection path has changed because the VM is attached through the destination host. The network update helps switches and nearby network devices direct subsequent traffic toward the destination-host connection.

9. The Source Releases VM Memory

The source host releases memory allocated to the migrated VM only after the VM is confirmed to be operating successfully on the destination. This is the final cleanup stage and completes the handoff.

vMotion Process Steps

Step	Source host activity	Destination host activity	VM availability or state	Network action
Migration initiated	Continues running the VM and participates in validation.	Is selected and prepared to receive the VM.	Powered on and serving requests.	vSphere coordinates the migration path.
Initial memory transfer	Copies the VM's memory.	Receives memory pages.	Continues running on the source.	Memory travels over the vMotion network.
Iterative dirty-page transfer	Tracks changed pages in the memory bitmap and recopies them.	Receives repeated updates.	Continues serving clients.	Additional memory passes use vMotion bandwidth.
Source VM quiesce	Temporarily stops VM request processing.	Waits for final state.	Briefly paused during cutover.	Client traffic may briefly encounter the handoff.
Final bitmap and device-state transfer	Sends remaining change information and virtual device state.	Receives final execution context.	Still not actively executing on the destination.	Final state crosses the vMotion network.
Destination requests outstanding memory	Supplies pages identified as still needed.	Uses bitmap information to request and receive those pages.	Waiting for complete synchronization.	Outstanding page transfers complete the state copy.
VM resumes on destination	Stops running the VM.	Starts executing the VM.	Powered on and serving requests from the destination.	VM retains its MAC address.
RARP network announcement	No longer owns VM execution.	Provides the new physical connection path.	Running on the destination.	RARP announces the MAC address on the new switch port.
Source memory cleanup	Releases the migrated VM's memory after successful destination operation.	Continues running the VM.	Normal operation resumes.	Normal client traffic uses the destination path.

Practical Examples

Planned ESXi Host Maintenance

Before taking an ESXi host out of service, an administrator initiates vMotion for a running application VM. Users continue accessing the application while memory is copied and dirty pages are recopied. The application pauses only briefly while the source is quiesced, final state is transferred, and the destination resumes execution.

This workflow is commonly part of host evacuation and maintenance planning. See maintenance mode for the related host operation.

A Busy VM With Rapidly Changing Memory

Suppose a VM is receiving many user requests and frequently modifying memory. The source bitmap records pages changed after earlier copies. More iterative passes are then required, and migration may take longer if the dirty-page rate is close to or greater than the effective vMotion transfer rate.

Network Location After Migration

A VM keeps its existing MAC address after moving to a new host. Because that MAC is now reachable through a different physical switch port, the destination sends a RARP notification to update network awareness. Network peers can then direct subsequent traffic toward the destination-host connection.

Troubleshooting the Conceptual Stages

Migration Takes Longer Than Expected

Likely cause: The VM is modifying memory pages faster than the vMotion network can copy and recopy them.
What is happening: The iterative pre-copy phase needs additional passes before the remaining state is small enough for handoff.
Key relationship: A higher dirty-page rate increases migration work; more available migration bandwidth generally improves convergence.

Clients Notice a Brief Application Interruption

Likely cause: The source VM is quiesced during final handoff.
What is happening: The destination is receiving the remaining memory and device state before it can resume execution.
Important distinction: The long pre-copy phase normally allows the VM to serve requests; the short pause occurs around cutover.

Network Connectivity Needs to Be Refreshed

Likely cause: The VM retained its MAC address but moved to a new physical switch port.
What is happening: The network must learn the new location for that MAC address.
Relevant step: The post-migration RARP notification communicates the new port location.

End-to-End Summary

The administrator starts vMotion.
The source host begins copying VM memory to the destination over the vMotion network.
The source tracks dirty pages in a memory bitmap and recopies changed pages in repeated passes.
The source briefly quiesces the VM for the final handoff.
Remaining memory-change information and virtual device state are transferred.
The destination uses the bitmap to obtain outstanding memory pages from the source.
The destination resumes the VM with its identity, hardware context, and MAC address preserved.
A RARP notification tells the local network that the MAC address is reachable through the new switch port.
After successful destination execution is confirmed, the source releases the VM's memory.

For broader study, review VMware ESXi fundamentals, DRS automation levels, and Enhanced vMotion Compatibility requirements.