par ·0 Commentaires

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…

Partager la publication "Échec de Remédiation VMware Update Manager à cause de vSphere Replication"

  • Facebook
  • Twitter

par ·0 Commentaires

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

Partager la publication "VMUG FR"

  • Facebook
  • Twitter

par ·0 Commentaires

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.

Lire la suite de

Partager la publication "VMware vCenter 6.7 : converger vos PSC externes"

  • Facebook
  • Twitter

par ·0 Commentaires

1- libérer le disque

L’intérêt d’un article dédié à l’extension de mon cluster vSAN m’a semblé limité tellement l’opération semble simple: ajouter l’hôte au cluster, puis réclamer les disques afin de les ajouter au cluster vSAN. Mais comme j’ai réutilisé l’un de mes ESXi, j’ai eu quelques petits soucis :

Malgré la réinstallation de l’hyperviseur j’avais encore quelques problèmes et afin d’ajouter des disques à un cluster vSAN, il est indispensable que ceux-ci soient vierges de toutes partitions.

Je pensais m’en sortir rapidement avec quelques lignes de partedUtil

partedUtil getptbl "/vmfs/devices/disks/t10.ATA_____Samsung_SSD _850_EVO_500GB_______________S21JNXBGC05991J_____"

ce qui m’affichait les partitions du disque : 

60801 255 63 976773168
1 64 8191 C12A7328F81F11D2BA4B00A0C93EC93B systemPartition 128
5 8224 520191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
6 520224 1032191 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
7 1032224 1257471 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
8 1257504 1843199 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0
9 1843200 7086079 9D27538040AD11DBBF97000C2911D1B8 vmkDiagnostic 0
2 7086080 15472639 EBD0A0A2B9E5443387C068B6B72699C7 linuxNative 0

puis PartedUtil delete pour supprimer la partition en ajoutant son numéro à la fin : 

partedUtil delete /vmfs/devices/diskst10.ATA_____Samsung_SSD_850_EVO_500GB_______________S21JNXBGC05991J_____ 1

Deux partitions revenaient avec un message d’erreur : 

Error: Read-only file system during write on /dev/disks/t10.ATA_____Samsung_SSD_                                  850_EVO_500GB_______________S21JNXBGC05991J_____

Heureusement ou hélas pour certain, je ne suis le premier à avoir ce problème et un très bon post de la communauté VMware m’a apporté la solution, je vais poursuivre pour les non-anglophones.

Lire la suite de

Partager la publication "Ajout d’un ancien nœud à un cluster vSAN"

  • Facebook
  • Twitter

par ·0 Commentaires

Voici la suite de mon article sur la mise à jour de mon homelab ,qui concernait la partie “matériel” de l’installation que je vous invite à la lire ici.

Pour la partie “logiciel”, j’ai procédé à l’installation de façon classique avec une clé USB comprenant les sources ESXi. Ces boîtiers sont également équipés de lecteur de carte SD mais côté Drivers et boot sur la carte SD ce n’est pas trop ça donc à éviter. Les sources de la version 6.7 VMware-VMvisor-Installer-6.7.0-8169922.x86_64.

Lire la suite de

Partager la publication "Homelab Refresh – Part II"

  • Facebook
  • Twitter