VMware ESXi and vSphere Cluster Management
Use vSphere vMotion to Migrate a Running Virtual Machine
Learn how to use the vSphere Web Client to live-migrate a powered-on virtual machine between compatible VMware ESXi hosts with vMotion.
vSphere vMotion is VMware technology for live migration: it moves a powered-on virtual machine from one ESXi host to another while the guest operating system and its applications continue running. The usual goal is to complete planned host maintenance or balance workloads without planned service downtime.
An ESXi host is the VMware hypervisor server that runs virtual machines. vCenter Server centrally manages hosts, virtual machines, inventory, permissions, and migration operations. The browser-based vSphere Web Client provides the workflow used in this lesson.
How vMotion Works
During vMotion, ESXi transfers the VM's memory contents and execution state across the vMotion network, a host-service network used for this purpose. The source VM remains active while memory is copied. A brief final switchover transfers the remaining changed state to the destination host, after which the VM continues execution there.
The result is a running VM on the selected destination host with no planned application shutdown. Actual service continuity still depends on the guest, application, network, and storage being healthy.
- Host migration: moves the VM's compute execution from one ESXi host to another.
- Storage migration: moves VM files between datastores and is handled by Storage vMotion.
- Live migration: moves a running workload while seeking to preserve continuous availability.
Migration Prerequisites
Check the environment before opening the migration wizard. A successful vMotion requires management, networking, compatibility, resources, storage, and permissions to be correct.
| Requirement | Why It Matters | How to Verify |
|---|---|---|
| vCenter management | vCenter coordinates inventory and the migration task. | Confirm both ESXi hosts appear connected in the same vCenter Server inventory. See Add an ESXi host to vCenter Server inventory. |
| vMotion-enabled VMkernel connectivity | Hosts must exchange VM memory and execution state. | Ensure each host has a VMkernel adapter with the vMotion service enabled and network reachability to the other host. |
| Compatible source and destination hosts | The destination must be able to run the VM's virtual hardware and CPU requirements. | Use the migration wizard's compatibility check; review CPU compatibility and EVC where applicable. |
| Shared datastore access for host-only migration | The destination must access the VM files after the compute host changes. | Verify that both hosts can see and use the VM's datastore. |
| Destination CPU and memory capacity | The destination must have enough available resources for the VM. | Review current host utilization, reservations, limits, and resource-pool availability. |
| Required permissions | vCenter must authorize the migration and destination placement. | Confirm rights to migrate the VM and use the destination host or resource pool. See Assign permissions. |
Networking preparation
Where possible, place vMotion traffic on a dedicated or suitably isolated VMkernel network. Confirm correct IP addressing, routing or Layer 2 reachability, speed, and firewall treatment. The VM's own network is separate from the vMotion network: the destination must also provide the VM's required port group, VLAN, virtual switch, and physical uplink path.
Power state and storage
vMotion is intended for a powered-on VM. If the VM is powered off, power it on first when a live migration is required, then start the vMotion workflow. For a standard host-only move, use storage that both hosts can access. If storage must change, choose a storage migration workflow rather than treating the operation as host-only vMotion.
Compatibility Validation
The migration wizard validates the selected destination before it allows the task to start. The compatibility check compares VM requirements with destination CPU features, virtual hardware support, resource availability, datastore access, network availability, and placement rules.
| Result Type | Effect on Migration | Administrator Action |
|---|---|---|
| Blocking error | The migration cannot proceed. | Read the detailed message, correct the stated problem, and run validation again. Common causes include CPU feature differences, insufficient resources, inaccessible datastores, and missing VM networks. |
| Nonblocking warning | The operation may continue, but a condition needs review. | Understand the impact and proceed only when the warning is acceptable for the environment. |
| Successful validation | The destination passed the displayed checks. | Continue to priority selection and review the final summary. |
A warning is not the same as a clean result. Record or resolve warnings that could affect performance, connectivity, policy compliance, or future operations.
Migrate a Running VM with the vSphere Web Client
| Step | vSphere Web Client Action | Expected Result |
|---|---|---|
| Select VM | Locate the powered-on VM in the inventory. | The VM summary and actions are available. |
| Open Migrate | Use the VM actions menu or right-click the VM and choose the migration command. | The Migrate Virtual Machine wizard opens. |
| Choose Change host | Select the option that changes the host or compute resource. | The workflow is configured for standard host migration rather than storage migration. |
| Select destination | Choose a compatible ESXi host, cluster placement, or permitted resource pool as appropriate. | The selected destination is checked for eligibility. |
| Review compatibility | Read all errors and warnings reported by validation. | Blocking errors are resolved before continuing. |
| Choose priority | Select an appropriate vMotion priority. | vMotion receives the intended CPU-resource treatment. |
| Review and finish | Review the summary and start the task. | The migration task begins. |
| Verify task completion | Monitor Recent Tasks and inspect the VM summary after completion. | The VM is running on the selected destination host. |
1. Select the virtual machine
Open the vSphere Web Client and locate the target VM in the inventory. Confirm its power state, current host, datastore, connected networks, and workload importance before starting.
2. Open the migration workflow
Open the VM's actions menu or right-click the VM, then select Migrate. The exact menu wording can vary by vSphere version and permissions.
3. Select the migration type
Choose Change host or the equivalent option labeled Change host or compute resource. Do not select a storage-only option when the goal is to change the ESXi host while keeping the VM files in place.
4. Choose and validate the destination
Select the destination ESXi host from the inventory. Prefer a connected host that is not in maintenance mode and that has adequate CPU and memory capacity. Run the compatibility validation and inspect the details rather than relying only on a green or acceptable summary.
5. Select vMotion priority
Migration priority controls the relative CPU resource treatment of the vMotion operation. Depending on the vSphere version and policy, the wizard may offer a normal or standard choice and an option that reserves more CPU resources or gives the migration higher priority.
Use higher priority when rapid completion is important, such as before urgent maintenance. The tradeoff is that vMotion can consume more shared host CPU resources and affect other workloads. Use the normal choice when the migration is not time-critical or when the hosts are already busy.
6. Review and start
Review the source VM, destination host or resource pool, migration type, datastore handling, networks, warnings, and priority. Start the task only after confirming that the destination meets the VM's requirements.
7. Monitor the operation
Watch the task in Recent Tasks. The task should progress through validation and migration stages and finish successfully. Do not power off or otherwise alter the VM unless the task or an incident procedure requires it.
Post-Migration Verification
- In the inventory or VM summary, confirm that the VM's current host is the selected destination host.
- Confirm that the guest operating system is still running and that the application remained available.
- Review Recent Tasks and, when needed, task or event history for completion details and warnings.
- Test guest network connectivity and confirm that the expected port group and VLAN are working.
- Check datastore access, VM power state, and application-level health after the move.
For a planned maintenance example, migrate an application VM away from the ESXi host that will be patched. After verification, place that host into maintenance mode according to your operational procedure. For load balancing, move a VM from a heavily utilized host only after confirming that the destination has sufficient CPU, memory, storage, and network capacity.
Operational Considerations
- Bandwidth: vMotion performance depends on available vMotion network bandwidth and latency. Congestion can extend the operation.
- Memory activity: A VM whose guest workload changes memory rapidly requires more memory copying. It may take longer to converge before the final switchover.
- Host resources: Source and destination CPU availability affects migration speed. Higher priority can improve completion time but may compete with production workloads.
- Network consistency: Keep port groups, VLANs, virtual switches, and physical uplinks consistent between hosts when VMs may move between them.
- Placement: Select a destination that meets resource reservations, limits, affinity rules, permissions, and compatibility requirements—not merely one that appears idle.
Troubleshooting vMotion
Compatibility error prevents continuation
Read the detailed compatibility message. Common causes are missing CPU compatibility, insufficient destination resources, unavailable VM storage, or a required virtual network missing on the destination. Correct the infrastructure issue, rerun validation, and restart the workflow if necessary. CPU compatibility and EVC concepts are covered in CPU compatibility for vMotion and Enhanced vMotion Compatibility explained.
Destination is unavailable or unsuitable
The host may be disconnected, in maintenance mode, outside the vCenter inventory, or excluded by placement and permission rules. Restore host connectivity and eligibility, verify access rights, and select another compatible managed host.
Migration is slow
Check vMotion network capacity and configuration, guest memory-change activity, and CPU or network contention. Reduce competing load where possible or schedule the migration during a less active period.
VM loses connectivity after migration
Compare the source and destination networking. Verify the required port group, VLAN, virtual switch, and physical uplink configuration. A completed vMotion does not guarantee that a differently configured destination can provide the same guest network path.
Exam-Relevant Notes
- vMotion moves a powered-on VM between ESXi hosts; Storage vMotion moves VM files between datastores.
- Both hosts normally must be managed by the same vCenter Server and have vMotion-capable VMkernel connectivity.
- Blocking compatibility errors must be resolved; nonblocking warnings require review but may not stop the task.
- Host-only vMotion normally relies on shared datastore access.
- Migration priority changes how CPU resources are treated during vMotion and can affect other workloads.
- Always verify the destination host, guest availability, network, datastore, and completed task after migration.