On Tue, Mar 04, 2025 at 04:06:02PM -0800, Bobby Eshleman wrote:
On Thu, Jan 16, 2020 at 06:24:25PM +0100, Stefano Garzarella wrote:
RFC -> v1:
* added 'netns' module param to vsock.ko to enable the
network namespace support (disabled by default)
* added 'vsock_net_eq()' to check the "net" assigned to a socket
only when 'netns' support is enabled
RFC: https://patchwork.ozlabs.org/cover/1202235/
Now that we have multi-transport upstream, I started to take a look to
support network namespace in vsock.
As we partially discussed in the multi-transport proposal [1], 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
This new feature is disabled by default, because it changes vsock's
behavior with network namespaces and could break existing applications.
It can be enabled with the new 'netns' module parameter of vsock.ko.
This implementation provides the following behavior:
- packets received from the host (received by G2H transports) are
assigned to the default netns (init_net)
- packets received from the guest (received by H2G - vhost-vsock) are
assigned to the netns of the process that opens /dev/vhost-vsock
(usually the VMM, qemu in my tests, opens the /dev/vhost-vsock)
- for vmci I need some suggestions, because I don't know how to do
and test the same in the vmci driver, for now vmci uses the
init_net
- loopback packets are exchanged only in the same netns
Hey Stefano,
I recently picked up this series and am hoping to help update it / get
it merged to address a known use case. I have some questions and
thoughts (in other parts of this thread) and would love some
suggestions!
Great!
I already have a local branch with this updated with skbs and using
/dev/vhost-vsock-netns to opt-in the VM as per the discussion in this
thread.
One question: what is the behavior we expect from guest namespaces? In
v2, you mentioned prototyping a /dev/vsock ioctl() to define the
namespace for the virtio-vsock device. This would mean only one
namespace could use vsock in the guest? Do we want to make sure that our
design makes it possible to support multiple namespaces in the future if
the use case arrives?
Yes, I guess it makes sense that multiple namespaces can communicate
with the host and then use the virtio-vsock device!
IIRC, the main use case here was also nested VMs. So a netns could be
used to isolate a nested VM in L1 and it may not need to talk to L0, so
the software in the L1 netns can use vsock, but only to talk to L2.
More questions/comments in other parts of this thread.
Sure, I'm happy to help with this effort with discussions/reviews!
Stefano
