Update January 27, 2023: The issue described below is limited to users of RAW partitions. But there is a workaround. See under “What to do?”
A recent update from QEMU 7.1 to QEMU 7.2 caused my Windows 10 VM to show 100% utilization of the C: drive. Performance of the Windows VM dropped to the bottom – the VM was pretty much unusable.
Users at the VFIO Reddit reported similar issues. However, as it turned out, it seems to affect only storage on LVM raw volumes. In other words, if you have your VM in a qcow file, all should be well.
What to do?
Make a backup of the Linux host (Timeshift for example) before you make any changes or update, just to be safe.
If you use file-based storage, you should be OK and won’t need to make any changes!
Update: There is workaround to this bug, as described under the following Reddit thread: “Anyone else facing 100% disk activity with Win11 VMs on qemu 7.2.0-1?” The solution is to remove the detect_zeroes="unmap" option in the drive configuration. Below is my previous configuration:
<disk type="block" device="disk"><driver name="qemu" type="raw" cache="none" io="native" discard="unmap" detect_zeroes="unmap"/><source dev="/dev/vmvg/win10"/><target dev="vda" bus="virtio"/><address type="pci" domain="0x0000" bus="0x03" slot="0x00" function="0x0"/></disk>
When using the virt-manager GUI, open the configuration screen, select the hard drive in question and click on the XML tab to reveal the XML code. Then delete the detect_zeroes="unmap" option. That’s it. Thanks to sunesis311 on Reddit.
See also the following bug report: https://gitlab.com/qemu-project/qemu/-/issues/1404
LVM-based storage
I partition my disks as LVM (Logical Volume Manager) partitions and create volume groups and logical volumes as I need. During the Windows installation, it sees the assigned LVM volume as an unformatted partition and formats it to NTFS. This has worked well ever since I used QEMU, I think it was version 2 or so.
LVM-based storage for virtual machines has, in my opinion, many advantages. It gives me simultaneous access from both Windows and Linux (the latter only in read mode, else all hell can break loose). It allows snapshots while the VM is running. But my main reason is easy backup, restore, and migration of the VM. I don’t have to care about the underlying physical media. If my NVMe drive reaches its capacity, I can add another and expand the Logical Volume underlying the Windows NTFS “partition”.
Other storage options
Aside from file-based storage, there are many more options to choose from today. One quite popular and probably the most performant option is passing through the disk controller. For NVMe drives that can be relatively straightforward, a long as they reside in their own IOMMU group.
Conclusion
Don’t haste updating to the latest and “greatest”. Use Timeshift on your Linux host to create restore points. It literally saved me this time around.