VxRail：在升级 VxRail 之前对 VxVerify 问题进行故障处理

本知识库文章专门用于对阻止 VxVerify 成功运行的问题进行故障处理。

此知识文章引用自测试，这些测试没有针对其相关响应的文章（例如：警告、故障和严重）。例如，从查询返回意外响应的查询。

VxVerify 旨在检测在 VxRail 升级期间可能导致并发症或故障的问题。VxVerify 创建称为 Minion 的 Python 程序，这些程序将发送到 VxRail 节点。以下是 中应预期的典型测试结果 vxverify_tests.json：

如果发现任何误报测试结果，请收集 VxVerify 日志并联系戴尔支持，以向 VxRail 工程部门创建 Jira VXV 工单。

有多种原因会阻止 VxVerify 成功运行。

• 最常见的失败原因是 Python 脚本已过期。每个 VxVerify 版本都设置为自发布之日起仅在两周内有效。当 VxVerify 作为 VxRail 运行状况检查框架的插件程序运行时（这会更改 VxVerify 功能），这不适用。
• 其他原因可能是 VxRail Manager 上的 权限问题 或与主机的 通信问题 。
• 如果事件原因不清楚，请联系戴尔支持，向 VxRail 工程部门提交 VXV 工单。

以下部分提供有关如何收集日志并在 VxVerify 未正常运行时进行故障处理的说明。

收集日志以进行支持参与

在联系支持人员解决 VxVerify 相关问题时， 请上传整个已归档的 vxv 用于分析的文件夹 ，或 vxverify 日志 .zip 文件。当前独立的 VxVerify 版本将归档文件保存到 /tmp，其中包含所有必要的结果和日志以供分析。

例如： /tmp/vxverify-c9.zip

除此之外 .zip 文件，在最近一次运行的 VxVerify 中，中还可能存在多达五组以前的日志 /tmp 文件夹。名称包含在文件属性中运行的日期时间： 

vxv_previous_01.zip

或者，运行以下命令以归档所有相关文件：

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

故障处理

运行 VxVerify 2（适用于 VxRail 4.5、4.7 和 7.0.000）的典型故障处理步骤

• VxVerify 需要 Python 来运行，运行它的命令行如下：

python /tmp/vxv/vxverify.pyc

• 如果发生 幻数错误 ，这通常意味着为 VxRM 上的 Python 版本使用了错误的 VxVerify 版本。例如，如果您在 7.0.320 上运行 VxVerify 2，则会遇到以下错误。

RuntimeError: Bad magic number in .pyc file

• 要检查是否正在使用正确的 VxVerify 版本，请参阅文章（下面的链接需要向戴尔支持门户进行身份验证）：
  • VxRail：如何运行 VxRail Verify 工具（“VxVerify 版本” 部分） 
• VxVerify 创建称为 minion 的程序，这些程序使用 SSH。如果 SSH 可以使用，即使尚未启用，VxVerify 也会开启 SSH 对于每个主机要运行的命令。如果主机在以下位置被锁定： SSH 无法运行，minion 无法运行，并且主机测试返回结果代码：2（故障）或 3（严重）。如果发生这种情况， 请讨论 SSH 具有管理员权限。
• VxVerify2 设计为在 Python 2.7 上运行，Python 2.7 应存在于 VxRM 虚拟机上，并且通常是唯一可用的 Python 版本。如果有更多 Python 版本，请运行以下命令进行测试（这具有 -h 选项，即 --help）：

python2.7 vxverify.pyc -h

VxVerify 将日志和输出文件写入到 /tmp/vxv/。如果它没有足够的权限，则无法运行。使用以下命令检查文件夹权限。如果并非所有用户都有读/写权限，请使用 chmod （可能需要 root 权限）：

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• 如果 VxVerify 的权限错误 仍然存在（例如：“Permission denied for deleting previous logs.”），请尝试删除 vxv 文件夹中安装以下命令（需要根密码 sudo 访问）。运行此删除命令后，必须仅使用 mystic 权限再次安装 VxVerify：

sudo rm -r -d /tmp/vxv

• 另一个选项是将 VxVerify 输出文件保存到新文件夹。如果树不存在，VxVerify 会使用 -l 或 --log 选项，后跟日志应保存到的路径。例如：

python vxverify.pyc -l /tmp/vx1

故障处理 VxVerify2 和 VxVerify 3 之间的差异（适用于 VxRail 7.0.010+）

对于 VxRail 7.0.010 和更高版本，由于 VxRM 中的根本性更改，必须使用 VxVerify 3。

VxVerify2 的相同故障处理步骤也适用于 VxVerify3，但以下 情况除外：

• VxVerify3 的 Python 版本为 3.6。
• VxVerify 需要更改的站点软件包的位置，位于以下位置之一：
  • /mystic/telemetry/DCManager/venv/lib/python3.6/site-packages
  • /mystic/radar/venv/lib/python3.6/site-packages
• 如果这两个文件夹都无法从 mystic 用户处访问，VxVerify 程序将显示有关站点软件包的错误消息并退出。
  • 解决方法是使用 root 用户。

超时

如果工作节点需要超过 20 分钟才能完成，VxVerify 必须在摘要表中提供超时事件。

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

• 相应的 vxv.log 此项的条目包括：

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

• 应通过查看该主机的 minion 日志来检查这一点，以查看 minion 是否遇到导致其停止的错误，或者测试是否继续缓慢且时间不足以完成。
• 如果工作节点正确完成，则日志中的最后一行应显示以下内容：

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 文件传输无法正常工作

如果无法使用 SCP 或 SFTP 将主机 minion 结果传输回 VxRM，则输出表上可能会显示以下内容：

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

• 相应的 vxv.log 此项的条目包括：

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

• 应通过查看该主机的 minion 日志来检查这一点，以查看 minion 是否遇到导致其停止的错误，或者是否生成了 JSON 文件，但无法使用 SSH。
• 如果 minion 正确完成，则日志中的最后一行应显示以下内容，这表明 JSON 已成功保存到 /tmp 节点的文件夹：

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.

对上述问题进行故障处理的建议步骤是：

• 如果使用 VxVerify3，请尝试使用 --fix 标志，该标志使用替代 SSH 机制。这可以避免一些 SSH 权限问题。
• 使用 指定新路径 -1 （不需要先创建文件夹），如果 VxRM 权限错误阻止文件传输，这会有所帮助：
• 例如： > python vxv2.pyc -l \tmp\vxv0
• 如果上述方法仍然不起作用，请先拍摄 VxRM 的快照，然后再清理 /tmp 和 /home/mystic，例如以前由 VxVerify 使用的方法。
• 重新启动 VxRM (VxRail Manager)。

如果 VxVerify 遇到无法通过上述步骤修复的错误，请按照上面的详细信息保存 vxv 日志包，然后向 戴尔支持上报问题。

VxVerify2 和 VxVerify3 中的登录和凭据错误

• 要在 VxRM （VxRail Manager） 和 VxRail 节点上运行测试，VxVerify 不需要任何凭据。VxVerify 可以直接从 VxRM 数据库访问加密凭据，并在使用之前对其进行解密。有时无法访问 VC 管理凭据，在这种情况下，可以在 VxVerify 命令行中指定这些凭据：

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

• 使用 vCenter 允许的一些 特殊字符可能会导致 VxRail Manager 出现问题（特别是对于使用 Linux Shell 的任何命令）。检查 vCenter 或 ESXi 主机的密码中未使用以下任何字符：

` $ % / \

• 如果对用于管理的用户名有疑问，请咨询 vxv.log。例如：

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

• 使用 SSH 对 vCenter 进行测试需要根用户名和密码，这可使用 -r 和 -w 选项。仅当指定了这些项时，才会运行 vCenter 测试（但如果 root 用户 root（这是默认值），则只需指定根密码）。例如：

python vxverify.py --verbose -w R00tPassword!

严重测试失败示例

这可能是严重错误导致的，这会阻止运行进一步的测试。例如，如果保存在 VxRM 中的 vCenter 管理用户名和密码不是最新的，则对 VC API 的所有查询都将失败，并且无法运行进一步的测试。示例包括：

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

VxVerify 在 /tmp/vxv/ 或 /var/log/mystic/vxv/ （除非使用 -l 参数）。  这些文件全部保存在 /tmp，例如 /tmp/vxverify-569ae010.zip 或 /tmp/vxv_previous_01.zip。
即使 VxVerify 脚本未完全完成，手动检查这些文件也可能有助于查找群集上的问题：   

• vxv.log - （VxVerify 脚本的日志文件）
• minion_hostname.log - （在每个主机上运行的 minion 脚本的远程日志）
• minion_hostname.txt - （每个 minion 的远程文本输出，显示正在进行的测试编号）
• /json/host_uid.json - （由每个 minion 生成的文件，其中包含测试结果，稍后与其他主机数据合并，然后删除）
• vxverify_tests.json - （所有测试的组合输出，可以手动检查以查看每个测试结果）
• vxtii.json - （主机对 iDRAC 硬件资源清册等查询的组合响应）
• vxtii.txt - （汇总每个节点的 iDRAC 和 ESXi 信息的报告）
• vxverify.txt - （如果 VxVerify 未在安静模式下运行，屏幕上也会显示摘要表）
• vxverify.html - （HTML 格式的组合 VxVerify 和 VxTii 报告）（仅在直接运行 VxVerify 而不是嵌入 VxRail Manager 运行状况检查时存在）