VMware ESXi and vSphere Cluster Management

VM Migration Types in VMware vSphere and ESXi

Learn when to use vMotion, Storage vMotion, cold migration, and combined compute-and-storage migration in VMware vSphere and ESXi.

VM migration fundamentals

VM migration is the relocation of a virtual machine's compute execution, storage files, or both. In vSphere, you can change the ESXi host running a VM, the datastore containing its files, or both destinations in one operation.

A VM migration should be planned around four separate considerations:

Execution state: A running VM has active CPU and memory state that must be transferred for a live migration. A powered-off VM has no running state to preserve.
Virtual disks: VMDK files may remain on their current datastore or be copied to a destination datastore.
Configuration files: The VM configuration, snapshots, logs, and related files may also need to move.
Network identity: The destination must provide the VM's port group or distributed port group so its virtual network connection remains available.

Live migration moves a running VM with little interruption. Cold migration moves a VM while it is powered off, so it does not need to preserve active execution state. The choice depends on downtime tolerance and whether the environment satisfies live-migration requirements.

Choosing a migration type

Start with the operational goal rather than the feature name. Host maintenance usually requires moving compute execution. Datastore replacement requires moving VM files. A host replacement may require both changes.

Operational goal | Recommended method | Why it fits | Important checks

ESXi host maintenance | vMotion | Evacuates running VMs before maintenance | Host compatibility, vMotion networking, destination capacity, and shared datastore access

Datastore maintenance | Storage vMotion | Moves VM files while the VM remains on its host | Destination capacity, datastore access, storage policy, and storage performance

Storage retirement | Storage vMotion or cold migration | Removes VM files from the old datastore | Confirm every related file has moved before retiring storage

Host replacement | Combined migration or cold migration | Changes compute placement and possibly storage placement | CPU compatibility, network availability, licensing, bandwidth, and destination resources

Cross-infrastructure relocation | Supported shared-nothing workflow or cold migration | Addresses environments without common datastore access | Validate vSphere release, edition, connectivity, and supported behavior

Planned shutdown window | Cold migration | Avoids live-migration prerequisites | Backup, guest shutdown procedure, destination compatibility, and outage duration

Selection factors include acceptable downtime, shared-storage availability, destination network readiness, host and datastore capacity, CPU compatibility, attached devices, storage policies, and the vSphere licensing and release capabilities in use.

vSphere vMotion

vMotion is the live migration of a running VM from one ESXi host to another. The migration transfers the VM's active memory state and compute execution context while the guest continues to run. Near the end, vSphere briefly pauses the VM to transfer the final changed state and switch execution to the destination host.

The common use case is evacuating an ESXi host for maintenance without shutting down its VMs. In standard vMotion, the VM normally keeps its existing datastore location. Both the source and destination hosts therefore need access to the VM's storage, typically through shared storage, meaning a datastore accessible to more than one ESXi host.

Core vMotion requirements

The VM must be managed through vCenter Server for the selected workflow.
Source and destination ESXi hosts must be compatible, including suitable CPU feature sets. Enhanced vMotion Compatibility (EVC) can establish a compatible CPU feature baseline across supported hosts.
Each participating host needs a VMkernel adapter with the vMotion service enabled.
The vMotion network needs adequate bandwidth, usable latency, and reliable connectivity between hosts.
The destination must provide the VM's required network port group or distributed port group.
When storage is shared, the destination host must be able to access the VM's datastore and files.
The destination host must have sufficient CPU, memory, and other resources.

Review the detailed compatibility results before starting. A VM can appear healthy while still being blocked by CPU incompatibility, a missing network, passthrough hardware, affinity rules, encryption settings, or another configuration constraint.

For background, see Enhanced vMotion explained, CPU compatibility for vMotion, and EVC requirements.

Storage vMotion

Storage vMotion relocates a powered-on VM's files from one datastore to another. The VM generally remains on the same ESXi host while its storage placement changes.

Depending on the VM layout and selected operation, files that may move include virtual disks, configuration files, snapshots, logs, and other related VM files. Check the resulting file placement before removing the source datastore.

Storage vMotion use cases and requirements

Move files away from a datastore undergoing maintenance.
Balance datastore capacity.
Place a VM on storage with better performance or a different tier.
Retire an aging, full, or incorrectly presented datastore.
Meet a storage policy or placement requirement.

Storage vMotion requires vCenter Server, suitable permissions, visibility of the source and destination datastores, enough destination capacity, and appropriate storage and network connectivity. Thin-provisioned disks, snapshots, encryption, storage policies, and special device configurations can affect the amount of space required and whether the operation is eligible.

Cold migration

Cold migration moves a VM while it is powered off. Because there is no active CPU or memory execution state, the operation can change host placement, datastore placement, or both without preserving a running state.

Cold migration is appropriate when planned downtime is acceptable or live-migration requirements cannot be met. Common examples include moving between incompatible CPU generations, relocating files when Storage vMotion is unavailable, moving a development VM to another host and datastore, or using a shutdown-based procedure during infrastructure replacement.

A cold migration is not automatically risk-free. Confirm the guest shutdown was clean, back up the VM, check the destination network and storage, and validate device compatibility before powering it on again.

Combined compute and storage migration

A combined migration changes both the VM's ESXi host and datastore placement. When supported, a running VM can be moved to another host while its files are copied to another datastore. This combines compute migration with storage migration and has more dependencies than changing only one placement.

There are two important patterns:

Combined live migration with shared storage: The hosts may share access to some storage while the VM's files are also relocated to a selected destination datastore.
Shared-nothing migration: The destination host does not rely on the same VM datastore as the source. Compute state and storage data must reach the destination through supported vSphere mechanisms.

Shared-nothing migration means that source and destination hosts do not use the same datastore for the VM. Its availability and supported behavior depend on the installed vSphere release, licensing, host connectivity, storage design, and VM configuration. Validate the exact workflow in the installed release before making it part of a maintenance plan.

Combined operations require planning for destination capacity, host compatibility, network throughput, storage performance, and a longer migration duration. A workload with high memory-write activity can prolong the compute portion, while large or busy virtual disks can prolong the storage portion.

Migration prerequisites and compatibility checks

Validation area | What to verify | Potential consequence if not met

Host CPU compatibility | Compare processor generations and EVC configuration | vMotion validation fails or the VM cannot run safely on the destination

vMotion VMkernel networking | Confirm the service is enabled and hosts have Layer 2 or routed connectivity | Memory transfer is unavailable, slow, or unreliable

Destination port groups | Confirm the VM's required standard or distributed port group, VLAN, and uplinks exist | Guest loses network connectivity or validation fails

Datastore visibility and capacity | Check mounts, permissions, health, free space, and destination capacity | VM files cannot be opened or copied

VM device compatibility | Review USB devices, passthrough, physical mappings, virtual hardware, and other attached devices | The VM may be restricted to its current host or require shutdown

Storage policies and encryption | Confirm destination compliance and supported encryption handling | Storage migration is rejected or leaves policy violations

Resource availability | Check CPU, memory, reservations, limits, shares, and active host tasks | Destination cannot admit the VM or migration competes with other work

Also inspect snapshots, affinity and anti-affinity rules, host-to-VM rules, virtual hardware version, backup activity, replication, and any special VM configuration. Attached USB devices and passthrough hardware commonly prevent live relocation.

Use the vCenter migration wizard to choose whether to change the compute resource, storage, or both. The wizard's migration validation is a pre-flight check: read every warning and error, correct blockers, and run validation again before execution.

Relevant vSphere configurations

Configure a VMkernel adapter with the vMotion service enabled on each participating host.
Ensure the vMotion adapters can communicate over the planned migration path and that physical uplinks provide sufficient capacity.
Use consistent standard-switch or distributed-switch port-group configuration at the destination.
Configure EVC at the cluster level when supported and appropriate for the host CPU generations.
Use host maintenance mode only after VMs have been migrated or powered off. Maintenance mode does not perform migration planning by itself.

Related configuration topics include distributed switches, standard switches, VLAN configuration, and maintenance mode.

Operational workflow and safety

Assess the requirement: Decide whether compute placement, storage placement, or both must change. Establish the downtime limit.
Inspect the environment: Check vCenter inventory visibility, host connectivity, destination resources, datastore health, network readiness, active tasks, and licensing.
Choose the method: Select vMotion, Storage vMotion, a combined workflow, or cold migration.
Prepare safely: Confirm a usable backup, notify monitoring and application owners, check capacity, pause conflicting operations when appropriate, and define the change window.
Select destinations: Choose the target host and/or datastore and verify network and storage policy placement.
Review validation: Read compatibility messages, warnings, and estimates. Do not treat a successful initial selection as proof that execution will succeed.
Execute and observe: Monitor the task, migration network, storage latency, host resources, and guest impact.
Validate afterward: Confirm VM power state, guest reachability, application health, network connectivity, datastore placement, and source-host evacuation status.

For host maintenance, migrate every eligible VM or power off the remaining ineligible VMs before entering maintenance mode. Verify that no active task, mounted ISO, device attachment, or rule has left an unexpected dependency on the source host.

Migration limitations and troubleshooting

Slow or incomplete live migration

Insufficient vMotion bandwidth, high latency, packet loss, many concurrent migrations, or a guest with a heavy memory-write rate can prevent the final switchover from completing. Check VMkernel and physical network performance, reduce concurrent migrations, and schedule the operation during a quieter period.

Inaccessible datastore

If validation reports an inaccessible datastore, the destination host may not have the shared datastore mounted or may have different storage presentation, zoning, permissions, or connectivity. Verify that the datastore is healthy and visible on both hosts. If common access cannot be provided, use a supported storage-relocation or cold-migration workflow.

Unavailable destination network

A missing port group, inconsistent distributed-switch configuration, incorrect VLAN, or unavailable physical uplink can block migration or leave the guest disconnected. Create or correct the destination network, then validate VLAN reachability and uplink status.

Incompatible CPUs

Different processor feature sets can cause vMotion validation to fail. Review the host generations and cluster EVC baseline. Use EVC when supported and correctly planned, or schedule a powered-off migration.

Storage vMotion rejection

Insufficient destination capacity, storage-policy incompatibility, inaccessible storage, snapshots, encryption, or unsupported file conditions can prevent Storage vMotion. Free capacity or select another datastore, check policy compliance and access, and review the VM's complete file layout.

VM-specific blockers

USB devices, passthrough hardware, physical device mappings, affinity rules, snapshots, encryption settings, and other special features can restrict migration even when hosts appear healthy. Read the detailed compatibility message, reconfigure or remove the blocking feature where appropriate, or use a supported shutdown-based procedure.

Practical migration examples

ESXi host maintenance with no VM downtime

Use vMotion to move running VMs to another compatible host. Confirm shared datastore access and destination capacity, then place the source host into maintenance mode only after its resident VMs have been evacuated.

Datastore replacement

Use Storage vMotion to keep the VM running on its current host while moving its files to a destination datastore. Confirm capacity and storage-policy support, verify all files have moved, and only then remove or retire the old datastore.

Powered-off development VM relocation

Power off the noncritical VM and use cold migration to change its host, datastore, or both. This is suitable when downtime is permitted and live-migration prerequisites are unavailable or unnecessary.

Host replacement without shared datastore

First confirm that the installed vSphere edition and release support the required combined compute-and-storage live workflow. Plan for data-transfer time and migration-network capacity. If requirements cannot be satisfied, use a planned cold migration with a verified backup and shutdown procedure.

Exam-relevant distinctions

vMotion changes compute placement: It moves a running VM between ESXi hosts and normally leaves its datastore unchanged.
Storage vMotion changes storage placement: It moves a powered-on VM's files between datastores and generally leaves the VM on the same host.
Cold migration requires power off: It can change host placement, datastore placement, or both without preserving active execution state.
Combined migration changes both: It has the combined requirements and longer transfer planning of compute and storage relocation.
Shared storage is not universal: Standard vMotion commonly depends on both hosts accessing the VM's datastore, while shared-nothing workflows depend on supported release, licensing, connectivity, and design.
Validation comes first: CPU, VMkernel networking, destination port groups, storage, resources, devices, policies, and rules must all be checked before execution.

For broader administration practice, see the VMware ESXi online course, adding an ESXi host to vCenter inventory, and setting the DRS automation level.