Am 24.03.2017 um 16:47 hat Stefan Hajnoczi geschrieben: > On Thu, Mar 23, 2017 at 05:48:48PM +0100, Markus Armbruster wrote: > > BlockdevOptionsNbd has a member SocketAddress, and nbd_config() doesn't > > restrict variants. Thus, all four SOCKET_ADDRESS_KIND_ can occur. > > > > Now have a look at nbd_refresh_filename(). s->saddr->type is If > > SOCKET_ADDRESS_KIND_VSOCK or SOCKET_ADDRESS_KIND_FD, then @host, @port > > and @path all remain null, and bs->exact_filename[] is not touched. > > > > Does this work as intended? > > NDB over AF_VSOCK has not been tested. I would expect it to fail > earlier than nbd_refresh_filename().
Why would that be? Do the socket creation helper functions not support vsock yet? > It's certainly possible to come up with the host=,port= for AF_VSOCK. > > Not sure about file descriptor passing. Either we could getsockaddr() > and print out the host=,port= or path= (depending on the address > family), or we could use some syntax for referring to the file > descriptor. The point of .bdrv_refresh_filename is to provide a "nicer" filename for humans, but it still needs to be a valid input. We do accept URLs as a convenience feature for NBD connections over TCP and Unix domain sockets, so we create a filename for those. For everything else, we require individual options rather than a URL and should therefore not create a filename. The block layer creates a json: description then. Kevin