VxRail: Felsöka problem med VxVerify före en VxRail-uppgradering

Den här KB-artikeln handlar om felsökning av problem som gör att VxVerify inte kan köras.

Den här kunskapsartikeln refereras från tester som inte har en artikel som är riktad för deras relevanta svar (till exempel: Varning, Fel och Kritisk). Ett exempel på detta är en fråga som returnerar ett oväntat svar från en fråga.

VxVerify är utformat för att identifiera problem som kan orsaka komplikationer eller fel under VxRail-uppgraderingar. VxVerify skapar Python-program, så kallade Minions, som skickas till VxRail-noderna. Nedan följer de typiska testresultaten som du kan förvänta dig i vxverify_tests.json:

Om ett falskt positivt testresultat upptäcks samlar du in VxVerify-loggarna och kontaktar Dells support för att öppna ett Jira VXV-ärende med VxRail Engineering.

Det finns flera orsaker som kan göra att VxVerify inte kan köras.

• Den vanligaste orsaken till fel är att Python-skriptet har upphört att gälla. Varje VxVerify-version är inställd på att bara pågå i två veckor från det datum då den publicerades. Detta gäller inte när VxVerify körs som ett insticksprogram till VxRail-ramverket för hälsokontroll (vilket ändrar VxVerify-funktionen).
• Andra orsaker kan vara behörighetsproblem i VxRail Manager eller kommunikationsproblem med värdarna.
• Om orsaken till händelsen är oklar kontaktar du Dells support för att öppna ett VXV-ärende hos VxRail Engineering.

I avsnittet nedan finns instruktioner om hur du samlar in loggar och felsöker om VxVerify inte fungerar som det ska.

Logginsamling för supportuppdrag

När du kontaktar supporten för VxVerify-relaterade problem laddar du upp hela arkiveringen vxv mapp för analys, eller vxverify Logga in .zip Filen. Aktuella fristående VxVerify-versioner sparar en arkiverad fil i /tmp, som har alla nödvändiga resultat och loggar för analys.

Till exempel: /tmp/vxverify-c9.zip

Utöver detta .zip från den senaste körningen av VxVerify kan upp till fem uppsättningar tidigare loggar också finnas i /tmp Mappen. Namnen har det datum och den tid då dessa kördes i filattributen: 

vxv_previous_01.zip

Du kan också köra kommandot nedan för att arkivera alla relevanta filer:

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

Felsökning

Typiska felsökningssteg för att köra VxVerify 2 (för VxRail 4.5, 4.7 och 7.0.000)

• VxVerify behöver Python för att köras och kommandoraden för att köra det är följande:

python /tmp/vxv/vxverify.pyc

• Om ett magiskt talfel inträffar innebär det vanligtvis att fel version av VxVerify används för Python-versionen på VxRM. Nedanstående fel uppstår till exempel om du kör VxVerify 2 på 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Information om hur du kontrollerar att rätt version av VxVerify används finns i artikeln (länken nedan kräver autentisering till Dells supportportal):
  • VxRail: Så här kör du VxRail Verify-verktyget (avsnittet VxVerify-versioner ) 
• VxVerify skapar program som kallas minioner, som skickas, körs och hämtas med hjälp av SSH. Om SSH användas, även om det inte redan är aktiverat, aktiveras VxVerify SSH för varje värd för de kommandon som ska köras. Om värdarna är låsta där SSH kan inte köras, minionerna kan inte köras och värdtesterna returnerar en resultatkod: 2 (Fel) eller 3 (Kritisk). Om detta händer, diskutera SSH behörigheter hos administratören.
• VxVerify2 är utformat för att köras på Python 2.7, som ska finnas på den virtuella VxRM-datorn och vanligtvis är den enda tillgängliga Python-versionen. Om det finns fler Python-versioner kör du följande för att testa det (detta har -h optionen, som är --help):

python2.7 vxverify.pyc -h

VxVerify skriver loggar och utdatafiler till /tmp/vxv/. Om den inte har tillräcklig behörighet kan den inte köras. Kontrollera mappbehörigheterna med följande kommandon. Om det inte finns läs-/skrivbehörighet för alla användare lägger du till dessa med chmod (root-behörigheter kan krävas):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Om behörighetsfelen kvarstår med VxVerify (till exempel: "Behörighet nekad för borttagning av tidigare loggar.") kan du prova att ta bort vxv -mappen med följande kommando (rotlösenordet behövs för sudo tillträde). När du har kört det här borttagningskommandot måste VxVerify installeras igen med endast mystiska behörigheter:

sudo rm -r -d /tmp/vxv

• Ett annat alternativ är att spara VxVerify-utdatafilerna i en ny mapp. VxVerify skapar trädet om det inte finns med hjälp av -l eller --log följt av den sökväg som loggarna ska sparas till. Till exempel:

python vxverify.pyc -l /tmp/vx1

Felsökning av skillnader mellan VxVerify2 och VxVerify 3 (för VxRail 7.0.010+)

För VxRail 7.0.010 och senare måste VxVerify 3 användas på grund av grundläggande förändringar i VxRM.

Samma felsökningssteg för VxVerify2 gäller även för VxVerify3, FÖRUTOM:

• Python-versionen för VxVerify3 är 3.6.
• Platsen för de platspaket som VxVerify kräver ändringar, och de finns på någon av platserna nedan:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Om mystic-användaren inte kan komma åt båda dessa mappar ger VxVerify-programmet ett felmeddelande om platspaketen och avslutas.
  • En tillfällig lösning är att använda rotanvändaren.

Timeout

Om minionen tar längre tid än 20 minuter att slutföra måste VxVerify ange en timeout-händelse i sammanfattningstabellen.

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

• Motsvarande vxv.log Poster för detta är:

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

• Detta bör kontrolleras genom att titta på minionloggen för den värden för att se om minionen stötte på ett fel som gjorde att den stoppades eller om testningen fortsatte långsamt och det tog slut på tid för att slutföras.
• Om en minion slutförs korrekt bör följande vara de sista raderna i loggen:

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-filöverföring fungerar inte

Om resultatet av värdminionen inte kan överföras med SCP eller SFTP tillbaka till VxRM kan följande visas i utdatatabellen:

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

• Motsvarande vxv.log Poster för detta är:

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

• Detta bör kontrolleras genom att titta på minionloggen för den värden för att se om minionen stötte på ett fel som fick den att stanna eller om en JSON-fil skapades, men inte kunde nås med hjälp av SSH.
• Om en minion slutförs korrekt bör följande vara de sista raderna i loggen, som visar att en JSON har sparats i /tmp nodens mapp:

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.

De rekommenderade stegen för att felsöka ovanstående är:

• Om du använder VxVerify3 kan du prova att köra med --fix flaggan, som använder en alternativ SSH Mekanism. På så sätt kan man undvika vissa SSH behörighetsproblem.
• Ange en ny sökväg med hjälp av -1 (mappen behöver inte skapas först), vilket kan vara till hjälp om VxRM-behörighetsfel förhindrar filöverföringen:
• Till exempel, > python vxv2.pyc -l \tmp\vxv0
• Om ovanstående fortfarande inte fungerar tar du en snapshot av VxRM innan du rensar bort onödiga filer och mappar i /tmp och /home/mystic, t.ex. de som tidigare användes av VxVerify.
• Starta om VxRM (VxRail Manager).

Om VxVerify påträffar ett fel som inte kan åtgärdas med stegen ovan sparar du vxv-loggpaketet enligt beskrivningen ovan och eskalerar problemet till Dells support.

Inloggnings- och autentiseringsfel i VxVerify2 och VxVerify3

• Det krävs inga inloggningsuppgifter för att köra tester på VxRM (VxRail Manager) och VxRail-noderna. VxVerify kan komma åt de krypterade inloggningsuppgifterna direkt från VxRM-databasen och dekrypterar dem innan de används. Ibland går det inte att komma åt VC-hanteringsautentiseringsuppgifterna, och i så fall kan dessa autentiseringsuppgifter anges på VxVerify-kommandoraden:

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

• Användning av vissa specialtecken som tillåts av vCenter kan orsaka problem i VxRail Manager (särskilt för kommandon som använder Linux Shell). Kontrollera att inget av följande tecken används i lösenorden för vCenter eller ESXi-värdarna:

` $ % / \

• Om du är osäker på vilket användarnamn som används för hantering, kontakta vxv.log. Till exempel:

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

• För test av vCenter med SSH krävs ett rotanvändarnamn och -lösenord, som kan anges med -r och -w alternativ. vCenter-testerna körs bara om dessa anges (om rotanvändaren är det root, vilket är standard, måste endast root-lösenordet anges). Till exempel:

python vxverify.py --verbose -w R00tPassword!

Exempel på kritiska testfel

Dessa kan vara resultatet av allvarliga fel, vilket förhindrar att ytterligare tester körs. Om användarnamnet och lösenordet för vCenter-hantering som sparas i VxRM till exempel inte är aktuellt misslyckas alla frågor till VC API och ingen ytterligare testning kan köras. Exempel på detta är:

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

VxVerify skapar följande filer i /tmp/vxv/ eller /var/log/mystic/vxv/ (såvida inte en annan loggningsmapp anges med hjälp av -l argumentet).  Dessa filer sparas alla i en enda arkivfil i /tmpSom /tmp/vxverify-569ae010.zip eller /tmp/vxv_previous_01.zip. – Herr talman,
Om du kontrollerar dessa filer manuellt kan du hitta problem i klustret även om VxVerify-skriptet inte slutförs:   

• vxv.log - (loggfil för VxVerify-skriptet)
• minion_hostname.log - (fjärrlogg för minionskriptet som körs på varje värd)
• minion_hostname.txt - (fjärrtextmatning för varje minion, som visar vilket testnummer som pågår)
• /json/host_uid.json - (fil som produceras av varje minion, med testresultaten, som senare slås samman med andra värddata och sedan raderas)
• vxverify_tests.json - (kombinerad utgång för alla tester, som kan kontrolleras manuellt för att se varje testresultat)
• vxtii.json - (kombinerade svar från värdar för frågor som iDRAC Hardware Inventory)
• vxtii.txt - (rapport som sammanfattar iDRAC- och ESXi-information för varje nod)
• vxverify.txt - (sammanfattningstabellen, som också visas på skärmen, om VxVerify inte körs i tyst läge)
• vxverify.html - (kombinerade VxVerify- och VxTii-rapporter i HTML-format) (finns endast när VxVerify körs direkt, i stället för inbäddat i VxRail Manager-hälsokontroller)