[Libguestfs] [PATCH libnbd 2/2] api: Add support for AF_VSOCK.

[Eric Blake]

On 10/18/19 10:39 AM, Richard W.M. Jones wrote:
> This adds a new API for connecting to AF_VSOCK protocol
> (https://wiki.qemu.org/Features/VirtioVsock).
> 
> For example:
> 
>    nbd_connect_vsock (nbd, 2, 10809);
> 
> There is no test of this feature because it only works between guest
> and host.  You cannot start a server and client on the host and talk
> between them, which is what we'd need to write a sane test.
> ---

> @@ -357,6 +366,23 @@ main (int argc, char *argv[])
>         exit (EXIT_FAILURE);
>       }
>       break;
> +
> +  case MODE_VSOCK:
> +    if (sscanf (argv[optind], "%" SCNu32, &cid) != 1) {

sscanf() can't detect overflow ;(

> +++ b/generator/generator

> +  "connect_vsock", {
> +    default_call with
> +    args = [ UInt32 "cid"; UInt32 "port" ]; ret = RErr;
> +    permitted_states = [ Created ];
> +    shortdesc = "connect to NBD server over AF_VSOCK protocol";
> +    longdesc = "\
> +Connect (synchronously) over the C<AF_VSOCK> protocol from a
> +virtual machine to an NBD server, usually running on the host.  The
> +C<cid> and C<port> parameters specify the server address.  Usually
> +C<cid> should be C<2> (to connect to the host), and C<port> might be
> +C<10809> or another port number assigned to you by the host
> +administrator.  This call returns when the connection has been made.";

You mentioned that right now, nbdkit has to be server on host, and 
libnbd is client on guest.  But if we can let nbdkit specify a cid, 
doesn't this mean we can run nbdkit as server in guest, and then connect 
libnbd as client on host?  Then add 'nbdkit nbd vsock=...' to let the 
nbdkit pass-through wrapper convert vsock from guest into TCP or Unix 
socket on the host to other host clients that don't know how to do vsock.


> @@ -2793,6 +2836,8 @@ let first_version = [
>     "aio_connect_systemd_socket_activation", (1, 2);
>     "connect_socket", (1, 2);
>     "aio_connect_socket", (1, 2);
> +  "connect_vsock", (1, 2);
> +  "aio_connect_vsock", (1, 2);
>   

As this is Linux-only (and for that matter, depends on kernel vsock 
support), we probably need "supports_vsock" as an additional function.

> +++ b/generator/states-connect.c
> @@ -37,6 +37,10 @@
>   #include <sys/socket.h>
>   #include <sys/un.h>
>   
> +#ifdef HAVE_LINUX_VM_SOCKETS_H
> +#include <linux/vm_sockets.h>
> +#endif
> +
>   /* Disable Nagle's algorithm on the socket, but don't fail. */
>   static void
>   disable_nagle (int sock)
> @@ -118,6 +122,24 @@ STATE_MACHINE {
>     SET_NEXT_STATE (%^CONNECT.START);
>     return 0;
>   
> + CONNECT_VSOCK.START:
> +#ifdef AF_VSOCK
> +  struct sockaddr_vm svm = {
> +    .svm_family = AF_VSOCK,
> +    .svm_cid = h->svm_cid,
> +    .svm_port = h->svm_port,
> +  };

Are there scenarios (mismatch in kernel vs. headers compiled against, 
for instance) where compilation says AF_VSOCK exists but where all 
attempts at vsock fail?  If so, is there anything that we should check 
dynamically, rather than just compile-time presence of AF_VSOCK?  But if 
nothing else, having:

int
libnbd_internal_supports_vsock(struct nbd_handle*h)
{
#ifdef AF_VSOCK
   return 1;
#else
   return 0;
}

is worth having.

Otherwise, the idea is pretty cool!

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org