VMware ESXi and vSphere Cluster Management

What Is VM Migration in VMware vSphere?

Learn how VM migration works in VMware vSphere, including cold migration, suspended migration, vMotion, Storage vMotion, prerequisites, planning, and troubleshooting.

VM migration is the process of relocating a virtual machine's compute execution, storage files, or both to another infrastructure location. In VMware vSphere, a VM can move between ESXi hosts, between datastores, or between both a host and a datastore.

A virtual machine (VM) is a software-defined computer that runs a guest operating system and applications. An ESXi host is a VMware hypervisor that provides the CPU, memory, networking, and other resources used by VMs. A datastore is a logical storage container for VM configuration files, virtual disks, and related files.

Compute Location and Storage Location

A VM has two important locations:

• Compute location: the ESXi host where the VM's virtual CPUs and memory are being executed.
• Storage location: the datastore where the VM's configuration, virtual disks, and other files are stored.

These locations do not have to change together. A host migration changes where the VM runs. A storage migration changes where its files are stored. A combined migration changes both.

vSphere is VMware's platform for managing ESXi hosts, VMs, storage, and related services. vCenter Server is the centralized management component that maintains the vSphere inventory and coordinates migration operations.

Why Migrate Virtual Machines?

Organizations with multiple physical hosts can place workloads where resources and operational conditions are most suitable. Common reasons to migrate a VM include:

• Balancing CPU and memory demand: move a powered-on VM away from a host under CPU or memory pressure.
• Improving resource utilization: distribute workloads so available host capacity is used more effectively.
• Preparing for maintenance: move VMs away from an ESXi host before patching, hardware work, or other maintenance.
• Changing storage placement: move VM files to a datastore with more free capacity, better performance, a different storage policy, or replacement hardware.
• Supporting workload placement: place a VM on a host or datastore that meets current performance, capacity, or operational requirements.
• Reducing service disruption: use live migration where supported so a running workload can remain available during the move.

VM Power State and Migration Availability

The VM's power state strongly influences which migration method is available.

• Powered off: the guest operating system and applications are not running. The VM can be moved using cold migration.
• Suspended: execution is paused and the VM retains its suspended execution state. It can be moved using suspended migration and resumed later.
• Powered on: the guest operating system and applications are running. Live migration methods such as vMotion and Storage vMotion may be used when their requirements are satisfied.

A cold migration includes downtime because the VM must remain powered off. A suspended migration does not continue executing the workload during the move. Live migration is designed for a running VM and aims to minimize service interruption, but it does not remove the need for compatibility, capacity, networking, and storage checks.

VM Migration Types Compared

Cold Migration

Cold migration moves a powered-off VM. Depending on the available infrastructure and selected workflow, the operation can move the VM to another ESXi host, another datastore, or both.

The VM must remain powered off throughout the move. This makes cold migration straightforward in situations where downtime is acceptable or where live migration cannot be used because of host incompatibility, storage limitations, networking limitations, or VM-specific dependencies.

A typical cold-migration sequence is:

1. Shut down the guest operating system normally when possible.
2. Confirm that the VM is powered off and that applications have stopped cleanly.
3. Select the destination host, datastore, or both in vCenter Server.
4. Review compatibility and capacity checks.
5. Start the migration and monitor its task progress.
6. Power on the VM at the destination.
7. Verify guest boot, networking, services, and application availability.

Suspended VM Migration

Suspended migration moves a VM while it is suspended. The VM preserves its paused execution state rather than continuing to run during the move. After the move, an administrator can resume the VM when the destination is ready.

This method can be useful for a paused test workload or another situation where preserving the current execution state is preferable to shutting down and booting the guest. It differs from cold migration because a cold migration starts from a powered-off VM, and it differs from vMotion because a suspended VM is not actively executing while it moves.

vSphere vMotion

vMotion is the live migration of a powered-on VM from one ESXi host to another. Its primary purpose is to change the VM's compute location while maintaining workload availability.

At a conceptual level, vMotion transfers the VM's active memory and execution state to the destination host while the VM is running. The source and destination hosts coordinate the transition so the VM can continue execution on the destination with minimal interruption.

Common uses include:

• Moving VMs away from a host before planned maintenance.
• Balancing CPU and memory demand across hosts.
• Optimizing workload placement as resource conditions change.

Before starting vMotion, validate environmental compatibility and network connectivity. The destination host must support the VM's required CPU and platform capabilities, have sufficient CPU and memory capacity, and provide suitable networking. The hosts also need a functioning VMkernel network configured for vMotion traffic.

vSphere Storage vMotion

Storage vMotion relocates the files of a powered-on VM from one datastore to another. It is a storage migration, not a host migration: the VM may continue running on the same ESXi host while its virtual disks and related files are copied or relocated.

Storage vMotion is commonly used to:

• Free capacity on a datastore that is becoming full.
• Move a workload to faster or more suitable storage.
• Drain or replace storage hardware.
• Apply a different storage placement or storage policy.

The source and destination datastores must be accessible and suitable for the VM files being moved. Sufficient destination capacity, healthy storage connectivity, and acceptable storage performance are required. When those requirements are satisfied, the VM can continue running while its files move.

Host Migration Versus Storage Migration

Choose the migration direction based on the problem you are solving:

• If the issue is CPU or memory pressure on an ESXi host, consider vMotion.
• If the issue is datastore capacity, performance, hardware replacement, or storage policy, consider Storage vMotion.
• If both compute and storage placement must change, use a workflow that moves both, provided the VM state and compatibility requirements allow it.
• If downtime is acceptable or live migration is not supported, use cold migration.
• If the workload is paused and its execution state must be preserved, consider suspended migration.

Migration Prerequisites and Compatibility

vCenter Server Coordination

vCenter Server manages the vSphere inventory and coordinates migration tasks. Administrators use it to select destinations, review compatibility checks, start operations, and monitor task progress.

Host Capacity

The destination ESXi host needs enough CPU and memory capacity for the VM and its expected workload. It also needs appropriate virtual networking and access to any required resources. A migration can fail or cause contention if the destination is technically available but does not have adequate headroom.

Host Compatibility

Live host migration requires compatible CPU and platform capabilities on the source and destination hosts. Differences in processor generations, exposed CPU features, VM hardware configuration, or other host characteristics can prevent vMotion or require additional compatibility configuration.

vMotion VMkernel Networking

A VMkernel network is an ESXi networking interface used for host services. A vMotion-enabled VMkernel interface provides the host network path used by vMotion traffic.

• Configure suitable VMkernel adapters on the source and destination hosts.
• Enable the vMotion service for the appropriate VMkernel interfaces.
• Confirm network reachability between the hosts.
• Provide sufficient bandwidth for transferring active VM memory and execution state.

Storage Accessibility

Host-based live migration scenarios commonly require the VM's storage to be shared or otherwise accessible by both the source and destination hosts. If the destination cannot access the VM's files, a host-only live move cannot complete without also relocating storage.

Storage vMotion requires source and destination datastores with suitable connectivity, visibility, free space, and performance. Confirm that the target can store all selected VM files, including virtual disks and configuration-related files.

Capacity, Concurrency, and Planning Limits

Migration operations consume resources. vMotion uses host CPU and memory resources and transfers data over the migration network. Storage vMotion consumes storage bandwidth, network bandwidth, host resources, and datastore input/output capacity.

Starting too many migrations at once can increase storage latency, consume network bandwidth, reduce application performance, and make each migration take longer. For the stated VMFS5 consideration, do not schedule more than eight concurrent migrations to a single VMFS5 datastore.

Concurrency limits and supported limits can vary by datastore type, vSphere product release, storage design, and the rest of the environment. Verify current platform documentation and storage guidance before scheduling large migration batches. Even when a platform permits a particular number of operations, actual storage and network capacity may require a lower number.

Migration Planning Checklist

Operational Checks Before and After Migration

1. Identify whether the goal concerns compute placement, storage placement, or both.
2. Record the current VM power state and decide whether shutdown, power-off, suspend, resume, or restart actions are appropriate.
3. Assess source and destination host CPU and memory capacity.
4. Check datastore free space, accessibility, and storage health.
5. Verify vMotion VMkernel connectivity and available bandwidth for live host migration.
6. Inspect dependencies such as mounted CD/DVD media, network mappings, device pass-through, and host-specific settings.
7. Choose a maintenance window or powered-off migration when the workload is not suitable for live movement or when downtime is safer.
8. Monitor the vCenter task and the host, network, and datastore performance during the operation.
9. After completion, verify the expected destination host and datastore.
10. Confirm the VM power state, guest operating system boot, virtual NIC connectivity, guest services, and application availability.

Selecting a Migration Method

Practical Examples

Balancing an Overloaded Host

An application VM is powered on while its ESXi host has high CPU or memory pressure. If another compatible host has sufficient capacity and vMotion networking is ready, use vMotion to move the VM's compute execution. Monitor performance after the move.

Preparing for Planned ESXi Maintenance

Before placing an ESXi host into maintenance mode, use vMotion to relocate its running VMs to compatible hosts. Confirm that every destination has enough capacity and that host-specific devices do not prevent movement.

Replacing or Draining a Datastore

If a datastore is being retired, use Storage vMotion to move running VMs' files to a datastore that remains in service. Stage the operations if many VMs are involved, and watch datastore latency and free space.

Moving a Noncritical VM During a Maintenance Window

Shut down a noncritical VM, perform a cold migration to a different host, datastore, or both, and power it on after the move. Validate guest boot and application availability before declaring the operation complete.

Relocating a Paused Test Workload

A suspended test VM can be moved while retaining its suspended state. After confirming the destination, resume the VM and verify that the test workload continues as expected.

Staging Storage Migration

When relocating many VMs, use batches rather than starting all Storage vMotion operations simultaneously. For a VMFS5 destination, keep concurrent migrations directed to that single datastore at or below eight, then monitor storage latency and network utilization before starting the next batch.

Troubleshooting Migration Problems

vMotion Is Unavailable or Fails Compatibility Validation

Likely causes include insufficient destination CPU or memory, incompatible host CPU or platform features, missing or unreachable vMotion networking, or a host-specific VM device or setting.

• Review the migration compatibility checks in vCenter Server.
• Confirm vMotion-enabled VMkernel connectivity between source and destination hosts.
• Check destination host capacity.
• Inspect attached devices, pass-through hardware, mounted media, and other VM dependencies.

Storage vMotion Cannot Use the Intended Datastore

Possible causes include insufficient free space, datastore inaccessibility, unsuitable storage connectivity, degraded performance, or too many migrations already targeting the datastore.

• Verify datastore visibility and free capacity.
• Review storage connectivity and latency.
• Confirm that the target can store the selected VM files.
• Reduce concurrent migrations, especially for a VMFS5 target.

Migration Is Slow or Affects Workload Performance

Slow operations can result from insufficient vMotion bandwidth, high memory change activity in a live VM, storage contention during Storage vMotion, or excessive concurrent migrations.

• Monitor migration-network throughput, host resource usage, and datastore latency.
• Schedule migrations during lower-demand periods.
• Move fewer VMs at one time.
• Stage operations to avoid saturating the source or destination storage.

The VM Does Not Operate Normally After Cold Migration

Check whether the guest operating system booted normally, whether the virtual NIC is connected to the correct port group, and whether application services started after power-on.

• Verify the VM power state and guest boot process.
• Confirm virtual network connectivity and port group assignment.
• Validate guest services and application reachability.

Boot and Power Operations Related to Migration

Power and boot actions should be part of the migration plan. A graceful shutdown allows the guest operating system and applications to stop cleanly. A forced power-off can cause data loss or filesystem recovery and should be reserved for situations where a normal shutdown is not possible. Suspend pauses execution while preserving the VM's suspended state; resume continues that state on the destination. A restart powers the guest through a new boot sequence and may be needed after certain operational changes.

After a cold migration, do not rely only on the vCenter task showing success. Confirm that the VM boots normally, receives expected network connectivity, starts required services, and responds to application tests. The same checks are useful after resuming a suspended VM or completing a live migration.

Exam-Relevant Notes

• vMotion: powered-on VM migration between ESXi hosts; it changes compute placement.
• Storage vMotion: powered-on VM file migration between datastores; it changes storage placement.
• Cold migration: migration of a powered-off VM and therefore includes planned downtime.
• Suspended migration: migration of a VM that is paused and retains its suspended execution state.
• Live host migration commonly depends on compatible hosts, sufficient destination resources, accessible storage, and vMotion-enabled VMkernel networking.
• vCenter Server coordinates vSphere migration operations.
• For the stated VMFS5 constraint, no more than eight concurrent migrations should target a single VMFS5 datastore.

For a concise reference, see VM migration in VMware vSphere.