Enhanced vMotion in VMware vSphere: Migrate a Virtual Machine Host and Datastore Together

Learn how Enhanced vMotion moves a running VM to another ESXi host and datastore in one operation, including requirements, compatibility checks, priorities, and validation.

Enhanced vMotion is a vSphere migration workflow that changes both the compute placement and storage placement of a virtual machine in one task. A running VM can move to a different ESXi host while its configuration files and virtual disks move to a selected datastore.

This is especially useful when hosts use local or otherwise nonshared storage. Shared SAN or NAS storage is not required for the central host-and-datastore migration use case, although the participating hosts still need suitable networking, compatibility, permissions, and resources.

Enhanced vMotion Compared with Other Migration Types

vSphere has separate migration operations for compute and storage. Enhanced vMotion combines those operations into a single workflow.

Migration type	Changes host	Changes datastore	Typical use case	Key prerequisite
vMotion	Yes	Usually no	Move a running workload to another ESXi host while retaining its storage placement	Compatible hosts and a functional vMotion network
Storage vMotion	No	Yes	Relocate VM files or disks while the VM remains on its current host	Accessible destination storage and sufficient capacity
Enhanced vMotion	Yes	Yes	Move a running VM between hosts and storage locations together	Compatible destination host, vMotion connectivity, destination datastore, and appropriate permissions

During the combined operation, vSphere transfers the VM's active execution to the destination ESXi host and copies or relocates the VM files to the destination datastore. After completion, the VM should run on the selected destination host and use the selected destination datastore.

The workflow is generally used for powered-on migrations. When a VM is powered off, the migration wizard may present different choices or perform fewer live-migration checks because guest execution is not being transferred.

When Enhanced vMotion Is Useful

Host replacement: Move workloads away from an aging or defective host while placing their files on storage associated with the replacement host.
Local-storage environments: Relocate a running VM between hosts that do not share a datastore.
Datastore evacuation: Move a VM and its files away from storage that must be serviced or retired.
Workload rebalancing: Place compute workloads and their storage in locations that better match current capacity.
Storage modernization: Move workloads away from older or slower storage during an infrastructure refresh.

The main trade-off is that VM storage data must be transferred. Large virtual disks, snapshots, limited vMotion bandwidth, or busy datastores can make the operation take longer and increase network or storage load.

Requirements and Planning Checks

Plan the migration before opening the wizard. vSphere performs compatibility validation before the task can begin, but a pre-check reduces failed attempts and unexpected impact.

Check	Why it matters	How to verify	Effect if not satisfied
vCenter Server management	The combined workflow is initiated through vCenter inventory and the vSphere Client.	Confirm the VM, source host, destination host, and datastores are visible in vCenter.	The workflow may not be available or cannot coordinate both placement changes.
vMotion VMkernel networking	Host-to-host live migration traffic requires configured vMotion interfaces.	Check that each participating host has a VMkernel adapter enabled for vMotion and suitable capacity.	Migration is blocked or may be unable to transfer the running workload.
Layer 2 connectivity	The required vMotion VMkernel interfaces must communicate across the Ethernet switching layer.	Verify the relevant VLAN, switch paths, MTU settings where applicable, and host reachability.	vMotion connectivity errors appear during validation.
CPU and VM compatibility	The destination CPU must support the VM's execution requirements.	Review the compatibility result and confirm compatible CPU features or an applicable Enhanced vMotion Compatibility configuration.	A CPU compatibility error blocks migration.
Destination datastore	The destination must store the VM files and virtual disks.	Confirm datastore visibility from the destination host, available capacity, performance, and storage-policy compliance.	The datastore cannot be selected or the task is blocked for insufficient capacity.
Destination VM networking	The guest needs a valid port group or distributed-switch mapping after relocation.	Confirm matching port groups, VLANs, uplinks, and distributed-switch configuration as applicable.	The VM may migrate but lose guest network connectivity, or validation may block the task.
Licensing and permissions	vMotion and storage operations require appropriate product licensing and administrator privileges.	Check licensing and permissions for VM migration, host inventory, and datastore operations.	Actions may be unavailable or denied.
Host and storage resources	The destination needs enough CPU, memory, network, and storage resources.	Review host state, available capacity, datastore free space, and current contention.	The target may be invalid or the migration may run slowly or fail.

Also review snapshots, attached devices, special storage configurations, and feature-specific constraints. These can affect whether a VM is eligible for the combined migration. The compatibility screen is the final authoritative check before starting the task.

Configure the vMotion Network

Each participating ESXi host should have a VMkernel adapter enabled for vMotion. The vMotion VMkernel interfaces need the required Layer 2 connectivity and enough network capacity for both memory-transfer traffic and, in this workflow, VM storage data.

Verify that the source and destination hosts have operational vMotion VMkernel interfaces.
Confirm the interfaces use the intended VLAN and switching path.
Check that physical uplinks and switch configuration are consistent between hosts.
Confirm that the destination host can present the VM's required port group or distributed-switch network.
Consider bandwidth and concurrent migrations before choosing an operational window.

Enhanced vMotion Migration Procedure

Select the VM. In the vSphere inventory, select the target virtual machine. For a live migration, confirm that its powered-on state and attached devices are supported.
Open Migrate. Use the VM's actions or context menu and open the Migrate workflow.
Choose the combined migration type. Select the option that changes both the compute resource and storage. The exact label can vary by vSphere version, but it represents a host-and-datastore migration.
Select the destination host. Choose the ESXi host that should run the VM after the operation. Review the compatibility results shown for available hosts.
Resolve compatibility results. Read every error and warning before continuing. Correct blocking errors and investigate warnings that could affect operation.
Select the destination datastore. Choose a datastore visible to the destination host with enough capacity for the VM files, disks, snapshots, and any required overhead.
Choose disk and policy options. When presented, select whether to preserve the existing virtual disk format or use another supported provisioning format. Select an appropriate storage policy when the environment uses storage policies.
Choose vMotion priority. Select the priority appropriate to the maintenance window and current host load.
Review the summary. Confirm the source and destination host, source and destination datastore, networks, disk format, storage policy, and priority.
Start the task. Finish the wizard and monitor the migration in Recent Tasks, task details, events, and alarms.
Validate placement and service health. After completion, verify the VM's host, datastore, guest connectivity, applications, and resource usage.

Migration Wizard Decisions

Wizard stage	Administrator choice	Impact	Validation point
Migration type	Change both compute resource and storage	Combines host relocation with datastore relocation.	Confirm this is not a host-only or storage-only operation.
Destination host	Select a compatible ESXi host	Determines where the VM executes after migration.	Review CPU, hardware, host state, and resource checks.
Destination datastore	Select suitable target storage	Determines where VM files and disks are placed.	Check visibility, capacity, performance, and policy compliance.
Disk format and policy	Preserve or change a supported disk format; select a storage policy if offered	Can change consumed capacity, allocation behavior, and migration duration.	Confirm the selected format and policy meet performance and capacity requirements.
vMotion priority	Choose standard or a higher resource-reservation priority	Controls how aggressively resources favor migration completion.	Consider the effect on other workloads.
Final review	Confirm all source and destination details	Prevents an unintended placement or storage choice.	Read the summary before selecting Finish.

Compatibility Results: Warnings Versus Errors

A compatibility check is pre-migration validation performed by vSphere. It examines whether the selected host, storage, network, VM configuration, and related features can support the operation.

Message type	Meaning	Can migration continue	Recommended administrator action
Error	A required condition is not satisfied.	No. The migration is blocked until the error is corrected.	Read the specific message, correct the configuration, and run validation again.
Warning	A condition needs administrator attention but is not necessarily a hard blocker.	Usually yes, subject to the wizard and the selected operation.	Investigate the warning and continue only when its operational effect is understood.
Passed check	The tested condition meets the current requirement.	Yes, for that check.	Continue reviewing all other results and the final summary.

Typical checks include CPU feature compatibility, destination port-group availability, datastore capacity, host connection state, VM hardware, storage configuration, and required host features. A warning should not be ignored merely because the wizard allows the task to start.

Destination Storage and Virtual Disk Formats

The destination datastore determines where the VM's configuration files, virtual disks, and related files reside after migration. It must be accessible from the destination host and have enough usable space for the selected operation.

The wizard may offer virtual disk format choices, such as preserving the current format or selecting another supported provisioning format. Provisioning format affects how storage is allocated and can affect consumed capacity, storage behavior, and the time required to copy or transform the disks.

Preserving the existing format can avoid an unnecessary conversion and may reduce migration work.
A different supported format may better match the destination datastore's capacity or performance requirements.
Thin or other space-efficient provisioning can reduce initially consumed capacity, but actual growth, snapshots, and storage policy rules still matter.
Thicker allocation can consume more space up front and may change the time and capacity required for the operation.
When storage policies are in use, select a policy that the destination datastore can satisfy and verify compliance after migration.

Do not estimate capacity only from the guest operating system's currently used space. Consider provisioned disk sizes, snapshots, swap or auxiliary files, format conversion, and destination datastore overhead.

vMotion Priority

vMotion priority controls the relative resource treatment of the migration. The available labels vary by vSphere release, but the choices generally represent standard priority and a higher-priority option that can reserve or favor host CPU resources for completing the migration.

Standard priority: Uses normal migration scheduling and is appropriate when minimizing disruption to other workloads is more important than finishing as quickly as possible.
Higher resource-reservation priority: Gives the migration stronger resource preference and can help it complete sooner, particularly during a planned maintenance window.

The trade-off is straightforward: prioritizing migration can reduce CPU resources available to other VMs while the operation runs. Choose the higher setting only when its urgency justifies the temporary contention, and monitor host performance during the task.

Post-Migration Validation

Confirm the VM is registered on and running from the intended destination ESXi host.
Check the VM summary and storage view to confirm that configuration files and virtual disks reside on the intended destination datastore.
Verify that the expected virtual networks, port groups, and distributed-switch mappings are attached.
Test guest operating system connectivity, DNS or other required services, and application health.
Review Recent Tasks, events, alarms, and task details for warnings, retries, or errors.
Check destination host CPU, memory, network, and storage usage for unexpected contention.
When cleanup is expected, confirm that obsolete VM files no longer remain on the source datastore. Do not delete files until the completed placement and any dependencies have been verified.

Troubleshooting Common Blockers

Compatibility error prevents the task from starting

Common causes include incompatible CPU capabilities, unavailable destination networking, insufficient datastore capacity, or an unsupported VM device or configuration. Read the specific error, correct the identified issue, and run compatibility validation again.

The destination host is unavailable or cannot be selected

Check whether the host is connected, in maintenance mode, or short of required resources. Then verify VM hardware and CPU compatibility, destination networks, and required host features.

Migration is slow or affects workload performance

Large virtual disks require substantial data transfer. Limited vMotion bandwidth, storage latency, contention, or an overly aggressive priority can also contribute. Schedule the operation during lower activity, validate network and storage performance, choose an appropriate priority, and monitor contention.

Guest connectivity is unavailable after migration

Verify the destination port group mapping, VLAN configuration, distributed-switch settings, and physical uplinks. Differences between source and destination host networking can leave the VM running but disconnected from the expected network.

The destination datastore lacks free space

Compare available capacity with the VM's provisioned disks, actual files, snapshots, and selected disk format. Choose a larger datastore, review snapshot usage, reassess the format, and confirm storage-policy requirements before retrying.

Practical Examples

Move a running VM between hosts with local storage

A VM runs on Host A with disks on a datastore local to Host A. The administrator selects the combined host-and-datastore migration type, chooses Host B and Host B's local datastore, reviews compatibility, and completes the move without deploying shared SAN or NAS storage.

Evacuate a host before maintenance

Before servicing an ESXi host, an administrator moves a production VM to another compatible host and simultaneously relocates its disks to storage associated with the destination environment. The administrator validates placement and application health before beginning host work.

Convert disk provisioning during relocation

While moving a VM to a datastore with limited free capacity, the administrator compares supported disk-format options and selects an appropriate format only after confirming capacity, performance, storage policy, and migration-duration implications.

Interpret validation output

If the wizard reports a CPU compatibility error, the administrator resolves the CPU or EVC issue before migration. If a nonblocking warning appears, the administrator reviews its impact and documents the decision before proceeding.

Exam-Relevant Notes

Enhanced vMotion changes both the VM's compute host and datastore in one migration workflow.
Ordinary vMotion changes the host while retaining storage; Storage vMotion changes storage while retaining the host.
The combined workflow is valuable for nonshared or local-storage environments, but it still requires vCenter management, vMotion networking, compatible hosts, destination storage, networking, licensing, permissions, and resources.
Compatibility errors block migration. Warnings require review but do not necessarily block the task.
Because storage data is transferred, migration duration and network load depend heavily on disk size, snapshots, bandwidth, and storage performance.
The final state should be verified through host placement, datastore placement, guest connectivity, application health, tasks, events, alarms, and resource usage.

For related administration skills, review adding an ESXi host to the vCenter inventory, assigning permissions, datastore concepts, and the VMware ESXi online course.