When an interface is configured outside of NetworkManager's knowledge (like libvirt's or docker's bridge), then NetworkManager generates an in-memory connection profile and pretends(!) that this is active. This is to show that something is going on with the device, and NetworkManager is supposed to touch that device.
Whether this pretend mode is of any use is a good question. It's obviously confusing. I actually do make use of this behaviour to have a dispatcher script that does something for such external devices, so it's not entirely useless. Also, it causes the output of `nmcli device` to show that *something* is going on there. Although, maybe that's more confusing than helpful. In any case, NetworkManager needs a way to express that something is happening with this devices, and this is the way it does that. It doesn't mean that NetworkManager actually touches the device. Comment 26 does not say what actual problem NetworkManager causes by this (aside the confusion to the user). Comment 26 also explains that `nm-online` gives wrong results. I think nm-online has one real use-case: to implement `NetworkManager-wait-online.service` (with the `--startup` option). Without the `--startup` option, I don't think it's of any use at all. It can only return "online" or "offline". It maps the NetworkManager's states "local", "site", and "global" to "online". I think that is is sensible, if you connect to a libvirt bridge some network is configured and nm-online considers that as "online". However I don't think that describing the online state in two words is meaningful and calling `nm-online` is not useful. For a while NetworkManager had a udev rule to automatically unmanage docker bridges. But that was dropped, because docker bridges are nothing special. It's a common thing that something aside NetworkManager configures an interface and NetworkManager must not interfere. So, what actual problems are causes by this? --- > 1) You should never need to create (actually *shouldn't* create) an ifcfg-* > file for a libvirt-created bridge. If proper operation requires this, then > there is definitely a bug. Right. NM doesn't. > 2) NetworkManager should never mess around with bridge devices created by other entities (e.g. libvirt, but really anyone else), and no special plugin should be required to make that happen. If we (libvirt) wanted NM to manage the bridge, we would create it via NM. Right. NM shouldn't. Does it? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1432599 Title: Network-manager tries to manage virbr0, which it should not Status in network-manager package in Ubuntu: Confirmed Status in network-manager package in Fedora: Won't Fix Bug description: Since a recent upgrade in vivid, nm is trying to manage virbr0. This results in my main machine not getting a real IP address on eth0, and virtual machines not being able to use the network. This is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1166199 ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: network-manager 0.9.10.0-4ubuntu11 ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1 Uname: Linux 3.19.0-9-generic x86_64 ApportVersion: 2.16.2-0ubuntu3 Architecture: amd64 CurrentDesktop: Unity Date: Mon Mar 16 12:36:07 2015 IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8) auto lo iface lo inet loopback InstallationDate: Installed on 2014-12-13 (92 days ago) InstallationMedia: Ubuntu 14.10 "Utopic Unicorn" - Release amd64 (20141022.1) IpRoute: default via 10.0.0.1 dev eth0 proto static metric 1024 10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.75 192.168.111.0/24 dev wlan0 proto kernel scope link src 192.168.111.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 NetworkManager.state: [main] NetworkingEnabled=true WirelessEnabled=true WWANEnabled=true WimaxEnabled=true SourcePackage: network-manager UpgradeStatus: No upgrade log present (probably fresh install) http_proxy: http://localhost:8118/ nmcli-nm: Error: command ['nmcli', '-f', 'all', 'nm'] failed with exit code 2: Error: Object 'nm' is unknown, try 'nmcli help'. no_proxy: localhost,127.0.0.0/8,::1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
