Fuidshift: migration from OpenVZ and some files owners (corrected)

I’m trying to migrate centos 7 containers from OpenVZ 6 to the latest LXD.

lxc init --empty ${ct}
zfs mount tank/lxd/containers/$ct
rsync -avPh --numeric-ids -e ssh root@old.server:/vz/private/$ve/ /var/snap/lxd/common/lxd/storage-pools/lxd/containers/$ct/rootfs/
# fuidshift /var/snap/lxd/common/lxd/storage-pools/lxd/containers/$ct/rootfs b:0:1000000:65536
zfs umount tank/lxd/containers/$ct
lxc start ${ct}

At this summer I had to do

fuidshift /var/snap/lxd/common/lxd/storage-pools/lxd/containers/$ct/rootfs b:0:1000000:65536

after syncing files. I found I should not do it any more with LXD 3.18 but was unable to find any changelog about it. Now it looks like to happen automatically after first start of container. Where to read about changes?

And now I have strange sideeffect -
/proc and /sys have now uid/gid 65534/65534 inside container. Why this happens? Should I fix it? It was nobody/nogroup inside OpenVZ 6

We did one small optimization in 3.17/3.18 which is probably causing what you’re seeing.

We used to do the initial filesystem shift on creation time, so on startup LXD would assume everything was already shifted and would just startup. This in fact was causing more load on servers than desired when people would create a lot of containers in parallel.

So we’ve instead moved that logic to startup time, meaning that the filesystem shift happens on initial container startup (or any startup where the map was changed in configuration).

In your case, that saves you from having to run fuidshift as the LXD triggered shift hasn’t happened again.

Is uid/gid 65534/65534 ok or should I change it somehow?

65534/65534 is nobody/nogroup, if you’re seeing the numeric values, it’s most likely because of an issue with resolving uid/gid to their name in /etc/passwd and /etc/group.