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.

C’est en parcourant d’autres blogs à la recherche du chemin que je suis tombé sur l’article de Bryan van Eeden : Where is my private key when using the vSphere UI? – vCloud Vision

Il y décrit, avec la même surprise que moi, la demande de la clé privée mal documenté, et indique la commande pour récupérer le précieux :

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CSR

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.

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.

Cette problématique est décrite dans la kb : Duplicate Multicast or Broadcast Packets are Received by a Virtual Machine When the Interface is Operating in Promiscuous Mode (59235) (vmware.com)

et dans la doc zscaler : Zscaler Help

Pour configurer la valeur

Get-VMHost votrenomESXici | Set-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc" -Value 1

Pour vérifier la valeur

Get-VMHost votrenomESXici | Get-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc"

Pour faire la modification sur tout un cluster par exemple

Get-Cluster votrenomCluster | Get-VMHost |Get-VMHostAdvancedConfiguration -Name "Net.ReversePathFwdCheckPromisc"

Après une installation des plus classiques, j’avais besoin de personnaliser les certificats d’un nouveau vCenter.

Après avoir lancé certificate-manager la procédure s’arrêtait sur le message : Certificate Manager tool do not support vCenter HA systems

Je n’utilise pas vCenter HA donc j’étais très surpris du message, mais après une rapide recherche un post sur le forum VMware m’a apporté la solution -> Cert Manager Tool Not Working / VCSA Web UI Not Ac… – VMware Technology Network VMTN

Je n’ai eu qu’a créer le répertoire manquant avec mkdir /var/tmp/vmware et l’opération se poursuit sans erreur.

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…

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.

Lire la suite de