[libvirt] oVirt considers using macTableManager='libvirt'

[Ido Barkan]

On Mon, Nov 2, 2015 at 8:22 AM, Ido Barkan <ibarkan at redhat.com> wrote:
> 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.
Oops. Sorry, dumb question. this _is_ the API for defining networks. I have
answered myself.
>>
>>> 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



-- 
Thanks,
Ido Barkan