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