Avatar of Jasmin shahrzad
Jasmin shahrzad
 asked on

moving lxd to another server

i take a export from my lxd:  (from ubuntu 18.04 with snap installation of lxc version 3.19 and using zsf)
lxc publish CONTAINER_NAME --alias my-lxd
lxc image export my-lxd .
then move tarball to my new server (ubuntu 18.04.3 default lxc (version 3.0.3installation using zfs )
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

UNIQUE constraint failed: storage_volumes.storage_pool_id, storage_volumes.node_id, storage_volumes.name, storage_volumes.type
* lxdInstallationLXCUbuntuLinux

Avatar of undefined
Last Comment
David Favor

8/22/2022 - Mon
David Favor

ZFS problem shown by "UNIQUE constraint failed:" message.

Looking at LXD go code for export/import, it's highly unlikely this will ever work or will ever be fixed to work... because...

1) Trying take an export image of a ZFS container references machine unique ZFS data which only lives on source machine.

So exports will work + imports will fail... at least... that's my read...

2) Instead of an export/import, get your new/target container working using EXT4 or ZFS or whatever.

3) Then stop your old/source container + new/target container.

4) Then just rsync over all the files required from old/source container -> new/target. This includes /var/lib/mysql, /var/log/mysql (if bin logging is used), /etc/apache2/* + /etc/php/* + /etc/letsencrypt/* + any other files of interest.

5) On new/target container, ensure all your file ownership is correct.

6) Start your new/target container + all should be well.

Note: In my situation, I clone/copy/move containers, many containers/day, so all these LXD commands must work for me.

I've learned by many lost hours, if you're doing clone/copy/move frequently, stick with EXT4 as your backing store.

You'll do this via an init sequence of...

lxd init --auto --storage-backend=dir
lxc network attach-profile lxdbr0 default eno1

Open in new window

David Favor

Open an https://github.com/lxc/lxd/issues ticket, if you believe this problem should be fixed.

Open a https://discuss.linuxcontainers.org, asking for potential work arounds.
Jasmin shahrzad

do you mean it's better i moving to other file system for future installation of lxd.?
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
Jasmin shahrzad

is it possible to move old lxd on zfs to other server with btrfs file system?
David Favor

do you mean it's better i moving to other file system for future installation of lxd.?

If you're requirement is fastest container I/O + LXD commands working 100% of the time...


You'll do this by setting up EXT4 machine level file systems, then use the lxd init sequence above.

2) You can mix filesystems, like BTRFS at machine level, then ZFS for containers. Doing this incurs a massive speed penalty, as every filesystem operation must be mapped back + forth between files systems.

3) is it possible to move old lxd on zfs to other server with btrfs file system?


You'll setup a machine running BTRFS, then do your lxd init specifying BTRFS.

And, you may find you run into a completely new set of problems, not as bad as ZFS, just sometimes a few second EXT4 command will devolve into hours of working around some problem.

4) If I/O speed must be maximized + your time must be optimized... stick with EXT4.
Jasmin shahrzad

I don't understand.
i move it to my lxd on laptop with btrfs file system and op it running then import it and the same move to new server
with zfs for lxd. it's op and running.
but problem (issue) is solved now.
Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
David Favor

Taking this path may also break... remove all ZFS internal tracking...

In other words, going from ZFS -> non-ZFS, the LXD go code may reset/remove all ZFS cruft.

Glad you got this working!
David Favor

Better to think of this as follows.

1) You never "move LXD".

2) You do "move LXD containers", one at a time.

3) The way I do this is to setup a new Ubuntu + LXD machine + running on top of ext4. Then "lxc copy" (never lxc move) a container from one machine to another. After a copy has worked, then I do an lxc delete on original container.

The reason for the extra step is because if "lxc move" fails, there are edge conditions where you can end up with your original container deleted + your new container broken.

Better, to me, to always do a copy + test new container + delete old container.

Just to be sure all's well.
David Favor

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.