From: Chris Webb <chris@arachsys.com>
To: qemu-devel@nongnu.org, netdev@vger.kernel.org
Subject: How to use macvtap/macvlan correctly
Date: Fri, 30 Sep 2011 09:49:35 +0100 [thread overview]
Message-ID: <20110930084935.GC12879@arachsys.com> (raw)
In-Reply-To: <20100826114355.GA455@arachsys.com>
I'm trying to get bridge-mode communication between a macvtap and a host
macvlan working correctly, but I think I must be doing something wrong as
the host macvlan and guest macvtap apparently can't communicate. I'm aware
that the underlying eth0 interface can't communicate with the macvtap, but I
thought that creating a host macvlan device and configuring that was the
standard work-around?
On a clean host running linux 3.0.4 and iptables 2.6.39, with no networking
except lo up with 127.0.0.1/8, I did
ip link add link eth0 name host address 02:a3:a6:ed:4b:94 type macvlan mode bridge
ip addr add 10.0.0.3/24 dev host
ip link set eth0 up
ip link set host up
I can ping a second host 10.0.0.1 attached to the eth0 interface of the test
host without problem.
I then created a macvtap device and launched a qemu guest against it:
ip link add link eth0 name macvtap0 type macvtap mode bridge
qemu-kvm -nographic -kernel /boot/vmlinuz-guest \
-append "console=ttyS0 root=/dev/vda" \
-drive file=/tmp/testroot.img,if=virtio,cache=none \
-net nic,model=virtio,macaddr=$(< /sys/class/net/macvtap0/address) \
-net tap,fd=3 3<>/dev/tap$(< /sys/class/net/macvtap0/ifindex)
Configuring the eth0 inside the guest with 10.0.0.4/24, I discovered I can
ping the external machine, but not the host, despite the macvtap and macvlan
being in bridge mode.
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 48 data bytes
56 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=0.351 ms
56 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.360 ms
56 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.281 ms
^C--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.281/0.331/0.360/0.035 ms
# ping 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 48 data bytes
^C--- 10.0.0.3 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
However something is working, because inside the guest:
# ip neigh
10.0.0.1 dev eth0 lladdr c8:0a:a9:37:29:6a REACHABLE
10.0.0.3 dev eth0 lladdr 02:a3:a6:ed:4b:94 REACHABLE
...and the MAC address it has for 10.0.0.3 is correct, so somehow an arp
request and response has got out to the host and back.
The kernel has
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
[...]
CONFIG_BRIDGE_NETFILTER=y
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
(I didn't know off the top of my head if the bridge options are needed for
macvlan/vtap bridge mode, but they're compiled in anyway just in case.)
Any guesses what I've missed here?
Cheers,
Chris.
WARNING: multiple messages have this Message-ID (diff)
From: Chris Webb <chris@arachsys.com>
To: qemu-devel@nongnu.org, netdev@vger.kernel.org
Subject: [Qemu-devel] How to use macvtap/macvlan correctly
Date: Fri, 30 Sep 2011 09:49:35 +0100 [thread overview]
Message-ID: <20110930084935.GC12879@arachsys.com> (raw)
In-Reply-To: <20100826114355.GA455@arachsys.com>
I'm trying to get bridge-mode communication between a macvtap and a host
macvlan working correctly, but I think I must be doing something wrong as
the host macvlan and guest macvtap apparently can't communicate. I'm aware
that the underlying eth0 interface can't communicate with the macvtap, but I
thought that creating a host macvlan device and configuring that was the
standard work-around?
On a clean host running linux 3.0.4 and iptables 2.6.39, with no networking
except lo up with 127.0.0.1/8, I did
ip link add link eth0 name host address 02:a3:a6:ed:4b:94 type macvlan mode bridge
ip addr add 10.0.0.3/24 dev host
ip link set eth0 up
ip link set host up
I can ping a second host 10.0.0.1 attached to the eth0 interface of the test
host without problem.
I then created a macvtap device and launched a qemu guest against it:
ip link add link eth0 name macvtap0 type macvtap mode bridge
qemu-kvm -nographic -kernel /boot/vmlinuz-guest \
-append "console=ttyS0 root=/dev/vda" \
-drive file=/tmp/testroot.img,if=virtio,cache=none \
-net nic,model=virtio,macaddr=$(< /sys/class/net/macvtap0/address) \
-net tap,fd=3 3<>/dev/tap$(< /sys/class/net/macvtap0/ifindex)
Configuring the eth0 inside the guest with 10.0.0.4/24, I discovered I can
ping the external machine, but not the host, despite the macvtap and macvlan
being in bridge mode.
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 48 data bytes
56 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=0.351 ms
56 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.360 ms
56 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.281 ms
^C--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.281/0.331/0.360/0.035 ms
# ping 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 48 data bytes
^C--- 10.0.0.3 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
However something is working, because inside the guest:
# ip neigh
10.0.0.1 dev eth0 lladdr c8:0a:a9:37:29:6a REACHABLE
10.0.0.3 dev eth0 lladdr 02:a3:a6:ed:4b:94 REACHABLE
...and the MAC address it has for 10.0.0.3 is correct, so somehow an arp
request and response has got out to the host and back.
The kernel has
CONFIG_MACVLAN=y
CONFIG_MACVTAP=y
[...]
CONFIG_BRIDGE_NETFILTER=y
CONFIG_BRIDGE_NF_EBTABLES=y
CONFIG_BRIDGE=y
CONFIG_BRIDGE_IGMP_SNOOPING=y
(I didn't know off the top of my head if the bridge options are needed for
macvlan/vtap bridge mode, but they're compiled in anyway just in case.)
Any guesses what I've missed here?
Cheers,
Chris.
next prev parent reply other threads:[~2011-09-30 9:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 11:43 [Qemu-devel] [PATCH, RESEND] Fix SIGFPE race for vnc display resize Chris Webb
2011-09-30 8:49 ` Chris Webb [this message]
2011-09-30 8:49 ` [Qemu-devel] How to use macvtap/macvlan correctly Chris Webb
2011-10-02 19:46 ` Chris Webb
2011-10-02 19:46 ` [Qemu-devel] " Chris Webb
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=20110930084935.GC12879@arachsys.com \
--to=chris@arachsys.com \
--cc=netdev@vger.kernel.org \
--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.