So, something bad happened! My Virtual Machine running on my NAS crashed.
And it looked like this…
2020-05-08T19:51:09.582896Z qemu-system-x86_64: -drive file=/share/Storage/VM/Windows 10 Enterprise/Windows 10 Enterprise.img,format=qcow2,if=none,id=drive-virtio-disk0,cache=writeback: qcow2: Image is corrupt; cannot be opened read/write
So I did what I normally do, I started googling, and found a bunch of old articles saying that I had to install some “nbd” module in the kernel and then run “ddrescue”, most of the articles I found pointed to one very sad solution, scrap your VM and reinstall, because you’re never getting your data back.
Anyway, all of that seemed pretty old (and sad), and I thought there must be a better way. And guess what, there was!
First I ran a command called “qemu-img” with the command “check”, and It looked like this:
./qemu-img check /share/Storage/VM/Windows\ 10\ Enterprise/Windows\ 10\ Enterprise.img
When that was done it gave this:
<WALL OF TEXT> (list of all errors in the Image), and then a Summary:
2047 errors were found on the image.
Data may be corrupted, or further writes to the image may corrupt it.
17593 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 802489/4096000 = 19.59% allocated, 4.83% fragmented, 0.00% compressed clusters Image end offset: 53754200064
I liked the part about “no harm to data”. So I ran the second command that I had found, which was:
./qemu-img check -r all /share/Storage/VM/Windows\ 10\ Enterprise/Windows\ 10\ Enterprise.img
And after that command finished:
The following inconsistencies were found and repaired:
17593 leaked clusters 1024 corruptions
Double checking the fixed image now… No errors were found on the image. 802489/4096000 = 19.59% allocated, 4.83% fragmented, 0.00% compressed clusters Image end offset: 53754331136
And that solved it!
Lesson learned: Scheduled Backup of your VM = good thing.
