Launchpad has imported 26 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1166199.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2014-11-20T14:55:32+00:00 Richard wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/0 ------------------------------------------------------------------------ On 2015-01-09T21:55:24+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/1 ------------------------------------------------------------------------ On 2015-01-09T22:11:14+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/2 ------------------------------------------------------------------------ On 2015-01-09T22:40:56+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/3 ------------------------------------------------------------------------ On 2015-01-09T22:47:23+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/4 ------------------------------------------------------------------------ On 2015-01-09T23:03:58+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/5 ------------------------------------------------------------------------ On 2015-01-09T23:16:57+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/6 ------------------------------------------------------------------------ On 2015-01-14T19:23:14+00:00 Dan wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/7 ------------------------------------------------------------------------ On 2015-01-14T20:18:34+00:00 Dan wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/8 ------------------------------------------------------------------------ On 2015-01-15T07:50:23+00:00 Aleksandar wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/9 ------------------------------------------------------------------------ On 2015-03-03T16:54:05+00:00 Laine wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/10 ------------------------------------------------------------------------ On 2015-03-04T15:58:40+00:00 Aleksandar wrote: @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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/11 ------------------------------------------------------------------------ On 2015-03-04T17:05:43+00:00 Laine wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/12 ------------------------------------------------------------------------ On 2015-04-22T08:27:19+00:00 Luboš wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/20 ------------------------------------------------------------------------ On 2015-04-22T14:03:53+00:00 Aleksandar wrote: I did: * net-destroy default * deleted virbr0 from network manager connection editor * net-start default result: network manager applet still shows virbr0 interface Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/21 ------------------------------------------------------------------------ On 2015-04-22T14:23:31+00:00 Luboš wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/22 ------------------------------------------------------------------------ On 2015-07-08T14:39:16+00:00 Wayne wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/23 ------------------------------------------------------------------------ On 2015-07-11T08:16:59+00:00 Mr. wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/24 ------------------------------------------------------------------------ On 2015-08-18T14:57:47+00:00 Fedora wrote: This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/25 ------------------------------------------------------------------------ On 2015-11-04T10:40:23+00:00 Fedora wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/27 ------------------------------------------------------------------------ On 2015-12-02T05:06:06+00:00 Fedora wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/28 ------------------------------------------------------------------------ On 2016-01-03T21:20:09+00:00 Aleksandar wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/29 ------------------------------------------------------------------------ On 2016-04-11T10:15:42+00:00 Andrej wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/30 ------------------------------------------------------------------------ On 2016-05-29T05:57:29+00:00 James wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/32 ------------------------------------------------------------------------ On 2016-11-24T11:17:48+00:00 Fedora wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/33 ------------------------------------------------------------------------ On 2016-12-20T12:57:33+00:00 Fedora wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network- manager/+bug/1432599/comments/34 ** Changed in: network-manager (Fedora) Status: Unknown => Won't Fix ** Changed in: network-manager (Fedora) Importance: Unknown => High ** Bug watch added: GNOME Bug Tracker #739482 https://bugzilla.gnome.org/show_bug.cgi?id=739482 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1432599 Title: Network-manager tries to manage virbr0, which it should not To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1432599/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
