J'ai encore des soucis.
Une certaine rigueur m'interdit de mettre en production DRBD et Xen , sans ajouter quelques scripts pour encadrer les migrations…

~~READMORE~~

Pour moi, l’intérêt principal des migrations est d'abord de permettre une maintenance des Dom0 sans impacter les DomU.

Mon parc de serveurs étant assez hétérogène et modeste, je n'ai pas les moyens de tous migrer d'un serveur sur un seul autre.
En effet, lorsque je dois libérer un serveur “Dom0”, je suis contraint de distribuer les “DomU” sur plusieurs serveurs “Dom0”.

Après, ça me pose des problèmes pour savoir où est migré quoi, comment les rapatrier sans en oublier, etc…

Lorsque j'en ai fini avec la maintenance d'un “Dom0”, que ce passe-t-il si je “reboot” ce serveur ?
Et bien, il va essayé de démarrer tout les “DomU” qui sont déclaré dans /etc/xen/auto, y compris ceux qui sont migrés !!!!

Le script “/etc/xen/scripts/drbd” fait un vague test, mais il n'est pas très rigoureux et entraine facilement des cas de “split-brain” !

Ce qui suit suppose que les Dom0 supportent à minima les migrations comme décrit là …

Le script “xen-migrate” :

• Bash: xen-migrate
• Bash/Txt: xen-migrate.txt
• Zippé: xen-migrate.zip

Copier le script dans: /usr/local/bin .

Verifier qu'il est executable, c'est un script bash.

# chmod a+x /usr/local/bin/xen-migrate

Dans /etc/xen/ , créer un fichier nommé migrate-tab.txt .
Dans ce fichier, mettre la liste des “DomU” avec les informations nécessaires a leurs migrations, c'est à dire:

Chaque colonne est séparé par des espaces, à la manière de “/etc/fstab” .

Exemple de fichier:

# -----------------------------------------------
# <domu_name>  <host_name>  <options>
# see: /usr/local/bin/xen-migrate
# -----------------------------------------------
my-domu-1       dom0-alpha      --live
my-domu-2       dom0-beta       --live
my-domu-3       dom0-alpha      --live
# -----------------------------------------------
# EOF

Un autre fichier nommé /etc/xen/migrate-status.txt sera créé automatiquement.

Vous informe de l'état des machines

# xen-migrate status ALL

Migrer une machine:

# xen-migrate migrate my-domu-2

Maintenant, il convient de faire revenir cette machine virtuelle.

La commande a faire est :

# xen-migrate reverse my-domu-2

… mais pour que cette commande fonctionne, il faut configurer aussi le “peer”:

La première fois: Créer des clés SSH spécifique a la migration.

# ssh-keygen -t rsa -b 2048 -f "/root/.ssh/xen-migrate-$( hostname )"

2 fichiers apparaissent dans /root/.ssh/ , par exemple:

xen-migrate-my-dom0.pub
xen-migrate-my-dom0

Maintenant, pour chaque Dom0 vers lequel on souhaite effectuer des migrations “reverse”, procéder comme suit:
Copier la clé publique /root/.ssh/xen-migrate-my-dom0.pub sur le “peer”.

# scp /root/.ssh/xen-migrate-my-dom0.pub dom0-beta:/root/

En passant, copier aussi le script “xen-migrate” dans “/usr/local/bin” du “peer”.

On a fini ici, on va sur le “peer”.

# ssh dom0-beta
.... etc ...

On autorise la clé publique:

# cd /root/.ssh
# cat ../xen-migrate-my-dom0.pub >> authorized_keys
# rm ../xen-migrate-my-dom0.pub

Maintenant, on va apporter quelques modification dans le fichier authorized_keys , sur la dernière ligne qu'on vient de rajouter.

Insérer au début de la ligne (en séparant par un espace):

from="<IP>",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/local/bin/xen-migrate migrate2"

Remplacer “<IP>” par l'adresse IP de la source. (l'initiateur de la migration qui va ordonner le “reverse”).

Exemple:

from="192.168.1.23",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/local/bin/xen-migrate migrate2" ssh-rsa AA...snip...Q== root@my-dom0

Que va-t-il se passer ? Explication:

Lorsqu'on voudra faire revenir une machine virtuelle avec la commande “reverse”, le script “xen-migrate” s'appuiera sur “ssh” pour contacter le peer.
La clé utilisé est spécifique à la migration, et une commande y est associé, cette commande est: “/usr/local/bin/xen-migrate migrate2” .

Lorsque cette commande est utilisée (suivit de paramètres dont vous n'avez pas a vous préoccuper ici), elle va effectuer divers tests puis migrer la machine virtuelle.

Pour tester que le “reverse” est possible sans migrer aucune machine, il suffit de taper “xen-migrate ping <host-name>” .

… où “<host-name>” est l'adresse/nom du Dom0 à tester.

Exemple:

# xen-migrate ping cloud2
PING from cloud1.local.eez.fr ...
PONG from cloud2.local.eez.fr ...
Success.

Le problème du “reboot” est un peu plus complexe, surtout sans “xen-migrate” installé (ce qui est possible).

Le script “xen-drbd-auto” :

• Bash: xen-drbd-auto
• Bash/Txt: xen-drbd-auto.txt
• Zippé: xen-drbd-auto.zip

Copier “xen-drbd-auto” dans “/etc/init.d/”

Vérifier qu'il est executable, sinon faire:

# chmod a+x /etc/init.d/xen-drbd-auto

Installer le script en service:

# update-rc.d xen-drbd-auto defaults

Là où les configurations de DomU avec “drbd” sont placé dans “/etc/xen/auto”, déplacé les plutôt dans le nouveau répertoire “/etc/xen/drbd-auto/” .

Et enfin:

# /etc/init.d/xen-drbd-auto start

Que va-t-il se passer ?

Pour chaque “domu” dont la configuration est dans “/etc/xen/drbd-auto”:

1. Vérifier que le domu n'existe pas déjà
2. Si “xen-migrate” est installé: Regarder si le domu a été migré ou pas (si oui: il ne fait rien)
3. Regarder l'état des ressources “drbd”

Si l'état de tout les disks DRBD sont (commande “drbdadm role <resource>”) :

Dans ce dernier cas, “Autres”, alors le démarrage du “DomU” est juste reporté à plus tard, en tâche de fond !

COMPRENDRE: Le DomU sera démarré dès que les ressources “drbd” seront dans un état reconnu.

Arrêter les tâche de fond qui guettent le changement d'état des ressources “drbd”.

Retourne l’état des traitements.

Le message “daemon gone” signifie juste qu'il n'y a aucune tâche de fond associé, et que tout va bien.

Forcer les tâches de fond a ré-vérifier immédiatement l'état des ressources “drbd”.

Sinon, c'est toutes les 5 minutes (a plus ou moins 60 secondes) qu'il y a une vérification.

Voila.