qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl,


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
User-agent: KMail/1.12.2 (Linux/2.6.31-22-generic; KDE/4.3.2; x86_64; ; )

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]