VxRail: Solução de problemas com o VxVerify antes de um upgrade do VxRail
Summary: Resoluções de problemas comuns que podem ocorrer durante a execução do VxVerify para pré-verificar um upgrade do Dell VxRail.
Symptoms
Este artigo da base de conhecimento é dedicado à solução de problemas que impedem que o VxVerify seja executado com sucesso.
Este artigo de conhecimento é referenciado a partir de testes que não têm um artigo destinado para sua resposta relevante (por exemplo: Warning, Failure e Critical). Um exemplo disso seria uma consulta que retorna uma resposta inesperada de uma consulta.
O VxVerify foi projetado para detectar problemas que podem causar complicações ou falhas durante os upgrades do VxRail. O VxVerify cria programas Python conhecidos como Minions, que são enviados aos nós do VxRail. Abaixo estão os resultados de teste típicos que devem ser esperados em vxverify_tests.json:
| Resultado do teste | Código do resultado | Ação sugerida |
|---|---|---|
| Aprovado | 0 | Todos os testes aprovados nesta categoria de verificação de integridade:
Nenhuma ação é necessária. |
| Warning | 1 | A verificação de integridade encontrou um problema que deve ser considerado antes de iniciar o upgrade.
Siga o artigo da base de conhecimento relacionado para resolver a advertência (o número do artigo é listado como parte da advertência). |
| Falha | 2 | Deve ser resolvido antes de qualquer upgrade.
Analise a mensagem retornada deste evento e, em seguida, analise o log vxv.log e minion. |
| Essencial | 3 | O erro crítico impediu o VxVerify de realizar um teste relevante.
Isso pode impedir a execução de testes adicionais. Analise a mensagem retornada deste evento e, em seguida, analise o log vxv.log e minion. Consulte o exemplo na seção Informações adicionais abaixo. |
| Py_Crash | 3 ou 9 | Esse evento ocorre quando ocorre um erro não tratado do Python ao executar um teste.
Analise a mensagem retornada desse evento e, em seguida, analise o log vxv.log e minion (consulte a Nota 1). |
Se algum resultado de teste falso positivo for detectado, colete os logs do VxVerify e entre em contato com o Suporte Dell para abrir um tíquete do Jira VXV com a engenharia do VxRail.
Cause
Há várias causas que podem impedir que o VxVerify seja executado com sucesso.
- A causa mais comum de falhas é o script Python ter expirado. Cada versão do VxVerify é definida para durar apenas duas semanas a partir da data em que foi publicada. Isso não se aplica quando o VxVerify é executado como um plug-in para a estrutura de verificação de integridade do VxRail (que altera a funcionalidade do VxVerify).
- Outros motivos podem ser problemas de permissões no VxRail Manager ou problemas de comunicação com os hosts.
- Se a causa do evento não estiver clara, entre em contato com o Suporte Dell para abrir um tíquete do VXV com a equipe de engenharia do VxRail.
Resolution
A seção abaixo fornece instruções sobre como coletar logs e solucionar problemas se o VxVerify não estiver sendo executado corretamente.
Coleta de registros para engajamento do suporte
Ao envolver o suporte com problemas relacionados ao VxVerify, carregue todo o arquivo vxv pasta para análise, ou o vxverify Log .zip . As versões atuais independentes do VxVerify salvam um arquivo arquivado no /tmp, que possui todos os resultados e logs necessários para análise.
Por exemplo: /tmp/vxverify-c9.zip
Além disso, .zip da execução mais recente do VxVerify, até cinco conjuntos de registros anteriores também podem estar presentes no /tmp Pasta. Os nomes têm a data e hora em que eles foram executados nos atributos do arquivo:
vxv_previous_01.zip
Como alternativa, execute o comando abaixo para arquivar todos os arquivos relevantes:
tar cvzf vxverify-2020-12-31.tgz /tmp/vxv/
Solução de problemas
Etapas típicas de solução de problemas para executar o VxVerify 2 (para VxRail 4.5, 4.7 e 7.0.000)
- O VxVerify precisa que o Python seja executado. Esta é a linha de comando a ser usada:
python /tmp/vxv/vxverify.pyc
- Se ocorrer um erro de número mágico , isso geralmente significa que a versão incorreta do VxVerify está sendo usada para a versão do Python no VxRM. Por exemplo, o erro abaixo será encontrado se você executar o VxVerify 2 na versão 7.0.320.
RuntimeError: Bad magic number in .pyc file
- Para verificar se a versão correta do VxVerify está sendo usada, consulte o artigo (o link abaixo requer autenticação no portal do Suporte Dell):
- VxRail: Como executar a ferramenta VxRail Verify (seção VxVerify Releases )
- O VxVerify cria programas chamados minions, que são enviados, executados e recuperados usando
SSH. SeSSHpode ser usado, mesmo que ainda não esteja habilitado, o VxVerify é ativadoSSHpara cada host para os comandos a serem executados. Se os hosts estiverem bloqueados em queSSHNão é possível executar, os minions não podem ser executados e os testes de host retornam um código de resultado: 2 (Falha) ou 3 (Crítico). Se isso acontecer, discuta oSSHpermissões com o administrador. - O VxVerify2 foi projetado para ser executado no Python 2.7, que deve estar presente na VM do VxRM e, geralmente, é a única versão do Python disponível. Se houver mais versões do Python, execute o seguinte para testá-lo (ele tem o
-hopção, que é--help):
python2.7 vxverify.pyc -h
O VxVerify grava registros e arquivos de saída no /tmp/vxv/. Se ele não tiver permissões suficientes, ele não poderá ser executado. Verifique as permissões da pasta com os seguintes comandos. Se não houver permissões de leitura/gravação para todos os usuários, adicione-as com chmod (permissões root podem ser necessárias):
$ ls -lad /tmp/vxv drwxrwxrwx 3 mystic users 4096 Oct 1 07:42 vxv
- Se os erros de permissões persistirem com o VxVerify (por exemplo: 'Permission denied for delete previous logs.'), tente excluir o
vxvcom o seguinte comando (a senha de root é necessária parasudoacesso). Depois de executar esse comando de exclusão, o VxVerify deve ser instalado novamente usando apenas permissões mystic:
sudo rm -r -d /tmp/vxv
- Outra opção é salvar os arquivos de saída do VxVerify em uma nova pasta. O VxVerify criará a árvore, se ela não existir, usando o comando
-lou--log, seguida pelo caminho no qual os registros devem ser salvos. Por exemplo:
python vxverify.pyc -l /tmp/vx1
Solução de problemas de diferenças entre o VxVerify2 e o VxVerify 3 (para VxRail 7.0.010+)
No VxRail 7.0.010 e posterior, o VxVerify 3 deve ser usado devido a alterações fundamentais no VxRM.
As mesmas etapas de solução de problemas do VxVerify2 também se aplicam ao VxVerify3, EXCETO:
- A versão do Python para VxVerify3 é 3.6.
- O local dos pacotes do site que o VxVerify requer alterações, que ficam em um dos locais abaixo:
/mystic/telemetry/DCManager/venv/lib/python3.6/site-packages/mystic/radar/venv/lib/python3.6/site-packages
- Se ambas as pastas estiverem inacessíveis a partir do usuário mystic, o programa VxVerify exibirá uma mensagem de erro sobre os pacotes do site e a saída.
- Uma solução temporária é usar o usuário root.
Tempos de espera excedidos
Se o minion demorar mais de 20 minutos para ser concluído, o VxVerify deverá fornecer um evento de tempo de espera excedido na tabela de resumo.
| Node-name |Critical 66460| minion: Maximum run time for minion exceeded
- O correspondente
vxv.logAs entradas para isso são:
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
- Isso deve ser verificado examinando o registro do minion desse host para ver se o minion encontrou um erro que o fez parar ou se o teste estava continuando lentamente e ficou sem tempo para ser concluído.
- Se um minion for concluído corretamente, estas devem ser as últimas linhas do log:
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.
A transferência de arquivos JSON não está funcionando
Se os resultados do minion do host não puderem ser transferidos de volta para o VxRM usando SCP ou SFTP, o seguinte poderá ser visto na tabela de saída:
| Node-name |Critical 66460| minion: No JSON downloaded from node via SSH
- O correspondente
vxv.logAs entradas para isso são:
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
- Isso deve ser verificado examinando o registro do minion desse host para ver se o minion encontrou um erro que o fez parar ou se um arquivo JSON foi produzido, mas não pôde ser acessado usando
SSH. - Se um minion for concluído corretamente, estas deverão ser as últimas linhas do log, que mostram que um JSON foi salvo com sucesso no
/tmpPasta do nó:
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.
As etapas recomendadas para solucionar o problema acima seriam:
- Se estiver usando o VxVerify3, tente executar com o
--fixflag, que usa uma alternativaSSHMecanismo. Isso pode evitar algunsSSHproblemas de permissões. - Especifique um novo caminho usando
-1(a pasta não precisa ser criada primeiro), o que pode ajudar se erros de permissão do VxRM estiverem impedindo a transferência de arquivos: - Por exemplo:
> python vxv2.pyc -l \tmp\vxv0 - Se mesmo assim não funcionar, faça um snapshot do VxRM antes de apagar quaisquer arquivos e pastas desnecessários no
/tmpe/home/mystic, como os usados anteriormente pelo VxVerify. - Reinicie o VxRM (VxRail Manager).
Se o VxVerify identificar um erro que não pode ser corrigido com as etapas acima, salve o pacote de logs do vxv conforme detalhado acima e encaminhe o problema para o Suporte Dell.
Erros de login e credenciais no VxVerify2 e no VxVerify3
- Para executar testes no VxRM (VxRail Manager) e nos nós do VxRail, o VxVerify não exige nenhuma credencial. O VxVerify pode acessar as credenciais criptografadas diretamente do banco de dados do VxRM e descriptografá-las antes de usá-las. Às vezes, não é possível acessar as credenciais de gerenciamento do VC. Nesse caso, elas podem ser especificadas na linha de comando do VxVerify:
python vxverify.py --verbose -u vxrailmgmt@localos -p ChangeMe1!
- O uso de alguns caracteres especiais, permitidos pelo vCenter, pode causar problemas no VxRail Manager (principalmente para qualquer comando que utilize o Shell Linux). Verifique se nenhum dos seguintes caracteres é usado nas senhas do vCenter ou dos hosts do ESXi:
` $ % / \
- Em caso de dúvida sobre qual nome de usuário está sendo usado para gerenciamento, consulte o
vxv.log. Por exemplo:
... - DEBUG Users from runtime & settings records: vxrailmgmt@localos & vxrailmgmt@localos
- Os testes no vCenter usando SSH exigem um nome de usuário root e uma senha, que podem ser especificados com o comando
-re-wopções, respectivamente. Os testes do vCenter só serão executados se forem especificados (embora se o usuário root forroot, que é o padrão, então somente a senha de root deve ser especificada). Por exemplo:
python vxverify.py --verbose -w R00tPassword!
Additional Information
Exemplos de falhas críticas de teste
Elas podem ser decorrentes de erros graves, que impedem que testes adicionais sejam executados. Por exemplo, se o nome de usuário e a senha de gerenciamento do vCenter salvos no VxRM não estiverem atualizados, todas as consultas à API do VC falharão e nenhum teste adicional poderá ser executado. Alguns exemplos são:
#========================#======#=========#====================================================================#==============# | 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
Arquivos VxVerify
O VxVerify cria os seguintes arquivos em /tmp/vxv/ ou /var/log/mystic/vxv/ (a menos que outra pasta de registro seja especificada usando o -l argumento). Esses arquivos são todos salvos em um único arquivo morto em /tmpComo /tmp/vxverify-569ae010.zip ou /tmp/vxv_previous_01.zip.
A verificação manual desses arquivos pode ajudar a encontrar problemas no cluster, mesmo que o script do VxVerify não seja totalmente concluído:
-
vxv.log- (arquivo de log para o script do VxVerify) -
minion_hostname.log- (log remoto para o script minion em execução em cada host) -
minion_hostname.txt- (saída de texto remoto para cada minion, mostrando qual número de teste está em andamento) -
/json/host_uid.json- (arquivo produzido por cada minion, com os resultados do teste, que depois é mesclado com outros dados do host, depois excluído) -
vxverify_tests.json- (saída combinada para todos os testes, que pode ser verificada manualmente para ver todos os resultados do teste) -
vxtii.json- (respostas combinadas de hosts para consultas como o inventário de hardware do iDRAC) -
vxtii.txt- (relatório resumindo as informações do iDRAC e ESXi para cada nó) -
vxverify.txt- (a tabela de resumo, que também é mostrada na tela, se o VxVerify não for executado no modo silencioso) -
vxverify.html- (relatórios combinados do VxVerify e do VxTii em formato HTML) (presente apenas ao executar o VxVerify diretamente, em vez de incorporado nas verificações de integridade do VxRail Manager)