Mise à jour ESXi 6.7 vers 8.0 - Correction d'un crash du serveur de production

Vérifiez d'abord la compatibilité matérielle

ESXi 6.7 a atteint la fin du support général le 15 octobre 2022, ce changement est donc attendu depuis longtemps, mais la version 6.7 vers 8.0 est une mise à niveau de version majeure, pas un correctif. Entre les deux versions, VMware a entièrement supprimé le modèle de pilote VMKLinux (chaque périphérique a désormais besoin d'un pilote natif) et a retiré une génération de processeurs, d'adaptateurs réseau et de contrôleurs de stockage. Un hôte 6.7 parfaitement sain peut toujours ne pas pouvoir être mis à niveau tel quel.

Avant de réserver une fenêtre, consultez le Guide de compatibilité VMware pour connaître votre modèle de serveur exact, votre famille de processeurs, vos adaptateurs réseau et votre contrôleur de stockage par rapport à ESXi 8.0, et mettez à jour le micrologiciel du serveur (BIOS, contrôleur de stockage, cartes réseau) vers les versions répertoriées par le fournisseur pour 8.0. La propre vérification préalable de l'installateur met également en garde contre les appareils obsolètes, mais le découvrir sur la console à minuit n'est pas le bon moment. Vérifiez d'abord sur papier.

Sauvegarder la configuration de l'hôte et les machines virtuelles

Sauvegardez la configuration de l'hôte à partir du shell de l'hôte (activez d'abord SSH sur l'hôte s'il est désactivé). La commande renvoie un lien de téléchargement pour le bundle de configuration : ouvrez-le et enregistrez le fichier .tgz quelque part qui ne se trouve pas sur ce serveur :

vim-cmd hostsvc/firmware/backup_config

Vérifiez ensuite que les sauvegardes de la VM sont à jour et qu'au moins une restauration a effectivement été testée. La moitié de tous les écrans violets post-mise à niveau remontent au micrologiciel toléré par l’ancien hyperviseur – mais les plantages que vous ne pouvez pas annuler sont ceux sans sauvegarde derrière eux.

Planifiez la fenêtre et gardez la clé de licence 8.0 prête

Choisissez un emplacement de maintenance et annoncez-le aux utilisateurs : personne ne devrait être en train de sauvegarder lorsque l'hôte tombe en panne. Notez la séquence avec les heures et définissez un délai de restauration ferme : le moment de la nuit après lequel vous arrêtez le débogage et effectuez une restauration (étape 7) au lieu de manger toute la fenêtre. Envoyez un message de clôture lorsque le travail est terminé, afin que le lendemain matin ne commence pas par des rumeurs.

Triez la licence avant la fenêtre, pas pendant celle-ci. Les clés de licence sont liées à la version majeure : un hôte 8.0 n'acceptera pas de clé 6.7 et sans clé, il fonctionne en mode d'évaluation pendant 60 jours. Sous Broadcom, les clés et les téléchargements proviennent du portail d'assistance Broadcom et correspondent à vos droits, alors organisez cet accès à l'avance.

Route A - Mise à niveau en démarrant l'ISO 8.0

Informez les utilisateurs, puis mettez l'hôte en mode maintenance : chaque VM s'arrête ou migre vers un autre hôte. Ne mettez jamais à niveau un hôte qui exécute toujours des machines virtuelles de production.

Démarrez le programme d'installation d'ESXi 8.0 à partir de l'ISO, sélectionnez le disque qui contient l'installation existante et choisissez Mettre à niveau ESXi, préserver la banque de données VMFS. C'est l'itinéraire affiché sur la plupart des serveurs, et celui qui gère proprement un saut de version importante car les pré-vérifications apparaissent à l'écran au fur et à mesure.

Route B – Mise à niveau depuis le Shell avec esxcli

La route du dépôt s'exécute entièrement à partir du shell hôte (sans support physique ou virtuel), ce qui en fait le choix pratique pour un hôte distant. L'hôte passe toujours en mode maintenance en premier, exactement comme dans la route A. Autorisez le client HTTP à traverser le pare-feu de l'hôte :

esxcli network firewall ruleset set -e true -r httpClient

Répertoriez les profils disponibles dans le dépôt en ligne de VMware et notez le nom exact du profil standard 8.0 :

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Exécutez ensuite la mise à jour du profil sur le dépôt, en utilisant ce nom de profil exact, et redémarrez l'hôte une fois l'opération terminée :

esxcli software profile update -d <depot-url> -p <exact-profile-name>

La même route fonctionne hors ligne : copiez le ZIP du bundle de dépôt dans une banque de données et pointez la valeur -d sur ce fichier à la place. Notez que profile update est la commande de mise à niveau : elle conserve votre configuration existante et les VIB tiers là où ils sont compatibles ; ne remplacez pas profile install, qui remplace l'image.

Après le redémarrage : licence, vérification, puis libération

Une fois l'hôte sauvegardé sur 8.0, appliquez votre clé de licence ESXi 8.0 : la clé 6.7 n'est pas acceptée et sans la nouvelle clé, le temps d'évaluation tourne. Quittez le mode maintenance, puis démarrez d'abord une VM non critique et vérifiez son réseau, son stockage et sa console avant de démarrer les autres.

Travaillez ensuite sur l'hôte lui-même : le journal des événements et l'état du matériel pour les plaintes de pilotes ou de capteurs, chaque banque de données montée et les paramètres du réseau de gestion intacts. Ensuite seulement, libérez le serveur aux utilisateurs et envoyez le message de clôture de l'étape 3.

Le Crash Playbook – Écran violet et restauration Shift+R

Si l'hôte affiche des écrans violets (PSOD) ou ne démarre pas utilement après la mise à niveau, travaillez dans cet ordre. Tout d'abord, photographiez l'écran violet avant de toucher quoi que ce soit. Un PSOD est le fait que VMkernel s'arrête délibérément parce que continuer mettrait en danger les machines virtuelles — et l'écran est le diagnostic : le type d'exception et le module qui y est nommé indiquent la cause, avec un nom de module de pilote indiquant un problème de support matériel et une erreur de page pointant vers la mémoire ou le micrologiciel.

Deuxièmement, redémarrez une fois et regardez. Un seul écran violet transitoire après un changement de pilote correspond aux données ; une répétition est un verdict. Les premiers suspects, dans l'ordre de la mise à niveau : une carte réseau ou un adaptateur de stockage non pris en charge, un micrologiciel plus ancien que celui répertorié dans le guide de compatibilité ou une erreur de mémoire sur laquelle l'ancienne version n'a jamais souligné.

Troisièmement, revenez en arrière. ESXi s'installe dans deux banques de démarrage et la mise à niveau laisse votre version 6.7 précédente intacte dans la banque alternative. Redémarrez l'hôte et, à l'invite de démarrage, appuyez sur Shift + R et confirmez : l'hôte démarre la version 6.7 précédente, configuration incluse, exactement comme vous l'avez laissé. Si la restauration fonctionne, vous avez gagné du temps : corrigez la cause de compatibilité à la lumière du jour et effectuez à nouveau la mise à niveau dans une nouvelle fenêtre.

vim-cmd hostsvc/firmware/restore_config <bundle-path>

Cette commande de restauration est la deuxième voie d'évacuation : elle remet la configuration d'hôte du bundle de l'étape 2 sur un hôte de même version et build, pour les cas où une seule banque de démarrage ne suffit pas.