Software-soft emul-xen

De Lea Linux
Aller à la navigation Aller à la recherche

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.

  • 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) :

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

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

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 :

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

Récupérée de « https://lea-linux.org/docs/index.php?title=Software-soft_emul-xen&oldid=10957 »