Intéressé par des cours d'informatique en ligne ?
Visitez mon nouveau site
https://www.yesik.it !
Si l'on devait faire un palmarès des technologies à la mode, Xen – et la virtualisation en général – arriveraient certainement très bien placés. Honte à moi (?), c'est pourtant un domaine que j'avais laissé de côté. Voilà qui est chose réparée avec cet article où je décris mes premiers pas de Xenologue.
Si vous cherchez donc comment installer l'hyperviseur Xen sur une distribution Debian/Lenny, ou encore comment utiliser les xen-tools pour rapidement créer une première machine virtuelle, je vous propose de suivre mes pas dans la suite de cet article.
Sommaire
Vocabulaire
Avant de s'atteler à la mise en oeuvre technique de Xen, il est nécessaire de préciser quelques points de vocabulaire. En effet, dès que l'on parle de Xen, un certain nombre de termes de jargon apparaissent. Autant savoir tout de suite de quoi on parle.
Tout d'abord, Xen est un hyperviseur. C'est à dire un logiciel qui s'intercale entre le matériel (hardware) et le système d'exploitation. Une des fonctionnalités principales de Xen est de pouvoir héberger plusieurs systèmes d'exploitation et les faire tourner en parallèle. Ainsi, il est possible d'avoir sur la même machine physique plusieurs machines virtuelles. Chacune utilisant son propre système d'exploitation. On se reportera à la documentation officielle pour les cas d'usage typiques.
Un autre terme qui surgit très souvent est celui de domaine. C'est juste, dans la terminologie de Xen, une des machines virtuelles hébergée sur votre machine physique.
Une des spécificités de Xen est de distinguer deux types de domaines. Connus sous les noms de dom0 (ou domaine hôte) et domU (ou domaine invité).
| dom0 (domaine hôte) | domU (domaine invité) | |
| Par machine physique | 1 | 0 à N |
| Rôle | Supervision | Services |
Sur une machine Xenifiée il y a toujours 1 et 1 seul dom0. Par contre il peut y avoir autant de domU que les ressources de la machine le permettent. Il y a plusieurs raisons qui rendent le dom0 un peu particulier. Tout d'abord, c'est le domaine lancé au démarrage de la machine physique. Mais surtout, ce domaine a des privilèges qui lui permettent de contrôler les autres domaines (les domU) hébergés sur la machine. Nous verrons aussi dans quelques instants que le dom0 a aussi un rôle particulier vis-à-vis de la gestion de réseau. Mais ne brûlons pas les étapes, et passons sans plus tarder à l'installation.
Installer Xen
Ici, ma machine cible est un serveur sur lequel Debian/Lenny a déjà été installé. Pour mettre en place la virtualisation, j'ai donc besoin:
- de l'hyperviseur Xen,
- et d'un noyau Linux avec le support Xen qui me servira de dom0.
Remarque:
La technique de paravirtualisation originellement mise en oeuvre dans Xen nécessite que les systèmes d'exploitation soient spécialement portés pour être utilisés sous Xen.
Ceci dit, les technologies AMD-V et Intel VT présentes sur certains micro-processeurs permettent de lever cette limitation. A partir de sa version 3.0, Xen sait en tirer parti pour faire tourner des OS non modifiés en domaine invité. Ce qui permet par exemple d'utiliser des systèmes d'exploitation propriétaires comme Microsoft Windows.
Néanmoins, dans mon cas, comme ma machine n'a pas le support pour cette technique, je suis contraint d'utiliser des kernels spécifiquement modifiés pour utiliser Xen.
La plupart des distributions Linux offrent des paquets pour Xen et des versions modifiées de leurs noyaux. C'est le cas pour Debian. Nous allons donc installer ces paquets:
knuth:~# apt-get xen-hypervisor-i386 install linux-image-xen-686
Si votre hardware n'est pas trop exotique (voir encadré plus bas), au prochain démarrage de votre machine vous devriez avoir la possibilité de booter sur Xen. Et celui-ci lancera dans la foulée le dom0 dont nous venons d'installer le kernel.
knuth:~# reboot
A cette étape, mis à part quelques messages supplémentaires pendant le boot de la machine, du point de vue de l'utilisateur rien ne semble avoir changé.
Xen sur portable
Contrairement à une idée reçue, Xen peut fonctionner sur un ordinateur portable (dixit le wiki de Xen).
Ceci dit, j'ai été incapable de faire tourner les kernels standard Debian avec le support Xen de Debian sur mon Acer TravelMate 4603ELMI. Et si j'ai pu booter sur un kernel compilé par mes soins avec le support de Xen, j'ai expérimenté des plantages réguliers – et des pertes de données. Faites-moi savoir si vous êtes plus chanceux...
Vérifier que Xen "tourne"
D'accord: vous avez installé les paquets nécessaires et rebooté la machine. Mais êtes-vous vraiment "sous Xen"? Pour en avoir le coeur net, nous allons utiliser l'outil xm. Celui-ci permet de contrôler les différents domaines invités à partir du dom0. Ici, pour obtenir la liste des domaines actifs sur la machine:
knuth:~# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1881 4 r----- 63.1
Pour l'instant, il n'y a que le dom0 dans la liste. Normal: nous n'avons pas encore créé de domU. Et bien rassurez-vous, c'est ce que nous allons faire... juste après avoir fait un poil de configuration!
Configurer Xen
La configuration de Xen se fait à partir du fichier /etc/xen/xend-config.sxp. Les différentes options sont relativement explicites. Et en ce qui concerne cet article, nous n'allons pas de toute manière faire de grosses modifications. Seulement configurer la manière dont nos différents domaines vont se connecter au réseau.
Pour bien comprendre, il faut savoir que dans l'architecture réseau de Xen, chaque domaine invité est relié au domaine hôte via une interface virtuelle. Ensuite, le domaine hôte peut gérer ces différentes interfaces comme l'administrateur le souhaite (via les outils Linux classiques comme iptables). Le plus simple – et ce que nous allons mettre en oeuvre ici – est d'utiliser le mode bridged. Dans ce mode, le dom0 assure le routage des paquets entres les différentes interfaces. Et donc, tout va se passer comme si un switch était placé entre les cartes réseaux virtuelles et la carte physique.
Ce mode de fonctionnement est supporté en standard par Xen. Pour le mettre en oeuvre, il suffit donc de modifier le fichier xend-config.sxp pour ajouter la ligne:
(network-script 'network-bridge netdev=eth0')
Il faut aussi penser à supprimer – ou à mettre en commentaire (en ajoutant un dièse au début de la ligne) – toutes les autres directives network-script éventuellement présentes:
# (network-script network-dummy)
Après toute modification de la configuration de Xen, il est impératif de redémarrer xend:
knuth:~# /etc/init.d/xend restart
xm et xend
Peut-être vous souvenez vous que nous avons utilisé xm il y a quelques instants pour afficher la liste des domaines actifs?
Et bien, en réalité, xm est juste une interface qui permet de communiquer avec xend. Mais en coulisse, c'est bien ce dernier qui gère les différents domaines. Ainsi, par exemple, c'est xend qui démarrer les machines virtuelles ou les arrête.
Créer une machine virtuelle
Note:
Ici, je vais créer des domU qui tourneront aussi sous Debian/Lenny. C'est plus simple pour cette prise en main. Mais il est tout à fait possible de créer des domU pour d'autres distributions Linux – ou d'autres systèmes d'exploitation.
Toujours par souci de simplicité, nous allons utiliser le paquet xen-tools pour faciliter la création des machines virtuelles.
knuth:~# apt-get install xen-tools
Configuration des xen-tools
Une fois l'installation des xen-tools terminée, il est nécessaire d'ajuster la configuration de cet outil à vos besoins. Jetez un oeil au fichier /etc/xen-tools/xen-tools.conf et faites les modifications adaptées à votre cas. En ce qui me concerne, j'ai dû ajuster les sections suivantes:
Dossier destination des images
Tout d'abord, je voulais que les images soient crées dans le répertoire /var/xen (option dir):
#
##
# Output directory for storing loopback images.
#
# If you choose to use loopback images, which are simple to manage but
# slower than LVM partitions, then specify a directory here and uncomment
# the line.
#
# New instances will be stored in subdirectories named after their
# hostnames.
#
##
# dir = /home/xen
dir = /var/xen
#
Changement de distribution
Ensuite, je voulais créer des domU sous Lenny (option dist):
#
##
# Disk and Sizing options.
##
#
size = 4Gb # Disk image size.
memory = 128Mb # Memory size
swap = 128Mb # Swap size
# noswap = 1 # Don't use swap at all for the new system.
fs = ext3 # use the EXT3 filesystem for the disk image.
dist = lenny # Default distribution to install.
image = sparse # Specify sparse vs. full disk images.
Adresse IP statique
Ici, comme j'utilise des adresses IP statique, j'en profite pour fixer une fois pour toute la passerelle, le masque de sous-réseau et l'adresse de diffusion:
## # Networking setup values. ## # # Uncomment and adjust these network settings if you wish to give your # new instances static IP addresses. # gateway = 10.129.36.245 netmask = 255.255.255.0 broadcast = 10.129.36.255
Demander le mot de passe root
Très important – sinon vous ne pourrez pas vous connecter sur votre machine virtuelle – je veux que le script demande le mot de passe root de la machine à créer (option passwd):
#
# Uncomment the following line if you wish to interactively setup
# a new root password for images.
#
passwd = 1
Miroir pour le téléchargement des paquets
Enfin, pour économiser ma bande passante, je veux que les paquets nécessaires à l'installation des domU soient téléchargés à partir d'un proxy APT sur mon réseau local (option mirror):
#
# The default mirror for debootstrap to install Debian-derived distributions
#
mirror = http://10.129.36.102:9999/debian/
Créer un domU
Ouf: la configuration de xen-tools est prête. Maintenant, la création d'une nouvelle machine virtuelle ne nécessite plus qu'un appel à la commande xen-create-image:
knuth:~# mkdir /var/xen
knuth:~# xen-create-image --hostname=virthal --ip=10.129.36.150
General Information
--------------------
Hostname : virthal
Distribution : lenny
Partitions : swap 128Mb (swap)
/ 4Gb (ext3)
Image type : sparse
Memory size : 128Mb
Kernel path : /boot/vmlinuz-2.6.26-2-xen-686
Initrd path : /boot/initrd.img-2.6.26-2-xen-686
Networking Information
----------------------
IP Address 1 : 10.129.36.150 [MAC: 00:16:3E:A6:ED:3C]
[...]
Ne vous éloignez pas trop quand même, puisqu'au bout d'un moment le mot de passe root de la nouvelle machine va vous être demandé:
[...] Creating Xen configuration file Done Setting up root password Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully All done Logfile produced at: /var/log/xen-tools/virthal.log
Remarque:
La création de la machine virtuelle avec xen-create-image est un processus automatisé, potentiellement assez long – et qui implique de télécharger un certain nombre de paquets. C'est dire qu'il y a plein de petites choses qui peuvent aller de travers au cours de cette opération. Je vous conseille donc de garder un oeil aux logs de xen-create-image à partir d'une autre console. Histoire d'être averti si quelque-chose va mal:
knuth:~# tail -F /var/log/xen-tools/virthal.log
Démarrer le domU
A ce stade, nous avons sur le disque une image de la machine virtuelle à démarrer. En fait 2 images disque même:
- Une pour le disque principal (contenant le système de fichier racine): disk.img;
- et une pour le disque de swap: swap.img
knuth:~# ls /var/xen/domains/virthal/ disk.img swap.img
Mais xen-create-image a aussi créé un troisième fichier. Dans /etc/xen:
knuth:~# ls /etc/xen
scripts virthal.cfg xend-config.sxp xend-config-xenapi.sxp xend-pci-permissive.sxp xend-pci-quirks.sxp
Le fichier /etc/xen/virthal.cfg contient toutes les informations nécessaires pour démarrer la machine virtuelle virthal. Reste à effectivement démarrer cette machine virtuelle! Ici, nous allons retrouver la commande xm:
knuth:~# xm create virthal.cfg -c
Note:
L'option -c attache une console à la machine virtuelle. Autrement dit, vous pourrez suivre tout le processus de boot comme lorsque vous démarrez une machine physique. Idéal pour identifier un problème ... ou juste satisfaire votre curiosité!
Par ailleurs, à l'issue du boot cette console va être très précieuse, puisqu'elle vous permettra aussi de vous loguer sur la machine...
stdin: is not a tty
Sous Lenny j'ai eu un problème: la machine virtuelle démarrait, mais au lieu du login attendu j'avais le message d'erreur:
stdin: is not a tty
Si vous rencontrez le même problème, la solution est d'ajouter la ligne suivante dans /etc/xen/virthal.cfg:
extra = 'console=hvc0 xencons=tty'
Si vous avez été au bout du processus de démarrage du domaine invité, vous devriez voir sur la console le message de login:
Debian GNU/Linux 5.0 virthal tty1 virthal login:
Nous voici donc arrivé au terme de l'installation du domaine virthal. N'hésitez pas à vous connecter sur cette nouvelle machine et à expérimenter pour vous convaincre qu'elle fonctionne effectivement (et que c'est bien une autre machine!). Vous pouvez aussi vérifier le lancement du domaine invité avec xm (à partir d'une console de votre domaine hote – dom0):
knuth:~# xm list
Name ID Mem VCPUs State Time(s)
Domain-0 0 1878 4 r----- 74.6
virthal 1 128 1 -b---- 15.3
Voilà: Xen fait bien tourner en parallèle sur votre machine physique deux machines virtuelles: Domain-0 et virthal.
Pour quelques xm de plus
Il est temps de noter aussi d'autres sous-commandes de xm qui peuvent vous être utiles.
Ainsi, outre xm create et xm list que vous connaissez déjà, vous pourrez avoir rapidement besoin de:
- xm shutdown pour arrêter normalement un domaine;
- xm destroy pour mettre fin brusquement à un domaine;
- xm reboot pour redémarrer un domaine;
- xm console pour attacher une nouvelle console à un domaine actif.
Ces commandes utilisent toutes l'identifiant du domaine, pas son nom! Vous pouvez obtenir cet identifiant via xm list:
knuth:~# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1878 4 r----- 101.4 virthal 3 128 1 -b---- 16.5 knuth:~# xm reboot 3 knuth:~# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 1878 4 r----- 109.3 virthal 4 128 1 --p--- 0.0 knuth:~# xm console 4 virthal login:
Vous noterez au passage que le redémarrage du domaine a eu pour conséquence de changer sont ID. N'oubliez donc pas: en cas de doute, xm list est votre ami...
Accès "à distance"
Dans le titre de cette section, j'ai mis le terme "à distance" entre guillemets, car ce que nous allons voir peut être fait aussi bien sur une autre machine physique du réseau, qu'à partir d'une autre domaine hébergé sur la même machine physique! C'est aussi la beauté de la virtualisation: dans la plupart des cas, la machine virtuelle va se comporter comme si c'était une autre machine physique placée sur le réseau...
Piège:
A partir d'ici, les choses vont se compliquer puisque nous allons devoir jongler avec différentes machines. Dans ce qui suit, pour les commandes à taper, j'ai systématiquement pris soin d'indiquer dans le prompt le nom de la machine pour que vous vous y retrouviez plus facilement. A titre de résumé:
- knuth est le dom0 hébergé sur mon serveur;
- virthal est le domU créé plus haut – et s'exécutant sur la même machine physique que knuth;
- hal est une autre machine physique, quelque part sur le réseau – et qui nous servira pour quelques tests.
ping
Bon, pour commencer, nous allons rester simple. Et quoi de plus simple que d'essayer de pinguer notre nouvelle machine? Du dom0 au domU pour commencer:
knuth:~# ping virthal PING virthal (10.129.36.150) 56(84) bytes of data. 64 bytes from virthal (10.129.36.150): icmp_seq=1 ttl=64 time=0.548 ms 64 bytes from virthal (10.129.36.150): icmp_seq=2 ttl=64 time=0.139 ms 64 bytes from virthal (10.129.36.150): icmp_seq=3 ttl=64 time=0.137 ms 64 bytes from virthal (10.129.36.150): icmp_seq=4 ttl=64 time=0.138 ms
Puis du domU au dom0:
virthal:~# ping knuth PING knuth.esicom-st-malo.fr (10.129.36.100) 56(84) bytes of data. 64 bytes from knuth.esicom-st-malo.fr (10.129.36.100): icmp_seq=1 ttl=64 time=0.198 ms 64 bytes from knuth.esicom-st-malo.fr (10.129.36.100): icmp_seq=2 ttl=64 time=0.137 ms 64 bytes from knuth.esicom-st-malo.fr (10.129.36.100): icmp_seq=3 ttl=64 time=0.107 ms
Bon visiblement, le pont réseau virtuel entre les différents domaines fonctionne. Qu'en est-il d'une autre machine physique du réseau?
[hal:~] sylvain% ping 10.129.36.100 PING 10.129.36.100 (10.129.36.100): 56 data bytes 64 bytes from 10.129.36.100: icmp_seq=0 ttl=64 time=1.651 ms 64 bytes from 10.129.36.100: icmp_seq=1 ttl=64 time=0.417 ms 64 bytes from 10.129.36.100: icmp_seq=2 ttl=64 time=1.533 ms ^C --- 10.129.36.100 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.417/1.2/1.651 ms [hal:~] sylvain% ping 10.129.36.150 PING 10.129.36.150 (10.129.36.150): 56 data bytes 64 bytes from 10.129.36.150: icmp_seq=0 ttl=64 time=2.088 ms 64 bytes from 10.129.36.150: icmp_seq=1 ttl=64 time=1.586 ms 64 bytes from 10.129.36.150: icmp_seq=2 ttl=64 time=0.895 ms 64 bytes from 10.129.36.150: icmp_seq=3 ttl=64 time=1.618 ms ^C --- 10.129.36.150 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.895/1.546/2.088 ms
Bon OK: "ça passe". Il est temps de passer à quelque-chose de plus sérieux...
ssh
Lorsque nous avons démarré notre domU, nous lui avons attaché une console (option -c de xm create). Mais xen-create-image a aussi installé d'emblée sur notre machine virtuelle sshd. Autrement dit, nous devrions pouvoir nous connecter "à distance" sur notre domU via ssh:
knuth:~# ssh virthal
root@virthal's password:
virthal:~#
Le retour de "stdin: is not a tty"
Malheureusement, sous Lenny, j'ai à nouveau rencontré un problème ici:
[hal:~] sylvain% ssh root@10.129.36.150
root@10.129.36.150's password:
stdin: is not a tty
Et après ce message d'erreur, la console restait bloquée. Le problème vient de ce que xm-create-image n'installe pas udev. Il faut le faire manuellement.
Le plus simple est de se connecter sur la machine virtuelle à partir de la console attachée lors de sa création, puis d'utiliser APT pour installer le paquet nécessaire:
knuth:~# xm create virthal.cfg -c # Si nécessaire
[...]
Starting periodic command scheduler: crond.
Debian GNU/Linux 5.0 virthal tty1
virthal login: root
Password:
[...]
virthal:~# apt-get install udev
Conclusion
A l'origine, je voulais écrire une introduction rapide à Xen. Mais, de détails en petits soucis, finalement cet article s'avère plus long que prévu.
J'espère en tous cas que cela pourra vous aider à découvrir le monde de la virtualisation sous Xen – et le cas échéant vous aider à résoudre des problèmes similaires à ceux que j'ai rencontrés lors de la mise en place Xen sur mon serveur!
Références
- http://tx.downloads.xensource.com/downloads/docs/user/user.html – Le manuel de Xen
- http://wiki.xensource.com/xenwiki/XenNetworking – Xen et le réseau
- http://www.xen-tools.org/software/xen-tools/examples.html – Exemple d'utilisation de xen-create-image
- http://en.wikipedia.org/wiki/Xen – Xen sur Wikipedia
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502798 – Le bug udev chez Debian...
- http://lists.xensource.com/archives/html/xen-users/2006-09/msg00283.html – ...et chez Xen
