Understanding Qcow2 image , its header and verifying corruption..

qcow2 is one of the best image formats available for virtual machines running on top of KVM .. Its known as qemu image format version 2. Use it to have smaller images (useful if your filesystem does not supports holes, for example on Windows), optional AES encryption, zlib based compression and support of multiple VM snapshots.

Supported options:

Qcow2 header is composed by below byte allocation..

Byte 0 – 3: magic
QCOW magic string (“QFI\xfb”)

4 – 7: version
Version number (valid values are 2 and 3)

8 – 15: backing_file_offset
Offset into the image file at which the backing file name
is stored (NB: The string is not null terminated). 0 if the
image doesn’t have a backing file.

16 – 19: backing_file_size
Length of the backing file name in bytes. Must not be
longer than 1023 bytes. Undefined if the image doesn’t have
a backing file.

20 – 23: cluster_bits
Number of bits that are used for addressing an offset
within a cluster (1 << cluster_bits is the cluster size). Must not be less than 9 (i.e. 512 byte clusters). Note: qemu as of today has an implementation limit of 2 MB as the maximum cluster size and won't be able to open images with larger cluster sizes. 24 - 31: size Virtual disk size in bytes 32 - 35: crypt_method 0 for no encryption 1 for AES encryption 36 - 39: l1_size Number of entries in the active L1 table 40 - 47: l1_table_offset Offset into the image file at which the active L1 table starts. Must be aligned to a cluster boundary. 48 - 55: refcount_table_offset Offset into the image file at which the refcount table starts. Must be aligned to a cluster boundary. 56 - 59: refcount_table_clusters Number of clusters that the refcount table occupies 60 - 63: nb_snapshots Number of snapshots contained in the image 64 - 71: snapshots_offset Offset into the image file at which the snapshot table starts. Must be aligned to a cluster boundary. Now lets verify a qcow image header by following above byte allocation. I have an image whose first 1 MB look like :

Lets start verifying the image integrity ( well atleast its header) by manually unwinding above data in hexadecimal notation... The first 4 bytes represents its magic string.. so starting from offset 0x00000000 we can see its “51 46 49 fb” which is equivalanto to “QFI” . luckily atleast these bytes are not corrupted..

lets see next 4 bytes.. 00 00 00 02 , Isnt it saying its version is “2” ?? yes..

Now, lets see what is the size of this image : Bytes from 24-31 tells us the size of the image..

3e 80 00 00 00 00 00 00 which is equivalent to
00111110100000000000000000000000 in binary or 1048576000 in decimal.. 1048576000 == 1 GB ? yes, it is..

Lets see whether this image has any snapshots ? 60-63 says it all..
00 00 00 00 -> so, NO SNAPSHOTS!

If you extract above hexadecimal values you would end up in :

Hmmmm.. looks like there is no corruption reported at least in this header.. well, is there any binary available for checking integrity of the image itself ? Yes, ‘qemu-img’ check can be used for the same purpose..

lot many operations can be performed against qcow2 image using this binary..

To get some information about this image we can try:

Also its possible to check the integrity of the image by :

Hope this helps!!

Leave a Reply

Your email address will not be published. Required fields are marked *