Re: [RFC 00/10] NFS: add AF_VSOCK support to NFS client

[Stefan Hajnoczi <stefanha-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3505 bytes --]

On Mon, Jun 08, 2015 at 05:02:47PM -0400, J. Bruce Fields wrote:
> On Thu, Jun 04, 2015 at 05:45:43PM +0100, Stefan Hajnoczi wrote:
> > The approach in this series
> > ---------------------------
> > AF_VSOCK stream sockets can be used for NFSv4.1 much in the same way as TCP.
> > RFC 1831 record fragments divide messages since SOCK_STREAM semantics are
> > present.  The backchannel shares the connection just like the default TCP
> > configuration.
> 
> So the NFSv4 backchannel isn't handled for now, I assume.

Right, I did not touch nfs4_callback_up_net(), only
nfs41_callback_up_net().

If I'm reading the code right NFSv4 uses a separate listen port for the
backchannel instead of sharing the client's socket?

This is possible to implement with AF_VSOCK but I have only tested
NFSv4.1 so far.  Should I go ahead and do this?

> And I guess
> NFSv2/v3 is out too thanks to rpcbind?  Which maybe is fine.

Yes, I ignored rpcbind and didn't test NFSv2/v3.

> Do we need an IETF draft or similar to document how NFS should work over
> AF_VSOCK?

I am not familiar with the standards process but I came across a few
places where it makes sense to have a standard:

 * SUNRPC netid for AF_VSOCK (currently "tcp", "udp", and others exist)
 * The uaddr string format ("vsock:...")
 * Use of RFC 1831 record fragments (just like TCP) over AF_VSOCK
   SOCK_STREAM sockets

These are all at the SUNRPC level rather than at the NFS protocol level.

Any idea who I need to talk to?

> NFS developers rely heavily on wireshark (and similar tools) for
> debugging.  Is that still possible over AF_VSOCK?

No, this will require kernel and libpcap patches.  Something like
drivers/net/nlmon.c is needed for AF_VSOCK.  Basically a dummy network
interface and code that clones skbs when monitoring is enabled.

It's on the TODO list and will be very useful.

> > The next step is tackling NFS server.  In the meantime, I have tested the
> > patches using the nc-vsock netcat-like utility that is available in my Linux
> > kernel repo below.
> 
> So by a netcat-like utility, you mean it's proxying between client and a
> server so the client thinks the server is communicating over AF_VSOCK
> and the server thinks the client is using TCP?  (Sorry, I haven't looked
> at the code.)

Yes, exactly.  It works since the TCP and AF_VSOCK streams are almost
bit-compatible.  I think the difference between the streams occurs when
network addresses are transmitted (e.g. SUNRPC netids), but I haven't
encountered that with NFSv4.1 and no pnfs or fancy features in use.

> Once we have a server and client, how will you recommend testing them?
> (Will the server side need to run on real hardware?)

I have been testing nfsd on the host and nfs client in a virtual
machine.  Vice versa should work in the same way.

It's also possible to run nfsd in VM #1 and nfs client in VM #2 and use
the netcat-like utility on the host to forward the traffic.  That way
any kernel panic happens in a VM and doesn't bring down the machine.
I'll probably begin using this approach when I start nfsd work.

> I guess if it works then the main question is whether it's worth
> supporting another transport type in order to get the zero-configuration
> host<->guest NFS setup.  Or whether there's another way to get the same
> gains.

Thanks!  If anyone has suggestions to avoid adding the AF_VSOCK
transport I'd be interested to learn about that.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]