On 04/30/2015 11:18 AM, Laine Stump wrote:

On 04/30/2015 10:26 AM, Lars Kellogg-Stedman wrote:

...

I am running OpenStack inside a libvirt guest that is connected to the local network via a macvtap interface. My experience so far suggests that a macvtap interface will not pass traffic with a source MAC address other than the MAC address of the interface itself...for example, if inside the guest eth0 is attached to a bridge.

Is that correct, or is there some setting that will make that work?

I think that you have to use a passthru macvtap device in this case. Bridge and vepa mode macvtap devices determine which device to pass traffic to based on the destination mac address. If the destination doesn't match the macvtap device (as in your case), the traffic is not passed through the macvtap. Passtru mode is different. It will always pass the packet to the macvtap device. The limitation of a passthru mode is that you effectively assign the hardware device to the VM. You will not be able that device on the host. If the above doesn't appeal to you, you'd need to use a a bridge or OVS on the host. -vlad

...

Outbound traffic doesn't seem to be a problem (I can see, for example, dhcp requests on the local network), but replies get dropped before they reach the guest.

My understanding is that macvtap doesn't work with multiple MAC addresses behind the macvtap device. There might be some way to make it work, but if there is libvirt doesn't have a knob for it. (I Cc'ed Vlad in case he wants to give a more informed statement).

Recent versions of libvirt have the ability to change the MAC address (and multicast table) of the macvtap device based on events from the virtual guest, which allows the guest to change the interface's MAC address and have traffic still pass, but that is different from allowing multiple MAC addresses at the same time. (this functionality is enabled by adding "trustGuestRxFilters='yes'" as an attribute to the guest's <interface> element)

If you need to do support multiple MAC addresses coming from the guest, you should probably use a standard tap-to-bridge connection on the host instead (and make sure your openstack config isn't adding "<filterref name='clean-traffic'/>" to the guest's interface, as that filter enforces a strict single MAC address policy on traffic from the guest).