Tigera Logo

Guides: VMware Live Migration

VMware Live Migration: How vSphere vMotion Works + 5 Tips

What Is VMware Live Migration (vSphere vMotion)?

VMware Live Migration, known as vSphere vMotion, is a technology that seamlessly moves a running virtual machine from one physical ESXi server to another with zero downtime. Applications and network connections remain fully active during the transfer, enabling hardware maintenance, load balancing, and dynamic resource allocation.

How it works:

When you initiate a live migration, the vCenter Server and the ESXi hosts perform the following steps under the hood:

  • Compatibility check: The system verifies that the destination host can support the VM’s requirements.
  • Memory tracking: The VM’s memory and CPU state are iteratively copied from the source to the destination host. The system only copies memory pages that change during the transfer.
  • State transfer: The VM is briefly paused (a “stun” or suspension lasting milliseconds), the remaining memory and execution state are quickly transferred, and the VM resumes operation on the destination host.

Requirements for vMotion:

To perform a live migration without shared storage limitations, your environment requires:

  • Shared storage: Typically used so both hosts can access the VM’s disk files (though Storage vMotion removes this requirement if needed).
  • Network bandwidth: A dedicated Gigabit Ethernet (or higher) network for the vMotion interface is recommended.
  • CPU compatibility: Destination hosts must have compatible processors (or you must enable Enhanced vMotion Compatibility (EVC) in your cluster).

This is part of a series of articles about VMware migration.

In this article:

How VMware Live Migration Works

Compatibility Check

Before a live migration begins, the VMware environment performs a compatibility check to confirm that the virtual machine can run on the destination host. This step helps prevent migration failures and ensures that the VM continues operating correctly after it is moved. The system checks whether the destination host has compatible CPU features, sufficient compute resources, proper networking configuration, and access to the required storage.

Why it’s needed:
This check is important because a running VM depends on several host-level resources. For example, the destination host must be able to present compatible processor instructions to the VM, and the VM’s virtual network connections must be available on the destination side. If shared storage is used, both the source and destination hosts must be able to access the VM’s files. If the migration also involves moving storage, the system verifies that the destination datastore can support the VM.

If any requirement is not met, the migration may be blocked, or the administrator may receive warnings before proceeding. This prevents the VM from being moved to a host where it could lose network connectivity, fail to access its disks, or encounter CPU compatibility issues. The compatibility check acts as a safeguard that helps maintain service continuity during the migration process.

Memory Tracking

During vMotion, the virtual machine continues running on the source host while its memory is copied to the destination host. Since the VM remains active, its memory can change while the migration is taking place. To handle this, the system tracks which memory pages are modified during the copy process. These changed memory pages are then copied again so the destination host stays synchronized with the source host.

This process usually happens in multiple passes:

  1. First, most of the VM’s memory is transferred while the workload continues to operate.
  2. Then, any memory pages that changed during the first copy are sent again.
  3. The system continues tracking and transferring changed pages until the amount of remaining unsynchronized memory is small enough for the final handoff to occur quickly.

Why it’s needed:
Memory tracking is one of the main reasons vMotion can move a running VM with little or no visible disruption. Instead of shutting down the VM and copying all of its memory at once, the migration process prepares the destination host while the VM continues serving users and applications. This reduces the final pause required to complete the move.

State Transfer

After most of the VM’s memory has been synchronized, the migration enters the final state transfer phase:

  1. At this stage, the VM is briefly paused on the source host so the last remaining changes can be copied to the destination host. This includes the remaining memory pages, CPU execution state, and other information needed to resume the VM exactly where it left off.
  2. The destination host then takes over execution of the virtual machine.
  3. The VM resumes running on the new host using the transferred state, while network connectivity is maintained so users and applications can continue working without noticing the move.
  4. The VM does not reboot, its operating system remains active, and application sessions are preserved.
  5. Once the destination host resumes the VM, the source host releases its ownership of the running workload.
  6. If the migration cannot be completed successfully, the VM remains on the original host, protecting the workload from interruption.
  7. This final handoff allows administrators to move workloads between hosts while preserving service availability and reducing planned downtime.

Requirements for vSphere vMotion

Shared Storage

Shared storage is a requirement for traditional vMotion operations. Both the source and target ESXi hosts must have access to the same storage system, such as a SAN, NAS, or VMware vSAN. This shared access allows the VM’s virtual disks to remain available throughout the migration, so data does not need to be copied or moved during the process.

The use of shared storage allows only the VM’s memory and state to be transferred over the network, not its disk files. This reduces the overall time and bandwidth required for migration and lowers the risk of data inconsistency. Shared storage also supports high availability and failover capabilities.

Network Bandwidth

Adequate network bandwidth is required for successful live migrations. vMotion transfers the active memory and state of the VM over the network between hosts, which can involve gigabytes of data depending on the VM’s workload. Insufficient bandwidth can result in longer migration times or migration failures.

To optimize performance:

  • Use dedicated high-speed network interfaces, preferably 10 GbE or faster, for vMotion traffic.
  • Isolate vMotion traffic from other network workloads to reduce congestion and help migrations complete quickly, even during peak usage periods.
  • Ensure proper network planning and capacity management to help maintain reliable live migrations.

CPU Compatibility

CPU compatibility between the source and destination hosts is another requirement for vMotion. Hosts must support the same or compatible processor features so that the VM can execute instructions without errors after migration. VMware provides Enhanced vMotion Compatibility (EVC) to mask CPU differences and present a consistent feature set across hosts.

If CPU compatibility is not maintained, live migration may fail or the VM may experience application errors after migration. Administrators should configure EVC clusters and ensure that all hosts are running supported processor generations and features. This management avoids disruption and increases the flexibility of vMotion in mixed hardware environments.

Tips from the Expert

In my experience, here are tips that can help you get more reliable and predictable results from VMware live migrations:

  1. Check memory change rates before migrating large VMs:

    Workloads with heavy memory activity, such as databases and analytics platforms, can take longer to migrate because memory pages are constantly changing during the copy process.

  2. Use Enhanced vMotion Compatibility (EVC) proactively:

    Enable EVC before introducing new hosts into a cluster. This reduces CPU compatibility issues and provides greater flexibility when moving workloads between servers.

  3. Avoid migration storms:

    Automated load balancing can trigger multiple migrations simultaneously. Set reasonable thresholds and monitor cluster activity to prevent unnecessary resource consumption.

  4. Validate network dependencies before migration:

    Ensure VLANs, distributed port groups, security policies, and routing configurations are available on destination hosts. Many migration issues stem from network inconsistencies rather than vMotion itself.

  5. Schedule migrations around latency-sensitive workloads:

    Although vMotion downtime is typically measured in milliseconds, applications with strict latency requirements may still experience brief performance impacts. Test critical workloads before relying on live migration during production hours.

Profile Picture

Dillon Barry

Technical Marketing Engineer (TME)

Dillon Barry is a Technical Marketing Engineer at Tigera. He has worked with Kubernetes and Cloud Native technologies for over 8 years at some of the largest and most forward thinking companies in the industry. Based in Ireland, Dillon has a wealth of experience across different roles and industries as a consultant and solutions architect, with a background at companies like Pivotal and VMware. Dillon has a Bachelor's degree in Computer Science and an interest in everything modern computing.

VMware Live Migration Types

Host vMotion

Host vMotion refers to the live migration of a running virtual machine from one ESXi host to another while keeping the VM powered on. In this type of migration, the virtual machine’s compute execution moves from the source host to the destination host, but the VM’s storage usually remains in the same shared datastore. Because the VM files stay in place, both hosts must be able to access the same storage location.

Use case:
This type of migration is commonly used for host maintenance, hardware upgrades, patching, and workload balancing. For example, administrators can move running VMs away from a host before performing maintenance, allowing the host to be updated or restarted without shutting down the workloads. It is also used when a host is under heavy resource pressure and some VMs need to be moved to another host with more available CPU or memory capacity.

How it works:
Host vMotion requires proper network configuration, compatible hosts, and access to the required VM storage. The destination host must support the VM’s CPU, memory, network, and device requirements. When configured correctly, the VM continues running during the migration, and users typically do not notice that the workload has moved to another physical server.

Storage vMotion

Storage vMotion moves a virtual machine’s disk files from one datastore to another while the VM remains powered on. Unlike Host vMotion, which moves the running VM between hosts, Storage vMotion relocates the VM’s storage components. These components can include virtual disks, configuration files, snapshots, and related VM files.

Use case:
This type of migration is used when storage systems need maintenance, when datastores are running out of space, or when workloads need to be moved to faster or more appropriate storage. For example, an administrator might move a VM from older storage to a newer storage array, from standard storage to higher-performance storage, or from an overloaded datastore to one with more available capacity. The VM continues operating while its files are transferred in the background.

How it works:
During the process, the system tracks changes to the VM’s disks while the VM continues running. Once the data is synchronized on the destination datastore, the VM begins using the new storage location. This allows organizations to rebalance storage usage, retire old storage hardware, and adjust VM placement without interrupting services.

Shared-Nothing vMotion

Shared-Nothing vMotion combines compute and storage migration into a single operation. It allows a running virtual machine to be moved from one host and datastore to another, even when the source and destination hosts do not share the same storage. This makes it useful in environments where shared storage is unavailable or where workloads must move across storage accessibility boundaries.

How it works:
In a traditional Host vMotion, both hosts usually need access to the same datastore. In Shared-Nothing vMotion, the VM’s running state and its storage files are transferred as part of the migration. The VM can move to a different host and a different datastore at the same time while remaining powered on. The process transfers both the active workload state and the VM disk data needed for operation at the destination.

Use case:
This migration type is used when moving workloads between clusters, storage systems, or parts of an infrastructure that do not share common datastores. It also supports infrastructure upgrades, storage migrations, and workload consolidation projects. Because both compute and storage data are transferred, Shared-Nothing vMotion depends on network performance, available resources, and compatibility between the source and destination environments.

Cross-vCenter vMotion

Cross-vCenter vMotion allows virtual machines to be migrated between different vCenter Server instances. This is used when organizations manage multiple vCenter environments and need to move workloads between them without treating each vCenter as an isolated platform. Depending on the environment and configuration, this migration can move VMs between data centers, clusters, administrative domains, or cloud-connected vSphere environments.

Use case:
This type of migration supports operational flexibility and infrastructure modernization. For example, a company may use Cross-vCenter vMotion during data center consolidation, hardware refreshes, cloud migration planning, or transitions between separately managed vSphere environments. It allows workloads to be moved while preserving VM operation and reducing the need for manual rebuilds or extended downtime.

How it works:
Cross-vCenter vMotion requires the source and destination environments to meet specific compatibility, licensing, networking, and version requirements. Network compatibility is important because the VM must maintain proper connectivity after the migration. When configured correctly, the VM can be moved between vCenter Server systems while keeping the workload available and reducing disruption to users.

Long-Distance vMotion

Long-Distance vMotion extends vMotion capabilities across hosts or sites that are separated by higher network latency than a typical local migration. It is used to move running virtual machines across greater distances, such as between data centers or geographically separated sites, when the network and licensing requirements are met.

Use case:
This type of migration is used for planned data center maintenance, data center evacuation, disaster avoidance, workload balancing between sites, and infrastructure relocation. For example, an organization might use Long-Distance vMotion to move workloads from one site to another before scheduled maintenance or to shift workloads away from a location that is expected to experience service disruption.

How it works:
Long-Distance vMotion requires careful planning because the migration depends on network latency, bandwidth, reliability, and compatibility between the participating hosts and sites. The VM must continue functioning after the move, including maintaining network access and reaching required storage or services. When implemented properly, it provides greater mobility for running workloads across distributed infrastructure.

VMware Live Migration Best Practices

There are several ways that organizations can improve their migration of VMware infrastructure.

1. Use a Dedicated vMotion Network

A dedicated vMotion network should be used whenever possible to keep migration traffic separate from other infrastructure and application traffic. During a live migration, large amounts of VM memory data may be transferred between hosts, and this traffic can consume significant bandwidth. If vMotion shares the same network path as management, storage, or production workload traffic, migrations may slow down other services or become slower.

Separating vMotion traffic also improves security and operational control: The vMotion network should be accessible only to trusted hosts and infrastructure components because migration traffic can contain sensitive workload state information. Using a dedicated VMkernel adapter, separate VLAN, or dedicated physical network adapter helps limit exposure and ensures that only authorized hosts participate in migration operations.

For better performance, the vMotion network should have sufficient bandwidth and low latency between the source and destination hosts. High-speed adapters, such as 10 GbE or faster, are recommended for environments with large VMs, memory-intensive workloads, or frequent migrations. In larger environments, multiple NICs can distribute vMotion traffic and reduce migration time.

2. Monitor Performance During Migration

Live migration should be monitored to ensure that it does not negatively affect host, network, storage, or application performance. Although vMotion avoids downtime, the migration process still consumes CPU, memory, network bandwidth, and sometimes storage resources. If several migrations run at the same time, these resource demands can increase and affect other workloads.

Administrators should monitor host use before, during, and after migration: Important indicators include CPU usage, memory pressure, network throughput, datastore latency, and VM responsiveness. If a host is already under heavy load, moving additional workloads to or from that host may increase contention. Monitoring helps determine whether migrations should be delayed, limited, or scheduled during lower-activity periods.

Performance monitoring is especially important when migrating large VMs, busy database servers, latency-sensitive applications, or workloads with high memory change rates. These workloads can take longer to migrate because memory pages may continue changing while the transfer is in progress.

3. Separate vMotion, Storage, Management, and Kubernetes Workload Traffic

Different types of infrastructure traffic should be separated to improve performance, security, and reliability. vMotion traffic, storage traffic, management traffic, and Kubernetes workload traffic each serve different purposes and place different demands on the network. Keeping them separated helps prevent one traffic type from consuming bandwidth or affecting another function.

Management traffic should remain stable and protected: This is because it is used to manage hosts, clusters, and platform components. Storage traffic requires predictable performance because storage latency can directly affect VM and application behavior. vMotion traffic can create large temporary bursts during migrations, while Kubernetes workload traffic may include pod-to-pod, service, ingress, and application communication. Mixing these on the same network without controls can create congestion and make troubleshooting more difficult.

Separation can be achieved through dedicated physical adapters, VLANs, distributed port groups, network I/O control, traffic shaping, and clear network design. In environments running Kubernetes on vSphere, administrators should ensure that Kubernetes node, pod, service, and ingress traffic have the required connectivity without interfering with vSphere management or migration operations.

Related content: Read our guide to VMware NSX alternatives.

4. Drain Kubernetes Nodes When Workload Disruption Risk Is High

When a virtual machine being migrated acts as a Kubernetes node, administrators should consider the potential impact on the workloads running inside the cluster. While vMotion keeps the VM running, some Kubernetes workloads may be sensitive to brief pauses, network changes, latency spikes, or resource pressure during migration. This is especially important for stateful applications, latency-sensitive services, or workloads with strict availability requirements.

If the risk of disruption is high, the Kubernetes node should be drained before migration. Draining a node safely evicts eligible pods and allows Kubernetes to reschedule them onto other available nodes. This reduces the chance that application workloads will be affected if the migration causes temporary performance changes. It also gives administrators more control over where workloads run during maintenance or infrastructure changes.

Before draining a node, administrators should confirm that the cluster has enough capacity to run the affected workloads elsewhere. They should also consider PodDisruptionBudgets, replica counts, storage attachments, and application availability requirements. After migration is complete and the node is stable, the node can be returned to normal scheduling.

5. Stage Network Policies Before Enforcing Them

Network policies should be introduced carefully, especially in environments where Kubernetes workloads depend on specific communication paths. A policy that is too restrictive can block pod-to-pod traffic, service access, DNS resolution, ingress traffic, monitoring connections, or communication with external systems. During migration planning or network redesign, policies should be staged and tested before being broadly enforced.

A good practice is to first map the required traffic flows for the applications and platform services. This includes identifying which namespaces, pods, services, ingress controllers, databases, APIs, and monitoring tools need to communicate. Policies can then be created in a controlled way, tested in a non-production environment, and gradually applied to production workloads.

When enforcing network policies, administrators should monitor application behavior and network connectivity closely. Logging, observability tools, and staged rollout methods can help identify blocked traffic before it causes a major outage. This is especially important when live migration, host maintenance, or Kubernetes node movement is happening at the same time, because network changes and workload placement changes can interact in unexpected ways.

Enhancing Live Migration Security and Visibility with Tigera’s Calico

Calico extends the VM’s existing Layer 2 segment into the Kubernetes cluster and tracks its IP, VLAN, and MAC across nodes, so a KubeVirt live migration becomes a node-to-node compute event rather than a network reconfiguration event. The same data plane that preserves network identity also provides eBPF-based flow visibility and Kubernetes-native policy enforcement on the VM’s interfaces, giving migrated workloads the security and observability posture expected of any other workload in the cluster.

  • Calico L2 Bridge Networks for VM network continuity. Calico creates a bridge on each cluster node and attaches a trunk interface, allowing the VM’s original VLAN, IP address, and MAC address to be carried directly into Kubernetes through a secondary interface (net1) on the virt-launcher pod. Multiple VLANs can share the same trunk-backed bridge, so the existing Layer 2 topology is preserved without per-VLAN infrastructure.
  • Declarative network configuration. Administrators define a Kubernetes network resource that tells Calico which VLAN to bridge and how to map it, and a NetworkAttachmentDefinition instructs KubeVirt to attach the secondary interface at boot. Migration tooling such as Forklift maps existing VM interfaces to these definitions and registers the VM’s IP with Calico before cutover.
  • IP tracking across live migration. Once Calico owns the VM’s IP, it maintains routing state and follows the VM as KubeVirt moves it between nodes, so the same IP, VLAN, and MAC remain bound to the workload after migration. From the upstream network’s perspective the VM has not moved, which means firewall rules, DNS records, load balancer backends, and monitoring targets continue to resolve without change.
  • eBPF-based observability for VM interfaces. Calico provides traffic flow data, communication patterns, and east-west visibility for VM interfaces using eBPF, without requiring per-host agents, taps, or external monitoring tooling. This visibility applies to the same interfaces both before and after a live migration, giving consistent flow telemetry as VMs move across nodes.
  • Kubernetes-native network policy on VM interfaces. Calico network policy can be applied directly to VM interfaces using the same label and selector model used for containers, with selectors that can target specific VLANs or external networks. Existing hypervisor firewall rules can be migrated incrementally into version-controlled, auditable Calico policy without disrupting the workload or its live-migration behavior.

Next Steps

X