Re: [libvirt] oVirt considers using macTableManager='libvirt'

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