VxRail : Dépannage des problèmes liés à VxVerify avant une mise à niveau de VxRail

Cet article de la base de connaissances est consacré au dépannage des problèmes qui empêchent VxVerify de s’exécuter correctement.

Cet article de la base de connaissances est référencé à partir de tests qui n’ont pas d’article ciblé pour leur réponse appropriée (par exemple : Avertissement, Échec et Critique). Par exemple, une requête qui renvoie une réponse inattendue d’une requête.

VxVerify est conçu pour détecter les problèmes susceptibles de provoquer des complications ou des défaillances lors des mises à niveau de VxRail. VxVerify crée des programmes Python appelés Minions, qui sont envoyés aux nœuds VxRail. Vous trouverez ci-dessous les résultats de test typiques auxquels vous devez vous attendre dans vxverify_tests.json:

Si un résultat de test faussement positif est détecté, rassemblez les logs VxVerify et contactez le support Dell pour ouvrir un ticket Jira VXV auprès des ingénieurs VxRail.

Plusieurs causes peuvent empêcher VxVerify de s’exécuter correctement.

• La cause la plus fréquente d’échecs est l’expiration du script Python. Chaque version de VxVerify est configurée pour ne durer que deux semaines à compter de sa date de publication. Cela ne s'applique pas lorsque VxVerify est exécuté en tant que plug-in dans le cadre du bilan de santé VxRail (qui modifie la fonctionnalité VxVerify).
• D’autres raisons peuvent être des problèmes d’autorisations sur VxRail Manager ou des problèmes de communication avec les hôtes.
• Si la cause de l’événement n’est pas claire, contactez le support Dell pour ouvrir un ticket VXV auprès des ingénieurs VxRail.

La section ci-dessous fournit des instructions sur la collecte des logs et le dépannage si VxVerify ne s’exécute pas correctement.

Collecte de journaux pour l’engagement du support

Lorsque vous contactez le support pour des problèmes liés à VxVerify, téléchargez l’intégralité des fichiers archivés vxv pour l’analyse, ou le dossier vxverify rapport .zip . Les versions VxVerify autonomes actuelles enregistrent un fichier archivé dans /tmp, qui dispose de tous les résultats et journaux nécessaires à l’analyse.

Par exemple : /tmp/vxverify-c9.zip

En plus de cela .zip de l’exécution la plus récente de VxVerify, jusqu’à cinq ensembles de logs précédents peuvent également être présents dans le fichier /tmp . Les noms ont la date et l’heure auxquelles ils ont été exécutés dans les attributs de fichier : 

vxv_previous_01.zip

Vous pouvez également exécuter la commande ci-dessous pour archiver tous les fichiers pertinents :

tar cvzf vxverify-2020-12-31.tgz /tmp/vxv/

Dépannage

Étapes de dépannage classiques pour l’exécution de VxVerify 2 (pour VxRail 4.5, 4.7 et 7.0.000)

• VxVerify a besoin de Python pour s'exécuter. La ligne de commande nécessaire à l'exécution est la suivante :

python /tmp/vxv/vxverify.pyc

• Si une erreur de numéro magique se produit, cela signifie généralement que la mauvaise version de VxVerify est utilisée pour la version de Python sur VxRM. Par exemple, l’erreur ci-dessous se produit si vous exécutez VxVerify 2 sur la version 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Pour vérifier que la version correcte de VxVerify est utilisée, consultez l’article ( le lien ci-dessous nécessite une authentification sur le portail de support Dell) :
  • VxRail : Comment exécuter l’outil VxRail Verify (section Versions VxVerify ) 
• VxVerify crée des programmes appelés minions, qui sont envoyés, exécutés et récupérés à l’aide de SSH. Si SSH peut être utilisé, même s’il n’est pas déjà activé, VxVerify s’active SSH pour chaque hôte afin d’exécuter les commandes à exécuter. Si les hôtes sont verrouillés où SSH ne peuvent pas s’exécuter, les minions ne peuvent pas s’exécuter et les tests de l’hôte renvoient un code de résultat : 2 (échec) ou 3 (critique). Si cela se produit, discutez de la SSH autorisations accordées à l’administrateur.
• VxVerify2 est conçu pour s’exécuter sur Python 2.7, qui doit être présent sur la machine virtuelle VxRM et est généralement la seule version de Python disponible. S’il existe d’autres versions de Python, exécutez les opérations suivantes pour les tester (celle-ci a la méthode -h , qui est --help) :

python2.7 vxverify.pyc -h

VxVerify écrit les journaux et les fichiers de sortie dans /tmp/vxv/. S'il ne dispose pas des autorisations suffisantes, il ne peut pas s'exécuter. Vérifiez les autorisations du dossier à l’aide des commandes suivantes. S’il n’existe aucune autorisation en lecture/écriture pour tous les utilisateurs, ajoutez-les à l’aide de chmod (des autorisations root peuvent être requises) :

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Si des erreurs d’autorisation persistent avec VxVerify (par exemple : « Autorisation refusée pour la suppression des journaux précédents. »), essayez de supprimer le vxv avec la commande suivante (le mot de passe root est nécessaire pour sudo l’accès). Après avoir exécuté cette commande de suppression, VxVerify doit être réinstallé en utilisant uniquement les autorisations mystic :

sudo rm -r -d /tmp/vxv

• Une autre option consiste à enregistrer les fichiers de sortie VxVerify dans un nouveau dossier. VxVerify crée l’arborescence si elle n’existe pas à l’aide de -l ou --log suivie du chemin d’accès vers lequel les journaux doivent être enregistrés. Par exemple :

python vxverify.pyc -l /tmp/vx1

Dépannage des différences entre VxVerify2 et VxVerify 3 (pour VxRail 7.0.010+)

Pour VxRail 7.0.010 et versions supérieures, vous devez utiliser VxVerify 3 en raison des modifications fondamentales apportées à VxRM.

Les mêmes étapes de dépannage pour VxVerify2 s’appliquent également à VxVerify3, SAUF :

• La version de Python pour VxVerify3 est 3.6.
• L’emplacement des packages de site sur lesquels VxVerify nécessite des modifications, qui se trouvent dans l’un des emplacements ci-dessous :
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Si ces deux dossiers sont inaccessibles à l'utilisateur Mystic, le programme VxVerify affiche un message d'erreur concernant les packages de site, puis se ferme.
  • Une solution de contournement utilise l’utilisateur root.

Délais d’expiration

Si le minion prend plus de 20 minutes, VxVerify doit fournir un événement de délai d’expiration dans le tableau récapitulatif.

| Node-name  |Critical 66460| minion: Maximum run time for minion exceeded

• Les attributs correspondants vxv.log Les entrées pour cela sont les suivantes :

2022-10-06 06:42:51-WARNING  Creating a fault json for missing minion

2022-10-06 06:42:51-WARNING  [fail_minion] Producing result file for lab-esx22, due to: Maximum run time for minion exceeded. See minion logs in /tmp/vxv

• Cela doit être vérifié en examinant le journal minion de cet hôte pour voir si le minion a rencontré une erreur qui l’a forcé à s’arrêter ou si le test se poursuivait lentement et s’il manquait de temps pour se terminer.
• Si un minion termine correctement, les dernières lignes du journal doivent être les suivantes :

2022-10-06 06:39:30 INFO    Writing to JSON: /tmp/xc882-61f1f3b9-7cb2-130a-35b0-minion.json

2022-10-06 06:39:30 INFO    JSON save: os.stat_result(st_mode=33206, st_ino=47144, st_dev=1, st_nlink=1, st_uid=0, st_gid=0, st_size=499562, st_atime=1665038370, st_mtime=1665038370, st_ctime=1665038370)

2022-10-06 06:39:30 DEBUG   ESXi minion's work is done.

Le transfert de fichiers JSON ne fonctionne pas

Si les résultats minion de l’hôte ne peuvent pas être transférés à l’aide de SCP ou SFTP vers VxRM, les éléments suivants peuvent s’afficher dans le tableau de sortie :

| Node-name  |Critical 66460| minion: No JSON downloaded from node via SSH

• Les attributs correspondants vxv.log Les entrées pour cela sont les suivantes :

2022-10-06 06:42:51-WARNING  Creating a fault json for missing minion

2022-10-06 06:42:51-WARNING  [fail_minion] Producing result file for lab-esx22, due to: No JSON downloaded from node via SSH. See minion logs in /tmp/vxv

• Cela doit être vérifié en examinant le journal minion de cet hôte pour voir si le minion a rencontré une erreur qui l’a forcé à s’arrêter ou si un fichier JSON a été produit, mais n’a pas pu être consulté à l’aide de SSH.
• Si un minion se termine correctement, les dernières lignes du journal doivent apparaître comme suit, ce qui indique qu’un fichier JSON a été enregistré avec succès dans le fichier /tmp Dossier du nœud :

2022-10-06 06:39:30 INFO    Writing to JSON: /tmp/xc882-61f1f3b9-7cb2-130a-35b0-minion.json

2022-10-06 06:39:30 INFO    JSON save: os.stat_result(st_mode=33206, st_ino=47144, st_dev=1, st_nlink=1, st_uid=0, st_gid=0, st_size=499562, st_atime=1665038370, st_mtime=1665038370, st_ctime=1665038370)

2022-10-06 06:39:30 DEBUG   ESXi minion's work is done.

Les étapes recommandées pour résoudre les problèmes ci-dessus sont les suivantes :

• Si vous utilisez VxVerify3, essayez d’exécuter avec la commande --fix , qui utilise une alternative SSH Mécanisme. Cela permet d’éviter certains SSH problèmes d’autorisations.
• Spécifiez un nouveau chemin d’accès à l’aide de -1 (le dossier n’a pas besoin d’être créé au préalable), ce qui peut être utile si des erreurs d’autorisation VxRM empêchent le transfert de fichiers :
• Par exemple : > python vxv2.pyc -l \tmp\vxv0
• Si les tentatives ci-dessus ne fonctionnent toujours pas, prenez un snapshot de VxRM avant de nettoyer les fichiers et dossiers inutiles dans /tmp et /home/mystic, tels que ceux précédemment utilisés par VxVerify.
• Redémarrez VxRM (VxRail Manager).

Si VxVerify rencontre une erreur qui ne peut pas être corrigée avec les étapes ci-dessus, enregistrez le bundle de logs vxv comme indiqué ci-dessus et faites remonter le problème au support Dell.

Erreurs de connexion et d’informations d’identification dans VxVerify2 et VxVerify3

• Pour exécuter des tests sur VxRM (VxRail Manager) et les nœuds VxRail, VxVerify ne nécessite aucune information d’identification. VxVerify peut accéder aux informations d’identification chiffrées directement à partir de la base de données VxRM et les déchiffre avant de les utiliser. Parfois, les informations d’identification de gestion VC ne sont pas accessibles. Dans ce cas, ces informations d’identification peuvent être spécifiées dans la ligne de commande VxVerify :

python vxverify.py --verbose -u vxrailmgmt@localos -p ChangeMe1!

• L’utilisation de certains caractères spéciaux autorisés par vCenter peut entraîner des problèmes pour VxRail Manager (en particulier pour les commandes qui utilisent le shell Linux). Vérifiez qu’aucun des caractères suivants n’est utilisé dans les mots de passe de vCenter ou des hôtes ESXi :

` $ % / \

• En cas de doute sur le nom d’utilisateur utilisé pour la gestion, consultez le vxv.log. Par exemple :

... - DEBUG Users from runtime & settings records:     vxrailmgmt@localos & vxrailmgmt@localos

• Les tests sur vCenter à l’aide de SSH nécessitent un nom d’utilisateur et un mot de passe root, qui peuvent être spécifiés avec la commande -r et -w respectivement. Les tests vCenter ne sont exécutés que si ceux-ci sont spécifiés (bien que si l’utilisateur root est root, qui est la valeur par défaut, alors seul le mot de passe root doit être spécifié). Par exemple :

python vxverify.py --verbose -w R00tPassword!

Exemples d’échecs de test critiques

Il peut s'agir d'erreurs graves qui empêchent l'exécution de tests supplémentaires. Par exemple, si le nom d’utilisateur et le mot de passe de gestion vCenter enregistrés dans VxRM ne sont pas à jour, toutes les requêtes sur l’API VC échouent et aucun autre test ne peut être exécuté. Voici quelques exemples :

#========================#======#=========#====================================================================#==============#
|  Hostname / Category   |Status  Dell_KB |  Warnings or Failures, unless tests Passed                         | Product S.N. |
#========================#======#=========#====================================================================#==============#
| VxRM                   | Critical 66460 | vc_external: VC MOB API connection failed                                        .| <- Stored vCenter password rejected
| VxRail                 | Critical 66460 | vxtii_err: Internal DO host query failed. See vxv.log for details in /tmp/vxv    .| <- ESXi node data cannot be retrieved from the VxRM config service
| _cluster               | Critical 66460 | esx_vers: No valid ESXi test results found                                       .| <- No ESXi tests could be run

Fichiers VxVerify

VxVerify crée les fichiers suivants dans /tmp/vxv/ ou /var/log/mystic/vxv/ (à moins qu’un autre dossier de journalisation ne soit spécifié à l’aide de la commande -l l’argument).  Ces fichiers sont tous enregistrés dans un seul fichier d’archive dans /tmpComme /tmp/vxverify-569ae010.zip ou /tmp/vxv_previous_01.zip.
La vérification manuelle de ces fichiers peut vous aider à détecter des problèmes sur le cluster, même si le script VxVerify ne se termine pas entièrement :   

• vxv.log - (fichier journal pour le script VxVerify)
• minion_hostname.log - (journal distant pour le script minion en cours d’exécution sur chaque hôte)
• minion_hostname.txt - (sortie de texte à distance pour chaque minion, indiquant quel numéro de test est en cours)
• /json/host_uid.json - (fichier produit par chaque minion, avec les résultats du test, qui est ensuite fusionné avec d’autres données de l’hôte, puis supprimé)
• vxverify_tests.json - (sortie combinée pour tous les tests, qui peut être vérifiée manuellement pour voir chaque résultat de test)
• vxtii.json - (réponses combinées des hôtes pour des requêtes telles que l’inventaire matériel de l’iDRAC)
• vxtii.txt - (rapport résumant les informations iDRAC et ESXi pour chaque nœud)
• vxverify.txt - (le tableau récapitulatif, qui s’affiche également à l’écran, si VxVerify n’est pas exécuté en mode silencieux)
• vxverify.html - (rapports VxVerify et VxTii combinés au format HTML) (présent uniquement lors de l’exécution directe de VxVerify, plutôt qu’intégré dans les bilans de santé VxRail Manager)