RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1809330 - Changing bond mode from 1 to 5 fails
Summary: Changing bond mode from 1 to 5 fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: nmstate
Version: 8.2
Hardware: Unspecified
OS: Unspecified
medium
urgent
Target Milestone: rc
: 8.0
Assignee: Gris Ge
QA Contact: Mingyu Shi
URL:
Whiteboard:
: 1811389 (view as bug list)
Depends On: 1810506 1811389
Blocks: 1810550
TreeView+ depends on / blocked
 
Reported: 2020-03-02 21:02 UTC by Dominik Holler
Modified: 2022-05-01 23:54 UTC (History)
12 users (show)

Fixed In Version: nmstate-0.2.6-4.8.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-28 16:00:37 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
terminal log and nmstate files to reproduce (89.68 KB, application/x-xz)
2020-03-02 21:02 UTC, Dominik Holler 		no flags Details
verification.log (149.43 KB, text/plain)
2020-03-10 09:21 UTC, Mingyu Shi 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Github nmstate nmstate pull 910 0 None closed nm applier: only create ethernet when explicitly 2020-07-09 02:53:41 UTC
Red Hat Issue Tracker RHELPLAN-38836 0 None None None 2022-05-01 23:54:41 UTC
Red Hat Product Errata RHBA-2020:1696 0 None None None 2020-04-28 16:00:51 UTC

Internal Links: 1810550

Description Dominik Holler 2020-03-02 21:02:21 UTC 
Created attachment 1667073 [details]
terminal log and nmstate files to reproduce

Description of problem:
Changing bond mode from 1 to 5 fails

Version-Release number of selected component (if applicable):


How reproducible:
100%

Steps to Reproduce:
1. nmstatectl set 0_no_bond
2. nmstatectl set 1_initial_bond # create bond mode 1
3. nmstatectl set 2_changed_bond # try to create bond mode 5

Actual results:
Changing bond mode fails

Expected results:
Changing bond mode succeeds

Additional info:
Deleting the bond before applying the changed bond works.
Comment 1 Michael Burman 2020-03-03 09:41:34 UTC 
Reproduced also when trying to switch from bond mode 4 to 5 or 6
Comment 2 Till Maas 2020-03-03 20:41:42 UTC 
Dominik, is changing the bond mode a typical change that customers do? How important is it, that this is fixed in RHEL 8.2?
Comment 11 Gris Ge 2020-03-06 02:23:37 UTC 
It will be an ugly fix in nmstate.

Ideally, with NetworkManager fixed their problem, no changed would be required in nmstate.
Comment 12 Gris Ge 2020-03-09 12:19:14 UTC 
Found the root cause which is nmstate's fault.

Patch sent to upstream for review: https://github.com/nmstate/nmstate/pull/910
Comment 13 Gris Ge 2020-03-09 12:29:54 UTC 
*** Bug 1811389 has been marked as a duplicate of this bug. ***
Comment 15 Dominik Holler 2020-03-09 13:20:23 UTC 
Does the results from bug 1811389 means that the target release of the bug has to discussed again?
I think two NICs with the same MAC address are no acceptable state for layered products, because there is no comfortable workaround for users possible.
Comment 16 Michael Burman 2020-03-09 14:02:22 UTC 
Raising severity as this is much worse and it's now affecting the MAC addresses of the slaves.
Comment 17 Gris Ge 2020-03-09 14:46:11 UTC 
Patch been merged in upstream.


Downstream scratch build https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=27147692 passed CI tests.

The reason to request a blocker is this bug will left a system with multiple NIC sharing the same MAC address which could cause
terrible issues.
Comment 19 Till Maas 2020-03-09 15:13:29 UTC 
(In reply to RHEL Program Management from comment #3)

> Answer the following 3 questions:
> 1. What is the impact of waiting until the next release to include this BZ? 
> Reviewers want to know which RHEL features or customers are affected and if
> it will impact any Layered Product or Hardware partner plans.

The underlying issue of having multiple network interfaces with the same MAC after removing a bond interface is very likely to break a lot of workflows.

> 2. What is the risk associated with the fix?  Reviewers want to know if the
> fix is contained, testable, and there is enough time to verify the work
> without impact the schedule or other commitments.

We tested the change upstream and also asked RHV to test the downstream test already including CI tests from Nmstate upstream and RHV/Vdsm.

> 3. Provide any other details that should be weighed in making a decision
> (Other releases affected, upstream status, business impacts, etc).

Everything is prepared for an immediate downstream release:
https://src.osci.redhat.com/rpms/nmstate/pull-request/4
Comment 23 Mingyu Shi 2020-03-10 09:18:56 UTC 
nmstate-0.2.6-3.8.el8.noarch
NetworkManager-1.22.8-4.el8.x86_64

It works fine to switch among 7 modes, so does for creating bond with different modes. And after removing the bond, the slaves will get different MACs.
See the attachment for the details, it made switching modes at start, and then verified the MAC.
Comment 24 Mingyu Shi 2020-03-10 09:21:36 UTC 
Created attachment 1668835 [details]
verification.log
Comment 25 Gris Ge 2020-03-13 03:17:55 UTC 
nmstate-0.2.6-4.8.el8 fixed the regression for miimon=100 and MAC address issue.
Comment 27 errata-xmlrpc 2020-04-28 16:00:37 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://access.redhat.com/errata/RHBA-2020:1696
Note You need to log in before you can comment on or make changes to this bug.