Ganglia's gmond multicast traffic across kvm/qemu vnet0 bridge

Dear All,
Has anyone come across this before?

I am running Ganglia's gmond daemon on a KVM guest and using multicast
as with the default configuration for gmond on all hosts to
communicate with each other and with the central gmetad. This all
works nicely on bare metal hosts, just the kvm guest was not
communicating via multicast. I found the following,

(1) 'tcpdump -i eth0 dst 239.2.11.71' on the guest only sees multicast traffic
created by gmond running on that guest.

(2) 'tcpdump -i vnet0 dst 239.2.11.71' on the guest's bare metal host
also only sees multicast traffic created by the gmond running on its
guest.

(3) 'tcpdump -i br123 dst 239.2.11.71' on the guest's bare metal host
sees all the multicast traffic from all the other gmonds on our LAN
but none from its guest. br123 is the bridge device setup for 123
tagged packets on our 802.1Q VLAN. At the br123 interface stage the
packets are untagged so I presume this is not a VLAN problem.

Using virt-manager GUI for the guest's setup I have for the virtual NIC,

Source device: Host device eth0.123 (Bridge 'br123')
Device model: virtio

where eth0.123 is the corresponding Ethernet device extracting
untagged 123 network packets from the tagged packets on the eth0
physical NIC plugged into the switch.

ifconfig shows eth0.123, br123 & vnet0 are all multicast enabled.

By trial and error I found a solution was to do,

echo 2 > /sys/class/net/vnet0/brport/multicast_router

Then the guest's multicast traffic is forwarded to the rest of the LAN
and the guest receives multicast traffic from the LAN as expected.

I could not find any documentation on this. Can anyone shed any light?

I also discovered that re-writing 2 to these pseudo files results in a
total system freeze!

Cheers
Tom Crane
(PP IT Support)

OS details: SLC6.5 (SLC ~= RHEL)
Kernel: 2.6.32-431.1.2.el6.x86_64
KVM S/W RPMs: qemu-kvm-0.12.1.2-2.415.el6_5.3.x86_64,
libvirt-0.10.2-29.el6.1.x86_64, virt-manager-0.9.0-19.el6.x86_64

--
Ps. The email address in the header is just a spam-trap.

Tom Crane, Dept. Physics, Royal Holloway, University of London, Egham Hill,
Egham, Surrey, TW20 0EX, England.
Email: T dot Crane at rhul dot ac dot uk

 

Earlier I wrote:
: Dear All,
: Has anyone come across this before?

[cut]

: By trial and error I found a solution was to do,

: echo 2 > /sys/class/net/vnet0/brport/multicast_router

: Then the guest's multicast traffic is forwarded to the rest of the LAN
: and the guest receives multicast traffic from the LAN as expected.

It seems I jumped the gun a bit here. Re-checking I found that '2'
also needs to be written to both,

/sys/devices/virtual/net/br123/bridge/multicast_router &
/sys/devices/virtual/net/eth0.123/brport/multicast_router

before the multicast traffic would be routed beyond the br123 device
on the host system and onto the LAN. I also found that trying to repeat
the process with a second VLAN also resulted in a system hang. A routing
loop perhaps?

[cut]

: I also discovered that re-writing 2 to these pseudo files results in a
: total system freeze!

I noticed that the 'total system freeze' was not quite that. A 'top'
session running the console continued to run.

Cheers
Tom Crane
(PP IT Support)

Ps. The email address in the header is just a spam-trap.