Libvirt's schema never allowed them, but the code did not enforce it. +++ This bug was initially created as a clone of Bug #1588447 +++ Description of problem: https://www.redhat.com/archives/libvir-list/2018-June/msg00490.html If you have a reference to a relative path for a socket, these no longer work. They used to in older versions of libvirt, and they still work on certain architectures (for example, x86_64 still works, but i686 fails). libvirt should either reject them if they are wrong, or be fixed so that it works like it used to. If you decide to reject them, please clone this bug for libguestfs because we will need to fix the paths that we pass to libvirt. Version-Release number of selected component (if applicable): libvirt 4.4.0-1.fc29 How reproducible: Unknown, only on certain architectures at certain times. I was only able to reliably reproduce on i686 in a Koji build using qemu:///session. Steps to Reproduce: 1. Start nbdkit serving over a local Unix domain socket in the current directory: rm -f my.sock nbdkit -f -v -U my.sock example1 2. Create a guest which has a disk like: <disk device="disk" type="network"> <source protocol="nbd"> <host transport="unix" socket="my.sock"/> </source> <target dev="sda" bus="scsi"/> <driver name="qemu" type="raw" cache="writeback"/> </disk> 3. Start the guest under qemu:///session 4. Fails with: internal error: process exited while connecting to monitor: 2018-06-06T17:02:5 4.450507Z qemu-system-i386: -drive file=nbd+unix://?socket=my.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=w riteback: Failed to connect socket my.sock: No such file or directory [code=1 int1=-1] --- Additional comment from Peter Krempa on 2018-06-07 13:29:12 CEST --- The XML schema for the network disk unix socket backing always called for an 'absFilePath' so the given XML is not valid. I think we want to enforce absolute path even in the code for APPS which don't pass correct XML to libvirt.
Yes we'll have to "absolutize" (is that a word?) these paths before adding them to the XML, easy fix.
I don't have a very good reproducer because it only happens sometimes on some architectures. We could only reproduce it under Koji, on i686, with the very latest libvirt. This _may_ reproduce the problem: rm -f test.sock nbdkit -U test.sock example1 guestfish --format=raw -a 'nbd://?socket=test.sock' run killall nbdkit Note the error message when the bug has been reproduced is: Failed to connect socket test.sock: No such file or directory If you see other errors (eg. Permission denied) then you are not reproducing the error. Permission denied can happen because of SELinux. In fact to get guestfish to connect you'll probably need to set SELinux to Permissive. You can also try the full path which should NOT reproduce the problem, eg: guestfish --format=raw -a 'nbd://?socket=/var/tmp/test.sock' run The change we are going to make to libguestfs is to turn relative paths (test.sock) into absolute paths (/var/tmp/test.sock).
https://www.redhat.com/archives/libguestfs/2018-June/thread.html#00053
v2 of patch which fixes the tests: https://www.redhat.com/archives/libguestfs/2018-June/msg00067.html
Reproduced with the following packages: libvirt-4.4.0-1.fc29.i686 libguestfs-1.38.2-1.fc28.i686 nbdkit-1.2.2-1.fc28.i686 Steps: 1. Update libvirt on fedora28 host and then install nbdkit related packages. 2. rm -f test.sock 3. nbdkit -U test.sock example1 4. guestfish --format=raw -a 'nbd://?socket=test.sock' run --------------------------------------------------------- Original error from libvirt: internal error: process exited while connecting to monitor: 2018-06-20T08:40:16.518284Z qemu-system-i386: -drive file=nbd+unix://?socket=test.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback: Failed to connect socket test.sock: No such file or directory [code=1 int1=-1] --------------------------------------------------------- I can reproduce this bug, but when I turn the relative paths to absolute paths, another error pops up. # killall nbdkit # rm -rf test.sock # nbdkit -U test.sock example1 # guestfish --format=raw -a 'nbd://?socket=/home/test.sock' run ---------------------------------------------------------- Original error from libvirt: internal error: process exited while connecting to monitor: 2018-06-20 08:43:20.115+0000: Domain id=5 is tainted: high-privileges 2018-06-20 08:43:20.115+0000: Domain id=5 is tainted: custom-argv 2018-06-20T08:43:20.197767Z qemu-system-i386: -drive file=nbd:unix:/home/test.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback: request for write access conflicts with read-only export [code=1 int1=-1] rjones, do you know the reason about the error above?
> rjones, do you know the reason about the error above? Ooops, my example was wrong. Try changing the nbdkit command to use the example3 plugin which is writable: nbdkit -U test.sock example3 BTW you shouldn't need to run the tests as root.
> Try changing the nbdkit command to use the example3 plugin > which is writable: > > nbdkit -U test.sock example3 > > BTW you shouldn't need to run the tests as root. The example3 plugin is OK. Thanks a lot.
v3: https://www.redhat.com/archives/libguestfs/2018-June/msg00092.html
Upstream in https://github.com/libguestfs/libguestfs/commit/70bc83f893e6e0daf20ca7c9b7bfe875ceaed594 which will be included in libguestfs >= 1.39.6. I'll also backport this to 1.38 at some point. Note the current bug is against RHEL 7 so I'm not going to close it.
Verified with packages: libguestfs-1.38.2-8.el7.x86_64 nbdkit-1.2.6-1.el7.x86_64 libvirt-4.5.0-3.el7.x86_64 Steps: 1.Install nbdkit and nbdkit-example-plugins packages on rhel7.6 host, then run the following commands: $ rm -f test.sock $ nbdkit -U test.sock example3 $ guestfish --format=raw -a 'nbd://?socket=test.sock' run No error pops up. Verified it.
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:3021