From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBsrs-0003qG-QU for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:40:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBsrr-0006SL-Qy for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:40:28 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:56092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBsrr-0006S6-I4 for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:40:27 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p96IGDVm029480 for ; Thu, 6 Oct 2011 14:16:13 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p96Id6fw219110 for ; Thu, 6 Oct 2011 14:39:06 -0400 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p96Id2le009589 for ; Thu, 6 Oct 2011 12:39:02 -0600 Message-ID: <4E8DF5C0.8080001@linux.vnet.ibm.com> Date: Thu, 06 Oct 2011 14:38:56 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1317915508-15491-1-git-send-email-rmarwah@linux.vnet.ibm.com> <1317915508-15491-2-git-send-email-rmarwah@linux.vnet.ibm.com> <20111006164148.GF2450@redhat.com> <4E8DEDA5.3050209@us.ibm.com> In-Reply-To: <4E8DEDA5.3050209@us.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/4] Add basic version of bridge helper List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Richa Marwaha , qemu-devel@nongnu.org On 10/06/2011 02:04 PM, Anthony Liguori wrote: > On 10/06/2011 11:41 AM, Daniel P. Berrange wrote: >> On Thu, Oct 06, 2011 at 11:38:25AM -0400, Richa Marwaha wrote: >>> This patch adds a helper that can be used to create a tap device >>> attached to >>> a bridge device. Since this helper is minimal in what it does, it can be >>> given CAP_NET_ADMIN which allows qemu to avoid running as root while >>> still >>> satisfying the majority of what users tend to want to do with tap >>> devices. >>> >>> The way this all works is that qemu launches this helper passing a >>> bridge >>> name and the name of an inherited file descriptor. The descriptor is one >>> end of a socketpair() of domain sockets. This domain socket is used to >>> transmit a file descriptor of the opened tap device from the helper >>> to qemu. >>> >>> The helper can then exit and let qemu use the tap device. >> >> When QEMU is run by libvirt, we generally like to use capng to >> remove the ability for QEMU to run setuid programs at all. So >> obviously it will struggle to run the qemu-bridge-helper binary >> in such a scenario. >> >> With the way you transmit the TAP device FD back to the caller, >> it looks like libvirt itself could execute the qemu-bridge-helper >> receiving the FD, and then pass the FD onto QEMU using the >> traditional tap,fd=XX syntax. > > Exactly. This would allow tap-based networking using libvirt session:// > URIs. > I'll take note of this. It seems like it would be a nice future addition to libvirt. A slight tangent, but a point on DAC isolation. The helper enables DAC isolation for qemu:///session but we still need some work in libvirt to provide DAC isolation for qemu:///system. This could be done by allowing management applications to specify custom user/group IDs when creating guests rather than hard coding the IDs in the configuration file. >> >> The TAP device FD is only one FD we normally pass to QEMU. How about >> support for vhost net ? Is it reasonable to ask the qemu-bridge-helper >> to send back a vhost net FD also. > > Absolutely. > >> Or indeed multiple vhost net FDs >> when we get multiqueue NICs. Should we expect the bridge helper to >> be strictly limited to just connecting a TAP dev to a bridge, or is >> the expectation that it will grow more& more functionality over >> time ? > > I would not expect it to do more than create virtual network interfaces, > and add them to bridges. Multiqueue virtual nics, vhost, etc. would all > be in scope as they are part of creating a virtual network interface. > > Creating the bridges and managing the bridges should be done statically > by an administrator and would be out of scope. > > Regards, > > Anthony Liguori > >> >> Daniel > -- Regards, Corey