From: Jan Kiszka <jan.kiszka@siemens.com>
To: Gerhard Wiesinger <lists@wiesinger.com>
Cc: qemu-devel@nongnu.org, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible?
Date: Wed, 23 Feb 2011 13:53:48 +0100 [thread overview]
Message-ID: <4D65035C.6070104@siemens.com> (raw)
In-Reply-To: <alpine.LFD.2.02.1102230720590.27714@bbs.intern>
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
next prev parent reply other threads:[~2011-02-23 12:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-19 19:32 [Qemu-devel] Network bridging without adding bridge with brctl, possible? Gerhard Wiesinger
2011-02-20 9:44 ` [Qemu-devel] " Jan Kiszka
2011-02-20 10:19 ` Gerhard Wiesinger
2011-02-20 11:19 ` Jan Kiszka
2011-02-20 21:28 ` Arnd Bergmann
2011-02-21 6:12 ` Gerhard Wiesinger
2011-02-20 12:49 ` Gerhard Wiesinger
2011-02-20 14:15 ` Jan Kiszka
2011-02-20 15:19 ` Gerhard Wiesinger
2011-02-20 17:39 ` Jan Kiszka
2011-02-20 20:03 ` Gerhard Wiesinger
2011-02-20 21:33 ` Arnd Bergmann
2011-02-21 6:40 ` Gerhard Wiesinger
2011-02-21 8:44 ` Jan Kiszka
2011-02-21 12:07 ` Arnd Bergmann
2011-02-23 6:38 ` Gerhard Wiesinger
2011-02-23 12:53 ` Jan Kiszka [this message]
2011-02-24 6:49 ` Gerhard Wiesinger
2011-02-24 7:50 ` Jan Kiszka
2011-02-24 8:00 ` Arnd Bergmann
2011-02-23 14:47 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D65035C.6070104@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=arnd@arndb.de \
--cc=lists@wiesinger.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.