VxRail: problemen met VxVerify oplossen voorafgaand aan een VxRail-upgrade

Dit KB-artikel is gewijd aan het oplossen van problemen die voorkomen dat VxVerify met succes wordt uitgevoerd.

Naar dit knowledge base-artikel wordt verwezen vanuit tests die geen artikel hebben dat is gericht op hun relevante reactie (bijvoorbeeld: Waarschuwing, Fout en Kritiek). Een voorbeeld hiervan is een query die een onverwacht antwoord van een query retourneert.

VxVerify is ontworpen om problemen te detecteren die complicaties of storingen kunnen veroorzaken tijdens VxRail upgrades. VxVerify maakt Python-programma's die bekend staan als Minions, die naar de VxRail-knooppunten worden verzonden. Hieronder vindt u de typische testresultaten die u kunt verwachten in vxverify_tests.json:

Als er een vals-positief testresultaat wordt ontdekt, verzamel je de VxVerify-logboeken en neem je contact op met Dell Support om een Jira VXV-ticket te openen bij VxRail Engineering.

Er zijn meerdere oorzaken waardoor VxVerify niet goed kan worden uitgevoerd.

• De meest voorkomende oorzaak van fouten is dat het Python-script is verlopen. Elke VxVerify-versie is ingesteld op slechts twee weken vanaf de datum waarop deze is gepubliceerd. Dit is niet van toepassing wanneer VxVerify wordt uitgevoerd als een plug-in voor het VxRail healthcheck-framework (waardoor de VxVerify-functionaliteit wordt gewijzigd).
• Andere redenen kunnen problemen met machtigingen in de VxRail Manager of communicatieproblemen met de hosts zijn.
• Als de oorzaak van de gebeurtenis onduidelijk is, schakelt u Dell Support in om een VXV-ticket te openen bij VxRail Engineering.

Het onderstaande gedeelte bevat instructies voor het verzamelen van logboeken en het oplossen van problemen als VxVerify niet goed werkt.

Logboekverzameling voor betrokkenheid van support

Wanneer u support inschakelt voor problemen met VxVerify, uploadt u de volledige gearchiveerde vxv voor analyse, of de vxverify Log .zip Bestand. Huidige zelfstandige VxVerify-versies slaan een gearchiveerd bestand op in /tmp, die over alle benodigde resultaten en logboeken voor analyse beschikt.

Bijvoorbeeld: /tmp/vxverify-c9.zip

Daarnaast .zip bestand van de meest recente uitvoering van VxVerify kunnen er ook maximaal vijf sets van eerdere logboeken aanwezig zijn in de /tmp Map. De namen hebben de datum-tijd waarop deze zijn uitgevoerd in de bestandskenmerken: 

vxv_previous_01.zip

U kunt ook de onderstaande opdracht uitvoeren om alle relevante bestanden te archiveren:

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

Probleemoplossing

Typische stappen voor probleemoplossing voor het uitvoeren van VxVerify 2 (voor VxRail 4.5, 4.7 en 7.0.000)

• VxVerify heeft Python nodig om het uit te voeren en de opdrachtregel om het uit te voeren is als volgt:

python /tmp/vxv/vxverify.pyc

• Als er een magische getalfout optreedt, betekent dit meestal dat de verkeerde versie van VxVerify wordt gebruikt voor de Python-versie op VxRM. De onderstaande fout treedt bijvoorbeeld op als u VxVerify 2 uitvoert op 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Om te controleren of de juiste versie van VxVerify wordt gebruikt, raadpleegt u het artikel (voor onderstaande koppeling is verificatie vereist voor de Dell Support portal):
  • VxRail: de VxRail Verify-tool uitvoeren (gedeelte VxVerify Releases ) 
• VxVerify maakt programma's die minions worden genoemd, die worden verzonden, uitgevoerd en opgehaald met behulp van SSH. Als SSH kan worden gebruikt, zelfs als deze nog niet is ingeschakeld, VxVerify gaat aan SSH voor elke host voor de uit te voeren opdrachten. Als de hosts zijn vergrendeld waar SSH Kan niet worden uitgevoerd, kunnen de minions niet worden uitgevoerd en de hosttests retourneren een resultaatcode: 2 (Fout) of 3 (Kritiek). Als dit gebeurt, bespreek dan de SSH machtigingen bij de beheerder.
• VxVerify2 is ontworpen om te worden uitgevoerd op Python 2.7. Dit pakket zou aanwezig moeten zijn op de VxRM VM en is meestal de enige beschikbare Python-versie. Als er meer Python-versies zijn, voer dan het volgende uit om deze te testen (dit heeft de -h optie, die --help):

python2.7 vxverify.pyc -h

VxVerify schrijft logboeken en uitvoerbestanden naar /tmp/vxv/. Als het niet voldoende machtigingen heeft, kan het niet worden uitgevoerd. Controleer de mapmachtigingen met de volgende opdrachten. Als er geen lees-/schrijfmachtigingen zijn voor alle gebruikers, voeg deze dan toe met chmod (mogelijk zijn rootmachtigingen vereist):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Als er machtigingenfouten blijven optreden bij VxVerify (bijvoorbeeld: 'Toestemming geweigerd voor het verwijderen van vorige logboeken.'), probeert u de vxv met de volgende opdracht (het root-wachtwoord is nodig voor sudo toegang). Na het uitvoeren van deze verwijderopdracht moet VxVerify opnieuw worden geïnstalleerd met alleen mystieke machtigingen:

sudo rm -r -d /tmp/vxv

• Een andere optie is om de VxVerify-uitvoerbestanden op te slaan in een nieuwe map. VxVerify maakt de structuur als deze niet bestaat met behulp van de -l of --log gevolgd door het pad waarop de logboeken moeten worden opgeslagen. Bijvoorbeeld:

python vxverify.pyc -l /tmp/vx1

Probleemoplossing: verschillen tussen VxVerify2 en VxVerify 3 (voor VxRail 7.0.010+)

Voor VxRail 7.0.010 en hoger moet VxVerify 3 worden gebruikt vanwege fundamentele wijzigingen in VxRM.

Dezelfde stappen voor probleemoplossing voor VxVerify2 zijn ook van toepassing op VxVerify3, behalve:

• De versie van Python voor VxVerify3 is 3.6.
• De locatie van de sitepakketten waarvoor VxVerify wijzigingen vereist, die zich op een van de onderstaande locaties bevinden:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Als beide mappen niet toegankelijk zijn voor de mystieke gebruiker, geeft het VxVerify-programma een foutmelding over de sitepakketten en afsluiten.
  • Een tijdelijke oplossing is het gebruik van de rootgebruiker.

Time-outs

Als het langer dan 20 minuten duurt om de minion te voltooien, moet VxVerify een time-outgebeurtenis opgeven in de overzichtstabel.

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

• De bijbehorende vxv.log Inschrijvingen hiervoor zijn:

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

• Dit moet worden gecontroleerd door te kijken naar het minion-logboek voor die host om te zien of de minion een fout heeft aangetroffen waardoor het is gestopt of dat het testen langzaam is voortgezet en het geen tijd meer had om te voltooien.
• Als een minion correct wordt voltooid, moeten de volgende regels in het logboek de volgende zijn:

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-bestandsoverdracht werkt niet

Als de minionresultaten van de host niet met behulp van SCP of SFTP terug naar VxRM kunnen worden overgebracht, kan het volgende worden weergegeven in de uitvoertabel:

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

• De bijbehorende vxv.log Inschrijvingen hiervoor zijn:

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

• Dit moet worden gecontroleerd door te kijken naar het minion-logboek voor die host om te zien of de minion een fout heeft aangetroffen waardoor het is gestopt of dat er een JSON-bestand is geproduceerd, maar niet toegankelijk is met behulp van SSH.
• Als een minion correct wordt voltooid, moeten de volgende de laatste regels in het logboek zijn, waaruit blijkt dat een JSON is opgeslagen in de /tmp Map van het knooppunt:

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 aanbevolen stappen om het bovenstaande op te lossen zijn:

• Als u VxVerify3 gebruikt, probeer dan uit te voeren met de --fix vlag, die een alternatief gebruikt SSH Mechanisme. Dit kan een aantal SSH problemen met machtigingen.
• Geef een nieuw pad op met behulp van -1 (de map hoeft niet eerst te worden gemaakt), wat kan helpen als VxRM-machtigingsfouten de bestandsoverdracht verhinderen:
• Bijvoorbeeld, > python vxv2.pyc -l \tmp\vxv0
• Als het bovenstaande nog steeds niet werkt, maakt u een snapshot van VxRM voordat u onnodige bestanden en mappen in /tmp en /home/mystic, zoals die eerder door VxVerify werden gebruikt.
• Start VxRM (VxRail Manager) opnieuw.

Als VxVerify een fout tegenkomt die niet met de bovenstaande stappen kan worden opgelost, slaat u de vxv-logboekbundel op zoals hierboven beschreven en escaleert u het probleem met Dell Support.

Aanmeldings- en referentiefouten in VxVerify2 en VxVerify3

• Voor het uitvoeren van tests op VxRM (VxRail Manager) en de VxRail knooppunten heeft VxVerify geen referenties nodig. VxVerify heeft rechtstreeks vanuit de VxRM-database toegang tot de versleutelde referenties en ontsleutelt deze voordat ze worden gebruikt. Soms kan er geen toegang worden verkregen tot de VC-beheerreferenties. In dat geval kunnen deze referenties worden opgegeven in de VxVerify-opdrachtregel:

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

• Het gebruik van enkele speciale tekens die zijn toegestaan door vCenter, kan problemen veroorzaken voor VxRail Manager (met name voor opdrachten die gebruikmaken van de Linux Shell). Controleer of geen van de volgende tekens wordt gebruikt in de wachtwoorden voor vCenter of de ESXi-hosts:

` $ % / \

• Als u twijfelt over welke gebruikersnaam wordt gebruikt voor het beheer, raadpleeg dan de vxv.log. Bijvoorbeeld:

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

• Tests naar vCenter met SSH vereisen een rootgebruikersnaam en -wachtwoord, die kunnen worden opgegeven met de -r en -w opties. De vCenter-tests worden alleen uitgevoerd als deze zijn opgegeven (hoewel als de rootgebruiker root, wat de standaardinstelling is, hoeft alleen het root-wachtwoord te worden opgegeven). Bijvoorbeeld:

python vxverify.py --verbose -w R00tPassword!

Voorbeelden van kritieke testfouten

Deze kunnen het gevolg zijn van ernstige fouten, waardoor verdere tests niet kunnen worden uitgevoerd. Als bijvoorbeeld de gebruikersnaam en het wachtwoord voor vCenter-beheer die zijn opgeslagen in VxRM niet actueel zijn, mislukken alle query's aan de VC API en kan er geen verdere test worden uitgevoerd. Voorbeelden hiervan zijn:

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

VxVerify maakt de volgende bestanden in /tmp/vxv/ of /var/log/mystic/vxv/ (tenzij een andere map voor logboekregistratie is opgegeven met behulp van de -l argument).  Deze bestanden worden allemaal opgeslagen in één archiefbestand in /tmpZoals /tmp/vxverify-569ae010.zip of /tmp/vxv_previous_01.zip.
Het handmatig controleren van deze bestanden kan helpen om problemen op het cluster te vinden, zelfs als het VxVerify-script niet volledig wordt voltooid:   

• vxv.log - (logbestand voor het VxVerify-script)
• minion_hostname.log - (extern logboek voor het minion-script dat op elke host wordt uitgevoerd)
• minion_hostname.txt - (externe tekstuitvoer voor elke minion, die laat zien welk testnummer bezig is)
• /json/host_uid.json - (bestand geproduceerd door elke minion, met de testresultaten, dat later wordt samengevoegd met andere hostgegevens en vervolgens wordt verwijderd)
• vxverify_tests.json - (gecombineerde output voor alle tests, die handmatig kan worden gecontroleerd om elk testresultaat te zien)
• vxtii.json - (gecombineerde antwoorden van hosts voor vragen zoals de iDRAC-hardware-inventaris)
• vxtii.txt - (rapport met een samenvatting van iDRAC- en ESXi-informatie voor elk knooppunt)
• vxverify.txt - (de overzichtstabel, die ook op het scherm wordt weergegeven, als VxVerify niet in de stille modus wordt uitgevoerd)
• vxverify.html - (gecombineerde VxVerify- en VxTii-rapporten in HTML-indeling) (alleen aanwezig bij het rechtstreeks uitvoeren van VxVerify, in plaats van ingesloten in VxRail Manager-healthchecks)