NM in vivid tries to take over my libvirt bridge, deconfigures its address

[Steve Langasek]

Over the past couple of months in vivid, from time to time I have noticed that my virbr0 interface, which is set up and managed by libvirt-bin, has been in an "up" state with no IP address configured.

As I don't use VMs on my laptop very frequently, I don't know when the problem started and I don't know when exactly the problem is being triggered. But a search through logs shows the following:

Mar 16 16:48:56 virgil systemd[1]: Stopping Network Manager...
[...]
Mar 16 16:48:56 virgil NetworkManager[32588]: <info> (virbr0): device state change: activated -> deactivating (reason 'removed') [100 110 36]
Mar 16 16:48:56 virgil NetworkManager[32588]: <info> (virbr0): device state change: deactivating -> unmanaged (reason 'removed') [110 10 36]
Mar 16 16:48:56 virgil NetworkManager[32588]: <info> (virbr0): deactivating device (reason 'removed') [36]
Mar 16 16:48:56 virgil avahi-daemon[1336]: Withdrawing address record for 192.168.122.1 on virbr0.
[...]
Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager Script Dispatcher Service...
[...]
Mar 16 16:48:56 virgil systemd[1]: Started Network Manager Script Dispatcher Service.
[...]
Mar 16 16:48:56 virgil nm-dispatcher: Dispatching action 'down' for virbr0
[...]
Mar 16 16:48:56 virgil systemd[1]: Starting Network Manager...
[...]
Mar 16 16:48:56 virgil NetworkManager[6097]: <info> devices added (path: /sys/devices/virtual/net/virbr0, iface: virbr0)
Mar 16 16:48:56 virgil NetworkManager[6097]: <info> device added (path: /sys/devices/virtual/net/virbr0, iface: virbr0): no ifupdown configuration found.
[...]
Mar 16 16:49:01 virgil systemd[1]: Started Network Manager.
[...]
Mar 16 16:49:02 virgil NetworkManager[6097]: <info> (virbr0): carrier is OFF
Mar 16 16:49:02 virgil NetworkManager[6097]: <info> (virbr0): new Bridge device (driver: 'bridge' ifindex: 5)
Mar 16 16:49:02 virgil NetworkManager[6097]: <info> (virbr0): exported as /org/freedesktop/NetworkManager/Devices/4
Mar 16 16:49:02 virgil NetworkManager[6097]: <info> (virbr0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
Mar 16 16:49:02 virgil NetworkManager[6097]: <warn> (virbr0): device not up after timeout!
Mar 16 16:49:02 virgil NetworkManager[6097]: <info> (virbr0): preparing device
Mar 16 16:49:02 virgil NetworkManager[6097]: nm_device_get_device_type: assertion 'NM_IS_DEVICE (self)' failed

The interface 'virbr0' also shows up in nm-applet's display, which was never the case before. This interface has always been managed by the libvirt-bin startup scripts (which causes problems of its own, since a 'service libvirt-bin restart' does not reinitialize the network and a 'service libvirt-bin stop' does not stop it). The bring-up of virbr0 appears to still be handled by libvirt-bin, not by NM; but somehow NM has a device configuration for it and is downing the interface on service stop - and not restoring it on service start.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: network-manager 0.9.10.0-4ubuntu13
ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0
Uname: Linux 3.19.0-7-generic x86_64
ApportVersion: 2.17-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Wed Apr 1 15:48:28 2015
InstallationDate: Installed on 2010-09-24 (1650 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
IpRoute:
 default via 192.168.15.1 dev wlan2 proto static metric 1024
 169.254.0.0/16 dev virbr0 scope link metric 1000
 192.168.15.0/24 dev wlan2 proto kernel scope link src 192.168.15.71
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
 207.224.24.209 via 192.168.15.1 dev wlan2 proto dhcp metric 10
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WWanEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to vivid on 2014-12-06 (116 days ago)
nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mike Pontillo (mpontillo)]

I'm seeing this on Trusty for VLAN interfaces. In the log I see:

<info> (eth0.1): carrier is OFF
<info> (eth0.1): VLAN ID 1 with parent eth0
<info> (eth0.1): new VLAN device (driver: '8021q' ifindex: 26)
<info> (eth0.1): exported as /org/freedesktop/NetworkManager/Devices/18
<info> (eth0.1): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
<info> (eth0.1): deactivating device (reason 'managed') [2]

In /etc/NetworkManager/NetworkManager.conf I have:

[ifupdown]
managed=false

... which should mean that anything listed in /etc/network/interfaces should be ignored.

In my /etc/network/interfaces file I have:

auto eth0.1
iface eth0.1 inet static
  address 100.64.0.1/24

So NetworkManager is incorrectly marking this interface as managed. (according to the man page, you don't need "auto" for non-physical interfaces, but I tried putting it in there anyway, in case NetworkManager was looking for it in /etc/network/interfaces)

[Mike Pontillo (mpontillo)]

I missed some relevant logs:

SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/eth0.1, iface: eth0.1)
SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/eth0.1, iface: eth0.1): no ifupdown configuration found.

From that, I think I found the root cause. After doing "apt-get source network-manager" and grepping for "no ifupdown configuration found", I looked in src/settings/plugins/ifupdown/plugin.c and found the function udev_device_added(), which does a g_hash_table_lookup() to find out if the interface is managed or not.

It appears that NetworkManager doesn't ever refresh its idea of the interfaces list. So if you edit /etc/network/interfaces, NetworkManager doesn't update its internal hashtable of unmanaged interfaces.

Therefore, the following is a workaround:

sudo invoke-rc.d network-manager restart
sudo ifup <desired-unmanaged-interface>