Nothing has changed regarding privileged vs. unprivileged settings. I just set this up again with a privileged container, and I believe the cause of the regression to actually be in libvirt. I think it must have silently ignored the bridge configuration error before and marked the network active (such that it shows up in `virsh net-list` without the `--all` parameter).
Reasoning: yesterday before I rebuilt my test container, MAAS showed only two networks; none of which were virbr* interfaces (I never explicitly deleted the default virsh network). Today when I encountered this bug, MAAS showed three (because I made the container privileged). Additionally, MAAS KVM pods check to see if a `default` or `maas` network is active in virsh before allowing a KVM pod to be composed. Therefore, unless libvirt believed its `default` network was up and running, my previous test environment would not have worked at all. Conclusion: we're just now seeing this because libvirt (in bionic- updates) began raising an error and failing to mark a network active in the case that it could not configure the bridge STP parameters. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1784501 Title: libvirtd is unable to configure bridge devices inside of LXD containers Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Triaged Bug description: libvirtd cannot properly configure the default bridge device when installed inside of unprivileged LXD containers. 'systemctl status libvirtd' shows the following error: error : virNetDevBridgeSet:140 : Unable to set bridge virbr0 forward_delay: Permission denied This is caused due to the files under /sys/class/net/ being owned by init namespace root rather than container root even when the bridge device is created inside of the container. Here's an example from inside of an unprivileged container: # brctl addbr testbr0 # ls -al /sys/class/net/testbr0/bridge/forward_delay -rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 /sys/class/net/testbr0/bridge/forward_delay libvirt cannot open this file for writing even though it created the device. Where safe, files under /sys/class/net/ should be owned by container root. The following upstream patches have been merged into linux-next which fix this bug: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784501/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp