Re: virtual interfaces [Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released]

[Dan Williams <dcbw redhat com>]

On Thu, 2014-06-19 at 12:58 +0200, Michael Biebl wrote:
> Am 17.06.2014 17:21, schrieb Michael Biebl:
> > Am 07.06.2014 02:20, schrieb Dan Williams:
> > > Hi,
> > >
> > > I'm pleased to announce the release of NetworkManager 0.9.9.95
> >
> > * Changes made to IP addresses, IP routes, and master/slave
> > relationships from
> >     external tools are now recognized and reflected in the D-Bus API
> >
> > I do have virtualbox and vmware installed on this particular laptop,
> > i.e. I have the following virtual interfaces: vboxnet0 and vmnet1/vmnet8.
> >
> > nmcli shows them as
> >
> > # nmcli d
> > DEVICE    TYPE      STATE         CONNECTION
> > vmnet1    ethernet  connected     vmnet1
> > vmnet8    ethernet  connected     vmnet8
> > wlan0     wifi      connected     wgrouter (automatisch)
> > vboxnet0  ethernet  disconnected  --
> > eth0      ethernet  unavailable   --
> > ttyACM0   gsm       unavailable   --
> > lo        loopback  unmanaged     --
> >
> >
> > # nmcli c
> > ...
> > vmnet8                       ef586f60-75cf-4717-8279-ed82c28c15cc
> > 802-3-ethernet   vmnet8
> > vmnet1                       105b4339-54a8-4fea-b6fe-2e2fafabff49
> > 802-3-ethernet   vmnet1
> > Kabelgebundene Verbindung 2  2cf491fd-a74d-4b65-84ac-789196009487
> > 802-3-ethernet   vboxnet0
>
> Looks like NM is creating more of those vmnet connections
> # nmcli c | grep vmnet
> vmnet8                       576ec95a-e3d3-4004-a1ad-825d0722e3e6
> 802-3-ethernet   --
> vmnet1                       1cdf6f65-b143-4e52-a970-8f6028c830df
> 802-3-ethernet   --
> vmnet8                       2055126c-f084-4ae3-b4de-150c95870b27
> 802-3-ethernet   --
> vmnet1                       f446a89c-3b3e-40db-a275-10dee6decca7
> 802-3-ethernet   --

This could be connection matching issues that we've been progressively
squashing.  NM tries to be safe and use an auto-generated connection
from the existing configuration instead of a stored one if the two
aren't the same, so that it doesn't disrupt the interface.  That's
probably what's happening here; and in this case, could you turn on
debug logging with --log-level=debug or "[logging]\nlevel=debug" in
NetworkManager.conf and see if you can reproduce the problem?  That
should dump the generated connection and also indicate why it didn't
match the stored one.

New with NM 0.9.9+ is that connections can be "unsaved" or "dirty" and
the changes will be lost if NM quits, unless they are explicitly saved
with the Connection.Save() method.  Generated connections are unsaved
from the start, which is why they don't show up on-disk.

Dan