VxRail：在 VxRail 升級之前先針對 VxVerify 進行故障診斷

本知識文章致力於故障診斷阻礙 VxVerify 成功執行的問題。

本知識文章引用自沒有針對其相關回應（例如：警告、失敗和嚴重）的測試。例如，從查詢返回意外回應的查詢。

VxVerify 的設計目的是偵測可能在 VxRail 升級期間造成複雜性或故障的問題。VxVerify 會建立稱為「minion」的 Python 程式，並傳送至 VxRail 節點。以下是預期的典型測試結果 vxverify_tests.json：

如果發現任何偽陽性測試結果，請收集 VxVerify 記錄，並聯絡 Dell 支援，以向 VxRail 工程部門開立 Jira VXV 工單。

有許多原因可導致 VxVerify 無法成功執行。

• 最常見的故障原因是 Python 指令檔已過期。每個 VxVerify 版本設定為自發佈日期起僅持續兩週。當 VxVerify 以 VxRail 執行狀況檢查架構的附掛程式執行時，這並不適用 (這會變更 VxVerify 的功能性)。
• 其他原因包括 VxRail Manager 的 權限問題 或與主機 的通訊問題 。
• 如果不清楚事件發生原因，請聯絡 Dell 支援部門，向 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 版本，請參閱文章 （以下連結需要驗證至 Dell 支援入口網站）：
  • VxRail：如何執行 VxRail 驗證工具 （VxVerify 版本 一節） 
• VxVerify 會建立稱為「minion」的程式，這些程式會透過以下方式傳送、執行和擷取： SSH。如果 SSH 可以使用，即使尚未啟用，VxVerify 也會開啟 SSH 以執行命令。如果主機在以下位置鎖定： SSH 無法運行，工作節點無法運行，並且主機測試返回結果代碼：2（失敗）或 3（嚴重）。如果發生這種情況， 請討論 SSH 系統管理員的權限。
• VxVerify2 的設計是在 Python 2.7 上執行，VxRM VM 上應具備 Python 2.7，而且通常是唯一可用的 Python 版本。如果有更多 Python 版本，請執行下列命令以進行測試 （其中 -h 選項，即 --help)：

python2.7 vxverify.pyc -h

VxVerify 會將記錄和輸出檔案寫入 /tmp/vxv/。如果沒有足夠的權限，便無法執行。使用下列命令檢查資料夾權限。如果所有使用者都沒有讀/寫權限，請將權限新增至 chmod （可能需要根權限）：

$ ls -lad /tmp/vxv

drwxrwxrwx  3 mystic   users      4096 Oct  1 07:42 vxv

• 如果 VxVerify 持續發生權限錯誤 （例如：「刪除先前記錄的權限遭拒」），請嘗試刪除 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 使用者。

逾時

如果 minion 需要超過 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 是否遇到導致其停止的錯誤，或者測試是否繼續緩慢且沒有完成時間。
• 如果 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 記錄套裝，並向 Dell 支援呈報問題。

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 - （每個工作節點的遠端文字輸出，顯示正在進行哪個測試編號）
• /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 執行狀況檢查中）