We have all been there. A guest VM running a heavy database starts thrashing the disk, and suddenly the entire host starts acting like it is wading through molasses. You try to log in via SSH to check the load, but your keystrokes take three seconds to echo back. It is not always the kernel process killing you; it is often the QEMU process waiting on I/O completion while holding up the virtual hardware interface.

Why the default writeback cache is a trap

By default, libvirt often hands out writeback caching for your virtual disks. It is fast, sure, but it is dangerous because the guest assumes the data hit the platter when it actually hit the host memory. When the host hits memory pressure or the underlying block device saturation point, the guest I/O queues fill up, the thread gets blocked in the kernel, and the entire VM monitor thread halts. If you do not change your cache mode to none, you are essentially asking for silent corruption and host-wide latency spikes during heavy write bursts.

virsh edit vm-name

• Change driver cache from writeback to none inside the disk xml block
• Enable io threads in the libvirt domain xml to offload block processing
• Switch your virtio-blk driver to virtio-scsi for better handling of multi-queue I/O

Once you make these changes, you will need to perform a full shutdown and start of the domain for the new threading model to take effect. It is an annoying downtime, but it is better than having to hard-reset the physical server because the I/O waiter lock-up is unrecoverable. Next time you build a VM, do not settle for the defaults unless you actually want to debug kernel threads at 3 AM.