Bug 2004254

+++ This bug was initially created as a clone of Bug #1994428 +++

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.

--- Additional comment from Tingting Mao on 2021-08-17 09:16:03 UTC ---

This issue is fixed in rhelav, refer to bug 1599277 and bug 1783173 please.

--- Additional comment from Klaus Heinrich Kiwi on 2021-08-18 19:39:49 UTC ---

How is thus bug different from bug 1783173?

--- Additional comment from Tingting Mao on 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.

--- Additional comment from Hanna Reitz on 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

--- Additional comment from Tingting Mao on 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

--- Additional comment from Hanna Reitz on 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

--- Additional comment from Tingting Mao on 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.

--- Additional comment from Hanna Reitz on 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