Stop libvirt from burning your CPU cycles on ghost migration traffic

Technical Briefing | 9/26/2026

Most of us treat live migration as a magic box. You fire off virsh migrate and hope the VM lands on the target host before the timeout kills it. That works great until your management network gets saturated, the VM state transfer stalls, and you end up with a guest stuck in a suspended state while your storage backend screams for mercy. It bit me hard once when I assumed the default migration speed was capped, but turns out it was wide open and eating the entire 10GbE pipe.

Why the defaults are actually dangerous

By default, libvirt doesn’t impose a bandwidth limit on migration. If you don’t explicitly set a cap, QEMU will try to move memory pages as fast as the source host can read them from RAM and pump them over the wire. On a congested network, this kills your cluster’s heartbeat and can even cause host-to-host storage disconnects. You want to throttle this, especially if you share the management network with disk I/O traffic.

virsh migrate --live --bandwidth 500 --migrate-disks vda --xml /tmp/guest.xml --persistent vm-name qemu+ssh://target-host/system

• Bandwidth is measured in Mbps so 500 gives you a stable 62.5 megabytes per second transfer
• The –migrate-disks flag ensures you arent just moving RAM while leaving the storage attached to the wrong place
• Adding the –persistent flag saves you from having to define the VM on the new host manually after the move

If you are running older versions of libvirt, keep an eye on the migration-timeout setting in your libvirtd.conf. It defaults to zero, which means the process will wait forever. A hung network transfer can leave your host memory locked up indefinitely until you get tired of waiting and manually kill the QEMU process. Keep that threshold low enough to fail fast so your orchestration tooling knows something went sideways and can retry on a cleaner node.