qemu-img create -f qcow2 -b win7_base.qcow2 -F qcow2 win7_clone1.qcow2 qemu-img create -f qcow2 -b win7_base.qcow2 -F qcow2 win7_clone2.qcow2 Each clone is <1MB initially and writes only changes to its own file. Performance is "top" because reads come from the base qcow2 cache. | Symptom | Likely Cause | Fix | | --- | --- | --- | | VM freezes under disk load | Missing VirtIO drivers | Reinstall virtio-win, switch to virtio-blk. | | qcow2 file grows forever | Windows 7 deleted files but no TRIM | Enable "Unmap" in virtio-scsi and run Optimize-Volume -DriveLetter C -ReTrim -Verbose in PowerShell. | | High host CPU (~50% idle guest) | qcow2 encryption + old host CPU | Disable encryption, use LUKS on host instead. | | Snapshot revert takes minutes | Deep snapshot chain | Commit snapshots, then create fresh qcow2 via qemu-img convert . | | Windows 7 shows "Disk is busy 100%" | Antivirus real-time scan | Exclude .qcow2 files and VM process from host AV; inside guest, exclude C:\Windows\CSC. | Part 8: Final Verdict – Is Windows 7 on qcow2 "Top" Ready? Yes — when configured correctly. The combination of cache='writeback' , multi-queue virtio-blk, hugepages, and properly aligned NTFS partitions yields performance within 5-10% of raw disk. For legacy applications that cannot migrate to Windows 10/11, a qcow2-based Windows 7 VM on modern NVMe storage often feels faster than native hardware from 2015 .
qemu-img rebase -u -b '' win7.qcow2 qemu-img commit win7.qcow2 Windows 7 never TRIMs its disk by default. After years of use, your qcow2 file may be huge but internally empty. Fix it: windows 7 qcow2 top
sdelete -z C: (after shutting down VM):