Ce serveur vCenter vient d'être mis à niveau vers la mise à jour 5.1. Je passe par des hôtes et je mets à jour le firmware, puis je les mets à jour à partir de différentes versions de 5.0 vers 5.1u1.
vCenter 5.1u1 semble avoir un nouveau comportement intéressant: il supprime les hôtes du mode maintenance lorsqu'ils se reconnectent après avoir été déconnecté - mais de manière très incohérente, je l'ai vu peut-être 4 ou 5 fois lors des redémarrages de l'hôte ~ 25-30. Je ne l'ai vu que sur des hôtes 5.0 qui n'ont pas encore été mis à niveau vers 5.1.
Dans l'image, j'ai placé l'hôte en mode maint et l'ai redémarré en mode de mise à jour automatique du DVD HP SPP. Après son processus de mise à jour habituel de ~ 40 minutes, l'hôte est revenu en ligne .. et 7 secondes avant même d'enregistrer que l'hôte s'était reconnecté, vCenter avait envoyé à l'hôte une tâche pour quitter le mode de maintenance.
À ma connaissance, le seul moment où vCenter doit supprimer un hôte du mode de maintenance est lorsque vCenter le met lui-même en mode de maintenance (comme une tâche de mise à niveau VUM).
Pourquoi ce vCenter quitterait-il unilatéralement un hôte du mode de maintenance initié par l'utilisateur?
Modifier, informations supplémentaires:
J'ai exécuté les mises à niveau du micrologiciel sur 5 hôtes supplémentaires, tous en même temps. Deux d'entre eux ont quitté le mode maint après la reconnexion, trois non. Le facteur commun à ceux qui quittent le mode maint semble être la durée pendant laquelle ils étaient hors ligne ; les deux qui ont mis quelques essais à démarrer sur le média virtuel sont les deux qui ont été mis hors service.
- esx31 (image ci-dessus): 45 minutes sans réponse
- esx19 (sortie maintenue): 87 minutes sans réponse
- esx24 (resté en maintenance): 32 minutes sans réponse
- esx29 (resté en maintenance): 39 minutes sans réponse
- esx32 (resté en maintenance): 30 minutes sans réponse
- esx34 (sortie maintenue): 70 minutes sans réponse
Edit: L'idée du temps de déconnexion semble avoir été un hareng rouge, car cela ne se produit pas de manière cohérente.
De plus , dans l' vpxd.loginitiation de la tâche de sortie, le mode de maintenance semble toujours suivre immédiatement cet vim.EnvironmentBrowser.queryProvisioningPolicyappel SOAP. Voici les lignes, légèrement coupées pour plus de clarté:
15:27:49.535 [info 'vpxdvpxdVmomi'] [ClientAdapterBase::InvokeOnSoap] Invoke done (esx31, vim.EnvironmentBrowser.queryProvisioningPolicy)
15:27:49.560 [info 'commonvpxLro'] [VpxLRO] -- BEGIN task -- esx31 -- HostSystem.exitMaintenanceMode --
Notez que sur les nœuds qui n'obtiennent pas la tâche de sortie, l' vim.EnvironmentBrowser.queryProvisioningPolicyévénement se produit toujours. Je ne vois aucune autre différence dans les événements avant ou après cela dans le processus de reconnexion, à part les événements supplémentaires causés par la sortie du mode de maintenance.
Compte tenu de la mention dans le journal des stratégies de provisioning, la recherche de problèmes de mode de maintenance liés au déploiement automatique fait apparaître des plaintes concernant un comportement similaire (bien que je n'utilise pas du tout le déploiement automatique).
la source
Réponses:
J'ai vu cela se produire avec des hôtes ESXi 4.1 après qu'un correctif ait accidentellement corrompu le dossier / tmp / scratch. Vous souhaiterez peut-être vérifier si ce répertoire existe toujours sur les hôtes qui ont quitté le mode de maintenance automatiquement.
S'ils manquent, vous voudrez mkdir pour le créer. En outre, vous souhaiterez vérifier si le scratch persistant est correctement configuré sur chaque hôte en suivant cet article de la base de connaissances VMware:
VMware KB: création d'un emplacement de travail permanent pour ESXi 4.x et 5.x
la source