i take a export from my lxd:
lxc publish CONTAINER_NAME --alias my-lxd
lxc image export my-lxd .
then move tarball to my new server and
lxc image import bxxxx.tar.gz --alias my-lxd
then i try to create a new-lxd-name with command
lxc init my-lxd new-lxd-name
the last one error : failed to change ACLs on /var/lib/lxd/storage-pools/default/new-lxd-name/rootfs/var/log/journal
HELP
i get following error:
Error: UNIQUE constraint failed: storage_volumes.storage_pool_id, storage_volumes.node_id, storage_volumes.name, storage_volumes.type
i using zfs
from snap installed version 3.19 with zfs file system mac net run the following command
lxc publish dontainer_name --alias my_lxd
and tar bar
"lxc images export my_lxd . "
copy tar ball to other server lxc default installation with zfs file system and bridge net
import image
lxc image import tarball.gz --alias my-lxd
ok until here the create lxd with
then lxc init my-lxd to new-container
error:
UNIQUE constraint failed: storage_volumes.storage_pool_id, storage_volumes.node_id, storage_volumes.name, storage_volumes.type
i don’t understand what happen here. But problem is solved.
i export and create it on lxd with btrfs file system then take a
lxc publish CONTAINER_NAME --alias my-lxd
lxc image export my-lxd .
and move tarball to new server with zfs as file system for lxd. then
lxc image import bxxxx.tar.gz --alias my-lxd
then i try to create a new-lxd-name with command
lxc init my-lxd new-lxd-name
just running.
So is what different that it was exported first on a ZFS filesystem and now on a BTRFS filesystem? Perhaps there is an issue exporting from ZFS, can you confirm that was the only difference?
i have a lxd on zfs and want to move to other server with zfs in lxd default. get error. then
i export it from lxd with zfs and import it to lxd on other server with btrfs as file system.
then i export it fram btrfs and export it to final server with zfs as default in lxd file system.
I suspect the unique constraint issue is caused by the ACL issue causing the lxc init to fail and not clean up fully the DB records created, so I will check our code paths for that.
For those new to LXD like myself that find this post after googling the error message can I suggest that you double-check which version of LXD is in play .
In my case I had built a number of build agents in the cloud using the cloud provider’s Ubuntu image and my provision script installed snap and LXD 4.x over the top as they weren’t already installed. I didn’t notice that LXD 3.0.3 was already installed as part of the OS image via apt and therefore I wasn’t invoking the version of LXD that I thought I was [1] . After running lxd.migrate -yes to upgrade to the snap version everything worked and the container started okay. (Presumably whatever was broken was fixed via the version change.)
[1] I had built the container from scratch on the cloud server up until this point as our image server was on-premise and I didn’t discover the tarball approach until sometime later.