Kvm Gestion des VM en cluster

Lorsque les vm sont intégrées dans le cluster, il ne faut plus les gérer avec virsh (car le cluster ne le voit pas ) mais avec clusvcadm. Pour intégrer une vm dans le cluster, le mieux est de ne pas la mettre dans le cluster.conf, de la gérer avec virsh le temps de la finaliser, puis d'éteindre la vm, de l'intégrer dans le cluster.conf, et en reloadant la conf cluster, la vm se mettra toute seule sur le bon noeud. Le nom de la vm ne doit pas dépasser 56 caractères, sinon elle ne pourra pas être mise dans le cluster (kvm ne fera pas d'erreur mais ne la démarrera pas)

Migration automatique après reboot

Lorsqu un noeud reboot ou crash, l autre noeud va récupérer les VM en cluster qui étaient sur le 1er noeud. Mais lorsque le noeud qui a rebooté ou crashé va remonter (avec les services de cluster
associés), les VM vont remigrées toutes seules en se basant sur le cluster.conf. Si l'on ne veut pas que ca arrive, et donc remigrer nous même manuellement les VM, il faut modifier le cluster.conf
pour mettre toutes les VM sur le même noeud

Informations diverses

• Sur les vm il faut que le process acpid tourne, sinon on ne pourra pas les arreter proprement avec la commande virsh shutdown (cela est valable pour des vm hors cluster)
• Dans la config xlm, il faut préciser une option supplémentaire pour que le live migration puisse fonctionner (pour tout les types de disque : classique, swap ou cdrom) : <driver name='qemu' type='raw' cache='none'/>, ne pas avoir de données "locales" (genre un fichier iso qui est monté dans le cdrom et qui n'existe pas sur tous les noeuds)
• Normalement les config xml sont copiés automatiquement lors du live migration (à véfifier), cependant si il n'y pas eu de live migration, et qu'un noeud crash, le kvm va lancer la vm sur l'autre noeud et il lui faudra le fichier xml, à copier donc de préférence manuellement sur tous les noeuds
• Dans la config xml, il faut éviter les éléments locaux (genre un montage d'un fichier iso dans le cdrom), le cas échéant cet élémént doit etre présent au meme endroit sur tous les noeuds
• Lorsque l on met une vm en disable il faut la remettre en enable depuis le kvm qui doit accueillir la vm, sinon c est celui qui la lance qui devient le proprietaire
• Pour ajouter une vm dans le cluster, le mieux est de l'arreter, modifier le cluster.conf et faire une cman_tool -r version
• Pour modifier le xml d une vm dans le cluster il faut l'arreter avec clusvcadm -s, elle sera marquée en stopped dans le clustat, puis la redémarrer avec clusvcadm -R
• Lorsqu'on lance des commande avec clusvcadm il est préférable de le faire sur le noeud qui fait tourner la vm, sinon la vm risque de migrer sur le noeud d'où on lance la commande,

même si la commande n'est pas une commmande de migration

Commandes diverses

• clustat : donne l'état du cluster et des vm
• cman_tool -r version : reload de la conf /etc/cluster/cluster.conf
• Arreter une vm du cluster : clusvcadm -s <nom_service> (nom service correspond au retour de clustat, en général vm:$nomdelavm)
• Démarrer une vm du cluster : clusvcadm -R <nom_service>
• Réallouer un service sur un autre noeud : clusvcadm -r <nom_service> -m <nom_noeud>
• Migrer une VM d'un noeud à l'autre : clusvcadm -M <nom_service> -m <nom_noeud>
• Disable d'un service : clusvcadm -d <nom_service>
• Enable d'un service : clusvcadm -e <nom_service>
• Freeze d'un service (évite la migration d'une vm en attendant) : clusvcadm -Z <nom_service>
• Migration live hors cluster : virsh migrate --live <$nom_vm> qemu+ssh://<$hostname_autre_hyperviseur>/system
• Migration hors cluster avec pause de la VM : virsh migrate --persistent <$nom_vm> qemu+ssh://<$hostname_autre_hyperviseur>/system