From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N5h42-00041I-SF for qemu-devel@nongnu.org; Wed, 04 Nov 2009 09:42:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N5h3y-0003xl-45 for qemu-devel@nongnu.org; Wed, 04 Nov 2009 09:42:22 -0500 Received: from [199.232.76.173] (port=40418 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N5h3x-0003xg-TO for qemu-devel@nongnu.org; Wed, 04 Nov 2009 09:42:17 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:49528) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N5h3x-0001KX-DP for qemu-devel@nongnu.org; Wed, 04 Nov 2009 09:42:17 -0500 Received: by yxe26 with SMTP id 26so6325211yxe.4 for ; Wed, 04 Nov 2009 06:42:16 -0800 (PST) Message-ID: <4AF192C7.5040709@codemonkey.ws> Date: Wed, 04 Nov 2009 08:42:15 -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> <5F92BA13-77B1-4BAB-B009-F0D864D0C4CB@suse.de> In-Reply-To: <5F92BA13-77B1-4BAB-B009-F0D864D0C4CB@suse.de> 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: Alexander Graf Cc: Mark McLoughlin , Arnd Bergmann , Dustin Kirkland , Michael Tsirkin , Juan Quintela , qemu-devel@nongnu.org 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. Regards, Anthony Liguori