Description of problem: After creation preallocate volume on block device with 'host_device' format and after creation snapshot of this volume with 'host_device' as backing-file format, 'qemu-img info' of this snapshot failed. Version-Release number of selected component (if applicable): How reproducible: > qemu-img create -f host_device /dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234 100M Formatting '/dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234', fmt=host_device, size=102400 kB > qemu-img create -f qcow2 -F host_device -b /dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234 /dev/16430fb2-c720-4581-9632-77f9aa804e5/2345 Formatting '/dev/16430fb2-c720-4581-9632-a77f9aa804e5/2345', fmt=qcow2, backing_file=/dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234, backing_fmt=host_device, size=1048576 kB > qemu-img info -f qcow2 /dev/16430fb2-c720-4581-9632-a77f9aa804e5/2345 ERROR: ext_backing_format: len=16 too large (>=16) ERROR: ext_backing_format: len=16 too large (>=16) qemu-img: Could not open '/dev/16430fb2-c720-4581-9632-a77f9aa804e5/2345' Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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