From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:55824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBsPm-00061X-V9 for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:11:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RBsPl-0001Bp-N2 for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:11:26 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:56828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RBsPl-0001Bj-KL for qemu-devel@nongnu.org; Thu, 06 Oct 2011 14:11:25 -0400 Received: from /spool/local by us.ibm.com with XMail ESMTP for from ; Thu, 6 Oct 2011 14:05:24 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p96I4Qg0193296 for ; Thu, 6 Oct 2011 14:04:27 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p96I4LrB021825 for ; Thu, 6 Oct 2011 12:04:22 -0600 Message-ID: <4E8DEDA5.3050209@us.ibm.com> Date: Thu, 06 Oct 2011 13:04:21 -0500 From: Anthony Liguori 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> In-Reply-To: <20111006164148.GF2450@redhat.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: "Daniel P. Berrange" Cc: Richa Marwaha , coreyb@linux.vnet.ibm.com, qemu-devel@nongnu.org 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. > > 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