Re: [PATCH nfs-utils v2 05/12] getport: recognize "vsock" netid

From: Chuck Lever <chuck.lever@oracle.com>
To: NeilBrown <neilb@suse.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Jeff Layton <jlayton@redhat.com>,
	Abbas Naderi <abiusx@google.com>,
	Steve Dickson <steved@redhat.com>
Subject: Re: [PATCH nfs-utils v2 05/12] getport: recognize "vsock" netid
Date: Fri, 7 Jul 2017 00:14:19 -0400	[thread overview]
Message-ID: <00E66803-089E-415C-94E4-D2BEBD37AEF6@oracle.com> (raw)
In-Reply-To: <87wp7lvst9.fsf@notabene.neil.brown.name>

> On Jul 6, 2017, at 11:17 PM, NeilBrown <neilb@suse.com> wrote:
> 
> On Fri, Jun 30 2017, Chuck Lever wrote:
>> 
>> Wouldn't it be nicer if it worked like this:
>> 
>> (guest)$ cat /etc/hosts
>> 129.0.0.2  localhyper
>> (guest)$ mount.nfs localhyper:/export /mnt
>> 
>> And the result was a working NFS mount of the
>> local hypervisor, using whatever NFS version the
>> two both support, with no changes needed to the
>> NFS implementation or the understanding of the
>> system administrator?
> 
> Yes. Yes. Definitely Yes.
> Though I suspect you mean "127.0.0.2", not "129..."??

I meant 129.x.  127.0.0 has well-defined semantics as a
loopback to the same host. The hypervisor is clearly a
network entity that is distinct from the local host.

But maybe you could set up 127.0.0.2, .3 for this purpose?
Someone smarter than me could figure out what is best to
use here. I'm not familiar with all the rules for loopback
and link-local IPv4 addressing.

Loopback is the correct analogy, though. It has predictable
host numbers that can be known in advance, and loopback
networking is set up automatically on a host, without the
need for a physical network interface. These are the stated
goals for vsock.

The benefit for re-using loopback here is that every
application that can speak AF_INET can already use it. For
NFS that means all the traditional features work: rpcbind,
NFSv4.0 callback, IP-based share access control, and Kerberos,
and especially DNS so that you can mount by hostname.

> There must be some way to redirect TCP connections to some address
> transparently through to the vsock protocol.
> The "sshuttle" program does this to transparently forward TCP connections
> over an ssh connection.  Using a similar technique to forward
> connections over vsock shouldn't be hard.
> 
> Or is performance really critical, and you get too much copying when you
> try forwarding connections?  I suspect that is fixable, but it would be
> a little less straight forward.
> 
> I would really *not* like to see vsock support being bolted into one
> network tool after another.

--
Chuck Lever