Live Migration Requirements (KVM / libvirt / oVirt)

Introduction¶

Live migration copies a running VM's memory from one host to another and switches execution over with a sub-second pause. It's how you patch a hypervisor without downtime. It works only when the two hosts are compatible in specific ways.

The requirements¶

Shared or replicated storage¶

The VM's disk must be reachable from both hosts at the same path:

• Shared: NFS, iSCSI/FC LUN, CephRBD, GlusterFS, a clustered filesystem.
• Or storage migration (--copy-storage-all / oVirt "move disk" as part of migration) copies the disk too — much slower, more fragile.

Local-disk-only VMs can't live-migrate without copying storage.

CPU compatibility¶

The destination CPU must support every feature the guest currently sees. Options:

• Named CPU model (Haswell-noTSX, EPYC-Rome) — pick one supported by all hosts in the cluster. oVirt sets the cluster CPU type to the lowest common denominator for exactly this reason.
• host-model — libvirt picks a close named model at start; migratable within similar CPUs.
• host-passthrough — exposes the exact physical CPU. Only migratable to an identical CPU. Fastest, least flexible.

Mixed Intel/AMD clusters can't live-migrate between vendors.

Machine type¶

The QEMU machine type (pc-q35-8.2, pc-i440fx-6.2) must be available on the destination. A newer host has newer machine types; migrating a VM pinned to pc-q35-8.2 to a host whose QEMU only goes to 8.0 fails. Keep QEMU versions close, or pin machine types to a version all hosts support.

QEMU / libvirt versions¶

Migrate to the same or newer QEMU/libvirt, not older. Big version gaps can fail even forward.

Networking¶

• The destination host needs the same bridges / libvirt networks / OVS configuration with the same names.
• A dedicated migration network (separate from management and VM traffic) is strongly recommended — memory copy can saturate a link.
• The guest keeps its MAC/IP; the destination sends a gratuitous ARP so the switches relearn the port. Brief packet loss during the switchover.

Other¶

• Same or compatible NUMA / hugepages setup if the VM uses them.
• No un-migratable devices: PCI passthrough / SR-IOV VFs, USB passthrough, mediated devices (unless the driver supports migration), local-only host devices. Detach or use failover (virtio-net + VF bond) for SR-IOV.
• <cpu><feature> for entropy/rng etc. present on both.

Pre-copy vs post-copy¶

• Pre-copy (default): copy all memory, then re-copy pages that changed during the copy ("dirty pages"), iterate until the remaining set is small enough to pause and transfer. A VM dirtying memory faster than the link can copy never converges — the migration runs forever or aborts.
• Fixes: faster/dedicated migration link, auto-converge (throttle the guest CPU to slow dirtying), or compression.
• Post-copy: switch execution to the destination almost immediately, then pull pages on demand as the guest faults on them. Converges regardless of dirty rate, but if the network drops mid-migration the VM is lost (its memory is split across two hosts). Often used as: start pre-copy, switch to post-copy if it doesn't converge in N seconds.

virsh migrate --live --auto-converge --persistent --undefinesource \
  myvm qemu+ssh://desthost/system

# with a dedicated migration network:
virsh migrate --live myvm qemu+ssh://desthost/system \
  --migrateuri tcp://10.20.0.5

Verification and troubleshooting¶

virsh domjobinfo myvm          # during migration: data/mem progress, dirty rate
virsh capabilities | grep -A5 '<cpu>'    # host CPU features
virsh domcapabilities | grep machine

• "Unable to find security driver" / "Cannot access storage file" — the disk path isn't valid on the destination (not shared, different mount point, permissions/SELinux).
• "unsupported configuration: guest CPU ... does not match" — destination CPU lacks a feature. Use a lower named model cluster-wide, or don't use host-passthrough.
• "unknown machine type pc-q35-8.2" — destination QEMU too old. Align versions or pin an older machine type.
• Migration never completes, dirty rate stays high — busy VM + slow link. Dedicated migration NIC, --auto-converge, or post-copy.
• VM pauses and doesn't resume on destination — post-copy network failure, or an error on the destination. Check libvirtd logs both sides; virsh domstate / virsh resume.
• Passthrough device VM won't migrate at all — expected. Hot-unplug the VF (with a virtio-net failover bond the guest keeps connectivity), migrate, re-plug.
• oVirt: "no available host to migrate to" — cluster policy, affinity/ anti-affinity rules, insufficient memory on other hosts, or the CPU/network mismatch surfacing as "not eligible".

Related tools and reading¶

• On-site: Subnet Calculator.
• Related posts: virtio drivers explained, libvirt networking: NAT vs bridged.