VMware ESXi and vSphere Cluster Management

How to Use vSphere vMotion to Migrate a Running Virtual Machine

Learn how to use the vSphere Web Client to live-migrate a powered-on VM between ESXi hosts, review compatibility, choose vMotion priority, and verify completion.

vSphere vMotion is VMware's live migration feature. It moves a powered-on virtual machine from one ESXi host to another while the guest operating system and its applications continue running. The goal is to move the VM's compute execution with no planned service interruption.

This guide covers a compute-only host migration using the vSphere Web Client. For a practical reference to the complete procedure, see using vSphere vMotion.

What vMotion Does

An ESXi host is the VMware hypervisor server that runs virtual machines. During vMotion, vSphere transfers the VM's active execution state from the source host to the destination host. The VM remains powered on, and users should normally continue to reach the guest and its hosted applications throughout the operation.

A standard host vMotion changes where the VM runs, but does not intentionally move its virtual disks to another datastore. The VM files must remain accessible to the destination host, commonly through shared datastore access.

Feature	What moves	Primary use case
vMotion	The VM's compute execution from one ESXi host to another	Host maintenance, workload balancing, or moving a running VM to a more suitable host
Storage vMotion	VM files between datastores	Changing storage placement, balancing datastore capacity, or moving a VM to different storage

Prerequisites and Planning Checks

Perform these checks before opening the migration wizard. vMotion can validate many conditions, but planning first reduces failed attempts and unexpected workload impact.

Same vSphere environment: Confirm that the source and destination ESXi hosts are managed by the same vCenter Server and vSphere environment.
Powered-on VM: The VM must be running for a live vMotion operation. A powered-off VM can use other migration workflows, but it is not a live migration.
Accessible VM files: Make sure the destination host can access the VM's datastore and files. Shared datastores are a common design for compute-only vMotion.
vMotion networking: Confirm that both hosts have working VMkernel adapters configured for vMotion. The hosts must have compatible network connectivity for vMotion traffic.
Virtual networking: Check the relevant virtual switch and VMkernel port group configuration. The vMotion-enabled VMkernel port group must be usable by both participating hosts.
Destination capacity: Verify that the destination has enough available CPU and memory for the VM's demand and that its overall resource state is appropriate.
Host and VM compatibility: Check CPU feature compatibility, VM hardware compatibility, host configuration, networking, storage access, and any cluster or policy constraints.
Operational timing: Consider workload activity, maintenance deadlines, backup jobs, and other migrations that may compete for host or network resources.

Key Terms

Live migration: Moving an active workload while aiming to keep its service available.
VMkernel port group: A host networking construct commonly used to provide services such as vMotion.
Virtual switch: A standard or distributed switch that connects virtual machines and VMkernel adapters to networks.
Destination host: The ESXi host selected to receive the VM.

Start the Migrate Virtual Machine Wizard

Sign in to the vSphere Web Client.
Locate the target virtual machine in the inventory.
Confirm that the VM is powered on and identify its current source host.
Open the VM's context menu.
Select Migrate to launch the Migrate Virtual Machine wizard.

The exact appearance of the menu can vary between vSphere releases, but the workflow begins from the VM object rather than from an unrelated host action.

Select the Migration Type

When the wizard asks what to change, select Change host. This tells vSphere to move the running workload's compute execution to another ESXi host while retaining its storage location, subject to the selected environment's configuration.

Do not select a storage migration option when the goal is only to move the VM away from a host for maintenance or resource balancing. Storage migration addresses the location of VM files and is a different operation.

Select a Destination ESXi Host

Browse or expand the inventory shown by the wizard.
Find the intended destination ESXi host.
Select that host.
Wait for vSphere to perform its compatibility checks.
Read the displayed results before continuing.

The destination host should be selected based on suitability, not merely availability in the inventory. Confirm that its CPU, memory, storage access, networking, and VM compatibility meet the workload's needs.

Interpret Compatibility Results

A compatibility check is vSphere's validation of whether the selected VM can migrate to the destination host. Results commonly appear as errors or warnings.

Result type	Effect on migration	Administrator response
Compatibility error	Blocking condition; the migration cannot be completed until it is resolved.	Read the exact message, correct the reported host, VM, storage, networking, or compatibility issue, and run the workflow again.
Compatibility warning	Usually non-blocking; the wizard may allow the migration to continue.	Investigate the warning and determine its operational impact. Do not assume that a warning is harmless.

Examples of areas to investigate include destination CPU compatibility, unavailable datastores, missing vMotion VMkernel connectivity, incompatible virtual networking, insufficient capacity, or configuration differences between hosts.

Choose vMotion Priority

The wizard presents a migration-priority choice. The available labels vary by vSphere version and configuration, but the decision generally compares a normal migration priority with a higher-priority or reserved-resource option.

Normal or standard priority: The migration uses available resources while giving normal consideration to the running workloads on the hosts.
High priority or reserved resources: vSphere reserves a greater share of CPU resources for the vMotion operation so that the migration can receive more scheduling priority.

Higher priority can help a time-sensitive migration finish sooner, such as when a host must enter maintenance during a short window. The tradeoff is that resources reserved for vMotion are not available in the same way to running workloads during the operation. Choose the setting according to urgency, host load, and the impact of delaying the migration.

Review and Execute the Migration

Review the selected virtual machine.
Confirm that the migration type is Change host.
Confirm the destination ESXi host.
Verify the selected vMotion priority.
Review any remaining notices, warnings, or settings shown in the summary.
Select Finish to initiate the vMotion task.
Monitor the task until it reports completion or failure.

VM inventory object
  -> Migrate
  -> Change host
  -> Select destination ESXi host
  -> Review compatibility
  -> Select vMotion priority
  -> Review summary
  -> Finish
  -> Monitor task and verify new host

Migration Workflow Summary

Step	Action in vSphere Web Client	Expected result
1. Locate VM	Select the running VM in the inventory.	The correct VM and current host are identified.
2. Open workflow	Open the VM context menu and select Migrate.	The Migrate Virtual Machine wizard opens.
3. Select type	Choose Change host.	The wizard prepares a compute-only host migration.
4. Choose host	Browse to and select the destination ESXi host.	vSphere evaluates destination compatibility.
5. Review results	Read errors and warnings.	Blocking issues are identified before execution.
6. Set priority	Choose the appropriate vMotion priority.	The migration receives the selected resource treatment.
7. Finish	Review the summary and select Finish.	A vMotion task starts.
8. Verify	Inspect the task, events, VM summary, and guest service.	The VM is confirmed on the destination and remains available.

Verify the VM After Migration

Open the VM summary and confirm that the selected destination ESXi host is now listed as its host location.
Confirm that the guest operating system is still running and responsive.
Test the hosted application or service from an appropriate client or monitoring system.
Review recent tasks and events for a successful completion message, warnings, or follow-up actions.
Confirm that expected network and storage access remain available to the guest.

A completed task alone is not the entire verification. The VM's inventory location, guest availability, application behavior, and recent events should agree.

Troubleshooting Common Problems

A compatibility error blocks the migration

Read the exact error in the wizard rather than retrying blindly. Validate destination-host compatibility, available CPU and memory, datastore access, VMkernel vMotion connectivity, virtual switch and port group configuration, and any reported VM or host restrictions. Resolve the cause and rerun the migration workflow.

A warning appears for the destination host

A warning is generally non-blocking, but it still represents a condition that needs review. Determine whether it affects performance, connectivity, storage access, or operational support. Proceed only when the destination is suitable for the workload.

The desired destination host is not suitable

Confirm that the host is available and managed in the same vSphere environment. Then check destination capacity, VM compatibility, shared datastore visibility, and working vMotion configuration. If any required condition is absent, choose another host or correct the configuration before migrating.

The migration completed, but the outcome is unclear

Check the VM summary for its current host, inspect recent tasks and events, and test guest operating system and application availability. If the task shows warnings or failure, use those messages to guide the next investigation.

Practical Scenarios

Planned ESXi host maintenance

An application VM is running on Host-A, which must undergo maintenance. The administrator opens the VM's context menu, selects Migrate, chooses Change host, selects Host-B, reviews compatibility, chooses an appropriate priority, and finishes the wizard. After the task completes, the administrator confirms that Host-B is the VM's host and tests application reachability before starting maintenance on Host-A.

Blocking compatibility result

The destination selection page displays a compatibility error. The administrator stops instead of finishing the wizard, reads the message, corrects the reported issue, and starts the workflow again. This avoids treating a blocked migration as a simple retry problem.

Time-sensitive migration

A maintenance window is short and the hosts have sufficient capacity. The administrator selects the high-priority or reserved-resource option so vMotion receives a greater share of CPU resources. The administrator still evaluates the effect on other running workloads before confirming.

Quick Checklist

Source and destination hosts are managed in the same vSphere environment.
The VM is powered on.
Both hosts can access the VM's files and required datastore.
vMotion-enabled VMkernel networking works between hosts.
The destination has adequate CPU and memory capacity.
Host, VM, networking, storage, and CPU compatibility have been reviewed.
Change host is selected for a compute-only move.
Compatibility errors are resolved and warnings are understood.
vMotion priority matches the maintenance and workload requirements.
The task completes, the VM shows the new host, and the guest application remains available.