Я лично предпочитаю другой подход. Учитывая, что часть контейнеров, относящаяся к ОС, относительно мала (макс. 2 ГБ сервера debian jessie с множеством запущенных служб, около 3 ГБ рабочего образа ubuntu с удаленным рабочим столом), я оставляю ОС постоянно в / var / lib / lxc и использую отдельный раздел для данных контейнера.
Это просто изменение файла / var / lib / lxc / container / fstab:
/mnt/data/container-data/ /var/lib/lxc/container/rootfs/home/ none bind 0 0
Создайте папки (как исходные, так и целевые) на главном хосте, остановите свой контейнер, переместите данные и перезапустите контейнер!
В приведенном выше случае обе директории находятся в разделе / mnt / data на хосте lxc, в моем случае на большом диске.
Этот метод дает много преимуществ: разделение ОС и данных позволяет быстро копировать и запускать тестовые контейнеры, когда вам нужно выполнить опасные задачи (например, «aptitude -f dist-upgrade»):
остановите контейнер (разделы в fstab будут отсоединены от каталога / var / lib / lxc / container / rootfs /):
lxc-stop -n container
скопировать контейнер:
mkdir / var / lib / lxc / containertest
rsync -Pavv / var / lib / lxc / container / / var / lib / lxc / containertest /
Не забудьте соответствующим образом изменить / var / lib / lxc / containertest / config и / var / lib / lxc / containertest / fstab
запускают новый контейнерный тест, поработайте с ним и посмотрите результаты!
lxc-start -n containertest
Кроме того, отвечая на ваши вопросы, вам не следует беспокоиться о том, что вы не сделали этого до : одним из величайших преимуществ lxc является то, что он универсальность!