VMware ESXi and vSphere Cluster Management

Enhanced vMotion Explained: Live VM Migration Between Hosts and Datastores Without Shared Storage

Learn how Enhanced vMotion moves a running VM to another ESXi host and datastore, including requirements, compatibility checks, procedure, storage choices, troubleshooting, and validation.

Enhanced vMotion is a live migration workflow that moves a virtual machine (VM) to a different ESXi host and a different datastore in one operation. It combines the result of compute-only vMotion with Storage vMotion, allowing administrators to change both compute placement and storage placement while the VM remains powered on.

This capability is often called shared-nothing live migration because the source and destination hosts do not need to access the same VM datastore. The operational goal is to relocate a workload with minimal service interruption, even when the VM uses host-local storage rather than a shared SAN or NAS datastore.

This guide explains the planning checks, vSphere Client workflow, compatibility findings, storage choices, performance considerations, and post-migration validation steps for Enhanced vMotion.

What Enhanced vMotion Does

An ESXi host is the VMware hypervisor server that runs virtual machines. A datastore is a vSphere storage container that holds VM configuration files, virtual disks, snapshots, and related files.

During Enhanced vMotion, vSphere coordinates two transfers:

The VM's running compute execution moves from the source ESXi host to the destination ESXi host.
The VM's configuration files, virtual disks, and applicable snapshot-related files move from the source datastore to the destination datastore.

The VM continues to run during the operation. vSphere tracks the VM's changing memory and storage state, then performs a brief final handoff. The exact interruption depends on workload activity and infrastructure performance, but the purpose is to avoid a normal shutdown-and-copy process.

How It Relates to Other Migration Types

vMotion is the live migration of a running VM's compute execution from one ESXi host to another. In a compute-only migration, the VM's storage remains in place and must be accessible as needed by the participating hosts.

Storage vMotion moves VM files and virtual disks to another datastore while the VM remains on its current ESXi host.

Enhanced vMotion is the appropriate choice when both placements must change. In the vSphere Client, this is represented by the migration wizard option to change both the compute resource and storage. Selecting that combined option produces the Enhanced vMotion workflow.

Migration type	Changes compute host	Changes datastore	Shared storage expectation	Typical use case
Compute-only vMotion	Yes	No	Storage must remain accessible to the required hosts	Move a running VM for host maintenance or compute balancing
Storage vMotion	No	Yes	Source and destination storage must be available to the current host	Move a VM to faster, larger, or less busy storage
Enhanced vMotion	Yes	Yes	Shared VM storage is not required when the hosts can transfer the VM data directly	Move a VM between hosts with local or otherwise separate datastores
Cold migration	Usually yes	Possibly	Live-migration networking requirements do not apply in the same way	Move a powered-off VM when live migration is unsupported or unsuitable

Requirements and Compatibility Planning

Before starting, identify four locations:

The source ESXi host currently running the VM.
The destination ESXi host, cluster, or resource destination.
The source datastore containing the VM files.
The destination datastore that will receive the VM files.

Host and CPU compatibility

The source and destination hosts must pass vMotion compatibility checks. They need suitable VM hardware support, host features, resource availability, and compatible configurations.

CPU generation differences are a frequent concern. Hosts may expose different processor instruction sets even when they run compatible ESXi versions. Enhanced vMotion Compatibility (EVC) can mask selected CPU features and establish a common CPU baseline across supported hosts. EVC should be planned and configured before the migration, not treated as an emergency fix after a failed check.

Compare the processor generations and feature sets of the participating hosts.
Confirm that the VM's virtual hardware is supported on the destination.
Check for host features or attached devices that cannot move live.
Verify that the destination has sufficient CPU, memory, and other resources.

vMotion and VM networking

Each participating ESXi host needs a properly configured VMkernel adapter with vMotion enabled. A VMkernel adapter is an ESXi networking interface used for services such as vMotion. The vMotion VMkernel interfaces must have IP connectivity and sufficient bandwidth between hosts.

For the applicable VM networking scenario, the participating hosts also require Layer 2 network connectivity. Layer 2 connectivity preserves the VM's network presence across the migration environment. Confirm that the destination host has the required virtual switches, port groups, VLAN access, uplinks, and network policies.

vMotion network checks:
- vMotion is enabled on a VMkernel adapter on each host
- VMkernel addresses can communicate end to end
- VLAN, subnet, routing expectations, and MTU values are correct
- Physical switch ports and uplinks carry the required traffic
- The destination host provides the VM's required port groups
- Bandwidth and packet-loss levels are acceptable

Storage, licensing, and permissions

The destination datastore must have enough capacity for VM configuration files, virtual disks, snapshots, swap-related requirements, and migration overhead.
The destination storage must satisfy any selected storage policy.
The source and destination hosts and datastores must be supported by the installed vSphere licensing and configuration.
The administrator needs appropriate privileges to migrate the VM, use the destination compute resource, and place files on the destination datastore.
The VM should normally be powered on for live Enhanced vMotion. A powered-off workload can use cold migration instead.

Pre-Migration Assessment

Do not commit the migration solely because a destination appears in the inventory. First establish the VM's current placement and investigate conditions that can affect eligibility or service impact.

Verify the VM's current ESXi host, datastore, power state, networks, disks, snapshots, and storage policy.
Confirm that the destination host can run the VM and provides every required VM port group or network.
Confirm that the destination datastore is suitable, has sufficient free space, and can meet the selected disk format and policy requirements.
Review snapshots. A snapshot is a point-in-time VM state that can introduce additional disk files and capacity requirements. Include snapshot-related files when estimating space and migration time.
Review active tasks, backup activity, replication, mounted CD/DVD or removable media, device passthrough, USB devices, affinity settings, and other special VM conditions.
Check vMotion VMkernel reachability, latency, bandwidth, packet loss, and host network errors.
Run the wizard's compatibility validation and read the detailed findings before starting the task.

Check	Why it matters	How to validate	Result if unmet
Source and destination hosts	Defines the compute movement and compatibility scope	Inspect VM placement and select a destination in the migration wizard	The host may be unavailable or rejected
vMotion VMkernel networking	Transfers running VM state between hosts	Check enabled VMkernel adapters, IP reachability, VLANs, MTU, bandwidth, and errors	The migration can fail or perform poorly
CPU and VM compatibility	Ensures the destination can execute the VM	Review wizard checks, CPU generations, EVC baseline, VM hardware, and devices	A blocking error prevents live migration
Destination network	Maintains guest connectivity after the move	Compare port groups, VLANs, uplinks, and security policies	The VM may lose network access
Destination datastore	Holds the VM after the storage move	Check capacity, accessibility, performance, type, and storage policy	The datastore may not be selectable or may run out of space
Snapshots and active operations	Influence files, space, locking, and workload risk	Review snapshots, backup, replication, tasks, and mounted media	The task may be delayed, restricted, or consume unexpected capacity
Permissions and licensing	Controls which migration actions the administrator can perform	Review assigned privileges and vSphere licensing	Resources may be hidden or the task may be denied

Enhanced vMotion Procedure in the vSphere Client

Locate the target VM in the vSphere inventory.
Open the VM's context menu or Actions menu and select Migrate.
Select the migration type that changes both the compute resource and storage.
Select the destination ESXi host, cluster, or resource destination as appropriate.
Review the compatibility result. Read every warning and error rather than accepting the first available destination.
Select the destination datastore.
If the wizard presents storage choices, select the appropriate virtual disk format and storage policy. The available choices depend on the datastore and environment.
Select the migration priority.
Review the summary, including source and destination host, datastore, networks, disk placement, policy, and any warnings.
Start the migration.
Monitor the task in Recent Tasks or the VM's task view until it completes.
Perform the post-migration validation described below.

Understanding Compatibility Findings

The compatibility check validates whether the selected host, datastore, networks, VM configuration, permissions, and available resources can support the operation.

Finding type	Can migration start	Administrator action	Example conditions
Error	No	Correct the condition or choose another destination	Incompatible CPU feature, missing required network, unavailable datastore, unsupported device, or insufficient capacity
Warning	Possibly	Assess risk, confirm the intended behavior, and remediate where practical	Performance concern, policy consideration, device state, or configuration difference
Successful check	Yes, subject to operational conditions	Review the summary and begin the task when ready	Host, network, storage, permissions, and VM checks pass

Common compatibility categories include CPU features, connected networks, datastore availability, host configuration, compute and memory resources, storage policy compatibility, and unsupported VM devices. A successful check means the selected configuration is eligible; it does not guarantee that a congested network or slow datastore will complete quickly.

Destination Storage and Virtual Disk Formats

The destination datastore is central to a migration without shared storage because it becomes the VM's new storage location. Account for VM configuration files, virtual disks, snapshot-related files, and other files included by the migration workflow.

When the environment presents the choice, a virtual disk format determines how a VMDK is provisioned. Common choices include:

Thin provisioning: Initially consumes less physical space and grows as data is written. Monitor available capacity and overcommitment carefully.
Thick provisioning: Reserves more physical capacity in advance. It may require more free space and can make the migration longer, depending on the source format and storage implementation.

A disk-format conversion can change physical space consumption and migration duration. Storage policies may also be available. A policy expresses requirements such as performance, availability, or placement characteristics, and vSphere evaluates whether the destination datastore satisfies those requirements.

Migration Priority and Workload Impact

Migration priority balances faster completion against the resources consumed by the migration. The exact labels vary by vSphere version and workflow, but the practical choice is generally between allocating more host resources to finish sooner and reducing the migration's impact on production workloads.

Priority approach	Primary benefit	Potential tradeoff	Best-fit scenario
Higher resource reservation	Completes the live transfer sooner	Consumes more CPU, memory, storage, or network resources during the task	Urgent host evacuation or a maintenance window with spare capacity
Lower production impact	Preserves more resources for active workloads	Migration may take longer	Busy production systems where service performance is the priority

Completion time depends on guest memory churn, storage throughput, VM disk size, vMotion bandwidth, and competing host or storage activity. A VM that frequently rewrites memory can require more synchronization before the final handoff. Slow source or destination storage can also dominate the operation.

Practical Examples

Moving a production VM between hosts with local datastores

Suppose a production VM runs on Host A and its files are on Datastore A. A replacement Host B has Datastore B, and no shared datastore is available. The administrator confirms vMotion VMkernel connectivity, checks that Host B exposes the required VM network, verifies CPU compatibility and capacity, and confirms that Datastore B can hold the VM and snapshot-related files. In the migration wizard, the administrator selects the combined compute-and-storage option, chooses Host B and Datastore B, reviews compatibility, selects a suitable disk format and priority, and starts the task. After completion, the VM should run on Host B with its files on Datastore B.

Evacuating a host before maintenance

When VMs use host-local datastores, compute-only vMotion cannot complete the evacuation because the destination host cannot use the source host's local VM files. Enhanced vMotion moves each running VM's compute state and storage. An administrator may choose a higher migration priority when the maintenance window is short, or a lower-impact setting when production workloads are busy. Application health should be checked after each move.

Rebalancing an application VM to faster storage

An application VM may need both a new host and a faster datastore. The administrator evaluates the target datastore's performance, free space, storage policy, disk format, and available transfer bandwidth. A format conversion or a large disk can increase the migration duration, so the task should be scheduled with enough capacity and operational time.

Post-Migration Validation

Do not treat task completion as the only success criterion. Confirm both placement and service health.

Validation item	Expected result	Where to verify
Compute placement	The VM is registered and running on the intended destination host	VM Summary, inventory placement, and host view
Storage placement	Configuration files and virtual disks reside on the selected destination datastore	VM Datastores or storage details and datastore browser
Guest networking	The guest OS can reach required networks	Guest tests, monitoring, and application checks
Application availability	Services respond and dependencies remain reachable	Application health checks and user-facing tests
Tasks and events	No unexpected warnings or errors remain	Recent Tasks, Events, alarms, and host logs
Backup and replication	Protection jobs recognize the new placement and complete normally	Backup and replication consoles or vSphere integrations
Monitoring and policy	Monitoring continues and the VM complies with its storage policy	Monitoring system, vSphere alarms, and storage-policy status

Use Cases and Limitations

Evacuating a standalone ESXi host before maintenance.
Replacing host-local storage.
Rebalancing compute and storage placement.
Refreshing host hardware.
Moving workloads without a SAN or NAS shared datastore.

Enhanced vMotion does not remove the need for suitable network capacity, compatible hosts, adequate destination storage, correct permissions, or supported VM configurations. Device passthrough, special virtual devices, mounted media, CPU requirements, network differences, and storage policies can restrict live migration.

If prerequisites cannot be satisfied, use a shutdown-and-move alternative such as cold migration, or plan another supported migration method. Cold migration avoids the requirement to preserve a running workload but introduces downtime.

Troubleshooting Common Problems

Incompatible CPU or unsupported CPU feature

Likely causes include different CPU feature sets, no EVC configuration, an unsuitable EVC baseline, or VM hardware requirements that the destination cannot provide. Read the detailed compatibility message, select a compatible host, or plan an appropriate EVC configuration. If live compatibility cannot be achieved, use a powered-off migration.

The destination host or datastore cannot be selected

Check permissions, host maintenance state, available compute resources, datastore capacity, network mappings, storage accessibility, and storage-policy compatibility. Remediate the limiting condition or select another destination.

vMotion network connectivity failure

Verify that both hosts have VMkernel adapters enabled for vMotion. Check IP addressing, VLANs, physical-switch configuration, MTU consistency when jumbo frames are used, packet loss, bandwidth, and network errors. A routing assumption that is valid for management traffic may not satisfy the intended vMotion design.

Migration is slow or does not converge

High guest memory write activity, limited vMotion bandwidth, slow source or destination storage, and competing workloads can extend the operation. Assess workload activity and migration priority, schedule a lower-change period, improve available throughput, or reduce competing activity.

The VM moves but application connectivity is disrupted

Compare the destination port group name, VLAN assignment, uplinks, virtual switch configuration, and security policies with the source. Then test guest connectivity and application dependencies. A VM can complete migration successfully while still being attached to an incomplete or incorrectly mapped destination network.

The destination datastore runs out of space

Recalculate requirements for virtual disks, configuration files, snapshots, swap-related files, and disk-format conversion. Thin-provisioned storage may be overcommitted, while thick provisioning may consume more space immediately. Choose a datastore with adequate free capacity and manage or consolidate snapshots where appropriate before retrying.

Key Takeaways

Enhanced vMotion moves a running VM to another ESXi host and datastore in one workflow.
It combines compute-only vMotion and Storage vMotion outcomes and can support shared-nothing live migration.
Successful planning requires compatible CPUs and VM hardware, vMotion VMkernel connectivity, destination networks, sufficient compute resources, datastore capacity, licensing, and permissions.
The combined compute-and-storage option in the vSphere Client is the workflow to select.
Compatibility errors block migration; warnings require deliberate risk assessment.
Disk format, storage policy, migration priority, memory churn, storage throughput, and network bandwidth affect the task.
Always verify host placement, datastore placement, guest networking, applications, tasks, alarms, backups, replication, monitoring, and policy status afterward.

For a focused reference, see Enhanced vMotion Explained.