Re: Where does NM persists which connection is active? (Centos7)

[Thomas Haller <thaller redhat com>]

On Sun, 2016-09-11 at 23:45 +0300, Edward Haas wrote:
> On Sun, Sep 11, 2016 at 10:56 PM, Thomas Haller <thaller redhat com>
> wrote:
> > On Sun, 2016-09-11 at 15:45 +0300, Edward Haas wrote:
> > > Hello,
> > >
> > > Assuming there are multiple connection defined for an ethernet
> > device
> > > and only a single one is active, how can I detect which ifcfg
> > file
> > > was used for the connection?
> > >
> > > I cannot use nmcli for this, as NetworkManager is down at the
> > moment
> > > I need the information.
> > > I just hope this info is available somewhere (as when starting
> > NM,
> > > the correct connection is activated).
> > >
> > > Thanks,
> > > Edy.
> >
> > Hi,
> >
> >
> > If NetworkManager is not running, there isn't a concept of "active
> > connection". What would that be?
> NM is defining multiple connection/ifcfg files, I hoped to have the
> last active one
> referenced somewhere.
> The fact that NM leaves multiple ifcfg files with autoconnect enabled
> is a problem,
> it is not a supported state for initscripts.

yes, NetworkManager is some cases supports more options than
initscripts and in other cases initscripts support something that
NetworkManager doesn't (OVS support). The aim is that NM supports
everything that initscripts does, but that will never be perfect.
See `man nm-settings-ifcfg-rh` for notable differences.
There is no aim that initscripts support everything that NetworkManager
does. Well... in a way it does, because if you have NetworkManager
running then initscripts will call to `nmcli connection up`.

Note that for NetworkManager connections could also be stored in other
backends, most notably the keyfile plugin with ini-files in
/etc/NetworkManager/system-connections. But I guess for your use-case
you can ignore that.


> > When NM starts and the device has IP configuration, NM will pick a
> > connection that matches to what is currently configured on the
> > interface. In my opinion, that is a wrong thing, but that is what
> > currently happens. https://bugzilla.gnome.org/show_bug.cgi?id=74644
> > 0 is
> > supposed to improve on that, and it also will write a state-file
> > that
> > contains which connection was active on a device when
> > NetworkManager
> > stopped.
>
> Is this considered for back-porting to centos7/rhel7?
>
> > When the device has no IP configuration at startup, NetworkManager
> > will
> > autoconnect one of the available connections. Thereby it takes into
> > account connection.autoconnect-priority and connection.timestamp.
> >
> >
> > Maybe it would be helpful to explain what you are trying to do as
> > an
> > end-goal. If NetworkManager is not running, why would you want to
> > know
> > which connection was active when it stopped?
> >  
> >
> > Thomas
>
> It is related to an oVirt node that is initially setup using Cockpit
> (through NM).
> Then, VDSM is installed and NM is disabled to avoid collisions.
> At this point, VDSM is required to acquire the last active ifcfg file
> and adjust it
> for VDSM.
> The problem is: There may be multiple such ifcfg files, so which one
> should be
> acquired and which should be just removed?
>
> This is actually an intermediate solution, I would prefer to either
> leave NM running
> and work with it, or ask it to 'ignore' devices.
> ifcfg is also something we should stop using directly.
> But all of these options won't happen in the immediate time frame,
> and we need
> something now.


if VDSM is the one stopping NetworkManager, can you not ask which
connections are active before stopping NM?

  nmcli -f all device show
  nmcli -f GENERAL.CON-UUID device show wlp3s0

  (or directly querrying the D-Bus API).


Thomas

Attachment: signature.asc
Description: This is a digitally signed message part