From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N653T-0003NY-FG for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:19:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N653N-0003K8-Vm for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:19:22 -0500 Received: from [199.232.76.173] (port=33595 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N653N-0003K4-ON for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:19:17 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:51856) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N653N-0007LT-Ai for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:19:17 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA5GDBgU028635 for ; Thu, 5 Nov 2009 09:13:11 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA5GJAxM103486 for ; Thu, 5 Nov 2009 09:19:12 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA5GJ9eZ029256 for ; Thu, 5 Nov 2009 09:19:10 -0700 Message-ID: <4AF2FAFC.9050606@us.ibm.com> Date: Thu, 05 Nov 2009 10:19:08 -0600 From: Anthony Liguori 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> <4AF2E2E3.1030600@redhat.com> <4AF2E638.8050302@us.ibm.com> <4AF2E9CA.4060008@redhat.com> <4AF2F449.6040308@us.ibm.com> <4AF2F700.90605@redhat.com> In-Reply-To: <4AF2F700.90605@redhat.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: Avi Kivity Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin 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. A policy decides how group a bunch of mechanisms together into a higher level thing that's hopefully easier to understand/manage. > Of course, -net bridge doesn't prevent the management stack from doing > management itself (and using -net tap,fd=), but as can be seen from > Dan Berrange's response, -net bridge might encourage them into > laziness; then we're on the slippery slope of adding more features to > -net bridge because libvirt depends on it. Do you really want to add > selinux labelling (whatever that is) to qemu? If you're real concern is that we're implementing a policy of 'ifconfig $tap 0.0.0.0 up && brctl addif $bridge $tap', then I certainly can understand where you're coming from. However, I think you're wrong to think of that as a policy. I've seen many exotic network configurations over the years and I've never seen anyone do anything other than that with a tap device. It really doesn't make sense to do anything more than that. 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. >> I strongly disagree with the way you separate users who use >> management software from people who invoke qemu directly. libvirt >> and virt-manager are existence proofs that management software >> heavily relies on the defaults and mechanisms we establish within qemu. > > So you say, if someone makes a wrong decision, we should fix it by > making the decision ourselves? > > -net bridge will only dig them deeper into qemu defaults. I'm suggesting we should get off our ivory tower claiming that management tools should do a better job than they are today and proactively make it easier for them to do the right thing. We've always touted the improvement of security that qemu/kvm bridges because it allows a guest to run as an unprivileged user. But this is chart-ware because it's simply not the case today. >> We can say all we want about how management software should do things >> but the best way is to make it easy for them to do the right thing. > > Except it's not the right thing, at least not completely. Creating > the tap and attaching it to a bridge is just a part of configuring > networking. You're making it easy to do that part and impossible to > do the rest. What is impossible to do with -net bridge? Certainly, you can still capture the network interface very easily. You can also still program ebtables rules as it's trivial to discover the name of the network device. > > Perhaps the same patchset, but to libvirt-devel, would be more useful > since they can then add any extra features without burdening qemu. Except why limit this functionality to libvirt when it's useful to all management tools? -- Regards, Anthony Liguori