I will probably have to re-install on the
default loop btrfs pool to reproduce if at all. One difference I notice exporting and importing into the same pool now is that I get only single
.tar.gz files. When I exported before I would get two files, one I believe
.squashfs. Not sure how or why or whether it even matters.
Would I reinstall I would try hard if possible to immediately configure ZFS or btrfs proper, but it would be great if
lxd could make some additions to facilitate moving images or image trees between pools without resorting to hacks while the deamon is stopped and hoping it might start after hacking - I read it could be done by directly editing the SQLite database for example and amongst others.
This is how I get a container with the same MAC address as another (
volatile.eth0.hwaddr: 00:16:3e:fc:7e:f3) and the same IP address (
10.41.132.180), but they’re both on DHCP so this isn’t exactly a repro:
lxc launch images:alpine/3.8 repro
lxc launch images:alpine/3.8 repro-restored
lxc stop repro && lxc stop repro-restored
lxc snapshot repro snapshot
lxc restore repro-restored repro/snapshot
lxc start repro-restored && lxc exec repro-restored -- ifconfig
lxc start repro && lxc exec repro -- ifconfig
Could argue this isn’t quite right either, but seeing the
repro container will at least be off when starting the
repro-restored container the latter wasn’t immediately in error when it started with the MAC address it had before the snapshot.
Another issue is that it responds to ping
127.0.1.1 since it is listed in
hosts but its hostname matches the new container name
repro-restored. However pinging
repro-restored will get 100% loss to an IP-address that isn’t listed at all with
lxc list (
Also the original
repro container will not list any IPv6 address anymore. If I start them in opposite order the
repro-restored container will not list any IPv6 address. So that DHCP client is just better than the IPv4 one I guess.