Created attachment 1675603 [details] libvirtd-debug.log Description: Failed to create a disk only snapshot with --reuse-external to a existing qcow2 image Versions: libvirt-6.0.0-16.module+el8.2.0+6139+d66dece5.x86_64 qemu-kvm-4.2.0-17.module+el8.2.0+6129+b14d477b.x86_64 PLEASE NOTE: This is a regression, and not reproduced with: libvirt-6.0.0-15.module+el8.2.0+6106+b6345808.x86_64 qemu-kvm-4.2.0-16.module+el8.2.0+6092+4f2391c1.x86_64 Auto info: Failed case: virsh.snapshot_create_as.positive_tests.non_acl.file_disk.no_snapshot_attr.reuse_external Failed URL: https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.2%20x86_64/job/libvirt-RHEL-8.2-runtest-x86_64-function-snapshot/31/testReport/rhel.virsh/snapshot_create_as/positive_tests_non_acl_file_disk_no_snapshot_attr_reuse_external/ Latest passed URL: https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.2%20x86_64/job/libvirt-RHEL-8.2-runtest-x86_64-function-snapshot/30/testReport/rhel.virsh/snapshot_create_as/positive_tests_non_acl_file_disk_no_snapshot_attr_reuse_external/ How reproducible: 100% Steps: 1. Prepare a vm with disk = vda [root@dell-per740xd-11 ~]# virsh domblklist vm1 Target Source ----------------------------------------------- vda /var/lib/libvirt/images/rhel8.qcow2 [root@dell-per740xd-11 ~]# qemu-img info -U /var/lib/libvirt/images/rhel8.qcow2 image: /var/lib/libvirt/images/rhel8.qcow2 file format: qcow2 virtual size: 10 GiB (10737418240 bytes) disk size: 1 GiB cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false 2. Prepare another image as the disk snapshot target file [root@dell-per740xd-11 ~]# qemu-img create -f qcow2 /var/lib/libvirt/images/vda.snap1 10G Formatting '/var/lib/libvirt/images/vda.snap1', fmt=qcow2 size=10737418240 cluster_size=65536 lazy_refcounts=off refcount_bits=16 [root@dell-per740xd-11 ~]# qemu-img info /var/lib/libvirt/images/vda.snap1 image: /var/lib/libvirt/images/vda.snap1 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. Clear libvirtd log [root@dell-per740xd-11 ~]# echo "" > /var/log/libvirtd-debug.log 4. Do disk snapshot with --reuse-external [root@dell-per740xd-11 ~]# virsh snapshot-create-as vm1 --reuse-external --disk-only --diskspec vda,file=/var/lib/libvirt/images/vda.snap1 error: internal error: unable to execute QEMU command 'blockdev-add': Image is not in qcow2 format libvirtd debug log uploaded as attachment And the target image is removed, is this expected when snapshot job failed? [root@dell-per740xd-11 ~]# ll /var/lib/libvirt/images/vda.snap1 ls: cannot access '/var/lib/libvirt/images/vda.snap1': No such file or directory Expected result: Snapshot creation successful
Oops, this is a regression caused by upstream commit: commit 2ace7a87a8aced68c2504fd4dd4e2df4302c3eeb Author: Peter Krempa <pkrempa> Date: Mon Mar 30 11:18:37 2020 +0200 qemuDomainSnapshotDiskPrepareOne: Don't load the relative path with blockdev Since we are refreshing the relative paths when doing the blockjobs we no longer need to load them upfront when doing the snapshot.
Fixed upstream: commit ae64a75a8713cf14b25b40078766c2da93e001ff Author: Peter Krempa <pkrempa> Date: Thu Apr 2 07:29:58 2020 +0200 qemuDomainSnapshotDiskPrepareOne: Fix logic of relative backing store update Commit 2ace7a87a8aced68c250 introduced a logic bug by an improperly modified condition where we'd skip to the else branch when reusing of external images was requested and blockdev is available. The original intentions were to skip the backing store update with blockdev. Fix it by only asserting the boolean which was used to track whether we support update of the backing store only when blockdev is not present along with the appropriate rename.
Test with libvirt-6.0.0-17.module+el8.2.0+6257+0d066c28.x86_64 And result is PASS Snapshot auto test: No regression failures https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.2%20x86_64/job/libvirt-RHEL-8.2-runtest-x86_64-function-snapshot/33/testReport/ (The failed case is a expecting behavior after libvrt commit 045a8e19, not related to current issue, auto case will be updated) Blockcopy auto test: No regression failures https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.2%20x86_64/job/libvirt-RHEL-8.2-runtest-x86_64-function-block_copy_shallow/27/testReport/ Blockcommit blockpull auto test: No regression failures https://libvirt-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/libvirt/view/RHEL-8.2%20x86_64/job/libvirt-RHEL-8.2-runtest-x86_64-function-block_job_commit_pull/34/testReport/ (Well, the result is a little ugly, all failures are automation script issues since we have some libvirt behavior changed in this release, auto owner will modify the script in future, if you're interested about failure reason: https://projects.engineering.redhat.com/browse/LIBVIRTEIG-896)
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-2020:2017