VxRail: Feilsøke problemer med VxVerify før en VxRail-oppgradering

Denne KB-artikkelen er dedikert til feilsøking av problemer som hindrer VxVerify i å kjøre.

Denne kunnskapsartikkelen refereres fra tester som ikke har en artikkel rettet mot det relevante svaret (for eksempel: Advarsel, Feil og Kritisk). Et eksempel på dette kan være en spørring som returnerer et uventet svar fra en spørring.

VxVerify er utviklet for å oppdage problemer som kan forårsake komplikasjoner eller feil under VxRail-oppgraderinger. VxVerify oppretter Python-programmer som kalles Minions, som sendes til VxRail-nodene. Nedenfor er de typiske testresultatene som kan forventes i vxverify_tests.json:

Hvis det oppdages et falskt positivt testresultat, samler du inn VxVerify-loggene og kontakter Dell Support for å åpne en Jira VXV-forespørsel med VxRail Engineering.

Det er flere årsaker som kan forhindre at VxVerify kjører uten problemer.

• Den vanligste årsaken til feil er at Python-skriptet er utløpt. Hver VxVerify-versjon er satt til å bare vare i to uker fra datoen den ble publisert. Dette gjelder ikke når VxVerify kjøres som en plugin til VxRail-helsesjekk-rammeverket (som endrer VxVerify-funksjonaliteten).
• Andre årsaker kan være tillatelser, problemer med VxRail Manager eller kommunikasjonsproblemer med vertene.
• Hvis årsaken til hendelsen er uklar, kan du kontakte Dell Support for å åpne en VXV-sak med VxRail Engineering.

Avsnittet nedenfor inneholder instruksjoner om hvordan du samler inn logger og feilsøker hvis VxVerify ikke kjører som det skal.

Logginnsamling for støtteengasjement

Når du engasjerer støtte med VxVerify-relaterte problemer, laster du opp hele det arkiverte vxv -mappen for analyse, eller vxverify Logge .zip Filen. Gjeldende frittstående VxVerify-versjoner lagre en arkivert fil på /tmp, som har alle nødvendige resultater og logger for analyse.

For eksempel: /tmp/vxverify-c9.zip

I tillegg til dette .zip fra den siste kjøringen av VxVerify, kan opptil fem sett med tidligere logger også være til stede i /tmp Mappen. Navnene har datoen da disse ble kjørt i filattributtene: 

vxv_previous_01.zip

Alternativt kan du kjøre kommandoen nedenfor for å arkivere alle relevante filer:

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

Feilsøking

Typiske feilsøkingstrinn for kjøring av VxVerify 2 (for VxRail 4.5, 4.7 og 7.0.000)

• VxVerify trenger Python for å kjøre, og kommandolinjen for å kjøre den er som følger:

python /tmp/vxv/vxverify.pyc

• Hvis det oppstår en magisk tallfeil , betyr dette vanligvis at feil versjon av VxVerify brukes for Python-versjonen på VxRM. Feilen nedenfor oppstår for eksempel hvis du kjører VxVerify 2 på 7.0.320.

RuntimeError: Bad magic number in .pyc file

• For å kontrollere om riktig versjon av VxVerify brukes, kan du se artikkel (koblingen nedenfor krever godkjenning til Dell Support Portal):
  • VxRail: Slik kjører du VxRail Verification-verktøyet (VxVerify-versjoner ) 
• VxVerify oppretter programmer som kalles minions, som sendes, kjøres og hentes ved hjelp av SSH. Hvis SSH kan brukes, selv om den ikke allerede er aktivert, slår VxVerify på SSH for hver vert for kommandoene som skal kjøres. Hvis vertene er låst hvor SSH kan ikke kjøre, minions kan ikke kjøre, og vertstestene returnerer en resultatkode: 2 (feil) eller 3 (kritisk). Hvis dette skjer, diskuter SSH Tillatelser med administratoren.
• VxVerify2 er utviklet for å kjøre på Python 2.7, som skal være til stede på VxRM VM, og er vanligvis den eneste tilgjengelige Python-versjonen. Hvis det finnes flere Python-versjoner, kjører du følgende for å teste det (dette har -h -alternativet, som er --help):

python2.7 vxverify.pyc -h

VxVerify skriver logger og utdatafiler til /tmp/vxv/. Hvis den ikke har tilstrekkelige tillatelser, kan den ikke kjøres. Kontroller mappetillatelsene med følgende kommandoer. Hvis det ikke er noen lese-/skrivetillatelser for alle brukere, legger du til disse med chmod (root-tillatelser kan være nødvendig):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Hvis tillatelsesfeil vedvarer med VxVerify (for eksempel: 'Tillatelse nektet for sletting av tidligere logger.'), kan du prøve å slette vxv mappe med følgende kommando (root-passordet er nødvendig for sudo tilgang). Etter å ha kjørt denne slette kommandoen, må VxVerify installeres igjen ved hjelp av bare mystic tillatelser:

sudo rm -r -d /tmp/vxv

• Et annet alternativ er å lagre VxVerify-utdatafilene i en ny mappe. VxVerify oppretter treet hvis det ikke finnes ved hjelp av -l eller --log -alternativet, etterfulgt av banen som loggene skal lagres på. For eksempel:

python vxverify.pyc -l /tmp/vx1

Feilsøke forskjeller mellom VxVerify2 og VxVerify 3 (for VxRail 7.0.010+)

For VxRail 7.0.010 og nyere må VxVerify 3 brukes, på grunn av grunnleggende endringer i VxRM.

De samme feilsøkingstrinnene for VxVerify2 gjelder også for VxVerify3, bortsett fra:

• Versjonen av Python for VxVerify3 er 3.6.
• Plasseringen av nettstedspakkene som VxVerify krever endringer, som ligger på et av stedene nedenfor:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Hvis begge disse mappene er utilgjengelige fra mystic-brukeren, gir VxVerify-programmet en feilmelding om nettstedpakkene og avslutter.
  • En løsning bruker rotbrukeren.

Tidsavbrudd

Hvis minion tar mer enn 20 minutter å fullføre, må VxVerify oppgi en tidsavbruddhendelse i sammendragstabellen.

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

• Tilsvarende vxv.log Oppføringer for dette er:

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

• Dette bør kontrolleres ved å se på minionloggen for den verten for å se om minion oppdaget en feil som fikk den til å stoppe, eller om testingen fortsatte sakte og den gikk tom for tid til å fullføre.
• Hvis en minion fullføres riktig, skal følgende være de siste linjene 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-filoverføring fungerer ikke

Hvis minion for verten ikke kan overføres med SCP eller SFTP tilbake til VxRM, kan du se følgende på utdatatabellen:

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

• Tilsvarende vxv.log Oppføringer for dette er:

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

• Dette bør kontrolleres ved å se på minion-loggen for den verten for å se om minion oppdaget en feil som fikk den til å stoppe eller om en JSON-fil ble produsert, men ikke kunne nås ved hjelp av SSH.
• Hvis en minion fullføres riktig, skal følgende være de siste linjene i loggen, som viser at en JSON ble lagret i /tmp Nodemappe:

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 anbefalte trinnene for å feilsøke ovenstående vil være:

• Hvis du bruker VxVerify3, kan du prøve å kjøre med --fix flagg, som bruker et alternativ SSH Mekanisme. Dette kan unngå noen SSH Problemer med tillatelser.
• Angi en ny bane ved hjelp av -1 (mappen trenger ikke opprettes først), noe som kan hjelpe hvis VxRM-tillatelsesfeil forhindrer filoverføringen:
• For eksempel > python vxv2.pyc -l \tmp\vxv0
• Hvis ovenstående fortsatt ikke fungerer, kan du ta et øyeblikksbilde av VxRM før du rydder opp i unødvendige filer og mapper i /tmp og /home/mystic, for eksempel de som tidligere ble brukt av VxVerify.
• Start VxRM (VxRail Manager) på nytt.

Hvis VxVerify støter på en feil som ikke kan løses med trinnene ovenfor, lagrer du vxv-loggpakken som beskrevet ovenfor, og eskalerer problemet til Dell Support.

Påloggings- og legitimasjonsfeil i VxVerify2 og VxVerify3

• VxVerify krever ingen legitimasjon for å kjøre tester på VxRM (VxRail Manager) og VxRail-nodene. VxVerify kan få tilgang til kryptert legitimasjon direkte fra VxRM-databasen og dekrypterer dem før du bruker dem. Noen ganger er det ikke mulig å få tilgang til VC-administrasjonslegitimasjonen, og i så fall kan denne legitimasjonen spesifiseres i VxVerify-kommandolinjen:

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

• Bruk av enkelte spesialtegn som tillates av vCenter, kan skape problemer for VxRail Manager (spesielt for kommandoer som bruker Linux Shell). Kontroller at ingen av følgende tegn brukes i passordene for vCenter- eller ESXi-vertene:

` $ % / \

• Hvis du er i tvil om hvilket brukernavn som brukes til ledelse, se vxv.log. For eksempel:

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

• Tester til vCenter ved hjelp av SSH krever et rotbrukernavn og -passord, som kan angis med -r og -w opsjoner henholdsvis. vCenter-testene kjøres bare hvis disse er angitt (men hvis rotbrukeren er root, som er standard, må bare root-passordet spesifiseres). For eksempel:

python vxverify.py --verbose -w R00tPassword!

Eksempler på kritiske testfeil

Disse kan være et resultat av alvorlige feil, som forhindrer at ytterligere tester kjøres. Hvis for eksempel vCenter-administrasjonsbrukernavnet og -passordet som er lagret i VxRM, ikke er oppdatert, mislykkes alle spørringer til VC API, og ingen videre testing kan kjøres. Eksempler på dette inkluderer:

#========================#======#=========#====================================================================#==============#
|  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 oppretter følgende filer i /tmp/vxv/ eller /var/log/mystic/vxv/ (med mindre en annen loggingsmappe er angitt ved hjelp av -l argumentet).  Disse filene er alle lagret i en enkelt arkivfil i /tmpSom /tmp/vxverify-569ae010.zip eller /tmp/vxv_previous_01.zip.
Hvis du kontrollerer disse filene manuelt, kan det hjelpe deg med å finne problemer på klyngen, selv om VxVerify-skriptet ikke fullføres helt:   

• vxv.log - (loggfil for VxVerify-skriptet)
• minion_hostname.log - (ekstern logg for minion skriptet som kjører på hver vert)
• minion_hostname.txt - (ekstern tekstutgang for hver undersåtte, som viser hvilket testnummer som pågår)
• /json/host_uid.json - (fil produsert av hver minion, med testresultatene, som senere slås sammen med andre vertsdata, deretter slettet)
• vxverify_tests.json - (kombinert utgang for alle tester, som kan kontrolleres manuelt for å se hvert testresultat)
• vxtii.json – (kombinerte svar fra verter for spørringer som iDRAC Hardware Inventory)
• vxtii.txt - (rapport som oppsummerer iDRAC- og ESXi-informasjon for hver node)
• vxverify.txt - (sammendragstabellen, som også vises på skjermen, hvis VxVerify ikke kjøres i stille modus)
• vxverify.html – (kombinerte VxVerify- og VxTii-rapporter i HTML-format) (finnes bare ved kjøring av VxVerify direkte, i stedet for innebygd i VxRail Manager-tilstandskontroller)