On Fri, Mar 24, 2017 at 06:48:44PM +0100, Kevin Wolf wrote:
> 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?

You are right.  The following creates an AF_VSOCK connection:

  -drive 
if=virtio,file.driver=nbd,file.server.type=vsock,file.server.data.cid=3,file.server.data.port=1234

There is no pretty filename or URL representation that block/nbd.c
parses today.  The user must specify the full file.server
VsockSocketAddress options.

I think nbd_refresh_filename() is fine from a vsock point of view.  If
we'd like to encourage NBD-over-vsock in the future we could add code to
for nbd+vsock:// but in the meantime we don't need to fill in
bs->exact_filename[].

Attachment: signature.asc
Description: PGP signature

Reply via email to