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

On Sun, Nov 1, 2015 at 8:05 PM, Laine Stump <laine(a)laine.org&gt; 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