You spend days tuning your guest filesystem, only to watch the host disk latency spike the moment your database starts a heavy write operation. It is not always the hardware. Most of the time, it is the KVM cache mode fighting the guest kernel’s expectations about who actually owns the disk flush cycle.

Why default settings are a trap

Libvirt defaults usually rely on the host’s page cache. This sounds great until the guest starts issuing barriers. When the guest thinks it has committed data, the host is often still buffering it. If you lose power or the host kernel decides to put the pressure on that page cache, everything goes sideways. I have seen this cause total guest hangs during minor I/O load because the host kernel was blocked on sync requests.

virsh edit my-guest-vm
# Look for <driver name='qemu' type='qcow2' cache='none'/>

• Use cache=none to bypass the host page cache entirely for direct I/O
• Avoid writeback if you value your data integrity during sudden host power loss
• Set io=native to allow the kernel to handle AIO efficiently without blocking the thread

Changing these parameters requires a full shutdown of the domain, and yes, that is annoying if you have high availability requirements. But doing it now saves you from the diagnostic hell of investigating why your database logs are corrupt after a standard host kernel update. If you are running on NVMe drives, native AIO is mandatory. Do not bother with default settings if your IOPS numbers are nowhere near the hardware spec.

Check your block device latency with iostat while under load. If you see high await times but low utilization on the host hardware, you are likely looking at a locking contention issue rather than a drive speed limit. Fix the cache mode, restart the guest, and watch those spikes flatten out.