Comment 7 for bug 1718133

This patch set was never accepted that way, but yeah reviving that might be an option to work around this. Also this was long ago, but the lock rewrite/enablement happened only recently so a totally new approach might be needed (or is present without us knowing).

We might ping qemu-devel about that to be clear of too much assumptions.

To help with that I found that repro could be as easy as:
1. start a guest
2. get the blockinfo and pick a disk
3. run qemu-img info on it while running

Example:
#1 (any other kvm guest will do as well)
uvt-simplestreams-libvirt --verbose sync --source http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=xenial
uvt-kvm create --password=ubuntu xenial-test release=xenial arch=amd64 label=daily
#2 Depending on how you started it you might know the path already
virsh domblklist xenial-test
Target Source
------------------------------------------------
vda /var/lib/uvtool/libvirt/images/xenial-test.qcow
vdb /var/lib/uvtool/libvirt/images/xenial-test-ds.qcow
#3 check img info
$ qemu-img info /var/lib/uvtool/libvirt/images/xenial-test.qcow
qemu-img: Could not open '/var/lib/uvtool/libvirt/images/xenial-test.qcow': Failed to get shared "write" lock
Is another process using the image?

To simplify further - we don't care what the guest does:
$ qemu-img create -f qcow2 /tmp/test.qcow2 1M
$ qemu-system-x86_64 -hda /tmp/test.qcow2 -enable-kvm -nodefaults -nographic &
$ qemu-img info /tmp/test.qcow2
qemu-img: Could not open '/tmp/test.qcow2': Failed to get shared "write" lock
Is another process using the image?

I't won't get easier, but that might be great to re-trigger the old nolock thread.