VMware – Page 3

vSAN : Rechercher un disque

La lecture du titre de ce post vous laisse dubitatif avouez le 🙂 .

Dernièrement nous avons dù identifier physiquemebt un disque (au sein d’un disque group) qui rencontrait de grosses latences (entre 15000 ms et 45000 ms), un remplacement rapide s’imposait donc.

Le problème est que nous avons pu identifier le disque au sein du disque groupe via son naa, mais comment l’identifier physiquement sur l’ESXi (serveur CISCO UCS-C240-M4SX) ? Dans UCS Central aucune alarme ne remontait côté disque (normal il n’y a pas de problème hardware vous nous direz) et en ESXCLI on ne remonte pas d’informations de type PID permettant de faire le lien entre le naa. et le disque dans UCS. Dans le Vcenter, sur l’ESXi dans l’onglet “Configure” – “Storage-Storage Device” vous avez un bouton qui permet (logiquement) d’allumer la led d’un disque selectionné (le fameux “turn on ou turn off disk locator”), mais dans notre cas cela ne fonctionnait pas.

En googlelant nous sommes tombés sur la commande ci-dessous qui permet d’allumer (ou clignoter) la led d’un disque.

esxcli storage core device set -d naa.50000397885347bd -l=locator -L=600

Après avoir trouver une âme charitable dans le Datacenter, le collègue a pu nous donner la position du disque dans le serveur en vue de son prochain remplacement.

vSAN : Supprimer un objet dans le “Resyncing Component”

Dans un Vcenter 6.5.0 (build 5318154) au sein d’un cluster vSAN (version : 6.6) nous avons remarqué la présence d’un objet orphelin dans l’onglet “Resyncing Components”.

L’objet avait été supprimé il y a quelque temps, mais visiblement vSAN ne l’entend pas de cette oreille 🙂

Nous avons constaté que le vSAN Health était en jaune en GUI et via la commande ci-dessous.

esxcli vsan health list

Le problème en l’état, c’est que nous ne connaissons pas l’objet récalcitrant, afin de le retrouver nous avons lancé la commande ci-dessous.

esxcli vsan debug resync list

Voila notre objet est désormais identifié.

Afin de supprimer un objet récalcitrant il existe une commande qui permet de supprimer des objets, cependant cette commande est à utiliser avec parcimonie 😉 .

/usr/lib/vmware/osfs/bin/objtool delete "your object" -f -v 10

Et là, mauvaise nouvelle, la commande se termine par un failed 🙁 .

Du coup on décide de lancer les commandes ci-dessous au cas où.

esxcli vsan debug resync list

esxcli vsan health cluster list

Et voila tout est en green, la commande objtool a visiblement quand même fait un petit nettoyage 🙂

Vcenter error : esx.problem.hyperthreading.unmitigated

Si comme nous, vous rencontrez l’erreur “esx.problem.hyperthreading.unmitigated” sur un host ESXi dans votre Vcenter (dans notre cas un Vcenter 6.5) après l’application de patch, alors là KB57374 va vous aider a supprimer rapidement cette erreur et à comprendre son origine.

On va quand même pas désactiver l’hyperthreading quand même 🙂

Comme l’explique la KB57374, il suffit de forcer la valeur “UserVars.SuppressHyperthreadWarning” à 1 afin de supprimer ce message dans les options avancées (Onglet Configure, puis aller dans System-Advanced System Settings) de l’ESXi, mais comme on est sympa on vous donne aussi la version en CLI.

Get-VMHost MyESXi | Get-AdvancedSetting -Name 'UserVars.SuppressHyperthreadWarning' | Set-AdvancedSetting -Value 1

ESXi 6.5: Erreur lors de l’installation

Lors de l’instalation d’un ESXi 6.5 (sur un Cisco UCS C220 M5) nous avons rencontré l’erreur ci-dessous (hé oui on ne fait pas que du Citrixm 🙂 .

partedUtil failed with message: b”Error: Can’t have a partition outside the disk!nUnable to read partition table for device /vmfs/devices/disk/eui.00a0504658335330\n\n”.

En googlelant nous sommes tombés sur la KB2082806, ce qui nous a amené à faire un Erase du Virtual Drive via la CIMC (Cisco Integrated Management Controller) du server.

Selectionnez le Virtual Drive puis cliquez sur le bouton “Erase Virutal Divre”

Une fois l’erase du “Virtual Drive” réalisé, l’installation a pu être réalisée sans problème.