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

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:

I'm pleased to announce the release of NetworkManager

* 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
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.


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