Description of problem: the libguestfs version available in the Fedora 29 repositories has a bug which makes it impossible to start a QEMU image created by libguestfs. Version-Release number of selected component (if applicable): libguestfs-1.39.11-1.fc29.src.rpm How reproducible: always Steps to Reproduce: 1. run libguestfs to create a read-only clone a QEMU image 2. start the image 3. QEMU fails -> Failed to get "write" lock Actual results: QEMU fails with the message: Failed to get "write" lock libvirt: QEMU Driver error : internal error: process exited while connecting to monitor: 2019-01-08T10:43:31.779093Z qemu-system-x86_64: -drive file=/tmp/osw-instances-1mw3fvuk/de81c7ff-b795-47f7-aa21-54d27c33fbbb/de81c7ff-b795-47f7-aa21-54d27c33fbbb,format=qcow2,if=none,id=drive-virtio-disk0: Failed to get "write" lock Is another process using the image? Expected results: The VM should have started normally. Additional info: I found this bug report on launchpad: https://bugs.launchpad.net/qemu/+bug/1740364 stating that the bug should be fixed in libguestfs 1.40, with a link to the commit on Github: https://github.com/libguestfs/libguestfs/commit/f00f920ad3b15ab8e9e8f201c16e7628b6b7b109 Please tell me if it can be done, or what is blocking you ATM. Thanks.
You'll probably find a few more of these because qemu broke a load of stuff recently. 1.40 should be released soon but in the meantime I pushed a build with this patch.
Fix is here, I don't know why Bodhi didn't update this bug though. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7e427beea7
I downloaded your source package, but for some reason, DNF won't install it: $ sudo dnf install libguestfs-1.39.11-3.fc29.src.rpm Dernière vérification de l’expiration des métadonnées effectuée il y a 0:29:47 le mar. 08 janv. 2019 16:41:59 CET. Erreur : Un paquet source rpm ne sera pas installé (libguestfs-1:1.39.11-3.fc29.src). Error: a source package will not be installed Did i do something wrong ? Also I tried to login on Bodhi to drop a comment, but the login page give me a invalid ID error. Thanks !
Ok, DNF is not supposed to deal with source package. I'm not familiar with updating a package outside of the traditional "sudo dnf upgrade" How should I do this ? download all the binary packages one by one ? or wait for the package to be in the repositories I'd like to test your update and give you a confirmation that it works.
Go to the build on the Builds tab: https://koji.fedoraproject.org/koji/buildinfo?buildID=1177918 Run a command such as: koji download-build libguestfs-1.39.11-3.fc29 and dnf install the packages you need.
It turns out that the patch didn't solve my problem. But I think i need to explain how my project works for you to better understand what's going on. I'm building a sort of VM inspector. When i start inspecting a VM, a new VM (let's call it VM_COPY) will be created with a hard disk using the inspected VM disk as baking file (to avoid modifying it) Then i start a libguestfs instance (which creates a temporary VM too, with its own hard disks and baking files from the inspected VM) VM -> /home/wenzel/kvm/ubuntu16.04.qcow2 VM_COPY -> /tmp/osw-instances/VM_COPY/{uuid}.qcow2 baking file: /home/wenzel/kvm/ubuntu16.04.qcow2 VM_GUESTFS -> /tmp/libguestfsxxxxx/overlay1.qcow2 baking file: /tmp/osw-instances/VM_COPY/{uuid}.qcow2 -> /tmp/libguestfsxxxxx/overlay2.qcow2 baking file: /var/tmp/.guestfs-1000/appliance.d/root And when i'm done with libguestfs (without calling g.shutdown()), the next step of my inspection is to start the VM_COPY domain. And it's at this point that I have the message about the lock from QEMU. As long as libguestfs is running, even if I specified read-only, i cannot start my VM_COPY. Maybe it can help you figure out the problem ? It's the first time I have this issue. I always used my project this way and It was working before. When did QEMU introduced this "locked" feature ? Thanks Richard !
> And when i'm done with libguestfs (without calling g.shutdown()), the next > step of my inspection is to start the VM_COPY domain. > And it's at this point that I have the message about the lock from QEMU. This is really a question about the new qemu locking feature added in 2.10. But why not close the libguestfs connection before starting the VM? Also there is an "lslocks" command which will show you the processes which are holding locks on a file. That should be able to precisely answer your question about what exactly is holding the lock.
> But why not close the libguestfs connection before starting the VM? Because I have a plugin based architecture and some plugins might require this libguestfs instance after the VM_COPY has been shutdown, at the end of the analysis. But that's a detail. I look at `lsocks` output while having libguestfs running, and the only I can see is 3 locks related to libvirt: 53:virtlogd 26648 POSIX 5B WRITE 0 0 0 /run/user/1000/libvirt/virtlogd.pid 59:libvirtd 9212 POSIX 4B WRITE 0 0 0 /run/user/1000/libvirt/libvirtd.pid 75:libvirtd 1259 POSIX 4B WRITE 0 0 0 /run/libvirtd.pid The rest is not helpful because the path is incomplete and the process is (undefined) I can stick with shutting down libguestfs before starting my VM_COPY, that's not a problem for now. I was just curious how this could be fixed in the long term.
It's qemu (or qemu-img) which is holding locks. Neither libguestfs nor libvirt should be holding locks on VM images as far as I'm aware (definitely not libguestfs, not certain about libvirt).