[libvirt] oVirt considers using macTableManager='libvirt'

[Ido Barkan]

On Sun, Nov 1, 2015 at 8:05 PM, Laine Stump <laine at laine.org> wrote:
> 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.
Very well! So what is the API for turning this feature on for an
existing bridge?
I only found the documentation for managed networks (as in <network>
<name>test</name> <bridge name='br0' macTableManager='libvirt'/> ...).
oVirt creates the bridges by itself and then uses <source bridge="foo"/>
when it asks libvirt to create the VM interfaces.
>
>> 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 :-)
>
>



-- 
Thanks,
Ido Barkan