Les Linux containers (lxc) sont une solution d’isolation ou de virtualisation (selon l’utilisation) à l’instar des Jails BSD. Contrairement à d’autres solutions similaires (vserver ou openvz) sous Linux, les lxc ne nécessitent pas de patch du noyau car faisant directement partie de la branche principale du développement du noyau. Même si lxc est jeune (donc souffrant d’un certain nombre de bugs), il s’agit d’une solution déjà fonctionnelle. Je vais décrire ici l’installation et la configuration de lxc sur une Debian Squeeze disposant d’une seule interface avec une IP publique (comme sur un serveur dédié quoi).
Préparation du système
On installe d’abord lxc et debootstrap :
# apt-get install lxc debootstrap
Il nous faudra aussi créer un bridge lié à une interface dummy :
# apt-get install bridge-utils
# modprobe dummy
Ensuite il faut créer un bridge. Ajoutez ceci au fichier /etc/network/interfaces :
auto br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
bridge_ports dummy0
bridge_fd 0
bridge_maxwait 0
pre-up /sbin/modprobe dummy
Pour charger cette nouvelle configuration :
# /etc/init.d/networking restart
Préparation des cgroups
Pas très compliqué :
# mkdir /cgroup
# echo "cgroup /cgroup cgroup defaults 0 0" >> /etc/fstab
# mount cgroup
Vérification de la configuration de lxc
Cela se fait à l’aide de la commande lxc-checkconfig :
$ lxc-checkconfig
Kernel config /proc/config.gz not found, looking in other places...
Found kernel config file /boot/config-2.6.32-5-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
Network namespace: enabled
Multiple /dev/pts instances: enabled
--- Control groups ---
Cgroup: enabled
Cgroup namespace: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: missing
Cgroup cpuset: enabled
--- Misc ---
Veth pair device: enabled
Macvlan: enabled
Vlan: enabled
File capabilities: enabled
Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig
Il est possible que vous n’obteniez pas enabled sur la ligne File capabilities. Vous aurez alors besoin d’installer libcap2-bin :
# apt-get install libcap2-bin
Création d’un container
Le paquet lxc fournit un moyen très simple de créer un container Debian via le script /usr/lib/lxc/templates/lxc-debian mais celui-ci ne fournit qu’une debian lenny, sans compter que son chemin d’accès n’est pas très pratique. Donc :
# cp /usr/lib/lxc/templates/lxc-debian /usr/lib/lxc/templates/lxc-debian-squeeze
# ln -s /usr/lib/lxc/templates/lxc-debian-squeeze /usr/sbin/lxc-debian-squeeze
Ensuite vous éditez ce nouveau script et vous remplacez :
SUITE=${SUITE:-lenny}
par
SUITE=${SUITE:-squeeze}
et
dhcp3-client,\
par
isc-dhcp-client,\
Vous êtes libre d’ajouter les paquets que vous voulez avoir par défaut dans votre container dans la liste des paquets déjà présente (htop et multitail par exemple). Vous avez un répertoire tout près à accueillir vos containers mais le chemin n’est pas très pratique. Je vous conseille donc de faire :
# ln -s /var/lib/lxc /lxc
Créons un répértoire qui contiendra le container et celui-ci dans la foulée:
# mkdir /lxc/vm0
# lxc-debian-squeeze -p /lxc/vm0
Le répertoire /lxc/vm0 contiendra un fichier config et un répertoire rootfs. Voici le contenu du fichier de configuration du container :
lxc.tty = 4
lxc.pts = 1024
lxc.rootfs = /var/lib/lxc/sql/rootfs
lxc.cgroup.devices.deny = a
# /dev/null and zero
lxc.cgroup.devices.allow = c 1:3 rwm
lxc.cgroup.devices.allow = c 1:5 rwm
# consoles
lxc.cgroup.devices.allow = c 5:1 rwm
lxc.cgroup.devices.allow = c 5:0 rwm
lxc.cgroup.devices.allow = c 4:0 rwm
lxc.cgroup.devices.allow = c 4:1 rwm
# /dev/{,u}random
lxc.cgroup.devices.allow = c 1:9 rwm
lxc.cgroup.devices.allow = c 1:8 rwm
lxc.cgroup.devices.allow = c 136:* rwm
lxc.cgroup.devices.allow = c 5:2 rwm
# rtc
lxc.cgroup.devices.allow = c 254:0 rwm
# mounts point
lxc.mount.entry=proc /var/lib/lxc/sql/rootfs/proc proc nodev,noexec,nosuid 0 0
lxc.mount.entry=devpts /var/lib/lxc/sql/rootfs/dev/pts devpts defaults 0 0
lxc.mount.entry=sysfs /var/lib/lxc/sql/rootfs/sys sysfs defaults 0 0
Ajoutez ceci :
lxc.utsname = vm0
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
# lxc.network.name = eth0
lxc.network.hwaddr = 00:FF:12:34:56:02
lxc.network.ipv4 = 192.168.1.2
La ligne lxc.network.name est commentée car eth0 est la valeur par défaut de l’interface du container. Libre à vous de la modifier.
ATTENTION : pour que vos containers soient en mesure de communiquer entre eux, prenez soin de changer leur adresse mac virtuelle ! (ligne lxc.network.hwaddr)
Si vous n’avez pas de serveur dhcp et ne voulez pas vous embêter à en installer un, allez dans le répertoire rootfs et modifiez le fichier etc/network/interfaces en remplaçant :
auto eth0
iface eth0 inet dhcp
par
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.225.0
network 192.168.1.0
broadcast 192.168.1.255
Ajoutez ceci au fichier etc/rc.local (toujours dans /lxc/vm0/rootfs, hein !):
route add default gw 192.168.1.1
Se simplifier la vie
Vous pouvez télécharger ma lxc-debian : elle est en squeeze et surtout elle permet de choisir l’adresse ip, l’adresse mac et le hostname du container et ça ajoute la route dans rc.local lors de sa création. Par contre je n’ai pas mis de sécurité si on ne précise pas ces paramêtres et certaines ip sont en dur donc « bla bla bla logiciel fourni bla bla bla aucune garantie bla bla bla à vos risques et périls ».
Configurer le firewall
Et oui, sans firewalling, vos containers vont avoir du mal à communiquer avec internet ! (sauf si vous les avez directement intêgrés à votre réseau local) :
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE
Voici deux options à changer dans /etc/sysctl.conf :
net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.default.forwarding=1
Pour les prendre en compte :
# sysctl -p
C’est fini
Vous pouvez maintenant lancer vos containers :
# lxc-start -n vm0 -d
Les stopper :
# lxc-stop -n vm0
Savoir s’ils sont up ou down :
# lxc-info -n vm0
Y entrer (pour sortir, faites Ctrl+a q) :
# lxc-console -n vm0
Sources
http://blog.foaa.de/2010/05/lxc-on-debian-squeeze/ (c’est par là si vous voulez tuner vos lxc (mémoire, cpu, toussa))
http://www.nsnam.org/wiki/index.php/HOWTO_Use_Linux_Containers_to_set_up_virtual_networks
merci pour billet bien utile.
j’ai pu mettre en place des machines virtuelles sans problème.
à moi l’autohébergement !
Bonjour
Très bon article. J’ai juste un petit problème j’ai ce qui qui apparait dans la console d’une VM
INIT: Id « c1 » respawning too fast: disabled for 5 minutes
INIT: Id « c3 » respawning too fast: disabled for 5 minutes
INIT: Id « c2 » respawning too fast: disabled for 5 minutes
INIT: Id « c4 » respawning too fast: disabled for 5 minutes
Je ne sais pas quoi faire.
Merci pour l’article
snif, je bloque sur modprobe dummy
Mon serveur me répond :
FATAL: Could not load /lib/modules/2.6.38.2-grsec-xxxx-grs-ipv6-64/modules.dep: No such file or directory
Bonjour
pour dummy j’ai régler autrement j’utilise directement le bridge sans interface dummy
ppb
Après 2-3 recherches sur le net, il semble que le noyau d’OVH soit monolithique et ne permet pas de charger dynamiquement des modules. Et malgré le fait que tu ais installé le noyau 2.6.32, tu n’arrives toujours à rien.
Si tu n’as modifié le grub pour booter sur le 2.6.32, tu bootes sans doute toujours sur le noyau d’OVH. Un petit uname -a te dira le noyau actuellement installé.
Si tu ne l’as pas fait, regarde la fin de /boot/grub/grub.cfg pour voir en quelle position est ton noyau dans le grub. Voici la fin du mien :
### BEGIN /etc/grub.d/06_OVHkernel ###
menuentry « Debian GNU/Linux, OVH kernel 2.6.34.6-xxxx-grs-ipv6-64 » {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)’
search –no-floppy –fs-uuid –set
d2bdc4b8-506c-4514-98f1-dc0cf8c1b9ab
linux /boot/bzImage-2.6.34.6-xxxx-grs-ipv6-64 root=/dev/sda1
ro quiet
}
### END /etc/grub.d/06_OVHkernel ###
>>
### BEGIN /etc/grub.d/10_linux ###
menuentry ‘Debian GNU/Linux, avec Linux 2.6.xxx’ –class debian
–class gnu-linux –class gnu –class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)’
search –no-floppy –fs-uuid –set
d2bdc4b8-506c-4514-98f1-dc0cf8c1b9ab
echo ‘Chargement de Linux 2.6.xxx …’
linux /boot/vmlinuz-2.6.xxx root=/dev/sda1 ro quiet
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.xxx
}
menuentry ‘Debian GNU/Linux, avec Linux 2.6.xxx (mode de
dépannage)’ –class debian –class gnu-linux –class gnu –class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)’
search –no-floppy –fs-uuid –set
d2bdc4b8-506c-4514-98f1-dc0cf8c1b9ab
echo ‘Chargement de Linux 2.6.xxx …’
linux /boot/vmlinuz-2.6.xxx root=/dev/sda1 ro single
echo ‘Chargement du disque mémoire initial …’
initrd /boot/initrd.img-2.6.xxx
}
### END /etc/grub.d/10_linux ###
Comme tu peux le voir, le noyau ovh est le premier de la liste et donc grub boote dessus par défaut. Pour modifier ça, j’ai modifié le fichier /etc/default/grub et mis cette option : GRUB_DEFAULT=1 (il faut compter les positions à partir de zéro). Ensuite il faut lancer la commande update-grub en root et rebooter ton serveur. Contrôle avec uname -a que tu as maintenant le bon noyau
Voilà qui devrait résoudre ton problème. Si ça ne fonctionne toujours pas, tu peux toujours ajouter
deb http://mirror.ovh.net/debian/ testing main
à ton /etc/apt/sources.list et lancer
apt-get update&& apt-get install linux-image-2.6.38-2-amd64
(si ton architecture est amd64 bien sûr) et rebooter. Ce noyau étant plus récent que celui d’OVH, grub devrait booter dessus en priorité.
N’oublie pas de supprimer la ligne que tu as ajouté au /etc/apt/sources.list et de faire un apt-get update, sinon tu risques de te retrouver en testing à la prochaine mise à jour, ce qui n’est pas trop conseillé sur un serveur 😉
Bonjour
Après une installation fonctionnelle de LXC je voudrais pouvoir installer dans un conteneure une distribe UBUNTU
j’ai voulu utiliser le script prévu dans le pkg LXC ça ne fonctionne pas, pour vériffier j’ai tenté :
debootstrap –arch -amd64 lucid /lxc/myvm/ http://fr.archive.ubuntu.com/ même souci :
I: Retrieving Release
E: Failed getting release file http://fr.archive.ubuntu.com/dists/natty/Release
Que ce soi pour natty lucid et les autres, sur diffèrents serveur ubuntu
Je ne comprends pas mon problème, sachant que pour un chroot Debian ça fonctionne bien, pour Archlinux aussi.
Grand merci d’avance.
PPB
Essaye voir avec http://fr.archive.ubuntu.com/ubuntu/ ?
Ton message d’erreur va chercher dans un répertoire qui n’existe pas.
La bonne URL est
http://fr.archive.ubuntu.com/ubuntu/dists/natty/Release
donc je pense que rajouter /ubuntu/ à la fin de ton URL devrait marcher.
Re moi
Je voudrais pouvoir cloner des VMs entre serveurs ou après une réinstallation sur un même serveur.
Pour ce là, je compresse puis les décompresses les VMs….
Le souci: tans que c’est sur la même installation pas de difficulté, par contre après une réinstallation d’un serveur ou le clonage par ssh sur un autre ça ne marche pas
Je précise, j’adapte chaque fois le fichier conf de la VMs cloner en fonction du nom du dossier qui la contient, je change l’adresse MAC et IP et les chemins dossier
La réponse apprés un lxc-start :
lxc-start: No such file or directory – failed to exec /sbin/init
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn ‘cloudc141’
Bon je ne pige pas, je dois louper un truc
Grand merci d’avance, comme d’ab
A+
PPB
Yeah ça rocks !!!!
Je me tape juste des Warnings quand je crée une vm au sujet des langues :
warning: setting locale failed
LANGUAGE = « fr_FR:fr »
Bon j’ai résolu ce problème en modifiant le fichier lxc-debian-squeeze
Je vire le if [ -z « $LANG » ]; then … fi
et je mets :
echo « fr_FR.UTF-8 UTF-8 » > $rootfs/etc/locale.gen
chroot $rootfs locale-gen fr_FR.UTF-8 UTF-8
chroot $rootfs update-locale LANG=fr_FR.UTF-8
Par contre, j’ai ajouté des paquets comme aptitude et iputils-ping et il ne semlbe pas me les installer …
arf, c’était juste un problème de cache.
Donc au passage, j’ai édité le fichier lxc-debian-squeeze et dans debian_install j’ai changé le nom du dossier pour le cache. J’ai mis debian-squeeze. Histoire que le cache soit pas le même quand on installe une vm lxc-debian et une vm lxc-debian-squeeze
je te conseille de faire un « dpkg-reconfigure locales » et de mettre les bonnes options claviers !!
Bonjour à tous et à toutes
Ce petit mot est là pour signaler la mise en chantier d’un site consacré à étude et à la création d’une solution de mise en place de VM LXC et KVM.
Je m’inspire de http://www.proxmox.com/products/proxmox-ve et de http://archipelproject.org/
Par contre, Promos n’intègre pas LXC et Archipel est trop complexe à installer.
Cette solution a comme cahier des charges :
1 de fonctionner sur Debian (possibilité d’un kernel plus adapté)
2 de s’installer très facilement
3 de permettre la migration la sécurisation et la redondance des serveurs
4 Le projet sera sous licence GPL
Le but avoué est la possibilité pour la société que je monte actuellement (pas de forme juridique encore définie) de proposer à mes client une solution clef en main.
Vu que la solution sera GPL elle est bien entendue non soumise commercialement à des contraintes, la société facturera les services nécessaires à la mise en place et aux suivis.
Je précise cela par honnêteté et pour montrer le sérieux de la démarche.
Actuellement auto entrepreneur j’installe déjà des solutions virtualisées autour de Linux.
Toutes contributions seront les bienvenues, car seul il est difficile de progresser.
le site : http://my-cloud-control.org/
A+
PPB
PS je n’avais pas bien relu peut-on reprendre les fautes, car je ne vois pas de moyen pour les rectifier.
Merci
PPB
C’est fait !
Plutôt que d’ajouter une route à la main, pourquoi ne pas modifier la valeur de gateway dans le fichier interfaces ?
Oui, pourquoi pas ?
Je t’avouerai que j’ai tellement bloqué sur mes problèmes de lxc que quand j’ai trouvé une solution qui fonctionnait, je n’ai pas été chercher plus loin, même si ce n’est pas forcément la solution idéale ou la plus propre.
Sur les lxc, je suis l’adage « Si ça marche, n’y touche pas ! ».
Salut de viens de configurer lxc sur ma debian squeeze grâce à votre document. J’arrive à démarrer la vm0 en tapant la commande « lxc-start -n vm0 -d » j’ai la réponse « Is runnig » en tapant « lxc-info -n vm0 »
Une fois la commande « lxc-console -n vm0 » lancée j’accède à la console mais plus aucune commande ne répond excepté « ctrl+a q » pour quitter la console.
Ma question: comment faire pour installer un miroir « squeeze » sur la machine virtuelle « vm0 »?
Merci de votre aide
Il me semble qu’on ne voit pas forcément l’invite de login lors du « lxc-console -n vm0 ».
Sachant que les login et mot de passe par défaut sont ‘root’ et ‘root’, essaye donc de te logger même si tu ne vois rien s’afficher.
Pour ton miroir Debian, je n’en ai aucune idée. Google me donne http://smhteam.info/wiki/?wiki=CreerUnMirroirDebianLocal tu pourrais essayer.
Salut,
Personnellement je suis utilisateur d’OpenVZ pour tout ce qui est virtualisation légère, je me suis dernièrement intéressé à XLC étant donnée que Debian annonce suspendre son support d’OpenVZ dans ses futures releases. Malheureusement, les capacités d’LXC sont pour moi encore trop faibles, il n’y pas par exemple pas à ma connaissance de gestion des ressources disques, ce qui peut causer des soucis de sécurité (attaque DoS basée sur le remplissage de l’espace disque).
Il manque aussi de flexibilité : Pas d’outils pour le dump/restauration des VM, d’outils pour la migration à chaud ou à froid….Etc. Ceci me poussera plus tard à passer plus tard à CentOS puisque le support d’OpenVZ chez REDHAT est toujours d’actualité.
Bref, pour le milieu professionnel je pense que ce n’est pas encore une solution totalement viable. Au travail et sur mon serveur personnel je continue donc à utiliser OpenVZ. Sur nos serveurs supportant la virtualisation matérielle nous utilisons KVM.
Sinon pour revenir sur le projet Archipel, celui-ci est intéressant mais après l’avoir installé je lui reproche d’être assez lent et il ne semble pas supporter OpenVZ contrairement à ce qui est mentionné sur leur site (cela proviendrait d’une limitation de libvirt).
J’ai pensé développé une outil web basé sur libvirt et des scripts python pour gérer de manière centralisé des VM de différent type (KVM, Xen, VMWARE, LXC, OpenVZ et Vserver). Je comptais utiliser un framework python type Django ainsi qu’un framework Javascript comme mochaui.org.
Bonjour. J’ai appris à maîtriser LXC grâce à des vidéos sur http://www.alphorm.com/tutoriel/formation-en-ligne-lxc et je trouve que ce tutoriel est très réussi.