Bug 1591628

Created attachment 1451788 [details]
libvirtd_qemu_logs

Could you please check if managesave will hang and then libvirtd deadlock after snapshot-revert --force?

(In reply to Han Han from comment #4)
> Could you please check if managesave will hang and then libvirtd deadlock
> after snapshot-revert --force?

Checked and the result is yes.

Since it seems this is the root cause of the vmgenid validation effort and resulting needsinfo on me - https://bugzilla.redhat.com/show_bug.cgi?id=1149445#c10 - I investigated whether what I had ready to post would also solve this problem and it did.

So, I posted a patch series upstream to resolve:

https://www.redhat.com/archives/libvir-list/2018-June/msg01425.html

patch 5 is the actual fix, but patches 1-4 get a few things set up and also make a minor adjustment to the way vmgenid (e.g. bz1149445) is handled for the --force option.

This has now been pushed upstream:

commit 0c4408c832368b45c8246175e2a75132d3ff0302
Author: John Ferlan <jferlan>
Date:   Tue Jun 19 18:54:19 2018 -0400

    qemu: Don't use asyncJob after stop during snapshot revert
    
...
    
    Attempting to use the FORCE flag for snapshot-revert was resulting
    in failures because qemuProcessStart and qemuProcessStartCPUs were
    using QEMU_ASYNC_JOB_START after a qemuProcessStop resulting in an
    error when entering the monitor:
    
    error: internal error: unexpected async job 6 type expected 0
    
    So create a local @jobType, initialize to QEMU_ASYNC_JOB_START, and
    change to QEMU_ASYNC_JOB_NONE if we end up in the --force path
    where the qemuProcessStop is run before a Start and StartCPUs.
    
$  git describe 0c4408c832368b45c8246175e2a75132d3ff0302
v4.4.0-296-g0c4408c832
$

Verified on:
libvirt-4.5.0-6.el7.x86_64
qemu-kvm-rhev-2.12.0-10.el7.x86_64

(test vm with/without <genid/>, most detailed genid test will be carried on with bz1149445)
# virsh domblklist vm2
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/vm2-1.qcow2


# qemu-img info /var/lib/libvirt/images/vm2-1.qcow2 -U --backing-chain
image: /var/lib/libvirt/images/vm2-1.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 10G
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true
    refcount bits: 16
    corrupt: false

# virsh snapshot-create-as vm2 vm2.s1
Domain snapshot vm2.s1 created

# qemu-img info /var/lib/libvirt/images/vm2-1.qcow2 -U --backing-chain
image: /var/lib/libvirt/images/vm2-1.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 10G
cluster_size: 65536
Snapshot list:
ID        TAG                 VM SIZE                DATE       VM CLOCK
1         vm2.s1                 487M 2018-08-20 17:26:14   00:02:41.660
Format specific information:
    compat: 1.1
    lazy refcounts: true
    refcount bits: 16
    corrupt: false


# qemu-img create -f qcow2 /var/lib/libvirt/images/bar.img 10M
Formatting '/var/lib/libvirt/images/bar.img', fmt=qcow2 size=10485760 cluster_size=65536 lazy_refcounts=off refcount_bits=16


# virsh attach-disk vm2 /var/lib/libvirt/images/bar.img vdb --live
Disk attached successfully

# virsh domblklist vm2
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/vm2-1.qcow2
vdb        /var/lib/libvirt/images/bar.img

# virsh snapshot-revert vm2 vm2.s1
error: revert requires force: Target domain disk count 1 does not match source 2

# virsh snapshot-revert vm2 vm2.s1 --force

# echo $?
0

# virsh domblklist vm2
Target     Source
------------------------------------------------
vda        /var/lib/libvirt/images/vm2-1.qcow2

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:3113