Bug 842338 - VDSM 3.1 beta1: vdsm doesn't manage to configure bonding mode.
VDSM 3.1 beta1: vdsm doesn't manage to configure bonding mode.
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: beta
: ---
Assigned To: Dan Kenigsberg
Yaniv Kaul
network rhev-3.1
: Regression, TestBlocker
: 832758 (view as bug list)
Depends On:
Blocks: 844119
  Show dependency treegraph
Reported: 2012-07-23 10:10 EDT by Avi Tal
Modified: 2016-04-22 00:59 EDT (History)
15 users (show)

See Also:
Fixed In Version: vdsm-4.9.6-24.0
Doc Type: Bug Fix
Doc Text:
Previously, VDSM failed to configure bonding mode until the network was restarted due to a change in the kernel semantics regarding asking for changes in bond mode. Now, the VDSM changes bond mode only when the bonding device is down, meaning the Red Hat Enterprise Virtualization Manager-configured bonding mode takes effect immediately.
Story Points: ---
Clone Of:
: 844119 (view as bug list)
Last Closed: 2012-12-04 14:03:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
vdsm 3.0 log (365.88 KB, application/x-compressed-tar)
2012-07-23 10:11 EDT, Avi Tal
no flags Details
vdsm 3.1 log (838.00 KB, application/x-compressed-tar)
2012-07-23 10:12 EDT, Avi Tal
no flags Details

  None (edit)
Description Avi Tal 2012-07-23 10:10:54 EDT
Description of problem:
Configuring bonding interface via rhevm (vdsm) doesn't actually configure the bonding mode but only adding the slaves.

looks like bonding mode is the latest mode before the current configuration.

Steps to Reproduce:
1. check /proc/net/bonding/bond0
2. write down the "Bonding Mode:"
3. configure new bonding interface mode=4 (or any other mode - different then what exists) on same bond0 
4. check /proc/net/bonding/bond0

Actual results:
/proc/net/bonding/bond0 will still contain the old "Bonding Mode:" instead of updating the new mode=4

Expected results:
update mode regarding configuration

Additional info:
** This bug appear also on latest 3.0.z (vdsm-4.9-113.2.el6_3.x86_64)
Comment 1 Avi Tal 2012-07-23 10:11:50 EDT
Created attachment 599788 [details]
vdsm 3.0 log
Comment 2 Avi Tal 2012-07-23 10:12:23 EDT
Created attachment 599789 [details]
vdsm 3.1 log
Comment 3 Avi Tal 2012-07-23 10:14:22 EDT
3.1 details:
kernel 2.6.32-286.el6.x86_64

3.0 details:
Comment 4 Dan Kenigsberg 2012-07-23 11:12:29 EDT
Your 3.1 kernel is older than your 3.0's. There's probably a place for upgrade.

Could you see when this was introduced? I mean, did it work fine with rhel-6.2? Please record initscripts and kernel versions.

The following patch by Mark Wu aims to fix this issue
Comment 5 Martin Pavlik 2012-07-24 08:01:02 EDT
On rhel 6.2 with vdsm vdsm-4.9-113.1.el6.x86_64 it works fine. See more details below:

[root@dell-r210ii-08 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.2 (Santiago)

[root@dell-r210ii-08 ~]# uname -a
Linux dell-r210ii-08.rhev.lab.eng.brq.redhat.com 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux

root@dell-r210ii-08 ~]# rpm -qa | grep vdsm

[root@dell-r210ii-08 ~]# cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Aggregator selection policy (ad_select): stable
bond bond1 has no active aggregator

Slave Interface: p1p1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 90:e2:ba:04:28:b8
Aggregator ID: N/A
Slave queue ID: 0

Slave Interface: p1p2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 90:e2:ba:04:28:b9
Aggregator ID: N/A
Slave queue ID: 0

[root@dell-r210ii-08 ~]# cat /etc/sysconfig/network-scripts/ifcfg-bond1
Comment 6 Avi Tal 2012-07-24 08:05:14 EDT
Adding to above comment
# rpm -q initscripts
Comment 8 Dan Kenigsberg 2012-07-24 13:36:05 EDT
I'd like to copy Mark's gerrit comment to here:

It turns out that it caused by a recent kernel change as you guessed. So that means this problem could only happen on fedora host, which explains that it's not reported before.

For details, please see the following kernel commit:

$git show 4a8bb7e2
commit 4a8bb7e27fbb68da888b55f26defd2855225b2d5
Author: Veaceslav Falico <vfalico@redhat.com>
Date: Tue Nov 15 06:44:42 2011 +0000

bonding: Don't allow mode change via sysfs with slaves present

When changing mode via bonding's sysfs, the slaves are not initialized
correctly. Forbid to change modes with slaves present to ensure that every
slave is initialized correctly via bond_enslave().

Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Acked-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 5a20804..4ef7e2f 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -319,6 +319,13 @@ static ssize_t bonding_store_mode(struct device *d,
goto out;

+ if (bond->slave_cnt > 0) {
+     pr_err("unable to update mode of %s because it has slaves.\n",
+     bond->dev->name);
+     ret = -EPERM;
+     goto out;
+ }
new_value = bond_parse_parm(buf, bond_mode_tbl);
if (new_value < 0) {
pr_err("%s: Ignoring invalid mode value %.*s.\n",
[mark@localhost net]$ git name-rev --tag 4a8bb7e27fbb68da888b55f26defd2855225b2d5
4a8bb7e27fbb68da888b55f26defd2855225b2d5 tags/v3.2-rc3~25^2~4
Comment 9 Igor Lvovsky 2012-07-30 13:17:26 EDT
*** Bug 832758 has been marked as a duplicate of this bug. ***
Comment 10 Avi Tal 2012-07-31 05:10:10 EDT
verify on vdsm-4.9.6-24.0.el6_3.x86_64 - PASS
i have configured all supported bond 1,2,4,5 and mode was updated.
Comment 13 errata-xmlrpc 2012-12-04 14:03:26 EST
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.


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