On Mon, Nov 28, 2016 at 03:24:36PM +0000, Jorgen S. Hansen wrote: > > On Nov 23, 2016, at 3:55 PM, Stefan Hajnoczi <[email protected]> wrote: > > > > Hi Jorgen, > > There are two use cases where network namespace support in AF_VSOCK > > could be useful: > > > > 1. Claudio Imbrenda pointed out that a machine cannot act as both host > > and guest at the same time. This is necessary for nested > > virtualization. Currently only one transport (the host side or the > > guest side) can be registered at a time. > > VMCI based AF_VSOCK relies on the VMCI driver for nested virtualization > support. The VMCI driver is a combined host/guest driver with a routing > component, that will either direct traffic to VMs managed by the host > “personality” of the driver, or to the outer host. So any VMCI driver driver > is able to function simultaneously as both a guest and a host driver - > exactly to be able to support nested virtualization. > > Since, for VMCI based vSocket, the host has a fixed CID (2), any traffic > generated by an application inside a VM destined for CID 2 will be routed out > of the VM (to the host - either a virtual or physical one). Any traffic for a > CID > 2 will be directed towards VMs managed by the host personality of the > VMCI driver. > > Since VMCI predates nested virtualization, the solution above was partly a > result of having to support existing configurations in a transparent way.
Thanks for your reply. It seems like a reasonable solution. We could do something similar for virtio. > > 2. Users may wish to isolate the AF_VSOCK address namespace so that two > > VMs have completely independent CID and ports (they could even use > > the same CID and ports because they're in separate namespaces). This > > ensures that a host service visible to VM1 is not automatically > > visible to VM2. > > If the goal is to provide fine grained service access control, won’t this end > up requiring a namespace per VM? For ESX, we have a mechanism to tag VMs that > allows them to be granted access to a service offered through AF_VSOCK, but > this is not part of the Linux hypervisor. Yes it would and using one network namespace per VM is a bit clumsy because it means IP networking (e.g. for libiscsi or GlusterFS) needs to be configured carefully so that external network connectivity works (using a veth interface). I did think about netfilter support but one of the main reasons for using AF_VSOCK vs Ethernet is to avoid user firewall rules from disrupting hypervisor services :). > If the intent is to be able to support multi tenancy, then this sounds like a > better fit. Also, in the multi tenancy case, isolating the other AFs is > probably what you want as well. Eventually multi-tenancy might be interesting but just fine-grained service access control would be enough for most cases. Stefan
signature.asc
Description: PGP signature
