Nous n’arrivions pas à faire de remédiation d’un hôte ESXi, il fallait forcément le passer en maintenance “manuellement” avant, ce qui est fort peu pratique quand il y a plusieurs dizaines d’ESXi à mettre à jour.
La remédiation échouait avec les messages “Another Task is already in progress / Une autre tâche est déjà en cours.” et “The task failed because another task is currently in prgress. Either your task, the task that is in progress, or both tasks require exclusive execution. / La tâche a échoué car une autre tâche est actuellement en cours d’exécution. Votre tâche, la tâche qui est en cours d’exécution ou les deux tâches nécessitent une exécution exclusive”.
Dans les logs, on constate effectivement deux taches lancées en même temps par 2 composants :
La tache en erreur de com.vmware.vcIntegrity correspond à VMware Update Manager, com.vmware.vcHms correspond à vSphere Replication, mais pourquoi lancent-ils une tache en même temps ?
message du /var/log/esxupdate.log :
2020-01-15T14:08:31Z esxupdate: 4185081: esxupdate: ERROR: wmware.esximage.Errors.VibDownloadError: ('https://IP:8043/vib/vmware-hbr-agent.vib', None, '(\'https://IP:8043/vib/vmware-hbr-agent.vib\', \'/tmp/vibtransaction/tmp.vib\', \'[Errno 14] curl#56 - "Content-Length: in 200 response"\')')^@
Plusieurs KB VMware font référence à ce type de message d’erreurs, pas exactement pour le même problème, alors je prends contact avec le GSS VMware.
Ils m’indiquent que les deux seuls problèmes connus avec ce message sont référencés dans les KB vSphere replication 8.2. ESXi unable to download hbr-agent.vib “VibDownloadError” (75321) et ESXi hosts report vib errors after installing VMware vSphere Replication 5.6.x or later (2110304)
En premier lieu, nous vérifions la présence des vibs sur les ESXi
localcli software vib list | egrep -i "vr2c|hbr"
localcli software vib get | egrep -i "vr2c|hbr"
Les vibs sont bien installées, le workaround consiste à désactiver l’option d’installation automatique des vibs de vSphere Replication afin de ne plus entrer en conflit avec Update Manager, ce qui aura comme conséquence de devoir installer ces vibs “manuellement” sur les nouveaux ESXi.
Sur les appliances vSphere Replication le ssh n’est pas activé par défaut, ce que je m’empresse de faire à l’aide du script /usr/bin/enable-sshd.sh disponible en console cf: Unable to Establish an SSH Connection to the vSphere Replication Appliance
Je vérifie ensuite le paramètre hms-auto-install sur l’appliance en SSH
/opt/vmware/hms/bin/hms-configtool -cmd list | grep -i hms-auto-install-hbragent
Le retour est bien :
hms-auto-install-hbragent-vib = true
Je modifie la valeur :
/opt/vmware/hms/bin/hms-configtool -cmd reconfig -property hms-auto-install-hbragent-vib=false
Puis, je relance le service :
service hms restart
Après ces opérations, je lance une remédiation sur un des ESXi et l’opération de patching se passe correctement.
Je ne suis pas pleinement satisfait, car même si le patching se déroule normalement, des opérations supplémentaires sont à prévoir à l’installation de nouveau nœud, mais je vous indique une partie de la réponse du support à ce sujet : “There is no projected fix for this issue presently. Engineering are only providing us with the VR vib ‘auto-install’ disable option.
New hosts added to the cluster require a manual vib install or you can include the vib in a VUM baseline.”
J’essaye donc d’appliquer cette dernière recommandation et de créer une nouvelle baseline avec les vibs en suivant la KB75321.
Après récupération des vibs comme dans la procédure, j’essaye d’importer celle-ci dans Update Manager, mais j’ai un message d’erreur :
Il s’avère que le fichier fourni ne permet pas l’importation dans VMware Update Manager, il sert uniquement à l’installation sur l’ESXi. Le support est au courant et m’a confirmé qu’il n’y aurait pas d’autre workaround pour ce problème et m’a même conseillé de soumettre une feature request… Ce n’est pas une feature que d’avoir les deux produits qui fonctionnent “normalement” dans son infrastructure…
