| Message ID | 20191128171519.203979-1-sgarzare@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | vsock: support network namespace | expand |
On Thu, Nov 28, 2019 at 06:15:16PM +0100, Stefano Garzarella wrote: > Hi, > now that we have multi-transport upstream, I started to take a look to > support network namespace (netns) 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 preliminary 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 > > Questions: > 1. Should we make configurable the netns (now it is init_net) where > packets from the host should be delivered? Yes, it should be possible to have multiple G2H (e.g. virtio-vsock) devices and to assign them to different net namespaces. Something like net/core/dev.c:dev_change_net_namespace() will eventually be needed. > 2. Should we provide an ioctl in vhost-vsock to configure the netns > to use? (instead of using the netns of the process that opens > /dev/vhost-vsock) Creating the vhost-vsock instance in the process' net namespace makes sense. Maybe wait for a use case before adding an ioctl. > 3. Should we provide a way to disable the netns support in vsock? The code should follow CONFIG_NET_NS semantics. I'm not sure what they are exactly since struct net is always defined, regardless of whether network namespaces are enabled.
On Tue, Dec 03, 2019 at 09:26:49AM +0000, Stefan Hajnoczi wrote: > On Thu, Nov 28, 2019 at 06:15:16PM +0100, Stefano Garzarella wrote: > > Hi, > > now that we have multi-transport upstream, I started to take a look to > > support network namespace (netns) 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 preliminary 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 > > > > Questions: > > 1. Should we make configurable the netns (now it is init_net) where > > packets from the host should be delivered? > > Yes, it should be possible to have multiple G2H (e.g. virtio-vsock) > devices and to assign them to different net namespaces. Something like > net/core/dev.c:dev_change_net_namespace() will eventually be needed. > Make sense, but for now we support only one G2H. How we can provide this feature to the userspace? Should we interface vsock with ip-link(8)? I don't know if initially we can provide through sysfs a way to set the netns of the only G2H loaded. > > 2. Should we provide an ioctl in vhost-vsock to configure the netns > > to use? (instead of using the netns of the process that opens > > /dev/vhost-vsock) > > Creating the vhost-vsock instance in the process' net namespace makes > sense. Maybe wait for a use case before adding an ioctl. > Agree. > > 3. Should we provide a way to disable the netns support in vsock? > > The code should follow CONFIG_NET_NS semantics. I'm not sure what they > are exactly since struct net is always defined, regardless of whether > network namespaces are enabled. I think that if CONFIG_NET_NS is not defined, all sockets and processes are assigned to init_net and this RFC should work in this case, but I'll try this case before v1. I was thinking about the Kata's use case, I don't know if they launch the VM in a netns and even the runtime in the host runs inside the same netns. I'll send an e-mail to kata mailing list. Thanks, Stefano
Hi, now that we have multi-transport upstream, I started to take a look to support network namespace (netns) 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 preliminary 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 Questions: 1. Should we make configurable the netns (now it is init_net) where packets from the host should be delivered? 2. Should we provide an ioctl in vhost-vsock to configure the netns to use? (instead of using the netns of the process that opens /dev/vhost-vsock) 3. Should we provide a way to disable the netns support in vsock? 4. Jorgen: Do you think can be useful support it in vmci host driver? I tested the series in this way: l0_host$ qemu-system-x86_64 -m 4G -M accel=kvm -smp 4 \ -drive file=/tmp/vsockvm0.img,if=virtio --nographic \ -device vhost-vsock-pci,guest-cid=3 l1_vm$ ip netns add ns1 l1_vm$ ip netns add ns2 # same CID on different netns l1_vm$ ip netns exec ns1 qemu-system-x86_64 -m 1G -M accel=kvm -smp 2 \ -drive file=/tmp/vsockvm1.img,if=virtio --nographic \ -device vhost-vsock-pci,guest-cid=4 l1_vm$ ip netns exec ns2 qemu-system-x86_64 -m 1G -M accel=kvm -smp 2 \ -drive file=/tmp/vsockvm2.img,if=virtio --nographic \ -device vhost-vsock-pci,guest-cid=4 # all iperf3 listen on CID_ANY and port 5201, but in different netns l1_vm$ ./iperf3 --vsock -s # connection from l0 or guests started # on default netns (init_net) l1_vm$ ip netns exec ns1 ./iperf3 --vsock -s l1_vm$ ip netns exec ns1 ./iperf3 --vsock -s l0_host$ ./iperf3 --vsock -c 3 l2_vm1$ ./iperf3 --vsock -c 2 l2_vm2$ ./iperf3 --vsock -c 2 This series is on top of the vsock-loopback series (not yet merged), and it is available in the Git repository at: git://github.com/stefano-garzarella/linux.git vsock-netns Any comments are really appreciated! Thanks, Stefano [1] https://www.spinics.net/lists/netdev/msg575792.html Stefano Garzarella (3): vsock: add network namespace support vsock/virtio_transport_common: handle netns of received packets vhost/vsock: use netns of process that opens the vhost-vsock device drivers/vhost/vsock.c | 29 ++++++++++++++++------- include/linux/virtio_vsock.h | 2 ++ include/net/af_vsock.h | 6 +++-- net/vmw_vsock/af_vsock.c | 31 ++++++++++++++++++------- net/vmw_vsock/hyperv_transport.c | 5 ++-- net/vmw_vsock/virtio_transport.c | 2 ++ net/vmw_vsock/virtio_transport_common.c | 12 ++++++++-- net/vmw_vsock/vmci_transport.c | 5 ++-- 8 files changed, 67 insertions(+), 25 deletions(-)