Bug 1664318
Summary: | Upgrade libguestfs package to 1.39.14 | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | mathieu.tarral |
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
Status: | MODIFIED --- | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | ptoscano |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libguestfs-1.39.11-3.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | Type: | Bug | |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
mathieu.tarral
2019-01-08 12:43:08 UTC
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). |