XEN : migration de machines en live

Avec l'installation de la dernière version de Xen l'envie m'est venue de tester la migration d'une Machine Virtuelle d'un serveur à l'autre.
Pour réaliser cette opération il faut :

• Deux serveurs de MV !
• Des installations de XEN "compatibles" (avec les mêmes chemins d'accès aux différentes fonctionnalités de XEN)
  
• Un espace de stockage partagé
  note : le chemin d'accès aux "disques virtuels" doit être identique sur les deux systèmes, si le disque de la machine est accédé par "/REP/XEN.img" ce chemin doit être identique pour les deux serveurs.
• Assez de mémoire libre sur le deuxième système pour "accueillir"  une machine virtuelle supplémentaire.
  
• Une liaison réseau pour le tout, si elle est rapide (1 Gb) celà n'est que mieux
  
• Que les fonctions " xm save " et " xm restore " fonctionnent correctement sur chacune des deux machines.
• Que les processeurs soient compatibles, ici pas de problème tout est en AMD 64 bits.
  

1. Pour les deux serveurs de MV un "simple" emprunt me permet de remplir ce pré-requis.
2. Pour les installations compatibles cela semble OK car l'implantation de la machine "prêtée" (OpenSuse 11.2) est strictement standard, l'autre machine, installée avec les sources de Xensource est au standard.
3. L'espace de stockage partagé est fourni par le NS5200 sur un "folder" ouvert en NFS, les deux machines ont été autorisées sur la boîte miracle.
4. La liaison réseau est fournie par un petit hub 1 Gigabit D-LINK à 8 ports modèle DGS-1008d.
5. Les fonctions " xm save" et " xm restore " ont été testées séparément sur les deux machines et marchent à merveille.

Il faut configurer les deux XEN pour permettre la migration, il faut pour cela modifier le fichier de configuration "/etc/xen/xend-config.sxp" :

• (xend-relocation-server yes)
• (xend-relocation-hosts-allow '192.168.2.20') ou (xend-relocation-hosts-allow '') pour des tests.
• (xend-relocation-port 8002)

Une fois la belle machine prêtée branchée, configurée et connectée au réseau (petite mise à jour de l'adresse de la carte nécessaire) les tests peuvent commencer.
Il faut d'abord assurer l'accès au NS5200 en NFS à la nouvelle machine, les structures de stockages devant être identiques il suffit de créer un nouveau point de montage à le racine du nouveau serveur.
Pour la commodité le serveur prêté (AMD dualcore) sera appelé serveur B, l'autre (AMD quadcore) sera appelé serveur A.
Un petit script permettra de ne pas retaper plusieurs fois la même commande d'accès au serveur NFS.

#!/bin/bash
NS5200='192.168.3.101'
mount -t nfs $NS5200:/raid0/data/Sauvegardes    /THECUS_NFS -o rw

Une machine de test est lancée sur le serveur A, l'exemple utilisé est une machine WIndows XP dont le fichier de configuration est présenté en fichier attaché.
La machine est accédée par le logiciel " rdesktop ".

La suite des opérations est très simple :

• Connecter le montage NFS sur les deux machines
  
• Lancer la machine virtuelle XP sur le serveur A
• Se connecter à la machine XP à l'aide de "rdesktop"
  
• Ouvrir une application (OpenOffice) dans la machine XP
• Lancer la migration de serveur A vers serveur B
• Vérifier dans l'écran "rdesktop" que l'application est bien fonctionnelle sur la MV

Le script de connexion NFS est lancé sur les deux serveurs
Lancer la machine sur le serveur A : xm start com-xp1
Lancer la connexion à la MV : rdesktop -B -P -x -l -g 1024x768 com-xp1
Lancer OpenOffice et ouvrir un document.
Cà marche !

<Image 1 > : la MV est bien active sur le serveur A et invisible sur le serveur B.


Lancer la migration :  xm migrate com-xp1 192.168.3.10

La machine apparaît sur le " xm top " du serveur A et passe en " migrating " sur le " xm top " de serveur B, après environ 20 secondes la machine disparait du serveur A et après une quinzaine de secondes supplémentaires la machine XP est de nouveau parfaitement exploitable dans l'écran rdesktop.
La vitesse de transfert de la mémoire (par le réseau) est d'environ 80 MO/s ce qui explique assez bien le temps de migration pour une taille mémoire de 1536 Mo.

<image 2> La machine est bien affectée au serveur B.


C'est quasiment magique !

Je vais regretter de rendre le deuxième serveur, mais arrêtons de rêver !