Stop letting QEMU guests hog your I/O and kill host latency

Technical Briefing | 10/20/2026

You spend all weekend tuning your host’s disk scheduler and network stack, only to watch a single runaway guest VM trash your host’s IOPS because you didn’t define a throughput ceiling. It is a classic move that has bitten me in prod more times than I care to admit. When you leave the default disk bandwidth settings for a guest, you are basically handing them a blank check on your underlying storage hardware.

Why defaults are dangerous for storage

By default, libvirt lets your VMs scream at the host storage controller as hard as they want. If one guest starts a massive reindex operation on a Postgres database, every other VM on that host is going to feel the latency hit. You don’t need fancy storage appliances to fix this; you just need to clamp the I/O at the cgroup level before it ripples out to your host block devices.

virsh blkiotune vm-name --write-bytes-sec 50000000 --read-bytes-sec 50000000

• Use –write-iops-sec and –read-iops-sec to cap the actual request volume, not just the throughput.
• Verify your kernel supports blkio cgroup controllers before you go tweaking these knobs.
• Always apply these limits to the total device bandwidth, not just specific partitions.

The reality of performance caps

Most tutorials tell you to over-provision and hope for the best, but that is how you end up with erratic p99 latency spikes during backup windows. Setting hard caps keeps the noisy neighbor problem from becoming a full-blown outage. If you need to debug which guest is actually hammering the bus, check the blkio statistics directly on the host rather than trusting the guest’s internal metrics.

Keep these limits in your libvirt XML templates from day one. You will thank yourself the next time a junior dev accidentally runs a massive bulk insert on the wrong environment.