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"
J’avais apparemment un problème de synchronisation avec vSphere Replicaton. Le redémarrage des appliances réglait temporairement le problème, mais invariablement le dernier point de synchronisation semblait se bloquer sur toutes les machines au même moment.
Pour une raison inconnue, l’une de nos appliances vSphere Replication était bloquée sur la vérification de nouvelles mises à jour. Malgré un reboot et quelques tentatives de redémarrage de service, rien n’y faisait.
Après une rapide recherche sur Internet et un passage par le forum de la communauté VMware, je suis tombé sur un post de Tim Scheppeit concernant la même problématique sur VCSA. Le support lui a donné la solution suivante et il a eu la gentillesse de la partager.
1. On se connecte en SSH sur l’appliance. Dans mon cas, je me suis connecté en console :
2. /opt/vmware/bin/vamicli update –check (Attention avec la mise en page wordpress c’est bien deux – à la suite)
J’ai juste eu à réaliser cette opération deux fois. La première a simplement débloqué la situation, mais l’update a échoué. Alors que pour la seconde, tout a fonctionné. Après un redémarrage de l’appliance, la nouvelle version était installée.
Cette procédure semble s’appliquer sur beaucoup de produits. Le titre de l’article aurait pu être “mise à jour bloquée sur une appliance VMware”.
Partager la publication "vSphere Replication Appliance stuck checking for available updates"
J’ai eu besoin d’étendre un disque d’une machine virtuelle Windows 2012, répliqué entre deux sites distants, innocemment je pensais en avoir pour quelques secondes, et j’avoue avoir été surpris de constater que l’agrandissement d’une machine protégée avec vSphere Replication n’est pas du tout « user-friendly ».
1re étape : renommer le répertoire de destination de la synchronisation afin d’empêcher vSphere Replication de la détruire lorsque nous stopperons la synchronisation.
2e étape : noter les paramètres de la réplication.
3e étape : supprimer ladite réplication : à noter qu’à l’exécution de l’opération plusieurs erreurs apparaissent, car ils ne retrouvent plus les fichiers à supprimer.
Ci-dessous le message d’erreur qui est très clair, pas d’augmentation à chaud au-delà de 2TB.
5e étape : on attaque un ESXi ayant accès au stockage du replica afin d’augmenter en ligne de commande avec vmkfstools la taille de son disque autant dire que cette partie nécessiterais clairement une amélioration.
J’avais besoin d’augmenter à 8TB la volumétrie du disque et je confirme que le commutateur [tT] pour tera fonctionne malgré qu’il ne soit pas mentionné dans la doc : vmkfstools—X—extendvirtualdisk newSize [kK|mM|gG] .(source Extending a Virtual Disk)
Pour exemple : vmkfstools -X 8T test-VM.vmdk fonctionne. La commande s’exécute sur le vmdk et non sur le -flat.vmdk.
6e étape : Reconfigurer le nom d’origine du répertoire du replica.
7e étape : Reconfigurer la réplication.
8e étape : Si votre extension été supérieur à 2TB, rallumer la VM.
Partager la publication "Extend VM up to 2TB with vSphere Replication"
