From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Hajnoczi Subject: Re: AF_VSOCK network namespace support Date: Tue, 29 Nov 2016 15:09:45 +0000 Message-ID: <20161129150945.GE1300@stefanha-x1.localdomain> References: <20161123145535.GA16465@stefanha-x1.localdomain> <4DA0F029-EE07-4E51-879C-2033D1F8AFCD@vmware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Cc: "netdev@vger.kernel.org" , "imbrenda@linux.vnet.ibm.com" To: "Jorgen S. Hansen" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41674 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933638AbcK2PJs (ORCPT ); Tue, 29 Nov 2016 10:09:48 -0500 Content-Disposition: inline In-Reply-To: <4DA0F029-EE07-4E51-879C-2033D1F8AFCD@vmware.com> Sender: netdev-owner@vger.kernel.org List-ID: --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2016 at 03:24:36PM +0000, Jorgen S. Hansen wrote: > > On Nov 23, 2016, at 3:55 PM, Stefan Hajnoczi wrot= e: > >=20 > > Hi Jorgen, > > There are two use cases where network namespace support in AF_VSOCK > > could be useful: > >=20 > > 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. >=20 > VMCI based AF_VSOCK relies on the VMCI driver for nested virtualization s= upport. The VMCI driver is a combined host/guest driver with a routing comp= onent, that will either direct traffic to VMs managed by the host =E2=80=9C= personality=E2=80=9D of the driver, or to the outer host. So any VMCI drive= r driver is able to function simultaneously as both a guest and a host driv= er - exactly to be able to support nested virtualization. >=20 > 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 o= ut 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. >=20 > 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. >=20 > If the goal is to provide fine grained service access control, won=E2=80= =99t 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 thro= ugh 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 li= ke a better fit. Also, in the multi tenancy case, isolating the other AFs i= s 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 --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJYPZo5AAoJEJykq7OBq3PImioIAIhNp30g1aLzCQ7d3uZvuykT Txn7f7vGJm0Mc1sJFHCvCpEZx8YxC5v/W8i5202dos37xaEZzyKWGEaUT9gdVPCM 9xTLIJhip0vqw1G5WFgPrRh5bFqU/PS4P7yteAXTutSWouVq+3ozAL0d+HyUjheK 6pbkWeF+S5h8xT4RowopOzCYvFDSRcjDr0E/QuOKBarmrGU4lcyaRnq6neQjFAD5 Av+Iz1njV0A7YswpYmsG/xYkkkopr/3Etvy1sZZRdzkm0sFiivDgo0mqgKWKPpEw rzYk2BsQbw9rb41vr63BOH994z0DokmAc11sCgd/Tt6LwrSe1/8UPLnTu4PeYUk= =/l7R -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad--