[Impact]
* Certain actions need to open/reopen files e.g. when doing a snapshot it
will reopen the old file as backing image. Those cases can fail due to
a bug in the flag handling.
* The fix is a backport of an upstream fix that fixes the options that
were lost on recursing through images.
[Test Case]
* There is a great test description in the initial report which I
extended to a script. Run the attached script should work once the fix
is applied.
Summary: set up image files, do a snapshot via QMP.
[Regression Potential]
* There were a lot of changes in this area and chances are that there are
side effects by only picking this change compared to adding up all the
other changes. In my testing I found the isolated single patch to work
fine for the case shown here and through regression tests. While at the
same time the bigger set of changes is harder to review/understand and
had some new hangs (by more side effects). So there is a risk, but I'd
hope we chose the most sane an reviewable approach.
[Other Info]
* n/a
---
On Bionic, Qemu complains that it cannot acquire write lock when commiting a snapshot if a read-only backing-store is opened by another qemu process. This behavior does not happen with version 2.12 in Cosmic.
Reproducer
==========
Create two QCOW2 containers sharing the same base file as a backing store :
base.qcow2
|
+---------+---------+
|-------------------|
middle-vm01.img middle-vm02.img
|-------------------|
top-vm01.img ---- top-vm02.img
# cat mkimage
#!/bin/bash
qemu-img create -f qcow2 base.qcow2 10G
qemu-img create -f qcow2 -b base.qcow2 middle-vm01.img 10G
qemu-img create -f qcow2 -b base.qcow2 middle-vm02.img 10G
qemu-img create -f qcow2 -b middle-vm01.img top-vm01.img 10G
qemu-img create -f qcow2 -b middle-vm01.img top-vm02.img 10G
Start two VM each using its own top-vm{id}.img
# cat runvm
#!/bin/bash
qemu-system-x86_64 -nographic -qmp unix:./qmp-1.sock,server,nowait -enable-kvm -device virtio-scsi-pci,id=scsi -device sga -nodefaults -monitor none -m 256M -drive file=./top-vm01.img,if=virtio,id=disk0 -smp 1 -smbios type=1,manufacturer=test&
qemu-system-x86_64 -nographic -qmp unix:./qmp-2.sock,server,nowait -enable-kvm -device virtio-scsi-pci,id=scsi -device sga -nodefaults -monitor none -m 256M -drive file=./top-vm02.img,if=virtio,id=disk0 -smp 1 -smbios type=1,manufacturer=test&
Create a snapshot
./scripts/qmp/qmp-shell ./qmp-1.sock
Welcome to the QMP low-level shell!
Connected to QEMU 2.11.1
(QEMU) blockdev-snapshot-sync device=disk0 snapshot-file=tmp.qcow2 format=qcow2
Formatting 'tmp.qcow2', fmt=qcow2 size=10737418240 backing_file=./top-vm01.img backing_fmt=qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16
{"return": {}}
Commit the snapshot
(QEMU) block-commit device=disk0 base=top-vm01.img
{"error": {"class": "GenericError", "desc": "Failed to get \"write\" lock"}}
Expected Behavior
=================
The commit should complete succesfully as the base.img backing store is opened read-only so no write lock is required
Current Behavior
================
The commit fails with "Failed to get "write" lock
Hi Luis o/,
glad to see you again.
This was a huge source of issues back when added in Bionics qemu.
I'm not wondering there were issues that still needed to be uncovered.
You flagged it as fixed in Disco, do you happen to know a particular patch already or just that the behavior doesn't appear there for you when testing?