Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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 1939911

Summary:	if not explicitly list, don't manage virtual interface
Product:	Red Hat Enterprise Linux 8	Reporter:	Mingyu Shi <mshi>
Component:	nmstate	Assignee:	Fernando F. Mancera <ferferna>
Status:	CLOSED WONTFIX	QA Contact:	Mingyu Shi <mshi>
Severity:	low	Docs Contact:
Priority:	low
Version:	8.4	CC:	ferferna, jiji, jishi, network-qe, sfaye, till
Target Milestone:	rc	Keywords:	Triaged
Target Release:	8.8	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-09-17 07:27:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mingyu Shi 2021-03-17 10:00:44 UTC

Description of problem:
According to https://bugzilla.redhat.com/show_bug.cgi?id=1932247 , if nmstate automatically manage an interface, that may cause problem. The fix in above bug works well on NIC/veth, but doesn't work on virtual interface, say dummy, bond etc.

Version-Release number of selected component (if applicable):
nmstate-1.0.2-5.el8.noarch
nispor-1.0.1-4.el8.x86_64
NetworkManager-1.30.0-2.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
echo 'interfaces:
- name: br0
  type: linux-bridge
  state: up' | nmstatectl set -
ip link add dummy0 type dummy
ip link set dummy0 up
ip link set dummy0 master br0
ip link show dummy0 | grep 'master br0'
echo 'interfaces:
- name: dummy1
  type: dummy
  state: up
- name: br0
  type: linux-bridge
  state: up
  bridge:
    port:
    - name: dummy1' | nmstatectl set -
ip link show dummy0 | grep 'master br0'
nmcli con

Actual results:
:: [ 17:41:46 ] :: [   PASS   ] :: Command 'echo 'interfaces:
- name: br0
  type: linux-bridge
  state: up' | nmstatectl set -' (Expected 0, got 0)
:: [ 17:41:46 ] :: [   PASS   ] :: Command 'ip link add dummy0 type dummy' (Expected 0, got 0)
:: [ 17:41:46 ] :: [   PASS   ] :: Command 'ip link set dummy0 up' (Expected 0, got 0)
:: [ 17:41:46 ] :: [   PASS   ] :: Command 'ip link set dummy0 master br0' (Expected 0, got 0)
:: [ 17:41:46 ] :: [   PASS   ] :: Command 'ip link show dummy0 | grep 'master br0'' (Expected 0, got 0)
:: [ 17:41:47 ] :: [   PASS   ] :: Command 'echo 'interfaces:
- name: dummy1
  type: dummy
  state: up
- name: br0
  type: linux-bridge
  state: up
  bridge:
    port:
    - name: dummy1' | nmstatectl set -' (Expected 0, got 0)
# now dummy0 doesn't master br0 anymore, and becomes managed
:: [ 17:41:47 ] :: [   FAIL   ] :: Command 'ip link show dummy0 | grep 'master br0'' (Expected 0, got 1)
[17:41:47@hp-dl388g10-01 ~/repo-nmstate/libnmstate]0# nmcli dev
DEVICE      TYPE      STATE         CONNECTION
eno5        ethernet  connected     eno5      
dummy0      dummy     connected     dummy0    
br0         bridge    connected     br0        
dummy1      dummy     connected     dummy1    


Expected results:
dummy0 stays untouched

Additional info:
If replace dummy0 as a real NIC or veth, it won't be managed except you explicitly list it 'interfaces' tree, like:
---
interfaces:
- name: dummy0

Comment 1 Gris Ge 2021-06-09 01:59:32 UTC

Hi Mingyu,

This should be fixed in nmstate-1.1.0-0.3.alpha3.el8 can you give it try?

Comment 2 Mingyu Shi 2021-06-22 09:47:02 UTC

Hi Fernando

I still reproduced it with nmstate-1.1.0-0.3.alpha3.el8.noarch.
Just run the same reproducer.

Comment 4 Fernando F. Mancera 2022-07-04 15:38:27 UTC

Hi Mingyu, I tried this out and I were not able to reproduce it. Do you have this section on /etc/NetworkManager/NetworkManager.conf?

[keyfile]
unmanaged-devices=interface-name:dummy0

Without this, the interface could be managed but connected externally, even if it was created with iproute2.

Comment 9 Mingyu Shi 2022-07-21 08:49:23 UTC

Hi Fernando,

It can be reproduced here, I didn't touch NetworkManager.conf. I understand some rules between default unmanaged and strictly unmanaged, but the key is using dummy and veth with the same rule results in different results respectively.
Please see the attachment above, you can see:
I run two YAML files, the only difference is one using dummy and another one using veth.
After running use-dummy.sh, dummy0 became managed and detached, while
after running use-veth.sh, veth0 stayed unmanged and attached.

Just wonder, is there some difference when nmstate/NetworkManager deal with dummy(or bond, bridge) vs veth(or NIC)?


I'm using
nmstate-1.3.1-1.el8.x86_64
nispor-1.2.3-1.el8.x86_64
NetworkManager-1.39.10-1.el8.x86_64

Comment 10 Fernando F. Mancera 2022-08-05 08:48:39 UTC

(In reply to Mingyu Shi from comment #9)
> Hi Fernando,
> 
> It can be reproduced here, I didn't touch NetworkManager.conf. I understand
> some rules between default unmanaged and strictly unmanaged, but the key is
> using dummy and veth with the same rule results in different results
> respectively.
> Please see the attachment above, you can see:
> I run two YAML files, the only difference is one using dummy and another one
> using veth.
> After running use-dummy.sh, dummy0 became managed and detached, while
> after running use-veth.sh, veth0 stayed unmanged and attached.
> 
> Just wonder, is there some difference when nmstate/NetworkManager deal with
> dummy(or bond, bridge) vs veth(or NIC)?
> 

It seems there are differences.. ideally, there shouldn't be differences.

I think this comes from NetworkManager because Nmstate shouldn't do anything different. If you think they should have a consistent behaviour please move the bug back to ASSIGNED/NEW and I will take care of it ASAP.

Thank you!!

Comment 11 Mingyu Shi 2022-08-05 09:19:01 UTC

Thanks, Fernando.

As the original issue was about veth/NIC, plus, so far no one complains about the behavior on bond, dummy or something.
I'm lowering the priority.

Comment 14 RHEL Program Management 2022-09-17 07:27:35 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.