VxRail: risoluzione dei problemi con VxVerify prima di un aggiornamento di VxRail

Questo articolo della Knowledge Base è dedicato alla risoluzione dei problemi che impediscono l'esecuzione di VxVerify.

A questo articolo della Knowledge Base viene fatto riferimento da test che non dispongono di un articolo destinato alla risposta pertinente (ad esempio: Warning, Failure e Critical). Un esempio potrebbe essere una query che restituisce una risposta imprevista da una query.

VxVerify è progettato per rilevare problemi che potrebbero causare complicazioni o errori durante gli aggiornamenti di VxRail. VxVerify crea programmi Python, noti come Minions, che vengono inviati ai nodi VxRail. Di seguito sono riportati i risultati tipici dei test che dovrebbero essere previsti in vxverify_tests.json:

Se viene rilevato un risultato del test falso positivo, raccogliere i registri di VxVerify e contattare il Supporto Dell per aprire un ticket Jira VXV con VxRail Engineering.

Esistono diverse cause che possono impedire la corretta esecuzione di VxVerify.

• La causa più comune degli errori è la scadenza dello script Python. Ogni versione di VxVerify è impostata per durare solo due settimane dalla data di pubblicazione. Ciò non vale quando VxVerify viene eseguito come plug-in sul framework di controllo integrità di VxRail (che modifica la funzionalità VxVerify).
• Altri motivi possono essere problemi di autorizzazioni su VxRail Manager o problemi di comunicazione con gli host.
• Se la causa dell'evento non è chiara, contattare il Supporto Dell per aprire un ticket VXV con VxRail Engineering.

La sezione seguente fornisce istruzioni su come raccogliere i registri e risolvere eventuali problemi in caso di VxVerify non correttamente in esecuzione.

Raccolta dei registri per il coinvolgimento del supporto

Quando si contatta il supporto per i problemi correlati a VxVerify, caricare l'intero file vxv cartella per l'analisi o la cartella vxverify Registro .zip file. Le versioni standalone correnti di VxVerify salvano un file archiviato in /tmp, che contiene tutti i risultati e i registri necessari per l'analisi.

Ad esempio: /tmp/vxverify-c9.zip

Oltre a questo .zip dall'esecuzione più recente di VxVerify, potrebbero essere presenti fino a cinque set di registri precedenti in /tmp Cartella. I nomi hanno la data/ora in cui sono stati eseguiti negli attributi del file: 

vxv_previous_01.zip

In alternativa, eseguire il comando seguente per archiviare tutti i file pertinenti:

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

Risoluzione dei problemi

Procedure tipiche di risoluzione dei problemi per l'esecuzione di VxVerify 2 (per VxRail 4.5, 4.7 e 7.0.000)

• Per l'esecuzione di VxVerify è necessario Python e la riga di comando per eseguirlo è la seguente:

python /tmp/vxv/vxverify.pyc

• Se si verifica un errore magic number , in genere significa che si sta utilizzando la versione errata di VxVerify per la versione Python su VxRM. Ad esempio, l'errore riportato di seguito si verifica se si esegue VxVerify 2 sulla versione 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Per verificare di utilizzare la versione corretta di VxVerify, consultare l'articolo (il link sottostante richiede l'autenticazione al portale del supporto Dell):
  • VxRail: come eseguire lo strumento VxRail Verify (sezione Versioni di VxVerify ) 
• VxVerify crea programmi denominati minion, che vengono inviati, eseguiti e recuperati utilizzando SSH. Se SSH può essere utilizzato, anche se non è già abilitato, VxVerify si accende SSH per ciascun host per i comandi da eseguire. Se gli host sono bloccati dove SSH non può essere eseguito, i minion non possono essere eseguiti e i test sull host restituiscono un codice di risultato: 2 (Errore) o 3 (Critico). In questo caso, discutere il SSH Autorizzazioni con l'amministratore.
• VxVerify2 è progettato per essere eseguito su Python 2.7, che dovrebbe essere presente sulla VM VxRM e che in genere è l'unica versione di Python disponibile. Se sono presenti più versioni di Python, eseguire il comando seguente per verificarlo (questo ha l'attributo -h opzione, che è --help):

python2.7 vxverify.pyc -h

VxVerify scrive i registri e i file di output in /tmp/vxv/. Se non dispone di autorizzazioni sufficienti, non può essere eseguito. Controllare le autorizzazioni della cartella con i seguenti comandi. Se non sono presenti autorizzazioni di lettura/scrittura per tutti gli utenti, aggiungerle con chmod (potrebbero essere necessarie autorizzazioni root):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Se gli errori di autorizzazione persistono con VxVerify (ad esempio: "Autorizzazione negata per l'eliminazione dei registri precedenti."), provare a eliminare il file vxv cartella con il seguente comando (la password root è necessaria per sudo accesso). Dopo aver eseguito questo comando di eliminazione, è necessario installare nuovamente VxVerify utilizzando solo le autorizzazioni mystic:

sudo rm -r -d /tmp/vxv

• Un'altra opzione consiste nel salvare i file di output di VxVerify in una nuova cartella. VxVerify crea la struttura ad albero se non esiste utilizzando il metodo -l o --log , seguito dal percorso in cui devono essere salvati i registri. Ad esempio:

python vxverify.pyc -l /tmp/vx1

Risoluzione dei problemi relativi alle differenze tra VxVerify2 e VxVerify 3 (per VxRail 7.0.010+)

Per VxRail 7.0.010 e versioni successive, è necessario utilizzare VxVerify 3 a causa di modifiche fondamentali in VxRM.

Le stesse procedure di risoluzione dei problemi per VxVerify2 si applicano anche a VxVerify3, TRANNE:

• La versione di Python per VxVerify3 è la 3.6.
• La posizione dei pacchetti del sito che VxVerify richiede modifiche, che si trovano in una delle posizioni seguenti:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Se entrambe queste cartelle sono inaccessibili all'utente mystic, il programma VxVerify restituisce un messaggio di errore sui site packages e si chiude.
  • Una soluzione alternativa consiste nell'utilizzare l'utente root.

Timeout

Se il completamento del minion richiede più di 20 minuti, VxVerify deve fornire un evento di timeout nella tabella di riepilogo.

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

• Il corrispondente vxv.log Le relative voci sono:

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

• Questa operazione deve essere verificata esaminando il registro dei minion per l'host per verificare se il minion ha riscontrato un errore che ne ha causato l'arresto o se il test continua lentamente e non ha esaurito il tempo per il completamento.
• Se un minion viene completato correttamente, le ultime righe del registro dovrebbero essere le seguenti:

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.

Il trasferimento del file JSON non funziona

Se i risultati del minion host non possono essere trasferiti nuovamente a VxRM utilizzando SCP o SFTP, nella tabella di output potrebbe essere visualizzato quanto segue:

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

• Il corrispondente vxv.log Le relative voci sono:

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

• Questa operazione deve essere verificata esaminando il registro dei minion per l'host per verificare se il minion ha riscontrato un errore che ne ha causato l'arresto o se è stato prodotto un file JSON, ma non è stato possibile accedervi utilizzando SSH.
• Se un minion viene completato correttamente, le ultime righe del registro devono essere riportate di seguito, a dimostrazione del corretto salvataggio di un JSON in /tmp Cartella del nodo:

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.

La procedura consigliata per risolvere il problema è la seguente:

• Se si utilizza VxVerify3, provare a eseguire con il --fix flag, che utilizza un SSH Meccanismo. In questo modo è possibile evitare SSH problemi di autorizzazioni.
• Specificare un nuovo percorso utilizzando -1 (non è necessario creare prima la cartella), il che può essere utile se gli errori di autorizzazione di VxRM impediscono il trasferimento dei file:
• Per esempio: > python vxv2.pyc -l \tmp\vxv0
• Se quanto sopra non risolve il problema, eseguire una snapshot di VxRM prima di eliminare eventuali file e cartelle non necessari in /tmp e /home/mystic, come quelli utilizzati in precedenza da VxVerify.
• Riavviare VxRM (VxRail Manager).

Se VxVerify rileva un errore che non può essere corretto con i passaggi precedenti, salvare il pacchetto di registro vxv come descritto in precedenza ed eseguire l'escalation del problema con il supporto Dell.

Errori di accesso e credenziali in VxVerify2 e VxVerify3

• Per eseguire test su VxRM (VxRail Manager) e sui nodi VxRail, VxVerify non richiede alcuna credenziale. VxVerify può accedere alle credenziali crittografate direttamente dal database VxRM e decrittografarle prima di utilizzarle. A volte non è possibile accedere alle credenziali di gestione di VC, nel qual caso è possibile specificare queste credenziali nella riga di comando di VxVerify:

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

• L'utilizzo di alcuni caratteri speciali consentiti da vCenter può causare problemi per VxRail Manager (in particolare per i comandi che utilizzano la shell di Linux). Verificare che nelle password per vCenter o gli host ESXi non siano utilizzati i seguenti caratteri:

` $ % / \

• In caso di dubbi sul nome utente utilizzato per la gestione, consultare il vxv.log. Ad esempio:

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

• I test su vCenter tramite SSH richiedono un nome utente e una password root, che possono essere specificati con -r e -w opzioni rispettivamente. I test vCenter vengono eseguiti solo se sono specificate queste credenziali (anche se se l'utente root è root, che è l'impostazione predefinita, è necessario specificare solo la password root). Ad esempio:

python vxverify.py --verbose -w R00tPassword!

Esempi di errori di test critici

Possono essere conseguenza di errori gravi che impediscono l'esecuzione di ulteriori test. Ad esempio, se il nome utente e la password di gestione di vCenter salvati in VxRM non sono aggiornati, tutte le query all'API VC hanno esito negativo e non è possibile eseguire ulteriori test. Ecco alcuni esempi:

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

File VxVerify

VxVerify crea i seguenti file in /tmp/vxv/ o /var/log/mystic/vxv/ (a meno che non venga specificata un'altra cartella di registrazione utilizzando il -l argomento).  Questi file vengono tutti salvati in un unico file di archivio in /tmpCome /tmp/vxverify-569ae010.zip o /tmp/vxv_previous_01.zip.
Il controllo manuale di questi file può aiutare a individuare i problemi nel cluster anche se lo script VxVerify non viene completamente completato:   

• vxv.log - (file di registro per lo script VxVerify)
• minion_hostname.log - (registro remoto per lo script minion in esecuzione su ciascun host)
• minion_hostname.txt - (output di testo remoto per ogni minion, che mostra il numero di test in corso)
• /json/host_uid.json - (file prodotto da ogni minion, con i risultati del test, che viene successivamente unito ad altri dati dell'host, quindi eliminato)
• vxverify_tests.json - (output combinato per tutti i test, che può essere controllato manualmente per vedere ogni risultato del test)
• vxtii.json - (risposte combinate degli host per query come l'inventario hardware di iDRAC)
• vxtii.txt - (report che riepiloga le informazioni su iDRAC ed ESXi per ciascun nodo)
• vxverify.txt - (la tabella di riepilogo, visualizzata anche sullo schermo, se VxVerify non viene eseguito in modalità silenziosa)
• vxverify.html - (report combinati di VxVerify e VxTii in formato HTML) (presente solo quando si esegue VxVerify direttamente, anziché integrato nei controlli integrità di VxRail Manager)