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

Summary: Risoluzioni dei problemi comuni che possono verificarsi durante l'esecuzione di VxVerify per controllare preventivamente un aggiornamento di Dell VxRail.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

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:

Risultato del test Codice risultato Azione consigliata
Riuscito 0 Tutti i test sono stati superati per questa categoria di controllo integrità:
non sono richieste azioni.
Avviso 1 Il controllo integrità ha rilevato un problema che deve essere preso in considerazione prima di iniziare l'aggiornamento.
Seguire l'articolo della Knowledge Base correlato per risolvere l'avvertenza (il numero dell'articolo è elencato come parte dell'avvertenza).
Esito negativo 2 Deve essere risolto prima di qualsiasi aggiornamento. 
Esaminare il messaggio restituito da questo evento, quindi esaminare il registro vxv.log e minion.
Critico 3 Un errore critico ha impedito a VxVerify di eseguire un test pertinente.
Ciò potrebbe impedire l'esecuzione di ulteriori test.
Esaminare il messaggio restituito da questo evento, quindi esaminare il registro vxv.log e minion. Vedere l'esempio nella sezione Informazioni aggiuntive riportata di seguito.
Py_Crash 3 o 9 Questo evento si verifica quando si è verificato un errore Python non gestito durante l'esecuzione di un test. 
Esaminare il messaggio restituito da questo evento, quindi esaminare il registro vxv.log e minion (vedere la nota 1).

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.

Cause

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.

Resolution

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):
  • 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!

Additional Information

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)

     

    Affected Products

    VxRail, VxRail Appliance Series

    Products

    VxRail Appliance Family
    Article Properties
    Article Number: 000066460
    Article Type: Solution
    Last Modified: 22 Jul 2026
    Version:  21
    Find answers to your questions from other Dell users
    Support Services
    Check if your device is covered by Support Services.