Rozwiążę tutaj kilka mitów.
To tylko zły pomysł. Przepraszam. - Jacob 5 marca o 20:30
Nie rozumiem, jak to jest zły pomysł. To naprawdę tylko chroot w chroot. Z jednej strony może potencjalnie zmniejszyć wydajność w nieznaczny sposób (nic w porównaniu z uruchomieniem maszyny wirtualnej wewnątrz maszyny wirtualnej). Z drugiej strony, prawdopodobnie będzie bardziej bezpieczny (np. Bardziej odizolowany od głównego systemu hosta i jego składników).
Czy naprawdę masz prawdziwy powód, aby to zrobić? Pamiętaj, że tutaj pytania powinny dotyczyć rzeczywistych problemów, z którymi się borykasz. - Zoredache 5 marca o 21:52
Zgadzam się w 100% z następującym komentarzem plakatu. Ponadto uważam, że można bezpiecznie założyć, że każdy, kto zamieszcza tutaj pytanie, prawdopodobnie uważa, że ma prawdziwy powód, aby to zrobić.
Myślę, że lxc powinien być w stanie uprościć migrację maszyn wirtualnych (a także tworzenie kopii zapasowych + odzyskiwanie). Ale nie jestem pewien co do przypadków, w których nie ma dostępu do systemu operacyjnego hosta (na przykład tanie vps). - Michaił 6 marca o 11:17
Właściwie natknąłem się na to pytanie w czerwcu, kiedy po raz pierwszy nurkowałem w LXC dla projektów PaaS / IaaS, i byłem szczególnie zainteresowany możliwością umożliwienia użytkownikom emulacji środowisk chmurowych w celach programistycznych.
LXCepcja. Jesteśmy za głęboko. - Tom O'Connor 6 marca o 22:46
Zaśmiałem się trochę, kiedy to przeczytałem, ale wcale tak nie jest :)
W każdym razie, po przeczytaniu tego wszystkiego, ostatecznie skonfigurowałem środowisko VirtualBox ze standardową instalacją Ubuntu 12.04 LTS Server Edition, myśląc, że było to w 100% możliwe. Po zainstalowaniu LXC utworzyłem nowy kontener i zainstalowałem LXC wewnątrz kontenera za pomocą apt-get. Większość instalacji przebiegła pomyślnie, ale ostatecznie spowodowała błąd z powodu problemu z pakietem cgroup-lite, którego zadanie upstart nie uruchomiło się po zainstalowaniu pakietu.
Po krótkich poszukiwaniach natknąłem się na ten świetny artykuł na stgraber.org (gadżety chowają się w sekcji „Zagnieżdżanie kontenerów”):
sudo apt-get install lxc
sudo lxc-create -t ubuntu -n my-host-container -t ubuntu
sudo wget https://www.stgraber.org/download/lxc-with-nesting -O /etc/apparmor.d/lxc/lxc-with-nesting
sudo /etc/init.d/apparmor reload
sudo sed -i "s/#lxc.aa_profile = unconfined/lxc.aa_profile = lxc-container-with-nesting/" /var/lib/lxc/my-host-container/config
sudo lxc-start -n my-host-container
(in my-host-container) sudo apt-get install lxc
(in my-host-container) sudo stop lxc
(in my-host-container) sudo sed -i "s/10.0.3/10.0.4/g" /etc/default/lxc
(in my-host-container) sudo start lxc
(in my-host-container) sudo lxc-create -n my-sub-container -t ubuntu
(in my-host-container) sudo lxc-start -n my-sub-container
Zainstalowanie tej zasady AppArmor i ponowne uruchomienie demona załatwiło sprawę (nie zapomnij jednak zmienić zakresów sieci!). W rzeczywistości uważałem, że ten fragment kodu był tak ważny, że dublowałem go na stronie http://pastebin.com/JDFp6cTB na wypadek, gdyby artykuł kiedykolwiek został wyłączony.
Potem sudo /etc/init.d/cgroup-lite startudało się i było płynnie.
Tak, możliwe jest uruchomienie kontenera LXC w innym kontenerze LXC :)