Xen

From AleikoumWiki

(Difference between revisions)
Jump to: navigation, search
m (Creation "manuelle" de l'image de notre DomU)
Current revision (07:55, 22 July 2010) (edit) (undo)
m
 
(20 intermediate revisions not shown.)
Line 1: Line 1:
 +
== Présentation ==
 +
 +
=== Qu'est ce que Xen ? ===
 +
 +
'''Xen''' est un logiciel libre de virtualisation, plus précisément un hyperviseur de machine virtuelle.<br />
 +
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.<br />
 +
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.<br />
 +
<br />
 +
{| cellspacing="10" cellpadding="5" align="center"
 +
|+ ''Architecture Xen''
 +
|-
 +
|
 +
{| border="1" align="center" style="border: 1px solid #999; background-color:#FFFFFF; border-collapse:collapse;" cellpadding="5"
 +
|-bgcolor="#CCCCCC"
 +
|align="center" |Logiciels de contrôle Xen
 +
|-bgcolor="#CCCCCC"
 +
|align="center" |''Xeno-Linux''
 +
|-bgcolor="#CCCCCC"
 +
|align="center" |''Pilotes Xen''
 +
|}
 +
|
 +
{| border="1" align="center" style="border: 1px solid #999; background-color:#FFFFFF; border-collapse:collapse;" cellpadding="5"
 +
|-
 +
|align="center" |Espace utilisateur
 +
|-
 +
|align="center" |'''Linux'''
 +
|-
 +
|align="center" |''Pilotes Xen''
 +
|}
 +
|
 +
{| border="1" align="center" style="border: 1px solid #999; background-color:#FFFFFF; border-collapse:collapse;" cellpadding="5"
 +
|-
 +
|align="center" |Espace utilisateur
 +
|-
 +
|align="center" |'''NetBSD'''
 +
|-
 +
|align="center" |''Pilotes Xen''
 +
|}
 +
|
 +
{| border="1" align="center" style="border: 1px solid #999; background-color:#FFFFFF; border-collapse:collapse;" cellpadding="5"
 +
|-
 +
|align="center" |Espace utilisateur
 +
|-
 +
|align="center" |'''FreeBSD'''
 +
|-
 +
|align="center" |''Pilotes Xen''
 +
|}
 +
|
 +
{| border="1" align="center" style="border: 1px solid #999; background-color:#FFFFFF; border-collapse:collapse;" cellpadding="5"
 +
|-
 +
|align="center" |Espace utilisateur
 +
|-
 +
|align="center" |'''Plan 9'''
 +
|-
 +
|align="center" |''Pilotes Xen''
 +
|}
 +
|-bgcolor="#CCCCCC"
 +
|colspan="5" align="center" |
 +
''Xen''
 +
 +
|-bgcolor="#EFEFEF"
 +
|colspan="5" align="center" |
 +
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:Xen|Wikipedia]] :<br />
 +
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.<br />
 +
<br />
 +
<br />
 +
D'autres informations et "vulgarisation" sur Xen sur ce lien : [http://www.antredugeek.fr/xen/ xen pour les nuls]
 +
 +
 +
====Différences avec d'autres outils de virtualisation====
 +
 +
source : http://fr.wikipedia.org/wiki/Virtualisation_(informatique) <br />
 +
 +
====Machine Virtuelle====
 +
[[Image:Diagramme ArchiEmulateur.png|thumb|right|250px|Emulateur]]
 +
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====
 +
[[Image:Diagramme ArchiHyperviseur.png|thumb|right|250px|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).<br />
 +
Les manipulations ont été réalisées sur une Debian Lenny 5.0 et en utilisant LVM.
 +
== Requis ==
== Requis ==
 +
Plusieurs packages sont nécessaires pour pouvoir faire tourner le processus Xen. Pour une machine 32bits :
<pre>
<pre>
-
aptitude install xen-linux-system-2.6.26-1-xen-686 libc6-xen bridge-utils xen-tools
+
$ sudo aptitude install xen-linux-system-2.6.26-1-xen-686 bridge-utils xen-tools
</pre>
</pre>
-
 
+
Le premier paquet (xen-linux-system-2.6.26-1-xen-686) va permettre d'avoir un nouveau kernel patché pour xen.<br />
-
puis il faut rebooter sur le kernel patche xen<br />
+
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.<br />
-
et theoriquement une fois loggue, on obtient cette information :<br />
+
Le dernier paquet est la suite d'outils pour xen.<br />
 +
<br />
 +
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 :<br />
<pre>
<pre>
-
# uname -a
+
$ 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
Linux psrv-qg-dmz-0 2.6.26-1-xen-686 #1 SMP Sat Jan 10 22:52:47 UTC 2009 i686 GNU/Linux
</pre>
</pre>
-
Xen (ses outils et le kernel) est installe ! on peut commencer a creer notre premier DomU !
+
A ce stade, Xen (ses outils et le kernel) est installé ! on peut donc commencer à créer nos premières machines virtuelles !
-
== Creation avec xen-create-image ==
+
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 [http://www.broadcom.com/support/ethernet_nic/netxtremeii.php 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).<br />
 +
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.<br />
 +
Voici à quoi doit ressembler - au moins - ce fichier de configuration :
 +
<pre>
 +
$ 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 '')
 +
</pre>
 +
Les deux premières lignes correspondent aux modifications à apporter pour la configuration réseau.<br />
 +
Il est nécessaire de relancer le service afin que les modifications soient prises en compte :
 +
<pre>
 +
$ sudo /etc/init.d/xend restart
 +
</pre>
 +
<br />
 +
Nota : en fin de doc, il y a la config à suivre si l'on souhaite mettre du bonding
-
=== Modification des fichiers de configuration ===
+
== Création d'un DomU avec les xen-tools ==
-
Il faut bien distinguer les outils (les xen-tools qui permettent de creer les DomU, les modifier, etc...) du processus xend (qui va faire tourner chaque DomU que vous allez creer)... Ils possedent chacun leur propre fichier de configuration.<br />
+
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.<br />
<br />
<br />
-
Nous allons les modifier comme suit :
+
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.
-
==== /etc/xen-tools/xen-tools.conf ====
+
=== étape 1 : configuration des xen-tools ===
-
Voici le mien :
+
La configuration des outils xen passe par le fichier ''/etc/xen-tools/xen-tools.conf'' .<br />
 +
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.<br />
 +
Voici le fichier que j'ai utilisé avec les explications pour chaque entrée :
<pre>
<pre>
-
# cat /etc/xen-tools/xen-tools.conf | grep -v "^#"
+
$ sudo cat /etc/xen-tools/xen-tools.conf | grep -v "^#"
lvm = vg0 # le nom de mon groupe de volume qui sera utilise pour faire
lvm = vg0 # le nom de mon groupe de volume qui sera utilise pour faire
# les futurs disques
# les futurs disques
-
install-method = debootstrap # la methode d'installation
+
install-method = debootstrap # la methode d'installation choisie
size = 4Gb # la taille de la partition / par defaut
size = 4Gb # la taille de la partition / par defaut
Line 39: Line 195:
image = sparse # sparse vs. full disk images.
image = sparse # sparse vs. full disk images.
-
gateway = 192.168.0.1
+
gateway = 212.99.45.161
-
netmask = 255.255.255.0
+
netmask = 255.255.255.224
-
broadcast = 192.168.0.255
+
broadcast = 212.99.45.191
passwd = 1 # en placant cette option a 1, un password vous sera demande
passwd = 1 # en placant cette option a 1, un password vous sera demande
Line 55: Line 211:
xfs_options = defaults
xfs_options = defaults
reiser_options = defaults
reiser_options = defaults
- 
-
serial_device = hvc0 # /!\ tres important, sans ca pas de console
 
</pre>
</pre>
-
 
+
'''Attention''' cette configuration suppose qu'un groupe de volume ''vg0'' a déjà été créé.<br />
-
 
+
Pour toute information sur lvm ca se passe [http://doc.ubuntu-fr.org/lvm ici]<br />
-
==== /etc/xen/xend-config.sxp ====
+
<br />
-
 
+
Toutes les options de configuration pour la création des images sont accessibles en via la commande suivante :
-
Voici le mien :
+
<pre>
<pre>
-
#cat /etc/xen/xend-config.sxp | grep -v "^#"
+
$ sudo xen-create-image --manual
-
(network-script network-bridge)
+
-
(vif-script vif-bridge)
+
-
(dom0-min-mem 196)
+
-
(dom0-cpus 0)
+
-
(vncpasswd '')
+
</pre>
</pre>
-
Theoriquement les lignes que vous aurez a ajouter sont :
+
=== étape 2 : création de l'image du DomU ===
-
<pre>
+
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 !<br />
-
(network-script network-bridge)
+
-
(vif-script vif-bridge)
+
-
</pre>
+
-
Elles permettent a vos DomU de "sortir" par le reseau et d'avoir acces a Internet par exemple.
+
-
 
+
-
=== Creation "auto" de l'image de notre DomU ===
+
-
 
+
-
==== Etape 1 ====
+
-
Maintenant que tout semble bien configure, nous allons utilise l'assistant de creation d'image pour generer le fichier de configuration xen de notre DomU mais aussi pour installer le systeme de notre DomU !<br />
+
Pour cela il suffit de lancer la commande suivante :
Pour cela il suffit de lancer la commande suivante :
<pre>
<pre>
-
#xen-create-image --hostname=le-nom-de-votre-host --ip=192.168.0.42
+
$ sudo xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188
</pre>
</pre>
-
 
+
(plus d'options de création en consultant le man de xen-create-image).
-
En consultant le man de xen-create-image vous obtiendrez la liste complete des options... de plus il faut noter que les options non explicitees seront initialisees avec le fichier de conf edite plus tot : /etc/xen-tools/xen-tools.conf. <br />
+
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''. <br />
<br />
<br />
-
Voici ce que donne l'execution de la commande :
+
Voici ce que donne l'éxecution de la commande :
<pre>
<pre>
-
# xen-create-image --hostname=le-nom-de-votre-host --ip=192.168.0.42
+
# xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188
General Information
General Information
--------------------
--------------------
-
Hostname : le-nom-de-votre-host
+
Hostname : psrv-qg-dmz-0-1
Distribution : lenny
Distribution : lenny
Partitions : swap 128Mb (swap)
Partitions : swap 128Mb (swap)
Line 107: Line 246:
Networking Information
Networking Information
----------------------
----------------------
-
IP Address 1 : 192.168.0.42 [MAC: 00:16:3E:8C:EB:F0]
+
IP Address 1 : 212.99.45.188 [MAC: 00:16:3E:8C:EB:F0]
-
Netmask : 255.255.255.0
+
Netmask : 255.255.255.224
-
Broadcast : 192.168.0.255
+
Broadcast : 212.99.45.191
-
Gateway : 192.168.0.1
+
Gateway : 212.99.45.161
-
Creating swap on /dev/vg0/le-nom-de-votre-host-swap
+
Creating swap on /dev/vg0/psrv-qg-dmz-0-1-swap
Done
Done
-
Creating ext3 filesystem on /dev/vg0/le-nom-de-votre-host-disk
+
Creating ext3 filesystem on /dev/vg0/psrv-qg-dmz-0-1-disk
Done
Done
Installation method: debootstrap
Installation method: debootstrap
Line 133: Line 272:
passwd: password updated successfully
passwd: password updated successfully
All done
All done
- 
Logfile produced at:
Logfile produced at:
Line 139: Line 277:
</pre>
</pre>
-
Et suivre l'evolution de l'installation :
+
N'hésitez pas à suivre l'évolution de l'installation :
<pre>
<pre>
tail -f /var/log/xen-tools/le-nom-de-votre-host.log
tail -f /var/log/xen-tools/le-nom-de-votre-host.log
</pre>
</pre>
-
Si tout se passe bien, les deux disques virtuels /dev/vg0/le-nom-de-votre-host-swap et /dev/vg0/le-nom-de-votre-host-disk ont ete crees (verification avec la commande lvdisplay) et un joli petit fichier a ete genere dans '''/etc/xen/le-nom-de-votre-host.cfg''' .
+
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'' .<br />
-
 
+
<br />
-
==== Etape 2 ====
+
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 :
-
 
+
-
Voici donc le contenu de mon fichier /etc/xen/le-nom-de-votre-host.cfg genere plus tot et qui a subi de legere petite modification :
+
<pre>
<pre>
-
# cat le-nom-de-votre-host.cfg
+
$ sudo cat /etc/xen-tools/partitions.d/test-server
-
#
+
[root]
-
# Configuration file for the Xen instance le-nom-de-votre-host, created
+
size=1G
-
# by xen-tools 3.9 on Tue Feb 24 11:21:52 2009.
+
type=ext3
-
#
+
mountpoint=/
 +
options=sync,errors=remount-ro
-
#
+
[swap]
-
# Kernel + memory size
+
size=2G
-
#
+
type=swap
-
kernel = '/boot/vmlinuz-2.6.26-1-xen-686'
+
-
ramdisk = '/boot/initrd.img-2.6.26-1-xen-686'
+
-
memory = '64'
+
-
#
+
[home]
-
# Disk device(s).
+
size=1G
-
#
+
type=ext3
-
root = '/dev/sda2 ro'
+
mountpoint=/home
-
disk = [
+
options=nodev,nosuid
-
'phy:/dev/vg0/le-nom-de-votre-host-swap,sda1,w',
+
-
'phy:/dev/vg0/le-nom-de-votre-host-disk,sda2,w',
+
-
]
+
 +
[usr]
 +
size=4G
 +
type=ext3
 +
mountpoint=/usr
 +
options=nodev
-
#
+
[var]
-
# Hostname
+
size=4G
-
#
+
type=ext3
-
name = 'le-nom-de-votre-host'
+
mountpoint=/var
 +
options=nodev,nosuid
-
#
+
[tmp]
-
# Networking
+
size=4G
-
#
+
type=ext3
-
vif = [ 'ip=192.168.0.42,mac=00:16:3E:8C:EB:F0' ]
+
mountpoint=/tmp
-
 
+
options=nodev,nosuid
-
#
+
-
# Behaviour
+
-
#
+
-
on_poweroff = 'destroy'
+
-
on_reboot = 'restart'
+
-
on_crash = 'destroy'
+
-
 
+
-
extra = "console=hvc0"
+
</pre>
</pre>
 +
La commande pour créer le DomU est donc complétée d'une option pour les partitions :
 +
<pre>
 +
$ sudo xen-create-image --hostname=psrv-qg-dmz-0-1 --ip=212.99.45.188 --partition=test-server --memory=1024
 +
</pre>
 +
<br />
 +
<br />
 +
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 :
 +
<pre>
 +
# echo "extra = 'xencons=tty1 clocksource=jiffies'" >> /etc/xen/psrv-qg-dmz-0-1.cfg
 +
</pre>
 +
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.<br />
 +
<br />
 +
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...
-
== Creation "manuelle" de l'image de notre DomU ==
+
== 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.<br />
-
il peut etre utile de creer et configurer soit meme from scratch un DomU : typiquement pour avoir plusieurs partitions par exemple.<br />
+
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. [[Xen#Création_d'un_DomU_avec_les_xen-tools|paragraphe d'avant]]''' ).<br />
-
voici donc la procedure que j'ai utilise pour creer un DomU "sur mesure" !
+
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.<br />
-
 
+
Pas forcément très compliqué, la procédure reste tout de même plus longue que la précedente.<br />
-
=== creation des partitions LVM ===
+
<br />
-
 
+
On souhaite avoir un DomU avec les partitions suivantes :
-
on veut pouvoir retrouver la situation suivante :
+
* / de 1Go
-
* / de 1Go
+
* /boot de 64Mo
* /boot de 64Mo
* /usr de 5Go
* /usr de 5Go
Line 208: Line 349:
* /home de 5Go
* /home de 5Go
* /usr/local de 5Go
* /usr/local de 5Go
-
* un swap de 2Go
+
* un swap de 2Go
-
<br />
+
 
-
Pour cela voici les commandes que j'ai utilise pour creer et formater ces partitions
+
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 [http://doc.ubuntu-fr.org/lvm tuto] permettra de comprendre les lignes de commandes qui suivent :
<pre>
<pre>
lvcreate -n p01 -L 64m vg0
lvcreate -n p01 -L 64m vg0
Line 228: Line 375:
mke2fs -j /dev/vg0/p07
mke2fs -j /dev/vg0/p07
</pre>
</pre>
 +
A ce stade, vous avez donc toutes vos partitions créées et formatées.
-
=== installation du systeme ===
+
=== é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.<br />
-
l'installation du systeme va se faire via debootstrap mais avant il va falloir monter les partitions precedemment creees pour y installer le systeme :
+
<pre>
<pre>
-
# mount /dev/vg0/p03 /data/forinstall
+
$ sudo mkdir /data/forinstall
-
# mkdir /data/forinstall/boot /data/forinstall/usr /data/forinstall/tmp /data/forinstall/var /data/forinstall/boot
+
$ sudo mount /dev/vg0/p03 /data/forinstall
-
# mount /dev/vg0/p01 /data/forinstall/boot/
+
$ sudo mkdir /data/forinstall/boot /data/forinstall/usr /data/forinstall/tmp /data/forinstall/var /data/forinstall/boot
-
# mount /dev/vg0/p04 /data/forinstall/usr/
+
$ sudo mount /dev/vg0/p01 /data/forinstall/boot/
-
# mount /dev/vg0/p05 /data/forinstall/tmp/
+
$ sudo mount /dev/vg0/p04 /data/forinstall/usr/
-
# mount /dev/vg0/p06 /data/forinstall/var/
+
$ sudo mount /dev/vg0/p05 /data/forinstall/tmp/
-
# mount /dev/vg0/p06 /data/forinstall/usr/lost+found/
+
$ sudo mount /dev/vg0/p06 /data/forinstall/var/
-
# mkdir /data/forinstall/usr/local
+
$ sudo mkdir /data/forinstall/usr/local
-
# mount /dev/vg0/p07 /data/forinstall/usr/local/
+
$ sudo mount /dev/vg0/p07 /data/forinstall/usr/local/
-
+
$ df
-
# df
+
Filesystem 1K-blocks Used Available Use% Mounted on
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda5 1921156 174472 1649092 10% /
/dev/sda5 1921156 174472 1649092 10% /
Line 262: Line 408:
/dev/mapper/vg0-p06 51606140 184268 48800432 1% /data/forinstall/var
/dev/mapper/vg0-p06 51606140 184268 48800432 1% /data/forinstall/var
/dev/mapper/vg0-p07 5160576 141436 4756996 3% /data/forinstall/usr/local
/dev/mapper/vg0-p07 5160576 141436 4756996 3% /data/forinstall/usr/local
 +
</pre>
 +
Maintenant on peut lancer l'installation du système dans cette arborescence :
 +
<pre>
 +
$ sudo debootstrap --arch i386 lenny /data/forinstall/ http://ftp.fr.debian.org/debian
 +
</pre>
 +
Puis pour finaliser l'installation :
 +
<pre>
 +
$ 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>
 +
</pre>
 +
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).<br />
 +
<pre>
 +
# 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
</pre>
</pre>
-
== Exploitation du DomU ==
+
Le DomU est donc créé et configuré. Il ne reste plus qu'a démonter toutes les partitions du DomU.
-
Arrive le moment ou il va falloir demarrer le DomU fraichement cree !<br />
+
=== étape 3 : création du fichier de configuration du DomU ===
-
Le processus xend doit tourner et la machine physique (donc celle qui heberge les domU) doit apparaitre en tant que dom0 :
+
Il faut maintenant refaire un fichier de configuration du DomU pour le processus xend.<br />
 +
Créez le fichier ''/etc/xen/psrv-qg-dmz-0-3.cfg'' comme suit :
<pre>
<pre>
-
# xm list
+
#
-
Name ID Mem VCPUs State Time(s)
+
# Kernel + memory size + cpu
-
Domain-0 0 7984 4 r----- 134.7
+
#
 +
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
</pre>
</pre>
-
Maintenant il faut lancer le domU puis le configurer un minimum afin de pouvoir se connecter a lui via SSH :
+
== 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.<br />
 +
Puis pour démarrer une machine virtuelle, il suffit de lancer la commande suivante ''xm create <file>'', par exemple :
<pre>
<pre>
-
# cd /etc/xen && xm create le-nom-de-votre-host.cfg
+
$ sudo xm create /etc/xen/psrv-qg-dmz-0-3.cfg
-
Using config file "./le-nom-de-votre-host.cfg".
+
Using config file "/etc/xen/psrv-qg-dmz-0-3.cfg".
-
Started domain le-nom-de-votre-host
+
Started domain psrv-qg-dmz-0-3
 +
$
</pre>
</pre>
-
 
+
La vérification des DomU activé, se fait ainsi :
-
Ensuite on va se connecter a la console de ce domU :
+
<pre>
<pre>
# xm list
# xm list
Name ID Mem VCPUs State Time(s)
Name ID Mem VCPUs State Time(s)
Domain-0 0 7984 4 r----- 122.1
Domain-0 0 7984 4 r----- 122.1
-
le-nom-de-votre-host 3 64 1 r----- 9.3
+
psrv-qg-dmz-0-3 3 1024 2 -b---- 9.3
-
# xm console le-nom-de-votre-host
+
</pre>
 +
On constate bien que la machine virtuelle psrv-qg-dmz-0-3 est bien démarrée et se trouve dans l'état blocked.<br />
 +
 
 +
=== 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).<br />
 +
Pour avoir accès à la console de la machine virtuelle psrv-qg-dmz-0-3, il suffit de taper la commande suivante :
 +
<pre>
 +
# xm console psrv-qg-dmz-0-3
Debian GNU/Linux 5.0 le-nom-de-votre-host hvc0
Debian GNU/Linux 5.0 le-nom-de-votre-host hvc0
-
le-nom-de-votre-host login:
+
psrv-qg-dmz-0-3 login:
</pre>
</pre>
-
Il ne reste qu'a se logger en root avec le password initialise lors de la creation de l'image, configurer les users, les acces SSH et faire les MAJs et installs souhaitees.<br />
+
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.<br />
-
<br />
+
Pour la suite de l'installation et de la configuration de cette machine virtuelle, il vous faudra suivre les instructions de [[Installation_OS_serveur | la procédure d'installation d'un OS chez Linkeo]].<br />
-
Tel quel il sera impossible de se connecter via SSH a votre domU (pour Debian Lenny !) ! Il faudra en plus faire les operations suivantes :
+
 
 +
 
 +
==== 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 :
<pre>
<pre>
-
#aptitude install udev
+
$ sudo aptitude install udev
...
...
-
#echo "none /dev/pts devpts defaults 0 0" >> /etc/fstab
+
$ sudo echo "none /dev/pts devpts defaults 0 0" >> /etc/fstab
 +
$ sudo mount -a
</pre>
</pre>
-
Sinon a chaque tentative de connexion, il y aura l'erreur suivante : '''PTY allocation request failed on channel 0''' <br />
 
-
Redemarrer le domU depuis le dom0 grace 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 :
<pre>
<pre>
-
xm shutdown le-nom-de-votre-host && xm create le-nom-de-votre-host
+
$ sudo echo "xen.independent_wallclock=1" >> /etc/sysctl.conf
 +
$ sudo sysctl -p
 +
$ sudo echo "jiffies"> /sys/devices/system/clocksource/clocksource0/current_clocksource
</pre>
</pre>
 +
Cette opération ne sera à faire qu'une seule fois !<br />
 +
Explications : http://www.steveglendinning.com/2009/03/23/time-went-backwards/
 +
 +
=== commandes / admin ===
 +
<pre>
 +
# 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
 +
</pre>
 +
 +
== Configuration avancées ==
 +
 +
=== mettre en place le bonding pour les DomU ===
 +
 +
Le bonding des DomU se fait... au niveau du Dom0 ! <br />
 +
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<br />
 +
<br />
 +
On suppose ici que le kernel est bien compilé avec le module de bonding. On peut le vérifier ainsi :
 +
<pre>
 +
$ cat /boot/config-`uname -r` |grep BONDING
 +
CONFIG_BONDING=m
 +
</pre>
 +
La seule chose à faire est de modifier le fichier ''/etc/network/interfaces'' du Dom0 comme suit :
 +
<pre>
 +
$ 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"
 +
</pre>
 +
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
 +
<br />
 +
 +
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 :
 +
<pre>
 +
$ 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 '')
 +
</pre>
 +
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 :
 +
<pre>
 +
$ sudo cat migration-test.cfg | grep vif
 +
vif = [ 'bridge=br0' ]
 +
</pre>
 +
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)<br />
 +
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 :
 +
<pre>
 +
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
 +
</pre>
 +
 +
=== 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 :
 +
<pre>
 +
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
 +
</pre>
 +
== HVM : virtualisation matérielle ==
 +
 +
... à completer ...<br />
 +
 +
=== 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).<br />
 +
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) :<br />
 +
<pre>
 +
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>
 +
</pre>
 +
On continue en créant une partition avec LVM que l'on va utiliser pour représenter le disque "physique" de notre futur DomU.
 +
<pre>
 +
lvcreate -n p11 -L 8g vg0
 +
</pre>
 +
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).<br />
 +
<br />
 +
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 :
 +
<pre>
 +
 +
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 ;)
 +
</pre>
 +
 +
==== étape 2 : installation ====
 +
 +
Une fois le fichier de configuration, on peut lancer la machine virtuelle comme d'habitude :
 +
<pre>
 +
$ sudo xm create /etc/xen/vnotes-hvm.cfg
 +
Using config file "/etc/xen/vnotes-hvm.cfg".
 +
Started domain vnotes-hvm
 +
$
 +
</pre>
 +
Théoriquement comme on est en "pré-installation", le boot se fait sur l'ISO (soit sur le lecteur cd).<br />
 +
Mais comment suivre et poursuivre l'installation ? VNC !!<br />
 +
Vérifiez d'abord qu'un serveur VNC est bien en écoute sur 127.0.0.1:5901 :
 +
<pre>
 +
# netstat -an | grep 5901
 +
tcp 0 0 127.0.0.1:5901 0.0.0.0:* LISTEN
 +
</pre>
 +
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 :
 +
<pre>
 +
[erwan@erwan-laptop -14:34:37- ~]$ ssh -N -T -L 3128:127.0.0.1:5901 erwan@<IP_DOM0>
 +
</pre>
 +
puis il vous suffit de lancer un VNC sur 127.0.0.1:3128.<br />
 +
A ce stade vous pouvez installer votre système comme vous le souhaitez.<br />
 +
 +
==== é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.<br />
 +
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).<br />
 +
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
 +
<pre>
 +
$ 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
 +
</pre>
 +
 +
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
 +
<pre>
 +
$ 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
 +
</pre>
 +
 +
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 ...<br />
 +
<br />
 +
* 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 :
 +
<pre>
 +
$ sudo update-rc.d -f service_name remove
 +
</pre>
 +
<br />
 +
* 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 :
 +
<pre>
 +
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
 +
</pre>
 +
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<br />
 +
<br />
 +
* Démarrage automatique des domU au boot de la machine physique et du dom0 ?<br />
 +
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'' :
 +
<pre>
 +
ln -s /etc/xen/domU-file.cfg /etc/xen/auto/domU-file.cfg
 +
</pre>
 +
 +
==== Migration de machine virtuelle ====
 +
 +
On considère deux types de migrations : les '''migrations live''' et les '''migrations offline'''.<br />
 +
<br />
 +
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 [http://sys-admin.wikidot.com/live-migration-xen celui ci]) expliquent comment réaliser cette manipulation relativement simple si tous les prérequis sont réunis.<br />
 +
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é...<br />
 +
<br />
 +
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 [[Xen#étape_2_:_installation_du_système|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 [[Xen#étape_2_:_installation_du_système|ici]] )
 +
* ensuite il suffit de faire une synchronisation entre les deux Dom0 dans les arborecenses tout juste montées
 +
<br />
 +
Pour faciliter la synchro, il est préférable de configurer sur le Dom0 source un serveur rsync comme suit :
 +
<pre>
 +
$ 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
 +
</pre>
 +
 +
Depuis le Dom0 destination il ne reste qu'a lancer la commande suivante :
 +
 +
<pre>
 +
rsync -av --numeric-ids rsync://<IP_DOM0_SOURCE>/<REPERTOIRE_RSYNC> <POINT_DE_MONTAGE_SUR_DOM0_DESTINATION>
 +
</pre>
 +
* 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.<br />
 +
A noter que cette opération n'est pas possible pour une machine virtuelle en HVM.
 +
 +
==== Supervision ====
-
Et voila
+
Pour faciliter la configuration de La supervision dans Centreon, 2 templates d'hosts ont été créés : Servers-Linux_dom0 et Servers-Linux_domU.<br />
 +
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 ==
== Liens ==
http://www.cl.cam.ac.uk/research/srg/netos/xen/ : site officiel du projet<br />
http://www.cl.cam.ac.uk/research/srg/netos/xen/ : site officiel du projet<br />
http://fr.wikipedia.org/wiki/Xen : presentation de xen<br />
http://fr.wikipedia.org/wiki/Xen : presentation de xen<br />
-
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502798 : lien vers le bug debian pour la console
+
https://bugs.launchpad.net/ubuntu/+source/xen-tools/+bug/139046 : lien expliquant les parades possibles au bug de la console<br />
 +
http://therbelot.free.fr/Xen/ : tuto et généralité sur Xen<br />
 +
http://www.debian-administration.org/users/lters/weblog/14 : faire du bonding sous Xen<br />
 +
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<br />
 +
http://sys-admin.wikidot.com/live-migration-xen : migration live sous Xen<br />
 +
http://doc.ubuntu-fr.org/lvm : tout sur les bases de LVM<br />
 +
http://www.tldp.org/HOWTO/text/LVM-HOWTO : la doc complète sur la démystification de LVM

Current revision

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