Both x86 and ppc64le have this problem.

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.

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.

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.

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.

Posted a documentation patch to upstream:

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

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>

Fix included in qemu-kvm-rhev-2.10.0-13.el7

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.

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