VMware ESXi and vSphere Cluster Management

vSphere vMotion Explained: Live Virtual Machine Migration in VMware ESXi

Learn how vSphere vMotion moves running virtual machines between ESXi hosts, including migration phases, requirements, maintenance workflows, compatibility checks, and troubleshooting.

vSphere vMotion is VMware vSphere's live migration technology. It moves a powered-on virtual machine (VM) from one ESXi host to another while the guest operating system and applications continue running. An ESXi host is the physical virtualization server that supplies CPU, memory, networking, and other resources to VMs.

In a successful migration, the workload's compute execution changes hosts without requiring the guest OS to shut down and boot again. This makes vMotion especially useful for planned ESXi maintenance, workload balancing, and moving a VM away from a busy host.

What vMotion Moves

During a compute migration, vMotion transfers the active state required for the VM to continue on the destination host. This includes:

• The VM's active memory contents.
• CPU execution state and other processor state needed to resume execution.
• Virtual machine configuration and identity information needed by the destination host.
• Virtual devices and firmware-related settings.
• The virtual network adapter identity, including its virtual MAC address.

The guest OS, running processes, and applications remain the same running instance. vMotion is not the same as shutting down a VM, copying its files, and starting a new instance elsewhere.

For compute-only vMotion, the VM's virtual disks remain on shared storage that both hosts can access. The destination host opens the same virtual disks after the VM's execution state has moved.

Service Continuity and User Impact

Applications can continue serving users because the VM remains powered on while most of its memory state is copied. Preserving the VM's virtual network identity also allows active network sessions to remain available in the normal case.

The phrase no downtime should be treated as an operational goal rather than an unconditional guarantee. vMotion includes a short switchover: the source briefly stops VM execution, transfers the remaining changed state, and starts execution on the destination. A successful switchover is normally brief, but network congestion, incompatible hardware, resource shortages, or an operation failure can affect the migration.

How a vMotion Operation Works

Several components participate in a typical operation:

• Source host: The ESXi host currently running the VM.
• Destination host: The ESXi host that will run the VM after migration.
• vCenter Server: The centralized vSphere management component that validates and orchestrates the operation.
• VMkernel adapters: ESXi networking interfaces configured for host services such as vMotion.
• vMotion network: The network path used to transfer memory and execution state between hosts.
• VM: The powered-on workload being relocated.
• Shared storage: Storage accessible to both hosts for compute-only migration.

1. Validation: vCenter Server checks host compatibility, capacity, storage visibility, networking, VM configuration, and other rules.
2. Initial memory copy: The source host copies the VM's memory pages to the destination while the VM continues running.
3. Changed-page copying: As the VM runs, applications and the guest OS modify memory pages. The source repeatedly sends those changed pages to the destination.
4. Switchover: When the remaining changed state is small enough, the source briefly pauses execution, transfers the final state, and hands control to the destination.
5. Destination activation: The destination resumes the VM, reconnects its virtual devices and networks, and continues execution.
6. Source cleanup: After successful activation, the source host releases its execution state and vCenter Server updates the VM's placement.

Completion time depends on the VM's memory size, its rate of memory modification, available vMotion bandwidth, network latency, source and destination host load, and other concurrent migrations. A database or analytics VM with high memory churn may keep changing pages faster than the network can transfer them, making the operation slow or difficult to complete.

vMotion Process Phases

What occurs: Validation; VM execution: Continues on source; Administrator observation: Compatibility checks and warnings.

Phase Initial copy; What occurs: Most memory is sent to destination; VM execution: Continues on source; Administrator observation: Migration task shows progress.

Phase Changed-page copy; What occurs: Modified pages are copied repeatedly; VM execution: Continues on source; Administrator observation: Duration varies with memory write rate.

Phase Switchover; What occurs: Final state is transferred; VM execution: Briefly paused, then starts on destination; Administrator observation: Short finalization period.

Phase Cleanup; What occurs: Source execution state is released; VM execution: Continues on destination; Administrator observation: Task completes and placement changes.

Migration Types and Scope

Compute-only vMotion: Changes ESXi host; Changes datastore: No; Primary purpose: Maintenance or compute balancing; Storage requirement: Shared datastore access from both hosts.

Storage vMotion: Changes ESXi host: Not necessarily; Changes datastore: Yes; Primary purpose: Storage maintenance or placement; Storage requirement: Destination datastore capacity and compatibility.

Combined migration: Changes ESXi host: Yes; Changes datastore: Yes; Primary purpose: Relocate compute and storage together; Storage requirement: A migration method that supports the selected storage and compute changes.

A VM can often move between eligible hosts in the same cluster. Depending on licensing, versions, configuration, and compatibility, vSphere can also support migrations between eligible hosts outside the same cluster. Do not assume that physical reachability alone makes such a migration valid; the wizard's compatibility checks must pass.

An administrator can start a manual migration for a selected VM. Automated workflows can also use vMotion. For example, DRS—Distributed Resource Scheduler—can recommend or automate placement changes to balance cluster resources, subject to its automation level and rules. See DRS automation levels for related configuration.

vMotion Prerequisites Checklist

vCenter Server management — Why: Standard vMotion workflows are orchestrated through vCenter Server. Verify: Both hosts and the VM appear in the same vSphere management environment or an explicitly supported migration configuration. Missing symptom: The migration action is unavailable or cannot be completed.

Managed and reachable hosts — Why: vCenter and both ESXi hosts must coordinate the move. Verify: Hosts show connected and healthy. Missing symptom: Host or task communication errors.

Licensing and configuration — Why: The applicable vSphere edition and host configuration must include the capability. Verify: Review assigned licenses and host features. Missing symptom: vMotion is unavailable or blocked.

vMotion VMkernel adapters — Why: ESXi needs an interface for migration traffic. Verify: A VMkernel adapter on each host has the vMotion service enabled. Missing symptom: No usable migration network.

Host-to-host network connectivity — Why: Memory and execution state must travel between the two hosts. Verify: Check VLANs, IP addressing, routing or Layer 2 design, MTU, uplinks, and firewall policies. Missing symptom: Connection or timeout failure.

Destination CPU compatibility — Why: The destination must expose a CPU instruction set the VM can safely use. Verify: Read compatibility results and compare processor generations. Missing symptom: CPU feature warning.

Capacity — Why: The destination needs sufficient usable CPU and memory. Verify: Review current demand, reservations, limits, and admission policies. Missing symptom: Insufficient resources.

VM networking — Why: The destination must provide the VM's required port groups, VLAN access, uplinks, and policies. Verify: Compare virtual networking on both hosts. Missing symptom: Network or port-group compatibility warning.

Shared datastore access — Why: Compute-only vMotion requires both hosts to see the VM's virtual disks. Verify: Confirm datastore visibility and permissions on both hosts. Missing symptom: Datastore or disk access warning.

Compatible VM hardware and devices — Why: Passthrough devices, local resources, and special features can bind a VM to a host. Verify: Review attached devices and host capabilities. Missing symptom: Unsupported device or feature warning.

CPU generations do not always expose identical instruction sets. Enhanced vMotion Compatibility (EVC) establishes a common CPU feature baseline for hosts in an eligible cluster, improving migration compatibility. EVC does not make every hardware feature interchangeable; review the specific compatibility result. See EVC explained and CPU compatibility for vMotion.

Configuring the Environment

1. Create or identify a VMkernel adapter on each ESXi host.
2. Enable the vMotion service on the relevant VMkernel adapters.
3. Provide end-to-end connectivity between the source and destination vMotion interfaces according to the network design.
4. Use consistently configured standard or distributed virtual networking so the destination can connect the VM to every required port group. See distributed switches and standard switches.
5. Verify datastore visibility from both hosts for compute-only migration.
6. Configure or validate EVC when processor generations require a common baseline.

A dedicated, adequately sized vMotion network reduces contention with management, storage, and VM traffic. Monitor bandwidth, latency, packet errors, and switch configuration; a nominally configured interface is not sufficient if the physical path is congested or inconsistent.

Planned ESXi Maintenance Workflow

Hardware maintenance is a central vMotion use case. For example, an ESXi host may need a fan or power component replaced.

1. Identify the host that requires maintenance and inventory its running VMs.
2. Confirm that other hosts have enough CPU and memory capacity, compatible CPU capabilities, datastore visibility, and matching virtual networks.
3. Migrate each eligible production VM away from the affected source host.
4. Verify that each VM is powered on, reachable, and running on a destination host.
5. Place the empty host into maintenance mode, which is the host state used to evacuate workloads before planned work. Review maintenance mode for related behavior.
6. Perform the hardware work, including powering down the host if the procedure requires it.
7. Return the repaired host to service and confirm that it is connected and healthy.
8. Optionally rebalance workloads or return selected VMs, after repeating compatibility and capacity checks.

vMotion reduces planned application interruption, but it does not replace maintenance planning. Validate backups, application health, network dependencies, capacity headroom, and rollback procedures before evacuating a production host.

Manual vSphere Client Workflow

1. In the vSphere Client, select the powered-on VM.
2. Choose the migration action.
3. Select the workflow to change the compute resource. Do not select a storage-only workflow when the goal is only to change hosts.
4. Select an eligible destination ESXi host or cluster.
5. Review the destination networks and other placement choices.
6. Read every compatibility warning and review the migration validation results.
7. Finish the workflow only after resolving blocking errors or consciously evaluating nonblocking warnings.
8. Monitor Recent Tasks, VM events, host events, and performance metrics until the operation completes.
9. After completion, verify the VM power state, host placement, application reachability, virtual network connections, and CPU and memory usage.

Common Compatibility Issues

CPU feature mismatch — Likely cause: Processor generations expose different features. Effect: Destination is rejected. Resolution: Select a compatible host or establish an appropriate EVC baseline.

Insufficient destination resources — Likely cause: Not enough available CPU or memory, reservations, limits, or admission constraints. Effect: Validation fails or placement is denied. Resolution: Free capacity, choose another host, or adjust capacity planning.

Missing datastore access — Likely cause: The destination cannot see the VM's shared datastore. Effect: Compute-only migration is blocked. Resolution: Correct storage presentation and host access, or use a migration method that also moves storage.

Missing virtual network — Likely cause: Required port group, VLAN, uplink, or policy is absent. Effect: VM connectivity may be lost or validation fails. Resolution: Make networking consistent across hosts.

Passthrough or local dependency — Likely cause: The VM uses hardware or a resource tied to the source host. Effect: Live migration is unsupported or restricted. Resolution: Remove or reconfigure the dependency when appropriate, or plan downtime and another relocation method.

High memory churn — Likely cause: The workload continually modifies memory pages. Effect: Pre-copy cycles continue and migration takes longer. Resolution: Migrate during lower activity, improve vMotion bandwidth, or choose a less-contended period.

Troubleshooting vMotion

Destination host is incompatible

Read the detailed compatibility message instead of relying only on the final task summary. Compare CPU features, available CPU and memory, datastore visibility, destination port groups, attached devices, and special VM or host capabilities. Select another destination, correct the missing configuration, or establish an appropriate EVC baseline before retrying.

Hosts cannot communicate over the migration network

Verify that vMotion is enabled on a VMkernel adapter on both hosts. Check VMkernel IP addresses, VLAN assignments, uplinks, routing or Layer 2 reachability, MTU settings, firewall policies, switch configuration, and physical link health. Use supported host-to-host VMkernel connectivity tests for the installed vSphere version. Repair the complete network path before retrying.

Migration remains in progress

Review VM and host performance metrics, vMotion throughput, network errors, and host contention. Compare the VM's memory size and active memory write rate with available migration bandwidth. If possible, lower application activity, schedule the move during a quieter period, improve vMotion network capacity, or select a less-loaded destination.

Application connectivity changes after migration

Confirm that the VM's destination port group maps to the intended network and that VLAN access, uplinks, distributed-switch membership, and security policies are consistent. Test guest connectivity and application listeners, and check external network policies. Validate the configuration with a noncritical VM before migrating production workloads.

Limitations and Planning Notes

• Not every VM and host pair is eligible for live migration.
• CPU compatibility, passthrough devices, local-resource dependencies, networking differences, and capacity limits are common blockers.
• Large memory footprints and high memory write rates can make pre-copy take longer or prevent it from converging quickly.
• The destination must support every virtual network to which the VM is connected.
• Compute-only vMotion depends on shared datastore access; when storage is not shared, use a migration method that includes storage relocation.
• Use dedicated and adequately sized vMotion networking, and avoid congestion during planned moves.
• Monitor the VM and application after migration rather than assuming a successful task means every dependency is healthy.

Exam-Relevant Summary

• vMotion is live migration of a powered-on VM between ESXi hosts.
• The memory pre-copy phase transfers memory while the VM continues running.
• The switchover briefly pauses execution, transfers remaining state, and resumes the VM on the destination.
• Compute-only vMotion changes the host but normally leaves virtual disks on shared storage.
• vCenter Server, compatible hosts, vMotion-enabled VMkernel networking, destination capacity, CPU compatibility, matching VM networks, and required datastore access are core prerequisites.
• EVC provides a common CPU feature baseline when eligible hosts have different processor generations.
• Storage vMotion moves virtual disks and is distinct from basic compute-host vMotion.
• DRS can recommend or automate placement changes that use vMotion, while an administrator can also initiate a migration manually.