Bug 1451269
Summary: | Clarify the relativity of backing file and created image in "qemu-img create" | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | yilzhang |
Component: | qemu-kvm-rhev | Assignee: | Fam Zheng <famz> |
Status: | CLOSED ERRATA | QA Contact: | Ping Li <pingl> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.4 | CC: | aliang, chayang, coli, juzhang, knoel, lmiksik, michen, ngu, pingl, qzhang, virt-maint, xuma, yilzhang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | qemu-kvm-rhev-2.10.0-13.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-04-11 00:19:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1473046 |
Description
yilzhang
2017-05-16 09:19:31 UTC
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> 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> Reviewed-by: Eric Blake <eblake> Reviewed-by: Jeff Cody <jcody> Reviewed-by: Stefan Hajnoczi <stefanha> Signed-off-by: Kevin Wolf <kwolf> 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 |