VM live migration allows an administrator to relocate an active virtual machine between physical hypervisor hosts with no planned downtime, typically avoiding user-visible disconnections when stun time stays within the sub-second design window. At its core, VMware vMotion relies on an iterative memory pre-copy mechanism that transfers modified memory pages in repeated passes while the guest operating system continues running, with only brief micro-stuns or a final switchover pause when needed for convergence. The critical design threshold is the final cutover: VMware engineering documentation describes an approximate switchover goal of about 0.500 seconds (< 500 ms), stunning the virtual machine only when the remaining dirty memory pages can be transmitted within that brief latency budget. Understanding how this convergence mechanism operates—and how it contrasts with Microsoft Hyper-V's Shared Nothing Live Migration and Proxmox VE's shared storage requirements—is essential before you explore VMware alternatives or redesign your data centre cluster architectures.
View the data behind this chart
| Layer | Detail |
|---|---|
| Initial Memory Pre-Copy | Transfers baseline VM memory allocation to target |
| Iterative Dirty-Page Passes | Transfers only pages modified during prior pass |
| SDPS Micro-Throttling (if needed) | Injects microsecond vCPU pauses to drop dirty rate |
| VM Stun Phase (< 500 ms) | Pauses VM, sends final 37 dirty pages and state |
| Execution Resume & Gratuitous ARP | Target host resumes vCPUs and updates switch ARP |
The Core Mechanism: Iterative Pre-Copy and Stun Time
Live migration across enterprise hypervisors avoids downtime by decoupling memory transfer from execution state cutover. During standard runtime, an active virtual machine continuously alters its memory contents. If an administrator initiated a simple snapshot-and-copy operation, the hypervisor would have to pause the virtual machine for the entire duration of the multi-gigabyte memory transfer, causing unacceptable application timeouts.
To solve this, VMware vMotion establishes an iterative pre-copy cycle. In the initial pass, the hypervisor copies the entire memory allocation of the VM across the network to the target hypervisor host. Because the guest operating system remains active during this transfer, it continues to dirty memory pages. In subsequent iterations, vMotion tracks these modified addresses and transfers only the pages dirtied during the preceding iteration. This loop repeats, with each pass copying a progressively smaller set of memory changes.
The total migration duration must not be conflated with the stun time. The pre-copy phase constitutes the vast majority of the elapsed wall-clock migration time, during which active application processing and network connectivity proceed normally. Stun time, by contrast, occurs only at the very end of the cycle. Once the volume of remaining dirty memory pages decreases to a threshold that can be transferred within this target switchover budget, the virtual machine execution is briefly suspended on the source host. The remaining dirty pages and current device states are pushed to the destination, and execution resumes immediately on the new node.
- •Initial pass: The entire active RAM footprint is transferred to the destination host over the configured vMotion network.
- •Iterative passes: Only memory pages modified (dirtied) during the previous iteration are transmitted.
- •Stun phase: Virtual machine execution halts momentarily while the final dirty pages and hardware device states transfer.
Managing Memory Churn: Stun During Page Send (SDPS)
A primary obstacle to completing live migration occurs when an application dirties memory pages faster than the migration network can transmit them. If write churn exceeds network transmission throughput, the volume of dirty memory generated between iterations expands rather than contracts, preventing the migration from converging.
VMware introduced Stun During Page Send (SDPS) with vSphere 5.0 to address non‑converging vMotion migrations where the dirty‑page rate exceeds the transmit rate. When vMotion detects that memory iteration cycles are failing to converge towards the switchover threshold, SDPS activates. Instead of allowing guest threads to write unchecked when the dirty‑page rate exceeds the transmit rate, SDPS injects microsecond-level pauses into guest virtual CPU execution during migration iterations to force memory pre-copy convergence.
These microsecond execution pauses artificially throttle the rate at which the guest operating system can dirty additional memory pages. By dampening memory write churn without normally dropping TCP sessions or crashing applications, SDPS helps the remaining memory deficit shrink until it falls within the designated cutover window.
- •Introduced in vSphere 5.0 to resolve non-converging live migrations.
- •Injects microsecond pauses into guest vCPUs to limit page-dirtying rates.
- •Preserves guest application state and network connections while forcing convergence.
VMware vMotion Diagnostic Mechanics: A Worked Example
In VMware's vMotion troubleshooting documentation, diagnostic output details the exact runtime parameters monitored by the hypervisor to execute the final cutover. Administrators troubleshooting migration performance or examining `vmkernel.log` and `esxtop` metrics can observe how vMotion tracks remaining dirty memory pages against network throughput and the target switchover threshold.
In one recorded troubleshooting scenario documented by VMware, the hypervisor logs iterative convergence as dirty page counts decrease pass by pass. In that logged trace, the hypervisor reports a throughput of approximately 185.134 MB/s across the migration link, and the pre-copy process continues until 37 pages remain unsent.
At this volume, transmitting the final 37 pages comfortably complies with the cutover budget. The VMkernel halts execution on the source host, transmits the final 37 pages along with CPU and device state, issues a gratuitous (unsolicited) ARP to update the guest MAC address on the physical switch, and resumes vCPU execution on the target host.
Network and Cluster Prerequisites for vMotion
Running vMotion reliably in enterprise production requires meeting specific physical networking, compute, and licensing prerequisites. On the network layer, VMware recommends dedicated VMkernel interfaces isolated on their own VLAN or dedicated physical NICs (typically 10 GbE or higher for modern workloads) to guarantee throughput and prevent live migration traffic from contending with production VM workloads or host management.
At the compute level, host CPU architectures across the cluster must be compatible. VMware addresses processor disparities through Enhanced vMotion Compatibility (EVC), which enforces a common CPU feature baseline across all cluster nodes. EVC masks newer instruction set extensions, allowing seamless live migration between different CPU generations within the same processor family (Intel or AMD) without triggering guest operating system panics.
From an orchestration and licensing perspective, vMotion requires centralized cluster management via VMware vCenter Server and a vSphere licensing edition that includes vMotion capabilities. In addition, physical distance and network latency impose strict boundaries: standard intra-cluster vMotion requires a maximum round-trip time (RTT) latency ceiling of 10 ms, whereas long-distance or cross-site vMotion topologies support extended latency limits of up to approximately 150 ms RTT, provided adequate link bandwidth is maintained.
- •Network isolation: Dedicated VMkernel interfaces and VLAN isolation, ideally on 10 GbE or faster links to prevent traffic contention.
- •EVC compatibility: Enhanced vMotion Compatibility enforces a common CPU instruction baseline across disparate host hardware generations.
- •Management and licensing: Requires orchestration through VMware vCenter Server and a compatible vSphere licensing edition.
- •Latency thresholds: Standard intra-cluster migrations require under 10 ms RTT latency, while long-distance cross-site vMotion supports up to ~150 ms RTT.
Hyper-V Live Migration and Shared Nothing Architecture
Microsoft Hyper-V implements live migration using a comparable iterative pre-copy methodology, but differs significantly in how it handles underlying storage. In a standard clustered Hyper-V implementation, virtual machines reside on shared volumes, such as an SMB 3.0 file share or a cluster shared volume accessible by all cluster nodes. In this scenario, only the active memory state, device state, and execution context must traverse the migration link.
However, Microsoft also supports Shared Nothing Live Migration, designed for moving virtual machines whose virtual hard disks are not on SMB 3.0 or other shared storage so that hosts without common storage hardware can still migrate running VMs. (Similarly, vSphere also supports simultaneous compute and storage migration without shared storage by combining compute and storage migration into a single non-disruptive operation.) If a virtual machine's virtual hard disks are not situated on SMB 3.0 storage or an otherwise shared repository, Shared Nothing Live Migration moves the VM’s configuration files, virtual hard disks, and running memory state over the network in a coordinated process designed to complete without guest-visible downtime.
To accomplish this without shared storage, Hyper-V copies and synchronises the virtual machine’s virtual hard disks and configuration files to the destination node while performing memory pre-copy, then transfers the running state once storage is in sync. Once storage blocks are fully synchronised and active writes are mirrored, the hypervisor executes the final memory cutover. A critical constraint documented by Microsoft is that pass-through physical disks are not supported in Shared Nothing Live Migration.
- •Standard Live Migration: Uses shared storage such as SMB 3.0 shares or cluster shared volumes, so only RAM and CPU/device state need to be transferred.
- •Shared Nothing Live Migration: Synchronises configuration files, virtual disks, and memory state simultaneously across the network without requiring shared SAN or NAS infrastructure.
- •Storage Mirroring: Active disk writes are duplicated to the target storage location across the migration link prior to switchover.
- •Architectural Constraint: Pass-through physical disks are strictly unsupported without shared storage.
Proxmox VE: Shared Storage vs Offline Disks
Proxmox VE approaches virtual machine mobility from an architectural baseline that depends heavily on the deployment model of the storage back-end. Proxmox engineering guidance establishes that seamless live migration is native when virtual machine disks reside on shared storage accessible by all participating cluster nodes.
Proxmox explicitly identifies four primary shared storage implementations suited for this: Ceph, NFS, iSCSI, and GlusterFS. When virtual disks are provisioned across these shared fabrics, only the VM's active RAM state requires network transfer during live migration. Because the underlying storage block devices or files are already reachable by both hypervisor nodes, Proxmox conducts an iterative RAM pre-copy followed by a switchover pause measured in milliseconds.
Conversely, when virtual machines are deployed on local non-shared storage, Proxmox guidance distinguishes live migration from offline migration workflows. While shared fabrics permit continuous guest uptime during host evacuations, unshared local disks require dedicated storage-copy mechanisms, prompting administrators to weigh shared cluster storage versus local storage density before designing clusters.
- •Supported Shared Storage: Native live migration is documented across Ceph, NFS, iSCSI, and GlusterFS fabrics.
- •RAM-Only Migration: In shared storage environments, disk blocks remain stationary; only memory pages and runtime states are transferred.
- •Switchover Latency: Memory pre-copy culminates in a final execution pause lasting only milliseconds.
- •Local Disk Distinction: Unshared local storage layouts require alternative storage migration workflows rather than pure RAM live migration.
Architectural Comparison: vMotion, Hyper-V, and Proxmox
Selecting or migrating hypervisor platforms requires evaluating the operational trade-offs of their live migration engines. VMware vMotion delivers a mature, highly optimised memory transport framework governed by SDPS and strict switchover timing, making it exceptionally reliable for memory-heavy transactional workloads. While commonly deployed on shared SAN or vSAN storage, vSphere also supports shared-nothing migrations that move both compute and storage without shared volumes.
Microsoft Hyper-V provides high deployment flexibility through its Shared Nothing Live Migration capability. By supporting simultaneous live storage mirroring alongside memory pre-copy, Hyper-V allows administrators to evacuate nodes or rebalance hosts across detached storage topologies, provided pass-through disks are avoided.
Proxmox VE delivers clean operational simplicity in clustered environments equipped with distributed storage architectures like Ceph or enterprise NFS/iSCSI. For organisations assessing infrastructure changes, evaluating whether migration relies on a shared storage fabric or network-level storage replication directly dictates physical network bandwidth requirements, resilience planning, and hardware outlays.
Strategic Infrastructure Planning for UK Enterprises
For UK IT engineering teams, data centre live migration mechanisms dictate core infrastructure topology. When designing virtualised platforms, IT directors must determine whether to fund centralized shared storage—such as a resilient SAN, NAS, or distributed Ceph cluster—or adopt independent host architectures relying on network-based live storage replication.
In UK mid-market enterprises operating distributed branch estates connected by typical 100 Mbps to 1 Gbps leased lines or MPLS WAN connections, moving multi-gigabyte virtual disks across wide-area links introduces severe bandwidth bottlenecks. In such branch topologies, Shared Nothing Live Migration is best reserved for local rack-to-rack host evacuations, while cross-site moves require careful scheduling. Conversely, centralised UK colocation facilities and primary data centres equipped with 10 GbE or 25 GbE interconnects can support rapid state synchronisation without saturating production circuits.
For UK organisations operating enterprise SAN, iSCSI, or Ceph fabrics, host evacuations transmit only memory states, maintaining lower network overheads. When mapping lifecycle refreshes or evaluating platform transitions, balancing storage architecture against hypervisor migration capabilities ensures predictable migration convergence without risking service interruptions. To model the broader cost implications of system disruptions during major transitions, infrastructure leads frequently calculate the cost of IT downtime before committing to host architectures.
Sources
Every figure in this article traces to the sources below.
- •VMware — The vMotion Process Under the Hood
- •VMware — Enhanced vMotion for vGPU VMs in VCF 9.0
- •VMware — Troubleshooting vMotion Guidance
- •Microsoft — Virtual Machine Live Migration Overview
- •Microsoft — Live Migration Without Shared Storage
- •Proxmox — Proxmox Live Migration: Moving VMs
- •ProxmoxR — Proxmox Migration Guide: Live vs Offline