From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46024 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsG0B-0002fz-9G for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:47:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsG08-0007cA-3o for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:47:37 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]:53069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsG07-0007bF-LT for qemu-devel@nongnu.org; Wed, 23 Feb 2011 09:47:36 -0500 From: Arnd Bergmann Subject: Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible? Date: Wed, 23 Feb 2011 15:47:23 +0100 References: <201102211307.38714.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102231547.23804.arnd@arndb.de> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerhard Wiesinger Cc: Jan Kiszka , qemu-devel@nongnu.org On Wednesday 23 February 2011, Gerhard Wiesinger wrote: > After some further tests and looking at the iproute ip and kernel code I > finally gave up because I thing such a setup it is not possible without > breaking up/reconfiguring eth0. When I have to reconfigure eth0 I think a > better approach is to configure a bridge which I finally did and works > well. > > I tried to explain/document the macvtap/macvlan concepts and limitations > below. Please comment on it whether this is true or false. > > macvtap/macvlan driver concepts and limitations: > 1.) macvlan driver adds a MAC address to a lower interface device where > the actual macvlanx device is based on > 2.) macvtap driver is based on macvlan driver and macvtap driver adds > additional functionality of interface <=> external program communication > with stdin/stdout channel. > 3.) Limitations: macvtap/macvlan based devices can only communicate with > childs based on the same lower device (e.g. eth0 in this sample) but not > to the lower device itself, only to the outside world of the interface Correct. > finally this makes the macvlan/macvtap approach useless because main eth0 > interface must still be broken in the chain and reconfigured which was > against the requirements that eth0 should not be touched and reconfigured! Yes, that is unfortunate, but it's the same that you'd get with a bridge device: When you have a bridge on top of eth0, you can no longer assign an IP address to eth0 and let it communicate with the virtual ports on the bridge. You need to instead set the IP address on the bridge itself. Macvlan is slightly better because it allows you to have multiple host devices that can each have their own MAC/IP address, unlike the bridge, but of course it can not be connected to anything else besides macvlan or macvtap ports. Arnd