Lxc sur Debian

Les Linux contai­ners (lxc) sont une solu­tion d’iso­la­tion ou de virtua­li­sa­tion (selon l’uti­li­sa­tion) à l’ins­tar des Jails BSD. Contrai­re­ment à d’autres solu­tions simi­laires (vser­ver ou openvz) sous Linux, les lxc ne néces­sitent pas de patch du noyau car faisant direc­te­ment partie de la branche prin­ci­pale du déve­lop­pe­ment du noyau. Même si lxc est jeune (donc souf­frant d’un certain nombre de bugs), il s’agit d’une solu­tion déjà fonc­tion­nelle. Je vais décrire ici l’ins­tal­la­tion et la confi­gu­ra­tion de lxc sur une Debian Squeeze dispo­sant d’une seule inter­face avec une IP publique (comme sur un serveur dédié quoi).

Prépa­ra­tion du système

On installe d’abord lxc et deboots­trap :

# apt-get install lxc debootstrap

Il nous faudra aussi créer un bridge lié à une inter­face dummy :

# apt-get install bridge-utils
# modprobe dummy

Ensuite il faut créer un bridge. Ajou­tez ceci au fichier /etc/network/inter­faces :

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 char­ger cette nouvelle confi­gu­ra­tion :

# /etc/init.d/networking restart

Prépa­ra­tion des cgroups

Pas très compliqué :

# mkdir /cgroup
# echo "cgroup        /cgroup        cgroup        defaults    0    0" >> /etc/fstab
# mount cgroup

Véri­fi­ca­tion de la confi­gu­ra­tion de lxc

Cela se fait à l’aide de la commande lxc-check­con­fig :

$ 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’ob­te­niez pas enabled sur la ligne File capa­bi­li­ties. Vous aurez alors besoin d’ins­tal­ler libcap2-bin :

# apt-get install libcap2-bin

Créa­tion d’un contai­ner

Le paquet lxc four­nit un moyen très simple de créer un contai­ner Debian via le script /usr/lib/lxc/templates/lxc-debian mais celui-ci ne four­nit qu’une debian lenny, sans comp­ter que son chemin d’ac­cè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 rempla­cez :

SUITE=${SUITE:-lenny}

par

SUITE=${SUITE:-squeeze}

et

dhcp3-client,\

par

isc-dhcp-client,\

Vous êtes libre d’ajou­ter les paquets que vous voulez avoir par défaut dans votre contai­ner dans la liste des paquets déjà présente (htop et multi­tail par exemple). Vous avez un réper­toire tout près à accueillir vos contai­ners 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ér­toire qui contien­dra le contai­ner et celui-ci dans la foulée:

# mkdir /lxc/vm0
# lxc-debian-squeeze -p /lxc/vm0

Le réper­toire /lxc/vm0 contien­dra un fichier config et un réper­toire rootfs. Voici le contenu du fichier de confi­gu­ra­tion du contai­ner :

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

Ajou­tez 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 commen­tée car eth0 est la valeur par défaut de l’in­ter­face du contai­ner. Libre à vous de la modi­fier.

ATTENTION : pour que vos contai­ners soient en mesure de commu­niquer entre eux, prenez soin de chan­ger leur adresse mac virtuelle ! (ligne lxc.network.hwaddr)

Si vous n’avez pas de serveur dhcp et ne voulez pas vous embê­ter à en instal­ler un, allez dans le réper­toire rootfs et modi­fiez le fichier etc/network/inter­faces 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

Ajou­tez ceci au fichier etc/rc.local (toujours dans /lxc/vm0/rootfs, hein !):

route add default gw 192.168.1.1

Se simpli­fier la vie

Vous pouvez télé­char­ger ma lxc-debian : elle est en squeeze et surtout elle permet de choi­sir l’adresse ip, l’adresse mac et le host­name du contai­ner et ça ajoute la route dans rc.local lors de sa créa­tion. Par contre je n’ai pas mis de sécu­rité si on ne précise pas ces para­mêtres et certaines ip sont en dur donc « bla bla bla logi­ciel fourni bla bla bla aucune garan­tie bla bla bla à vos risques et périls ».

Confi­gu­rer le fire­wall

Et oui, sans fire­wal­ling, vos contai­ners vont avoir du mal à commu­niquer avec inter­net ! (sauf si vous les avez direc­te­ment 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 à chan­ger 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 main­te­nant lancer vos contai­ners :

# lxc-start -n vm0 -d

Les stop­per :

# 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_Contai­ners_to_set_up_virtual_networks

21 réflexions au sujet de “Lxc sur Debian”

  1. merci pour billet bien utile.
    j’ai pu mettre en place des machines virtuelles sans problème.
    à moi l’autohébergement !

  2. 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

  3. 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 😉

  4. 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

  5. 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

  6. 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 !!

  7. 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

  8. PS je n’avais pas bien relu peut-on reprendre les fautes, car je ne vois pas de moyen pour les rectifier.
    Merci
    PPB

  9. 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 ! ».

  10. 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.

  11. 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.

Les commentaires sont fermés.