對使用 cloud-init 的 VM 佈建進行疑難排解

  • 發行項

警告

本文參考 CentOS，這是接近結束生命週期 (EOL) 狀態的 Linux 發行版本。 請據以考慮您的使用和規劃。 如需詳細資訊，請參閱 CentOS 生命週期結束指引。

適用於：✔️ Linux VM ✔️ 彈性擴展集

如果您已建立使用 cloud-init 進行佈建的一般化自訂映像，但發現未正確建立 VM，則您必須針對自訂映像進行疑難排解。

以下是佈建問題的一些範例：

  • VM 卡在「建立」達 40 分鐘，而且建立的 VM 被標示為失敗。
  • 未處理 CustomData。
  • 無法掛接暫時性磁碟。
  • 未建立使用者，或者有使用者存取問題。
  • 未正確設定網路功能。
  • 分頁檔或分割區失敗。

本文將逐步引導您針對 cloud-init 進行疑難排解。 如需更深入的詳細資料，請參閱 cloud-init 深入探討。

步驟 1：不搭配 customData 測試部署

Cloud-init 可以接受建立 VM 時傳遞來的 customData。 首先，您應該確定這不會造成任何部署問題。 請嘗試佈建 VM 而不傳入任何組態。 如果您發現無法佈建 VM，請繼續進行下列步驟，如果您發現未套用您傳遞的組態，請移至步驟 4。

步驟 2：檢閱映像需求

VM 佈建失敗的主要原因是 OS 映像不符合在 Azure 上執行的必要條件。 嘗試在 Azure 中佈建映像之前，請確定您已正確備妥映像。

下列文章說明 Azure 中支援的各種 Linux 發行版本的準備步驟：

若是支援的 Azure cloud-init 映像，Linux 發行版本已備妥在 Azure 中正確佈建映像的所有必要套件和組態。 如果您發現無法從自有的策劃映像建立 VM，請嘗試支援的 Azure Marketplace 映像搭配您選用的 customData，該映像已針對 cloud-init 進行設定。 如果 customData 搭配 Azure Marketplace 映像正常運作，則您的策劃映像可能有問題。

步驟 3：收集和檢閱 VM 記錄

若佈建 VM 失敗，在最終將 VM 標示為 OSProvisioningTimedOut 錯誤之前，Azure 會顯示「建立」狀態達 20 分鐘，然後重新啟動 VM，再等候 20 分鐘，最後才會將 VM 部署標示為失敗。

當 VM 正在執行時，您需要來自該 VM 的記錄，以了解佈建失敗的原因。 為了解 VM 佈建失敗的原因，請勿停止 VM。 讓 VM 保持執行狀態。 您必須讓失敗的 VM 處於執行中狀態，才能收集記錄。 若要收集記錄，請使用下列其中一種方法：

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

注意

或者，您可以使用 Azure 入口網站手動建立救援 VM。 如需詳細資訊，請參閱使用 Azure 入口網站將 OS 磁碟連結至復原 VM，以針對 Linux VM 進行疑難排解。

若要開始初始疑難排解，請從 cloud-init 記錄開始，了解發生失敗的位置，然後使用其他記錄深入探討，並提供額外的深入解析。

  • /var/log/cloud-init.log
  • /var/log/cloud-init-output.log
  • 序列/開機記錄

在所有記錄中，開始搜尋 "Failed", "WARNING", "WARN", "err", "error", "ERROR"。 建議將組態設定為忽略區分大小寫的搜尋。

提示

如果您要針對自訂映像進行疑難排解，您應該考慮在建立映像期間新增使用者。 如果佈建無法設定管理使用者，您仍然可以登入 OS。

分析記錄

以下是要在每個 cloud-init 記錄中尋找的內容詳細資料。

/var/log/cloud-init.log

根據預設，所有具有偵錯或更高優先順序的 cloud-init 事件都會寫入至 /var/log/cloud-init.log。 這個記錄提供 cloud-init 初始化期間所發生每個事件的詳細資訊記錄。

例如：

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

您找到錯誤或警告之後，在 cloud-init 記錄中往回閱讀，以了解 cloud-init 在遇到錯誤或警告之前所嘗試的動作。 在許多情況下，cloud-init 會在錯誤之前執行 OS 命令或執行佈建作業，這可讓您深入了解記錄中出現錯誤的原因。 下列範例示範 cloud-init 在發生錯誤之前正在嘗試掛接裝置。

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

如果您有序列主控台的存取權，您可以嘗試重新執行 cloud-init 當時嘗試執行的命令。

您也可以在 /etc/cloud/cloud.cfg.d/05_logging.cfg 中重新設定 /var/log/cloud-init.log 記錄。 如需 cloud-init 記錄的詳細資訊，請參閱 cloud-init 文件。

/var/log/cloud-init-output.log

您可以在各個 cloud-init 階段期間，從 stdout 和 stderr 取得資訊。 這通常包含有路由表資訊、網路資訊、ssh 主機金鑰驗證資訊、cloud-init 每個階段的 stdout 和 stderr，以及每個階段的時間戳記。 如有需要，可以從 /etc/cloud/cloud.cfg.d/05_logging.cfg 重新設定 stderr 和 stdout 記錄。

序列/開機記錄

Cloud-init 有多個相依項目，這些都記載於 Azure 上的映像必要條件中，例如網路功能、儲存體、掛接 ISO 以及掛接和格式化暫存磁碟的能力。 其中任何一項都可能會擲回錯誤，並導致 cloud-init 失敗。 例如，如果 VM 無法取得 DHCP 租用，cloud-init 將會失敗。

如果您仍然無法找出 cloud-init 佈建失敗的原因，則您必須了解 cloud-init 執行的內容，以及模組執行的時間。 如需詳細資訊，請參閱深入探討 cloud-init。

步驟 4：調查未套用組態的原因

在 Cloud-init 中，不是每個失敗都會導致嚴重的佈建失敗。 例如，如果您在 cloud-init config 中使用 runcmd 模組，則所執行命令中的非零結束代碼會導致 VM 佈建失敗。 這是因為模組在 cloud-init 前 3 個階段中發生的核心佈建功能之後執行命令。 若要針對未套用組態的原因進行疑難排解，請手動檢閱步驟 3 中的記錄和 cloud-init 模組。 例如：

  • runcmd - 指令碼執行時沒有錯誤嗎？ 從終端機手動執行組態以確保組態如預期般執行。
  • 安裝套件 - VM 是否能夠存取套件存放庫？
  • 您也應該檢查提供給 VM 的 customData 資料組態，資料組態位於 /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt。

下一步

如果您仍然無法找出 cloud-init 未執行組態的原因，則您必須更仔細地查看每個 cloud-init 階段中發生的事件，以及模組執行的時間。 如需詳細資訊，請參閱深入探討 cloud-init 組態。