Virtualisation xen install
From UnixWiki
Nous allons maintenant étudier la mise en place de xen, en utilisant le noyau précompilé fourni par le site officiel, et en configurant le réseau pour fonctionner sur un bridge.
Contents |
[edit] Installation
Tout d'abord, téléchargez le paquet xen-3.0.0-install-x86_32.tgz. Ces fichiers sont disponibles sur le site officiel.
[edit] Installation des fichiers de Xen
Commencez par décompresser l'archive dans un dossier temporaire:
# tar xfzp xen-3.0.0-install-x86_32.tgz # cd xen-3.0.0-unstable-install
Dans le dossier d'extraction des fichiers, vous trouverez un script d'installation, que vous devrez lancer:
# ./install.sh
Ce script va commencer par vérifier que vous disposez bien des prérequis sur votre système. Dans le cas contraire, il vous affichera un message pour vous indiquer ce que vous devez installer par ailleurs. Si la vérification s'est bien passée, le script va copier les fichiers du noyau dans /boot, les modules correspondants dans /lib/modules, les scripts de démarrage et les paramètres dans /etc, et enfin les commandes de gestion dans /usr et ses sous-dossiers.
[edit] Gestionnaire d'amorçage
La prochaine étape consiste à mettre à jour votre gestionnaire d'amorçage pour démarrer sur le noyau vmlinuz-xen0 qui aura été installé pour le système hôte. Il est impératif d'utiliser Grub, car Lilo ne permet pas de faire fonctionner Xen.
Pour cela, éditez le fichier /boot/grub/menu.lst avec votre éditeur préféré. Il est fortement conseillé de garder les entrées permettant de démarrer sur votre ancien noyau, au cas où il y aurait un problème. Vous devrez ajouter les lignes suivantes:
title Xen 3.0.0 kernel /boot/xen-3.0.0.gz dom0_mem=128M module /boot/vmlinuz-2.6.12.6-xen0 root=/dev/hda1 ro console=tty0
Vous remarquerez que le fichier fourni à grub est d'une taille inférieure à un noyau habituelle, puisqu'il fait autour de 200 Ko. Ce fichier a pour rôle d'initialiser le système et se charge de démarrer le vrai noyau, c'est à dire vmlinuz-2.6-xen0. Pensez à remplacer hda1 par la partition qui correspond chez vous à la partition principale de votre système Linux. De plus, vous pouvez modifier la quantité de mémoire réservée au système hôte. La quantité s'exprime en Kilo-Octets, à moins que vous n'utilisiez le suffixe M pour préciser qu'il s'agit de Mega-Octets.
Avec Grub, contrairement à Lilo, il n'est pas nécessaire de lancer une commande après la modification du fichier de configuration. Cependant, cette opération est nécessaire à la première utilisation de Grub, ou en cas de changement de disque dur, ou dans le partitionnement.
[edit] Démarrage du système
Enfin, vous devez vous assurer que les scripts d'initialisation xend et xendomains situés dans /etc/init.d sont bien démarrés automatiquement, au moins avec le runlevel que vous utilisez. La prise en charge de ces scripts varie selon la distribution de Linux. Vous devez donc vous reporter au manuel correspondant si nécessaire.
Une fois ces opérations terminées, vous pouvez redémarrer votre machine, et choisir l'options que nous venons d'ajouter au démarrage.
Il est possible que le noyau fourni par défaut soit moins complet, et qu'il ne supporte pas tout votre matériel. Dans ce cas, il faudra suivre les instructions qui montrent comment recompiler le noyau pour xen, que vous trouverez un peu plus loin.
En cas de problème, n'hésitez pas à consulter les fichiers logs stockés dans /var/log. Xen en propose deux, et ils vous servirons à comprendre d'ou proviennent les problèmes que vous pourrez rencontrer.
[edit] Fichiers de config
Xen repose sur plusieurs fichiers de configuration. Nous allons étudier les principaux.
[edit] configuration générale
Le fichier /etc/xen/xend-config.sxp définir les paramètres pour le programme xend. C'est un processus qui fonctionne uniquement sur le système hôte, et qui sert à gérer la virtualisation.
Ce fichier comporte des paramètres relatifs à l'administration par une interface web, ou au fichier de log. Le paramètre dom0-min-mem (à zéro par défaut) définit la quantité minimale de mémoire que le système hôte devra conserver. Si cette valeur n'est pas nulle, et qu'il ne reste pas suffisement de mémoire libre pour les domU, xend réduira celle du système hôte pour pouvoir en allouer à un invité.
Nous nous intéresserons surtout aux paramètres relatifs au réseau.
Par défaut, les lignes suivantes sont utilisées:
(network-script network-bridge) (vif-script vif-bridge)
Ceci indique à xend qu'il doit mettre en place une configuration réseau basée sur un bridge (un pont). Il prendra en charge le "raccordement" des interfaces réseau des invités sur ce bridge, lors du démarrage d'un système invité, et ceci automatiquement.
Nous reviendrons plus en détails sur la configuration réseau un peu plus loin.
[edit] configuration d'un système invité
Vous pouvez démarrer des systèmes invités (domU) avec des paramètres de cfonctionnement différents. Pour chaque configuration différente, vous devrez écrire un fichier listant les options. Par exemple, vous pourrez avoir un système Linux Gentoo installé sur /dev/hda8 qui aura 128 Mo de mémoire réservée, et un second système Gentoo Debian installé sur /dev/hda9 qui aura besoin de 64 Mo de mémoire.
Par défaut, le projet xen fournit des exemples de configuration dans les fichiers xmexample1 et xmexample2. Le plus simple est d'en faire une copie et de l'adapter à votre configuration personnelle.
Voici par exemple ce qu'on pourrait y trouver dans un fichier /etc/xen/gentoo, une fois les commentaires retirés:
kernel = "/boot/vmlinuz-2.6.12.6-xenU" memory = 64 name = "gentoo" vif = [ 'mac=aa:00:00:00:00:11, bridge=xenbr0' ] disk = [ 'phy:hda8,sda1,w' ] root = "/dev/sda1 ro"
Ce fichier indique par exemple que le domaine utilisateur appellé gentoo aura 64 Mo de mémoire, qu'il verra une carte réseau ayant l'adresse mac indiquée ici, et que cette carte réseau sera automatiquement reliée au bridge xenbr0 sur le système hôte. Le système gentoo est installé sur la partition /dev/hda8 du disque dur, mais le système hôte va lui dire qu'il s'agit du disque /dev/sda1. Le w indique que le système invité aura accès au disque en écriture, alors qu'un r ne lui aurait permis que la lecture+ sur la partition. Le système invité ne verra aucune des autres partitions du disque physique.
En tapant la commande suivante, vous pouvez démarrer ce système:
xm create gentoo -c
Si vous souhaitez que ce système invité soit chargé en mémoire automatiquement au démarrage du système hôte, il faut placer une copie du fichier dans le dossier /etc/xen/auto, ou un simple lien symbolique. C'est le script de démarrage xendomains qui fera ce travail.
[edit] configuration du gestionnaire de domaines
Le script /etc/init.d/xendomains a pour but de démarrer automatiquement les domaines invités au démarrage de la machine principale, et de la même façon de les arrêter. Ce script prend en charge les fichiers de configuration qu'il trouve dans le dossier /etc/xen/auto.
Pour configurer le comportement de ce script, vous devez éditer le fichier /etc/sysconfig/xendomains. En voici un exemple, dans lequel les commentaires ont été supprimés:
XENDOMAINS_SYSRQ="" XENDOMAINS_USLEEP=100000 XENDOMAINS_MIGRATE="" XENDOMAINS_SAVE=/var/lib/xen/save XENDOMAINS_SHUTDOWN="--halt --wait" XENDOMAINS_SHUTDOWN_ALL="--all --halt --wait" XENDOMAINS_RESTORE=true XENDOMAINS_AUTO=/etc/xen/auto XENDOMAINS_AUTO_ONLY=false XENDOMAINS_STOP_MAXWAIT=300
On voit qu'il est par exemple possible de dire à xendomains de ne pas sauvegarder et restaurer l'état de la machine virtuelle au démarrage et à l'arrêt du système hôte. De même, vous pouvez y définir les chemins de sauvegarde, la façon d'arrêter les machines, ...
[edit] Manipulation des systèmes invités
Les outils de gestion de la virtualisation sont exclusivement gérés sur le système hôte. C'est donc depuis dom0 que vous aurez la main pour créer un nouveau système invité domU, modifier la répartition de la mémoire entre les domaines, ... Aucun outil relatif à xen n'est installé sur les systèmes invités, en dehors du noyau et des modules qui l'accompagnent (dans /lib/modules).
La commande fournie par xen pour assurer le contrôle des systèmes s'appelle xm. Cette commande doit être exécutée avec le compte root, sur dom0. Voici les principales utilisations de cette commande:
- xm create domU -c
Cette commande démarre en mémoire le système invité ayant pour nom domU. Son fichier de configuration doit être accessible via le chemin /etc/xen/domU (remplacer par le nom du domaine utilisateur). De plus, le nom de l'invité dans le contenu du fichier, avec l'option name, doit lui aussi correspondre. Si vous ajoutez l'option "-c" en exécutant la commande alors l'écran de démarrage de la machine et les messages du noyau s'afficheront dans la console courante. Vous pourrez alors utiliser le système par ce biais. Sans cette option, le système sera chargé en mémoire mais rien ne s'affichera à l'écran. Il faudra alors utiliser un client ssh ou vnc pour avoir la main sur ce système.
- xm list
Cette commande affiche la liste des domaines chargés en mémoire, y compris le domaine hôte (dom0). On peut voir la mémoire réservée à chaque sysyème, et l'identificateur qui leur a été attribué.
- xm shutdown domU
Ceci va arrêter le système invité, en effectuant un arrêt normal de la machine, comme si vous aviez lancé la commande halt depuis le système.
- xm destroy domU
L'option destroy arrêtera brutalement le domaine concerné sans passer par la procédure normale de fermeture des processus. Cette commande peut donc aboutir à corrompre les données et le système de fichiers du système concerné. A ne faire qu'en cas de réelle nécessité.
- xm mem-set dom mem
Cela vous permet de redéfinir la quantité de mémoire que vous désirez allouer à un système. Vous devez fournir le nom ou l'identificateur du domaine en premier paramètre, puis la quantité de mémoire en Mega-Octets.
La commande xm propose encore d'autres possibilité avancées comme la possibilité de sauvegarder l'état d'une machine et de la migrer vers un autre système hôte. Ces utilisations avancées sortent du cadre de ce tutoriel.
[edit] Mise en réseau
Chacun des domaines chargés en mémoire sont considérés au niveau logiciel comme une machine à part entière. Si vous voulez pouvoir communiquer entre les machines, il faudra donc leur définir une configuration réseau.
[edit] interfaces réseau des invités
Rappelons que les ressources des domaines utilisateurs sont controllées par le domaine principal, et le réseau n'échappe pas à la règle. Par défaut, chaque domaine invité possèdera une interface ethernet appellée eth0. Vous pouvez en rajouter en modifiant la valeur du paramètre nics dans le fichier de configuration du système invité. Il faudra d'une part effectuer la configuration réseau au niveau de l'invité (attribution d'une adresse IP, ...) et d'autre part faire en sorte que le domaine hôte lui permette de communiquer.
Par défaut, xen choisit lui même l'adresse mac des interfaces réseau qu'il attribue aux systèmes invités. Si cela a une importance, vous pouvez les fixer grâce au paramètre vif du fichier de configuration correspondant au domaine:
vif = [ 'mac=aa:00:00:00:00:11, bridge=xenbr0' ]
Du coté du domaine hôte, une interface réseau sera créée pour chaque interface d'un domaine invité. Le nom de ces interfaces est vifx.y en remplaçant x par l'identifiant de l'invité, et y par le numéro de l'interface. Par exemple, si un domaine ayant pour identifiant 4 possède deux interfaces eth0 et eth1, le système hôte pourra voir vif4.0 et vif4.1. Un paquet envoyé par dom0 sur l'interface vif4.0 arrivera sur l'interface eth0 du domU. L'hôte devra se servir de des interfaces pour relier les systèmes invités au réseau, si nécessaire en installant un fitrage des paquets pour garantir la sécurité.
Attention: l'identifiant (nombre entier attribué au démarrage du domU) d'un domU pouvant varier entre deux exécutions, le nom des interfaces vifx.y changent eux aussi. C'est pour cette raison que le nom des interfaces ne sont pas utilisables de façon fixes dans les fichiers de configuration. Pour remédier à ce problème, les scripts de xen se chargent de relier les interfaces dynamiquement, à chaque lancement d'un système invité.
[edit] Les ponts (bridges)
Avec des machines réelles, le moyen le plus simple de les mettre en réseau est de relier toutes les interfaces ethernet à un swith, qui peut comporter deux ou plusieurs ports. C'est exactement la même technique que xen utilise par défaut pour relier eux les systèmes virtuels.
Un pont est une interface réseau virtuelle visible par ifconfig, comparable à un swith dans le monde réel. Un pont permet d'interconnecter plusieurs interfaces. En général, on y connecte l'interface réelle eth0 du domaine principal, avec les interfaces vifx.y des différents domaines invités. Les paquets émis par une interface sera alors propagée à tous le réseau, ou plus exactement à l'hôte qui possède l'adresse mac correspondant.
Avec la configuration par défaut, le bridge mis en place par xen s'apelle xenbr0. Le programme xend prend en charge l'ajout des interfaces à ce pont lorsqu'un domaine invité est chargé en mémoire, et il le retire quand nécessaire. Tout est donc géré automatiquement, à partir du moment où le fichier /etc/xen/xend-config.sxp a les bons paramètres.
Vous pouvez manipuler les ponts grâce à la commande brctl (bridge control). Ainsi la commande "brctl show" affichera la liste des ponts présents. Les options de brctl les plus utilisées sont "brctl addbr brname" pour créer un nouveau bridge, et "brctl addif brname ifname" pour connecter une interface réseau existante à un bridge". De même les options "delif" et "delbr" permettent de deconnecter une interface du bridge, et de supprimer un bridge.
[edit] Gestion des disques durs
Comme pour les autres ressources, l'accès des sytèmes invités aux disques durs (et autres supports de stockage comme les disquettes, CDRom, ...) est contrôlé par le système principal dom0. Le fichier de configuration d'un système invité devra définir les ressources auxquelles il aura accès.
[edit] accès exclusif aux partitions
Vous pourrez donc interdire l'accès à la plupart des partitions de votre disque pour des raisons de sécurité pour vos données, et parce qu'il est impossible de partager cette ressource. A aucun moment deux domaines ne devront accéder à la même partition ou au même disque, si l'un au moins des systèmes y accède en écriture. Cela aboutirait à des erreurs, et à une corruption du système de fichiers du disque. Il faut donc être très prudent dans la gestion de cette ressource, car rien ne vous protège contre l'exécution de deux systèmes avec des accès concurrents en écriture.
L'erreur classique consiste à monter la partition d'un système invité sur le domaine principal pour y copier un fichier manquant. Si vous démarrez le système invité qui est installé sur cette partition, avant d'avoir démonté la partiition sur l'autre domaine, vous pouvez être sur que le système de fichiers sera corrompu à l'arrivée.
Si vous avez besoin d'accéder aux fichiers d'une partition depuis plusieurs domaines, il est obligatoire de mettre en place une solution d'accès par le réseau, comme par exemple avec un serveur NFS (Network File System). Un domaine aura alors un accès exclusif à la partition, et tous les autres domaines devront passer par des clients NFS pour accéder aux fichiers. Vous pouvez aussi transférer un fichier assez facilement avec la commande scp, fournie avec ssh, mais ceci nécessite qu'un serveur ssh soit installé sur l'un des deux domaines.
[edit] deux types de supports
Il existe deux façons de fournir un accès à une partition à un système invité. Vous pouvez soit lui donner accès à une partition réelle du disque, en lecture (r) ou en lecture/écriture (w). Au passage, vous pouvez demander à xen de faire en sorte que l'invité voit le disque avec un autre nom. Dans l'exemple suivant, le système pensera accéder à sda1 alors qu'il s'agit en réalité de hda8:
disk = ['phy:hda8,sda1,w']
Voici un exemple dans lequel on donne accès à une partition en lecture, et l'autre en accès complet:
disk = ['phy:hda8,sda1,w', 'phy:hda5,sda2,r']
La seconde façon de fournir une ressource est de créer un fichier sur le domaine principal, et de le montrer comme étant une partition à l'invité:
disk = ['file:/mnt/images/gentoo.dd,sda1,w']
Cette seconde possibilité a l'avantage de ne pas nécessiter la création de nombreuses partitions sur le domaine principal, mais elle ralentit l'accès aux données. En effet, il y aura deux traitements bas niveau qui vont avoir lieu au lieu d'un seul. Par exemple, lorsque l'invité va demander l'écriture d'un fichier, le système de fichier du noyau du domaine invité va gérer les données, et cette demande va être transmise au système de fichiers du domaine principal lorsqu'il écrira dans le fichier image du disque. Deux traitements auront bien lieu, au lieu d'un habituellement, d'où un ralentissement.
