Bug #1432599 “Network-manager tries to manage virbr0, which it s...” : Bugs : network-manager package : Ubuntu

Revision history for this message

In Red Hat Bugzilla #1166199, Richard (richard-redhat-bugs) wrote on 2014-11-20:

#9

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#10

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#11

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#12

Created attachment 978433
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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#13

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#14

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-09:

#15

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Dan (dan-redhat-bugs) wrote on 2015-01-14:

#16

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

Revision history for this message

In Red Hat Bugzilla #1166199, Dan (dan-redhat-bugs) wrote on 2015-01-14:

#17

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?

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-01-15:

#18

Created attachment 980356
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?

Revision history for this message

In Red Hat Bugzilla #1166199, Laine (laine-redhat-bugs) wrote on 2015-03-03:

#19

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

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-03-04:

#20

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

Revision history for this message

In Red Hat Bugzilla #1166199, Laine (laine-redhat-bugs) wrote on 2015-03-04:

#21

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.

Revision history for this message

Franck (alci) wrote on 2015-03-16:

#1

CRDA.txt Edit (238 bytes, text/plain; charset="utf-8")
Dependencies.txt Edit (8.6 KiB, text/plain; charset="utf-8")
IpAddr.txt Edit (1.5 KiB, text/plain; charset="utf-8")
IwConfig.txt Edit (580 bytes, text/plain; charset="utf-8")
NetDevice.eth0.txt Edit (837 bytes, text/plain; charset="utf-8")
NetDevice.lo.txt Edit (225 bytes, text/plain; charset="utf-8")
NetDevice.virbr0.txt Edit (386 bytes, text/plain; charset="utf-8")
NetDevice.virbr0-nic.txt Edit (385 bytes, text/plain; charset="utf-8")
NetDevice.wlan0.txt Edit (865 bytes, text/plain; charset="utf-8")
NetworkManager.conf.txt Edit (75 bytes, text/plain; charset="utf-8")
PciNetwork.txt Edit (1.2 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (103 bytes, text/plain; charset="utf-8")
RfKill.txt Edit (182 bytes, text/plain; charset="utf-8")
WifiSyslog.txt Edit (147.7 KiB, text/plain; charset="utf-8")
nmcli-con.txt Edit (3.7 KiB, text/plain; charset="utf-8")
nmcli-dev.txt Edit (1.0 KiB, text/plain; charset="utf-8")

Franck (alci) on 2015-03-16

description:

updated

Revision history for this message

Franck (alci) wrote on 2015-03-19:

#2

Here is a bug report, related to the subject: https://bugzilla.gnome.org/show_bug.cgi?id=731014

Notice vboxnet0 also appears in nm-applet, but is shown as Unmanaged, unlike virbr0.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-03-30:

#3

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

Changed in network-manager (Ubuntu):
status:	New → Confirmed

Revision history for this message

Andreas Olsson (andol) wrote on 2015-03-30:

#4

Taking a cue from https://bugzilla.redhat.com/show_bug.cgi?id=1166199 I worked around the issue by adding the following to my /etc/NetworkManager/NetworkManager.conf

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

Yet I imagine that the real solution is something more general.

Changed in network-manager (Ubuntu):
importance:	Undecided → Medium

Revision history for this message

Franck (alci) wrote on 2015-03-30:

#5

Here is the feedback I got from the network-manager mailing list:

On Thu, 2015-03-19 at 09:18 +0100, Franck Routier (perso) wrote:
> Hi list,
>
> I'm using Ubuntu and just upgraded to (still in development) Vivid.
> Now I see that network-manager handles my virbr0 bridge (libvirt), which
> it didn't before.

NM will recognize and "manage" all network interfaces, but that does not
mean that NM actually touches the interfaces. If the interface already
has a configuration, NM simply assumes the existing configuration and
waits for you to tell it to do something. That's a difference from
older versions of NM (0.9.8 and earlier) where NM was mostly ignorant of
existing configuration.

We know that NM 0.9.10 still has a few edge cases where it touches
interfaces and shouldn't, but almost all of those have already been
fixed in NM 1.0 and later.

Dan

Revision history for this message

Franck (alci) wrote on 2015-03-30:

#6

The "

/etc/NetworkManager/NetworkManager.conf

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

"

indeed does the trick.

Revision history for this message

In Red Hat Bugzilla #1166199, Luboš (lubo-redhat-bugs) wrote on 2015-04-22:

#22

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2015-04-22:

#23

I did:
* net-destroy default
* deleted virbr0 from network manager connection editor
* net-start default

result:
network manager applet still shows virbr0 interface

Revision history for this message

In Red Hat Bugzilla #1166199, Luboš (lubo-redhat-bugs) wrote on 2015-04-22:

#24

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

Revision history for this message

In Red Hat Bugzilla #1166199, Wayne (wayne-redhat-bugs) wrote on 2015-07-08:

#25

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Mr. (mr.-redhat-bugs) wrote on 2015-07-11:

#26

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

Revision history for this message

In Red Hat Bugzilla #1166199, Fedora (fedora-redhat-bugs) wrote on 2015-08-18:

#27

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

Revision history for this message

RobertDahlström (cinnarob) wrote on 2015-10-30:

#7

For me this happened after upgrade from 15.04 to 15.10.
Adding suggested fix to NetworkManager.conf solved the issue.

Revision history for this message

In Red Hat Bugzilla #1166199, Fedora (fedora-redhat-bugs) wrote on 2015-11-04:

#28

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Fedora (fedora-redhat-bugs) wrote on 2015-12-02:

#29

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Aleksandar (aleksandar-redhat-bugs) wrote on 2016-01-03:

#30

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Andrej (andrej-redhat-bugs) wrote on 2016-04-11:

#31

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.

Revision history for this message

Trent McPheron (tiz-ex1) wrote on 2016-05-27:

#8

This affected me when I went from Xubuntu 15.10 to 16.04; the wired network icon would be shown whenever I wasn't connected to any actual networks, and adding the config tweak in #4 triages the issue for me.

Revision history for this message

In Red Hat Bugzilla #1166199, James (james-redhat-bugs) wrote on 2016-05-29:

#32

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

Revision history for this message

In Red Hat Bugzilla #1166199, Fedora (fedora-redhat-bugs) wrote on 2016-11-24:

#33

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.

Revision history for this message

In Red Hat Bugzilla #1166199, Fedora (fedora-redhat-bugs) wrote on 2016-12-20:

#34

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.

Bug Watch Updater (bug-watch-updater) on 2017-10-28

Changed in network-manager (Fedora):
importance:	Unknown → High
status:	Unknown → Won't Fix

Ubuntu
network-manager package

Network-manager tries to manage virbr0, which it should not

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Fedora)	Won't Fix	High	redhat-bugs #1166199
	network-manager (Ubuntu)	Confirmed	Medium	Unassigned

Ubuntunetwork-manager package

Network-manager tries to manage virbr0, which it should not

Bug Description

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
network-manager package