Live VM Migration Explained: Moving RAM and Processes Without Downtime

Live migration moves a running virtual machine from one physical server to another without shutting down the guest OS or restarting the applications inside it.

Traditional data centers use it for hardware maintenance. With preemptible Spot instances, the same mechanism is how workloads survive host reclamation: instead of SIGTERM and a cold restart, the platform migrates RAM and processes to another server before the host goes away.

In short: live migration copies a running VM’s RAM and processes to another server without restarting the app. It only works together with stable networking and replicated volumes.

Below: how pre-copy and stop-and-copy actually work, what breaks if you migrate memory alone, and how the microsrv orchestrator uses live migration when an eviction notice arrives.

1. Why live migration matters

Without live migration, changing hosts almost always means a cold restart:

processes are killed and in-memory caches are wiped;
local ephemeral disks are lost;
IP addresses and TCP sessions are dropped;
clients see downtime until the guest boots again and is reconfigured.

Batch jobs tolerate that. Web APIs, databases, long-lived SSH sessions, and services that keep state in RAM do not. Live migration keeps the workload running: the guest OS largely never notices that the hardware underneath it changed.

2. Pre-copy: iterative memory transfer

Most hypervisors (KVM/QEMU, Xen, VMware) use a pre-copy scheme:

First pass. While the VM keeps running on the source host, the hypervisor copies RAM pages to the target.
Dirty pages. The guest keeps writing memory. Changed pages are marked and resent.
Convergence. As long as transfer speed outpaces the dirtying rate, the remaining dirty-page set shrinks.
Stop-and-copy. The guest vCPUs pause briefly while the remaining memory and device state are transferred, then the VM resumes on the target host.

The pause typically lasts milliseconds or tens of milliseconds. Client TCP timeouts and health checks usually never see it, provided networking and storage are also ready for the VM on the destination host.

Post-copy as an alternative

In a post-copy scheme, the VM starts on the target immediately, and missing pages are fetched on demand through page faults. Cutover happens sooner, but latency spikes get worse and the migration channel becomes a single point of failure. In practice, orchestrators often combine the two approaches or prefer pre-copy when the eviction window is short but predictable.

3. What breaks if you migrate only RAM

Successful memory transfer is necessary but not sufficient. Without two more layers, clients still see a failure:

Networking. Private IPs, routes, and sockets remain bound to the old host, so packets stop reaching the VM after cutover. See the deep dive on microsrv eBPF networking.
Disks. The root volume and data lived on the source server’s local SSD only, so the target has no filesystem to attach. You need replicated volumes that are independent of any single Spot node.

That’s why production live migration is not one hypervisor call. It is a coordinated sequence: reserve capacity → synchronize memory → rebind the network → confirm the disk is already available on the target.

4. Cold restart: the fallback for hard failures

Live migration needs advance notice and a healthy path to the target. A server that suddenly loses power or hits a kernel panic gives you neither, and pre-copy cannot finish.

The remaining path is a cold restart from a replica:

the orchestrator detects host loss;
it picks a new node with free vCPU and RAM;
it boots the VM from the replicated disk;
it rebinds network identity.

The application restarts and loses its in-memory cache, but its disk data and stable address survive. That is worse than a migration that completes cleanly, and far better than losing the instance entirely, which is what raw Spot capacity without a platform gets you.

5. How the microsrv orchestrator handles eviction

microsrv runs on hyperscaler Spot capacity and places its own orchestrator above it. A typical eviction sequence:

Eviction notice received (often tens of seconds before reclaim).
Capacity reserved on another host. The orchestrator tracks available dedicated vCPUs and memory so the VM always has a migration target.
Live migration of RAM and processes. The guest moves without restarting the application.
eBPF routes updated. Traffic and open TCP sessions follow the VM.
Source host released. The provider reclaims the source host while the customer’s workload keeps running on the new node.

When there isn’t enough time to migrate, the platform falls back to a cold restart from the replicated volume. To the application this looks like a rare emergency reboot, not the routine price of the Spot model.

6. Practical takeaways for engineers

Live migration removes Spot’s main operational downside: forced restarts every time a host is reclaimed.
Memory migration alone is useless without stable networking and disks that outlive the source server.
Treat the two failure modes separately: graceful eviction → live migration; hard failure → cold restart from a replica.
On microsrv that stack is already assembled: orchestrator + replicated storage + eBPF networking deliver about 25% savings versus standard cloud rates, with no rewrite of your app for graceful shutdown and checkpointing.

Sources and further reading

QEMU — Migration (pre-copy, post-copy, dirty-page tracking)
KVM — Live migration internals (kernel.org)
Clark et al. — “Live Migration of Virtual Machines” (NSDI ’05): the pre-copy baseline this post summarizes
microsrv companion posts: eBPF networking (why RAM alone is not enough) and replicated storage (disk continuity)

How we verified: a lab migration of an 8 GB KVM guest with migrate --live showed a stop-and-copy pause of tens of milliseconds; TCP sessions were held while eBPF maps repointed to the target host. On hard failure the fallback is a cold restart from a replicated volume, not a missed migration.