Re: NetworkManager behavior answers not found in docs


thanks for your answers. Very useful !
Much content to digest ;-)

you can ignore
initscripts entirely.

I know, I was just curious about how they used D-Bus and nmcli and how compatibility worked both ways (network-scripts <-> NM)

There is little difference

   - `nmcli connection up "$PROFILE"` will find a suitable device
   - `nmcli device connect "$DEVICE"` will find a suitable connection
automatically. Note this may create a new profile (see later).
   - `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly selects
both the profile and the device.


As the profile contains the necessary settings for what to do with the
device, you cannot ~configure~ a device without a profile.


re-activating can be done via `nmcli connection up` (or similar) and
goes through a full re-activation cycle (and temporarily disconnects
you). A more graceful way is `nmcli device reapply "$DEVICE"` which
takes the changes and configured on the device.

`nmcli device reapply` may also be useful if there are no actual
changes in the device. For example, it will re-start DHCP and restore
IP address configuration (if it was modified, for example via iproute).

You see, when a profile is activated on a device, the original settings
were internally copied and those are "applied". And "nmcli device
reapply" just updates the "applied" clone to be the current profile and
does the changes.

ok, so those details apart,

- profile is applied or re-applied to a device
- connection is up-ed or activated
- profile is activated
- device is connected

are kind of synonymous ?

Usually, NetworkManager (the daemon) does not automatically create
connection profiles

But when it does (as in your cases), is it always only in RAM (unless we then save the profile to disk of course) ?

Regarding "autoconnect", that is a property of the connection profile

So in a way, when a profile is autocreated and activated, it is first created with this property which make it then immediatly (auto)connect, correct ?

   - per-device: nmcli device set $DEVICE autoconnect no

this confuses me since we just said autoconnection was a property of a profile and this command deals with a device ?

"Autoconnect" prefers profiles which
were active last

Same remark here

If a device is unmanaged, NetworkManager does nothing with it. It won't
autocreate a profile for it, and it won't autoactivate anything >
Depending on the reasons why it's unmanaged, you still can let
NetworkManager take over, either via

   nmcli device set $DEVICE managed yes

or simply `nmcli con up` or `nmcli device connect`.

My understanding is that a device is managed by default unless explicitly set to unmanaged (via one of the several ways you described)

Also, that profile autocreation works (when its not forbidden by no-auto-default for instance) only on managed devices

So in your above example I don't understand how nmcli con up alone or nmcli device connect alone would actually create the profile without the device set managed yes first ?

Or maybe nmcli con up or device connect would create a profile and apply it but the device would still be unmanaged ?

Also, since adding a profile creates a persistent profile (provided the save option is not set to false), is there a point to set a device to managed when a persistent profile for it exists ? I mean the persistent profile would make NM "manage" the device even if not really set to managed yes ?

Let's take the following use case as an example :

- a host with 2 ethernet devices : eth0 and eth1

- eth0 has a network-script like connection file
(/etc/sysconfig/network-scripts/ifcfg-eth0) and is NetworkManager
managed (either by default because no "NM_CONTROLLED=no" is stated
explicitly with "NM_CONTROLLED=yes")
- eth1 has no connection file (neither ifcfg-rh style nor keyfile
that is nothing for eth1 neither in /etc/sysconfig/network-scripts
in /etc/NetworkManager/system-connections)

- no NM_UNMANAGED=1 in udev

test 1 :

-> after boot, as expected eth0 is configured and up, nmcli shows a
connection for it but eth1 has no connection. It has to be manually
connected for that matter. If done, NetworkManager seems to auto
magically CREATE the connection

I guess, on CentOS you have a package NetworkManager-config-server,
which installs a file /usr/lib/NetworkManager/conf.d/00-server.conf

That's not the case for me : I don't see any no-auto-default anywhere which could match eth1 or any at all (I only have 10-slaves-order.conf in conf.d)

By default, without any profiles files, would be my eth1 device managed or unmanaged (I would guess managed since I'm not in any case you describe where a device could be unmanaged) ?

So shouldn't NM have auto created a temp profile and auto connected it for my eth1 ?

man nmcli:

        connect ifname
            Connect the device. NetworkManager will try to find a suitable connection that will be activated. 
It will also consider connections that are not set to auto

ok. It's not described. That's a documentation bug.

So you confirm that unless a device in explictly unmanaged, a device connect would not only look for declared profiles but would also if no suitable profile is found create a temp profile creation and activate it ?

test 2 under the same conditions :

- reboot of the host
- only one connection (eth0) as expected
- create the foobar connection like this

      nmcli connection add type ethernet con-name foobar ifname eth1

-> as expected a ifcgh-rh format connection file has been created in
/etc/sysconfig/network-scripts/ifcfg-foobar and nmcli shows 2
connections : eth0 and foobar

- manually delete foobar connection file : rm

-> as expected nmcli still shows foobar connection

- reload connection files via nmcli connection reload

-> as expected nmcli only shows eth0 connection

So far, everything seems to work as expected BUT :

if instead of nmcli connection reload we RESTART (not reload, but
restart) NetworkManager via systemctl restart NetworkManager,
(different UUID and eth1 instead of foobar for the name) connection
auto created and auto activated

Yes, that is case 3). NM (re) starts and sees the the device is already

you mean via the /run state dir we talked about ?

It has no configuration for that device

You mean no more persistent profile ?

Those 2 above facts seems contradictory to me : if the device is "already configured" doesn't it mean that it has some in RAM profile applied ? Then NM hasn' "no configuration for that device" ?

, so it assumes
somebody else was configuring it and does not touch it. This eth0
device is no longer managed by NetworkManager. For example, it does no
DHCP and your addresses will time out.

Sorry for the confusion. I'm sure that when sorted out, those concepts are simple ;-)

Thank you

Thomas Hummel

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]