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

[Jan Kiszka]

On 2011-02-23 07:38, Gerhard Wiesinger wrote:
> On Mon, 21 Feb 2011, Arnd Bergmann wrote:
> 
>> On Monday 21 February 2011, Jan Kiszka wrote:
>>>> Now I think I tried all useful possible combinations:
>>>> 1.) macvtap0 and macvlan0 in bridged and non bridge mode
>>>> 2.) macvlan0 based on eth0 or based on macvtap0
>>>> 3.) Using and ip address on macvlan0 or not (tried both for 7b mac and
>>>> 7c mac)
>>>> 4.) Using 7b and 7c mac address in KVM (MAC in KVM is always the
>>>> command
>>>> line configured) and used tap interface from macvtap0 (as no second tap
>>>> devices shows up)
>>>>
>>>> Summary:
>>>> 1.) Using macvtap0 only with 7b mac on interface and also at qemu works
>>>> well in bridged mode as well as non bridged mode but with limitation no
>>>> guest/host communication possible, used interface in KVM is tap
>>>> interface created by macvtap0. Quite logically that it doesn't work
>>>> with
>>>> guest/host because of missing hairpin mode on the switch. But according
>>>> to http://virt.kernelnewbies.org/MacVTap bridge mode should work even
>>>> without hairpinning available on the switch.
>>>> 2.) macvlan0 doesn't create any tap interface therefore it can't be
>>>> used
>>>> as a device on KVM.
>>>> 3.) Using 7c mac address in KVM doesn't work at all regardsless of
>>>> setting ip addresses on macvlan0 or any other setup.
>>>>
>>>> @Arnd: Can you explain a setup in detail which should work also with
>>>> host/guest communication. Thnx.
>>>>
>>>> Any further ideas?
>>>> Which kernel is needed to work?
>>>> (current: 2.6.34.7-56.fc13.x86_64)
>>>
>>> Actually, I tried this successfully over a 2.6.38-rcX, but I have no
>>> idea what changes related to macvlan/tap went in since .34 and if this
>>> is required for this.
>>
>> We had a few bugs in .34, but it should work in general.
>>
>> One thing to make sure is that the host has connectivity through the
>> macvlan interface and the lower interface (eth0) has no IP address
>> assigned
>> but is 'up'.
>>
>> It could also be a bug in the NIC, you could try to set the NIC into
>> promiscious mode using ethtool to work around that.
> 
> Hello,
> 
> 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
> (I guess limitations are derived from function macvlan_queue_xmit:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/net/macvlan.c;h=6ed577b065df136a18af5ee483810773ca4f43f8;hb=HEAD#l217)
> 
> 
> Example:
> # Lower device eth0 must not have an IP address assigned, but when also
> no communication is possible with macv* devices
> /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name
> macvtap0 type macvtap mode bridge
> /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvtap0 address
> 1a:46:0b:ca:bc:7b up
> /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name
> macvtap1 type macvtap mode bridge
> /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvtap1 address
> 1a:46:0b:ca:bc:7c up
> /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name
> macvlan0 type macvtap mode bridge
> /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvlan0 address
> 1a:46:0b:ca:bc:7d up
> 
> Example usage:
> eth0 should not be assigned any IP. macvlan0 should be used as the main
> host interface and the main IP address is configured.
> macvtap0 and macvtap1 can be used in e.g. VMs.
> Bridge communication is possible between the 3 interfaces and the outer
> world: macvtap0, macvtap1, macvlan0
> E.g.:
> 1.) macvtap0 <=> macvtap1, macvlan0, eth0 external
> 2.) macvtap1 <=> macvtap0, macvlan0, eth0 external
> 3.) macvlan0 <=> macvtap0, macvtap1, eth0 external
> 
> But no communication is possible between lower device eth0 and the child
> interfaces macvtap0, macvtap1, macvlan0:
> 1.) eth0 <=> macvtap0
> 2.) eth0 <=> macvtap1
> 3.) eth0 <=> macvlan0

Right, but if I set IP(eth0) == IP(macvlan0), I'm able to communicate
between macvlan0 and mactapX, thus between guest and host. Just
re-checked here, still works (after resolving the usual MAC address mess
I caused by configuring manually).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux