On Wed, 5 Mar 2025 at 08:32, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> On Thu, Jan 16, 2020 at 06:24:26PM +0100, Stefano Garzarella wrote:
> > This patch adds a check of the "net" assigned to a socket during
> > the vsock_find_bound_socket() and vsock_find_connected_socket()
> > to support network namespace, allowing to share the same address
> > (cid, port) across different network namespaces.
> >
> > This patch adds 'netns' module param to enable this new feature
> > (disabled by default), because it changes vsock's behavior with
> > network namespaces and could break existing applications.
> > G2H transports will use the default network namepsace (init_net).
> > H2G transports can use different network namespace for different
> > VMs.
>
>
> I'm not sure I understand the usecase. Can you explain a bit more,
> please?
It's been five years, but I'm trying!
We are tracking this RFE here [1].
I also add Jakub in the thread with who I discussed last year a possible
restart of this effort, he could add more use cases.
The problem with vsock, host-side, currently is that if you launch a VM
with a virtio-vsock device (using vhost) inside a container (e.g.,
Kata), so inside a network namespace, it is reachable from any other
container, whereas they would like some isolation. Also the CID is
shared among all, while they would like to reuse the same CID in
different namespaces.
This has been partially solved with vhost-user-vsock, but it is
inconvenient to use sometimes because of the hybrid-vsock problem
(host-side vsock is remapped to AF_UNIX).
Something from the cover letter of the series [2]:
As we partially discussed in the multi-transport proposal, it could
be nice to support network namespace in vsock to reach the following
goals:
- isolate host applications from guest applications using the same ports
with CID_ANY
- assign the same CID of VMs running in different network namespaces
- partition VMs between VMMs or at finer granularity
Thanks,
Stefano
[1] https://gitlab.com/vsock/vsock/-/issues/2
[2] https://lore.kernel.org/virtualization/20200116172428.311437-1-sgarzare@xxxxxxxxxx/
