Hi Ademar, I've read the virt-devel thread and I still have no idea what we're supposed to do at the OpenStack layer and when - can you please expand a little? Ideally it seems like this should be handled for us transparently by libvirt/qemu... Thanks, Steve
(In reply to Stephen Gordon from comment #1) > Hi Ademar, > > I've read the virt-devel thread and I still have no idea what we're supposed > to do at the OpenStack layer and when - can you please expand a little? > Ideally it seems like this should be handled for us transparently by > libvirt/qemu... > It should and it probably will. In this case, I recommend changing this BZ to TestOnly. We have made it a habit to open BZs for layered products whenever we change something substantial in QEMU, so you're aware of changes and have time to evaluate if it impacts you or not. In this particular case, looks like everything should be transparent to OpenStack.
As of now (07-MAR-2017), the upstream QEMU patch series for image locking is now targeted at QEMU 2.10. And also adding 'TestOnly' keyword, as this should be handled transparently by libvirt, which will have all the details about image sharing.
Expect any issues here to be detected via normal regression testing.
I'm re-opening this because I think we need a proactive action to audit Nova code. In particular any place in Nova which runs 'qemu-img' must be checked to make sure it doesn't do this while a running QEMU has the disk open. QEMU acquires locks on all images, so this would cause 'qemu-img' to fail unless told to override the locks. I think this is tricky enough that we shouldn't rely on normal QE testing finding all the problems, but rather actively check the code.
There's an upstream WIP patch to address this: https://review.openstack.org/#/c/505673/
Hey guess what, this breaks the support for working on volume multiattach in the upstream Queens release: https://review.openstack.org/#/c/267587/75/nova/virt/libvirt/guest.py We test against the ubuntu pike cloud archive which has qemu 2.10 and libvirt 3.6.0 and fail to attach a volume (block device) to a 2nd guest even with the shareable flag set. So I guess we'll have to put some conditional logic in the libvirt driver in nova to determine when multiattach will work or not based on the version of qemu and libvirt.
What kind of error is reported in that case?
(In reply to Peter Krempa from comment #12) > What kind of error is reported in that case? The error we see now is this: libvirtError: internal error: unable to execute QEMU command 'device_add': Failed to get "write" lock Driver failed to attach volume 68fc8c1d-b39d-4365-b370-a068c5d99d81 at /dev/vdb: libvirtError: internal error: unable to execute QEMU command 'device_add': Failed to get "write" lock
(In reply to Matt Riedemann from comment #11) > Hey guess what, this breaks the support for working on volume multiattach in > the upstream Queens release: > > https://review.openstack.org/#/c/267587/75/nova/virt/libvirt/guest.py > > We test against the ubuntu pike cloud archive which has qemu 2.10 and > libvirt 3.6.0 and fail to attach a volume (block device) to a 2nd guest even > with the shareable flag set. > > So I guess we'll have to put some conditional logic in the libvirt driver in > nova to determine when multiattach will work or not based on the version of > qemu and libvirt. Just to be clear, this bug is tracking https://review.openstack.org/#/c/505673/ into Queens for OSP 13. That change simply allows `qemu-img info` to be used against live instances with QEMU 2.10. AFAICT this change isn't causing the issues we are seeing with multi-attach at this time.
(In reply to Matt Riedemann from comment #11) > Hey guess what, this breaks the support for working on volume multiattach in > the upstream Queens release: > > https://review.openstack.org/#/c/267587/75/nova/virt/libvirt/guest.py > > We test against the ubuntu pike cloud archive which has qemu 2.10 and > libvirt 3.6.0 and fail to attach a volume (block device) to a 2nd guest even > with the shareable flag set. > > So I guess we'll have to put some conditional logic in the libvirt driver in > nova to determine when multiattach will work or not based on the version of > qemu and libvirt. So I learnt that 'multiattach' is supposed to mean that two VMs are able to use one image read-write (e.g. for cluster filesystems). This configuration should be possible in libvirt if the image shared is formatted as 'RAW' (qcow2 would suffer metadata corruption in such case) and the <shareable/> flag is put into the libvirt disk XML.
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/RHEA-2018:2086