Re: Hermetic virtio-vsock in QEMU

[Paolo Bonzini <pbonzini@redhat.com>]

On Wed, May 8, 2024 at 2:51 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> Designwise, a native VSOCK backend in QEMU really should implement the
> same approach defined by firecracker, so that we have interoperability
> with systemd, firecracker and cloud-hypervisor. See
>
>   https://gitlab.com/qemu-project/qemu/-/issues/2095
>   https://github.com/firecracker-microvm/firecracker/blob/main/docs/vsock.md#firecracker-virtio-vsock-design
>
> This involves multiple UNIX sockets on the host
>
>   1 * /some/path   - QEMU listens on this, and accepts connections
>                      from other host processes. The client sends
>                      "PORT <num>" to indicate that guest port it
>                      is connecting to
>
>   n * /some/path_$PORT - QEMU connect to this for outgoing connections
>                          from the guest. Other host processes need
>                          to listen on whatever path_$PORT need to be
>                          serviced

The former is quite horrible, but okay. Out of curiosity, which
clients are using that convention?

> IOW, from a CLI pov, QEMU should need nothing more than
>
>     -object vsock-forward,prefix=/some/path

I would call this a "vsock-namespace" object with a matching namespace
property on the virtio-vsock device.  The id on the vsock-namespace
object would also allow 1) adding vsock-forward objects hanging from
the namespace 2) omitting the prefix to only allow specifying
connections via vsock-forward.

I agree that allowing interoperability with existing implementations
is nice to have, at least as a principle.

Paolo