From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6VOJ-00041R-UA for qemu-devel@nongnu.org; Fri, 06 Nov 2009 15:26:40 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6VOF-0003ro-3g for qemu-devel@nongnu.org; Fri, 06 Nov 2009 15:26:39 -0500 Received: from [199.232.76.173] (port=50061 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6VOE-0003rR-RL for qemu-devel@nongnu.org; Fri, 06 Nov 2009 15:26:34 -0500 Received: from mail2.shareable.org ([80.68.89.115]:52638) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1N6VOE-0003vv-Dy for qemu-devel@nongnu.org; Fri, 06 Nov 2009 15:26:34 -0500 Date: Fri, 6 Nov 2009 20:26:29 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 0/4] net-bridge: rootless bridge support for qemu Message-ID: <20091106202629.GB27751@shareable.org> References: <1257294485-27015-1-git-send-email-aliguori@us.ibm.com> <20091105082125.GB5774@redhat.com> <20091106020350.GH21630@shareable.org> <200911061258.51303.arnd@arndb.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911061258.51303.arnd@arndb.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Arnd Bergmann Cc: Mark McLoughlin , Anthony Liguori , Arnd Bergmann , Dustin Kirkland , Juan Quintela , "Michael S. Tsirkin" , qemu-devel@nongnu.org Arnd Bergmann wrote: > On Friday 06 November 2009, Jamie Lokier wrote: > > > > Michael S. Tsirkin wrote: > > > On Thu, Nov 05, 2009 at 04:12:36AM +0000, Jamie Lokier wrote: > > > > I notice that if we eventually teach the kernel to have unnamed > > > > bridges (just attach interfaces to each other), only the helper > > > > commands will need changing to use it :-) > > > > > > What do you mean by "attach interfaces to each other"? > > > Which interfaces do you want to attach to each other? > > > > For example, attaching eth0 to tap0 without having to define br0, > > instead of the current method where you define br0 then attach eth0 > > and tap0 to it, then transfer eth0's IP configuration to br0, then > > tell all the network management tools about it. > > "Attaching" two network interfaces to each other does not work the > way you'd like it to. The tap device is on it's own unless you use > either a bridge or configure IP forwarding, which has another set > of problems. That's why I called it "unnamed bridges". There still needs to be a bridge doing the usual MAC learning, possibly spanning tree, etc. to have the right behaviour. The only trouble is having to configure the local IP settings on the bridge itself, which entails modifying every network configuration tool, every script and so on. Hence the idea of allowing attached physical interfaces to have individual local IP settings, and (perhaps) not bothering with a separate named interface for the bridge, instead just allow brctl to be given a physical interface and instantiate a "slave" bridge which is always attached to that interface and referenced through it. So instead of: brctl addbr br0 brctl addif br0 eth0 # Already inherits MAC from the first attached if. brctl addif br0 tap0 ifconfig br0 1.2.3.4 # Move IP configuration from eth0 to br0 ifconfig eth0 0.0.0.0 You'd do: brctl addif eth0 tap0 Much simpler, and would Just Work with so many more things. It's just configuration sugar really. Underneath there would still be a bridge, using the Linux bridge code, with two interfaces attached. > I posted an experimental 'macvtap' driver a few some time ago that > would allow you to do something like that, i.e. add another logical > interface to an existing eth0 device, with a separate mac address, > and export that as a character device that is compatible with /dev/tun. (That's not as useful as unnamed bridges because it only works with tun devices, but that's not relevant to QEMU/KVM). If the guest contains it's own bridges, or even it's own macvtaps, you need bridge MAC learning (and perhaps STP to avoid cycles) to forward packets efficiently. Otherwise you have to either forward all packets to the guest (won't do that obviously), or some guest configurations just won't work as they'd expect. Of course it's ok if "interesting" guests don't work properly. macvtap can come with documented restrictions (they are a useful form of security anyway), and people can use proper host bridges like they already do for guests who need to behave like they're plugged into the host network properly. But imho it'd be far nicer not to have "specialness" like that unless you want it for some positive reason like security. > I probably need to start that one over from scratch, because I also > want to make it work with vhost-net, and to allow the guest and > the host to communicate with each other. > Note that this would be transparent to qemu, we'd only need a different > helper script to call. Helper scripts are the new management tools I hear ;-) -- Jamie