---
title: Virtual Machine Live Migration
url: https://www.emergentmind.com/topics/virtual-machine-live-migration
type: topic
---

# Virtual Machine Live Migration

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 [2512.10979][2101.09716][2112.02593][1601.03854].

## 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 [2512.10979][2112.02593][1601.03854].

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 [2108.12509]. In wireless fog settings, the pre-copy workflow is expanded into **Pre-migration**, **Reservation**, **Iterative pre-copy**, **Stop-and-copy**, **Commitment**, and **Reactivation** [1805.12509][1701.06178]. 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 [1706.04118].

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 [2512.10979][1601.03854]. 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 [1406.5760].

## 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 \(R_k\cdot \rho_k/L<1\) [2101.09716].

A closely related classical form writes total migration time as
\[
T_{\mathrm{mig}}=\sum_{i=0}^{N-1}\frac{M_i}{B_i}+T_{\mathrm{stop}},
\]
with downtime
\[
D=\frac{M_N}{B_N}+T_{\mathrm{sync}},
\]
where \(M_0\) is the total memory footprint and later \(M_i\) are the pages dirtied during previous rounds [2112.02593]. OpenStack-oriented modeling decomposes
\[
T_{\mathrm{total}}=T_{\mathrm{pre}}+T_{\mathrm{stop}}+T_{\mathrm{post}},\qquad
T_{\mathrm{down}}\approx T_{\mathrm{stop}}+T_{\mathrm{post}},
\]
while wireless fog formulations separate
\[
T_{\mathrm{tot}}=T_{\mathrm{PM}}+T_{\mathrm{RE}}+T_{\mathrm{IP}}+T_{\mathrm{SC}}+T_{\mathrm{CM}}+T_{\mathrm{AT}},
\qquad
T_{\mathrm{down}}=T_{\mathrm{SC}}+T_{\mathrm{CM}}+T_{\mathrm{AT}}.
\]
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 [2108.12509][1805.12509].

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 \(B\), dirty-page rate \(\lambda\), transmitted memory \(M_{\rm tr}\), and iteration count \(N\) as the central analytical variables [2112.02593]. 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
\[
MO(v,p)=\alpha_1 MD(v,p)+\alpha_2 MT(v,p)+\alpha_3 DT(v,p)+\alpha_4 NC(v,p).
\]
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 [1706.06646].

## 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 [2101.09716][2111.08942].

SLAMIG composes a **deadline-aware multiple migration grouping algorithm** with **on-line migration scheduling**. It first builds a dependency graph \(G_{\mathrm{dep}}\), extracts maximal complete subgraphs, computes for each request a weight
\[
cost(n_j)=\alpha\cdot T_{\mathrm{mig}}^j+\beta\cdot (T_{\mathrm{mig}}^j-D_j)+\gamma\cdot I_j,
\]
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:
\[
\min \sum_{k=1}^{K}\tau_k+\sum_{k=1}^{K}\max\{0,\tau_k-D_k\}.
\]
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 [2101.09716].

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% [2111.08942].

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 \(y[n]\) of “LM” or “NLM” states:
\[
Y[k]=\sum_{n=0}^{N-1} y[n] e^{-j\,2\pi\,k\,n/N}.
\]
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 [1607.07846].

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 [1706.06646]. 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 [2007.08695].

## 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 \(i\) evaluates the average weighted latency
\[
u_i(x)=\frac{\sum_{j=1}^{n} d_{ij}\, l(x,x_j)}{\sum_{j=1}^{n} d_{ij}},
\]
with
\[
l(x_i,x_j)=\tau(x_i,x_j)+\rho(x_i)+\rho(x_j),
\]
and migrates if a regularized inequality involving \(u_i(\cdot)\), cloud load \(w_x\), and a function \(f(w_x)\) 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 \(n\) at approximately \(O(n^{0.8})\), the worst-case ratio \(C(\sigma^{NE})/C(\sigma^*)\) was about 1.21 and the average about 1.1 for \(\eta=0.9\) [1610.00289].

Wireless fog migration introduces explicit energy-delay coupling. Both TCBM and SCBM model transmission power as
\[
P(R)=K_0 R^\alpha,
\]
and minimize migration energy subject to hard constraints on total migration time, downtime, convergence speed, and maximum bandwidth [1701.06178][1805.12509]. SCBM clusters pre-copy rounds so that only \(Q+2\) 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 \(Q=1\), up to 20% with \(Q=3\), and up to 70% energy gain for MPTCP(EWTCP) versus SPTCP when \(VM\ge 64\) Mb, \(D_{\max}<200\) ms, and \(\bar w/\widehat R>0.1\) [1805.12509]. 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 \(\bar w\) or \(K_0\) [1701.06178].

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 \(T_{\rm total}\approx 15.5\) s versus 52 s in the two-layer model, \(T_{\rm down}\approx 3.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 [1706.04118].

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, \(T_{\rm total}\approx 59\) s, \(T_{\rm down}\approx 0.8\) s, and network load about 3.5 GB; **Container Small** had checkpoint 13 s, metadata transfer 3 s, restore 16 s, \(T_{\rm total}\approx 32\) s, and \(T_{\rm down}\approx 32\) 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 [2108.12509].

## 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
\[
T=\langle a, B, c, D\rangle,
\]
with an access matrix \(B\), subject and object integrity mappings \(c_s\) and \(c_o\), and separation-of-duty constraints \(D\). The framework enforces the Simple-Security Property
\[
\forall(s,o,\alpha)\in a.\ \text{if }\alpha=r\ \text{or}\ \alpha=a\ \text{ then } c_s(s)\ge c_o(o),
\]
and uses standard TPM mechanisms such as PCR chaining and nonce-challenge quotes to protect the migration path [2110.04457].

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 [2110.04457].

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 \(save[i]\) and \(restore[i]\). 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 [2311.06991].

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 [2110.04457][2311.06991].

## 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 [1607.07846]. 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 [2108.12509]. 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 [2101.09716][2111.08942].

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 [2512.10979]. 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 [1406.5760][2311.06991][1706.04118].

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 [2007.08695]. 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 [2108.12509]. The 2021 taxonomy similarly notes that container platforms still trail VM migration in performance and orchestration maturity in several edge scenarios [2112.02593].

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 [2101.09716][2112.02593][2512.10979][1601.03854].

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.

Source: https://www.emergentmind.com/topics/virtual-machine-live-migration