Une belle journée pour casser VMWare HA !

EDIT 17h56: quelques petites précisions à la demande générale, en fin d’article (merci pour les retours par mail !)

Préparation de la migration vSphere 6 oblige, j’avais programmé pour aujourd’hui même une petite maintenance de santé sur notre vCenter 5.5 update 2 pour le faire passer à la dernière version en date, vCenter 5.5 update 3b. Jusque là, rien de bien compliqué. Et pourtant, le diable se cache dans les détails, bien sûr…

Habituellement, toutes les mises à jours de notre vCenter de production sont précédées par une mise à jour de notre vCenter “bac à sable”, afin de pouvoir essuyer les plâtres éventuels avant le “grand saut” en production. Or, nous sommes dans une situation intermédiaire ou notre bac à sable est en vCenter 6 (pour la qualif correspondante) et notre vCenter de production en 5.5. Résultat, pas vraiment le choix, sauf à reconstruire entièrement un troisième environnement (hors de notre portée financière et JH). Vous me voyez venir sans doute, je me suis dit : BOOOOARF ! On en a fait des dizaines de mises à jour mineures sur 5.5, on n’a jamais eu de problème majeur. Allons-y donc directement sur notre production, tout en lisant précisément les release notes, les pré-requis et les problèmes potentiels documentés. Oui mais non.

C’était sans compter sur les facéties de vCenter !

Me voila donc lancé dans l’update vCenter 5.5u2 vers u3b. Toute la procédure elle-même s’est très bien passée. A l’issue, vCenter se relance normalement, ainsi que ses services compagnons (Inventory Services, Web services, Profile-driven Storage etc. …). Je me reconnecte donc sur le serveur… et là, je constate ça :

Boooooonn, restons calme. Que s’est-il passé ?!

Je vous passe la période habituelle de sidération et les premiers tests. En fait vCenter a réalisé une mise à jour des services “vCenter/HA” sur une majorité de machines. Jusque là, pas de souci, c’est souvent le cas lors d’une maintenance de ce type, sauf qu’en règle générale, ces mises à jour de packages ne nécessitent pas de reboot. Et bien, il se trouve que pour une raison encore indéterminée et liée, sans doute, aux versions installées précédemment sur les machines, cette dernière mouture VMware_bootbank_vmware-fdm_5.5.0-3252642 impose un reboot de l’ESXi pour être correctement démarrée. Pour votre info, la précédente version désinstallée sur les machines en erreur était la VMware_bootbank_vmware-fdm_5.5.0-2001466.

La conséquence directe de ce mode “dégradé” de la communication entre vCenter et son agent ESXi c’est que toutes les fonctions HA sont en erreur :

Voici le log /var/run/log/install-fdm.log qui présente la cause “reboot required” à l’origine de cet état bien dégradé :

Les machines affectées par ce problème fonctionnent encore très bien pour le service VM, cependant, d’après ce que j’ai constaté, seule la fonction HA est défaillante. Même si vous tentez de reconfigurer chaque ESXi pour HA (avec la fonction ad-hoc dans le menu contextuel “clic-droit” sur le serveur), le vCenter va tenter de réinstaller l’agent (apparamment avec succès) et ensuite tester son fonctionnement. Ça se traduit de cette manière sur les logs :

… le vCenter vérifie ensuite pendant quelques dizaines de secondes si l’agent en question fonctionne …

… puis se plante avec une erreur un peu générique. Au final, les serveurs concernés ont une double alerte de ce type :

Au final, nous devons donc redémarrer chaque hyperviseur en erreur (environ une trentaine en tout …) afin de récupérer nos fonctions HA et une production dans un état nominal. Belle journée à tous !