Virtual Machine Live Migration

• Virtual Machine Live Migration is the process of moving running virtual machines between physical hosts with minimal service interruption to enable cloud elasticity and high availability.
• It employs paradigms like pre-copy, post-copy, and hybrid methods that balance redundant transfer with minimized downtime, leveraging iterative transfers and on-demand memory fetches.
• Optimization focuses on dependency-aware scheduling, robust resource management, and integrated security measures to handle varying workloads and network conditions across cloud and edge environments.

Virtual machine live migration is the process by which a running VM—its CPU state, memory contents, device state, and network connections—is moved from one physical host to another with minimal interruption of service. Since its first demonstration in 2005, it has become a core mechanism for cloud elasticity, high-availability clusters, and edge-to-cloud handovers. In cloud and SDN-NFV environments, it supports reallocation of VMs in cloud services and Virtual Network Functions in Service Function Chaining; in broader resource management, it underpins load balancing, consolidation, fault management, disaster recovery, and real-time maintenance (Attar-Khorasani et al., 3 Dec 2025, He et al., 2021, He et al., 2021, Liaqat et al., 2016).

1. Migration paradigms and execution phases

The canonical taxonomy distinguishes pre-copy, post-copy, and hybrid migration. In pre-copy, the source VM continues executing while memory is pushed iteratively to the destination; pages dirtied during one round are resent in later rounds until the remaining dirty set falls below a threshold, after which the VM is paused and the residual state is transferred. In post-copy, the VM is suspended, minimal execution state is sent to the destination, execution resumes there, and the remaining pages are fetched on demand. Hybrid schemes combine both patterns, typically using a bounded amount of pre-copy before switching to pull-based completion (Attar-Khorasani et al., 3 Dec 2025, He et al., 2021, Liaqat et al., 2016).

These techniques recur across systems with environment-specific phase decompositions. In OpenStack/KVM–QEMU, the process is described as pre-live/pre-copy, live/stop-and-copy, and post-live, where Nova and Neutron update database state and port bindings after memory transfer (Ramanathan et al., 2021). In wireless fog settings, the pre-copy workflow is expanded into Pre-migration, Reservation, Iterative pre-copy, Stop-and-copy, Commitment, and Reactivation (Baccarelli et al., 2018, Amendola et al., 2017). In Mobile Edge Clouds, a layered framework decomposes service state into base, application, and instance layers so that only the instance layer contributes to downtime (Machen et al., 2017).

The main technical distinction among the paradigms is how they trade redundant transfer, service interruption, and failure exposure. Pre-copy minimizes pause time but may recopy hot pages many times. Post-copy eliminates redundant retransfers but exposes the VM to failure sensitivity if the source fails before all pages arrive (Attar-Khorasani et al., 3 Dec 2025, Liaqat et al., 2016). Hybrid designs attempt to bound both effects. A notable implementation-oriented example is Virtual Memory Streaming, which combines iterative pre-copy, a brief stop-and-copy handover, and lazy post-copy fetches via read caching; it describes service interruption on the order of 5–30 ms and presents VMS-based clone startup times of 2–10 s, alongside 2×–4× memory oversubscription on a 16 GB host (Moniruzzaman et al., 2014).

2. Analytical models, convergence conditions, and core metrics

Across the literature, live migration is modeled by the interaction of VM memory size, dirty-page rate, and available bandwidth. In the SLAMIG formulation, a migration request $k$ is characterized by source $s_k$, destination $d_k$, memory size $M_k$, average page-dirtying rate $R_k$, compression factor $\rho_k$, deadline $D_k$, and feasible paths $P_k$. Under pre-copy, its network-copy time is

$T_{\mathrm{mem},k}=\sum_{i=0}^{n}T_i,$

with

$$V_0=\rho_k M_k,\qquad V_i=\rho_k\cdot T_{i-1}\cdot R_k\ \text{for}\ i>0,\qquad T_i=\frac{V_i}{L_i},$$

and convergence requires $s_k$0 (He et al., 2021).

A closely related classical form writes total migration time as

$s_k$1

with downtime

$s_k$2

where $s_k$3 is the total memory footprint and later $s_k$4 are the pages dirtied during previous rounds (He et al., 2021). OpenStack-oriented modeling decomposes

$s_k$5

while wireless fog formulations separate

$s_k$6

These formulations emphasize that downtime is only one component of the operational cost; pre- and post-phases, network reconfiguration, and commit/activation overheads can be material (Ramanathan et al., 2021, Baccarelli et al., 2018).

The standard performance metrics are total migration time, downtime, total transferred data, and, in management settings, deadline misses, QoS degradation, energy consumption, and response-time impact. The 2021 taxonomy additionally highlights available network bandwidth $s_k$7, dirty-page rate $s_k$8, transmitted memory $s_k$9, and iteration count $d_k$0 as the central analytical variables (He et al., 2021). In migration-impact-aware consolidation, overhead is explicitly decomposed into Migration Data (MD), Migration Time (MT), Downtime (DT), and Network Cost (NC), then aggregated as

$d_k$1

This suggests a common modeling structure: live migration is not a single latency number, but a coupled optimization over memory dynamics, bandwidth allocation, residual state, and system-side side effects (Ferdaus et al., 2017).

3. Planning, scheduling, and migration-aware resource management

When multiple migrations are triggered together, ordering and concurrency become first-order concerns. In SDN-enabled cloud data centers, performing multiple live migrations in arbitrary order can lead to service degradation; both SLAMIG and CAMIG formalize this through resource dependency graphs whose edges represent shared source hosts, shared destination hosts, or overlapping network paths (He et al., 2021, He et al., 2021).

SLAMIG composes a deadline-aware multiple migration grouping algorithm with on-line migration scheduling. It first builds a dependency graph $d_k$2, extracts maximal complete subgraphs, computes for each request a weight

$d_k$3

greedily assigns tasks to concurrent groups, and finally schedules group launches online under current SDN-reported bandwidth availability. Its objective minimizes the sum of response times and tardiness: $d_k$4 The reported results show total migration time reductions over one-by-one scheduling of up to 60–87%, total downtime reductions of 40–55% versus FPTAS, misses of approximately 0 tasks where other methods miss up to 90% of deadlines, marginal QoS degradation of less than 0.7 s versus more than 2 s for FPTAS/CQNCR, energy savings of up to 20–30%, and planning runtime of about 30 s for 1,000 migrations (He et al., 2021).

CAMIG addresses the same interference problem from the perspective of concurrency-aware selection. Its dependency graph is analyzed via maximal cliques and independent sets, and candidate migrations are ranked by a Migration Concurrency Score that captures how much adding a migration would force serialization with already selected ones. In small-scale load balancing, CAMIG matched the optimal dependency count and convergence time up to 32 hosts, reduced dependent migrations by up to 90% versus a Sandpiper baseline, and reduced convergence time by 25–92% compared to running the same VM moves with a naïve one-by-one scheduler. In a 24 h PlanetLab-trace evaluation on a 1024-host fattree, it cut the number of migrations by 32%, total migration time by 73%, downtime by 50%, host energy by 3.8%, switch energy by 38%, workload timeouts by 14%, and average serve time per VM slice by 8% (He et al., 2021).

Not all orchestration is network-centric. ALMA interposes a Live Migration Control Module between consolidation policies and the hypervisor and detects workload cycles via the FFT of a binary time series $d_k$5 of “LM” or “NLM” states: $d_k$6 Migration is triggered immediately if the current phase belongs to the recognized low-impact set; otherwise it is postponed to the next “safe” window. In a private-cloud testbed, migration times were reduced by up to 74.6% for benchmarks and 67.5% for real applications, while network traffic was reduced by approximately 21.6% and up to 62.2%, respectively; downtime showed no statistically significant change (Baruchi et al., 2016).

Migration-aware placement and consolidation algorithms integrate these execution costs upstream. A decentralized ACO-based consolidation framework models per-VM migration overhead and optimizes released PMs against migration cost, reporting reductions of up to 47% in power consumption, 64% in resource wastage, and 83% in migration overhead relative to a migration-unaware baseline (Ferdaus et al., 2017). A threshold-based DRM model driven by RAM utilization uses live migration for overload relief and underload consolidation; in the reported experiments, VM migration yielded about 120 s migration time and 120–130 ms downtime, while container migration under the same framework yielded about 96 s and about 95 ms, with an energy saving of about 250 W by shutting off one host (Smimite et al., 2020).

4. Edge, fog, wireless, and optical-backhaul regimes

In edge and fog computing, live migration is driven not only by server-side objectives but also by user mobility, radio conditions, and end-to-end latency. Flock formulates decentralized VM migration across heterogeneous edge and conventional cloud platforms as a congestion game. Each VM $d_k$7 evaluates the average weighted latency

$d_k$8

with

$d_k$9

and migrates if a regularized inequality involving $M_k$0, cloud load $M_k$1, and a function $M_k$2 is satisfied. The protocol is fully decentralized, converges to a Nash equilibrium, and admits a Price of Anarchy bound; in simulation, convergence rounds grew sublinearly in $M_k$3 at approximately $M_k$4, the worst-case ratio $M_k$5 was about 1.21 and the average about 1.1 for $M_k$6 (Abdelwahab et al., 2016).

Wireless fog migration introduces explicit energy-delay coupling. Both TCBM and SCBM model transmission power as

$M_k$7

and minimize migration energy subject to hard constraints on total migration time, downtime, convergence speed, and maximum bandwidth (Amendola et al., 2017, Baccarelli et al., 2018). SCBM clusters pre-copy rounds so that only $M_k$8 rates are optimized, applies a log-transform to obtain a convex program, and uses an adaptive primal-dual solver. Reported results include 25–45% energy saving versus the Xen heuristic, about 12% saving versus LIV_MIG with $M_k$9, up to 20% with $R_k$0, and up to 70% energy gain for MPTCP(EWTCP) versus SPTCP when $R_k$1 Mb, $R_k$2 ms, and $R_k$3 (Baccarelli et al., 2018). TCBM reports 3–44% energy savings over Xen in 4G, up to 82% in Wi-Fi, and convergence within about 6–7 re-optimizations under abrupt changes in $R_k$4 or $R_k$5 (Amendola et al., 2017).

In MEC-specific service migration, the three-layer model separates base, application, and instance layers so that the application layer can be transferred while the service is still running. For LXC, when the application layer was already present at the destination, Face Detection showed $R_k$6 s versus 52 s in the two-layer model, $R_k$7 s versus 47.6 s, and transferred data of about 10 MB versus 363 MB; Video Streaming showed 8.5 s versus 27.5 s total time and 3.3 s versus 23.2 s downtime. Containers migrated 4–20× faster than KVM under typical RAM loads (Machen et al., 2017).

Optical-backhaul experiments show a different trade-off. For virtualized EPC components over OpenROADM, VM migration in OpenStack/KVM–QEMU had longer total times but short downtime, whereas container migration had shorter total time but downtime equal to total time. For HSS on an OpenROADM short lightpath, VM Small had Pre-live about 3.24 s, Live about 51 s, Post-live about 5 s, $R_k$8 s, $R_k$9 s, and network load about 3.5 GB; Container Small had checkpoint 13 s, metadata transfer 3 s, restore 16 s, $\rho_k$0 s, and $\rho_k$1 s. Similar behavior was observed for MME and SPGW. In CloudLab with 10 Gb/s co-located servers, HSS-VM total time dropped to about 17 s and HSS-container to about 15 s (Ramanathan et al., 2021).

5. Security, integrity, and trusted-state migration

Secure migration introduces additional state objects and trust dependencies that are absent from conventional throughput-centric models. Kororā, designed for Xen on a public IaaS environment, uses a virtual TPM Agent, I/O Agent, Data Plane Agent, Integrity Analyzer Agent, and Data Organization Agent. It formalizes operation as a state machine

$\rho_k$2

with an access matrix $\rho_k$3, subject and object integrity mappings $\rho_k$4 and $\rho_k$5, and separation-of-duty constraints $\rho_k$6. The framework enforces the Simple-Security Property

$\rho_k$7

and uses standard TPM mechanisms such as PCR chaining and nonce-challenge quotes to protect the migration path (Deylami et al., 2021).

Kororā’s contribution is not a new copy algorithm so much as an end-to-end integrity architecture around the standard Xen pre-copy path. The vTPM state moves in lock-step with the VM, outgoing writes are redirected through the I/O agent, and the data plane binds migrated chunks to nonces and TPM quotes. The paper notes that the implementation is not practically feasible in traditional distributed computing environments and requires fixed resources with high-performance capabilities connected through a high-speed, reliable network (Deylami et al., 2021).

Trusted Execution Environments intensify these problems because hypervisors cannot directly inspect dirty bits inside the protected region. ConstMig, built on Intel SGX and described as fully compatible with containers, virtual machines, and microVMs, splits state into a small synchronous metadata buffer (MBuff) and a large encrypted BBuff migrated asynchronously in post-copy style. Save and restore progress are tracked with per-page bit vectors $\rho_k$8 and $\rho_k$9. The system offers a kernel-based Fault Tracker and a compiler-based Access Tracker; for a 5 GB enclave it reports MigSGX downtime of about 8 s versus about 1.3 s for ConstMig-v1 and about 0.3 s for ConstMig-v2, corresponding to 84–96% reduction, while the abstract summarizes total downtime reductions of 77–96% for a suite of multi-GB SGX applications (Kumar et al., 2023).

These systems show that secure live migration is not reducible to encrypting the migration channel. Integrity-protected metadata, trusted replay of device or enclave state, and page-access-triggered restoration become part of the migration mechanism itself. A plausible implication is that future secure VM migration will continue to blur the boundary between hypervisor policy, operating-system support, compiler/runtime instrumentation, and hardware trust anchors (Deylami et al., 2021, Kumar et al., 2023).

6. Trade-offs, misconceptions, and open research directions

A persistent misconception is that shorter total migration time implies shorter downtime. The evidence is mixed. ALMA reduced migration time substantially while downtime remained statistically unchanged (Baruchi et al., 2016). In the OpenROADM EPC experiments, container migration often had much shorter total time than VM migration, yet container downtime equaled total time, whereas VM downtime remained around 0.8–1.2 s (Ramanathan et al., 2021). Another misconception is that more concurrency is always better: both SLAMIG and CAMIG show that only concurrency among resource-independent migrations is beneficial; arbitrary concurrency can increase convergence time, deadline misses, and QoS degradation (He et al., 2021, He et al., 2021).

Production preferences are also nuanced. The 2025 review states that pre-copy is generally preferred for reliability in production, whereas post-copy’s risk of total VM loss on source failure is unacceptable for most SLAs; hybrid methods are maturing but require careful hypervisor support (Attar-Khorasani et al., 3 Dec 2025). At the same time, several systems deliberately incorporate post-copy elements or demand fetching when the environment justifies it, as in VMS, ConstMig, and layered edge migration (Moniruzzaman et al., 2014, Kumar et al., 2023, Machen et al., 2017).

Container-based alternatives complicate any simple VM-versus-container narrative. Containers can reduce migration time and power consumption, pack workloads more tightly, and enable finer-grained consolidation (Smimite et al., 2020). Yet current CRIU-based migration does not fully support the mobile network protocol stack without extensions, and custom shell scripts and CRIU options were required in the OpenROADM study (Ramanathan et al., 2021). The 2021 taxonomy similarly notes that container platforms still trail VM migration in performance and orchestration maturity in several edge scenarios (He et al., 2021).

Open problems identified across the literature are highly consistent. They include joint optimization of which subset to migrate with routing and scheduling, extension to heterogeneous deadlines and multi-SLAs in multi-tenant settings, handling of unpredictable page-dirtying bursts and packet-loss/latency fluctuations in WANs, flexible networking management via slicing, compatibility among multiple migration optimization models, management scalability for mega-scale edge clouds, robustness and secure migration, security-hardened migration with TEE- and TPM-based trust anchors, heterogeneous-ISA migration, and standardized metadata schemas for reproducible live-migration logs (He et al., 2021, He et al., 2021, Attar-Khorasani et al., 3 Dec 2025, Liaqat et al., 2016).

Taken together, these results depict virtual machine live migration as an orchestration problem spanning hypervisor algorithms, workload behavior, network control, energy policy, and trust management. The technical frontier is not a single faster copy loop, but coordinated control of dependency-aware scheduling, application-aware timing, path-aware bandwidth allocation, integrity-preserving state transfer, and environment-specific execution models from cloud cores to wireless fog and optical backhaul.