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 1679230 - Virtual devices (like ovs bridge) appear as unmanaged after deleting its profile
Summary: Virtual devices (like ovs bridge) appear as unmanaged after deleting its profile
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.1
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 1689408 1701002
TreeView+ depends on / blocked
 
Reported: 2019-02-20 16:19 UTC by Edward Haas
Modified: 2020-11-14 10:57 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:29:15 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
journal output (11.00 MB, text/plain)
2019-02-20 16:19 UTC, Edward Haas 		no flags Details
More focused journal output without checkpoint (30.81 KB, text/plain)
2019-02-20 16:42 UTC, Edward Haas 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3623 0 None None None 2019-11-05 22:30:36 UTC

Description Edward Haas 2019-02-20 16:19:06 UTC 
Created attachment 1536757 [details]
journal output

Description of problem:
Deleting a virtual device profile is supposed to also remove the device.
However, in some cases we see the underlying kernel device being removed but it appears in NM as "unmanaged" (`nmcli dev`).

Example:
# nmcli con
NAME  UUID                                  TYPE      DEVICE
eth1  4f056a0c-c974-486f-8e54-7cc66c005b86  ethernet  eth1  
eth2  d970aa6d-b291-489f-9f2a-9457c9a60e0b  ethernet  eth2  
# nmcli dev
DEVICE         TYPE           STATE      CONNECTION 
eth1           ethernet       connected  eth1       
eth2           ethernet       connected  eth2       
eth0           ethernet       unmanaged  --         
lo             loopback       unmanaged  --         
ovs-br0        ovs-bridge     unmanaged  --         
ovs0           ovs-interface  unmanaged  --         
ovs-port-eth1  ovs-port       unmanaged  --         
ovs-port-ovs0  ovs-port       unmanaged  --         
# ovs-vsctl show
a334d63e-7870-499e-8619-164e68fd82ee
    ovs_version: "2.0.0"

Appeared as part of nmstate integration tests.
Sometimes it has been seen after a checkpoint rollback.

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


How reproducible:
Randomly

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Edward Haas 2019-02-20 16:40:53 UTC 
Debugging with the checkpoint shows that this occurs when this procedure is taking place (part of nmstate tests):
OVS profiles are added in this order:
- internal-interface
- bridge 
- port

Then activating the internal-interface.
The activation fails with "error=nm-manager-error-quark: Master device 'ovs0' can't be activated: Device unmanaged or not available for activation (7)" message.


nmstate logs:

nmclient.py                 77 DEBUG    Executing NM action: func=add_connection_async
connection.py               63 DEBUG    Connection adding succeeded: dev=ovs0
nmclient.py                 77 DEBUG    Executing NM action: func=add_connection_async
connection.py               63 DEBUG    Connection adding succeeded: dev=ovs-br0
nmclient.py                 77 DEBUG    Executing NM action: func=add_connection_async
connection.py               63 DEBUG    Connection adding succeeded: dev=ovs-port-ovs0
nmclient.py                 77 DEBUG    Executing NM action: func=_safe_activate_async
nmclient.py                143 ERROR    NM main-loop aborted: Connection activation failed on connection_id ovs0: error=nm-manager-error-quark: Master device 'ovs0' can't be activated: Device unmanaged or not available for activation (7)


Attaching the logs for this specific case.
Comment 3 Edward Haas 2019-02-20 16:42:01 UTC 
Created attachment 1536774 [details]
More focused journal output without checkpoint
Comment 4 Edward Haas 2019-02-20 17:13:08 UTC 
Few observations:
- Creating the OVS profiles (bridge, port and internal interface) does not auto-activate them.
- When enforcing an order of their activation to: Bridge, port and internal-interface, it works.
Comment 5 Beniamino Galvani 2019-02-21 17:44:32 UTC 
So the problem is that with:

 [device]
 match-device=*
 managed=0

in the configuration, every time a connection for a software device
gets added, the corresponding device is created, in unmanaged state.
This is not limited to ovs connections:

 $ nmcli connection add type bond ifname bond3
 $ nmcli device | grep bond3
 bond3     bond        unmanaged     --

I'm looking into this.
Comment 6 Lubomir Rintel 2019-03-26 14:21:25 UTC 
I think that this fixes a similar issue:
https://github.com/freedesktop/NetworkManager/commit/8f2a8a52f0d1f8d82409cc044413629adfd454ab
Comment 7 Beniamino Galvani 2019-04-15 13:45:10 UTC 
Fixed:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/246c2dbe9a104efc3703093103401e0cd278ff5b
Comment 12 errata-xmlrpc 2019-11-05 22:29:15 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-2019:3623
Note You need to log in before you can comment on or make changes to this bug.