From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N65Kg-0003Ag-E7 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:37:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N65Kb-00033y-GT for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:37:09 -0500 Received: from [199.232.76.173] (port=54193 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N65Kb-00033k-9S for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:37:05 -0500 Received: from mail2.shareable.org ([80.68.89.115]:60776) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N65Ka-0001TY-Qf for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:37:05 -0500 Date: Thu, 5 Nov 2009 16:37:02 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu Message-ID: <20091105163702.GC21630@shareable.org> References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <4AF2E247.3090409@redhat.com> <4AF2E2E3.1030600@redhat.com> <4AF2E638.8050302@us.ibm.com> <4AF2E9CA.4060008@redhat.com> <4AF2F449.6040308@us.ibm.com> <4AF2F700.90605@redhat.com> <4AF2FAFC.9050606@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF2FAFC.9050606@us.ibm.com> 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 , Avi Kivity Anthony Liguori wrote: > Avi Kivity wrote: > >No, of course not, I use qemu from the command line and would benefit > >from -net bridge. My badly-conveyed objection is that qemu should not > >take a system management role (and enforce system-wide policies) but > >leave that to system management tools. > > I do not consider this system management functional no more than I see > providing a global configuration file as system management functional. > They are both mechanisms. The ACL file is a mechanism just like VNC > sasl ACLs are a mechanism. That's why I would like there to be options to either pass to the helper program, or specify a different helper program. (Sorry if that's already in the patches - for some reason I received 0/4 but didn't receive the 4 patch emails). There's no need for QEMU to be cleverer than that, and that puts the whole policy in the hands of the user - where it should be. It'd still install the default helper you've provided and use it by default, of course. > The only other configuration I've seen with a tap device is to directly > configure an ip address with it and not use a bridge at all. That's > covered by -net tap though and really is not all that useful except for > benchmarking. Contrarily, it's incredibly useful! Most of my server VMs uses the tap device without a bridge. They are on private subnets within the host, and use iptables NAT to access the outside world, with NAT port forwarding to offer specific services. That isolates them securely far more effectively than bridging, and the iptables is simpler too. -- Jamie