Description of problem:
stalled vlan after this test scenario:
nmcli connection add type vlan con-name vlan dev eth1 id 80
nmcli connection modify vlan eth.mtu 1450 ipv4.method manual ipv4.addresses 220.127.116.11/24
nmcli connection up id testeth1
nmcli con up id vlan
systemctl restart NetworkManager
nmcli con del vlan
eth1.80 vlan unmanaged --
Version-Release number of selected component (if applicable):
Steps to Reproduce:
device should be deleted
Created attachment 1200967 [details]
Red Hat Enterprise Linux Server release 7.3 Beta (Maipo)
# nmcli con del vlan
# nmcli device
DEVICE TYPE STATE CONNECTION
p6p1.80 vlan disconnected --
Red Hat Enterprise Linux Server release 7.2
the device was deleted
(In reply to Aniss from comment #2)
> Red Hat Enterprise Linux Server release 7.2
> NetworkManager 1.0.6-27.el7
> the device was deleted
not really, I missed a step here (systemctl restart NetworkManager). I tried it again and I got:
DEVICE TYPE STATE CONNECTION
em1.80 vlan disconnected --
Hi, in this scenario NM tries to fulfill these two goals:
- keeping the connection up when NM is stopped, to avoid breaking
- don't destroy software devices that already existed when NM started
If these two are satisfied, the result is exactly what you see, that
after a restart NM finds a pre-existing vlan device and will not
delete it upon disconnect.
We have planned to rework how the connection assumption works and that
change will probably improve this scenario; see bug  for more details.
For now I propose to close this, as NM is behaving as expected.
Now that we have a state file to persist the device state on daemon restart, we could save there whether the device was created by NM or not, and do the right thing after restart. Implementation in branch:
I dislike a bit that there is nm_device_set_nm_owned(), so the device gets fully realized, and only then we set the flag.
How about nm_device_realize_start() and nm_device_create_and_realize() having an argument "nm_owned", and the caller (NMManager) determines for the device whether it is nm-owned -- and it should do so very early when realizing the device.
(In reply to Thomas Haller from comment #6)
> How about nm_device_realize_start() and nm_device_create_and_realize()
> having an argument "nm_owned", and the caller (NMManager) determines for the
> device whether it is nm-owned -- and it should do so very early when
> realizing the device.
These functions are called from 6 different places and I prefer not to
patch all those to load the state. Instead, how about setting nm-owned
in realize_start_setup(), which is called by both functions? Repushed
yeah, the place is good.
could we move it a bit up, I think it should set as early as possible.
Maybe immediately after _add_capabilities() (because we check for NM_DEVICE_CAP_IS_SOFTWARE).
Otherwise lgtm. This might fix CI failure bug 1452062. Will test tomorrow.
(In reply to Thomas Haller from comment #8)
> yeah, the place is good.
> could we move it a bit up, I think it should set as early as possible.
> Maybe immediately after _add_capabilities() (because we check for
Branch bg/nm-owned-persist-rh1376199 updated.
Merged to master:
(In reply to Beniamino Galvani from comment #11)
> Merged to master:
I did a related follow-up patch (merged to master as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=d83848be9dfd0edb5f318b81854b371133d84f6e )
I also backported bg/nm-owned-persist-rh1376199 branch + the follow-up patch to nm-1-8, as:
please see https://bugzilla.redhat.com/show_bug.cgi?id=1452062#c7 for rhel-7.4 backport.
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.