© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
I have the same (related?) issue and wanted to add my experience with it. I had 3 qemu qcow2 VM running on ArchLinux. I never used snapshots or something like it. Just normal start&shutdown. 2 of these VMs were also ArchLinux running on ext4. Both of these VMs had a data corruption inside the quest. The data being corrupted were files I had not touched in month (large tar archives). One guest was running on a SSD with discard, the other VM was running on a normal hard drive without any discard.
The last VM was a Windows 10 VM. While the VM was running fine, after "fixing" the image issues with qemu-img -r all hdd.qcow2 the Windows 10 installation was unbootable and beyond repair with normal Windows tools.
While the VMs are running I saw these lines printed by qemu (for all VMs in question):
qcow2_free_clusters failed: Invalid argument
qcow2_free_clusters failed: Invalid argument
qcow2_free_clusters failed: Invalid argument
I recreated my VMs and I now chose btrfs as a filesystem. No issues yet on the image. I also recreated the Windows 10 VM. It worked fine a couple of days. Today I checked the image, after I saw the free_clusters lines above again:
Many many lines like this:
Leaked cluster 260703 refcount=1 reference=0
ERROR cluster 260739 refcount=0 reference=1
ERROR OFLAG_COPIED data cluster: l2_entry=
638 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
339 leaked clusters were found on the image.
This means waste of disk space, but no harm to data.
314734/4096000 = 7.68% allocated, 26.70% fragmented, 0.00% compressed clusters
Image end offset: 21138374656
The installation itself still works but I don't know if there are any silently corrupted files in there.
QEMU 4.1.0 from ArchLinux
Host-Filesystem is ext4
Start-Parameter (the same on all VMs):
qemu-system-x86_64 -cpu Haswell-noTSX -M q35 -enable-kvm -smp 4,cores=