From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5hNd-0006Ml-F6 for qemu-devel@nongnu.org; Wed, 04 Nov 2009 10:02:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5hNY-0006Iw-6n for qemu-devel@nongnu.org; Wed, 04 Nov 2009 10:02:36 -0500 Received: from [199.232.76.173] (port=47676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5hNY-0006Im-28 for qemu-devel@nongnu.org; Wed, 04 Nov 2009 10:02:32 -0500 Received: from cantor2.suse.de ([195.135.220.15]:55934 helo=mx2.suse.de) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N5hNX-0005C4-CF for qemu-devel@nongnu.org; Wed, 04 Nov 2009 10:02:31 -0500 Message-ID: <4AF19785.2040800@suse.de> Date: Wed, 04 Nov 2009 16:02:29 +0100 From: Alexander Graf 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> <5F92BA13-77B1-4BAB-B009-F0D864D0C4CB@suse.de> <4AF192C7.5040709@codemonkey.ws> In-Reply-To: <4AF192C7.5040709@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 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 , Michael Tsirkin , Juan Quintela , qemu-devel@nongnu.org Anthony Liguori wrote: > Alexander Graf wrote: >> Yeah. Worse than the "run as root" part is the "it's hard" part >> though. I hate how I feel when I try to explain someone how to use >> non-slirp networking :-(. >> >> The response to that is then usually "oh whatever, it's too >> complicated anyways". > > I agree and it's a problem I would like to solve too. > >>> And assuming a bridge is defined named qemubr0 and the administrator >>> has setup >>> permissions accordingly, it will Just Work. My hope is that >>> distributions will >>> do this work as part of the qemu packaging process such that for >>> most users, >>> the out-of-the-box experience will also Just Work. >> >> Yeah, that won't work as easily. >> >> When your customer has 2 NICs this will already break. But let's >> imagine we only have a single NIC. >> >> So that NIC is a wifi card. When I set up the qemubr0 bridge for that >> one now, how does network manager configure my wifi access? It can't >> use the bridge device, as that doesn't have wifi extensions. It also >> can't use the wifi device, because setting up networking on that will >> break. >> >> IMHO the only customer friendly choice I see is the ugly way. The way >> VMware and Vbox do it. >> To make it a bit less ugly, maybe we could create some way to "glue" >> a tap device and an eth together, the same way the bridge code does, >> just without the extra device. > > I don't think that helps either. At the end of the day, this is > really a policy decision. You want to expose the subset of > functionality that the majority of your users require. Inevitably, > you'll leave some users who need more complex setups on their own. > > For instance, users with one NIC are certainly common. Two or more > NICs are also pretty common. But what about people that require > guests to be on separate VLANs? > > This is where management tools come in. When running qemu by hand, > the management tool is the distro more or less as they will be > choosing the default policies. What we need to think about is how to > make sure we can seamlessly integrate with whatever policies they want > to implement. > > I think the one thing we could add is a configurable message to print > when a user tries to use a bridge that isn't configured yet. For > instance, if a user runs qemu without a bridge setup, what would be > nice is the following: > > $ qemu -net bridge -net nic -hda ~/images/linux.img > qemu: error running bridge helper > > You currently do not have 'qemubr0' configured. To setup qemubr0, run > (as root): > zypper install qemu-network-setup > qemu-network-setup qemubr0 > > $ sudo qemu-network-setup > Which interface do you want to configure [qemubr0]: qemubr0 > Do you want to configure qemubr0 as NAT or Bridge [NAT]: Bridge > Which physical interface do you want to bridge qemubr0 to [eth0]: eth0 > qemubr0 is now configured. > > I expect that this is going to be different for every distro. netcf > my make this easier but for now, I think this is the most realistic > approach. Well I'm not that familiar with the bridging stuff as I'm rather scared by it myself, but last time I tried if I # brctl addif br0 eth0 # ifconfig br0 up eth0 stopped working, so I had to stop network manager, assign an IP to br0 manually and hope network manager doesn't kick in again. I don't see how we can solve that easily, as most people will want to use NM. Alex