Echec de Live Migration au sein d’un cluster Hyper-V 2

Après avoir installé votre cluster hyper-v et créé votre première VM, vous avez peut-être été confrontés à un échec lors de migration d’un hôte vers l’autre.
Une des erreurs couramment commise, est de configurer la VM au travers du Snap-in Hyper-V manager et non d’utiliser le Snap-in Fail Over Cluster Manager. Si tel est le cas vous constaterez lors de vos tentatives de migration l’apparition de l’événement ID 32 :

Cela est dû au fait que la configuration n’a pas été propagée sur l’autre noeud la configuration réseau de cette VM.
Voici comment corriger ce problème:
Lancer le Fail Over Cluster Manager, et se positionner sur la VM en question.
Dans le panneau action, cliquez sur settings :

Effectuez vos modifications au sein de la configuration de votre VM:
 

Puis rafraichissez la configuration de la VM au sein du cluster:

Enfin relancez votre migration:

La migration s’effectue maintenant normalement.

Il faut donc retenir que si vous n’utilisez pas SCVMM, il est impératif de modifier les caractéristiques ainsi que les connexions réseau de vos VM au travers de l’interface cluster.
Et en cas de bêtises rafraichissez la configuration au sein du module cluster, tout devrait rentrer dans l’ordre !

 

2 thoughts on “Echec de Live Migration au sein d’un cluster Hyper-V

  1. Reply Tom Mai 17,2013 10:11

    Bonjour,
    Je m’y perd un peu dans les configuration de cluster sous 2012.
    Je suis en labo de test pré prod.

    Si nous créons les VMS sur le cluster, elle sont hautement disponibles et basculent d’un noeuds à l’autre en cas de défaillance d’un des deux hyperV ( vms présentent sur un san)? Il n’est pas question de live migration dans cette configuration? Y’a t-il une solution moins gourmande en ressources (il faut quand même deux gros serveurs )?

    Un grand merci d’avance.

    Cdt

  2. Reply Vecteur Informatique Mai 17,2013 20:24

    Live migration permet de déplacer au sein d’un cluster Windows 2012 une machine virtuelle d’un nœud vers l’autre sans avoir de rupture de service. Cette fonction est disponible par défaut et est utilisée notamment lorsque l’on veux arrêter un nœud pour faire une maintenance.
    En revanche en cas de crash d’un nœud, les VM qui étaient en cours d’exécution, redémarreront sur le nœud restant mais les process qui étaient en cours de traitement seront perdus…

Leave a Reply to Tom