|
|
| Ligne 37 : |
Ligne 37 : |
|
| |
|
| == Rubrique : Léavancé == | | == Rubrique : Léavancé == |
| [[Virtualisation avec Xen]] | | * [[Virtualisation avec Xen]] : mise en oeuvre d'une solution de virtualisation avec Xen |
| | |
| == Virtualisation avec Xen ==
| |
| | |
| === 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 ».
| |
| | |
| 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.
| |
| | |
| 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.
| |
| | |
| Remarque : bien qu'étant un logiciel libre, Xen bénéficie du soutien de partenaires industriels, acteurs majeurs de l'informatique.
| |
| | |
| | |
| === 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.
| |
| | |
| <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>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>
| |
| </ul>
| |
| | |
| Récupérer les paquetages Slackware suivants et les placer dans le répertoire /root/ressources-xen (par exemple) :
| |
| <div class="code">
| |
| aaa_base-10.2.0-noarch-2.tgz<br/>
| |
| aaa_elflibs-10.2.0-i486-3.tgz<br/>
| |
| bash-3.0-i486-3.tgz<br/>
| |
| bin-10.2-i486-1.tgz<br/>
| |
| bzip2-1.0.3-i486-1.tgz<br/>
| |
| coreutils-5.2.1-i486-1.tgz<br/>
| |
| curl-7.12.2-i486-1.tgz<br/>
| |
| cxxlibs-5.0.7-i486-1.tgz<br/>
| |
| dcron-2.3.3-i486-5.tgz<br/>
| |
| devs-2.3.1-noarch-22.tgz<br/>
| |
| e2fsprogs-1.38-i486-2.tgz<br/>
| |
| elvis-2.2_0-i486-2.tgz<br/>
| |
| etc-5.1-noarch-10.tgz<br/>
| |
| findutils-4.1.7-i386-1.tgz<br/>
| |
| fluxbox-0.9.13-i486-1.tgz<br/>
| |
| gawk-3.1.5-i486-1.tgz<br/>
| |
| gettext-0.14.3-i486-1.tgz<br/>
| |
| glibc-solibs-2.3.5-i486-5.tgz<br/>
| |
| glibc-zoneinfo-2.3.5-noarch-5.tgz<br/>
| |
| grep-2.5-i386-2.tgz<br/>
| |
| groff-1.19.1-i486-3.tgz<br/>
| |
| gzip-1.3.3-i386-2.tgz<br/>
| |
| hotplug-2004_09_23-noarch-5.tgz<br/>
| |
| infozip-5.52-i486-1.tgz<br/>
| |
| iproute2-2.6.11_050330-i486-2.tgz<br/>
| |
| iptables-1.3.3-i486-1.tgz<br/>
| |
| kbd-1.12-i486-2.tgz<br/>
| |
| less-382-i486-1.tgz<br/>
| |
| libidn-0.5.17-i486-1.tgz<br/>
| |
| man-1.5p-i486-1.tgz<br/>
| |
| mkinitrd-1.0.1-i486-3.tgz<br/>
| |
| module-init-tools-3.1-i486-1.tgz<br/>
| |
| mozilla-firefox-1.0.6-i686-2.tgz<br/>
| |
| openssl-solibs-0.9.7g-i486-1.tgz<br/>
| |
| pciutils-2.1.11-i486-6.tgz<br/>
| |
| perl-5.8.7-i486-1.tgz<br/>
| |
| pkgtools-10.2.0-i486-5.tgz<br/>
| |
| procps-3.2.5-i486-1.tgz<br/>
| |
| python-2.4.1-i486-1.tgz<br/>
| |
| sed-4.0.9-i486-2.tgz<br/>
| |
| shadow-4.0.3-i486-11.tgz<br/>
| |
| sysklogd-1.4.1-i486-9.tgz<br/>
| |
| sysvinit-2.84-i486-56.tgz<br/>
| |
| tar-1.15.1-i486-1.tgz<br/>
| |
| tcpip-0.17-i486-35.tgz<br/>
| |
| traceroute-1.4a12-i386-2.tgz<br/>
| |
| udev-064-i486-2.tgz<br/>
| |
| usbutils-0.11-i486-3.tgz<br/>
| |
| utempter-1.1.3-i486-1.tgz<br/>
| |
| util-linux-2.12p-i486-2.tgz<br/>
| |
| x11-6.8.2-i486-3.tgz<br/>
| |
| x11-fonts-misc-6.8.2-noarch-3.tgz<br/>
| |
| </div>
| |
| | |
| | |
| Récupérer les sources des programmes suivants (ils ne font pas partie des paquetages de la distribution) :<ul>
| |
| <li>zopeinterface: http://www.zope.org/Products/ZopeInterface</li>
| |
| <li>twisted et twistedweb: http://twistedmatrix.com/</li>
| |
| <li>tightvnc: http://www.tightvnc.com/</li>
| |
| <li>bridge-utils: http://bridge.sourceforge.net/</li>
| |
| </ul>
| |
| | |
| Construire des paquetages pour ces programmes, puis ranger les paquetages dans /root/ressources-xen :
| |
| <div class="code">
| |
| export VERSION=`ls bridge-utils* | sed s/.tar.gz//`<br/>
| |
| tar -zxvf $VERSION.tar.gz; cd $VERSION<br/>
| |
| ./configure --prefix=/usr; make; make install DESTDIR=`pwd`/pack<br/>
| |
| cd pack; makepkg -l y -c y ../../$VERSION-i486-frk.perso; cd ../..; rm -rf $VERSION
| |
| | |
| export VERSION=`ls tightvnc* | sed s/_unixsrc.tar.gz//`<br/>
| |
| tar -zxvf $VERSION\_unixsrc.tar.gz; cd vnc_unixsrc<br/>
| |
| PATH=$PATH:/usr/X11/bin; xmkmf; make World<br/>
| |
| cd Xvnc; ./configure --prefix=/usr; make; cd ..<br/>
| |
| mkdir -p pack/usr/{bin,man/man1}<br/>
| |
| ./vncinstall `pwd`/pack/usr/bin `pwd`/pack/usr/man<br/>
| |
| cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf vnc_unixsrc
| |
| | |
| export VERSION=`ls Twisted-* | sed s/.tar.bz2//`<br/>
| |
| tar -jxvf $VERSION.tar.bz2; cd $VERSION; mkdir pack<br/>
| |
| python setup.py build; python setup.py install --root `pwd`/pack<br/>
| |
| cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
| |
| | |
| export VERSION=`ls TwistedWeb* | sed s/.tar.bz2//`<br/>
| |
| tar -jxvf $VERSION.tar.bz2; cd $VERSION; mkdir pack<br/>
| |
| python setup.py build; python setup.py install --root `pwd`/pack<br/>
| |
| cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
| |
| | |
| export VERSION=`ls ZopeInterface* | sed s/.tgz//`<br/>
| |
| tar -zxvf $VERSION.tgz; cd $VERSION; mkdir pack<br/>
| |
| python setup.py build; python setup.py install --root `pwd`/pack<br/>
| |
| cd pack; makepkg -l y -c y ../../$VERSION-i486-perso.tgz; cd ../..; rm -rf $VERSION
| |
| </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é) :
| |
| <div class="code">
| |
| mke2fs -j partition_système_hôte #exemple: mke2fs -j /dev/hda7<br/>
| |
| mount partition_système_hôte point_de_montage_système_hôte #exemple: mount /dev/hda7 /mnt/partitions/hda7
| |
| </div>
| |
| | |
| 2. Installer dans la partition système de l'hôte (option « -root » de « installpkg ») les paquetages qui lui sont nécessaires :
| |
| <div class="code">
| |
| cd /root/ressources-xen/<br/>
| |
| for p in *.tgz; do installpkg -root point_de_montage_système_hôte $p; done<br/>
| |
| ldconfig -r point_de_montage_système_hôte
| |
| </div>
| |
| | |
| 3. Créer le fichier « /etc/fstab » du système hôte (« vi /point_de_montage_système_hôte/etc/fstab ») :
| |
| <div class="code">
| |
| partition_système / ext3 defaults 1 1 #/dev/hda7 pour l'exemple<br/>
| |
| none /proc proc defaults 0 0<br/>
| |
| none /sys sysfs defaults 0 0<br/>
| |
| </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 »:
| |
| <div class="code">
| |
| chroot point_de_montage_partition_système_hôte<br/>
| |
| cd /etc; ln -s rc.d init.d<br/>
| |
| cd /usr/lib; ln -s python2.4 python<br/>
| |
| cd /tmp/xen-x.y-install; ./install.sh<br/>
| |
| cd /etc/rc.d; mv xend rc.xend #pour s'adapter aux conventions<br/>
| |
| rm -f /etc/init.d #de la distribution Linux Slackware<br/>
| |
| exit<br/>
| |
| </div>
| |
| | |
| 5. 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">
| |
| title Xen 2.0 / XenLinux 2.6<br/>
| |
| root (hd0,6) #pour un hôte installé sur /dev/?da7<br/>
| |
| kernel /boot/xen-2.0.gz dom0_mem=98304 #96 Mo de RAM alloués à l'hôte<br/>
| |
| module /boot/vmlinuz-2.6-xen0 root=/dev/hda7 ro<br/>
| |
| </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 :
| |
| <div class="code">
| |
| dd if=/dev/zero of=/point_de_montage_système_hôte/tmp/invite.img bs=1024k count=500<br/>
| |
| mke2fs -j /point_de_montage_système_hôte/tmp/invite.img<br/>
| |
| mount -o loop /point_de_montage_système_hôte/tmp/invite.img /mnt/tmp<br/>
| |
| cp -dpR /point_de_montage_système_hôte/* /mnt/tmp/<br/>
| |
| umount /mnt/tmp #l'installation du système virtualisé est terminée
| |
| </div>
| |
| | |
| 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 :
| |
| <div class="code">
| |
| kernel = "/boot/vmlinuz-2.6-xenU" #noyau pour un 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/>
| |
| 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/>
| |
| root = "/dev/hda7 ro" #partition racine du système virtualisé<br/>
| |
| </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.
| |
| | |
| | |
| === Mise en oeuvre de la virtualisation (mise en page à effectuer) ===
| |
| 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 ...
| |
| | |
| 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
| |
| 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
| |
| 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 (« cd /etc/X11/xinit; ln -sf xinitrc.fluxbox xinitrc ») puis redémarrer l'interface graphique.
| |
| 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/ » puis 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 set-mem 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 ».
| |