Bug 540893

Uri, is there any specific reason why the backing format length has to be
rounded up to the next multiple of 8 before it's written to the header?
"host_device" would easily fit into a 16 byte char array, but with this
rounding it obviously doesn't work any more.

The idea is that all qcow2-extensions are 8-aligned (similar to header_size).
I'm not sure qcow2-extensions need to be aligned but if it's important for header_size it might be important for qcow2-extensions too.

Although we only got to implement a single extension (backing format) we had plans to implement more (e.g. zero-page offset).

As for the backing_format length rounding. The rounded length represents what is written on disk (and not the length of backing_format c-string).

I think you are right. We can keep the actual backing_format length on disk (in qcow_create2 make  ext_bf.len = backing_format_len), as qcow_read_extensions() already skips the 8-aligned extension length.

The alignment would go in the calculation of d (difference between backing_format length and rounded-up extension length) since we want to write a 8-aligned number of bytes.

That should solve this bug.
However, what would happen when the backing-format length is 16 (or more) ? It would fail the same way. Should we limit backing-format length to 15 on qcow2 image creation (when backing-format is provided) ?

Sure, aligning the the extension itself makes some sense. I was just wondering why we are aligning the format twice, there might have been some non-obvious reason for it.

I'm going to store the actual string length in ext_bf.len then. Thanks, Uri.

Concerning the maximum string length, I think we only want to save valid format names. Currently the longest one is "host_device" with its 11 characters, so we're fine with 16 (there is "vvfat_write_target", but it's only used internally in vvfat and you can't access it).

--> Igor: I tested this bug with the following steps on kvm-83-140.el5. Please correct me if the step has mistake. 

1. create logical volume
   # pvcreate mpath1
   # vgcreate vg1 mpath1
   # lvcreate -n lv1 -L 10G vg1
     Logical volume "lv1" created
2. 
   # ls /dev/mapper/
    control  mpath1  vg1-lv1
   # qemu-img create -f host_device /dev/mapper/vg1-lv1 100M
Formatting '/dev/mapper/vg1-lv1', fmt=host_device size=104857600
   # qemu-img create -f qcow2 -F host_device -b /dev/mapper/vg1-lv1 /dev/mapper/snapshot1
     Formatting '/dev/mapper/snapshot1', fmt=qcow2 size=10737418240 backing_file='/dev/mapper/vg1-lv1' backing_fmt='host_device' encryption=off cluster_size=0 
   # qemu-img info -f qcow2 /dev/mapper/snapshot1
   image: /dev/mapper/snapshot1
   file format: qcow2
   virtual size: 10G (10737418240 bytes)
   disk size: 144K
   cluster_size: 65536
   backing file: /dev/mapper/vg1-lv1 (actual path: /dev/mapper/vg1-lv1)

Update my testing steps. The last step was passed. So the bug could not be reproduced on kvm-83-140.el5

[root@localhost mapper]# lvcreate -n lv1 -L 1G vg1
  Logical volume "lv1" created
[root@localhost mapper]# lvcreate -n lv2 -L 1G vg1
  Logical volume "lv2" created
[root@localhost mapper]# lvs
  LV   VG   Attr   LSize Origin Snap%  Move Log Copy%  Convert
  lv1  vg1  -wi-a- 1.00G                                     
  lv2  vg1  -wi-a- 1.00G
[root@localhost mapper]# ls /dev/mapper/
control  mpath1  vg1-lv1  vg1-lv2
[root@localhost mapper]# qemu-img create -f host_device 
/dev/mapper/vg1-lv1 1G
Formatting '/dev/mapper/vg1-lv1', fmt=host_device size=1073741824
[root@localhost mapper]# qemu-img create -f qcow2 -F host_device -b 
/dev/mapper/vg1-lv1 /dev/mapper/vg1-lv2
Formatting '/dev/mapper/vg1-lv2', fmt=qcow2 size=1073741824 
backing_file='/dev/mapper/vg1-lv1' backing_fmt='host_device' 
encryption=off cluster_size=0
[root@localhost mapper]#
[root@localhost mapper]# qemu-img info -f qcow2 /dev/mapper/vg1-lv2
image: /dev/mapper/vg1-lv2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 0
cluster_size: 65536
backing file: /dev/mapper/vg1-lv1 (actual path: /dev/mapper/vg1-lv1)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0271.html