Les plus attentifs d’entre vous aurons noté que j’ai récemment fait un billet sur l’utilisation de l’outil certificate-manager en ligne de commande. Mais il s’avère que mon CSR n’avait pas le niveau de sécurité requis et je n’ai pas trouvé l’option pour modifier la taille de la clé.
il y a bien le fichier certool.cfg pour modifier la configuration mais rien ne semble documenter la longueur de la clé. J’aurai simplement pu générer ma demande avec openssl, mais j’avais la ferme intention d’utiliser les produits mis à disposition par VMware.
Je suis donc partie sur l’utilisation de la GUI pour réaliser l’opération car le changement de la taille de la clé y est accessible:
La génération du csr se passe très bien, mais les soucis apparaissent à l’importation:
En effet, l’assistant nous demande de lui fournir la clé privée générée lors de notre demande de csr, sauf qu’à aucun moment, il ne nous indique le chemin en question. Impossible de trouver le chemin dans la documentation officielle VMware.
Copier les informations avec —–BEGIN CERTIFICATE REQUEST—– et —–END CERTIFICATE REQUEST—– dans un fichier et vous pourrez l’utiliser pour l’importation, ou copier les directement dans le menu VMware dans la section Private Key :
Pour la section « Chain of trusted root certificates » copier les informations du certificat de l’autorité de certification ou de la chaine complète qui a signé la demande.
Après redémarrage des services, le certificat devrait correctement en place.
Partager la publication "VMware Import and Generate certificate"
Si comme moi vous avez des appliances ZIA Virtual Service Edges à déployer sur des clusters VMware, vous aurez peut être un paramètre bien particulier à configurer pour éviter de recevoir les paquets réseau en double lorsque vous avez plusieurs interfaces physique sur votre vSwitch mais pas de LCAP pour le teaming.
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.
