« Software-soft emul-xen » : différence entre les versions
mAucun résumé des modifications |
Aucun résumé des modifications |
||
(20 versions intermédiaires par 8 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
[[Category:Logiciels]] | |||
=== Introduction à la virtualisation | = Virtualisation avec Xen = | ||
par [[Utilisateur:Frankendres|Frankendres]] | |||
== Introduction à la virtualisation == | |||
La virtualisation de systèmes informatiques consiste à faire fonctionner sur une même machine (physique) plusieurs systèmes d'exploitation en même temps. | La virtualisation de systèmes informatiques consiste à faire fonctionner sur une même machine (physique) plusieurs systèmes d'exploitation en même temps. | ||
Concrètement, un système d'exploitation, dit « hôte », est installé sur la machine « physique » et émule une ou plusieurs machines « virtuelles » (avec processeur, mémoire, disque dur, carte réseau, BIOS, ...). Chaque machine virtuelle peut accueillir un système d'exploitation dit « virtualisé » (ou « invité »). Le système hôte assure le cloisonnement entre les systèmes virtualisés et le partage des ressources physiques : c'est un « superviseur ». | Concrètement, un système d'exploitation, dit « hôte », est installé sur la machine « physique » et émule une ou plusieurs machines « virtuelles » (avec processeur, mémoire, disque dur, carte réseau, BIOS, ...). Chaque machine virtuelle peut accueillir un système d'exploitation dit « virtualisé » (ou « invité »). Le système hôte assure le cloisonnement entre les systèmes virtualisés et le partage des ressources physiques : c'est un « superviseur ». | ||
Remarque : le système hôte et les systèmes invités peuvent être tous différents : il peut y avoir un superviseur Linux, un système invité Windows 2003 serveur et un autre système invité Mac OS X. | <cadre type=note>'''Remarque :''' le système hôte et les systèmes invités peuvent être tous différents : il peut y avoir un superviseur Linux, un système invité Windows 2003 serveur et un autre système invité Mac OS X.</cadre> | ||
Les systèmes virtualisés sont manipulables à souhait par le superviseur : démarrage, arrêt, gel, sauvegarde de contexte ... De plus, comme le disque dur d'un système virtualisé est généralement émulé par un fichier, il est facile de dupliquer un système virtualisé ou de le faire migrer d'un hôte à un autre. | Les systèmes virtualisés sont manipulables à souhait par le superviseur : démarrage, arrêt, gel, sauvegarde de contexte ... De plus, comme le disque dur d'un système virtualisé est généralement émulé par un fichier, il est facile de dupliquer un système virtualisé ou de le faire migrer d'un hôte à un autre. | ||
Ligne 15 : | Ligne 19 : | ||
Le principe de fonctionnement de Xen est différent : c'est un « paravirtualiseur » de machines virtuelles, c'est à dire que les systèmes invités ont « conscience » de sa présence (ils doivent d'ailleurs être modifiés pour fonctionner avec Xen). L'avantage de cette solution est que Xen n'a pas besoin d'émuler de machines virtuelles, d'où des performances remarquables. Par contre les systèmes propriétaires comme Windows ne peuvent être modifiés sans l'accord de leur éditeur. Ce problème est résolu avec l'avènement de processeurs intégrant le support matériel de la virtualisation (« Pacifia » pour AMD, « Virtualization Technology » pour Intel, ce qui permet de virtualiser des systèmes avec Xen sans avoir à les modifier. | Le principe de fonctionnement de Xen est différent : c'est un « paravirtualiseur » de machines virtuelles, c'est à dire que les systèmes invités ont « conscience » de sa présence (ils doivent d'ailleurs être modifiés pour fonctionner avec Xen). L'avantage de cette solution est que Xen n'a pas besoin d'émuler de machines virtuelles, d'où des performances remarquables. Par contre les systèmes propriétaires comme Windows ne peuvent être modifiés sans l'accord de leur éditeur. Ce problème est résolu avec l'avènement de processeurs intégrant le support matériel de la virtualisation (« Pacifia » pour AMD, « Virtualization Technology » pour Intel, ce qui permet de virtualiser des systèmes avec Xen sans avoir à les modifier. | ||
Remarque : bien qu'étant un logiciel libre, Xen bénéficie du soutien de partenaires industriels, acteurs majeurs de l'informatique. | <cadre type=note>'''Remarque :''' bien qu'étant un logiciel libre, Xen bénéficie du soutien de partenaires industriels, acteurs majeurs de l'informatique.</cadre> | ||
== Préparation de l'environnement de travail == | |||
Les instructions de cette documentation supposent que la mise en place de Xen s'effectue depuis une distribution '''Linux Slackware''', mais sont transposables à n'importe quelle distribution avec quelques adaptations. Pour information, les dernières versions testées des logiciels utilisés pour la mise en place de la solution de virtualisation sont : Slackware-10.2, xen-2.0.7, bridge-utils-1.0.6, tightvnc-1.2.9, twisted-2.1.0, twistedweb-0.5.0, et zopeinterface-2.0.1. | Les instructions de cette documentation supposent que la mise en place de Xen s'effectue depuis une distribution '''Linux Slackware''', mais sont transposables à n'importe quelle distribution avec quelques adaptations. Pour information, les dernières versions testées des logiciels utilisés pour la mise en place de la solution de virtualisation sont : Slackware-10.2, xen-2.0.7, bridge-utils-1.0.6, tightvnc-1.2.9, twisted-2.1.0, twistedweb-0.5.0, et zopeinterface-2.0.1. | ||
<ul> | <ul> | ||
<li>Le système servant à construire la solution de virtualisation doit disposer des outils de développement suivants :<br/>''' binutils, gcc, glibc kernel-headers, make, python, x11-devel'''.</li> | <li>Le système servant à construire la solution de virtualisation doit disposer des outils de développement suivants :<br/>''' binutils, gcc, glibc kernel-headers, make, python, x11-devel'''.</li> | ||
<li>Peut-être faudra t | <li>Peut-être faudra t-il ajouter ces autres outils de développement :<br/>'''autoconf, automake, bin86, bison, flex, gcc-g++, gettext-tools, libtool, m4, perl, pkgconfig'''.</li> | ||
<li>Il faudra également installer le gestionnaire d'amorce '''GRUB''' (LiLo ne permet pas de démarrer Xen).</li> | <li>Il faudra également installer le gestionnaire d'amorce '''GRUB''' (LiLo ne permet pas de démarrer Xen).</li> | ||
</ul> | </ul> | ||
Ligne 96 : | Ligne 99 : | ||
tar -zxvf $VERSION.tar.gz; cd $VERSION<br/> | tar -zxvf $VERSION.tar.gz; cd $VERSION<br/> | ||
./configure --prefix=/usr; make; make install DESTDIR=`pwd`/pack<br/> | ./configure --prefix=/usr; make; make install DESTDIR=`pwd`/pack<br/> | ||
cd pack; makepkg -l y -c y ../../$VERSION-i486- | cd pack; makepkg -l y -c y ../../$VERSION-i486-perso; cd ../..; rm -rf $VERSION | ||
export VERSION=`ls tightvnc* | sed s/_unixsrc.tar.gz//`<br/> | export VERSION=`ls tightvnc* | sed s/_unixsrc.tar.gz//`<br/> | ||
Ligne 122 : | Ligne 125 : | ||
</div> | </div> | ||
== Installation de l'hôte Xen == | |||
1. Formater la partition système en « ext3 » puis la monter (il faut une partition libre de 1 Go pour installer l'hôte Xen et un système virtualisé) : | 1. Formater la partition système en « ext3 » puis la monter (il faut une partition libre de 1 Go pour installer l'hôte Xen et un système virtualisé) : | ||
<div class="code"> | <div class="code"> | ||
Ligne 144 : | Ligne 146 : | ||
</div> | </div> | ||
4. Pour installer le noyau et les outils Xen, il faut extraire les fichiers de l'archive « xen-x.y.z-install-x86_32.tgz » dans le répertoire « /tmp » du système hôte, puis « basculer » (« chroot ») vers ce système pour exécuter le script d'installation. Attention, le programme d'installation prévoit d'installer les scripts de démarrage de Xen dans le répertoire « /etc/init.d » alors que Slackware utilise le répertoire « /etc/rc.d ». De même, Xen installe les « modules python » dans le répertoire « /usr/lib/python » alors que Slackware utilise « /usr/lib/python2.4 ». Des liens symboliques résolvent le « problème »: | 4. Télécharger la distribution compilée de Xen: http://www.xensource.com/xen/downloads/ | ||
5. Pour installer le noyau et les outils Xen, il faut extraire les fichiers de l'archive « xen-x.y.z-install-x86_32.tgz » dans le répertoire « /tmp » du système hôte, puis « basculer » (« chroot ») vers ce système pour exécuter le script d'installation. Attention, le programme d'installation prévoit d'installer les scripts de démarrage de Xen dans le répertoire « /etc/init.d » alors que Slackware utilise le répertoire « /etc/rc.d ». De même, Xen installe les « modules python » dans le répertoire « /usr/lib/python » alors que Slackware utilise « /usr/lib/python2.4 ». Des liens symboliques résolvent le « problème »: | |||
<div class="code"> | <div class="code"> | ||
pushd /point_de_montage_système_hôte/tmp; tar -zxvf /root/xen-*.tgz; popd | |||
chroot point_de_montage_partition_système_hôte<br/> | chroot point_de_montage_partition_système_hôte<br/> | ||
cd /etc; ln -s rc.d init.d<br/> | cd /etc; ln -s rc.d init.d<br/> | ||
Ligne 155 : | Ligne 161 : | ||
</div> | </div> | ||
6. Le système hôte est prêt. Il faut maintenant installer « Grub » si ce n'est pas déjà fait, puis le configurer en ajoutant les lignes suivantes au fichier « menu.lst » de « Grub » pour amorcer le système hôte : | |||
<div class="code"> | <div class="code"> | ||
title Xen 2.0 / XenLinux 2.6<br/> | title Xen 2.0 / XenLinux 2.6<br/> | ||
Ligne 163 : | Ligne 169 : | ||
</div> | </div> | ||
== Installation d'un système virtualisé == | |||
1. Créer un fichier (« /tmp/invite.img ») pour émuler le disque dur du système virtualisé dans la partition système de l'hôte, le formater, le monter puis y recopier les fichiers du système hôte : | 1. Créer un fichier (« /tmp/invite.img ») pour émuler le disque dur du système virtualisé dans la partition système de l'hôte, le formater, le monter puis y recopier les fichiers du système hôte : | ||
<div class="code"> | <div class="code"> | ||
Ligne 179 : | Ligne 184 : | ||
memory = 96 #Mo #mémoire allouée au système virtualisé<br/> | memory = 96 #Mo #mémoire allouée au système virtualisé<br/> | ||
name = "invite" #nom donné au système virtualisé<br/> | name = "invite" #nom donné au système virtualisé<br/> | ||
disk = [ 'file:/tmp/invite.img,hda7,w' ] #le système virtualisé verra le fichier /tmp/invite.img de l'hôte comme /dev/hda7<br/> | disk = [ 'file:/tmp/invite.img,hda7,w' ] #le système virtualisé verra le fichier /tmp/invite.img de l'hôte comme /dev/hda7 (à adapter)<br/> | ||
root = "/dev/hda7 ro" #partition racine du système virtualisé<br/> | root = "/dev/hda7 ro" #partition racine du système virtualisé (à adapter)<br/> | ||
</div> | </div> | ||
Remarque : si la partition système de l'hôte est « /dev/hda7 », alors le système virtualisé qui est un « clone » du système hôte à la même partition système. Il est possible de lui en définir une autre, à condition d'adapter son fichier « /etc/fstab », et de modifier le fichier de configuration précédent en conséquence. | Remarque : si la partition système de l'hôte est « /dev/hda7 », alors le système virtualisé qui est un « clone » du système hôte à la même partition système. Il est possible de lui en définir une autre, à condition d'adapter son fichier « /etc/fstab », et de modifier le fichier de configuration précédent en conséquence. | ||
== Mise en oeuvre de la virtualisation == | |||
===Commandes de démarrage et d'arrêt de systèmes virtualisés=== | |||
Commandes de démarrage et d'arrêt de systèmes virtualisés | |||
1. Démarrer le système hôte puis démarrer le service Xen : | 1. Démarrer le système hôte puis démarrer le service Xen : | ||
<div class="code"> | |||
/etc/rc.d/rc.xend start | |||
</div> | |||
2. Démarrer le système virtualisé avec la commande : | 2. Démarrer le système virtualisé avec la commande : | ||
<div class="code"> | |||
exemple : « xm create /tmp/invite.cfg -c » | xm create fichier_de_configuration -c # ( exemple : « xm create /tmp/invite.cfg -c » ) | ||
</div> | |||
Attention : le système virtualisé s'approprie cette console ... | Attention : le système virtualisé s'approprie cette console ... | ||
<cadre type=note> Remarque : Pour sortir de la console : ctrl + altGr+] </cadre> | |||
3. Sur une console de l'hôte, afficher la liste des systèmes actifs : | |||
<div class="code"> | |||
xm list | |||
</div> | |||
4. Pour arrêter le système virtualisé (depuis une console de l'hôte) : | 4. Pour arrêter le système virtualisé (depuis une console de l'hôte) : | ||
<div class="code"> | |||
xm shutdown nom_système_virtualisé # (« invite » par exemple). | |||
</div> | |||
Configuration du réseau entre l'hôte et le système virtualisé | ===Configuration du réseau entre l'hôte et le système virtualisé=== | ||
Rappel : lorsqu'aucun masque de réseau n'a été spécifié, la commande « ifconfig » attribue un masque « naturel » à l'interface (8 bits pour une adresse de classe A, 16 bits pour une adresse de classe B, ...). | Rappel : lorsqu'aucun masque de réseau n'a été spécifié, la commande « ifconfig » attribue un masque « naturel » à l'interface (8 bits pour une adresse de classe A, 16 bits pour une adresse de classe B, ...). | ||
Pour que l'hôte puisse communiquer avec le système virtualisé, il faut attribuer une adresse IP à l'interface « xen-br0 » de l'hôte et à l'interface « eth0 » du système virtualisé(ces deux adresses doivent être dans le même réseau). | |||
Exemple : | |||
Configuration du réseau entre le système virtualisé et d'autres machines | Sur une console de l'hôte : | ||
<div class="code"> | |||
ifconfig xen-br0 192.168.1.254 | |||
</div> | |||
Sur la console du système virtualisé : | |||
<div class="code"> | |||
ifconfig eth0 192.168.1.1 | |||
</div> | |||
Tester la communication entre l'hôte et le système virtualisé avec la commande « ping ». | |||
De puis l'hôte : | |||
<div class="code"> | |||
ping 192.168.1.1 # (« CTRL + C » pour arrêter). | |||
</div> | |||
===Configuration du réseau entre le système virtualisé et d'autres machines(1ère méthode)=== | |||
L'objectif suivant consiste à permettre au système virtualisé de communiquer avec une machine physique différente de l'hôte. Il faut pour cela : | L'objectif suivant consiste à permettre au système virtualisé de communiquer avec une machine physique différente de l'hôte. Il faut pour cela : | ||
Ligne 215 : | Ligne 243 : | ||
2.attribuer des adresses IP aux interfaces physiques des machines (dans le même réseau que celle de la machine virtuelle : « xen-br0 » est un pont, pas un routeur) : | 2.attribuer des adresses IP aux interfaces physiques des machines (dans le même réseau que celle de la machine virtuelle : « xen-br0 » est un pont, pas un routeur) : | ||
pour l'hôte : | |||
pour une « autre machine physique » : | pour l'hôte : | ||
<div class="code"> | |||
ifconfig eth0 192.168.1.101 | |||
</div> | |||
pour une « autre machine physique » : | |||
<div class="code"> | |||
ifconfig eth0 192.168.1.102 | |||
</div> | |||
3.tester la communication depuis une autre machine physique vers l'hôte puis vers le système virtualisé (« ping »). | 3.tester la communication depuis une autre machine physique vers l'hôte puis vers le système virtualisé (« ping »). | ||
Configuration du réseau entre le système virtualisé et d'autres machines | ===Configuration du réseau entre le système virtualisé et d'autres machines(2ème méthode)=== | ||
Une autre solution pour accéder à un système virtualisé depuis une autre machine physique est d'avoir un hôte transparent, c'est à dire sans adresse IP : | Une autre solution pour accéder à un système virtualisé depuis une autre machine physique est d'avoir un hôte transparent, c'est à dire sans adresse IP : | ||
1.L'hôte ne doit avoir ni adresses IP, ni routes. Pour supprimer l'adresse IP affectée à l'interface « xen-br0 » : | |||
1.L'hôte ne doit avoir ni adresses IP, ni routes. | |||
Pour supprimer l'adresse IP affectée à l'interface « xen-br0 » : | |||
<div class="code"> | |||
ifconfig xen-br0 0.0.0.0 | |||
</div> | |||
Vérifier ensuite que l'interface « eth0 » est en mode promiscuité. Si besoin : | |||
<div class="code"> | |||
ifconfig eth0 promisc up | |||
</div> | |||
2.Sur le système virtualisé, attribuer les adresses IP ainsi que les routes comme pour un système fonctionnant sur une machine physique. | 2.Sur le système virtualisé, attribuer les adresses IP ainsi que les routes comme pour un système fonctionnant sur une machine physique. | ||
Ligne 232 : | Ligne 277 : | ||
4.Pour que l'hôte puisse communiquer avec le système virtualisé (utilisation de VNC par exemple), il faut attribuer une adresse IP à l'interface « xen-br0 ». | 4.Pour que l'hôte puisse communiquer avec le système virtualisé (utilisation de VNC par exemple), il faut attribuer une adresse IP à l'interface « xen-br0 ». | ||
Prise de contrôle d'un système virtualisé par VNC | |||
===Prise de contrôle d'un système virtualisé par VNC=== | |||
1.configurer le réseau entre l'hôte et le système virtualisé (si ce n'est pas déjà fait), | 1.configurer le réseau entre l'hôte et le système virtualisé (si ce n'est pas déjà fait), | ||
2.démarrer l'interface graphique sur l'hôte : | 2.démarrer l'interface graphique sur l'hôte : | ||
<div class="code"> | |||
startx | |||
</div> | |||
3.sur le système virtualisé, démarrer le serveur VNC : | 3.sur le système virtualisé, démarrer le serveur VNC : | ||
<div class="code"> | |||
vncserver | |||
</div> | |||
4.sur l'hôte, enregistrer le mot de passe défini sur le système virtualisé : | 4.sur l'hôte, enregistrer le mot de passe défini sur le système virtualisé : | ||
<div class="code"> | |||
vncpasswd | |||
</div> | |||
5.sur l'hôte, prendre le contrôle du système virtualisé par VNC : | 5.sur l'hôte, prendre le contrôle du système virtualisé par VNC : | ||
<div class="code"> | |||
vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1 | |||
</div> | |||
===Améliorer l'interface=== | |||
Le gestionnaire de fenêtres utilisé par défaut par l'interface graphique et par VNC est « TWM ». Il sera avantageusement remplacé par « Fluxbox » qui, tout en n'utilisant qu'un minimum de ressources, est beaucoup plus convivial. | |||
Sur l'hôte, modifier le lien qui définit le gestionnaire de fenêtres à utiliser puis redémarrer l'interface graphique: | |||
<div class="code"> | |||
« cd /etc/X11/xinit; ln -sf xinitrc.fluxbox xinitrc » | |||
</div> | |||
Sur le système virtualisé : éditer le fichier « /root/.vnc/xstartup » et remplacer « twm » par « fluxbox », puis redémarrer le serveur VNC : | Sur le système virtualisé : éditer le fichier « /root/.vnc/xstartup » et remplacer « twm » par « fluxbox », puis redémarrer le serveur VNC : | ||
<div class="code"> | |||
vncserver -kill :1; vncserver | |||
</div> | |||
Sur l'hôte, pour prendre le contrôle d'un système virtualisé sans avoir à saisir de commande, il suffit d'ajouter une entrée dans le menu de « Fluxbox » : | Sur l'hôte, pour prendre le contrôle d'un système virtualisé sans avoir à saisir de commande, il suffit d'ajouter une entrée dans le menu de « Fluxbox » : | ||
1. Editer le fichier « /usr/X11R6/share/fluxbox/menu » et ajouter la ligne suivante : | 1. Editer le fichier « /usr/X11R6/share/fluxbox/menu » et ajouter la ligne suivante : | ||
[exec] (VNC pour 192.168.1.1) | <div class="code"> | ||
[exec] (VNC pour 192.168.1.1)<br> | |||
{vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1} | {vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1} | ||
</div> | |||
2. Pour appliquer les changements à l'administrateur, saisir la commande : | 2. Pour appliquer les changements à l'administrateur, saisir la commande : | ||
<div class="code"> | |||
cp /usr/X11R6/share/fluxbox/menu /root/.fluxbox/ | |||
</div> | |||
3. Redémarrer Fluxbox. | |||
Paramétrer le démarrage du système virtualisé | ===Paramétrer le démarrage du système virtualisé=== | ||
Pour ne pas avoir à reconfigurer le réseau ou à démarrer manuellement le serveur VNC à chaque démarrage du système virtualisé, effectuer les opérations suivantes (sur le système virtualisé) : | Pour ne pas avoir à reconfigurer le réseau ou à démarrer manuellement le serveur VNC à chaque démarrage du système virtualisé, effectuer les opérations suivantes (sur le système virtualisé) : | ||
1.éditer son fichier « /etc/rc.d/rc.inet1.conf » pour définir l'adresse IP et le masque, | 1.éditer son fichier « /etc/rc.d/rc.inet1.conf » pour définir l'adresse IP et le masque, | ||
2.pour démarrer le serveur VNC automatiquement, éditer le fichier « /etc/rc.d/rc.local » du système virtualisé et ajouter : | 2.pour démarrer le serveur VNC automatiquement, éditer le fichier « /etc/rc.d/rc.local » du système virtualisé et ajouter : | ||
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11/bin | <div class="code"> | ||
declare -x USER="/root" #le serveur VNC est pour l'administrateur | export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11/bin | ||
declare -x HOME="/root" | declare -x USER="/root" #le serveur VNC est pour l'administrateur | ||
vncserver | declare -x HOME="/root" | ||
vncserver | |||
</div> | |||
===Autres commandes utiles de gestion des systèmes virtualisés (depuis l'hôte)=== | |||
Autres commandes utiles de gestion des systèmes virtualisés (depuis l'hôte) | |||
Sauvegarder le contexte, suspendre, relancer, et restaurer le contexte d'un système virtualisé (le nom du système virtualisé est celui défini dans le fichier de configuration ou affiché par la commande « xm list ») : | Sauvegarder le contexte, suspendre, relancer, et restaurer le contexte d'un système virtualisé (le nom du système virtualisé est celui défini dans le fichier de configuration ou affiché par la commande « xm list ») : | ||
xm save nom_système_virtualisé fichier_sauvegarde_du_contexte | <div class="code"> | ||
xm pause nom_système_virtualisé | xm save nom_système_virtualisé fichier_sauvegarde_du_contexte | ||
xm unpause nom_système_virtualisé | xm pause nom_système_virtualisé | ||
xm restore fichier_sauvegarde_du_contexte | xm unpause nom_système_virtualisé | ||
xm restore fichier_sauvegarde_du_contexte | |||
</div> | |||
Migrer un système virtualisé vers un autre hôte sans interruption de service : | Migrer un système virtualisé vers un autre hôte sans interruption de service : | ||
<div class="code"> | |||
xm migrate --live nom_système_virtualisé hôte_destination | |||
</div> | |||
(« hôte_destination » peut être une adresse IP ou un nom de machine) | (« hôte_destination » peut être une adresse IP ou un nom de machine) | ||
Modifier la quantité de mémoire allouée à un système virtualisé : | Modifier la quantité de mémoire allouée à un système virtualisé : | ||
<div class="code"> | |||
xm mem-set nom_système_virtualisé quantité_à_allouer_en_Mo | |||
</div> | |||
Obtenir l'aide en ligne : | Obtenir l'aide en ligne : | ||
<div class="code"> | |||
xm help | |||
</div> | |||
Pour partager le temps processeur entre les différents systèmes virtualisés, rechercher de la documentation sur « xm atropos » et « xm bvt ». | Pour partager le temps processeur entre les différents systèmes virtualisés, rechercher de la documentation sur « xm atropos » et « xm bvt ». | ||
<br/> | |||
<br/> | |||
'''<b>[[Admin-index|@ Retour à la rubrique Administration système]]</b>'' | |||
<br/> | |||
{{Copy|2005,2006|[[Utilisateur:Frankendres|Frankendres]]|CC-BY-SA}} |
Dernière version du 22 juillet 2016 à 15:47
Virtualisation avec Xen
par Frankendres
Introduction à la virtualisation
La virtualisation de systèmes informatiques consiste à faire fonctionner sur une même machine (physique) plusieurs systèmes d'exploitation en même temps. Concrètement, un système d'exploitation, dit « hôte », est installé sur la machine « physique » et émule une ou plusieurs machines « virtuelles » (avec processeur, mémoire, disque dur, carte réseau, BIOS, ...). Chaque machine virtuelle peut accueillir un système d'exploitation dit « virtualisé » (ou « invité »). Le système hôte assure le cloisonnement entre les systèmes virtualisés et le partage des ressources physiques : c'est un « superviseur ».
<cadre type=note>Remarque : le système hôte et les systèmes invités peuvent être tous différents : il peut y avoir un superviseur Linux, un système invité Windows 2003 serveur et un autre système invité Mac OS X.</cadre>
Les systèmes virtualisés sont manipulables à souhait par le superviseur : démarrage, arrêt, gel, sauvegarde de contexte ... De plus, comme le disque dur d'un système virtualisé est généralement émulé par un fichier, il est facile de dupliquer un système virtualisé ou de le faire migrer d'un hôte à un autre. La virtualisation permet donc d'utiliser de manière optimale les ressources d'une machine : on peut ajouter des machines virtuelles si la machine physique est sous-exploitée (économie d'argent par mutualisation des ressources) ou en supprimer si elle est saturée (gestion de la montée en charge). Enfin la virtualisation permet une répartition des services sur plusieurs machines virtuelles et par là même une meilleure sécurité : si un système est compromis, les autres peuvent continuer à fonctionner normalement.
Les logiciels de virtualisation sont nombreux (Qemu, Bochs, VmWare, ...). La plupart d'entre eux émulent des machines virtuelles complètes : les systèmes invités n'ont pas conscience de fonctionner sur du matériel virtuel. Par contre, l'émulation de la machine virtuelle induit une surcharge qui grève les performances des systèmes virtualisés.
Le principe de fonctionnement de Xen est différent : c'est un « paravirtualiseur » de machines virtuelles, c'est à dire que les systèmes invités ont « conscience » de sa présence (ils doivent d'ailleurs être modifiés pour fonctionner avec Xen). L'avantage de cette solution est que Xen n'a pas besoin d'émuler de machines virtuelles, d'où des performances remarquables. Par contre les systèmes propriétaires comme Windows ne peuvent être modifiés sans l'accord de leur éditeur. Ce problème est résolu avec l'avènement de processeurs intégrant le support matériel de la virtualisation (« Pacifia » pour AMD, « Virtualization Technology » pour Intel, ce qui permet de virtualiser des systèmes avec Xen sans avoir à les modifier.
<cadre type=note>Remarque : bien qu'étant un logiciel libre, Xen bénéficie du soutien de partenaires industriels, acteurs majeurs de l'informatique.</cadre>
Préparation de l'environnement de travail
Les instructions de cette documentation supposent que la mise en place de Xen s'effectue depuis une distribution Linux Slackware, mais sont transposables à n'importe quelle distribution avec quelques adaptations. Pour information, les dernières versions testées des logiciels utilisés pour la mise en place de la solution de virtualisation sont : Slackware-10.2, xen-2.0.7, bridge-utils-1.0.6, tightvnc-1.2.9, twisted-2.1.0, twistedweb-0.5.0, et zopeinterface-2.0.1.
- Le système servant à construire la solution de virtualisation doit disposer des outils de développement suivants :
binutils, gcc, glibc kernel-headers, make, python, x11-devel. - Peut-être faudra t-il ajouter ces autres outils de développement :
autoconf, automake, bin86, bison, flex, gcc-g++, gettext-tools, libtool, m4, perl, pkgconfig. - Il faudra également installer le gestionnaire d'amorce GRUB (LiLo ne permet pas de démarrer Xen).
Récupérer les paquetages Slackware suivants et les placer dans le répertoire /root/ressources-xen (par exemple) :
aaa_base-10.2.0-noarch-2.tgz
aaa_elflibs-10.2.0-i486-3.tgz
bash-3.0-i486-3.tgz
bin-10.2-i486-1.tgz
bzip2-1.0.3-i486-1.tgz
coreutils-5.2.1-i486-1.tgz
curl-7.12.2-i486-1.tgz
cxxlibs-5.0.7-i486-1.tgz
dcron-2.3.3-i486-5.tgz
devs-2.3.1-noarch-22.tgz
e2fsprogs-1.38-i486-2.tgz
elvis-2.2_0-i486-2.tgz
etc-5.1-noarch-10.tgz
findutils-4.1.7-i386-1.tgz
fluxbox-0.9.13-i486-1.tgz
gawk-3.1.5-i486-1.tgz
gettext-0.14.3-i486-1.tgz
glibc-solibs-2.3.5-i486-5.tgz
glibc-zoneinfo-2.3.5-noarch-5.tgz
grep-2.5-i386-2.tgz
groff-1.19.1-i486-3.tgz
gzip-1.3.3-i386-2.tgz
hotplug-2004_09_23-noarch-5.tgz
infozip-5.52-i486-1.tgz
iproute2-2.6.11_050330-i486-2.tgz
iptables-1.3.3-i486-1.tgz
kbd-1.12-i486-2.tgz
less-382-i486-1.tgz
libidn-0.5.17-i486-1.tgz
man-1.5p-i486-1.tgz
mkinitrd-1.0.1-i486-3.tgz
module-init-tools-3.1-i486-1.tgz
mozilla-firefox-1.0.6-i686-2.tgz
openssl-solibs-0.9.7g-i486-1.tgz
pciutils-2.1.11-i486-6.tgz
perl-5.8.7-i486-1.tgz
pkgtools-10.2.0-i486-5.tgz
procps-3.2.5-i486-1.tgz
python-2.4.1-i486-1.tgz
sed-4.0.9-i486-2.tgz
shadow-4.0.3-i486-11.tgz
sysklogd-1.4.1-i486-9.tgz
sysvinit-2.84-i486-56.tgz
tar-1.15.1-i486-1.tgz
tcpip-0.17-i486-35.tgz
traceroute-1.4a12-i386-2.tgz
udev-064-i486-2.tgz
usbutils-0.11-i486-3.tgz
utempter-1.1.3-i486-1.tgz
util-linux-2.12p-i486-2.tgz
x11-6.8.2-i486-3.tgz
x11-fonts-misc-6.8.2-noarch-3.tgz
Récupérer les sources des programmes suivants (ils ne font pas partie des paquetages de la distribution) :
- zopeinterface: http://www.zope.org/Products/ZopeInterface
- twisted et twistedweb: http://twistedmatrix.com/
- tightvnc: http://www.tightvnc.com/
- bridge-utils: http://bridge.sourceforge.net/
Construire des paquetages pour ces programmes, puis ranger les paquetages dans /root/ressources-xen :
export VERSION=`ls bridge-utils* | sed s/.tar.gz//`
tar -zxvf $VERSION.tar.gz; cd $VERSION
./configure --prefix=/usr; make; make install DESTDIR=`pwd`/pack
cd pack; makepkg -l y -c y ../../$VERSION-i486-perso; cd ../..; rm -rf $VERSION
export VERSION=`ls tightvnc* | sed s/_unixsrc.tar.gz//`
tar -zxvf $VERSION\_unixsrc.tar.gz; cd vnc_unixsrc
PATH=$PATH:/usr/X11/bin; xmkmf; make World
cd Xvnc; ./configure --prefix=/usr; make; cd ..
mkdir -p pack/usr/{bin,man/man1}
./vncinstall `pwd`/pack/usr/bin `pwd`/pack/usr/man
cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf vnc_unixsrc
export VERSION=`ls Twisted-* | sed s/.tar.bz2//`
tar -jxvf $VERSION.tar.bz2; cd $VERSION; mkdir pack
python setup.py build; python setup.py install --root `pwd`/pack
cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
export VERSION=`ls TwistedWeb* | sed s/.tar.bz2//`
tar -jxvf $VERSION.tar.bz2; cd $VERSION; mkdir pack
python setup.py build; python setup.py install --root `pwd`/pack
cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
export VERSION=`ls ZopeInterface* | sed s/.tgz//`
tar -zxvf $VERSION.tgz; cd $VERSION; mkdir pack
python setup.py build; python setup.py install --root `pwd`/pack
cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
Installation de l'hôte Xen
1. Formater la partition système en « ext3 » puis la monter (il faut une partition libre de 1 Go pour installer l'hôte Xen et un système virtualisé) :
mke2fs -j partition_système_hôte #exemple: mke2fs -j /dev/hda7
mount partition_système_hôte point_de_montage_système_hôte #exemple: mount /dev/hda7 /mnt/partitions/hda7
2. Installer dans la partition système de l'hôte (option « -root » de « installpkg ») les paquetages qui lui sont nécessaires :
cd /root/ressources-xen/
for p in *.tgz; do installpkg -root point_de_montage_système_hôte $p; done
ldconfig -r point_de_montage_système_hôte
3. Créer le fichier « /etc/fstab » du système hôte (« vi /point_de_montage_système_hôte/etc/fstab ») :
partition_système / ext3 defaults 1 1 #/dev/hda7 pour l'exemple
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
4. Télécharger la distribution compilée de Xen: http://www.xensource.com/xen/downloads/
5. Pour installer le noyau et les outils Xen, il faut extraire les fichiers de l'archive « xen-x.y.z-install-x86_32.tgz » dans le répertoire « /tmp » du système hôte, puis « basculer » (« chroot ») vers ce système pour exécuter le script d'installation. Attention, le programme d'installation prévoit d'installer les scripts de démarrage de Xen dans le répertoire « /etc/init.d » alors que Slackware utilise le répertoire « /etc/rc.d ». De même, Xen installe les « modules python » dans le répertoire « /usr/lib/python » alors que Slackware utilise « /usr/lib/python2.4 ». Des liens symboliques résolvent le « problème »:
pushd /point_de_montage_système_hôte/tmp; tar -zxvf /root/xen-*.tgz; popd
chroot point_de_montage_partition_système_hôte
cd /etc; ln -s rc.d init.d
cd /usr/lib; ln -s python2.4 python
cd /tmp/xen-x.y-install; ./install.sh
cd /etc/rc.d; mv xend rc.xend #pour s'adapter aux conventions
rm -f /etc/init.d #de la distribution Linux Slackware
exit
6. Le système hôte est prêt. Il faut maintenant installer « Grub » si ce n'est pas déjà fait, puis le configurer en ajoutant les lignes suivantes au fichier « menu.lst » de « Grub » pour amorcer le système hôte :
title Xen 2.0 / XenLinux 2.6
root (hd0,6) #pour un hôte installé sur /dev/?da7
kernel /boot/xen-2.0.gz dom0_mem=98304 #96 Mo de RAM alloués à l'hôte
module /boot/vmlinuz-2.6-xen0 root=/dev/hda7 ro
Installation d'un système virtualisé
1. Créer un fichier (« /tmp/invite.img ») pour émuler le disque dur du système virtualisé dans la partition système de l'hôte, le formater, le monter puis y recopier les fichiers du système hôte :
dd if=/dev/zero of=/point_de_montage_système_hôte/tmp/invite.img bs=1024k count=500
mke2fs -j /point_de_montage_système_hôte/tmp/invite.img
mount -o loop /point_de_montage_système_hôte/tmp/invite.img /mnt/tmp
cp -dpR /point_de_montage_système_hôte/* /mnt/tmp/
umount /mnt/tmp #l'installation du système virtualisé est terminée
2. Éditer le fichier de configuration (« point_de_montage_système_hôte/tmp/invite.cfg » par exemple) pour permettre à Xen de démarrer ce système virtualisé. Exemple :
kernel = "/boot/vmlinuz-2.6-xenU" #noyau pour un système virtualisé
memory = 96 #Mo #mémoire allouée au système virtualisé
name = "invite" #nom donné au système virtualisé
disk = [ 'file:/tmp/invite.img,hda7,w' ] #le système virtualisé verra le fichier /tmp/invite.img de l'hôte comme /dev/hda7 (à adapter)
root = "/dev/hda7 ro" #partition racine du système virtualisé (à adapter)
Remarque : si la partition système de l'hôte est « /dev/hda7 », alors le système virtualisé qui est un « clone » du système hôte à la même partition système. Il est possible de lui en définir une autre, à condition d'adapter son fichier « /etc/fstab », et de modifier le fichier de configuration précédent en conséquence.
Mise en oeuvre de la virtualisation
Commandes de démarrage et d'arrêt de systèmes virtualisés
1. Démarrer le système hôte puis démarrer le service Xen :
/etc/rc.d/rc.xend start
2. Démarrer le système virtualisé avec la commande :
xm create fichier_de_configuration -c # ( exemple : « xm create /tmp/invite.cfg -c » )
Attention : le système virtualisé s'approprie cette console ...
<cadre type=note> Remarque : Pour sortir de la console : ctrl + altGr+] </cadre>
3. Sur une console de l'hôte, afficher la liste des systèmes actifs :
xm list
4. Pour arrêter le système virtualisé (depuis une console de l'hôte) :
xm shutdown nom_système_virtualisé # (« invite » par exemple).
Configuration du réseau entre l'hôte et le système virtualisé
Rappel : lorsqu'aucun masque de réseau n'a été spécifié, la commande « ifconfig » attribue un masque « naturel » à l'interface (8 bits pour une adresse de classe A, 16 bits pour une adresse de classe B, ...).
Pour que l'hôte puisse communiquer avec le système virtualisé, il faut attribuer une adresse IP à l'interface « xen-br0 » de l'hôte et à l'interface « eth0 » du système virtualisé(ces deux adresses doivent être dans le même réseau).
Exemple :
Sur une console de l'hôte :
ifconfig xen-br0 192.168.1.254
Sur la console du système virtualisé :
ifconfig eth0 192.168.1.1
Tester la communication entre l'hôte et le système virtualisé avec la commande « ping ».
De puis l'hôte :
ping 192.168.1.1 # (« CTRL + C » pour arrêter).
Configuration du réseau entre le système virtualisé et d'autres machines(1ère méthode)
L'objectif suivant consiste à permettre au système virtualisé de communiquer avec une machine physique différente de l'hôte. Il faut pour cela :
1.configurer le réseau entre l'hôte et le système virtualisé (si ce n'est pas déjà fait),
2.attribuer des adresses IP aux interfaces physiques des machines (dans le même réseau que celle de la machine virtuelle : « xen-br0 » est un pont, pas un routeur) :
pour l'hôte :
ifconfig eth0 192.168.1.101
pour une « autre machine physique » :
ifconfig eth0 192.168.1.102
3.tester la communication depuis une autre machine physique vers l'hôte puis vers le système virtualisé (« ping »).
Configuration du réseau entre le système virtualisé et d'autres machines(2ème méthode)
Une autre solution pour accéder à un système virtualisé depuis une autre machine physique est d'avoir un hôte transparent, c'est à dire sans adresse IP :
1.L'hôte ne doit avoir ni adresses IP, ni routes.
Pour supprimer l'adresse IP affectée à l'interface « xen-br0 » :
ifconfig xen-br0 0.0.0.0
Vérifier ensuite que l'interface « eth0 » est en mode promiscuité. Si besoin :
ifconfig eth0 promisc up
2.Sur le système virtualisé, attribuer les adresses IP ainsi que les routes comme pour un système fonctionnant sur une machine physique.
3.Tester la communication depuis une autre machine physique vers le système virtualisé. Remarque : l'hôte n'est plus joignable.
4.Pour que l'hôte puisse communiquer avec le système virtualisé (utilisation de VNC par exemple), il faut attribuer une adresse IP à l'interface « xen-br0 ».
Prise de contrôle d'un système virtualisé par VNC
1.configurer le réseau entre l'hôte et le système virtualisé (si ce n'est pas déjà fait),
2.démarrer l'interface graphique sur l'hôte :
startx
3.sur le système virtualisé, démarrer le serveur VNC :
vncserver
4.sur l'hôte, enregistrer le mot de passe défini sur le système virtualisé :
vncpasswd
5.sur l'hôte, prendre le contrôle du système virtualisé par VNC :
vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1
Améliorer l'interface
Le gestionnaire de fenêtres utilisé par défaut par l'interface graphique et par VNC est « TWM ». Il sera avantageusement remplacé par « Fluxbox » qui, tout en n'utilisant qu'un minimum de ressources, est beaucoup plus convivial.
Sur l'hôte, modifier le lien qui définit le gestionnaire de fenêtres à utiliser puis redémarrer l'interface graphique:
« cd /etc/X11/xinit; ln -sf xinitrc.fluxbox xinitrc »
Sur le système virtualisé : éditer le fichier « /root/.vnc/xstartup » et remplacer « twm » par « fluxbox », puis redémarrer le serveur VNC :
vncserver -kill :1; vncserver
Sur l'hôte, pour prendre le contrôle d'un système virtualisé sans avoir à saisir de commande, il suffit d'ajouter une entrée dans le menu de « Fluxbox » :
1. Editer le fichier « /usr/X11R6/share/fluxbox/menu » et ajouter la ligne suivante :
[exec] (VNC pour 192.168.1.1)
{vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1}
2. Pour appliquer les changements à l'administrateur, saisir la commande :
cp /usr/X11R6/share/fluxbox/menu /root/.fluxbox/
3. Redémarrer Fluxbox.
Paramétrer le démarrage du système virtualisé
Pour ne pas avoir à reconfigurer le réseau ou à démarrer manuellement le serveur VNC à chaque démarrage du système virtualisé, effectuer les opérations suivantes (sur le système virtualisé) :
1.éditer son fichier « /etc/rc.d/rc.inet1.conf » pour définir l'adresse IP et le masque,
2.pour démarrer le serveur VNC automatiquement, éditer le fichier « /etc/rc.d/rc.local » du système virtualisé et ajouter :
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11/bin declare -x USER="/root" #le serveur VNC est pour l'administrateur declare -x HOME="/root" vncserver
Autres commandes utiles de gestion des systèmes virtualisés (depuis l'hôte)
Sauvegarder le contexte, suspendre, relancer, et restaurer le contexte d'un système virtualisé (le nom du système virtualisé est celui défini dans le fichier de configuration ou affiché par la commande « xm list ») :
xm save nom_système_virtualisé fichier_sauvegarde_du_contexte xm pause nom_système_virtualisé xm unpause nom_système_virtualisé xm restore fichier_sauvegarde_du_contexte
Migrer un système virtualisé vers un autre hôte sans interruption de service :
xm migrate --live nom_système_virtualisé hôte_destination
(« hôte_destination » peut être une adresse IP ou un nom de machine)
Modifier la quantité de mémoire allouée à un système virtualisé :
xm mem-set nom_système_virtualisé quantité_à_allouer_en_Mo
Obtenir l'aide en ligne :
xm help
Pour partager le temps processeur entre les différents systèmes virtualisés, rechercher de la documentation sur « xm atropos » et « xm bvt ».
'@ Retour à la rubrique Administration système
Copyright
© 2005,2006 Frankendres
Ce document est publié sous licence Creative Commons Attribution, Partage à l'identique 4.0 : https://creativecommons.org/licenses/by-sa/4.0/ |