Je vais dissiper quelques mythes ici.
C'est juste une mauvaise idée. Je suis désolé. - Jacob 5 mars à 20h30
Je ne vois pas en quoi c'est une mauvaise idée. C'est vraiment juste un chroot à l'intérieur d'un chroot. D'une part, cela pourrait éventuellement réduire les performances de manière négligeable (rien par rapport à l'exécution d'une machine virtuelle à l'intérieur d'une machine virtuelle). D'un autre côté, il est susceptible d'être plus sûr (par exemple, plus isolé du système hôte racine et de ses composants).
Avez-vous réellement une vraie raison de le faire? N'oubliez pas que les questions doivent porter sur les problèmes réels auxquels vous êtes confronté. - Zoredache 5 mars à 21:52
Je suis d'accord à 100% avec le commentaire suivant de l'affiche. En outre, je pense qu'il est prudent de supposer que tous ceux qui publient une question ici pensent probablement qu'ils ont une vraie raison de le faire.
Je pense que lxc devrait être en mesure de simplifier la migration des VM (et la sauvegarde + la récupération aussi). Mais je ne suis pas sûr des cas, quand il n'y a pas d'accès au système d'exploitation hôte (vps bon marché par exemple). - Mikhail 6 mars à 11:17
En fait, je suis tombé sur cette question en juin lorsque j'ai plongé pour la première fois dans LXC pour des projets PaaS / IaaS, et j'étais particulièrement intéressé par la possibilité de permettre aux utilisateurs d'émuler des environnements cloud à des fins de développement.
LXCeption. Nous sommes trop profonds. - Tom O'Connor 6 mars à 22h46
J'ai ri un peu en lisant celui-ci, mais ce n'est pas du tout le cas :)
Quoi qu'il en soit, j'ai finalement mis en place un environnement VirtualBox avec une installation standard d'Ubuntu 12.04 LTS Server Edition après avoir lu tout cela, pensant que c'était 100% possible. Après avoir installé LXC, j'ai créé un nouveau conteneur et installé LXC à l'intérieur du conteneur avec apt-get. La plupart de l'installation a bien progressé, mais a finalement entraîné une erreur en raison d'un problème avec le package cgroup-lite, dont le travail parvenu à l'échec n'a pas pu démarrer après l'installation du package.
Après un peu de recherche, je suis tombé sur ce bel article sur stgraber.org (les goodies se cachent dans la section "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
L'installation de cette stratégie AppArmor et le redémarrage du démon ont fait l'affaire (n'oubliez pas de changer les plages réseau, cependant!). En fait, je pensais que cet extrait particulier était si important que je l'ai reflété @ http://pastebin.com/JDFp6cTB juste au cas où l'article serait mis hors ligne.
Après cela, il a sudo /etc/init.d/cgroup-lite startréussi et la navigation s'est bien déroulée.
Donc, oui, il est possible de démarrer un conteneur LXC à l'intérieur d'un autre conteneur LXC :)