Ich werde hier ein paar Mythen zerstreuen.
Das ist nur eine schlechte Idee. Es tut mir Leid. - Jacob 5. März um 20:30 Uhr
Ich verstehe nicht, dass das eine schlechte Idee ist. Es ist wirklich nur eine Chroot in einer Chroot. Einerseits könnte dies möglicherweise die Leistung in vernachlässigbarer Weise verringern (nichts im Vergleich zum Ausführen einer VM innerhalb einer VM). Auf der anderen Seite ist es wahrscheinlich sicherer (z. B. stärker vom Root-Host-System und seinen Bestandteilen isoliert).
Haben Sie tatsächlich einen wirklichen Grund dafür? Bitte denken Sie daran, dass sich die hier gestellten Fragen auf aktuelle Probleme beziehen sollten. - Zoredache 5. März um 21:52 Uhr
Ich stimme dem folgenden Kommentar des Posters zu 100% zu. Außerdem kann ich davon ausgehen, dass jeder, der hier eine Frage stellt, der Meinung ist, dass er einen echten Grund hat, dies zu tun.
Ich denke, dass lxc in der Lage sein sollte, die VM-Migration (und auch Backup + Recovery) zu vereinfachen. Aber ich bin mir nicht sicher, ob es Fälle gibt, in denen kein Zugriff auf das Host-Betriebssystem besteht (z. B. günstiges VPS). - Mikhail 6. März um 11:17 Uhr
Diese Frage traf mich im Juni, als ich zum ersten Mal in LXC für PaaS / IaaS-Projekte eintauchte, und ich war besonders an der Möglichkeit interessiert, Benutzern die Emulation von Cloud-Umgebungen für Entwicklungszwecke zu ermöglichen.
LXCeption. Wir sind zu tief. - Tom O'Connor 6. März um 22:46
Ich habe ein bisschen gelacht, als ich dieses gelesen habe, aber das ist überhaupt nicht der Fall :)
Wie auch immer, ich habe schließlich eine VirtualBox-Umgebung mit einer Standardinstallation von Ubuntu 12.04 LTS Server Edition eingerichtet, nachdem ich dies alles gelesen hatte und dachte, dass dies zu 100% möglich sei. Nach der Installation von LXC habe ich einen neuen Container erstellt und LXC mit apt-get im Container installiert. Der Großteil der Installation verlief gut, führte jedoch zu einem Fehler, der möglicherweise auf ein Problem mit dem cgroup-lite-Paket zurückzuführen war, dessen Startjob nach der Installation des Pakets nicht gestartet werden konnte.
Nach einigem Suchen bin ich auf diesen schönen Artikel auf stgraber.org gestoßen (die Goodies verstecken sich unter der Rubrik "Container Nesting"):
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
Die Installation dieser AppArmor-Richtlinie und der Neustart des Daemons haben den Trick ausgeführt (vergessen Sie jedoch nicht, die Netzwerkbereiche zu ändern!). Tatsächlich dachte ich, dass ein bestimmtes Snippet so wichtig ist, dass ich es unter http://pastebin.com/JDFp6cTB gespiegelt habe, für den Fall, dass der Artikel jemals offline geschaltet wird.
Danach sudo /etc/init.d/cgroup-lite startgelang es und es wurde reibungslos gesegelt.
Es ist also möglich, einen LXC-Container in einem anderen LXC-Container zu starten :)