Bug 1451269 - Clarify the relativity of backing file and created image in "qemu-img create"
Summary: Clarify the relativity of backing file and created image in "qemu-img create"
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Fam Zheng
QA Contact: Ping Li
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1473046
TreeView+ depends on / blocked
 
Reported: 2017-05-16 09:19 UTC by yilzhang
Modified: 2018-05-18 07:24 UTC (History)
13 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-04-11 00:19:31 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:1104 None None None 2018-04-11 00:21 UTC

Description yilzhang 2017-05-16 09:19:31 UTC
Description of problem:
Use one local bootable disk image as backing_file, and then create one snapshot with iSCSI backend will fail.

Version-Release number of selected component (if applicable):
Host:
kernel: 3.10.0-663.el7.ppc64le
qemu-kvm-rhev-2.9.0-3.el7.ppc64le
SLOF-20170303-3.git66d250e.el7.noarch
Guest:
3.10.0-663.el7.ppc64le

How reproducible:
100%

Steps to Reproduce:
1. Create one disk image on local filesystem
   # qemu-img create -f qcow2  rhel.qcow2  20G
2. Install guest
 -drive file=rhel.qcow2,if=none,id=drive-data-disk1,format=qcow2,cache=none,aio=native,serial=sluo-disk1 \
 -device scsi-hd,drive=drive-data-disk1,bus=virtio.0,bootindex=0 \
3. Boot up the guest and it works well, then shutdown it
4. Use the above disk image as backing_file,  create one snapshot with iSCSI backend
  # qemu-img create -f qcow2  -F qcow2  -b rhel.qcow2  iscsi://10.16.67.19:3260/iqn.2015-05.com.example:t1/0


Actual results:
Step4 fails, that is, creating snapshot with iSCSI backend fails.

# qemu-img info rhel.qcow2
image: rhel.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 1.7G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
# qemu-img check rhel.qcow2
No errors were found on the image.
27104/327680 = 8.27% allocated, 16.77% fragmented, 0.00% compressed clusters
Image end offset: 1777205248
# qemu-img create -f qcow2  -F qcow2  -b rhel.qcow2 iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/0
qemu-img: iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/0: Failed to parse URL : iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/rhel.qcow2

Expected results:
Creating snapshot with iSCSI backend succeeds.


Additional info:
But if we use one iSCSI disk image as backing_file, then create one snapshot on local filesystem will succeed.
The following case succeeds:
[... Shutdown Guest ...]
Host# qemu-img create -f qcow2  -F qcow2   -b  iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/0   local-sp
Formatting 'local-sp', fmt=qcow2 size=21474836480 backing_file=iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/0 backing_fmt=qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

Host# qemu-img info local-sp
image: local-sp
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: iscsi://10.16.67.19:3260/iqn.2017-05.com.example:t1/0
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Comment 2 yilzhang 2017-05-16 09:27:02 UTC
Both x86 and ppc64le have this problem.

Comment 4 juzhang 2017-06-08 10:50:44 UTC
Hi Developer,

We had better update the flag from rhel-7.4.0 to rhel-7.5.0 if we do not plan to fix it.

Comment 6 yilzhang 2017-08-01 07:35:04 UTC
I find that  this bug is related with the path name of backing_file:

If using absolute path for backing_file, creating snapshot with iSCSI backend will succeed; otherwise, if using relative path, creating snapshot with iSCSI backend will fail.



[host]#  qemu-img create -f qcow2  -F qcow2 -b  ../dataimage/rhel.qcow2    iscsi://129.40.28.33:3260/iqn.2017-04.com.example:t1/3
qemu-img: iscsi://129.40.28.33:3260/iqn.2017-04.com.example:t1/3: Failed to parse URL : iscsi://129.40.28.33:3260/iqn.2017-04.com.example:t1/../dataimage/rhel.qcow2

[host]# qemu-img create -f qcow2  -F qcow2 -b  /home/yilzhang/dataimage/rhel.qcow2    iscsi://129.40.28.33:3260/iqn.2017-04.com.example:t1/3
Formatting 'iscsi://129.40.28.33:3260/iqn.2017-04.com.example:t1/3', fmt=qcow2 size=31138512896 backing_file=/home/yilzhang/dataimage/rhel.qcow2 backing_fmt=qcow2 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16


pingl, please help to check, thank you.

Comment 8 Ping Li 2017-08-01 15:29:55 UTC
Change the summary to "Fail to create snapshot on iscsi backend when specifying backing file with relative path on local filesystem" according to comment 7.

Comment 9 Fam Zheng 2017-08-04 13:14:26 UTC
The relative filename is "relative to the created image", not relative to the working directory. Verify this with a small example:

fam@lemon:/var/tmp$ mkdir a
fam@lemon:/var/tmp$ cd a
fam@lemon:/var/tmp/a$ qemu-img create x 1G
Formatting 'x', fmt=raw size=1073741824
fam@lemon:/var/tmp/a$ cd ..
fam@lemon:/var/tmp$ qemu-img create a/y -b x -f qcow2
Formatting 'a/y', fmt=qcow2 size=1073741824 backing_file=x cluster_size=65536 lazy_refcounts=off refcount_bits=16
fam@lemon:/var/tmp$ qemu-img info a/y
image: a/y
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: x (actual path: a/x)
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
fam@lemon:/var/tmp$ cd
fam@lemon:~$ qemu-img info /var/tmp/a/y
image: /var/tmp/a/y
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: x (actual path: /var/tmp/a/x)
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false


So expecting a relative path to work against an iscsi URI doesn't make sense, and I don't see a reason why a user would think that could work. The only thing that is missing is to clarify that "if the backing file path is relative, it is looked up based on the newly created image, rather than the current working directory of the qemu-img command." in documentation.

Comment 10 Fam Zheng 2017-08-17 12:51:30 UTC
Posted a documentation patch to upstream:

https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg00821.html

Comment 11 Fam Zheng 2017-11-23 01:39:23 UTC
commit a16efd53406bc8d89f87253ab10290f8d1b145a7
Author: Fam Zheng <famz@redhat.com>
Date:   Fri Aug 4 22:36:58 2017 +0800

    qemu-img: Clarify about relative backing file options

    It's not too surprising when a user specifies the backing file relative
    to the current working directory instead of the top layer image. This
    causes error when they differ. Though the error message has enough
    information to infer the fact about the misunderstanding, it is better
    if we document this explicitly, so that users don't have to learn from
    mistakes.

    Signed-off-by: Fam Zheng <famz@redhat.com>
    Reviewed-by: Eric Blake <eblake@redhat.com>
    Reviewed-by: Jeff Cody <jcody@redhat.com>
    Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>

Comment 14 Miroslav Rezanina 2017-12-19 16:21:15 UTC
Fix included in qemu-kvm-rhev-2.10.0-13.el7

Comment 15 Ping Li 2017-12-20 03:36:26 UTC
The explanations have been added for subcommands create/convert/rebase of qemu-img since qemu-kvm-rhev-2.10.0-13.el7, set the bug as verified.

Comment 17 errata-xmlrpc 2018-04-11 00:19:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:1104


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