Bug 1166199 - NetworkManager now managing virbr0
NetworkManager now managing virbr0
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
23
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-11-20 09:55 EST by Richard W.M. Jones
Modified: 2016-12-20 07:57 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 07:57:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
log from systemctl restart NetworkManager (32.04 KB, text/plain)
2015-01-09 17:40 EST, Aleksandar Kostadinov
no flags Details
sudo journalctl -b -u NetworkManager (111.04 KB, text/plain)
2015-01-15 02:50 EST, Aleksandar Kostadinov
no flags Details

  None (edit)
Description Richard W.M. Jones 2014-11-20 09:55:32 EST
Description of problem:

Since I upgraded to Fedora 21, NetworkManager is now offering
to manage virbr0.  In fact, if I disconnect from wireless,
then it falls back to "helpfully" connecting me to virbr0, which
is of course completely useless.

More seriously, I suspect that NM is actually breaking virbr0.
For some reason, virbr0-nic became disconnected from the virbr0
bridge, and that broke all libvirt networking, and I suspect
this happened about the time that NM decided to connect my
main network to virbr0.

I've no idea what we can do about this, or even which component
this belongs to.

On my machine I tried adding:
NM_CONTROLLED=no
to /etc/sysconfig/network-scripts/ifcfg-virbr0
although this has so far not made any difference (but
I haven't rebooted yet).

Version-Release number of selected component (if applicable):

libvirt-1.2.9-4.fc21.x86_64
NetworkManager-0.9.10.0-13.git20140704.fc21.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Use Fedora 21 and libvirt and NM.
Comment 1 Aleksandar Kostadinov 2015-01-09 16:55:24 EST
Any update on this? It's been close to 2 months. I just performed a fedup to 21 and I hit the same issue. My em1 device remains disconnected and virbr0 is shown connected but of course I can't get internet through it. Good that at least wifi works though.
Comment 2 Aleksandar Kostadinov 2015-01-09 17:11:14 EST
looks like re-occurrence of bug 1063545 and bug 1064441
I'm changing product and version to fedora21 as it looks like a network manager issue.
Comment 3 Aleksandar Kostadinov 2015-01-09 17:40:56 EST
Created attachment 978433 [details]
log from systemctl restart NetworkManager

I've got rid of virbr0 device by putting into /etc/NetworkManager/NetworkManager.conf the following content:

> [keyfile]
> unmanaged-devices=interface-name:virbr0

It also should support unmanaged-devices=mac:...

But I still can't get em1 to connect. Attaching what I get from /var/log/messages on NetworkManager service restart.
Comment 4 Aleksandar Kostadinov 2015-01-09 17:47:23 EST
Forgot to say that running dhcp manually brings up the interface just fine:
> $ sudo dhclient -d em1
> Internet Systems Consortium DHCP Client 4.3.1
> Copyright 2004-2014 Internet Systems Consortium.
> All rights reserved.
> For info, please visit https://www.isc.org/software/dhcp/
> 
> Listening on LPF/em1/3c:97:0e:19:30:f9
> Sending on   LPF/em1/3c:97:0e:19:30:f9
> Sending on   Socket/fallback
> DHCPREQUEST on em1 to 255.255.255.255 port 67 (xid=0x37c3b531)
> DHCPREQUEST on em1 to 255.255.255.255 port 67 (xid=0x37c3b531)
> DHCPACK from 192.168.1.1 (xid=0x37c3b531)
> bound to 192.168.1.145 -- renewal in 19334 seconds.
Comment 5 Aleksandar Kostadinov 2015-01-09 18:03:58 EST
Very strange, after restarting the router, network manager started to successfully start the em1 interface. Before restarting the router, only manual dhclient request was working. Can that be related to leasing IP? I couldn't find how to configure that in NetworkManager :(

> After connection though I see the following in the log:
> Jan 10 00:56:36 localhost NetworkManager[7383]: <info>  Activation (em1) successful, device activated.
> Jan 10 00:56:36 localhost dnsmasq[8458]: started, version 2.72 cachesize 400
> Jan 10 00:56:36 localhost dnsmasq[8458]: compile time options: IPv6 GNU-getopt DBus no-i18n IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect
> Jan 10 00:56:36 localhost dnsmasq[8458]: using nameserver 192.168.1.1#53
> Jan 10 00:56:36 localhost dnsmasq[8458]: cleared cache
> Jan 10 00:56:36 localhost dbus[1023]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service'
> Jan 10 00:56:36 localhost dbus[1023]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory.
> Jan 10 00:56:36 localhost NetworkManager[7383]: <info>  NetworkManager state is now CONNECTED_GLOBAL

I'm referring to "dbus-org.freedesktop.nm-dispatcher.service failed to load" message.
Comment 6 Aleksandar Kostadinov 2015-01-09 18:16:57 EST
hmm, last comment. I've noticed that with the above setup the virbr interface does not go up so I don't see my VMs. I removed the `unmanaged-devices` configuration, restarted the laptop and now everything works like a charm. WTH?!

I think experience could have been better out of the box. Not sure what caused all the trouble.
Comment 7 Dan Williams 2015-01-14 14:23:14 EST
(In reply to Aleksandar Kostadinov from comment #3)
> Created attachment 978433 [details]
> log from systemctl restart NetworkManager
> 
> I've got rid of virbr0 device by putting into
> /etc/NetworkManager/NetworkManager.conf the following content:
> 
> > [keyfile]
> > unmanaged-devices=interface-name:virbr0
> 
> It also should support unmanaged-devices=mac:...
> 
> But I still can't get em1 to connect. Attaching what I get from
> /var/log/messages on NetworkManager service restart.

Note that the em1 issue you see in this log is https://bugzilla.gnome.org/show_bug.cgi?id=739482 and should be fixed in an F21 update very soon.
Comment 8 Dan Williams 2015-01-14 15:18:34 EST
I cannot reproduce with latest F21 NetworkManager-0.9.10.1-1.git20150105.fc21.  When NM starts up, it leaves virbr0 alone and shouldn't be starting DHCP on it. virbr0 has its own 192.168.122.1 address which NM leaves in place.

If you experience this issue still, could you grab:

journalctl -b -u NetworkManager

and attach that shows the issue?
Comment 9 Aleksandar Kostadinov 2015-01-15 02:50:23 EST
Created attachment 980356 [details]
sudo journalctl -b -u NetworkManager

Attaching journal from:
NetworkManager-0.9.10.1-1.2.20150109git.fc21.x86_64

perhaps I need to give some more details. My laptop was first installed with fedora18, then fedup to 20 and now fedup to 21. So the bridge was probably created in the fedora 18 times. I don't have /etc/sysconfig/network-scripts/ifcfg-virbr0, I'm not sure what and how is creating that bridge interface on boot.

Perhaps a simple recreate of the bridge would fix the issue? How can I do that?
Comment 10 Laine Stump 2015-03-03 11:54:05 EST
libvirt's bridge devices are never listed (and shouldn't ever be listed!) in an ifcfg file. They are created by libvirtd when it is started, and NM shouldn't be touching them, attaching things to them, or even displaying them (and it shouldn't take an "unmanaged-devices" line in /etc/NetworkManager/NetworkManager.conf to make that happen).

If you notice that NM is doing something with your virbrX bridges, don't try to fix it by creating an ifcfg file for that device, that will only make matters worse, as NM will now have tacit permission to manage the device, and even to create a new device with that name the next time the system boots (which will result in libvirt being unable to start its virtual network that uses that bridge).
Comment 11 Aleksandar Kostadinov 2015-03-04 10:58:40 EST
@Laine, so what do you suggest us to do? What I did at least fixed NM to touch the virt interface. If you know how to fix properly, please explain.
Comment 12 Laine Stump 2015-03-04 12:05:43 EST
Well, the way to fix it properly is for NM to stop messing with devices that it has no business messing with :-). In the meantime, if adding the "unmanaged-devices" line to NetworkManager.conf is the only workaround to get you going, then definitely use it! (to be more precise - my intent wasn't to say that you should never do that, but rather that you shouldn't *have to* do that. Conversely, adding an ifcfg file for the libvirt network's bridge actually won't help matters at all (will actually make things even more broken), and so should never be done).

Have you tried removing that line with the most recent F21 updates? I have updates and updates-testing enabled on my F21 machine; while "nmcli list" does still show virbr0 and virbr0-nic as "connected" (implying that it is still attempting to "manage" them at some level), it at least hasn't messed with the IP address of virbr0, or disconnected virbr0-nic from virbr0 or tried to set it ~IFF_UP.
Comment 13 Luboš Uhliarik 2015-04-22 04:27:19 EDT
if NM destroyed your virbr0 connection, you can try to create virbr0 again by yourself typing:

$ virsh

virsh # net-destroy default
virsh # net-start default


After executing these commands, there should be newly configured virbr0.
Comment 14 Aleksandar Kostadinov 2015-04-22 10:03:53 EDT
I did:
* net-destroy default
* deleted virbr0 from network manager connection editor
* net-start default

result:
network manager applet still shows virbr0 interface
Comment 15 Luboš Uhliarik 2015-04-22 10:23:31 EDT
(In reply to Aleksandar Kostadinov from comment #14)
> I did:
> * net-destroy default
> * deleted virbr0 from network manager connection editor
> * net-start default
> 
> result:
> network manager applet still shows virbr0 interface

Yes, NM will show vibr0 interfaces anyway, but the commands, which I posted, should help you in case, when NM disconnects your virbr0 interface and then it keeps connecting it. 

When virbr0 was in "connecting" state, I was not able to reach my virtual machines until reboot. But then, I found net-destroy and net-start commands and after their execution, I don't need to reboot to fix network connection to my VMs.
Comment 16 Wayne Walker 2015-07-08 10:39:16 EDT
I have the same problem.  I am running F 21 in a VM under VMware Fusion 7 Pro.

I'm not running xen, or any other virtual hypervisor in the VM.

But I've had the constantly orbiting green ball from vibr0 as long as I can remember.

I just added "unmanaged-devices=vibr0" to /etc/NetworkManager/NetworkManager.conf and restarted NetworkManager via systemctl.  That made it stop.  Thank you Laine!

However, NM shouldn't have been managing vibr0 in the first place.
Comment 17 Mr. Meval 2015-07-11 04:16:59 EDT
(In reply to Aleksandar Kostadinov from comment #3)
> Created attachment 978433 [details]
> log from systemctl restart NetworkManager
> 
> I've got rid of virbr0 device by putting into
> /etc/NetworkManager/NetworkManager.conf the following content:
> 
> > [keyfile]
> > unmanaged-devices=interface-name:virbr0
> 
> It also should support unmanaged-devices=mac:...
> 
> But I still can't get em1 to connect. Attaching what I get from
> /var/log/messages on NetworkManager service restart.

This fixed my issue in a clean install of Fedora release 22 (Twenty Two) workstation. /etc/sysconfig/network-scripts/ifcfg-virbr0 does not exist.
Comment 18 Fedora Admin XMLRPC Client 2015-08-18 10:57:47 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 19 Fedora End Of Life 2015-11-04 05:40:23 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 20 Fedora End Of Life 2015-12-02 00:06:06 EST
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 21 Aleksandar Kostadinov 2016-01-03 16:20:09 EST
Just upgraded to fedora 23 and I still see `virbr0` interface in Network Manager applet.

This time though `unmanaged-devices=interface-name:virbr0` fixes the issue (after restart).

I'm reopening the issue so that Network Manager automatically ignores such interfaces.
Comment 22 Andrej 2016-04-11 06:15:42 EDT
The same case here.

unmanaged-devices=interface-name:virbr0 did the trick.

This is especially problematic during the "offline" work when you don't have other connections active: NM is announcing to other applications that there are available network connections and then applications are all making unsuccessful attempts to get network resources polluting the notification system.
Comment 23 James Caldwell 2016-05-29 01:57:29 EDT
This crap came back recently and it's ignoring the unmanaged command in the conf file.

NetworkManager-wwan-1.0.12-2.fc23.x86_64
NetworkManager-vpnc-gnome-1.0.8-1.fc23.x86_64
NetworkManager-openvpn-1.0.8-2.fc23.x86_64
NetworkManager-vpnc-1.0.8-1.fc23.x86_64
NetworkManager-config-connectivity-fedora-1.0.12-2.fc23.x86_64
NetworkManager-1.0.12-2.fc23.x86_64
NetworkManager-pptp-gnome-1.1.0-2.20150428git695d4f2.fc23.x86_64
NetworkManager-openswan-gnome-1.0.8-3.fc23.x86_64
NetworkManager-wifi-1.0.12-2.fc23.x86_64
NetworkManager-pptp-1.1.0-2.20150428git695d4f2.fc23.x86_64
NetworkManager-iodine-gnome-0.0.5-2.fc23.x86_64
NetworkManager-openvpn-gnome-1.0.8-2.fc23.x86_64
NetworkManager-openswan-1.0.8-3.fc23.x86_64
NetworkManager-team-1.0.12-2.fc23.x86_64
NetworkManager-glib-1.0.12-2.fc23.x86_64
NetworkManager-l2tp-0.9.8.7-4.fc23.x86_64
NetworkManager-bluetooth-1.0.12-2.fc23.x86_64
NetworkManager-iodine-0.0.5-2.fc23.x86_64
NetworkManager-adsl-1.0.12-2.fc23.x86_64
NetworkManager-libnm-1.0.12-2.fc23.x86_64
NetworkManager-openconnect-1.0.8-1.fc23.x86_64

Linux tower.meval 4.5.5-201.fc23.x86_64 #1 SMP Sat May 21 15:29:49 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Comment 24 Fedora End Of Life 2016-11-24 06:17:48 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 25 Fedora End Of Life 2016-12-20 07:57:33 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.