Bug 1569835 - qemu-img get wrong backing file path after rebasing image with relative path
Summary: qemu-img get wrong backing file path after rebasing image with relative path
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.5
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Max Reitz
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-20 04:59 UTC by Tingting Mao
Modified: 2018-11-01 11:07 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-rhev-2.12.0-6.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-01 11:07:33 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Tingting Mao 2018-04-20 04:59:49 UTC
Description of problem:
qemu-img get wrong backing file path after rebasing image with relative path.

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.10.0-21.el7_5.2

How reproducible:
100%

Steps to Reproduce:
1.Create snapshots at the directory of /home/raw_test/vm/
1.1 Create first snapshot
# pwd
/home/raw_test/vm
# qemu-img create -f qcow2 -F raw -b base.img snapshot/sn1.qcow2 
Formatting 'snapshot/sn1.qcow2', fmt=qcow2 size=21474836480 backing_file=base.img backing_fmt=raw cluster_size=65536 lazy_refcounts=off refcount_bits=16
1.2 Create second snapshot
# qemu-img create -f qcow2 -F raw -b sn1.qcow2 snapshot/sn2.qcow2 
Formatting 'snapshot/sn2.qcow2', fmt=qcow2 size=197120 backing_file=sn1.qcow2 backing_fmt=raw cluster_size=65536 lazy_refcounts=off refcount_bits=16

2.Rebase second snapshot to base.img
2.1 Rebase the second snapshot to the backing file which is relative to the directory containing the snapshot ---> failed
# pwd
/home/raw_test/vm
# qemu-img rebase -b base.img -F raw -f qcow2 snapshot/sn2.qcow2
qemu-img: Could not open new backing file 'base.img': Could not open 'base.img': No such file or directory
2.2 Rebase the second snapshot to the backing file according to current path ---> successful 
# qemu-img rebase -p -b snapshot/base.img -F raw -f qcow2 snapshot/sn2.qcow2
    (100.00/100%)

3.Check backing chain
# qemu-img info snapshot/sn2.qcow2 --backing-chain
qemu-img: Could not open 'snapshot/snapshot/base.img': Could not open 'snapshot/snapshot/base.img': No such file or directory


Actual results:
Get the wrong path of backing file.

Expected results:
Get correct path of backing file.

Additional info:
If rebasing the snapshot 2 to the absolute path of base.img, it will work.
# qemu-img rebase -p -F raw -f qcow2 -b /home/raw_test/vm/snapshot/base.img snapshot/sn2.qcow2 
    (100.00/100%)
# qemu-img info snapshot/sn2.qcow2 --backing-chain
image: snapshot/sn2.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: /home/raw_test/vm/snapshot/base.img
backing file format: raw
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: /home/raw_test/vm/snapshot/base.img
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 1.9G

Comment 2 Max Reitz 2018-05-09 14:46:29 UTC
Hi,

First,

# qemu-img create -f qcow2 -F raw -b sn1.qcow2 snapshot/sn2.qcow2 

That should be -F qcow2.

Disregarding that, I can reproduce the bug.  I don’t think it’s a recent regression, I think we’ve had this issue for a long time now.

Max

Comment 3 Max Reitz 2018-05-09 16:03:48 UTC
Sent an upstream series: http://lists.nongnu.org/archive/html/qemu-block/2018-05/msg00243.html

Comment 4 Tingting Mao 2018-05-10 01:52:12 UTC
(In reply to Max Reitz from comment #2)
> Hi,
> 
> First,
> 
> # qemu-img create -f qcow2 -F raw -b sn1.qcow2 snapshot/sn2.qcow2 
> 
> That should be -F qcow2.

I am sorry for the mistake, and thanks for your remind.

> Disregarding that, I can reproduce the bug.  I don’t think it’s a recent
> regression, I think we’ve had this issue for a long time now.

Yes, I agree that we've had this issue for a long time now.

Comment 6 Miroslav Rezanina 2018-07-01 03:23:17 UTC
Fix included in qemu-kvm-rhev-2.12.0-6.el7

Comment 8 Tingting Mao 2018-07-09 04:42:12 UTC
Verified this issue like below

Tested packages
qemu-kvm-rhev-2.12.0-7.el7
kenerl-3.10.0-918.el7

Steps
1.Create base.qcow2 in director "/home/test/bug_relative-path/snapshot"
# qemu-img create -f qcow2 base.qcow2 10G
Formatting 'base.qcow2', fmt=qcow2 size=10737418240 cluster_size=65536 lazy_refcounts=off refcount_bits=16
2.Create sn1.qcow2 in director "/home/test/bug_relative-path/"
# qemu-img create -f qcow2 -F qcow2 -b base.qcow2 snapshot/sn1.qcow2
Formatting 'snapshot/sn1.qcow2', fmt=qcow2 size=10737418240 backing_file=base.qcow2 backing_fmt=qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16
3.Create sn2.qcow2 in the same director "/home/test/bug_relative-path/"
# qemu-img create -f qcow2 -F qcow2 -b sn1.qcow2 snapshot/sn2.qcow2
Formatting 'snapshot/sn2.qcow2', fmt=qcow2 size=10737418240 backing_file=sn1.qcow2 backing_fmt=qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16
4.Execute rebase 
#pwd
/home/test/bug_relative-path
4.1 Rebase with relative path for backing file also, it should be failed.
# qemu-img rebase -p -b snapshot/base.qcow2 -f qcow2 -F qcow2 snapshot/sn2.qcow2 
qemu-img: Could not open new backing file 'snapshot/base.qcow2': Could not open 'snapshot/snapshot/base.qcow2': No such file or directory
4.2 Rebase with relative path just for snapshot, it should success
# qemu-img rebase -b base.qcow2 -f qcow2 -F qcow2 snapshot/sn2.qcow2---> success
# qemu-img info snapshot/sn2.qcow2 --backing-chain
image: snapshot/sn2.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 196K
cluster_size: 65536
backing file: base.qcow2 (actual path: snapshot/base.qcow2)
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: snapshot/base.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

Comment 9 errata-xmlrpc 2018-11-01 11:07:33 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/RHBA-2018:3443


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