Re: [Libguestfs] [PATCH libnbd 2/2] api: Add support for AF_VSOCK.
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