VMware ESXi and vSphere Cluster Management

VM Migration Types in VMware vSphere and ESXi

Learn VMware VM migration types, including vMotion, Storage vMotion, combined, cold, and suspended migration, with requirements, workflows, risks, and troubleshooting.

A virtual machine (VM) is a software-defined computer running as a workload on an ESXi host. VM migration moves the VM's compute placement, storage location, or both. In VMware vSphere, the correct migration method depends mainly on whether the VM must remain online, whether the host must change, and whether the datastore must change.

vSphere is VMware's virtualization platform and management ecosystem. vCenter Server provides centralized management and is commonly required for coordinated live migration workflows. This lesson covers the major migration types, their downtime implications, prerequisites, operational workflow, and common failure conditions.

What VM Migration Is Used For

Migration relocates a VM without necessarily changing the guest operating system or application. Depending on the operation, migration can change the ESXi host that supplies CPU and memory, the datastore that holds VM files, or both.

Host maintenance: Move running VMs away from an ESXi host before patching, hardware work, or replacement.
Load balancing: Place workloads on hosts with available CPU and memory capacity.
Hardware replacement: Relocate VMs from older hosts to newer compatible hosts.
Datastore maintenance: Move VM files away from storage that must be retired, repaired, or reconfigured.
Consolidation: Reduce the number of active hosts or storage systems.
Storage reorganization: Move workloads between performance tiers, storage platforms, or datastores with different capacity characteristics.

Migration is normally a planned relocation. It is different from failover, which transfers service after a failure, and from disaster recovery, which restores or runs workloads at another site after a major disruption. Migration is generally initiated while the source environment is available and under administrative control.

Migration Classified by VM Power State

Cold migration

Cold migration moves a powered-off VM. Because the guest is not running, users experience downtime for the entire period during which the VM is unavailable. Cold migration can change the host, datastore, or both.

Suspended-state migration

Suspended migration moves a VM that has been suspended while preserving its suspended state. The VM's execution state is saved, but users cannot continue operating the guest during the relocation. After the move, an administrator can resume the VM.

Live migration

Live migration moves a running VM with little or no user-visible interruption. The VM remains powered on, and its network services are intended to remain available. Live migration requires more compatibility and infrastructure checks than a powered-off move.

vMotion: Live Compute Migration

vMotion is the live migration of a running VM's compute execution from one ESXi host to another. The VM remains powered on while CPU and memory execution are transferred. The main result is a change in host placement; vMotion does not necessarily move the VM's files to another datastore.

In the usual shared-storage design, both the source and destination ESXi hosts can access the VM's existing files on the same shared storage. Shared storage is storage that is simultaneously accessible to both hosts. The VM can therefore continue using its virtual disks while its compute execution moves.

Conceptual vMotion sequence

The destination host is checked for CPU, memory, networking, device, and policy compatibility.
The destination host begins receiving the VM's memory state while the VM continues running on the source.
Memory pages changed during the first copy are copied again. This synchronization can repeat while the guest continues executing.
At a brief switchover point, the VM's active execution state is transferred to the destination host.
The destination resumes execution, and the source releases the VM after the migration completes.

The primary use case is evacuating an ESXi host for maintenance without shutting down its running VMs. After required workloads have been moved, the administrator can place the original host into maintenance mode, a host state used to evacuate or stop workloads before maintenance.

Storage vMotion: Live Storage Migration

Storage vMotion is the live relocation of a running VM's virtual disks and configuration files between datastores. The VM can remain on the same ESXi host while its storage location changes.

A datastore is a logical storage container used by ESXi to hold VM files. Storage vMotion is useful when retiring a datastore, balancing capacity, moving a workload to a faster storage tier, or transferring a VM to a different storage platform.

The source datastore must be readable and usable during the operation.
The destination datastore must be accessible to the selected host or hosts.
The destination must have enough free capacity for the VM files and any required working space.
The storage configuration must support the selected migration and the VM's disk types and features.

Storage vMotion changes storage placement but does not, by itself, move the VM to another compute host.

Combined Compute and Storage Migration

A combined migration moves a running VM to a different host and a different datastore in one operation. This is useful when a workload must leave both an old ESXi host and a legacy or constrained storage platform.

There are two important models:

Shared-storage workflow: A standard vMotion changes the compute host while shared storage remains available, followed by Storage vMotion or an integrated operation that changes the datastore.
Shared-nothing vMotion: A live migration capability that can move compute and storage when the source and destination do not use the same datastore. Its availability depends on the vSphere version, licensing, storage configuration, networking, and other compatibility conditions.

In the vSphere Client migration wizard, this is commonly represented by choosing to change both the compute resource and storage. The wizard then asks for a destination host or cluster and a destination datastore. Review the compatibility checks and network mappings before completing the operation.

Cold Migration

Cold migration moves a powered-off VM between hosts, datastores, or both. The VM remains off during the move, so downtime is required. Depending on the environment, the operation moves VM files and updates the VM's inventory location or host registration.

Cold migration is useful when:

Live migration prerequisites are unavailable.
The source and destination do not have a suitable live-migration path.
A broad compatibility change is required that cannot be performed while the VM is running.
The workload is nonproduction or its outage fits an approved change window.
A simple, controlled move is preferred over the additional requirements of live migration.

After the move, power on the VM only after checking its destination network, datastore files, virtual hardware, and resource allocation.

Suspended VM Migration

Suspended migration relocates a suspended VM while retaining its saved execution state. Suspending a VM is different from shutting it down: the guest's current execution state is retained so it can later resume rather than boot from scratch.

Users cannot continue operating the VM during a suspended migration. Compared with cold migration, suspended migration preserves the in-memory execution state. Compared with live migration, it does not provide continuous service because the VM is unavailable while suspended and relocated.

Use cold migration when a clean shutdown is acceptable or when preserving memory state is unnecessary.
Use suspended migration when preserving a paused lab, test, or other environment is useful.
Use live migration when the VM must remain available during the relocation.

VMware VM Migration Types Comparison

Migration type	VM power state during migration	Changes compute host	Changes datastore	Expected service interruption	Shared storage requirement	Typical use case	Key prerequisites and limitations
vMotion	Powered on	Yes	Usually no	Little or no user-visible interruption	Usually required between source and destination	Evacuate a host for maintenance	Compatible hosts, vCenter, vMotion networking, resources, and compatible VM configuration
Storage vMotion	Powered on	Usually no	Yes	Little or no user-visible interruption	Source and destination datastore access is required	Datastore maintenance or storage tiering	Destination capacity, storage access, and supported disk and VM configuration
Combined compute and storage migration	Powered on	Yes	Yes	Little or no user-visible interruption when supported	May use shared storage or a supported shared-nothing workflow	Move a workload to another host and storage platform	Version, license, network, CPU, host, datastore, and VM compatibility
Cold migration	Powered off	Optional	Optional	Downtime for the move	Not necessarily shared, depending on the file-transfer method	Move a VM when live migration is unavailable	Clean power-off, file access, destination registration, and post-move validation
Suspended migration	Suspended	Optional	Optional	VM unavailable while suspended and moved	Depends on the selected host and storage workflow	Relocate a paused lab or test environment	Preserved suspended state, compatible destination, and no user activity during the move

Migration Requirements and Compatibility Checks

Management and permissions

vMotion and Storage vMotion workflows commonly require vCenter Server for coordinated management. The operator also needs permissions for the VM, source and destination hosts, datastores, networks, and the migration operation. Role design and licensing can limit which migration choices appear or can be completed.

vMotion VMkernel networking

A VMkernel adapter is an ESXi networking interface used for services such as vMotion. Create or identify a VMkernel adapter intended for vMotion traffic and enable the vMotion service on it. Source and destination hosts need the designed Layer 2 or routed connectivity, correct IP configuration, and a network path with suitable bandwidth and resilience.

Verify VLANs, routing, firewalls, MTU settings, physical switch configuration, and uplink availability end to end. Large-memory VMs and busy hosts can generate substantial migration traffic, so avoid treating the management network as an automatically adequate migration path.

CPU and VM compatibility

The destination CPU must expose a compatible feature set. Different CPU generations can block vMotion when the destination cannot provide features expected by the VM. Enhanced vMotion Compatibility (EVC) helps by presenting a common CPU feature baseline across hosts, but EVC does not make every host combination compatible.

Also check virtual hardware version, guest operating system conditions, virtual devices, attached local devices, passthrough devices, and other configuration restrictions. Some devices or host-specific attachments cannot be transferred through live migration.

Resources and admission checks

The destination host or cluster must have sufficient CPU and memory capacity. Check reservations, limits, resource pools, affinity rules, cluster policies, and admission controls. A host that appears to have free capacity can still reject a migration if a reservation or policy cannot be satisfied.

Storage and networking

Confirm that the destination host can access the required datastore.
Confirm sufficient datastore free space, including space needed by the selected disk format and migration operation.
Ensure the destination has the required VM port groups and correct network mappings.
Verify VLAN IDs, uplinks, security settings, and physical connectivity on the destination network.
For combined or shared-nothing moves, confirm that both compute and storage paths are supported by the environment.

Version, edition, and licensing

Migration features differ across vSphere versions and editions. The exact availability of Storage vMotion, shared-nothing vMotion, cross-boundary workflows, automation features, and cluster integrations can depend on licensing and product configuration. Treat the vSphere Client's compatibility result and the target release documentation as authoritative for the installed environment.

vMotion and Storage vMotion Prerequisite Checklist

Requirement	Applies to	Why it matters	How to verify
vCenter management	Most coordinated vMotion and Storage vMotion workflows	Provides centralized inventory, compatibility checks, and task coordination	Confirm both hosts, the VM, and target resources are managed by the required vCenter arrangement
VMkernel vMotion connectivity	vMotion and combined live migration	Carries migration state between ESXi hosts	Check VMkernel adapters, enabled vMotion service, IP reachability, VLANs, routing, MTU, and firewalls
CPU compatibility or EVC	Host-changing live migration	Prevents execution on a CPU feature set the VM cannot use	Run the migration compatibility check and review EVC and CPU differences
Destination resource capacity	All host-changing migrations	Ensures CPU, memory, reservations, and policies can be satisfied	Review host or cluster utilization, reservations, limits, affinity rules, and admission checks
Datastore access and free space	Storage and combined migrations	Allows VM files to be read, written, and retained at the destination	Check datastore visibility on relevant hosts, paths, permissions, and free capacity
Port group or network mapping	All migrations that change host or inventory placement	Preserves guest network connectivity	Compare port groups, VLANs, uplinks, and migration-wizard mappings
Permissions	All migration operations	Controls who can move workloads and alter resources	Review the operator's VM, host, datastore, network, and migration privileges
Supported versions and licensing	Feature-dependent workflows	Determines whether a migration method is available and supported	Compare vSphere versions, editions, licenses, and the selected workflow's compatibility result

How to Select the Correct Migration Type

Use this decision process:

Ask whether the VM must remain online. If yes, use a live migration method and verify all prerequisites. If no, cold or suspended migration may be simpler.
Ask whether the compute host must change. If yes, select a host-changing method such as vMotion, combined migration, cold migration, or suspended migration.
Ask whether the datastore must change. If yes, select Storage vMotion, combined migration, cold migration, or suspended migration as appropriate.
Check whether source and destination hosts share the required datastore. If they do, standard vMotion is often suitable for a host-only move. If they do not, use a supported storage-moving or shared-nothing workflow, or accept downtime and use cold migration.
Review compatibility, capacity, network, permissions, licensing, and application dependencies before committing to the operation.

Operational goal	VM must remain online?	Shared storage available?	Recommended migration method	Important validation steps
Evacuate an ESXi host	Usually yes	Usually yes	vMotion	Check destination CPU, memory, networks, datastore visibility, and then confirm the host is empty before maintenance mode
Replace or maintain a datastore	Usually yes	Source and destination storage access required	Storage vMotion	Confirm destination capacity, disk placement, storage performance, and VM file location
Move compute and storage together	Preferably yes	Depends on workflow	Combined compute-and-storage migration	Validate host and datastore compatibility, migration networking, network mappings, and licensing
Relocate a powered-off VM	No	Not necessarily	Cold migration	Confirm clean shutdown, file transfer, destination registration, network mapping, and power-on behavior
Move a suspended VM	No, but preserve state	Depends on workflow	Suspended migration	Confirm suspended state is retained, files are accessible, and resume behavior is correct

Operational Migration Workflow

1. Prepare the change

Confirm recent backups and verify that the recovery plan is usable.
Review snapshots, active tasks, scheduled jobs, backup operations, replication, and other activities that could conflict with migration.
Check host CPU and memory capacity, datastore free space, storage paths, network mappings, and application dependencies.
Define a change window, owner, success criteria, rollback plan, and escalation path.

Snapshots are not backups. Review snapshot age and dependency before moving a VM, and avoid creating unnecessary snapshots solely to make a migration feel safer.

2. Start the migration wizard

In the vSphere Client, right-click the VM and choose the migration action.
Choose whether to change the compute resource, storage, or both.
Select the destination host or cluster when changing compute placement.
Select the destination datastore when changing storage placement.
Review compatibility warnings, destination networks, and network mappings.
Finish the wizard after resolving blocking warnings and confirming the change details.

3. Monitor the operation

Monitor the migration in Recent Tasks and review events for the VM, source host, destination host, and datastores. A migration that is progressing slowly may be limited by migration bandwidth, guest memory churn, storage latency, or competing host activity.

4. Validate after completion

Confirm the VM's power state and that it is registered in the expected inventory location.
Confirm the new host and datastore placement.
Test guest IP connectivity, DNS, application ports, and dependent services.
Check application health, monitoring status, backup inclusion, replication, and security policies.
Review CPU, memory, storage latency, and network performance for unexpected changes.

Configuring ESXi vMotion Networking

For vMotion, create or identify a VMkernel adapter on each participating ESXi host. Enable the vMotion service on the intended adapter, then ensure the source and destination hosts can communicate through the designed Layer 2 or routed path.

Use correctly assigned VMkernel IP addresses and subnet or routing configuration.
Verify VLAN consistency and physical switch configuration.
Check MTU values end to end if larger frames are part of the design; inconsistent MTU settings can cause failures or degraded behavior.
Provide adequate bandwidth and resilient uplinks, especially for large-memory workloads.
Keep migration traffic appropriately separated or prioritized according to the network design and security policy.

Preparing an ESXi Host for Maintenance

Identify compatible destination hosts and confirm shared datastore visibility or an approved storage-moving workflow.
Review each VM for reservations, affinity rules, attached devices, network dependencies, and migration restrictions.
Migrate or evacuate running workloads.
Confirm that required VMs have left the host or have been handled according to policy.
Place the host into maintenance mode and perform the approved maintenance.

PowerCLI can automate bulk migration operations, but cmdlet names, parameters, permissions, and supported behavior vary by PowerCLI and vSphere version. Validate automation in a test environment and confirm the exact syntax and privileges for the target release rather than relying on automation as the only operational path.

Limitations and Risks

Live does not mean zero impact: vMotion is designed for little or no user-visible interruption, but latency-sensitive applications can still observe short delays or transient performance changes.
Memory churn affects duration: A VM that changes memory rapidly can keep generating pages that must be copied and synchronized. This can make vMotion slow or prevent the switchover from completing promptly.
Bandwidth matters: Insufficient vMotion bandwidth or competing network traffic increases migration time and may affect other services.
CPU generations can block migration: EVC may help provide a common baseline, but it cannot resolve every hardware or configuration difference.
Network differences can interrupt service: A missing port group, VLAN mismatch, wrong mapping, or different uplink configuration can leave the guest disconnected after migration.
Storage access is essential: An inaccessible datastore, missing mount, failed storage path, or insufficient free space can block a migration.
Attached local devices may be restrictions: Passthrough devices and host-specific attachments may not be movable while the VM is powered on.
Reservations and policies can reject a target: Resource reservations, affinity rules, cluster admission controls, and placement policies can make an apparently idle host unsuitable.
Application dependencies remain: Moving one VM does not move external databases, licenses, firewall rules, monitoring definitions, or other dependencies. Validate the entire service, not only the VM console.

Troubleshooting Migration Failures

Destination host is incompatible

If the compatibility check reports an incompatible destination, likely causes include a CPU feature mismatch, a different host configuration, unsupported VM hardware, or an attached device that cannot be migrated.

Read the detailed compatibility message in the vSphere Client.
Compare host CPU generations and verify the cluster's EVC configuration.
Remove or reconfigure unsupported devices when appropriate.
Use cold migration if live-migration compatibility cannot be achieved.

Destination host cannot access VM files

This commonly occurs when a shared datastore is not mounted on the destination, storage connectivity or permissions are incorrect, or the wrong datastore was selected.

Confirm datastore visibility on both hosts.
Check storage paths, storage networking, permissions, and free capacity.
Use Storage vMotion or a supported combined migration when the VM's storage must move.

vMotion network connection cannot be established

Check whether vMotion is enabled on the intended VMkernel adapter. Then verify VMkernel IP settings, VLANs, routing, MTU, firewall rules, physical switching, and uplinks between the hosts. Test host-to-host IP connectivity with approved ESXi diagnostic methods.

Migration is slow or does not complete

Common causes include insufficient bandwidth, high guest memory-change rates, and contention for network, CPU, or storage resources. Review task progress and host performance metrics, reduce competing traffic where possible, schedule the work during a quieter period, or provide more migration bandwidth.

VM loses network connectivity after migration

Verify that the destination host has the required port group, VLAN, and uplink configuration. Review the migration wizard's network mapping before retrying. After the move, test guest IP connectivity and application reachability rather than assuming that a successful task means the application is healthy.

Destination resources are insufficient

Review CPU and memory utilization, reservations, limits, resource pools, affinity rules, cluster policies, admission controls, and destination datastore capacity. Select another destination or free capacity before retrying.

Exam-Relevant Notes

vMotion changes the compute host of a running VM and usually relies on shared storage.
Storage vMotion changes the datastore location of a running VM and can leave the compute host unchanged.
A combined migration changes both host and datastore placement.
Cold migration requires the VM to be powered off.
Suspended migration preserves a suspended execution state, but the VM is not available to users during the move.
vMotion is planned mobility, not failover or disaster recovery.
CPU compatibility, VMkernel networking, datastore access, destination resources, port groups, permissions, and licensing are frequent prerequisites.
After migration, validate both infrastructure placement and guest application health.

Summary

Choose vMotion for an online host-only move with suitable shared storage. Choose Storage vMotion for an online datastore move. Choose a combined compute-and-storage migration when both placements must change and the vSphere environment supports it. Choose cold migration when downtime is acceptable or live prerequisites are unavailable. Choose suspended migration when preserving a paused execution state is more important than continuous service.

Successful migration depends on more than selecting a menu option. Confirm vCenter management, vMotion VMkernel connectivity, CPU and VM compatibility, destination capacity, datastore access, network mappings, permissions, licensing, backups, and application dependencies. For related planning, review VM migration types alongside your environment's maintenance and recovery procedures.