lxc will still provide lxcbr0 just as it always did, so there won't be a regression for any normal LXC user.
For LXD, the lxd package itself will provide a separate bridge specifically for LXD called lxdbr0. That bridges comes configured with IPv6 link-local only and LXD acts as a basic http proxy on it by default. That means that containers can be started out of the box and will be able to reach http hosts but will not themselves have a global IPv4 or IPv6 address. This is to avoid a current issue we've got with lxcbr0 where the 10.0.3.x/24 subnet we use may be used somewhere else on the user's network, therefore masking the real subnet and preventing any connection to it. That's been a serious problem ever since we added lxd to all cloud images and something we absolutely need to address. With our solution, any pure LXD user will only have lxdbr0 on their system which by default will only use IPv6 link local addresses so cannot possibly conflict with anything. It's then up to the user to run "dpkg-reconfigure lxd" and setup IPv4 or IPv6 connectivity on the bridge the way they want (and since we're using debconf, preseeding is also possible). Existing users of LXC will not see any difference as the lxc1 package where all the lxc-* tools are, will keep providing the lxcbr0 bridge as it always did with the same configuration it always did. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1548489 Title: [FFe] Let's get LXD 2.0 final in Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1548489/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
