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?

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.

3) Are there any drawbacks to enabling this feature?

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?

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

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

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

On 11/01/2015 01:05 PM, Laine Stump wrote: > On 11/01/2015 08:52 AM, Ido Barkan wrote: > > > > 6) are there any plans to support OVS for this feature in the future? Yes, we have plans to support this for OVS. -vlad > No concrete plans, but if someone wants to implement it, I'd be happy to assist/review :-) >

On 11/02/2015 01:18 PM, Laine Stump wrote: > On 11/02/2015 08:22 AM, Vlad Yasevich wrote: >> On 11/01/2015 01:05 PM, Laine Stump wrote: >>> On 11/01/2015 08:52 AM, Ido Barkan wrote: >>> >>> >>> > 6) are there any plans to support OVS for this feature in the

>> Yes, we have plans to support this for OVS. >> >> -vlad >> >>> No concrete plans, but if someone wants to implement it, I'd be happy

>>> > > These two statements might seem contradictory, but Vlad is of course

> (and OVS?) POV, and I'm speaking from libvirt POV (actually, I'm

> capabilities of OVS that I assumed such capabilities already existed in

> the case?) No, OVS still needs similar support as bridge has. -vlad

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list