VxRail: Solución de problemas con VxVerify antes de una actualización de VxRail

Este artículo de la base de conocimientos está dedicado a la solución de problemas que impiden que VxVerify se ejecute correctamente.

Se hace referencia a este artículo de la base de conocimientos desde pruebas que no tienen un artículo dirigido para su respuesta pertinente (por ejemplo: Advertencia, Falla y Crítico). Un ejemplo de esto sería una consulta que devuelve una respuesta inesperada de una consulta.

VxVerify está diseñado para detectar problemas que podrían causar complicaciones o fallas durante las actualizaciones de VxRail. VxVerify crea programas de Python conocidos como Minions, los cuales se envían a los nodos de VxRail. A continuación, se muestran los resultados de las pruebas típicas que se deben esperar en vxverify_tests.json:

Si se descubre algún resultado falso positivo en la prueba, recopile los registros de VxVerify y comuníquese con el soporte de Dell para abrir un ticket de Jira VXV con el equipo de ingeniería de VxRail.

Hay varias causas que pueden impedir que VxVerify se ejecute correctamente.

• La causa más común de las fallas es que el script de Python haya caducado. Cada versión de VxVerify está configurada para durar solo dos semanas a partir de la fecha en que se publicó. Esto no se aplica cuando VxVerify se ejecuta como un plug-in a la infraestructura de evaluación del estado de VxRail (que cambia la funcionalidad de VxVerify).
• Otras razones pueden ser problemas de permisos en VxRail Manager o problemas de comunicación con los hosts.
• Si la causa del evento no es clara, comuníquese con el soporte de Dell para abrir un ticket de VXV con el equipo de ingeniería de VxRail.

En la siguiente sección, se proporcionan instrucciones sobre cómo recopilar registros y solucionar problemas si VxVerify no se ejecuta correctamente.

Recopilación de registros para la participación del soporte

Cuando solicite soporte con problemas relacionados con VxVerify, cargue toda la información archivada vxv carpeta para el análisis, o la carpeta vxverify registro .zip file. Las versiones actuales independientes de VxVerify guardan un archivo archivado en /tmp, que tiene todos los resultados y registros necesarios para el análisis.

Por ejemplo: /tmp/vxverify-c9.zip

Además de esto .zip de la ejecución más reciente de VxVerify, es posible que también haya hasta cinco conjuntos de registros anteriores en el archivo /tmp carpeta. Los nombres tienen la fecha y hora en la que se ejecutaron en los atributos del archivo: 

vxv_previous_01.zip

Como alternativa, ejecute el siguiente comando para archivar todos los archivos pertinentes:

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

Solución de problemas

Pasos típicos de solución de problemas para ejecutar VxVerify 2 (para VxRail 4.5, 4.7 y 7.0.000)

• VxVerify necesita que Python se ejecute y la línea de comandos para ejecutarla es la siguiente:

python /tmp/vxv/vxverify.pyc

• Si se produce un error de número mágico , por lo general, esto significa que se está utilizando la versión incorrecta de VxVerify para la versión de Python en VxRM. Por ejemplo, se produce el siguiente error si ejecuta VxVerify 2 en 7.0.320.

RuntimeError: Bad magic number in .pyc file

• Para comprobar que se esté utilizando la versión correcta de VxVerify, consulte el artículo (el siguiente enlace requiere autenticación en el portal de soporte de Dell):
  • VxRail: Cómo ejecutar la herramienta VxRail Verify (sección Versiones de VxVerify ) 
• VxVerify crea programas que se denominan minions, los cuales se envían, ejecutan y recuperan mediante SSH. Si SSH incluso si aún no está habilitado, VxVerify se enciende SSH para cada host para que se ejecuten los comandos. Si los hosts están bloqueados donde SSH no se pueden ejecutar, los minions no pueden ejecutarse y las pruebas de host devuelven un código de resultado: 2 (falla) o 3 (crítico). Si esto sucede, analice el SSH permisos con el administrador.
• VxVerify2 está diseñado para ejecutarse en Python 2.7, que debe estar presente en la VM de VxRM y, por lo general, es la única versión de Python disponible. Si hay más versiones de Python, ejecute lo siguiente para probarla (esta tiene el atributo -h opción, que es --help):

python2.7 vxverify.pyc -h

VxVerify escribe registros y archivos de salida en /tmp/vxv/. Si no tiene permisos suficientes, no se puede ejecutar. Compruebe los permisos de la carpeta con los siguientes comandos. Si no hay permisos de lectura/escritura para todos los usuarios, agréguelos con chmod (es posible que se requieran permisos raíz):

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• Si los errores de permisos persisten con VxVerify (por ejemplo: "Permiso denegado para eliminar registros anteriores"), intente eliminar el vxv carpeta con el siguiente comando (la contraseña raíz es necesaria para sudo acceso). Después de ejecutar este comando de eliminación, VxVerify se debe volver a instalar utilizando solo los permisos de mystic:

sudo rm -r -d /tmp/vxv

• Otra opción es guardar los archivos de resultado de VxVerify en una nueva carpeta. VxVerify crea el árbol si no existe mediante -l o --log , seguido de la ruta en la que se deben guardar los registros. Por ejemplo:

python vxverify.pyc -l /tmp/vx1

Diferencias de solución de problemas entre VxVerify2 y VxVerify 3 (para VxRail 7.0.010+)

Para VxRail 7.0.010 y versiones posteriores, se debe utilizar VxVerify 3, debido a cambios fundamentales en VxRM.

Los mismos pasos de solución de problemas para VxVerify2 también se aplican a VxVerify3, EXCEPTO:

• La versión de Python para VxVerify3 es 3.6.
• La ubicación de los paquetes de sitio que VxVerify requiere cambios, que se encuentran en una de las siguientes ubicaciones:
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• Si no se puede acceder a ambas carpetas desde el usuario mystic, el programa VxVerify muestra un mensaje de error acerca de los paquetes del sitio y sale.
  • Una solución alternativa es usar el usuario raíz.

Tiempos de espera agotados

Si el minion tarda más de 20 minutos en completarse, VxVerify debe proporcionar un evento de tiempo de espera agotado en la tabla de resumen.

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

• El correspondiente vxv.log Las entradas para esto son:

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

• Esto se debe comprobar observando el registro de minion de ese host para ver si el minion encontró un error que hizo que se detuviera o si la prueba continuaba lentamente y se quedó sin tiempo para completarse.
• Si un minion se completa correctamente, las siguientes deben ser las últimas líneas del registro:

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 transferencia de archivos JSON no funciona

Si los resultados de minion del host no se pueden transferir mediante SCP o SFTP a VxRM, es posible que se vea lo siguiente en la tabla de salida:

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

• El correspondiente vxv.log Las entradas para esto son:

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

• Esto se debe comprobar observando el registro de minion de ese host para ver si el minion encontró un error que hizo que se detuviera o si se produjo un archivo JSON, pero no se pudo acceder a él mediante SSH.
• Si un minion se completa correctamente, las siguientes deben ser las últimas líneas del registro, lo que muestra que un JSON se guardó correctamente en el /tmp Carpeta 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.

Los pasos recomendados para solucionar los problemas anteriores serían los siguientes:

• Si usa VxVerify3, intente ejecutar con el comando --fix flag, que utiliza una alternativa SSH mecanismo. Esto puede evitar algunos SSH Problemas de permisos.
• Especifique una nueva ruta mediante -1 (no es necesario crear la carpeta primero), lo que puede ayudar si los errores de permisos de VxRM impiden la transferencia de archivos:
• Por ejemplo, > python vxv2.pyc -l \tmp\vxv0
• Si lo anterior aún no funciona, tome una instantánea de VxRM antes de limpiar los archivos y carpetas innecesarios en /tmp y /home/mystic, como los utilizados anteriormente por VxVerify.
• Reinicie VxRM (VxRail Manager).

Si VxVerify encuentra un error que no se puede corregir con los pasos anteriores, guarde el paquete de registros de vxv como se detalló anteriormente y escale el problema al soporte de Dell.

Errores de inicio de sesión y credenciales en VxVerify2 y VxVerify3

• Para ejecutar pruebas en VxRM (VxRail Manager) y los nodos de VxRail, VxVerify no requiere ninguna credencial. VxVerify puede acceder a las credenciales cifradas directamente desde la base de datos de VxRM y descifrarlas antes de usarlas. En ocasiones, no se puede acceder a las credenciales de administración de VC, en cuyo caso estas credenciales se pueden especificar en la línea de comandos de VxVerify:

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

• El uso de algunos caracteres especiales permitidos por vCenter puede causar problemas para VxRail Manager (en especial, para cualquier comando que utilice Linux Shell). Compruebe que no se utilice ninguno de los siguientes caracteres en las contraseñas de vCenter o de los hosts ESXi:

` $ % / \

• Si tiene dudas sobre qué nombre de usuario se utiliza para la administración, consulte el vxv.log. Por ejemplo:

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

• Las pruebas a vCenter mediante SSH requieren un nombre de usuario raíz y una contraseña, que se pueden especificar con el -r y -w respectivamente. Las pruebas de vCenter solo se ejecutan si se especifican (aunque si el usuario raíz es root, que es el valor predeterminado, solo se debe especificar la contraseña raíz). Por ejemplo:

python vxverify.py --verbose -w R00tPassword!

Ejemplos de fallas críticas de pruebas

Estos pueden ser el resultado de errores graves, lo que impide que se ejecuten más pruebas. Por ejemplo, si el nombre de usuario y la contraseña de administración de vCenter guardados en VxRM no están actualizados, todas las consultas a la API de VC fallan y no se pueden ejecutar más pruebas. Algunos ejemplos de esto incluyen los siguientes:

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

Archivos VxVerify

VxVerify crea los siguientes archivos en /tmp/vxv/ o /var/log/mystic/vxv/ (a menos que se especifique otra carpeta de registro mediante el método -l argumento).  Todos estos archivos se guardan en un único archivo en /tmp, como por ejemplo /tmp/vxverify-569ae010.zip o /tmp/vxv_previous_01.zip.
La comprobación manual de estos archivos puede ayudar a encontrar problemas en el clúster, incluso si el script de VxVerify no se completa por completo:   

• vxv.log - (archivo de registro para el script de VxVerify)
• minion_hostname.log - (registro remoto para el script minion que se ejecuta en cada host)
• minion_hostname.txt - (salida de texto remota para cada minion, que muestra qué número de prueba está en curso)
• /json/host_uid.json - (archivo producido por cada minion, con los resultados de la prueba, que luego se fusiona con otros datos del host y luego se elimina)
• vxverify_tests.json - (salida combinada para todas las pruebas, que se puede verificar manualmente para ver todos los resultados de las pruebas)
• vxtii.json - (respuestas combinadas de hosts para consultas como el inventario de hardware de iDRAC)
• vxtii.txt - (informe que resume la información de iDRAC y ESXi para cada nodo)
• vxverify.txt - (la tabla de resumen, que también se muestra en la pantalla, si VxVerify no se ejecuta en modo silencioso)
• vxverify.html - (informes combinados de VxVerify y VxTii en formato HTML) (solo está presente cuando se ejecuta VxVerify directamente, en lugar de estar integrado en las evaluaciones del estado de VxRail Manager)