Hi !!
I’m ready to publish the Japanese translation! 
Oops, updated the website now 
The Feature you recently added for unmanaged bridges, is breaking my setup.
I can’t understand how the default option is disabled but its still breaking.
Failed preparing container for start: Failed to start device "eth0": Cannot specify "ipv6.address" when DHCP or "ipv6.dhcp.stateful" are disabled (unless using security.ipv6_filtering) on network "bridge..."
I don’t disable DHCP, neither did I disable ipv6.dhcp.stateful.
Any idea on this?
Please can you show output of lxc config show <instance> --expanded and lxc network show <network> for the network the instance uses (if defined).
Ze Bridge:
config:
ipv4.address: 10.0.11.177/28
ipv4.nat: "true"
ipv6.address: 2a0e:xxxx:xxxx:b::1/64
description: ""
name: bridge...
type: bridge
used_by: []
managed: true
status: Created
locations:
- none
La containere:
architecture: x86_64
config:
boot.autostart: "1"
image.architecture: amd64
image.description: Centos 7 amd64 (20201124_07:08)
image.os: Centos
image.release: "7"
image.serial: "20201124_07:08"
image.type: squashfs
image.variant: default
limits.cpu: "1"
limits.cpu.allowance: 100%
limits.memory: 256MB
limits.memory.swap: "false"
limits.processes: "200"
security.idmap.isolated: "true"
volatile.base_image: 2be73469c53d245ea899404de4b0b5221c281951bb543b665e87c28270f2e0c1
volatile.eth0.host_name: veth42167f64
volatile.eth0.hwaddr: 00:16:3e:8d:16:58
volatile.idmap.base: "1655360"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1655360,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1655360,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1655360,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1655360,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1655360,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1655360,"Nsid":0,"Maprange":65536}]'
volatile.last_state.power: RUNNING
volatile.uuid: d09866fc-3763-4af7-9893-9c4a4c394716
devices:
eth0:
ipv4.address: 10.0.11.178
ipv6.address: 2a0e:xxxx:xxxx:b::2
limits.max: "25600000"
name: eth0
nictype: bridged
parent: bridge...
type: nic
root:
limits.read: 30MB
limits.write: 30MB
path: /
pool: primary
size: 2560MB
type: disk
ephemeral: false
profiles:
- default
stateful: false
description: ""
So that’s the issue the NIC setting ipv6.address: 2a0e:xxxx:xxxx:b::2 won’t be taking effect as in your case the parent bridge is a managed network and doesn’t have stateful dhcpv6 enabled.
That is the validation improvement that was added to avoid confusion of setting an ipv6 address and it not being applied (as by default the instance will use SLAAC to assign an automatic address).
So you need to remove that NIC key to proceed or enable stateful dhcpv6 on the parent network.
I see, we use to hand out a /64 per container, I thought by setting ipv6.address to a specific one, it would assign the container that one. But apparently I was wrong so.
Seems to work now thanks.
Cool. Yes assigning ipv6 addresses only works if the parent network has ipv6.dhcp.stateful=true and there is a dhcpv6 client (such as systemd-networkd) running inside the instance.
As lxd: support idmapped mounts by brauner · Pull Request #8778 · lxc/lxd · GitHub seems to be included in this release, can I assume that the replacement for shiftfs is now included and active?
Yeah, it should work, note however that it’s not a full replacement yet.
It doesn’t work on top of btrfs, zfs, cephfs, … it only works currently if your container or the volume you’re passing into it sits on ext4, xfs or vfat.
For that reason, we’re not deprecating shiftfs yet in Ubuntu. We have @brauner working furiously to add support to the filesystems we care about but until then we’re in a hybrid approach where LXD detects whether a particular filesystem is functional and if not, falls back to shiftfs.
2 Likes
Bit late to the party, but released in openSUSE. 
3 Likes
@stgraber @brauner Out of interest: Is there a bug report somewhere, so that we can know when the new approach is ready for other filesystems as well?
(And I can know when shiftfs is no longer available for new kernel versions)
1 Like
Not really, the upstream Linux kernel community is not big on milestone tracking and bug reports 
The initial set were ext4, xfs and vfat which were included in Linux 5.12, btrfs looks in line to make it to 5.15. @brauner is currently working on cephfs which theoretically could make it in 5.15 but may slip to 5.16. And then we need ZFS too which is a completely different beast and maintained outside of the kernel.
Once we have all of those in an Ubuntu kernel, we’ll be dropping shiftfs.
1 Like
5.15 has support for btrfs. We still have @brauner looking at cephfs and zfs then we should be good for the filesystems we care about and can drop shiftfs.
1 Like
Is leap15.3 will be supported any time soon? my project will depend on that version of opensuse.
LXD is available in Leap 15.3 (and has been for the entire history of Leap 15.3). I’ve just submitted an update for LXD 4.21 for all supported Leap releases and Factory.
As kernel 5.16 is released, Is there an update on the situation regarding cephfs and zfs?