Hide Forgot
+++ This bug was initially created as a clone of Bug #1379579 +++ Description of problem: As subject Version-Release number of selected component (if applicable): qemu-kvm-2.7.0-1.fc26.x86_64 libvirt-2.2.0-1.fc26.x86_64 libguestfs-tools-c-1.35.6-1.fc26.x86_64 How reproducible: 100% Steps to Reproduce: 1. Using nbdkit to setup a nbd server with exportname 'image': # nbdkit file -n -e image file=V.qcow2 2. Try to read the image via guestfish # qemu-img info nbd://xx.xx.xx.xx:10809/image image: nbd://xx.xx.xx.xx:10809/image file format: qcow2 virtual size: 3.0G (3221225472 bytes) disk size: unavailable cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false # guestfish --ro --format=qcow2 -a nbd://xx.xx.xx.xx:10809/image libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: create: flags = 0, handle = 0x7fb2bc712fc0, program = guestfish libguestfs: trace: set_pgroup true libguestfs: trace: set_pgroup = 0 libguestfs: trace: add_drive "/image" "readonly:true" "format:qcow2" "protocol:nbd" "server:tcp:xx.xx.xx.xx:10809" libguestfs: creating COW overlay to protect original drive content libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: disk_create "/tmp/libguestfsPImcnO/overlay1" "qcow2" -1 "backingfile:nbd:xx.xx.xx.xx:10809:exportname=/image" "backingformat:qcow2" libguestfs: command: run: qemu-img libguestfs: command: run: \ create libguestfs: command: run: \ -f qcow2 libguestfs: command: run: \ -o backing_file=nbd:xx.xx.xx.xx:10809:exportname=/image,backing_fmt=qcow2 libguestfs: command: run: \ /tmp/libguestfsPImcnO/overlay1 qemu-img: /tmp/libguestfsPImcnO/overlay1: No export with name '/image' available libguestfs: error: qemu-img: /tmp/libguestfsPImcnO/overlay1: qemu-img exited with error status 1, see debug messages above libguestfs: trace: disk_create = -1 (error) libguestfs: trace: add_drive = -1 (error) libguestfs: trace: close libguestfs: closing guestfs handle 0x7fb2bc712fc0 (state 0) libguestfs: command: run: rm libguestfs: command: run: \ -rf /tmp/libguestfsPImcnO Actual results: As above Expected results: Parse exportname as 'image', not '/image'.
Patch posted: https://www.redhat.com/archives/libguestfs/2016-September/msg00181.html
I'm somewhat unconvinced this is a real bug, nor that breaking all existing guestfish users is worthwhile. Note that the current behaviour is documented in the manual page, which is usually our gold standard for what we shouldn't break. You can just use the longer 'add-drive' command if you want to specify export names which don't begin with a '/'. I suppose an alternative might be to allow an optional ?exportname=... parameter for the (guestfish) URL.
*** Bug 1379579 has been marked as a duplicate of this bug. ***
Fast forward four years, the rejected patch was committed upstream (without a couple of extra tests my version had): https://github.com/libguestfs/libguestfs/commit/bd3fb6535106847edbe340f9413ad43d4be03005 It will be in libguestfs >= 1.43.2.
Oh sorry, I didn't realise there was a bug for this and you'd already suggested roughly the same patch. (What did change is there's now a standard for NBD URIs). Do you want to push your two extra hunks on top, with a note pointing to this BZ?