For some machines with LXC containers, they have been running for a number of years. I want to take the easy way out and move the containers from one physical machine to another. At another time, I will rebuild the containers.
Since I am running BTRFS subvolumes for each container, I could be using BTRFS snapshot/send/receive commands to migrate/copy/replicate subvolumes. But before attempting that, I wanted to give the 'copy' a try. To do this properly, at the source, use the following -- with numeric-owner being a required paramenter -- command to collect the files:
tar --numeric-owner -czvf mycontainer.tar.gz /var/lib/lxc/my_container
At the destination, expand that file out:
tar --numeric-owner -xzvf mycontainer.tar.gz -C /var/lib/lxc/
The lxc users mailing list and Stack OverFlow were helpful.
Other stuff to do:
- Read up on CGroups in the Linux Programmer's Manual
In migrating from a very old version of LXC to a much newer version of LXC, I was getting errors. I needed to run a some debug to get a handle on errors:
lxc-start -n container -F --logpriority=DEBUG --logfile log
I had errors along the lines of:
Activating lvm and md swap...done. Checking file systems...Segmentation fault (core dumped) failed (code 139).
ServerFault had the solution: put "vsyscall=emulate" into /etc/default/grub, run 'update-grub' and reboot. Looks like I need to modernize my containers so I can eliminate this workaround, which may have some security considerations. There is a Debian Bug for this.
einstein home has a blog with some kernel references to the issue, in effect saying: "vsyscall is now disabled on latest linux distros". A lengthier LWN article at On vsyscalls and the vDSO. This works with kernel 4.14, my current version, but I see somewhere else that the workaround is entirely removed in kernel 4.15, at least in the Arch world. At bug 847154: "This breaks (e)glibc 2.13 and earlier".