Xen

From AleikoumWiki

Jump to: navigation, search

Contents

Présentation

Qu'est ce que Xen ?

Xen est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle.
Il est développé par l'université de Cambridge au Royaume-Uni. Xen permet de faire fonctionner plusieurs systèmes d'exploitation virtuels (invités) sur une seule machine hôte.
Le principe de l'hyperviseur est de faire tourner les OS dans le noyau (kernel) même, et non-pas de les émuler, ce qui permet de conserver des performances proches des natives.

Architecture Xen
Logiciels de contrôle Xen
Xeno-Linux
Pilotes Xen
Espace utilisateur
Linux
Pilotes Xen
Espace utilisateur
NetBSD
Pilotes Xen
Espace utilisateur
FreeBSD
Pilotes Xen
Espace utilisateur
Plan 9
Pilotes Xen

Xen

Matériel : processeur, mémoire, stockage, réseau, etc.


notions

Avant de commencer il faut bien comprendre la différence entre un Dom0 et un DomU, voici une explication de Wikipedia :
A Xen system is structured with the Xen hypervisor as the lowest and most privileged layer. Above this layer are one or more guest operating systems, which the hypervisor schedules across the physical CPUs. The first guest operating system, called in Xen terminology "domain 0" (dom0), is booted automatically when the hypervisor boots and given special management privileges and direct access to the physical hardware. The system administrator can log into dom0 in order to manage any further guest operating systems, called "domain U" (domU) in Xen terminology.


D'autres informations et "vulgarisation" sur Xen sur ce lien : xen pour les nuls


Différences avec d'autres outils de virtualisation

source : http://fr.wikipedia.org/wiki/Virtualisation_(informatique)

Machine Virtuelle

Une machine virtuelle est un logiciel (généralement assez lourd) qui tourne sur l'OS hôte. Ce logiciel permet de lancer un ou plusieurs OS invités. La machine virtualise ou/et émule le matériel pour les OS invités, ces derniers croient dialoguer directement avec ledit matériel.

Cette solution est très comparable à un émulateur, et parfois même confondue. Cependant l’unité centrale de calcul, c'est-à-dire le microprocesseur, la mémoire de travail (ram) ainsi que la mémoire de stockage (via un fichier) sont directement accessible aux machines virtuelles, alors que sur un émulateur l’unité centrale est simulée, les performances en sont donc considérablement réduites par rapport à la virtualisation.

Cette solution isole bien les OS invités, mais elle a un coût en performance. Ce coût peut être très élevé si le processeur doit être émulé, comme cela est le cas dans l’émulation. En échange cette solution permet de faire cohabiter plusieurs OS hétérogènes sur une même machine grâce à une isolation complète. Les échanges entre les machines se font via les canaux standards de communication entre systèmes d’exploitation (TCP/IP et autres protocoles réseau), un tampon d’échange permet d’émuler des cartes réseaux virtuelles sur une seule carte réseau réelle.


Exemples :

  • QEMU : émulateur de plateformes x86, PPC, Sparc
  • Kernel-based Virtual Machine|kvm]] : version modifiée de QEMU tirant parti des instructions de virtualisation des processeurs Intel et AMD (Intel VT ou AMD-V)
  • bochs : émulateur de plateforme x86
  • Lismoresystems Guest PC : propriétaire, émulateur de plateforme x86 sur matériel PC
  • MacOnLinux : émulateur de plateforme Mac OS sur Linux PPC
  • Microsoft VirtualPC et Microsoft VirtualServer : propriétaire, émulateur de plateforme x86
  • Parallels Desktop : propriétaire
  • PearPC : émulateur de plateforme PPC sur matériel x86
  • Plex86 : émulateur de plateforme x86
  • VirtualBox : émulateur de plateforme x86
  • VMware : propriétaire, émulateur de plateforme x86 (produits VMware Server, VMware Player et VMware Workstation)
  • Hercules : émulateur qui permet l'émulation d'un mainframe z/OS sur PC Windows ou Linux avec émulation des disques


Hyperviseur

Un hyperviseur est comme un noyau système très léger et optimisé pour gérer les accès des noyaux d'OS invités à l'architecture matérielle sous-jacente. Si les OS invités fonctionnent en ayant conscience d'être virtualisés et sont optimisés pour ce fait, on parle alors de para-virtualisation (méthode indispensable sur Hyper-V de Microsoft et qui augmente les performances sur ESX de VMware par exemple).

Actuellement l’hyperviseur est la méthode de virtualisation d'infrastructure la plus performante mais elle a pour inconvénient d’être contraignante et onéreuse, bien que permettant plus de flexibilité dans le cas de la virtualisation d'un centre de traitement informatique.

Plusieurs solutions sont présentes sur ce marché, il est intéressant d’en faire un léger aperçu. Xen est un hyperviseur initialement développé par l'université de Cambridge au Royaume-Uni et actuellement propriété de Citrix, il utilise un noyau léger supportant des noyaux Linux, Plan9, NetBSD, etc. VMware a un produit mature, ESX qui fait partie d'une offre globale visant à virtualiser les moyens informatique de l'entreprise. Microsoft a sorti un hyperviseur basé sur les mêmes principes fondateurs que ses concurrent. L'hyperviseur de Microsoft est intégré dans son « Windows Server 2008 » (version 64bits uniquement).

Exemples :

  • VMware : propriétaire, hyperviseur sur plateforme x86 (produits ESX et ESXi -Gratuit-)
  • Xen : noyau léger supportant des noyaux Linux, Plan9, NetBSD, etc.
  • Hyper-V : propriétaire, hyperviseur sur plateforme x86.

Objectif de cette page

L'objectif de cette page est de donner une première approche de la virtualisation sous Xen : manuellement mais aussi via les outils Xen (xen-tools).
Les manipulations ont été réalisées sur une Debian Lenny 5.0 et en utilisant LVM.

Requis

Plusieurs packages sont nécessaires pour pouvoir faire tourner le processus Xen. Pour une machine 32bits :

$ sudo aptitude install xen-linux-system-2.6.26-1-xen-686 bridge-utils xen-tools

Le premier paquet (xen-linux-system-2.6.26-1-xen-686) va permettre d'avoir un nouveau kernel patché pour xen.
Le deuxième paquet est un paquet qui va permettre au machine virtuelle de pouvoir "sortir" sur le réseau et d'avoir accès à Internet par exemple.
Le dernier paquet est la suite d'outils pour xen.

Une fois ces paquets installés, il faudra rebooter sur le kernel patché xen. Pour vérifier que vous avez bien booté sur le bon kernel vous pouvez utiliser la commande suivante :

$ uname -a
Linux psrv-qg-dmz-0 2.6.26-1-xen-686 #1 SMP Sat Jan 10 22:52:47 UTC 2009 i686 GNU/Linux

A ce stade, Xen (ses outils et le kernel) est installé ! on peut donc commencer à créer nos premières machines virtuelles !

Attention : sur les R410 il faut recompiler le driver de la carte réseau manuellement... Pour cela il suffit de récupérer les sources ici et de lancer le fameux "make && make install" sauf que pour cela fonctionne il ne faut surtout pas oublier d'installer le package linux-header correspondant à votre kernel !

Paramètrage de xend

xend est le processus qui permet de gérer les interfaces entre les machines virtuelles (DomU) et la machine physique (Dom0).
Il est nécessaire de modifier son fichier (/etc/xen/xend-config.sxp) de configuration pour permettre aux DomU de pouvoir "sortir" sur le réseau.
Voici à quoi doit ressembler - au moins - ce fichier de configuration :

$ sudo cat /etc/xen/xend-config.sxp | grep -v "^#"
(network-script network-bridge)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vncpasswd '')

Les deux premières lignes correspondent aux modifications à apporter pour la configuration réseau.
Il est nécessaire de relancer le service afin que les modifications soient prises en compte :

$ sudo /etc/init.d/xend restart


Nota : en fin de doc, il y a la config à suivre si l'on souhaite mettre du bonding

Création d'un DomU avec les xen-tools

Comme expliqué plus haut, nous allons voir les deux méthodes possibles pour la création de vos DomU. Cette première méthode se base sur les outils de xen-tools. Elle est plus simple et rapide que celle que nous verrons plus tard.

Elle se divise en deux étapes :

  • étape 1 : modification du fichier de configuration des xen-tools, pour que les options correspondent à nos besoins.
  • étape 2 : création de l'image du DomU.

étape 1 : configuration des xen-tools

La configuration des outils xen passe par le fichier /etc/xen-tools/xen-tools.conf .
Ce dernier permet d'initialiser des options qui seront utilisées pour la création des DomU. L'unique but de cette configuration est d'assurer un certain confort dans l'utilisation des outils.
Voici le fichier que j'ai utilisé avec les explications pour chaque entrée :

$ sudo cat /etc/xen-tools/xen-tools.conf | grep -v "^#"
lvm = vg0         # le nom de mon groupe de volume qui sera utilise pour faire
                  # les futurs disques

install-method = debootstrap # la methode d'installation choisie

size   = 4Gb      # la taille de la partition / par defaut
memory = 64Mb     # la taille de la RAM par defaut
swap   = 128Mb    # la taille de la SWAP par defaut
fs     = ext3     # le systeme de fichier par defaut
dist   = lenny    # la distribution par defaut a installer
image  = sparse   # sparse vs. full disk images.

gateway   = 212.99.45.161
netmask   = 255.255.255.224
broadcast = 212.99.45.191

passwd = 1       # en placant cette option a 1, un password vous sera demande 
                 # lors de l'installation du DomU

kernel      = /boot/vmlinuz-`uname -r`
initrd      = /boot/initrd.img-`uname -r`

mirror = http://ftp.fr.debian.org/debian/

ext3_options   = noatime,nodiratime,errors=remount-ro
ext2_options   = noatime,nodiratime,errors=remount-ro
xfs_options    = defaults
reiser_options = defaults

Attention cette configuration suppose qu'un groupe de volume vg0 a déjà été créé.
Pour toute information sur lvm ca se passe ici

Toutes les options de configuration pour la création des images sont accessibles en via la commande suivante :

$ sudo xen-create-image --manual

étape 2 : création de l'image du DomU

Maintenant que tout semble bien configuré, nous pouvons utiliser les xen-tools pour générer le fichier de configuration xen de notre DomU mais aussi pour installer le système de notre DomU !
Pour cela il suffit de lancer la commande suivante :

$ sudo xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188

(plus d'options de création en consultant le man de xen-create-image). Il faut noter que les options non explicitées seront initialisées grâce au fichier de conf édité plus tôt : /etc/xen-tools/xen-tools.conf.

Voici ce que donne l'éxecution de la commande :

# xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188

General Information
--------------------
Hostname       :  psrv-qg-dmz-0-1
Distribution   :  lenny
Partitions     :  swap            128Mb (swap)
                  /               4Gb   (ext3)
Image type     :  full
Memory size    :  64Mb
Kernel path    :  /boot/vmlinuz-2.6.26-1-xen-686
Initrd path    :  /boot/initrd.img-2.6.26-1-xen-686

Networking Information
----------------------
IP Address 1   : 212.99.45.188 [MAC: 00:16:3E:8C:EB:F0]
Netmask        : 255.255.255.224
Broadcast      : 212.99.45.191
Gateway        : 212.99.45.161


Creating swap on /dev/vg0/psrv-qg-dmz-0-1-swap
Done

Creating ext3 filesystem on /dev/vg0/psrv-qg-dmz-0-1-disk
Done
Installation method: debootstrap
Done

Running hooks
Done

No role scripts were specified.  Skipping

Creating Xen configuration file
Done
Setting up root password
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
All done

Logfile produced at:
	 /var/log/xen-tools/le-nom-de-votre-host.log

N'hésitez pas à suivre l'évolution de l'installation :

tail -f /var/log/xen-tools/le-nom-de-votre-host.log

Si tout se passe bien, les deux disques virtuels /dev/vg0/psrv-qg-dmz-0-1-swap et /dev/vg0/psrv-qg-dmz-0-1-disk auront été créés et formatés (vérification avec la commande lvdisplay) et un fichier aura été généré : /etc/xen/psrv-qg-dmz-0-1.cfg .

Cependant cette méthode ne va créer que 2 partitions : pour / et pour le swap. Si vous souhaitez plus de partitions/disques formattés pour des fs différents c'est aussi possible ! Pour cela il va falloir créer un fichier dans le répertoire /etc/xen-tools/partition.d/ en s'inspirant de l'exemple suivant :

$ sudo cat /etc/xen-tools/partitions.d/test-server 
[root]
size=1G
type=ext3
mountpoint=/
options=sync,errors=remount-ro

[swap]
size=2G
type=swap

[home]
size=1G
type=ext3
mountpoint=/home
options=nodev,nosuid

[usr]
size=4G
type=ext3
mountpoint=/usr
options=nodev

[var]
size=4G
type=ext3
mountpoint=/var
options=nodev,nosuid

[tmp]
size=4G
type=ext3
mountpoint=/tmp
options=nodev,nosuid

La commande pour créer le DomU est donc complétée d'une option pour les partitions :

$ sudo xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188 --partition=test-server --memory=1024



Le DomU est donc créé et presque prêt à l'emploi... presque car tel quel, le fichier généré ne permettra pas d'avoir accès à la console de la machine virtuelle. Pour permettre cela, executer simplement la ligne suivante :

# echo "extra = 'xencons=tty1 clocksource=jiffies'" >> /etc/xen/psrv-qg-dmz-0-1.cfg

Cette ligne est une option de boot du kernel pour le DomU qui spécifie que tty1 (soit la première console) est dédiée au mode console xen.

Il est aussi possible de modifier certaines valeurs du fichier /etc/xen/psrv-qg-dmz-0-1.cfg pour tunner certaines valeurs "après coups" comme la RAM, le nombre de CPU...

Création d'un DomU "manuellement" - METHODE OBSOLETE !

La création des DomU via les outils xen est très intéressante mais ne permet pas une souplesse totale essentiellement pour les partitions.
En effet à chaque fois 2 partitions seront créées : une pour / et une pour le swap et visiblement il n'est pas possible de spécifier plus de partitions (du moins j'ai pas trouvé comment :) edit : en fait si cf. paragraphe d'avant ).
Cette section décrira donc les étapes à suivre pour permettre de créer un DomU avec les spécifications systèmes que l'on souhaite.
Pas forcément très compliqué, la procédure reste tout de même plus longue que la précedente.

On souhaite avoir un DomU avec les partitions suivantes :

  • / de 1Go
  • /boot de 64Mo
  • /usr de 5Go
  • /tmp de 2Go
  • /var de 50Go
  • /home de 5Go
  • /usr/local de 5Go
  • un swap de 2Go

Pour cela nous allons suivre les étapes suivantes :

  • étape 1 : création des partitions avec LVM
  • étape 2 : installation du système
  • étape 3 : création du fichier de configuration du DomU

étape 1 : création des partitions avec LVM

La création et la manipulation des partitions avec LVM n'est pas l'objectif de cette page mais ce tuto permettra de comprendre les lignes de commandes qui suivent :

lvcreate -n p01 -L 64m vg0
lvcreate -n p02s -L 2g vg0
lvcreate -n p03 -L 1g vg0
lvcreate -n p04 -L 5g vg0
lvcreate -n p05 -L 2g vg0
lvcreate -n p06 -L 50g vg0
lvcreate -n p07 -L 5g vg0

mkswap /dev/vg0/p02s
mke2fs -j /dev/vg0/p01
mke2fs -j /dev/vg0/p03
mke2fs -j /dev/vg0/p04
mke2fs -j /dev/vg0/p05
mke2fs -j /dev/vg0/p06
mke2fs -j /dev/vg0/p07

A ce stade, vous avez donc toutes vos partitions créées et formatées.

étape 2 : installation du système

L'installation du système se fera via debootstrap. Mais avant il faut monter toutes les partitions précédémment créées.

$ sudo mkdir /data/forinstall
$ sudo mount /dev/vg0/p03 /data/forinstall
$ sudo mkdir /data/forinstall/boot /data/forinstall/usr /data/forinstall/tmp /data/forinstall/var /data/forinstall/boot
$ sudo mount /dev/vg0/p01 /data/forinstall/boot/
$ sudo mount /dev/vg0/p04 /data/forinstall/usr/
$ sudo mount /dev/vg0/p05 /data/forinstall/tmp/
$ sudo mount /dev/vg0/p06 /data/forinstall/var/
$ sudo mkdir /data/forinstall/usr/local
$ sudo mount /dev/vg0/p07 /data/forinstall/usr/local/
$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda5              1921156    174472   1649092  10% /
tmpfs                  4088320         0   4088320   0% /lib/init/rw
udev                     10240       380      9860   4% /dev
tmpfs                  4088320         0   4088320   0% /dev/shm
/dev/sda1                62193     23900     35082  41% /boot
/dev/sda11           415286820    203096 393988376   1% /data
/dev/sda8              9614116    152736   8973008   2% /home
/dev/sda7              9614116    152692   8973052   2% /tmp
/dev/sda6              9614116    446612   8679132   5% /usr
/dev/sda10             9614116    152772   8972972   2% /usr/local
/dev/sda9              9614116    409108   8716636   5% /var
/dev/mapper/vg0-p03    1032088     34108    945552   4% /data/forinstall
/dev/mapper/vg0-p01      63461      5402     54783   9% /data/forinstall/boot
/dev/mapper/vg0-p04    5160576    141440   4756992   3% /data/forinstall/usr
/dev/mapper/vg0-p05    2064208     68676   1890676   4% /data/forinstall/tmp
/dev/mapper/vg0-p06   51606140    184268  48800432   1% /data/forinstall/var
/dev/mapper/vg0-p07    5160576    141436   4756996   3% /data/forinstall/usr/local

Maintenant on peut lancer l'installation du système dans cette arborescence :

$ sudo debootstrap --arch i386 lenny /data/forinstall/ http://ftp.fr.debian.org/debian 

Puis pour finaliser l'installation :

$ cd /data/forinstall
$ cp /etc/apt/sources.list etc/apt/
$ cp -a /lib/modules/2.6.26-1-xen-686/ lib/modules/
$ cp /etc/resolv.conf etc/
$ cp /etc/network/interfaces etc/network/
$ vim etc/network/interfaces # a modifier avec les informations reseaux du DomU
$ vim etc/hostname           # a modifier avec le nom du DomU
$ vim etc/hosts              # a modifier ainsi : 127.0.0.1 localhost <nom_du_DomU>

La dernière chose qu'il reste à faire et d'éditer la fstab du futur DomU afin de monter les partitions comme il se doit (et avec les options voulues).

# cat etc/fstab
proc            /proc           proc            defaults        0       0
/dev/sda1       /boot           ext3            defaults        0       2
/dev/sda2       none            swap            sw              0       0
/dev/sda3       /               ext3            errors=remount-ro 0     1
/dev/sda4       /usr            ext3            defaults        0       2
/dev/sda5       /tmp            ext3            defaults        0       2
/dev/sda6       /var            ext3            defaults        0       2
/dev/sda7       /usr/local      ext3            defaults        0       2

Le DomU est donc créé et configuré. Il ne reste plus qu'a démonter toutes les partitions du DomU.

étape 3 : création du fichier de configuration du DomU

Il faut maintenant refaire un fichier de configuration du DomU pour le processus xend.
Créez le fichier /etc/xen/psrv-qg-dmz-0-3.cfg comme suit :

#
#  Kernel + memory size + cpu
#
kernel      = '/boot/vmlinuz-2.6.26-1-xen-686'
ramdisk     = '/boot/initrd.img-2.6.26-1-xen-686'
memory      = '1024'
vcpus       = '2'

#
#  Disk device(s).
#
root        = '/dev/sda3 ro'
disk        = [
                  'phy:/dev/vg0/p01,sda1,w',
                  'phy:/dev/vg0/p02s,sda2,w',
                  'phy:/dev/vg0/p03,sda3,w',
                  'phy:/dev/vg0/p04,sda4,w',
                  'phy:/dev/vg0/p05,sda5,w',
                  'phy:/dev/vg0/p06,sda6,w',
                  'phy:/dev/vg0/p07,sda7,w',
              ]


#
#  Hostname
#
name        = 'psrv-qg-dmz-0-3'

#
#  Networking
#
vif         = [ 'ip=212.99.45.190' ]

#
#  Behaviour
#
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

extra = 'xencons=tty1' # /!\ sans cette ligne pas d'acces possible via xm console

Exploitation des DomU

démarrer un DomU

D'abord il faut s'assurer que le processus xend tourne bien et le démarrer si nécessaire.
Puis pour démarrer une machine virtuelle, il suffit de lancer la commande suivante xm create <file>, par exemple :

$ sudo xm create /etc/xen/psrv-qg-dmz-0-3.cfg
Using config file "/etc/xen/psrv-qg-dmz-0-3.cfg".
Started domain psrv-qg-dmz-0-3
$

La vérification des DomU activé, se fait ainsi :

# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  7984     4     r-----    122.1
psrv-qg-dmz-0-3                              3  1024     2     -b----      9.3

On constate bien que la machine virtuelle psrv-qg-dmz-0-3 est bien démarrée et se trouve dans l'état blocked.

finalisation de l'installation

La machine virtuelle tourne bien, il ne reste plus qu'à se connecter à la console de cette dernière pour finir la configuration (en particulier configurer SSH pour avoir un accès distant).
Pour avoir accès à la console de la machine virtuelle psrv-qg-dmz-0-3, il suffit de taper la commande suivante :

# xm console psrv-qg-dmz-0-3
Debian GNU/Linux 5.0 le-nom-de-votre-host hvc0

psrv-qg-dmz-0-3 login:

Le seul login possible pour le moment est root, avec un password dans le cas d'une installation avec les outils et sans password dans le cas d'une installation manuelle.
Pour la suite de l'installation et de la configuration de cette machine virtuelle, il vous faudra suivre les instructions de la procédure d'installation d'un OS chez Linkeo.


Vérification de la procédure d'installation

Ainsi vous aurez installé et configuré entre autre votre serveur SSH pour avoir l'accès distant... cependant si vous essayez de vous connectez vous risquez de tomber sur l'erreur suivante : PTY allocation request failed on channel 0. Pour pallier à ce problème, il suffit d'installer udev et de rajouter une ligne dans fstab comme suit :

$ sudo aptitude install udev
...
$ sudo echo "none /dev/pts devpts defaults 0 0" >> /etc/fstab
$ sudo mount -a

La dernière chose à régler est l'indépendance de la clock du DomU par rapport au Dom0, pour cela il suffit de faire ceci :

$ sudo echo "xen.independent_wallclock=1" >> /etc/sysctl.conf
$ sudo sysctl -p
$ sudo echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource

Cette opération ne sera à faire qu'une seule fois !
Explications : http://www.steveglendinning.com/2009/03/23/time-went-backwards/

commandes / admin

# lister les machines referencees dans xen
xm list
# le resultat se presente sous la forme suivante :
# name domid memory vcpus state cputime
# ou
#  * name : nom de la machine virtuelle
#  * domid : id de la machine virtuelle
#  * memory : taille de la RAM allouee a la machine virtuelle
#  * vcpus : nombre de processeur virtuel alloues a la machine virtuelle
#  * state : 
#      - r == running
#      - b == blocked
#      - p == paused
#      - s == shutdown
#      - c == crashed
#  * cputime : temps CPU consomme par la machine virtuelle


# demarrer la machine virtuelle definie dans fichier.cfg
xm create fichier.cfg


# arreter la machine virtuelle
# on peut utiliser le nom ou l'id
xm shutdown nom


# changer la quantite de memoire ou le nombre de cpu
xm mem-set id taille
xm vcpu-set id number
# s'il est toujours possible de reduire la taille de la memoire ou le nombre de VCPU
# il est impossible de les augmenter au dela des valeurs definies dans le fichier de 
# conf de la machine virtuelle
# a noter la taille est definie en Mo


# afficher les messages XEN au boot:
xm dmesg 


# le log de xend :
/var/log/xen/xend.log

Configuration avancées

mettre en place le bonding pour les DomU

Le bonding des DomU se fait... au niveau du Dom0 !
En effet pour le DomU, il y aura toujours une seule interface réseau (eth0). Tout se joue au niveau du Dom0 sur lequel on va déclarer eth1 et eth0 éligible au bonding, et c'est l'interface de bonding qui sera utilisée faire "sortir" le flux réseau des DomU

On suppose ici que le kernel est bien compilé avec le module de bonding. On peut le vérifier ainsi :

$ cat /boot/config-`uname -r` |grep BONDING
CONFIG_BONDING=m

La seule chose à faire est de modifier le fichier /etc/network/interfaces du Dom0 comme suit :

$ cat /etc/network/interfaces 
# The loopback network interface
auto lo
iface lo inet loopback

# definition de l'interface de bonding : bond0
auto bond0
iface bond0 inet manual
         slaves                 eth0 eth1
         bond_mode              active-backup    # mode active backup : 
         bond_miimon            100              # check toutes les 100ms
         bond_updelay           4000             # temps de latence entre la decouverte de la reconnexion d'une interface et de sa re-utilisation.
         bond_primary           eth0             # l'interface primaire est eth0

auto br0
iface br0 inet static
         address                212.99.45.187   # adresse IP du Dom0
         netmask                255.255.255.224 
         gateway                212.99.45.161
         bridge_ports  bond0                    # liaison du pont avec l'interface de bonding
         bridge_stp off                         # desactive le Spanning tree
         bridge_fd 0                            # temps en secondes entre "learning state" et "forwarding state"

Voici la liste complète des options pour le bonding :

  • updelay : temps de latence entre la découverte de la reconnexion d'une interface et de sa ré-utilisation.
  • downdelay : temps de latence entre la découverte de la déconnexion d'une interface et de sa désactivation de bond0.
  • miimon : fréquence de surveillance des interfaces par Mii ou ethtool. La valeur conseillée est 100.
  • use_carrier : utilisation de la surveillance des interfaces par "carrier".
  • arp_interval : système de surveillance par ARP, évitant l'utilisation de miitool et ethtool. Si aucune trame est arrivée pendant l'arp_interval, on envoie par cette interface jusqu'à 16 requêtes ARP à 16 adresses IP. Si aucune réponse n'est obtenue, l'interface est désactivée.
  • arp_ip_target : liste des adresses IP, séparées par une virgule, utilisée par la surveillance ARP. Si aucune n'est renseignée, la surveillance ARP est inactive


Mais pour qu'une telle configuration soit active il va falloir modifier la configuration du démon xen (/etc/xen/xend-config.spx) en remplacant la ligne (network-script network-bridge) , le fichier devient :

$ sudo cat /etc/xen/xend-config.sxp | grep -v "^#"
(network-script network-dummy)
(vif-script vif-bridge)
(dom0-min-mem 196)
(dom0-cpus 0)
(vncpasswd '')

De plus il faudra modifier les entrées vif de chaque fichier de configuration de DomU (sinon ils n'auront plus de réseau !) comme suit :

$ sudo cat migration-test.cfg | grep vif
vif         = [ 'bridge=br0' ]

En fait on spécifie manuellement le bridge que la machine virtuelle va utiliser pour "sortir", cette opération était réalisée avant par le script network-bridge de xen (qui créait des soucis lors du reboot du Dom0)
Il est possible d'ajouter l'adresse IP de la machine virtuelle dans le vif mais ce n'est pas obligé.


dom0 reboot automatiquement

Par défaut le comportement de Xen est de rebooter la machine lorsqu'il crash (typiquement lors d'un kernel panic). Pour désactiver ce comportement, il suffit d'utiliser l'option noreboot dans les options de Grub, par exemple :

title		Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-1-xen-686
root		(hd0,0)
kernel		/xen-3.2-1-i386.gz noreboot
module		/vmlinuz-2.6.26-1-xen-686 root=/dev/sda3 ro console=tty0
module		/initrd.img-2.6.26-1-xen-686

configurer la quantité de mémoire dont le dom0 a besoin

Pour forcer la taille de la quantité de mémoire utilisée par le dom0, il sufit d'utiliser l'option dom0_mem (la quantité de mémoire en octet), par exemple :

title		Debian Xen 2.0.7/2.6.11 
root		(hd0,0)
kernel	 	/boot/xen-2.0.7.gz dom0_mem=65536 noreboot
module		/boot/xen-linux-2.6.11-ocxen0 root=/dev/hda1 ro console=tty0

HVM : virtualisation matérielle

... à completer ...

Qu'est ce que le HVM ?

compléter : performance, intérêt, etc...

HVM (Hardware Virtual Machine) est l'abstraction de Xen concernant la virtualisation matérielle (dispo sur les Intel™ avec VT et les AMD™ avec Pacifica).
Ceci permet des choses relativement intéressante comme celle d'avoir des machines virtuelles utilisant des noyaux différents de celui du Dom0 (on peut donc installer un Windows par exemple !!).

Création d'un DomU

La création va se dérouler en deux étapes :

  • étape 1 : préparation du DomU, création du fichier xen, des partitions pour le futur file system
  • étape 2 : procédure d'installation du système sur ce nouveau DomU
  • étape 3 : post installation

étape 1 : préparatif

Tout d'abord il faut bien activer le module VT (virtual technologie) dans notre cas dans le bios car sinon il sera impossible de lancer des DomU en HVM. Ce module s'active au niveau des settings du CPU il suffit de le passer à "enable". Pour cela, une fois rentré dans le menu du BIOS (F2 lors du boot) :

Menu > CPU Information <ENTER>
Selectionner l'entree : Virtualization Technology et passer a Enable (<fleche de droite>)
Sortir de ce menu <ESC>
Sortir du BIOS <ESC>
Choisir Save and exit <ENTER>

On continue en créant une partition avec LVM que l'on va utiliser pour représenter le disque "physique" de notre futur DomU.

lvcreate -n p11 -L 8g vg0

Ainsi on aura un disque de 8Go pour ce DomU qu'on partionnera lors de l'installation de l'OS (démarche différente de ce qui a été vu plus tôt).

Il faut maintenant déclarer le fichier de configuration xen pour ce DomU et plusieurs nouvelles entrées vont faire leur apparition et certaines changent radicalement :


kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'
builder='hvm'                                    # specification du mode hvm
device_model = '/usr/lib/xen-3.2-1/bin/qemu-dm'

memory = 512


# TOTEST : sans shadow_memory, xen doit pouvoir gerer seul et au mieux
# Shadow pagetable memory for the domain, in MB.
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 8

vcpus=1

on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'

name = 'vnotes-hvm'

#
#  Networking
#
# la definition change un peu : il y a la précision du type 
# pour specifier qu'on est bien en HVM
# /!\ TOTEST : sans la precision du bridge a monter /!\
vif = ['type=ioemu, bridge=br0']


# definition de l'ordre du boot
# correspondance de boot : floppy (a), hard disk (c) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy
#boot="d"      # lors de la pre-installation
boot='cd'      # lors de la post-installation

disk = [ 
           'phy:/dev/vg0/p11,ioemu:hda,w', 
           'file:/usr/src/debian-31r8-i386-netinst.iso,ioemu:hdb:cdrom,r' # le cdrom est une ISO
           #'phy:/dev/hdb,ioemu:hdc:cdrom,r'                              # pour utiliser le lecteur cd physique
       ]

# deux methodes d'acces a distance : SDL et VNC 
sdl=0                       # desactivation de SDL
vnc=1                       # activation de VNC

vnclisten='127.0.0.1'       # VNC n'ecoutera que sur 127.0.0.1
vncunused=0
# il faut les incrementer pour chaque DomU dans ce cas
# sinon il y aura conflit !
vncdisplay=1                # identifiant VNC
vncconsole=1                # identifiant VNC


usb=1                       # activation des ports USB
usbdevice='tablet'          # precision qu'un clavier est connecte en USB

keymap='fr'                 # sans ca, c'est un keymapping suspect que vous aurez ;)

étape 2 : installation

Une fois le fichier de configuration, on peut lancer la machine virtuelle comme d'habitude :

$ sudo xm create /etc/xen/vnotes-hvm.cfg
Using config file "/etc/xen/vnotes-hvm.cfg".
Started domain vnotes-hvm
$

Théoriquement comme on est en "pré-installation", le boot se fait sur l'ISO (soit sur le lecteur cd).
Mais comment suivre et poursuivre l'installation ? VNC !!
Vérifiez d'abord qu'un serveur VNC est bien en écoute sur 127.0.0.1:5901 :

# netstat -an | grep 5901
tcp        0      0 127.0.0.1:5901          0.0.0.0:*               LISTEN 

Si comme moi vous accéder à votre Dom0 via ssh, il sera nécessaire d'ouvrir un tunnel pour pouvoir se connecter au serveur VNC. Pour cela il vous suffit de lancer un terminal et d'éxecuter la commande suivante :

[erwan@erwan-laptop -14:34:37- ~]$ ssh -N -T -L 3128:127.0.0.1:5901 erwan@<IP_DOM0>

puis il vous suffit de lancer un VNC sur 127.0.0.1:3128.
A ce stade vous pouvez installer votre système comme vous le souhaitez.

étape 3 : post-installation

L'installation une fois finie, il ne reste qu'a installer un serveur SSH, pour une prise à distance plus aisée.
Une fois SSH configuré, il va falloir éteindre la machine virtuelle et modifier son fichier de configuration xen pour désactiver le VNC et changer l'odre de boot !

Exploitation

Modification de la taille d'une partition d'un DomU

L'avantage de reposer sur LVM laisse la souplesse de resizer les partitions des DomU à la demande : aussi bien pour agrandir ou rétrécir une partition.

Agrandir une partition

Il n'y a aucun problème à agrandir une partition d'un DomU (soit un LV au niveau du Dom0).
Les seuls contraintes sont :

  • le DomU doit être éteint
  • être sûr que le VG possède bien de l'espace libre à donner au LV

Ensuite il suffit de lancer les commandes suivantes sur le Dom0

$ cat test-mysql-2.cfg | grep sda2
                  'phy:/dev/vg0/test-mysql-2-disk,sda2,w',
# ici nous allons donc resizer le LV /dev/vg0/test-mysql-2-disk correspondant à sda2 du DomU
# on éteint donc le DomU
$ sudo xm shutdown test-mysql-2
# puis on éxecute les commandes suivantes :
# on ajoute 7Go à la partition, sans le "+" cela signifierait qu'on souhaite une partition de 7Go
$ sudo lvresize -L +7g /dev/vg0/test-mysql-2-disk
$ sudo e2fsck -f /dev/vg0/test-mysql-2-disk
$ sudo resize2fs /dev/vg0/test-mysql-2-disk

C'est tout ! il ne reste qu'à relancer le DomU et vérifier avec un df la taille de la partition sda2.

Rétrécir une partition

La réduction de taille d'une partition est un plus subtile : en effet il faut faire très attention à ne pas réduire la partition plus que nécessaire afin d'éviter de perdre des données ! Les contraintes sont :

  • le DomU doit être éteint
  • connaître la quantité d'espace à retirer (soit Taille_A_Retirer), la taille actuelle de la partition (soit Taille_Actuelle) afin de terminer la taille finale de la partition (soit Taille_Actuelle-Taille_A_Retirer=Taille_Finale)

Ensuite il suffit de lancer les commandes suivantes sur le Dom0

$ cat test-mysql-2.cfg | grep sda2
                  'phy:/dev/vg0/test-mysql-2-disk,sda2,w',
# ici nous allons donc resizer le LV /dev/vg0/test-mysql-2-disk correspondant à sda2 du DomU
# on éteint donc le DomU
$ sudo xm shutdown test-mysql-2
# puis on éxecute les commandes suivantes :
# on retire 1Go à la partition qui en fait actuellement 10Go
$ resize2fs -p /dev/vg0/test-mysql-2-disk 9g # on precise que le filesystem doit tenir sur 9Go
$ lvresize -L -1g /dev/vg0/test-mysql-2-disk # on retire 1Go à la partition LVM
$ resize2fs /dev/vg0/test-mysql-2-disk

C'est tout ! il ne reste qu'à relancer le DomU et vérifier avec un df la taille de la partition sda2.

Bonnes pratiques

... à completer ...

  • Sur le Dom0 il faut penser à avoir le minimum de service qui tourne (il est avant tout là pour gérer les interface des DomU avec le matériel)... Pour retirer les services inutiles :
$ sudo update-rc.d -f service_name remove


  • Tips pour le boot du dom0 : avec l'installation du kernel Xen, il y a une nouvelle entrée dans le fichier /boot/grub/menu.lst qu'on peut légérement modifier comme suit :
title		Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-1-xen-686
root		(hd0,0)
kernel		/xen-3.2-1-i386.gz dom0_mem=128000
module		/vmlinuz-2.6.26-1-xen-686 root=/dev/sda5 ro console=tty0
module		/initrd.img-2.6.26-1-xen-686

dom0_mem : permet de spécifier la quantité de mémoire allouée au dom0 et attention c'est en Ko ! Ici donc 128Mo seront allouées au dom0

  • Démarrage automatique des domU au boot de la machine physique et du dom0 ?

Deux choses interviennent : le service xendomains doit être démarré et les fichiers de configuration des domU doivent être présents dans /etc/xen/auto :

ln -s /etc/xen/domU-file.cfg /etc/xen/auto/domU-file.cfg

Migration de machine virtuelle

On considère deux types de migrations : les migrations live et les migrations offline.

Les migrations lives ne sont possibles que si les "disques" du DomU à migrer sont accessibles via le réseau pour le Dom0 cible. Par exemple si les "disques" du DomU se trouvent sur un lecteur NFS... Plusieurs tutoriaux (comme celui ci celui ci) expliquent comment réaliser cette manipulation relativement simple si tous les prérequis sont réunis.
Ces migrations permettent de ne pas avoir de coupure de service (30 à 600ms de reprise annoncé par Xen), en fait ce qui se passe c'est que le contenu de la RAM du DomU sur le Dom0 d'origine est transféré au DomU du Dom0 de destination, et une fois que ceci est réalise le DomU du Dom0 d'origine est éteint et celui du Dom0 de destination activé...

Dans notre cas c'est surtout les migrations offlines qui vont nous intéresser. Pour cela il suffit de suivre les étapes suivantes :

  • créer les partitions du DomU sur le Dom0 destination et les monter en respectant la fstab du DomU : la partition /home du DomU sera montée sur /repertoire-racine-de-montage/home du Dom0 (un peu comme on a pu le faire ici )
  • éteindre le DomU sur le Dom0 source
  • monter les disques du DomU sur le Dom0 source en respectant la fstab du DomU (un peu comme on a pu le faire ici )
  • ensuite il suffit de faire une synchronisation entre les deux Dom0 dans les arborecenses tout juste montées


Pour faciliter la synchro, il est préférable de configurer sur le Dom0 source un serveur rsync comme suit :

$ cat /etc/rsyncd.conf 
log file=/var/log/rsyncd
# for pid file, dont' use /var/run/rsync.pid unless you're not going to run
# rsync out of the init.d script. The /var/run/rsyncd.pid below is OK.
pid file=/var/run/rsyncd.pid
syslog facility=daemon

[<REPERTOIRE_RSYNC>]
  comment = pour la synchro
  path = <POINT_DE_MONTAGE_SUR_DOM0_SOURCE>
  use chroot = yes
  read only = yes
  list = yes
  uid = root
  gid = root
  strict modes = yes #makes sure the secrets file has proper permissions
  hosts allow = <IP_DOM0_DEST>
  hosts deny = *
  ignore errors = no
  ignore nonreadable = yes
  transfer logging = yes
 log format = %t: host %h (%a) %o %f (%l bytes). Total %b bytes.
  timeout = 600
  refuse options = checksum, dry-run
  dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz

Depuis le Dom0 destination il ne reste qu'a lancer la commande suivante :

rsync -av --numeric-ids rsync://<IP_DOM0_SOURCE>/<REPERTOIRE_RSYNC> <POINT_DE_MONTAGE_SUR_DOM0_DESTINATION>
  • copier ensuite sur le Dom0 de destination le fichier de configuration Xen correspondant au DomU migré, démonter les partitions montées pour la synchronisation et démarrer le DomU sur le Dom0 destination (ouf) !

L'arret de service dépend directement du temps nécessaire pour la synchro.
A noter que cette opération n'est pas possible pour une machine virtuelle en HVM.

Supervision

Pour faciliter la configuration de La supervision dans Centreon, 2 templates d'hosts ont été créés : Servers-Linux_dom0 et Servers-Linux_domU.
Dans le template Servers-Linux_domU, les interfaces checkées ne sont pas les mêmes (bond0 n'existant pas) et il n'y a pas de check du matériel Dell (via omreport) ni du bonding.

Liens

http://www.cl.cam.ac.uk/research/srg/netos/xen/ : site officiel du projet
http://fr.wikipedia.org/wiki/Xen : presentation de xen
https://bugs.launchpad.net/ubuntu/+source/xen-tools/+bug/139046 : lien expliquant les parades possibles au bug de la console
http://therbelot.free.fr/Xen/ : tuto et généralité sur Xen
http://www.debian-administration.org/users/lters/weblog/14 : faire du bonding sous Xen
http://www.nabble.com/bonding-ethernet-and-xen-3.2.1-or-later.-td20577529.html : faire du bonding sous Xen sans changer la configuration de Xen
http://sys-admin.wikidot.com/live-migration-xen : migration live sous Xen
http://doc.ubuntu-fr.org/lvm : tout sur les bases de LVM
http://www.tldp.org/HOWTO/text/LVM-HOWTO : la doc complète sur la démystification de LVM

Personal tools