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@xxxxxxxxxxxxxxx. > > > > > > > > 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:
signature.asc
Description: PGP signature
