[PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Stefan Hajnoczi]

The AF_VSOCK address family allows virtual machines to communicate with the
hypervisor using a zero-configuration transport.  Both KVM and VMware
hypervisors support AF_VSOCK and it was introduced in Linux 3.9.

This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
the kernel NFS client patches that I am also posting to
linux-nfs@vger.kernel.org.

NFS over AF_VSOCK is useful for file system sharing between a virtual machine
and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
transparent to the user and more robust than asking the user to set up NFS over
TCP/IP.

A file system from the host (hypervisor) can be mounted inside a virtual
machine over AF_VSOCK like this:

  (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock

The VM's cid (address) is 3 and the hypervisor is 2.

For testing it's easiest to tunnel AF_VSOCK to the AF_INET nfsd on the host.
The following utility can do this:
https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c

  (host)# nc-vsock -l 2049 -t 127.0.0.1 2049

I will post nfsd patches for both the kernel and nfs-utils once they are
complete.

Alternatively you can use nfs-ganesha's AF_VSOCK support to run a native
AF_VSOCK server.

Note that this patch series relies on the AF_VSOCK getaddrinfo(3) support I
recently posted to glibc:
https://patchwork.ozlabs.org/patch/676589/

Stefan Hajnoczi (4):
  mount: don't use IPPROTO_UDP for address resolution
  mount: present AF_VSOCK addresses
  mount: accept AF_VSOCK in nfs_verify_family()
  getport: recognize "vsock" netid

 support/nfs/getport.c | 16 ++++++++++++----
 utils/mount/network.c | 10 +++++++++-
 utils/mount/stropts.c |  4 +---
 3 files changed, 22 insertions(+), 8 deletions(-)

-- 
2.7.4

[PATCH 1/4] mount: don't use IPPROTO_UDP for address resolution

[Stefan Hajnoczi]

Although getaddrinfo(3) with IPPROTO_UDP works fine for AF_INET and
AF_INET6, the AF_VSOCK address family does not support IPPROTO_UDP and
produces an error.

Drop IPPROTO_UDP and use the 0 default (TCP) which works for all address
families.  Modern NFS uses TCP anyway so it's strange to specify UDP.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 utils/mount/stropts.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index d5dfb5e..ab2d37b 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -885,9 +885,7 @@ static int nfs_try_mount(struct nfsmount_info *mi)
 	int result = 0;
 
 	if (mi->address == NULL) {
-		struct addrinfo hint = {
-			.ai_protocol	= (int)IPPROTO_UDP,
-		};
+		struct addrinfo hint = {};
 		int error;
 		struct addrinfo *address;
 
-- 
2.7.4

Re: [PATCH 1/4] mount: don't use IPPROTO_UDP for address resolution

[Jeff Layton]

On Fri, 2016-10-07 at 11:01 +0100, Stefan Hajnoczi wrote:
> Although getaddrinfo(3) with IPPROTO_UDP works fine for AF_INET and
> AF_INET6, the AF_VSOCK address family does not support IPPROTO_UDP and
> produces an error.
> 
> Drop IPPROTO_UDP and use the 0 default (TCP) which works for all address
> families.  Modern NFS uses TCP anyway so it's strange to specify UDP.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
>  utils/mount/stropts.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index d5dfb5e..ab2d37b 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -885,9 +885,7 @@ static int nfs_try_mount(struct nfsmount_info *mi)
>  	int result = 0;
>  
>  	if (mi->address == NULL) {
> -		struct addrinfo hint = {
> -			.ai_protocol	= (int)IPPROTO_UDP,
> -		};
> +		struct addrinfo hint = {};
>  		int error;
>  		struct addrinfo *address;
>  

I think this is ok.

Reviewed-by: Jeff Layton <jlayton@redhat.com>

[PATCH 2/4] mount: present AF_VSOCK addresses

[Stefan Hajnoczi]

Format vsock hosts as "vsock:<cid>" so the addresses can be easily
distinguished from IPv4 and IPv6 addresses.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 utils/mount/network.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/utils/mount/network.c b/utils/mount/network.c
index 7dceb2d..dcc38ca 100644
--- a/utils/mount/network.c
+++ b/utils/mount/network.c
@@ -44,6 +44,8 @@
 #include <rpc/pmap_prot.h>
 #include <rpc/pmap_clnt.h>
 
+#include <linux/vm_sockets.h>
+
 #include "sockaddr.h"
 #include "xcommon.h"
 #include "mount.h"
@@ -324,6 +326,12 @@ int nfs_string_to_sockaddr(const char *address, struct sockaddr *sap,
 int nfs_present_sockaddr(const struct sockaddr *sap, const socklen_t salen,
 			 char *buf, const size_t buflen)
 {
+	if (sap->sa_family == AF_VSOCK) {
+		snprintf(buf, buflen, "vsock:%u",
+			 ((struct sockaddr_vm *)sap)->svm_cid);
+		return 1;
+	}
+
 #ifdef HAVE_GETNAMEINFO
 	int result;
 
-- 
2.7.4

[PATCH 3/4] mount: accept AF_VSOCK in nfs_verify_family()

[Stefan Hajnoczi]

Since AF_VSOCK is now a supported address family it needs to be accepted
by nfs_verify_family().

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 utils/mount/network.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/mount/network.c b/utils/mount/network.c
index dcc38ca..e4c6e1d 100644
--- a/utils/mount/network.c
+++ b/utils/mount/network.c
@@ -1417,7 +1417,7 @@ sa_family_t	config_default_family = AF_INET;
 static int
 nfs_verify_family(sa_family_t family)
 {
-	if (family != AF_INET)
+	if (family != AF_INET && family != AF_VSOCK)
 		return 0;
 
 	return 1;
-- 
2.7.4

[PATCH 4/4] getport: recognize "vsock" netid

[Stefan Hajnoczi]

Neither libtirpc nor getprotobyname(3) know about AF_VSOCK.  For similar
reasons as for "rdma"/"rmda6", translate "vsock" manually in getport.c.

It is now possible to mount a file system from the host (hypervisor)
over AF_VSOCK like this:

  (guest)$ mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock

The VM's cid address is 3 and the hypervisor is 2.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 support/nfs/getport.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/support/nfs/getport.c b/support/nfs/getport.c
index 081594c..0b857af 100644
--- a/support/nfs/getport.c
+++ b/support/nfs/getport.c
@@ -217,8 +217,7 @@ nfs_get_proto(const char *netid, sa_family_t *family, unsigned long *protocol)
 	struct protoent *proto;
 
 	/*
-	 * IANA does not define a protocol number for rdma netids,
-	 * since "rdma" is not an IP protocol.
+	 * IANA does not define protocol numbers for non-IP netids.
 	 */
 	if (strcmp(netid, "rdma") == 0) {
 		*family = AF_INET;
@@ -230,6 +229,11 @@ nfs_get_proto(const char *netid, sa_family_t *family, unsigned long *protocol)
 		*protocol = NFSPROTO_RDMA;
 		return 1;
 	}
+	if (strcmp(netid, "vsock") == 0) {
+		*family = AF_VSOCK;
+		*protocol = 0;
+		return 1;
+	}
 
 	nconf = getnetconfigent(netid);
 	if (nconf == NULL)
@@ -258,14 +262,18 @@ nfs_get_proto(const char *netid, sa_family_t *family, unsigned long *protocol)
 	struct protoent *proto;
 
 	/*
-	 * IANA does not define a protocol number for rdma netids,
-	 * since "rdma" is not an IP protocol.
+	 * IANA does not define protocol numbers for non-IP netids.
 	 */
 	if (strcmp(netid, "rdma") == 0) {
 		*family = AF_INET;
 		*protocol = NFSPROTO_RDMA;
 		return 1;
 	}
+	if (strcmp(netid, "vsock") == 0) {
+		*family = AF_VSOCK;
+		*protocol = 0;
+		return 1;
+	}
 
 	proto = getprotobyname(netid);
 	if (proto == NULL)
-- 
2.7.4

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Steve Dickson]

On 10/07/2016 06:01 AM, Stefan Hajnoczi wrote:
> The AF_VSOCK address family allows virtual machines to communicate with the
> hypervisor using a zero-configuration transport.  Both KVM and VMware
> hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> 
> This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> the kernel NFS client patches that I am also posting to
> linux-nfs@vger.kernel.org.
> 
> NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> transparent to the user and more robust than asking the user to set up NFS over
> TCP/IP.
> 
> A file system from the host (hypervisor) can be mounted inside a virtual
> machine over AF_VSOCK like this:
> 
>   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> 
> The VM's cid (address) is 3 and the hypervisor is 2.
> 
> For testing it's easiest to tunnel AF_VSOCK to the AF_INET nfsd on the host.
> The following utility can do this:
> https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c
> 
>   (host)# nc-vsock -l 2049 -t 127.0.0.1 2049
> 
> I will post nfsd patches for both the kernel and nfs-utils once they are
> complete.
> 
> Alternatively you can use nfs-ganesha's AF_VSOCK support to run a native
> AF_VSOCK server.
> 
> Note that this patch series relies on the AF_VSOCK getaddrinfo(3) support I
> recently posted to glibc:
> https://patchwork.ozlabs.org/patch/676589/
> 
> Stefan Hajnoczi (4):
>   mount: don't use IPPROTO_UDP for address resolution
>   mount: present AF_VSOCK addresses
>   mount: accept AF_VSOCK in nfs_verify_family()
>   getport: recognize "vsock" netid
> 
>  support/nfs/getport.c | 16 ++++++++++++----
>  utils/mount/network.c | 10 +++++++++-
>  utils/mount/stropts.c |  4 +---
>  3 files changed, 22 insertions(+), 8 deletions(-)
> 
My apologies... I did lose track of these... 

Where the kernel patches for the AF_VSOCK support 
accepted??

steved.
 

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Stefan Hajnoczi]

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

On Tue, Jan 03, 2017 at 11:37:58AM -0500, Steve Dickson wrote:
> 
> 
> On 10/07/2016 06:01 AM, Stefan Hajnoczi wrote:
> > The AF_VSOCK address family allows virtual machines to communicate with the
> > hypervisor using a zero-configuration transport.  Both KVM and VMware
> > hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> > 
> > This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> > the kernel NFS client patches that I am also posting to
> > linux-nfs@vger.kernel.org.
> > 
> > NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> > and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> > transparent to the user and more robust than asking the user to set up NFS over
> > TCP/IP.
> > 
> > A file system from the host (hypervisor) can be mounted inside a virtual
> > machine over AF_VSOCK like this:
> > 
> >   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> > 
> > The VM's cid (address) is 3 and the hypervisor is 2.
> > 
> > For testing it's easiest to tunnel AF_VSOCK to the AF_INET nfsd on the host.
> > The following utility can do this:
> > https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c
> > 
> >   (host)# nc-vsock -l 2049 -t 127.0.0.1 2049
> > 
> > I will post nfsd patches for both the kernel and nfs-utils once they are
> > complete.
> > 
> > Alternatively you can use nfs-ganesha's AF_VSOCK support to run a native
> > AF_VSOCK server.
> > 
> > Note that this patch series relies on the AF_VSOCK getaddrinfo(3) support I
> > recently posted to glibc:
> > https://patchwork.ozlabs.org/patch/676589/
> > 
> > Stefan Hajnoczi (4):
> >   mount: don't use IPPROTO_UDP for address resolution
> >   mount: present AF_VSOCK addresses
> >   mount: accept AF_VSOCK in nfs_verify_family()
> >   getport: recognize "vsock" netid
> > 
> >  support/nfs/getport.c | 16 ++++++++++++----
> >  utils/mount/network.c | 10 +++++++++-
> >  utils/mount/stropts.c |  4 +---
> >  3 files changed, 22 insertions(+), 8 deletions(-)
> > 
> My apologies... I did lose track of these... 
> 
> Where the kernel patches for the AF_VSOCK support 
> accepted??

No, they haven't been merged because the discussion was slow (largely my
fault).  I'll send out a new round of kernel and nfs-utils patches with
the latest code soon.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Jeff Layton]

On Fri, 2016-10-07 at 11:01 +0100, Stefan Hajnoczi wrote:
> The AF_VSOCK address family allows virtual machines to communicate with the
> hypervisor using a zero-configuration transport.  Both KVM and VMware
> hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> 
> This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> the kernel NFS client patches that I am also posting to
> linux-nfs@vger.kernel.org.
> 
> NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> transparent to the user and more robust than asking the user to set up NFS over
> TCP/IP.
> 
> A file system from the host (hypervisor) can be mounted inside a virtual
> machine over AF_VSOCK like this:
> 
>   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> 
> The VM's cid (address) is 3 and the hypervisor is 2.
> 

Sorry for the long delay, and I may just not have been keeping up. I'd
like to start taking a look at these patches, but I'm having a hard time
finding much information about how one would use AF_VSOCK in practice.
I'd like to understand the general idea a little more before I go
reviewing code...

If 2 is always the HV's address, then is that documented somewhere?

How are guest addresses determined? Can different guests talk to each
other over vsock?

Are there plans to eventually add some sort of name resolution? (It
might be interesting to put together a NSS module that keeps a list of
running guest hostnames and their vsock addresses).


> For testing it's easiest to tunnel AF_VSOCK to the AF_INET nfsd on the host.
> The following utility can do this:
> https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c
> 
>   (host)# nc-vsock -l 2049 -t 127.0.0.1 2049
> 
> I will post nfsd patches for both the kernel and nfs-utils once they are
> complete.
> 
> Alternatively you can use nfs-ganesha's AF_VSOCK support to run a native
> AF_VSOCK server.
> 
> Note that this patch series relies on the AF_VSOCK getaddrinfo(3) support I
> recently posted to glibc:
> https://patchwork.ozlabs.org/patch/676589/
> 
> Stefan Hajnoczi (4):
>   mount: don't use IPPROTO_UDP for address resolution
>   mount: present AF_VSOCK addresses
>   mount: accept AF_VSOCK in nfs_verify_family()
>   getport: recognize "vsock" netid
> 
>  support/nfs/getport.c | 16 ++++++++++++----
>  utils/mount/network.c | 10 +++++++++-
>  utils/mount/stropts.c |  4 +---
>  3 files changed, 22 insertions(+), 8 deletions(-)
> 

-- 
Jeff Layton <jlayton@redhat.com>

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Stefan Hajnoczi]

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

On Wed, May 17, 2017 at 12:51:31PM -0400, Jeff Layton wrote:
> On Fri, 2016-10-07 at 11:01 +0100, Stefan Hajnoczi wrote:
> > The AF_VSOCK address family allows virtual machines to communicate with the
> > hypervisor using a zero-configuration transport.  Both KVM and VMware
> > hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> > 
> > This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> > the kernel NFS client patches that I am also posting to
> > linux-nfs@vger.kernel.org.
> > 
> > NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> > and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> > transparent to the user and more robust than asking the user to set up NFS over
> > TCP/IP.
> > 
> > A file system from the host (hypervisor) can be mounted inside a virtual
> > machine over AF_VSOCK like this:
> > 
> >   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> > 
> > The VM's cid (address) is 3 and the hypervisor is 2.
> > 
> 
> Sorry for the long delay, and I may just not have been keeping up. I'd
> like to start taking a look at these patches, but I'm having a hard time
> finding much information about how one would use AF_VSOCK in practice.
> I'd like to understand the general idea a little more before I go
> reviewing code...
> 
> If 2 is always the HV's address, then is that documented somewhere?

Yes, it's always the address for the host.  In
/usr/include/linux/vm_sockets.h:

  /* Use this as the destination CID in an address when referring to the host
   * (any process other than the hypervisor).  VMCI relies on it being 2, but
   * this would be useful for other transports too.
   */

  #define VMADDR_CID_HOST 2

VMCI is VMware's AF_VSOCK transport.  virtio-vsock is the VIRTIO
transport for AF_VSOCK (used by KVM).

> How are guest addresses determined?

Guest addresses are assigned before launching a VM.  They are
re-assigned upon live migration (they have host-wide scope, not
datacenter scope).

KVM (QEMU) virtual machines are typically managed using libvirt.
Libvirt support for AF_VSOCK is currently in development and it will
assign addresses to guests.

> Can different guests talk to each other over vsock?

No, for security reasons this is purely host<->guest.  The protocol is
not routable and guest<->guest communication is forbidden.

> Are there plans to eventually add some sort of name resolution? (It
> might be interesting to put together a NSS module that keeps a list of
> running guest hostnames and their vsock addresses).

Not at this time.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Jeff Layton]

On Thu, 2017-05-18 at 13:48 +0100, Stefan Hajnoczi wrote:
> On Wed, May 17, 2017 at 12:51:31PM -0400, Jeff Layton wrote:
> > On Fri, 2016-10-07 at 11:01 +0100, Stefan Hajnoczi wrote:
> > > The AF_VSOCK address family allows virtual machines to communicate with the
> > > hypervisor using a zero-configuration transport.  Both KVM and VMware
> > > hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> > > 
> > > This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> > > the kernel NFS client patches that I am also posting to
> > > linux-nfs@vger.kernel.org.
> > > 
> > > NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> > > and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> > > transparent to the user and more robust than asking the user to set up NFS over
> > > TCP/IP.
> > > 
> > > A file system from the host (hypervisor) can be mounted inside a virtual
> > > machine over AF_VSOCK like this:
> > > 
> > >   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> > > 
> > > The VM's cid (address) is 3 and the hypervisor is 2.
> > > 
> > 
> > Sorry for the long delay, and I may just not have been keeping up. I'd
> > like to start taking a look at these patches, but I'm having a hard time
> > finding much information about how one would use AF_VSOCK in practice.
> > I'd like to understand the general idea a little more before I go
> > reviewing code...
> > 
> > If 2 is always the HV's address, then is that documented somewhere?
> 
> Yes, it's always the address for the host.  In
> /usr/include/linux/vm_sockets.h:
> 
>   /* Use this as the destination CID in an address when referring to the host
>    * (any process other than the hypervisor).  VMCI relies on it being 2, but
>    * this would be useful for other transports too.
>    */
> 
>   #define VMADDR_CID_HOST 2
> 
> VMCI is VMware's AF_VSOCK transport.  virtio-vsock is the VIRTIO
> transport for AF_VSOCK (used by KVM).
> 
> > How are guest addresses determined?
> 
> Guest addresses are assigned before launching a VM.  They are
> re-assigned upon live migration (they have host-wide scope, not
> datacenter scope).
> 
> KVM (QEMU) virtual machines are typically managed using libvirt.
> Libvirt support for AF_VSOCK is currently in development and it will
> assign addresses to guests.
> 

Ok...is there some way for the guest to determine its own cid
programmatically? 

> > Can different guests talk to each other over vsock?
> 
> No, for security reasons this is purely host<->guest.  The protocol is
> not routable and guest<->guest communication is forbidden.
> 

Pity...that seems like it could have made this more useful.

Are there plans to eventually add some sort of name resolution? (It
> > might be interesting to put together a NSS module that keeps a list of
> > running guest hostnames and their vsock addresses).
> 
> Not at this time.

Yeah, not much point in it if it's always between guest and hv.

Ok, so this is really just allows a guest to mount a server running on
the bare metal host os? I guess you could also do it the other way
around too, but that doesn't seem terribly useful.

Other than the reliable way to know what the HV's VSOCK address is,
what's the compelling reason to do this? I guess you might be able to
get more reliable root on NFS with this, but if the server has to be
running on the same physical box then why not present a disk image in
another way and get NFS out of the picture?

Note that AF_VSOCK itself seems quite useful for certain guest->host
communications. I just don't quite grok why I'd want to use this over
vanilla IP networking for NFS as it doesn't seem quite as flexible.
-- 
Jeff Layton <jlayton@redhat.com>

Re: [PATCH 0/4] nfs-utils mount: add AF_VSOCK support

[Stefan Hajnoczi]

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

On Thu, May 18, 2017 at 10:07:34AM -0400, Jeff Layton wrote:
> On Thu, 2017-05-18 at 13:48 +0100, Stefan Hajnoczi wrote:
> > On Wed, May 17, 2017 at 12:51:31PM -0400, Jeff Layton wrote:
> > > On Fri, 2016-10-07 at 11:01 +0100, Stefan Hajnoczi wrote:
> > > > The AF_VSOCK address family allows virtual machines to communicate with the
> > > > hypervisor using a zero-configuration transport.  Both KVM and VMware
> > > > hypervisors support AF_VSOCK and it was introduced in Linux 3.9.
> > > > 
> > > > This patch series adds AF_VSOCK support to mount.nfs(8) and works together with
> > > > the kernel NFS client patches that I am also posting to
> > > > linux-nfs@vger.kernel.org.
> > > > 
> > > > NFS over AF_VSOCK is useful for file system sharing between a virtual machine
> > > > and the host.  Due to the zero-configuration nature of AF_VSOCK this is more
> > > > transparent to the user and more robust than asking the user to set up NFS over
> > > > TCP/IP.
> > > > 
> > > > A file system from the host (hypervisor) can be mounted inside a virtual
> > > > machine over AF_VSOCK like this:
> > > > 
> > > >   (guest)# mount.nfs 2:/export /mnt -v -o clientaddr=3,proto=vsock
> > > > 
> > > > The VM's cid (address) is 3 and the hypervisor is 2.
> > > > 
> > > 
> > > Sorry for the long delay, and I may just not have been keeping up. I'd
> > > like to start taking a look at these patches, but I'm having a hard time
> > > finding much information about how one would use AF_VSOCK in practice.
> > > I'd like to understand the general idea a little more before I go
> > > reviewing code...
> > > 
> > > If 2 is always the HV's address, then is that documented somewhere?
> > 
> > Yes, it's always the address for the host.  In
> > /usr/include/linux/vm_sockets.h:
> > 
> >   /* Use this as the destination CID in an address when referring to the host
> >    * (any process other than the hypervisor).  VMCI relies on it being 2, but
> >    * this would be useful for other transports too.
> >    */
> > 
> >   #define VMADDR_CID_HOST 2
> > 
> > VMCI is VMware's AF_VSOCK transport.  virtio-vsock is the VIRTIO
> > transport for AF_VSOCK (used by KVM).
> > 
> > > How are guest addresses determined?
> > 
> > Guest addresses are assigned before launching a VM.  They are
> > re-assigned upon live migration (they have host-wide scope, not
> > datacenter scope).
> > 
> > KVM (QEMU) virtual machines are typically managed using libvirt.
> > Libvirt support for AF_VSOCK is currently in development and it will
> > assign addresses to guests.
> > 
> 
> Ok...is there some way for the guest to determine its own cid
> programmatically? 

Yes, ioctl(IOCTL_VM_SOCKETS_GET_LOCAL_CID) can be used on an AF_VSOCK
socket to query the local CID but most applications use VMADDR_CID_ANY
instead of specifying their address.

Both IOCTL_VM_SOCKETS_GET_LOCAL_CID and VMADDR_CID_ANY are also defined
in /usr/include/linux/vm_sockets.h.

> Ok, so this is really just allows a guest to mount a server running on
> the bare metal host os? I guess you could also do it the other way
> around too, but that doesn't seem terribly useful.

Right, the host can mount a guest export over AF_VSOCK too.

> Other than the reliable way to know what the HV's VSOCK address is,
> what's the compelling reason to do this? I guess you might be able to
> get more reliable root on NFS with this, but if the server has to be
> running on the same physical box then why not present a disk image in
> another way and get NFS out of the picture?

1. File system as a service in a cloud.  The guest does NFS over
AF_VSOCK.  The host then forwards I/O onto a distributed storage system
like Ceph.  This way the guest doesn't need to be aware of the cloud's
Ceph configuration, details of the Ceph nodes, etc.

2. File sharing use cases.  Disk images can be inconvenient if the files
need to be accessible from both the guest and the host (not necessarily
at the same time).  This is because disk images require special tools
for access (libguestfs or loopback mounting).  Many users would prefer
to just point the guest at a shared directory.

> Note that AF_VSOCK itself seems quite useful for certain guest->host
> communications. I just don't quite grok why I'd want to use this over
> vanilla IP networking for NFS as it doesn't seem quite as flexible.

Vanilla IP networking setup is hard to automate from the host.  The
guest is a black box and its networking configuration (IP subnets,
firewall rules, etc) can change at the behest of the guest
administrator.  An automated approach to setting up an NFS export for
the guest will be unreliable and interfere with the guest's
configuration.

Due to the zero-configuration nature of AF_VSOCK, it's possible to run
NFS without worrying about intefering with the guest's configuration.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]