libvirt users - May 2015 - Re: Limitations of macvtap devices?

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?

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.

Thanks,

-- 
Lars Kellogg-Stedman <lars@redhat.com> | larsks @
{freenode,twitter,github}
Cloud Engineering / OpenStack          | http://blog.oddbit.com/

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?
>
> 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).

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).
>

On 30.04.2015 16:26, 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?
> 
> 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.
> 
> Thanks,
> 
Yes, this is actually correct. However, as of 1.2.10 libvirt listens for
the macvtap MAC changes initialized within guest and adjusts the host
side of the device accordingly.

Michal