Message ID | 20100826114355.GA455@arachsys.com |
---|---|
State | New |
Headers | show |
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.
Chris Webb <chris@arachsys.com> writes: > 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? This turns out to be a bug in the kernel I'm using, 3.0.4, fixed by this patch: http://patchwork.ozlabs.org/patch/115273/ Cheers, Chris.
diff --git a/ui/vnc.c b/ui/vnc.c index 7fc40ac..e04ebdf 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -1410,10 +1410,10 @@ static void pointer_event(VncState *vs, int button_mask, dz = 1; if (vs->absolute) { - kbd_mouse_event(ds_get_width(vs->ds) > 1 ? - x * 0x7FFF / (ds_get_width(vs->ds) - 1) : 0x4000, - ds_get_height(vs->ds) > 1 ? - y * 0x7FFF / (ds_get_height(vs->ds) - 1) : 0x4000, + int width = ds_get_width(vs->ds); + int height = ds_get_height(vs->ds); + kbd_mouse_event(width > 1 ? x * 0x7FFF / (width - 1) : 0x4000, + height > 1 ? y * 0x7FFF / (height - 1) : 0x4000, dz, buttons); } else if (vnc_has_feature(vs, VNC_FEATURE_POINTER_TYPE_CHANGE)) { x -= 0x7FFF;
cc39a92cbfc8 fixed a SIGFPE where the screen is resized to width/hight 1 and then receives a mouse click. However, there is a still a tiny window here for a race between the test for width/height > 1 and the division. Signed-off-by: Chris Webb <chris@arachsys.com> --- Sending this as I've just seen a SIGFPE from one of the qemu-kvm VMs running in our public-facing cluster. Running gdb on the resulting core dump pointed at line #1424 of vnc.c: 1423 if (vs->absolute) { 1424 kbd_mouse_event(ds_get_width(vs->ds) > 1 ? 1425 x * 0x7FFF / (ds_get_width(vs->ds) - 1) : 0x4000, 1426 ds_get_height(vs->ds) > 1 ? 1427 y * 0x7FFF / (ds_get_height(vs->ds) - 1) : 0x4000, 1428 dz, buttons); I think this must have been a (tight) race between the comparison and the division. This should probably go to the 0.12-stable branch too as that's where I saw the crash. I can send a rebased patch if that's more convenient? A pity this crash happened just after the release of 0.12.5 rather than a week or two earlier! ui/vnc.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)