[libvirt] Mystery of qemu being unable to open NBD Unix domain socket in current directory

[Eric Blake]

On 06/06/2018 12:29 PM, Richard W.M. Jones wrote:
> I'm chasing down a very frustrating bug which only happens on i686 &
> Koji during the nbdkit tests and seemingly nowhere else.  Anyway this
> is what I've been able to put together:
> 
> The libguestfs appliance (guest) is created with this XML snippet:
> 
>    <disk device="disk" type="network">
>      <source protocol="nbd">
>        <host transport="unix" socket="cow.sock"/>

Have you tried an absolute path?

> At this point I don't really have any ideas.  Does libvirt now run
> qemu in a different directory?  Does the error message mean something
> else apart from the file not existing?

Libvirtd does chdir("/") early on, so likely qemu is run with / (rather 
than the original current working directory) as its root. So an absolute 
path should fix things.

>   2018-06-06T17:02:54.450507Z qemu-system-i386: -drive file=nbd+unix://?socket=cow.sock,format=raw,if=none,id=drive-scsi0-0-0-0,cache=writeback: Failed to connect socket cow.sock: No such file or directory

> 
> Also the nbd+unix syntax doesn't appear to be documented in qemu.
> Is this a new thing?  Normally we use nbd:unix:...

nbd:unix:... is the old-style legacy form, nbd+unix:// is the URI style. 
  The URI style is a bit more flexible (you can add options without 
having to add more ad-hoc parsing). Ideally, we'll be moving libvirt to 
an even newer -blockdev style (which can either directly use the JSON 
you'd hand to QMP blockdev-add, or which uses a dotted syntax similar to 
-drive); that's been an ongoing task for Peter.  As for lack of 
documentation in qemu, I'm not surprised.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org