[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

This bug was fixed in the package libvirt - 4.0.0-1ubuntu1 --- libvirt (4.0.0-1ubuntu1) bionic; urgency=medium * Merged with Debian unstable (4.0) This closes several bugs: - Error generating apparmor profile when hostname contains spaces (LP: #77) - qemu 2.10

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Libvirt will make this "easier" to be avoided by commit 28907b0043fbf71085a798372ab9c816ba043b93 Author: Peter Krempa Date: Wed Nov 15 15:21:14 2017 +0100 qemu: command: Mark disks as such in qemu Qemu has now an internal mechanism for locking images to fix

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

I've taked this qemu-file-locking just so we can group/easily find other bugs that have this tag. link to search for all bugs with that tag is: https://goo.gl/W2aT2T or the longer form:

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

** Tags added: qemu-file-locking -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage notifications about this bug go to:

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

** Changed in: libvirt (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage notifications

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Also on the qemu side this is "works as intended" and workarounds are documented in this bug. So we should set that bug status as well - looking back given it was mostly a discussion I guess "opinion" is the best close status in this case. ** Changed in: qemu (Ubuntu) Status: Won't Fix

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Umm, the latter is the official way to go, but only in latter libvirt versions. https://libvirt.org/git/?p=libvirt.git;a=commit;h=28907b0043fbf71085a798372ab9c816ba043b93 I'm adding a libvirt bug task for the bionic merge to pick that up "explicitly" ** Changed in: qemu (Ubuntu) Status:

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Note: Depending on the case you might also get lucky with "shareable" and/or "readonly" disk attributes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

We had a discussion today on how to workaround if you drive qmeu via libvirt. While discussions often and up at the correctness of such setups they exists, I think it is worth to document until libvirt supports that officially. TL:DR: - no native libvirt feature yet - discussions if should set

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Note that 'share-rw' was introduced earlier (commit dabd18f6, qemu 2.9) than 'locking' (commit 16b48d5d, qemu 2.10), so if qemu 2.9 is relevant for you, your hacky check doesn't work. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Kevin, thanks again. You've provided enough support for me at this point. I had looked at trying to coalesce multiple -drive values into a single one, and that can definitely be made to work with the newer qemu, but i'm not sure I can make it work with older. the goal there would be to do

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

The important difference between your -drive command line and my -blockdev example is that I used the node-name to reference the image. You can specify a node-name with -drive, too (having both id and node- name is one of the main things that I meant what I said mixing both styles can be

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

I see the answer to my question above. 'format' is now driver=qcow2. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Your example does work (using -blockdev), but I can't get it to work with -drive. $ qemu-system-x86_64 \ -drive id=d01,file=disk1.img,format=qcow2 \ -device drive=d01,serial=s01,driver=virtio-blk,index=1,share-rw=on \ -device drive=d01,serial=s01,driver=virtio-blk,index=2,share-rw=on

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

The share-rw=on option belongs to -device, not to -drive/-blockdev. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage notifications

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Kevin, Thanks for the suggestion of share-rw=on. I figured I'd try to change our 'xkvm' wrapper around qemu to use that. Unfortunately, it looks like , at least in our version of qemu (QEMU emulator version 2.10.0(Debian 1:2.10+dfsg-0ubuntu1)), that this does not work with the -drive path. $

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Having a single QEMU process open the same qcow2 file twice is just as dangerous as having two separate QEMU processes open the same qcow2 file concurrently. In both cases you have qcow2 state cached in a BlockDriverState and nothing is able to invalidate the cache in the other BlockDriverState.

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

In our multipath case, the initial open succeeds (it's not locked by anything else) and the second lock attempt fails, however, IIUC the fcntl structure[1] includes the locking pid, which should be our invocation of QEMU; Can we not check if the locking pid matches the current pid and not fail?

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially "uncompress" qemu schema output" https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948029/+files/dump-qmp-schema.py ** Attachment removed: "dump-qmp-schema.py: a hack job to dump and partially

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

** Attachment added: "dump-qmp-schema.py: a hack job to dump and partially "uncompress" qemu schema output" https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028/+attachment/4948028/+files/dump-qmp-schema.py -- You received this bug notification because you are a member of Ubuntu

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Kevin, Thanks for the information. A couple of points for feedback: 1) there doesn't appear to be a way to run qmp query-schema without spawning a qemu instance in -qmp mode and having a second client issue the query-schema; certainly a qemu-system-$arch -qmp-schema would be quite useful when

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

The correct way to query whether file locking is supported is 'query- qmp-schema', which will expose the 'locking' option for the 'file' branch of the 'blockdev-add' command then. As a first comment, in your setup, completely disabling file locking is probably a too big hammer. It is preferable

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Thanks Ryan for filing this bug, as I said in IRC all the file locking is rather new and I think this is for upstream qemu to address. Might just be a missed use case for them as well. I'll be adding an upstream qemu task to get their attention. @Rayn - It would be nice if - from the multipath

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

Added a qemu task, this seems to be a use case affected by the file locking. In particular a (formerly working) case for multipath tests that use the same image files multiple times intentionally. So far the workaround is to set file.locking=off for all these, which might be just the right

[Bug 1716028] Re: qemu 2.10 locks images with no feature flag

** Branch linked: lp:~smoser/curtin/trunk.lp1716028-hack-file-locking- in-qemu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1716028 Title: qemu 2.10 locks images with no feature flag To manage