Lea Linux - Contributions [fr]

Software-soft emul-xen

2008-08-21T07:13:48Z

Nantes geek : /* Commandes de démarrage et d'arrêt de systèmes virtualisés */

{{En construction}}
= 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 ».

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

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

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">
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 (à adapter)<br/>
root = "/dev/hda7 ro" #partition racine du système virtualisé (à adapter)<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 ==
===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 :
<div class="code">
/etc/rc.d/rc.xend start
</div>
2. Démarrer le système virtualisé avec la commande :
<div class="code">
xm create fichier_de_configuration -c # ( exemple : « xm create /tmp/invite.cfg -c » )
</div>
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) :
<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é===
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 :
<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 :

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 :
<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 »).

===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 » :
<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.

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 :
<div class="code">
startx
</div>

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é :
<div class="code">
vncpasswd
</div>

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 :
<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 » :

1. Editer le fichier « /usr/X11R6/share/fluxbox/menu » et ajouter la ligne suivante :
<div class="code">
[exec] (VNC pour 192.168.1.1)<br>
{vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1}
</div>
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é===
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 :
<div class="code">
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
</div>

===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 ») :
<div class="code">
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
</div>

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)

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

{{Copy|novembre 2005|[[Utilisateur:Frankendres|Frankendres]]|CC-BY-SA}}

Software-soft emul-xen

2008-08-21T07:11:59Z

Nantes geek : /* Commandes de démarrage et d'arrêt de systèmes virtualisés */

{{En construction}}
= 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 ».

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

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

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">
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 (à adapter)<br/>
root = "/dev/hda7 ro" #partition racine du système virtualisé (à adapter)<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 ==
===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 :
<div class="code">
/etc/rc.d/rc.xend start
</div>
2. Démarrer le système virtualisé avec la commande :
<div class="code">
xm create fichier_de_configuration -c # ( exemple : « xm create /tmp/invite.cfg -c » )
</div>
Attention : le système virtualisé s'approprie cette console ...

Pour sortir de la console : ctrl + altGr+]

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) :
<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é===
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 :
<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 :

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 :
<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 »).

===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 » :
<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.

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 :
<div class="code">
startx
</div>

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é :
<div class="code">
vncpasswd
</div>

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 :
<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 » :

1. Editer le fichier « /usr/X11R6/share/fluxbox/menu » et ajouter la ligne suivante :
<div class="code">
[exec] (VNC pour 192.168.1.1)<br>
{vncviewer -geometry 800x600 -passwd /root/.vnc/passwd 192.168.1.1:1}
</div>
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é===
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 :
<div class="code">
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
</div>

===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 ») :
<div class="code">
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
</div>

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)

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

{{Copy|novembre 2005|[[Utilisateur:Frankendres|Frankendres]]|CC-BY-SA}}