From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N654o-0003zw-Qj for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:20:46 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N654j-0003vh-Kb for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:20:45 -0500 Received: from [199.232.76.173] (port=33623 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N654j-0003vc-Ff for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:20:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13734) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N654i-0007Wo-T6 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:20:41 -0500 Message-ID: <4AF2FB52.2090305@redhat.com> Date: Thu, 05 Nov 2009 18:20:34 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <4AF2E247.3090409@redhat.com> <4AF2E7CE.8010506@us.ibm.com> <20091105151154.GF689@redhat.com> <4AF2EBBB.7070605@redhat.com> <4AF2F674.6080205@us.ibm.com> In-Reply-To: <4AF2F674.6080205@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Mark McLoughlin , Arnd Bergmann , Juan Quintela , Dustin Kirkland , qemu-devel@nongnu.org, Michael Tsirkin On 11/05/2009 05:59 PM, Anthony Liguori wrote: > Avi Kivity wrote: >> On 11/05/2009 05:11 PM, Daniel P. Berrange wrote: >>> The main problem is that we've never really used the 'session' >>> instances, >>> since networking configs are rather limited to pretty much just SLIRP >>> and people expect full bridging. I think this patch series you've >>> done is invaluable and will let us finally make full use of the libvirt >>> 'session' instances for desktop virt, running everything unprivileged. >>> >> >> What's to stop you from using the same idea to get a tap fd for the >> unprivileged libvirtd instance? > > Why limit this to just libvirt based management tools? The helper has > to live somewhere, why not have it live in qemu? > Because anything special the management tools wants done (as simple as remembering the interface name so it can collect statistics and associate them with the guest) will render the helper unusable. The helper is pure glue so it will be very hard to generalize. > libvirt can still call it and pass the fd to qemu if it really wants to. Until it needs a new feature, then it goes back to -net tap. -- error compiling committee.c: too many arguments to function