Bug 1495905 - RHV-H reposts unknown bonding devices during the boot process.
Summary: RHV-H reposts unknown bonding devices during the boot process.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Tools
Version: 4.19.31
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ovirt-4.2.0
: ---
Assignee: Edward Haas
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-26 13:16 UTC by Roman Hodain
Modified: 2017-12-20 10:56 UTC (History)
4 users (show)

Fixed In Version: vdsm-api-4.20.6-62.gitd3023e4.el7.centos.noarch.rpm
Clone Of:
Environment:
Last Closed: 2017-12-20 10:56:19 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.2+
ylavi: planning_ack+
danken: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3195642 0 None None None 2017-09-26 13:35:05 UTC
oVirt gerrit 83784 0 'None' MERGED net: Rename the bond used for option mapping 2021-01-14 13:33:21 UTC

Description Roman Hodain 2017-09-26 13:16:40 UTC
Description of problem:
The following messages are reported during the boot process:

    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting fail_over_mac to none (0)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting fail_over_mac to active (1)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting fail_over_mac to follow (2)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: option fail_over_mac: invalid value (3)
    Sep 24 11:56:18 RHV-H01.example.com NetworkManager[1690]: <info>  [1506246978.6238] manager: (MrnNSFK7Vb2Q7OG): new Bond device (/org/freedesktop/NetworkManager/Devices/20)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting ad_select to stable (0)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting ad_select to bandwidth (1)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting ad_select to count (2)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: option ad_select: invalid value (3)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: option lacp_rate: mode dependency failed, not supported in mode balance-rr(0)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting arp_validate to none (0)
    Sep 24 11:56:18 RHV-H01.example.com kernel: MrnNSFK7Vb2Q7OG: Setting arp_validate to active (1)
    ...

Version-Release number of selected component (if applicable):
    vdsm-4.19.31-1.el7ev.x86_64


How reproducible:
    100%

Steps to Reproduce:
    1. Boot hypervisor
    2. Check /var/log/messages

Actual results:
    Suspicious messages in mesage file

Expected results:
    make the process in the way that it is understandable what is going on.

Additional info:
    Done by vdsm lib/vdsm/tool/dump_bonding_opts.py
                    _get_bonding_options_name2numeric
                    _get_default_bonding_options

Comment 2 Dan Kenigsberg 2017-09-26 20:40:46 UTC
This is an unfortunate side-effect of our solution for bug 1482014.

Edy, can we think of a way to silence some of that noise, such as moving back the defaults to /var/lib, and reenerating them only on the first-ever boot with a specific kernel version?

Comment 3 Edward Haas 2017-09-27 07:03:19 UTC
(In reply to Dan Kenigsberg from comment #2)
> This is an unfortunate side-effect of our solution for bug 1482014.
> 
> Edy, can we think of a way to silence some of that noise, such as moving
> back the defaults to /var/lib, and reenerating them only on the first-ever
> boot with a specific kernel version?

I guess we could sign the bond options dump with the kernel version and check before we attempt to execute a new one.
But for that, I think we need to use a different format for the dump.

We could start by naming the bond as suggested by Roman.

Comment 4 Edward Haas 2017-11-08 14:56:11 UTC
Just posted a patch with a suggested prefix for the bond name: "bondscan-"

Comment 5 Michael Burman 2017-11-13 09:50:51 UTC
bondscan- prefix was added - 

Nov 13 11:42:09 camel-vdsa kernel: bonding: bondscan-lPfMqc is being created...
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting fail_over_mac to none (0)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting fail_over_mac to active (1)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting fail_over_mac to follow (2)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: option fail_over_mac: invalid value (3)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting ad_select to stable (0)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting ad_select to bandwidth (1)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting ad_select to count (2)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: option ad_select: invalid value (3)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: option lacp_rate: mode dependency failed, not supported in mode balance-xor(2)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting arp_validate to none (0)
Nov 13 11:42:09 camel-vdsa kernel: bondscan-lPfMqc: Setting arp_validate to active (1)

Verified on - vdsm-4.20.6-62.gitd3023e4.el7.centos.x86_64

Comment 6 Sandro Bonazzola 2017-12-20 10:56:19 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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