Thank you for taking a look. I was able to rsync and confirm that everything worked as expected if I leave the instance running in privileged mode during the rsync. I was wondering if you could elaborate on the zfs mount option. When I try to mount it via `zfs mount default/containers/instance-00000019` I get the following error:
root@atl-comp1:~# zfs mount default/containers/instance-00000019 cannot mount '/var/lib/lxd/storage-pools/default/containers/instance-00000019': directory is not empty I would of course prefer to not have the guest running during this xfer. On Thu, Apr 4, 2019 at 12:50 PM Stéphane Graber <stgra...@ubuntu.com> wrote: > > LXD only mounts the ZFS datasets when the container is started, so you should: > - Set security.privileged to true > - Start the container (or alternatively manually "zfs mount" it) > - Rsync > - Stop or unmount the container > - Unset security.privileged > - Start it > > On Thu, Apr 04, 2019 at 10:42:38AM -0400, Brandon Whaley wrote: > > I'm in the middle of migrating some users from VZ to LXC/LXD with ZFS > > backed guest fs. I'm using rsync with --numeric-ids to copy the files > > with the correct uid/gid to the container's private area. It was > > suggested to me that I could get the uid/gid remapping done by making > > the destination container privileged and starting/stopping it before > > the xfer, which does appear to work from the host side. Unfortunately > > after setting the container back to unprivileged mode and starting it, > > the new files are gone and the fs is back to its pre-rsync state. > > Setting the container to privileged mode again shows that the files > > are still there, just being hidden by some overlay. > > > > I'm wondering if there is a mechanism to mount a non-uid/gid remapped > > guest fs that will not end up being overridden when the remapping is > > done. > > > > root@atl-comp1:~# lxc config set instance-00000019 security.privileged false > > root@atl-comp1:~# lxc start instance-00000019 > > root@atl-comp1:~# ls -hal > > /var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release > > ls: cannot access > > '/var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release': > > No such file or directory > > root@atl-comp1:~# lxc stop instance-00000019 > > root@atl-comp1:~# lxc config set instance-00000019 security.privileged true > > root@atl-comp1:~# lxc start instance-00000019 > > root@atl-comp1:~# ls -hal > > /var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release > > ls: cannot access > > '/var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release': > > No such file or directory > > root@atl-comp1:~# lxc stop instance-00000019 > > root@atl-comp1:~# ls -hal > > /var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release > > lrwxrwxrwx 1 root root 14 Apr 3 12:53 > > /var/lib/lxd/storage-pools/default/containers/instance-00000019/rootfs/etc/redhat-release > > -> centos-release > > _______________________________________________ > > lxc-users mailing list > > lxc-users@lists.linuxcontainers.org > > http://lists.linuxcontainers.org/listinfo/lxc-users > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > _______________________________________________ > lxc-users mailing list > lxc-users@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users