On Mon, Nov 2, 2015 at 8:22 AM, Ido Barkan <ibarkan@xxxxxxxxxx> wrote: > On Sun, Nov 1, 2015 at 8:05 PM, Laine Stump <laine@xxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list