Bug 540893 - qemu-img: snapshot info error
Summary: qemu-img: snapshot info error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.4.z
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 538068
TreeView+ depends on / blocked
 
Reported: 2009-11-24 13:23 UTC by Igor Lvovsky
Modified: 2013-03-01 04:51 UTC (History)
6 users (show)

Fixed In Version: kvm-83-137.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-03-30 07:56:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0271 0 normal SHIPPED_LIVE Important: kvm security, bug fix and enhancement update 2010-03-29 13:19:48 UTC

Description Igor Lvovsky 2009-11-24 13:23:14 UTC
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:

Comment 1 Kevin Wolf 2009-11-24 15:06:13 UTC
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.

Comment 2 Uri Lublin 2009-11-25 09:06:05 UTC
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) ?

Comment 3 Kevin Wolf 2009-11-25 09:22:45 UTC
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).

Comment 8 Golita Yue 2009-12-28 09:58:42 UTC
--> 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)

Comment 9 Golita Yue 2010-01-05 10:30:11 UTC
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)

Comment 12 errata-xmlrpc 2010-03-30 07:56:40 UTC
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


Note You need to log in before you can comment on or make changes to this bug.