** Description changed:
+ [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
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1837869
Title:
Cannot complete snapshot if read-only backing store is opened by
another VM
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1837869/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
