Disable id remap on first start of recovered container

Hi, some context of the situation:
On host A the LXD daemon has crashed permanently (due to snap’s automatic updates). The containers are working, but to fix the problem I need to migrate them to other machine (host B). Storage is on ZFS pool. My steps to migrate were:

  1. on host B: lxc init contX --empty
  2. zfs send-receive contX dataset from host A to host B
  3. on Host B: lxc start contX

The problem is that at this first start LXD performs remapping of IDs, bumping root’s ID from 1000000 to 2000000.

How can I avoid this?


Best regards
Seweryn Niemiec

What are the journalctl errors for the crashing lxd process?

We should try and rectify that, as snap auto updates are likely not the problem, but rather something else triggered by the update you would eventually apply anyway.

See also Managing the LXD snap for managing the snap updates.

Rather than initializing an empty container you should transfer the datasets and then run “lxd recover” so the correct db entries are restored.

https://linuxcontainers.org/lxd/docs/master/backup/#disaster-recovery

AFAIR, LXD from 5.12 requires ZFS 0.8, but Ubuntu 18.04 has ZFS 0.7. I can’t go back to 5.11 because it’s not available on snap anymore and can’t go to 5.0 because of LXD database schema changes.

OK, I’ll try that. Tank you.

If you install the hwe kernel it works on ubuntu 18.04 as its only the updated ZFS kernel modules LXD needs, not the userspace tooling:

Thanks for this hint, I was actually considering it already but in my situation it’s too risky. There is some fragile, legacy production software running in those containers and I need to be sure I have a parallel fully working instance before stopping those orphaned.

1 Like

I was finally able to try this method and it worked. I had to manually edit backup.yaml file before running lxd recover so that the storage pool name and other resource names matched those on new host.

1 Like