How Does KVM Online VM Migration Work? A Step‑by‑Step Guide

Introduction

With the rapid development of cloud computing, enterprises can reduce IT investment, lower operation costs, accelerate business delivery, dynamically adjust scale, and ensure reliability. These benefits rely on virtualization that creates multiple virtual resources from physical servers, enabling efficient, elastic, and maintainable infrastructure.

Online VM migration is a key component of this infrastructure, simplifying maintenance, achieving load balancing, optimizing energy consumption, and enhancing reliability.

Principle

Online migration moves a running virtual machine between physical hosts without downtime. The target host creates an identical VM, data is transferred, and a brief final switch occurs, keeping the VM operational for most of the process. The migration involves three phases: preparation, migration, and switch.

UCloud, a leading public‑cloud provider, uses KVM virtualization with Libvirt and Open vSwitch. The following description focuses on non‑shared storage migration.

Preparation Phase

Step.1 Choose a destination host (DestHost) with sufficient disk and memory, create empty system and data disks matching the source paths, and open a TCP port for data transfer.

Step.2 Use Libvirt on DestHost to create a new VM (VM') with the same configuration, attaching the previously created disks. VM' starts in a paused state and listens on an internal TCP port for migration data.

Migration Phase

Step.3 Libvirt issues a migration command to the Qemu process of the source VM, specifying destination host, block devices, maximum downtime, and bandwidth limits. Data is sent directly over the physical NICs, bypassing the virtual switch.

Step.4 Libvirt first triggers Qemu to mirror disk data, then initiates memory migration, and finally synchronizes device state. The migration proceeds in three sub‑steps: preparation, bulk transfer, and finalization. Disk and memory data are transferred block‑by‑block; after the bulk transfer, incremental dirty pages are iteratively sent until the remaining dirty data fits within the allowed downtime.

After the incremental phase, the source Qemu pauses, synchronizes remaining dirty data and device state, and the management layer switches the VM to the destination.

Switch Phase

Step.5 After data transfer, the source VM is shut down and the destination VM (VM') runs as a full copy. Network connectivity is restored by connecting VM' to the destination host's virtual switch, and an ARP broadcast updates the MAC address mapping, making the switch virtually seamless.

Conclusion

The described steps enable cross‑host VM migration on a KVM platform, supporting load balancing and maintenance while keeping the migration transparent to users. However, challenges remain, such as migration failures under high disk/memory load, longer network interruption times, handling heterogeneous storage types, and using migration for VM component upgrades.