[Qemu-discuss] Interruped snapshot deletion leads to corrupted image (qemu-img, qcow2, ERROR OFLAG_COPIED)

[Till Dörges]

Hi all,

I (quickly) wanted to delete a snapshot for one of my VMs. Image format is 
qcow2 with
a size of 200 GB. VM was turned off. Command issued was:

  qemu-img snapshot -d <id> <img>

The amount of data changed between the creation of the snapshot and the current 
state
was roughly 5-10 GB (update of operating system).


It was running for > 10 h when I decided to CTRL-C. Normally snapshot 
operations are
a lot quicker.


Apparently that was a bad mistake because now the image is corrupted.


Calling 'qemu-img check <img>' yields hundreds (or thousands) of

  ERROR OFLAG_COPIED: offset=214e0b4000 refcount=1

with different offsets, of course.


'qemu-img check -r all <img>' finished after a few minutes, but did not improve 
the
situation. Calling 'qemu-img check <img>' still yields tons of errors.


I then tried 'qemu convert <corrupted img> <new img>'. It completed without 
error
after 10-20 minutes.
Unfortunately the new image (raw format) contains loads of errors from the guest
perspective. Neither partition table nor file systems were present. I could 
recreate
both with the original parameters, but a subsequent fsck.ext3 again gave me so 
many
errors that I don't trust my data's integrity.


Booting a 1:1 copy of the corrupted image gives the same results as booting the 
image
created by 'qemu convert <corrupted img> <new img>'.


The original image was created with an old (couple of years, perhaps?) version 
of
qemu-img.
Currently I'm running version qemu-kvm/qemu-img 1.6.2 on openSUSE 13.1 (x86_64).


Now, before I go and restore the backups, is there any way to repair the image?


(And I guess it would be nice to have some sort of progress indicator for 
qemu-img,
leave alone some sort of transaction logic...)


Any hints are greatly appreciated.


TIA -- Till