Stop KVM guest storage from silently leaking your host disk performance

Technical Briefing | 7/23/2026

You probably set up your VM storage with a default qcow2 file and forgot about it. Everything runs fine until you start doing heavy database writes inside the guest. Then, the host load spikes, disk latency goes to hell, and you are left scratching your head because the guest isn’t even reporting high iowait. This bit me in prod back when I thought default settings were safe for production workloads.

Why default caching is killing your I/O

By default, libvirt often uses cache=none or writeback for your image files. If you’re on a filesystem that doesn’t play nice with these settings, you get constant synchronization hits that stall your virtio-blk driver. The guest kernel keeps pushing data, but the host is busy trying to guarantee every block hits the platter before acknowledging the write. It is a recipe for silent, agonizing latency.

virsh edit my-vm-name
# Find the <driver> element inside your <disk> section and change to:
<driver name='qemu' type='qcow2' cache='directsync' discard='unmap'/>

• directsync bypasses host page cache entirely so your RAM doesn’t get flooded with temporary buffers
• Adding discard=’unmap’ lets the guest tell the host when a block is deleted so your qcow2 file actually shrinks
• Check your host disk scheduler because keeping mq-deadline or kyber helps when the guest starts dumping heavy I/O

Most tutorials skip the discard setting, which is why your sparse image files keep growing forever even when you delete terabytes of data inside the VM. I’ve spent too many Sunday nights reclaiming space on nearly full LUNs because someone forgot to enable trim support. Next time you have a maintenance window, take five minutes to verify your cache and discard flags.