From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N659y-0007OX-Um for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:26:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N659u-0007Kq-6K for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:26:06 -0500 Received: from [199.232.76.173] (port=33794 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N659t-0007Kj-NX for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:26:01 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:51407) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N659t-0008HN-C3 for qemu-devel@nongnu.org; Thu, 05 Nov 2009 11:26:01 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA5GNQFR021073 for ; Thu, 5 Nov 2009 09:23:26 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id nA5GPoNf018698 for ; Thu, 5 Nov 2009 09:25:52 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA5AMn81009554 for ; Thu, 5 Nov 2009 03:22:49 -0700 Message-ID: <4AF2FC88.5030303@us.ibm.com> Date: Thu, 05 Nov 2009 10:25:44 -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> <4AF2E7CE.8010506@us.ibm.com> <4AF2EB17.8090202@redhat.com> <4AF2F7E9.50300@us.ibm.com> <4AF2FA2A.4060500@redhat.com> In-Reply-To: <4AF2FA2A.4060500@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: >> That's short sighted. If we just focus on "making a guest work" >> we'll end up with crappy interfaces that cripple management tools. > > Only with management tools that cripple themselves. It's pretty easy > to get unprivileged bridging with -net tap; it's just that libvirt > hadn't gotten around to it yet -- see Dan's comment. Are you going to > take on every libvirt deficiency and push it into qemu? No, but I'd like avoid forcing management tools to introduce these deficiencies in the first place. >> If users are constantly struggling to do even the simplest things >> with qemu, then it doesn't matter how well our "guest works". No one >> will use it. > > That's not the case today, even with virt-manager. I'm not going to pick on any particular tool, but kvm absolutely has a reputation of being difficult to use compared to other virtualization software out there. Nothing else requires modifying configuration files just to get a guest with bridged networking. >> I think we absolutely have to think about the full stack and how all >> the pieces interact. There are definitely problems in the stack >> right now. Security is the one I'm trying to address in this >> series. If you cannot launch a reasonable configured qemu from the >> command line as an unprivileged user, there's really no hope that we >> can expect a management tool to do that. > > I'm almost offended on Dan's behalf. We'll I guess it's about perspectives then. I don't see the fact that libvirt runs qemu as root as a libvirt deficiency. I see it as a qemu deficiency. >> Again, there are no shortage of existence proofs of this (beyond >> libvirt). I suspect there isn't a management tool out there that >> does the right thing today. > > RHEV-H launches guests as unprivileged users; the management daemon is > also unprivileged. I suspected as much based on how strongly you were advocating this. I think my point still stands though, there's an awful lot of management software out there that gets it wrong. It's great that you guys got it right but so far, the majority of users are not using qemu through RHEV-M so I still think we have a problem. Regards, Anthony Liguori -- Regards, Anthony Liguori