[libvirt] oVirt considers using macTableManager='libvirt'

[Laine Stump]

On 11/01/2015 08:52 AM, Ido Barkan wrote:
> Hi guys,
>
> We, at oVirt, are considring using the automatic bridge management
> feature of libvirt for our hosts
> (macTableManager='libvirt').
> I could find any discussion in the mailing list archives about the
> motivation for this feature.
>    (was there?). If there wasn't I would like to start a new one, about
> the possible trade offs it would
>    have in oVirt.
>    Specifically I have a few questions:
>
> 1) The obvious performance motivation is clear: considering N hosts
> with M vms each connected to
>     the same LAN, the first packet to any unknown yet host will flood
> all the vms in all N bridges.
>        -- was there any other motivation that I do not understand
> (apart from slightly better security?

It allows turning off both learning and flood, which improves 
performance, and also causes the physdev attached to the bridge to be 
automatically switched *out of * promiscuous mode (since the bridge 
always knows the list of MAC addresses that it should be listening for, 
it can just keep the physdev's mac filter table appropriately loaded, 
and have no need for promiscuous mode). Note that promisc mode can't be 
turned off if the bridge is connected to multiple physdevs (unless they 
are hooked together as a bond).

> 2) oVirt uses TC for port mirroring, in case this is requested by
> users, to mirror traffic from a chosen
>     bridge to a chosen NIC in the host. I could not understand if
> macTableManager will interfere
>     with it, or not.

I'm not sure, as I'm unfamiliar with this. I'm Cc's Vlad from 
qemu/kernel networking to see if he can give better information. (Vlad, 
please correct anything else I've gotten wrong in this response).


> 3) Are there any drawbacks to enabling this feature?

If a guest changes its MAC address, or expects to have traffic for 
multiple MAC addresses sent to it, you'll have problems. I don't 
remember right now if I also setup libvirt to respond to mac filter 
change events for tap devices connected to a bridge (as I have done for 
macvtap devices), but will look it up tomorrow and tell you.

> 4) We aim for rhel7.2. Will the feature be supported (or partially
> supported) for kernels older then
>      3.17? And if so, in what way?

I'm pretty sure that anything necessary to support it was backported to 
the kernel used in RHEL/CentOS7.2 (if it wasn't there already). Vlad 
will know for sure.

> 5) oVirt currently builds its own bridges and tell libvirt about them.
> Does that have any affect on the
>      functionality of that feature?

No. It works both for bridges created by libvirt and those created 
outside of libvirt.

> 6) are there any plans to support OVS for this feature in the future?

No concrete plans, but if someone wants to implement it, I'd be happy to 
assist/review :-)