VxRail: Troubleshooting von Problemen mit VxVerify vor einem VxRail-Upgrade

Dieser Wissensdatenbank-Artikel widmet sich der Behebung von Problemen, die eine erfolgreiche Ausführung von VxVerify verhindern.

Auf diesen Wissensdatenbank-Artikel wird von Tests verwiesen, bei denen kein Artikel enthalten ist, auf dessen relevante Antwort die entsprechende Antwort erfolgt (z. B.: "Warning", "Failure" und "Critical"). Ein Beispiel hierfür wäre eine Abfrage, die eine unerwartete Antwort von einer Abfrage zurückgibt.

VxVerify wurde entwickelt, um Probleme zu erkennen, die während VxRail-Upgrades zu Komplikationen oder Ausfällen führen können. VxVerify erstellt Python-Programme, die als Minions bezeichnet werden und an die VxRail-Nodes gesendet werden. Nachfolgend finden Sie die typischen Testergebnisse, die zu erwarten sind in vxverify_tests.json:

Wenn ein falsch positives Testergebnis ermittelt wird, erfassen Sie die VxVerify-Protokolle und wenden Sie sich an den Dell Support, um ein Jira VXV-Ticket beim VxRail Engineering zu eröffnen.

Es gibt mehrere Ursachen, die eine erfolgreiche Ausführung von VxVerify verhindern können.

• Die häufigste Ursache für Fehler ist, dass das Python-Skript abgelaufen ist. Jede VxVerify-Version ist so eingestellt, dass sie nur zwei Wochen ab dem Datum der Veröffentlichung gültig ist. Dies gilt nicht, wenn VxVerify als Plug-in für das VxRail-Integritätsprüfungs-Framework ausgeführt wird (wodurch die VxVerify-Funktionalität geändert wird).
• Andere Gründe können Berechtigungsprobleme auf dem VxRail Manager oder Kommunikationsprobleme mit den Hosts sein.
• Wenn die Ursache des Ereignisses unklar ist, wenden Sie sich an den Dell Support, um ein VXV-Ticket beim VxRail Engineering zu eröffnen.

Der folgende Abschnitt enthält Anweisungen zum Erfassen von Protokollen und zum Troubleshooting, wenn VxVerify nicht ordnungsgemäß ausgeführt wird.

Protokollerfassung für die Einbindung des Supports

Wenn Sie sich an den Support mit Problemen im Zusammenhang mit VxVerify wenden, laden Sie die gesamte archivierte vxv -Ordner für die Analyse oder den vxverify Protokoll .zip Datei. Aktuelle eigenständige VxVerify-Versionen speichern eine archivierte Datei unter /tmp, das alle erforderlichen Ergebnisse und Protokolle für die Analyse enthält.

Zum Beispiel: /tmp/vxverify-c9.zip

Darüber hinaus .zip Datei aus der letzten Ausführung von VxVerify, können bis zu fünf Sätze früherer Protokolle auch im /tmp Ordner. Die Namen enthalten in den Dateiattributen das Datum und die Uhrzeit der Ausführung: 

vxv_previous_01.zip

Alternativ können Sie den folgenden Befehl ausführen, um alle relevanten Dateien zu archivieren:

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

Beim Troubleshooting

Typische Schritte zur Fehlerbehebung für die Ausführung von VxVerify 2 (für VxRail 4.5, 4.7 und 7.0.000)

• VxVerify benötigt Python für die Ausführung, die Befehlszeile dafür sieht wie folgt aus:

python /tmp/vxv/vxverify.pyc

• Wenn ein Magic-Number-Fehler auftritt, bedeutet dies in der Regel, dass die falsche Version von VxVerify für die Python-Version auf VxRM verwendet wird. Der folgende Fehler tritt beispielsweise auf, wenn Sie VxVerify 2 auf 7.0.320 ausführen.

RuntimeError: Bad magic number in .pyc file

• Um zu überprüfen, ob die richtige Version von VxVerify verwendet wird, lesen Sie den Artikel (der Link unten erfordert eine Authentifizierung beim Dell Supportportal):
  • VxRail: So führen Sie das VxRail-Überprüfungstool aus (Abschnitt VxVerify-Versionen ) 
• VxVerify erstellt Programme, die als Minions bezeichnet werden und mithilfe von gesendet und ausgeführt und abgerufen werden SSH. Wenn die SSH verwendet werden kann, auch wenn es noch nicht aktiviert ist, wird VxVerify eingeschaltet SSH für jeden Host für die auszuführenden Befehle. Wenn die Hosts gesperrt sind, wo SSH Kann nicht ausgeführt werden, die Minions können nicht ausgeführt werden und die Hosttests geben einen Ergebniscode zurück: 2 (Fehler) oder 3 (kritisch). Besprechen Sie in diesem Fall die SSH Administratorberechtigungen erteilen.
• VxVerify2 ist für die Ausführung auf Python 2.7 konzipiert, das auf der VxRM-VM vorhanden sein sollte und in der Regel die einzige verfügbare Python-Version ist. Wenn weitere Python-Versionen vorhanden sind, führen Sie die folgenden Schritte aus, um sie zu testen (dies hat die -h Option, die --help):

python2.7 vxverify.pyc -h

VxVerify schreibt Protokolle und Ausgabedateien auf /tmp/vxv/. Wenn keine ausreichenden Berechtigungen vorliegen, kann es nicht ausgeführt werden. Überprüfen Sie die Ordnerberechtigungen mit den folgenden Befehlen. Wenn keine Lese-/Schreibberechtigungen für alle Nutzer vorhanden sind, fügen Sie diese mit chmod (Root-Berechtigungen sind möglicherweise erforderlich):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Wenn Berechtigungsfehler bei VxVerify weiterhin bestehen (z. B. "Permission denied for deleting previous logs"), versuchen Sie, die vxv Ordner mit dem folgenden Befehl (das Root-Kennwort ist erforderlich für sudo Zugriff). Nachdem Sie diesen Löschbefehl ausgeführt haben, muss VxVerify nur mit mystic-Berechtigungen neu installiert werden:

sudo rm -r -d /tmp/vxv

• Eine weitere Option ist das Speichern der VxVerify-Ausgabedateien in einem neuen Ordner. VxVerify erstellt die Struktur, wenn sie nicht vorhanden ist, mithilfe der -l oder --log Option, gefolgt von dem Pfad, unter dem die Protokolle gespeichert werden sollen. Zum Beispiel:

python vxverify.pyc -l /tmp/vx1

Troubleshooting von Unterschieden zwischen VxVerify2 und VxVerify 3 (für VxRail 7.0.010+)

Für VxRail 7.0.010 und höher muss VxVerify 3 aufgrund grundlegender Änderungen in VxRM verwendet werden.

Die gleichen Schritte zur Fehlerbehebung für VxVerify2 gelten auch für VxVerify3, AUSNAHME:

• Die Version von Python für VxVerify3 ist 3.6.
• Der Speicherort der Standortpakete, die VxVerify ändern muss und sich an einem der folgenden Speicherorte befinden:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Wenn der Nutzer mystic auf keinen der beiden Ordner zugreifen kann, gibt das VxVerify-Programm eine Fehlermeldung zu den Standortpaketen aus und wird beendet.
  • Ein Workaround ist die Verwendung des Root-Nutzers.

Timeouts

Wenn der Abschluss von "Minion" länger als 20 Minuten dauert, muss VxVerify ein Timeout-Ereignis in der Übersichtstabelle angeben.

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

• Das entsprechende vxv.log Einträge hierfür sind:

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

• Dies sollte überprüft werden, indem Sie sich das Minion-Protokoll für diesen Host ansehen, um festzustellen, ob der Minion einen Fehler gefunden hat, der zum Beenden geführt hat, oder ob der Test langsam fortgesetzt wird und die Zeit bis zum Abschluss abgelaufen ist.
• Wenn ein Minion ordnungsgemäß abgeschlossen wird, müssen die folgenden Zeilen im Protokoll lauten:

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.

JSON-Dateiübertragung funktioniert nicht

Wenn die Host-Minion-Ergebnisse nicht über SCP oder SFTP zurück an VxRM übertragen werden können, wird möglicherweise Folgendes in der Ausgabetabelle angezeigt:

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

• Das entsprechende vxv.log Einträge hierfür sind:

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

• Dies sollte überprüft werden, indem Sie sich das Minion-Protokoll für diesen Host ansehen, um festzustellen, ob der Minion auf einen Fehler gestoßen ist, der zum Beenden geführt hat, oder ob eine JSON-Datei erstellt wurde, auf die jedoch nicht mit zugegriffen werden konnte SSH.
• Wenn ein Minion ordnungsgemäß abgeschlossen wird, sollten die folgenden Zeilen im Protokoll angezeigt werden, die anzeigen, dass eine JSON-Datei erfolgreich im /tmp Ordner des Node:

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.

Die empfohlenen Schritte für das Troubleshooting der oben genannten sind:

• Wenn Sie VxVerify3 verwenden, versuchen Sie, mit dem --fix -Flag, das eine Alternative verwendet SSH Mechanismus. Dadurch können einige SSH Berechtigungsprobleme.
• Geben Sie einen neuen Pfad an, indem Sie -1 (Der Ordner muss nicht zuerst erstellt werden), was hilfreich sein kann, wenn VxRM-Berechtigungsfehler die Dateiübertragung verhindern:
• Beispiel: > python vxv2.pyc -l \tmp\vxv0
• Wenn die oben genannten Schritte immer noch nicht funktionieren, erstellen Sie einen Snapshot von VxRM, bevor Sie unnötige Dateien und Ordner in /tmp und /home/mystic, wie sie zuvor von VxVerify verwendet wurden.
• Starten Sie VxRM (VxRail Manager) neu.

Wenn VxVerify auf einen Fehler stößt, der mit den oben genannten Schritten nicht behoben werden kann, speichern Sie das VXV-Protokoll-Bundle wie oben beschrieben und eskalieren Sie das Problem an den Dell Support.

Anmelde- und Zugangsdatenfehler in VxVerify2 und VxVerify3

• Zum Ausführen von Tests auf VxRM (VxRail Manager) und den VxRail-Nodes benötigt VxVerify keine Zugangsdaten. VxVerify kann direkt aus der VxRM-Datenbank auf die verschlüsselten Zugangsdaten zugreifen und diese entschlüsseln, bevor sie verwendet werden. Manchmal kann nicht auf die Zugangsdaten für das VC-Management zugegriffen werden. In diesem Fall können diese Zugangsdaten in der VxVerify-Befehlszeile angegeben werden:

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

• Die Verwendung einiger Sonderzeichen, die von vCenter zugelassen sind, kann zu Problemen für VxRail Manager führen (insbesondere bei Befehlen, die die Linux-Shell verwenden). Überprüfen Sie, dass keines der folgenden Zeichen in den Kennwörtern für vCenter oder die ESXi-Hosts verwendet wird:

` $ % / \

• Wenn Sie nicht sicher sind, welcher Benutzername für die Verwaltung verwendet wird, konsultieren Sie die vxv.log. Zum Beispiel:

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

• Tests für vCenter mithilfe von SSH erfordern einen Root-Nutzernamen und ein Kennwort, die mit dem Befehl -r und -w -Optionen. Die vCenter-Tests werden nur ausgeführt, wenn diese angegeben sind (obwohl der Root-Nutzer root, die Standardeinstellung, muss nur das Root-Kennwort angegeben werden). Zum Beispiel:

python vxverify.py --verbose -w R00tPassword!

Beispiele für kritische Testfehler

Dies kann das Ergebnis schwerwiegender Fehler sein, die verhindern, dass weitere Tests ausgeführt werden. Wenn beispielsweise der in VxRM gespeicherte vCenter-Managementnutzername und das in VxRM gespeicherte Kennwort nicht aktuell sind, schlagen alle Abfragen an die VC API fehl und es können keine weiteren Tests ausgeführt werden. Beispiele hierfür sind:

#========================#======#=========#====================================================================#==============#
|  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

VxVerify-Dateien

VxVerify erstellt die folgenden Dateien in /tmp/vxv/ oder /var/log/mystic/vxv/ (es sei denn, ein anderer Protokollierungsordner wird mithilfe der -l Argument).  Diese Dateien werden alle in einer einzigen Archivdatei gespeichert in /tmp, wie z. B. /tmp/vxverify-569ae010.zip oder /tmp/vxv_previous_01.zip.
Das manuelle Überprüfen dieser Dateien kann dazu beitragen, Probleme auf dem Cluster zu finden, selbst wenn das VxVerify-Skript nicht vollständig ausgeführt wird:   

• vxv.log - (Protokolldatei für das VxVerify-Skript)
• minion_hostname.log - (Remote-Protokoll für das Minion-Skript, das auf jedem Host ausgeführt wird)
• minion_hostname.txt - (Remote-Textausgabe für jeden Minion, der anzeigt, welche Testnummer gerade ausgeführt wird)
• /json/host_uid.json - (von jedem Minion erzeugte Datei mit den Testergebnissen, die später mit anderen Hostdaten zusammengeführt und dann gelöscht wird)
• vxverify_tests.json - (kombinierte Ausgabe für alle Tests, die manuell überprüft werden kann, um jedes Testergebnis zu sehen)
• vxtii.json - (kombinierte Antworten von Hosts für Abfragen wie z.B. die iDRAC-Hardware-Bestandsaufnahme)
• vxtii.txt (Bericht mit Zusammenfassung der iDRAC- und ESXi-Informationen für jeden Node)
• vxverify.txt (die Übersichtstabelle, die auch auf dem Bildschirm angezeigt wird, wenn VxVerify nicht im stillen Modus ausgeführt wird)
• vxverify.html – (kombinierte VxVerify- und VxTii-Berichte im HTML-Format) (nur bei direkter Ausführung von VxVerify vorhanden, nicht eingebettet in VxRail Manager-Integritätsprüfungen)