[libvirt] oVirt considers using macTableManager='libvirt'
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? -- Thanks, Ido Barkan
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 :-)
On Sun, Nov 1, 2015 at 8:05 PM, Laine Stump <laine@laine.org> 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 Mon, Nov 2, 2015 at 8:22 AM, Ido Barkan <ibarkan@redhat.com> wrote:
On Sun, Nov 1, 2015 at 8:05 PM, Laine Stump <laine@laine.org> 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
On 11/01/2015 01:05 PM, Laine Stump 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.
As long as mirroring is only done in one direction (bridge to host NIC), there shouldn't be any interference. The bridge is is still programmed with the correct set of mac addresses and should still be able to receive traffic destined for the VM.
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.
I think we initially turned this on in 7.2, so everything should be there.
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?
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 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 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 :-)
These two statements might seem contradictory, but Vlad is of course speaking from kernel (and OVS?) POV, and I'm speaking from libvirt POV (actually, I'm ignorant enough of the capabilities of OVS that I assumed such capabilities already existed in OVS; is that not the case?)
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 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 :-)
These two statements might seem contradictory, but Vlad is of course speaking from kernel (and OVS?) POV, and I'm speaking from libvirt POV (actually, I'm ignorant enough of the capabilities of OVS that I assumed such capabilities already existed in OVS; is that not the case?)
No, OVS still needs similar support as bridge has. -vlad
On Nov 2, 2015 7:50 PM, "Vlad Yasevich" <vyasevic@redhat.com> wrote:
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
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 :-)
These two statements might seem contradictory, but Vlad is of course speaking from kernel (and OVS?) POV, and I'm speaking from libvirt POV (actually, I'm ignorant enough of the capabilities of OVS that I assumed such capabilities already existed in OVS; is that not the case?)
No, OVS still needs similar support as bridge has.
-vlad
Was a feature request to support this has been opened? Especially important as oVirt is moving to OVS. TIA, Y.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Ido Barkan -
Laine Stump -
Vlad Yasevich -
Yaniv Kaul