Qu'est-ce que Xen?

 

Selon wikipedia, Xen est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle.

Basiquement, xen est un logiciel qui permet l'execution de plusieurs systèmes d'exploitation en simultané sur une machine...

 

Comme VmWare ou Qemu c'est ça?

Oui et non.

VMWare et Qemu sont des émulateurs de PC. Ils font de la translation binaire de code

 

Petit aparté technique (je remercie Monsieur Ramblewski pour ses explications très complètes sur le principe): 

 

Par défaut, un processeur dispose de 4 niveaux d’exécution appelés « rings ». (cf http://en.wikipedia.org/wiki/Ring_%28computer_security%29 pour plus d'explications)

 

Sur une archi x86 32 bits, le système d’exploitation fonctionne sur le ring 0 et dispose du plus haut niveau de contrôle à l’inverse des applications qui tournent sur le ring 3.

 

Les couches de niveau supérieures ne peuvent pas modifier le comportement des couches inférieures, seul l’inverse est vrai. (Un OS arrête une appli, pas l’inverse)

Le passage en mode privilégié est standard sur des archis x86, ce sont nos chers syscalls.

Exemple :On fait un « open » en userland, une interruption (int 0x80 sous archi x86 pour ne pas la citer) est envoyée au kernel qui passe dans la fonction « trampoline » codée en assembleur (fichier syscalls.S si je ne m’abuse) et qui permet de switcher le processeur en mode privilégié, le fameux ring 0.

A partir de là on est en kernel mode, le processeur est au ring 0 et tout est possible.

 

Revenons à nos moutons :Lorsque l’on virtualise, on utilise un OS privilégié: l’hyperviseur. Il contrôle les hôtes et les ressources physiques et utilise le ring 0.

L’hyperviseur gère les guests qui doivent donc, pour respecter la hiérarchie de contrôle, utiliser les rings 1 ou 2.

Le problème est qu’un OS est conçu pour ne s’exécuter que sur le ring 0, il vérifie qu’il réside au bon endroit mémoire dédié aux OS et certaines instructions ne s’exécutent que si elles viennent du ring 0 ou y vont. (et heureusement…)

 

Pour pallier à ce problème, on utilise donc la virtualisation.

La paravirtualisation (XEN) consiste à modifier les OS invités pour permettre un mode d’exécution autre que le ring 0.Lorsque l’on ne peut pas modifier le code de l’OS (…), on procède à des translations binaires (VMware, QEMU) pour faire croire à l’OS qu’il occupe un emplacement mémoire valide ainsi que le niveau d’exécution processeur ring 0. Evidemment, ce dernier mode est plus gourmand en ressource.

 

Bon, on joue...

 

Ce TP se compose de deux parties... Une partie historique avec une debian qui lance une debian, et une partie funky qui utilise opensolaris en tant que domaine0.

 

 

Partie Solaris:

Nous allons utiliser le système Opensolaris en tant que Domaine0 (hyperviseur), nous allons ensuite installer une machine hôte

 

Le but de ce TP n'est pas d'apprendre Opensolaris...

 

Installation d'Opensolaris.

Installer votre Rack, booter le CD et installez l'OS

 

Initialisation du dom0

 

Installation des packages

pkg install SUNWxvmhvm

pkg install SUNWvirtinst

pkg install SUNWlibvirt

pkg install SUNWurlgrabber

 

Modification du grub

owulvery@opensolaris:~$ pfexec vi /rpool/boot/grub/menu.lst

...

title OpenSolaris xVM

bootfs rpool/ROOT/opensolaris

findroot (pool_rpool,0,a)

kernel$ /boot/$ISADIR/xen.gz

module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS

module$ /platform/i86pc/$ISADIR/boot_archive

 

reboot

 

Activation du domaine 0

 

svcadm enable store

svcadm enable xend

svcadm enable console

svcadm enable domains

svcadm enable virtd

 

Test du domaine0:

 

La commande

xm info

devrait retourner les mode de fonctionnement de Xen.

 

Installation d'un domU

 

L'utilitaire virtinstall permet d'installer facilement un domU http://opensolaris.org/os/community/xen/docs/virtinstall/

 

N'ayant pas exactement connaissance du matériel, je considère pour la suite de ce TP que les machines sont capables de lancer du HVM...

 

L'installation de ubutnu en HVM peut être réalisée via virt-install:

 

 

virt-install -n Ubuntu --hvm -r 1024 --vnc -f /export/home/images/ubuntu.img -s 5 -c /export/home/isos/ubuntu.iso

 

La fin de ce tp, consiste à utiliser la machine virtuelle en mode de paravirtualisation...

Afin de ne pas plagier un article, merci de vous référencer à l'adresse suivante pour continuer ce TP:

 

http://bderzhavets.wordpress.com/2008/12/11/ubuntu-hardy-hvm-vs-pv-domu-at-opensolaris-200811-dom0/

 

Partie Debian Legacy...

 

Paramétrage du dom0 

  

apt-cache -n search xen-linux-system

Installer le package qui correspond 

  

ex: 

apt-get install xen-linux-system-2.6.18-4-xen-686 

  

Vérifier la configuration de grub et redémarrer le système. 

  

Nous avons donc un dom0 disponible, et nous pouvons donc poursuivre avec l'installation d'un OS invité... 

  

Installation d'un domU

 

Une fois notre système prêt, il faut installer le deuxième OS à virtualiser.

 

Il est tout à fait possible de rebooter la machine et d'effectuer l'installation de l'OS de façon classique sur une autre partition du disque dur, mais, dans le cas ou l'on ne dispose pas d'une partition de libre, il est possible d'utiliser une image disque, ce que nous allons faire.

 

Le principe est de créer un gros fichier spécial que l'on va utiliser comme une disque dur. A l'aide de la commande dd, nous allons donc créer une image disque de 1,5Go dans /srv/.

 

dd if=/dev/zero of=/srv/xen1.img bs=1M count=1500

 

Cette image créée, il faut la formater (comme on le ferait avec une partition d'un 

disque dur):

 

mkfs.ext3 /srv/xen1.img

 

Nous disposons maintenant d'un fichier de 1,5Go que l'on peut utiliser comme une 

partition d'un disque dur.

 

Nous allons donc le monter:

 

mount -o loop /srv/xen1.img /mnt

 

Installons notre OS à virtualiser dans ce fichier (donc dans /mnt) grâce à debootstrap.

Debootstrap permet d'installer un système Debian de base en lui passant en paramètre la version à utiliser (man debootstrap est votre ami): 

  

debootstrap etch /mnt http://ftp.fr.debian.org/debian

  

Une fois le système de base installé, il ne reste plus qu'à s'enfermer dedans grâce à 

chroot afin de le configurer:

  

chroot /mnt /bin/bash 

  

Maintenant que nous somme dans notre OS à virtualiser, donnons-lui un noyau. 

Recherchez une image du noyau patchée pour Xen et installez là. Installez également la 

libc6-xen et module-init-tools si ce n'est pas déjà fait.

  

Une fois le noyau installé, il faut configurer le fichier /etc/fstab afin de donner une ou 

plusieurs partition à notre système.  

Dans notre cas, nous n'avons créé qu'un seul fichier 

image, donc nous n'aurons qu'une seule partition.  

Editer /etc/fstab en lui ajoutant la ligne:  

  

/dev/hda1 / ext3 defaults,errors=remount-ro 0 1. 

  

De la même façon, configurer votre réseau en éditant /etc/network/interfaces. Il faut bien avoir en tête que vous configurez l'interface réseau d'un deuxième système

d'exploitation, donc virtuellement d'une deuxième carte réseau. Il ne faut donc pas lui 

attribuer la même ip que le dom0. 

  

Ce système de base configuré, on sort du chroot (exit).

  

On copie le noyau installé dans notre DomU afin qu'il soit booté par xen à la création de 

celui-ci:  

  

cp /mnt/boot/* /boot/, et on démonte notre fichier image (umount /mnt).

  

Nous avons donc un fichier image xen1.img contenant un système Debian bootable. 

  

Afin que le réseau fonctionne correctement, Xen utilise le mécanisme de pont réseau de 

Linux afin de brancher les interfaces virtuelles des DomUs sur l'interface réseau du 

Dom0. Il faut donc modifier la configuration réseau du dom0 afin de mettre en place le 

pont. 

  

Editez le fichier /etc/network/interfaces afin de rajouter les lignes suivantes:

  

auto br-xen 

iface br-xen inet static 

address xxx.xxx.xxx.xxx 

netmask xxx.xxx.xxx.xxx 

gateway xxx.xxx.xxx.xxx 

bridge_ports eth0 

# optional 

bridge_maxwait 0 

  

Assurez-vous également que votre interface eth0 ne soit pas en mode auto: il ne faut 

pas qu'elle soit activée au boot car elle le sera par le bridge. 

  

Reste à configurer le Dom1. Cela se fait dans un fichier de configuration que nous allons 

créer dans /etc/xen/. 

  

Créez donc un fichier xen1 dans /etc/xen et ajoutez-y les lignes suivantes: 

  

# Noyau à booter 

kernel = "/boot/vmlinuz-2.6.18-2-xen-686" 

# Pour un noyau avec initrd 

ramdisk = "/boot/initrd.img-2.6.18-2-xen-686" 

# Memoire en Mo 

memory = 128 

# Nom de notre domaine 

name = "xen1" 

# Périphérique root 

root = "/dev/hda1 ro" 

# Disque dur 

# disk = [ 'phy:/dev/hdX,hda1,w' ] # si on utilise une vraie partition 

disk = [ 'file:/srv/xen1.img,hda1,w' ] # si on utilise un fichier image 

# Bridge réseau 

vif = [ 'mac=aa:00:00:00:00:d2, bridge=br-xen' ] 

  

Reste à rebooter le système sur le noyau Xen. 

  

Une fois le système rebooté, on se place dans /etc/xen et on lance le domaine xen1:  

  

xm create -c xen1. 

  

L'option -c permet de se déplacer dans la console du nouveau domaine. Vous 

voyez normalement le noyau de votre domaine en train de démarrer. 

Une fois le boot achevé, vous obtenez un invite de login classique où vous 

pouvez vous logger en tant que root (sans mot de passe). Vous voici loggé 

dans un OS virtuel. 

vous pouvez retourner dans le domaine0 en utilisant ctrl+alt+FX et en vous 

reloggant. Vous disposez maintenant d'une Etch et d'une Etch « virtuelle » tournant 

toutes les deux simultanément sur la même machine avec des noyaux 

différents.