Do I need to verify file integrity after running qemu-img convert?

Question

I'm running some v2v conversions to convert disk images from .vmdk to .img using the qemu-img convert utility. The .vmdk file is stored in the RAW format and the output .img file is also going to be in the RAW format.

I've been running checksums before and after conversions to make sure they match after the conversion has run. Is this file integrity check actually necessary? Does qemu-img convert have some built-in file consistency checks to make sure there are no problems with the conversions. As of now, the checksums take the most amount of time in my whole conversion process so eliminating this step would be a huge time-saving advantage. Also since I'm just converting from RAW to RAW is this conversion even needed or can I just copy/rename the file using rsync?

Thank you!

Checking file format:

$ qemu-img info <filename>-flat.vmdk
image: <filename>-flat.vmdk
file format: raw
virtual size: 150 GiB (161061273600 bytes)
disk size: 151 GiB

Running the conversion:

$ qemu-img convert -f vmdk -O raw <filename>.vmdk disk.img

Ensuring integrity:

$ crc32 <filename>-flat.vmdk
$ crc32 disk.img

Answer 1

If the checksum is truly equal then no conversion has happened. It's only a rename or file copy at that point.

If any conversion happens, the data will change and the checksum won't match anymore.

Answer 2

As a general rule, you should not need to run integrity checks for a conversion like this at all unless you suspect hardware issues or a bug in QEMU itself, and if either of those were the case you shouldn’t be doing such large scale data manipulation under those circumstances to begin with.

Also, this only happens to work because a raw VMDK image is just a different name for what most people call a ‘raw disk image’ (that is, there is no header, no special formatting, just the raw data that’s stored on the guest’s disk). That means that this ‘conversion’ is at worst just a copy of the whole file (and at best is a reflink or rename operation), so the checksums are identical. If, instead, you were converting from a VDI image, or to a QCOW2 image, you would be seeing different checksums for the two files, since both those formats have associated metadata embedded in the file itself that is different between formats.

It actually is possible to integrity check the stored data irrespective of format, but you can’t do it by just checksumming the files. You need to expose both of the files as actual ‘disks’ in some way (either by booting a recovery environment in a VM with both disks attached, or by serving both with qemu-nbd and connecting them to the host system) and then checksum the exposed disks, not the files themselves. However, as mentioned at the top of the answer there’s not much point (and especially not on the system you did the conversion on) unless you suspect some major issue.