lxcbr0 dissappears on Ubuntu 15.10
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
network-manager (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Wily |
Fix Released
|
Critical
|
Unassigned | ||
Xenial |
Fix Released
|
Critical
|
Unassigned |
Bug Description
=== SRU ===
Rationale:
Network Manager in wily triggers on newly created interfaces and resets their network configuration even though it's not supposed to manage them at all.
This breaks LXC and quite possibly libvirt as those provide bridges which are then completely unconfigured by Network Manager.
Test case:
1) Update (or not) network-manager
2) Restart it
3) Install lxc
4) Check that lxcbr0 exists and has an IP configured
Regression potential:
The change to Network Manager is related to udev handling of new devices, even though normal operation on a regular desktop machine was tested, it's not impossible that this may regress handling of some devices.
The fix was cherry-picked directly from upstream, so did go through code review and has been publicly available for a while.
This fixes a significant regression compared to Ubuntu 15.04 and looks less risky than the alternative workaround which was uploaded earlier.
=== Original report ===
After initial upgrade from Ubuntu 15.04 to Ubuntu 15.10 LXC worked for a couple days then failed. I found that the lxcbr0 interface no longer existed.
I reported this on the lxc-user alias and about the same time several others had this happen to them also.
Serge Hallyn requested I open a launchpad bug and post some info but before I could gather that info the system returned to normal (re lxcbr0 was back) the next day after the server was booted up again.
note: at least one other person had this happen to them also (lxcbr0 came back by itself).
Today, I booted this server again and ... again lxcbr0 was missing where it had been working last night.
Below is all of the Info Serge Hallyn asked me to post.
$ ifconfig lxcbr0
lxcbr0: error fetching interface information: Device not found
$ journalctl -u lxc-net
-- Logs begin at Tue 2015-11-03 07:25:22 EST, end at Tue 2015-11-03 10:02:08 EST
Nov 03 07:25:48 server3 systemd[1]: Starting LXC network bridge setup...
Nov 03 07:25:50 server3 lxc-net[913]: dnsmasq: failed to create listening socket
Nov 03 07:25:50 server3 lxc-net[913]: Failed to setup lxc-net.
Nov 03 07:25:50 server3 systemd[1]: Started LXC network bridge setup.
root@server3:
root@server3:
>> and lxcbr0 is still missing
# ifconfig lxcbr0
lxcbr0: error fetching interface information: Device not found
root@server3:
dnsmasq: failed to create listening socket for 10.0.3.1: Cannot assign requested address
Failed to setup lxc-net.
root@server3:
$ uname -a
Linux server3 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 15.10
Release: 15.10
Codename: wily
Related branches
no longer affects: | lxc (Ubuntu Wily) |
no longer affects: | lxc (Ubuntu) |
no longer affects: | lxc (Ubuntu Xenial) |
tags: | added: wily |
Just managed to reproduce it here, it's caused by Network Manager deciding to mess with our bridge instead of leaving it alone as it should.
Current workarounds include:
- reboot
- systemctl stop network-manager && systemctl restart lxc-net && systemct start network-manager
This only kicks in when the interface is brought up after network-manager, so it doesn't affect boot since lxc-net starts before network-manager and it doesn't affect upgrades where a container is already running (as we don't destroy the bridge in that case).
But it does absolutely affect all new installs and upgrades done when no container is running.
This is a critical regression in Network Manager behavior, NM should NEVER touch non-physical interfaces and it should even less start flushing existing network configuration.
Changes are this affects libvirt too, unless libvirt bring up takes long enough to win the race against NM.