Description of problem: When libguestfs started to account for QEMUs mandatory locking, it broke its support for handling NBD disks (like with the awesome nbdkit) when using the 'direct' backend. This is due to adding the option 'file.backing.file.locking=off' to the QEMU command line for readonly disks, which is not supported with NBD. It should be omitted when the guestfs overlay is backed by an NBD device. The issue was introduced with 9fe592808ccf ("launch: direct: Disable qemu locking when opening drives readonly (RHBZ#1417306)."). Version-Release number of selected component (if applicable): libguestfs-1.37.34-1.fc27.x86_64, but applies to current master, too. Steps to Reproduce: 1. export LIBGUESTFS_BACKEND=direct 2. nbdkit -rU- file file=$(mktemp) --run 'virt-filesystems -a nbd://?socket=$unixsocket' Actual results: libguestfs: error: appliance closed the connection unexpectedly. Use LIBGUESTFS_DEBUG to track it down to: qemu-system-x86_64: -drive file.file.filename=/tmp/libguestfsCKMsLP/overlay1.qcow2,file.driver=qcow2,cache=unsafe,file.backing.file.locking=off,id=hd0,if=none: Could not open backing file: Block protocol 'nbd' doesn't support the option 'locking' Expected results: Exit status 0, no output.
Thanks for the patch to fix this. I have pushed this and it'll be available in libguestfs >= 1.37.35. https://github.com/libguestfs/libguestfs/commit/35320dd0edb94d09d231bcded57aa883a5e7c784
Reopening because the fix is not quite right. It doesn't work when opening an NBD drive readonly.
Sorry, it *is* fixed, I was linking to the wrong (old) version of libguestfs ...