Stop your KVM guests from thrashing the host with shared write locks

Technical Briefing | 10/31/2026

You probably think your storage performance is a hardware problem. But I have seen countless setups where the host kernel spends more time juggling metadata locks than actually moving bits. When you have multiple guests hammering a single backend file on an EXT4 or XFS partition, the contention in the virtio block layer creates a silent performance ceiling that has nothing to do with disk IOPS.

Why shared images are a trap

If you are sharing raw disk images across multiple VMs or even just using lazy allocation, you are inviting trouble. The guest writes hit the host, triggering the filesystem to constantly expand the file and update the inode timestamps. When you stack this on top of a write-heavy application, the host becomes a bottleneck because it cannot reorder the IO requests effectively.

virsh domblklist <vm-name>
lsattr /var/lib/libvirt/images/<vm-disk>.qcow2
ionice -c 3 -p $(pgrep -f <vm-process-name>)

• Avoid using sparse qcow2 files on production databases unless you have IO priority mapping handled
• Use block devices or LVM partitions directly instead of relying on filesystem-level abstraction
• Ensure your host mount options include noatime to keep the kernel from metadata trashing every read operation

Seeing the lock contention in real time

If you suspect this is happening, watch the iowait on your host CPU stats while firing up a heavy write job inside the guest. If the host spikes in system time rather than IO wait, you are looking at lock contention. You might be tempted to mess with cache modes in libvirt, but remember that none of them are magic bullets for bad architectural choices. If you need speed, stop relying on the host’s filesystem to mediate your guest storage.

The next time you see weird latency spikes inside a VM, check the host mount options before you blame the SSD. Changing the filesystem cache mode or simply pinning your disk threads to a dedicated CPU core often reveals that the hardware wasn’t the problem at all.