From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N65CT-00010x-Gk for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:28:41 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N65CO-0000uk-J4 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:28:40 -0500 Received: from [199.232.76.173] (port=43072 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N65CO-0000uV-4o for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:28:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24374) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N65CN-0000Dk-CS for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:28:35 -0500 Message-ID: <4AF2FD2C.9020602@redhat.com> Date: Thu, 05 Nov 2009 18:28:28 +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> <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> In-Reply-To: <4AF2FAFC.9050606@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 , Dustin Kirkland , Juan Quintela , qemu-devel@nongnu.org, Michael Tsirkin On 11/05/2009 06:19 PM, 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. I meant system as in outside the scope of a single VM. VNC authentication is for a single VM. Determining who is allowed to bridge where is system-wide functionality. > > 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. guest-specific ebtables rules traffic control / QoS statistics on the tap interface vlan encapsulation selinux labelling (if that makes sense) > >>> 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. Fine, but fix it where it's broken, not in qemu. Configuring a tap is not rocket science, it's just 200 lines. >>> 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. How, through the qemu monitor? >> >> 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? > Because each will need to do something slightly different. -- error compiling committee.c: too many arguments to function