RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1994428 - Some backing file names are not accepted by qemu-img commit
Summary: Some backing file names are not accepted by qemu-img commit
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.0
Hardware: x86_64
OS: All
medium
low
Target Milestone: beta
: ---
Assignee: Hanna Czenczek
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On: 1997410
Blocks: 2004254
TreeView+ depends on / blocked
 
Reported: 2021-08-17 09:14 UTC by Tingting Mao
Modified: 2021-12-07 22:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2004254 (view as bug list)
Environment:
Last Closed: 2021-09-17 06:09:48 UTC
Type: ---
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-93801 0 None None None 2021-08-17 09:14:38 UTC

Description Tingting Mao 2021-08-17 09:14:14 UTC 
Description of problem:
As subject.


Version-Release number of selected component (if applicable):
qemu-kvm-4.2.0-57.module+el8.5.0+12118+4998563d
kernel-4.18.0-330.el8.x86_64


How reproducible:
100%


Steps to Reproduce:
1. Create a base luks image.
# qemu-img create -f luks --object secret,id=image1_encrypt0,data=redhat -o key-secret=image1_encrypt0 base.luks 1G

2. Create snapshot based on the luks image.
# qemu-img create --object secret,id=image1_encrypt0,data=redhat -f qcow2 -b 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' sn1.qcow2

3. Create another snapshot based on last snapshot.
# qemu-img create -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b sn1.qcow2 sn2.qcow2

4. Rebase the commit sn2.qcow2 to base.
# qemu-img commit -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' sn2.qcow2 -p     -----------------------> The string for base image is copied from step2.


Actual results:
After step4, failed as below.
# qemu-img commit -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' sn2.qcow2 -p
    (0.00/100%)
qemu-img: Did not find 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' in the backing chain of 'sn2.qcow2'


Expected results:
Commit successfully. 


Additional info:
It only works when specifying the string for new base with the result from backing-chain info.
1. Check the backing chain image info.
# qemu-img info sn2.qcow2 --backing-chain
image: sn2.qcow2
file format: qcow2
virtual size: 1 GiB (1073741824 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: sn1.qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: sn1.qcow2
file format: qcow2
virtual size: 1 GiB (1073741824 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: json:{"driver": "luks", "file": {"driver": "file", "filename": "base.luks"}, "key-secret": "image1_encrypt0"}
file format: luks
virtual size: 1 GiB (1073741824 bytes)
disk size: 256 KiB
encrypted: yes
Format specific information:
    ivgen alg: plain64
    hash alg: sha256
    cipher alg: aes-256
    uuid: 624f7e2f-48db-449e-9ebf-9a4a68c4a69c
    cipher mode: xts
    slots:
        [0]:
            active: true
            iters: 1030440
            key offset: 4096
            stripes: 4000
        [1]:
            active: false
            key offset: 262144
        [2]:
            active: false
            key offset: 520192
        [3]:
            active: false
            key offset: 778240
        [4]:
            active: false
            key offset: 1036288
        [5]:
            active: false
            key offset: 1294336
        [6]:
            active: false
            key offset: 1552384
        [7]:
            active: false
            key offset: 1810432
    payload offset: 2068480
    master key iters: 213596

2. Commit the changes to the base.
# qemu-img commit -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b 'json:{"driver": "luks", "file": {"driver": "file", "filename": "base.luks"}, "key-secret": "image1_encrypt0"}' sn2.qcow2 -p  --------------------------------- The string of new base is copied from the value of "image" of the result from last step.
    (100.00/100%)
Image committed.
Comment 1 Tingting Mao 2021-08-17 09:16:03 UTC 
This issue is fixed in rhelav, refer to bug 1599277 and bug 1783173 please.
Comment 2 Klaus Heinrich Kiwi 2021-08-18 19:39:49 UTC 
How is thus bug different from bug 1783173?
Comment 3 Tingting Mao 2021-08-19 01:14:44 UTC 
(In reply to Klaus Heinrich Kiwi from comment #2)
> How is thus bug different from bug 1783173?

The issue is the same, but bug 1783173 is for RHELAV, while this is for rhel8 slow train.
Comment 4 Hanna Czenczek 2021-08-19 08:24:07 UTC 
Hi,

BZ 1783173 was closed as WONTFIX, though.  I believe the reasoning I laid out in BZ 1783173 comment 1 still applies.  So why should we fix this in the slow train?

Hanna
Comment 5 Tingting Mao 2021-08-19 10:54:01 UTC 
Hi,

The issue of BZ 1783173 should be fixed by bug 1599277 in RHELAV. While in the slow train, there is also the issue of bug 1599277, check below steps, please.

My intention is that we could fix this bug via the patches of bug 1599277. what do you think?



Reproduced bug 1599277 in slow train as below:

Tested env:
qemu-kvm-4.2.0-58.module+el8.5.0+12272+74ace547
kernel-4.18.0-330.el8.x86_64


Steps:
1. Create snapshot chains and write data the top snapshot file.
# pwd
/home/timao/test
# qemu-img create -f qcow2 base.qcow2 10G
# qemu-img create -f qcow2 -b base.qcow2 sn1.qcow2
# qemu-img create -f qcow2 -b sn1.qcow2 sn2.qcow2
# qemu-io -c 'write -P 1 0 1G' sn2.qcow2

2. Check the working diretory and check info of the snapshot file
# pwd
/home/timao
# qemu-img info test/sn2.qcow2 --backing-chain
image: test/sn2.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 1 GiB
cluster_size: 65536
backing file: sn1.qcow2 (actual path: test/sn1.qcow2)
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

image: test/sn1.qcow2
file format: qcow2
virtual size: 10 GiB (10737418240 bytes)
disk size: 196 KiB
cluster_size: 65536
backing file: base.qcow2 (actual path: test/base.qcow2)
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

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

3. Commit the top snapshot file to the base file
# pwd
/home/timao
# qemu-img commit -f qcow2 -b base.qcow2 test/sn2.qcow2
qemu-img: Did not find 'base.qcow2' in the backing chain of 'test/sn2.qcow2'
# qemu-img commit -f qcow2 -b test/base.qcow2 test/sn2.qcow2
qemu-img: Did not find 'test/base.qcow2' in the backing chain of 'test/sn2.qcow2'
# qemu-img commit -f qcow2 -b /home/timao/test/base.qcow2 test/sn2.qcow2 
qemu-img: Did not find '/home/timao/test/base.qcow2' in the backing chain of 'test/sn2.qcow2'



Best,
Tingting
Comment 6 Hanna Czenczek 2021-08-19 11:08:11 UTC 
Ah, OK, but that has little to do with the JSON format.

The series to fix that (BZ 1599277) was really long and really invasive (compare BZ 1594747 comment 15; that BZ was fixed by the same series), so unless this really, really important, I don’t think we want to fix that in the slow train.

Hanna
Comment 7 Tingting Mao 2021-08-20 03:42:35 UTC 
As we're planning to rebase the qemu-kvm package for 8.6, maybe we'll get this automatically fixed then? Like BZ 1994194.
Comment 8 Hanna Czenczek 2021-08-20 10:25:00 UTC 
Oh, great!

Bisecting shows me this was fixed upstream in 0b877d09df4557900149384d60be0e9c3d309105 (part of the big “Deal with filters” series mentioned in comment 6).  I’ve tried to come up with a more general BZ title, which I hope is OK for you.

I suppose I’m leaving “Fixed in Version” open for now, and also I’m not moving this commit to POST until we have a downstream package/tag.  (I don’t see a rhel-8.6.0 branch in gitlab yet, so I don’t suppose we have a downstream package.)

Hanna
Comment 9 John Ferlan 2021-09-14 19:44:10 UTC 
Cloned to RHEL9, moved bug to POST, set DTM=4 and added qemu-6.1 rebase to depends on list
Comment 10 Tingting Mao 2021-09-16 08:39:26 UTC 
Verified this bug as below. 


Tested with:
qemu-kvm-6.1.50-1.scrmod+el8.5.0+12607+25db754d.wrb210915
kernel-4.18.0-339.el8.x86_64


Steps:
1. Create a base luks image.
# qemu-img create -f luks --object secret,id=image1_encrypt0,data=redhat -o key-secret=image1_encrypt0 base.luks 1G

2. Create snapshot based on the luks image.
# qemu-img create --object secret,id=image1_encrypt0,data=redhat -f qcow2 -b 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' -F luks sn1.qcow2

3. Create another snapshot based on last snapshot.
#  qemu-img create -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b sn1.qcow2 -F qcow2 sn2.qcow2

4. Rebase the commit sn2.qcow2 to base.
# qemu-img commit -f qcow2 --object secret,id=image1_encrypt0,data=redhat -b 'json:{"file": {"driver": "file", "filename": "base.luks"}, "driver": "luks", "key-secret": "image1_encrypt0"}' sn2.qcow2 -p
    (100.00/100%)
Image committed.


Results:
As above, commiting successed.
Note You need to log in before you can comment on or make changes to this bug.