I have spent too many mornings performing forensic surgery on qcow2 images after a sudden power loss hit a lab rack. The default libvirt configuration treats caching like it is just a performance knob, but when the host cuts out, the guest filesystem often winds up in a state that fsck cannot fix. Most people leave this at default and assume the kernel handles the safety, but that is a dangerous gamble.

Why default caching is a liar

When you use the default writeback mode, the host kernel tells the guest that a write is committed as soon as it hits the page cache. It is fast, sure. But if the physical server loses juice, those pages are gone, and the guest disk metadata is likely shredded. You really want to force the guest to wait for the disk backend to acknowledge the write.

virsh edit my-virtual-machine

• Change the driver cache setting from default or writeback to writethrough or directsync
• Set the IO mode to native to bypass standard host caching when possible
• Verify your disk controller supports barrier commands so the guest OS knows about the hardware reality

The trade-off you actually have to make

Setting this to writethrough will absolutely tank your disk I/O performance. You will feel the latency hit immediately. But that is the price you pay for sanity. If you have an enterprise SSD with a power-loss protection capacitor, directsync might give you some speed back while keeping the safety guarantees you need. Check your hardware specs before you decide which route to take.

Next time you spin up a persistent production database, flip these settings before you copy any data. It is much easier to tune your application to handle slower disk commits than it is to explain to a client why their database index is missing half its nodes.