KVM live migration moves a running virtual machine from one host to another with only a pause of milliseconds. It is how providers patch hosts or replace hardware without rebooting customer VPSs. This guide uses virsh migrate from libvirt.
Before you start
- Two KVM hosts with the same or compatible libvirt/QEMU versions.
- Root SSH key login from source to destination.
- The same bridge name (for example
br0) and network reachability on both hosts. - Either shared storage (NFS, Ceph RBD, iSCSI) visible on both, or enough local disk on the destination.
Make CPUs compatible
The guest must not depend on CPU features the destination lacks. With identical hardware, host-passthrough is fine. With mixed hardware, use a named CPU model that both support (for example x86-64-v2 or a specific generation) in the VM's <cpu> element. Compare hosts with virsh capabilities and virsh cpu-baseline.
Live migration with shared storage
When the disk image lives on storage both hosts see at the same path, only memory and device state move:
virsh migrate --live --persistent --undefinesource --verbose web01 qemu+ssh://kvm2.example.com/system--persistentdefines the VM on the destination.--undefinesourceremoves it from the source after success.
Live migration with local storage
Without shared storage, copy the disk as well. Pre-create an empty disk of the same size and path on the destination, then:
virsh migrate --live --persistent --undefinesource --copy-storage-all --verbose web01 qemu+ssh://kvm2.example.com/systemThis takes longer because the whole disk crosses the network. A dedicated migration network helps.
Verify the migration
- On the destination:
virsh listshows the VM running. - A continuous ping to the VM shows at most a lost packet or two.
- Uptime inside the guest did not reset.
Troubleshooting
- "unsupported configuration: guest CPU doesn't match": use a common CPU model instead of passthrough.
- Migration never finishes: the VM dirties memory faster than the link copies it. Use
--auto-convergeor--postcopy, or a faster link. - Network lost after migration: the bridge name differs or the upstream switch has not learned the new port yet; ensure the same VLANs exist on both hosts.
- Permission errors on disk: check the path exists with the same ownership and SELinux/AppArmor labels.
Frequently asked questions
Is live migration the same as a backup?
No. It moves a single running copy; it does not create a restore point.
Can panels do this for me?
Yes. Proxmox VE, VirtFusion and Virtualizor offer migration features built on the same KVM mechanism.
What about offline migration?
Shut down the VM, copy its disk and XML (virsh dumpxml), then define and start it on the new host. Simpler, but with downtime.