Bug 1094842 - Bonding modes 0, 5 and 6 should be avoided for VM networks
Summary: Bonding modes 0, 5 and 6 should be avoided for VM networks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: All
OS: Linux
high
high
Target Milestone: ovirt-3.6.1
: 3.6.0
Assignee: Marcin Mirecki
QA Contact: Michael Burman
URL:
Whiteboard:
: 928124 1121344 1230638 (view as bug list)
Depends On: 1097330 1136329
Blocks: 1059435 1250199
TreeView+ depends on / blocked
 
Reported: 2014-05-06 15:15 UTC by Dan Kenigsberg
Modified: 2019-04-28 10:40 UTC (History)
36 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
With this release, host network bonds with bond mode 0, 5, or 6 will not support adding a VM network to them. Similarly, a bond with a VM network attached will not be allowed to move into mode 0, 5, or 6.
Clone Of: 928124
: 1097143 1097312 (view as bug list)
Environment:
Last Closed: 2016-03-09 20:44:56 UTC
oVirt Team: Network
nyechiel: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 42525 master MERGED net: Use a VM compatible bond mode by default Never
oVirt gerrit 46251 master MERGED webadmin: Bonding modes 0, 5 and 6 should be avoided for VM networks Never
oVirt gerrit 46560 master MERGED engine: Bonding modes 0, 5 and 6 should be avoided for VM networks Never
oVirt gerrit 46797 master MERGED engine: Common changes for Bonding modes 0, 5 and 6 should be avoided for VM networks Never
oVirt gerrit 47819 master MERGED engine: BondMode refactoring Never
oVirt gerrit 48143 ovirt-engine-3.6 MERGED engine: Common changes for Bonding mode 0,5,6 patches Never
oVirt gerrit 48144 ovirt-engine-3.6 MERGED webadmin: Bonding modes 0, 5 and 6 should be avoided for VM networks Never
oVirt gerrit 48145 ovirt-engine-3.6 MERGED engine: BondMode refactoring Never
oVirt gerrit 48146 ovirt-engine-3.6 MERGED engine: Bonding modes 0, 5 and 6 should be avoided for VM networks Never
oVirt gerrit 48148 master MERGED engine: Bond modes correction for SetupNetworksJoinBondsModel Never
oVirt gerrit 51287 ovirt-3.5 MERGED net: Use a VM compatible bond mode by default 2016-01-06 16:57:34 UTC
Red Hat Knowledge Base (Solution) 67546 None None None Never
Red Hat Bugzilla 1097312 None CLOSED [Docs] Bonding modes 0, 5 and 6 should not be used for VM networks 2019-06-28 09:15:49 UTC
Red Hat Bugzilla 1233035 None CLOSED Change the default bonding mode to safe defaults (active-backup) 2019-06-28 09:15:49 UTC

Internal Links: 1233035

Description Dan Kenigsberg 2014-05-06 15:15:58 UTC
+++ 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.

Comment 2 Jamie Bainbridge 2014-05-06 22:16:20 UTC
*** Bug 928124 has been marked as a duplicate of this bug. ***

Comment 3 Nir Yechiel 2014-05-21 14:30:16 UTC
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.

Comment 4 Nir Yechiel 2014-06-05 09:58:17 UTC
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.

Comment 5 Lior Vernia 2014-07-20 11:10:00 UTC
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.

Comment 6 Nir Yechiel 2014-07-22 08:19:14 UTC
*** Bug 1121344 has been marked as a duplicate of this bug. ***

Comment 7 Lior Vernia 2014-11-27 15:30:35 UTC
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?

Comment 8 Dan Kenigsberg 2014-11-27 16:19:44 UTC
This are the only modes known to Linux to date. Each mode may have additional options, which should remain customizable.

Comment 9 Fabian Deutsch 2015-06-18 05:57:00 UTC
*** Bug 1230638 has been marked as a duplicate of this bug. ***

Comment 10 Fabian Deutsch 2015-06-18 06:03:23 UTC
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.

Comment 11 Sandro Bonazzola 2015-10-26 12:31:20 UTC
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

Comment 12 Michael Burman 2015-12-02 14:02:03 UTC
Verified on - 3.6.1-0.2.el6

Comment 13 Michael Burman 2015-12-02 14:52:44 UTC
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.

Comment 14 Michael Burman 2015-12-02 15:30:43 UTC
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

Comment 16 errata-xmlrpc 2016-03-09 20:44:56 UTC
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


Note You need to log in before you can comment on or make changes to this bug.