Suite à la consolidation de plusieurs clusters VMware, nous avons modifié en masse plusieurs dizaines de volumes afin de les présenter en respectant notre nouvelle organisation.
Après cette modification, 2 datastores (un par baie) sont passés inaccessibles, en lieu de place de ceux-ci, je me retrouvais avec un volume étrange de quelques Ko. L’administrateur du stockage m’assurait ne pas me présenter une autre volume.
Après plusieurs heures de recherches infructueuses : APD, hôte qui aurait verrouillé l’ancien volume, VMFS corrompu, mauvaise mapping SAN…
Il s’avère que le persona VMware HPE (VMware host persona 11), est compatible avec VMware vVols sans intervention particulière, mais il se réserve le LUN ID 256 pour faire fonctionner le “Protocol Endpoint” (PE), qui est un LUN technique qui permet de gérer les I/O :
Il faut savoir que sur ce type de baie 3PAR et j’imagine d’autres modèles du même vendeur, il ne faut en aucun cas utiliser le LUN ID 256. Sur d’autres modèles de SAN, compatible vVols il faudra se renseigner sur le LUN ID associé au PE.
Le support HPE a confirmé qu’il n’est pas possible de désactiver ce LUN.
Une fois l’ID de nos volumes en erreur modifié , un simple rescan pour monter les volumes VMFS et tout est rentré dans l’ordre.
Si vous rencontrez ce message d’erreur sur vos ESXi, vous utilisez sûrement vSphere Replication. Habituellement, les journaux d’événements des ESXi sont remplis d’événements “User root@127.0.0.1 logged in as hbr-agent” ou en français “L’utilisateur root@127.0.0.1 est connecté en tant que hbr-agent”.
J’ai récemment été contraint d’activer le lockdown mode. C’est une fonctionnalité de verrouillage qui permet d’éviter les interactions directes avec l’ESXi et ne permet son administration qu’au travers du vCenter.
Cet article de VMware détaille bien mieux que moi le fonctionnement des deux modes de verrouillage.
Mais vous l’aurez compris, vSphere Replication ne semble pas vouloir utiliser le vCenter et se connecter directement en root sur les ESXi.
Ajouter le root en exception, comme on me l’a proposé, équivaut pour moi à l’annulation du lockdown mode.
Après des semaines de bataille avec le Global Support Services, où ils m’étaient en cause des vibs HPe présentent sur les builds, le ticket est maintenant escaladé auprès des développeurs.
Je suis pour ma part assez surpris d’en arriver là. L’utilisation conjointe de vSphere Replication et Lockdown mode doit vraiment être exceptionnelle pour que le “bug” ne remonte que maintenant au dev. D’autant plus que j’utilise vSphere Replication depuis des années et l’utilisation du compte root me semble présent dans son ADN depuis un moment.
N’étant pas particulièrement fan du lockdown mode, j’ai prévenu le support qu’une simple déclaration officielle incompatibilité avec vSphere Replication m’irait très bien. Je mettrais à jour cet article lorsque j’aurais du nouveau. En attendant, j’ai temporairement une exception pour la désactivation de cette fonctionnalité.
Update 1er Septembre du GSS : “There is no impact to replication jobs with lockdown mode enabled. It will cause extra logging in vCenter. No workaround at present for the extra logging. Recommendation is to disable Lockdown mode”.
Partager la publication "Cannot login user @127.0.0.1: no permission – Connexion impossible pour l’utilisateur @127.0.0.1: aucune autorisation"
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 ?
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.
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…
Partager la publication "Échec de Remédiation VMware Update Manager à cause de vSphere Replication"
Mais le VMUG qu’est-ce que c’est ? Derrière ces initiales se cache le VMware User Group, autrement dit, le groupe des utilisateurs VMware. Historiquement, les membres se retrouvaient sur un forum où chacun était libre de poser ses questions. C’est vrai que les forums ne sont plus trop tendances et que VMware a bien centralisé les choses avec VMware Technology Network (VMTN) en intégrant un forum énorme, très bien référencé par Google, qui permet généralement de s’en sortir lorsqu’on rencontre un problème.
Pas besoin d’être un expert ! Le VMUG est ouvert à tous. L’important c’est de partager autour des technologies et de l’écosystème VMware.
Suite à la migration de nos vCenters 6.5.x vers 6.7.x, la topologie supportée et recommandée par VMware consiste à intégrer le Platform Services Controller (PSC) au vCenter Server Appliance (VCSA), même en Enhanced Linked mode (ELM). Autant dire que j’étais content de diviser par deux les infras. Voici, un peu en vrac, les petits soucis que j’ai rencontrés pour ces opérations.
