I, personally prefer a different approach.
Given that the OS part of the containers is relatively small (max. 2GB a debian jessie server with plenty of services running, about 3Gb a working ubuntu image with remote desktop), I leave the OS reside in /var/lib/lxc and use a separate partition for the container's data.
This is simply accomplished modifing the /var/lib/lxc/container/fstab file:
/mnt/data/container-data/ /var/lib/lxc/container/rootfs/home/ none bind 0 0
Create the folders (both source and target) on the main host, stop your container, move your data and restart the container!
In the case above, both direcories reside on a /mnt/data partition on the lxc host, in my case a large disk.
There are many advantages associated with this method: splitting the OS and the data allows you to rapidly copy and start test containers when you have to accomplish hazardous tasks (ex: "aptitude -f dist-upgrade"):
stop the container (the partitions in fstab will detach from the /var/lib/lxc/container/rootfs/ directory):
lxc-stop -n container
copy the container:
mkdir /var/lib/lxc/containertest
rsync -Pavv /var/lib/lxc/container/ /var/lib/lxc/containertest/
Remember to modify accordingly /var/lib/lxc/containertest/config and /var/lib/lxc/containertest/fstab
Also, answering to your concerns, you should not worry about not haveing done this before: one of the great advanages of lxc is it's versatility!
/var/lib/lxc
a symbolic link to a directory in/home
? – daniel kullmann Mar 11 '15 at 14:01