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 :-)
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list