Bug 1094842

Summary: Bonding modes 0, 5 and 6 should be avoided for VM networks
Product: Red Hat Enterprise Virtualization Manager Reporter: Dan Kenigsberg <danken>
Component: ovirt-engineAssignee: Marcin Mirecki <mmirecki>
Status: CLOSED ERRATA QA Contact: Michael Burman <mburman>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.0CC: bazulay, byount, cshao, danken, fdeutsch, huiwa, huzhao, iheim, jbainbri, jbuchta, jdonohue, jhunsaker, kernel-qe, leiwang, lpeer, masayag, mburman, michele, mkalinin, mleitner, mmirecki, myakove, nyechiel, pep, peterm, rbalakri, Rhev-m-bugs, rkhan, robimath, sputhenp, stbechto, tgummels, yaniwang, ycui, yeylon, ylavi
Target Milestone: ovirt-3.6.1Flags: nyechiel: Triaged+
Target Release: 3.6.0   
Hardware: All   
OS: Linux   
Whiteboard:
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.
Story Points: ---
Clone Of: 928124
: 1097143 1097312 (view as bug list) Environment:
Last Closed: 2016-03-09 20:44:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1097330, 1136329    
Bug Blocks: 1059435, 1250199    

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