+++ This bug was initially created as a clone of Bug #928124 +++ --- comment from Jiri Pirko on 2014-05-06: Do not use tlb or alb in bridge, never! It does not work, that's it. The reason is it mangles source macs in xmit frames and arps. When it is possible, just use mode 4 (lacp). That should be always possible because all enterprise switches support that. Generally, for 99% of use cases, you *should* use mode 4. There is no reason to use other modes. ---- I.E.: Engine should not allow to attach a VM network to an existing mode5/mode6 bond, and should not allow to create such a bond under a VM network.
*** Bug 928124 has been marked as a duplicate of this bug. ***
As of today, modes 1, 2, 4 and 5 are supported 'out of the box' in the UI, while the other modes can be configured manually using the custom bond, which can also be used to inject any non-default settings into the bonds. Let's tackle this one properly by having a clear separation in the GUI between the 'bond mode' and the 'custom bond configuration', so that all bond modes (0-6) can be configured 'out of the box' from RHEV-M nicely, in addition to the custom properties that will be used only for changing settings once the mode is already known. That way, we can have Engine validate the configuration and block unsupported mode/network combination: Modes 1, 2 and 4 are supported for VM and non-VM (bridgless) network types. Modes 0, 3, 5 and 6 are supported for non-VM (bridgless) networks only.
Modes 1, 2, 3 and 4 are supported for VM and non-VM (bridgless) network types. Modes 0, 5 and 6 are supported for non-VM (bridgless) networks only.
I think the easiest thing to do would be to parse the bonding options of each *modified* bond in SetupNetworksHelper, and fail Setup Networks whenever one of them has mode 0/3/5/6 while any of its networks are VM networks. Similarly, when attaching a VM network to a bond the operation should fail if the bond is already configured to mode 0/3/5/6 (I don't think the same should be done for modifying networks). This will also make sure that if a logical network entity is changed to be a VM network, this doesn't propagate to hosts where the network is provisioned on top of such a bond. Parsing could be improved to actually storing the bonding mode separately from other options (on the business entity and in the DB). This would be a wider change, but better modeling. Then serialization and parsing should be performed upon communication with vdsm. Existing configurations should not be touched, as they might be working properly somehow. So no upgrade scripts here, neither in the engine nor in vdsm. As Nir suggested, all bonding modes should be available for selection in the list box by default. Modes 0/3/5/6 should not be present if a bond that has VM networks is being edited. "Custom" should not appear as a bonding mode anymore, and the "Custom mode" text box should be renamed "Options" and always be visible. Should display all the other options configured on the bond (typically miimon). If such a bond already exists with one of these modes, I think the best thing to do would be to add (only in those cases) an entry to the list box called "Unsupported (mode X)", where X is whatever mode (out of 0/3/5/6) that's currently configured on the bond. 1. Moti/Yevgeny, sounds good? 2. Nir, from a workload point of view this sounds doable, but it sounds like a lot of changes post feature freeze, I'm not sure we should do this for 3.5.
*** Bug 1121344 has been marked as a duplicate of this bug. ***
Dan, I just want to make sure that it is okay to take out the bonding mode from the "custom" configuration - is there any way to "customize" bonding mode, i.e. specify anything other than 0-6?
This are the only modes known to Linux to date. Each mode may have additional options, which should remain customizable.
*** Bug 1230638 has been marked as a duplicate of this bug. ***
The last patch will change - in Node - the default bonding mode (the preset bonding mode when a new bond is created) to active backup, which is safe to use with VM networks. The user can still change the mode during creation or at runtime.
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015. Please review this bug and if not a blocker, please postpone to a later release. All bugs not postponed on GA release will be automatically re-targeted to - 3.6.1 if severity >= high - 4.0 if severity < high
Verified on - 3.6.1-0.2.el6
Maybe i was rush with verifying this one, after some attempts, engine allowed me to configure/edit a bond(was already exist) with 'BONDING_OPTS': 'mode=5 miimon=100', while a VM network was attached to him. This caused to some side effects like --> - Can't open setup networks dialog - gwt$exception - all network on host became unsynced Marcin is investigating. Moving back to ON_QA at this point.
False alarm)) This single bad attempt^^ happened cause someone removed the DC that this server was running on and this is what caused all the problems in my env. This bug is verified with success on 3.6.1-0.2.el6
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-0376.html