如果每台 VM 都從 ISO 開始手動安裝，作業系統版本、套件、主機名稱（Hostname）、網路設定與 SSH 金鑰很容易因操作順序不同而產生差異。第一台看起來可以正常運作，到了第十台卻可能已經漏裝套件、使用舊映像，或保留了不該重複的機器識別碼（Machine ID）與 SSH 主機金鑰（SSH Host Key）。
這一天要解決的是如何建立可重複使用，又不會把主機身分一起複製的系統基準。我們會先從 PVE、QEMU 與 KVM 的分工開始，認識建立 VM 時的虛擬硬體，再說明如何用雲端映像（Cloud Image）、Cloud-Init 與範本（Template），把共同設定保存下來，並在每台 VM 第一次開機時產生自己的身分。
本文閱讀方式
- 完整理解技術與底層原理：依序閱讀全文。
- 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
- 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
- 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。
前面完成 PVE、儲存與虛擬網路，現在要讓後續服務 VM 可以用一致方式建立。範本保存共同基準，Cloud-Init 則為每台 VM 注入自己的主機名稱、IP、SSH 金鑰與初始設定。
圖（一）由同一份雲端映像建立 VM 範本，再透過 Cloud-Init 產生不同用途的服務 VM。
後續的 jump01、proxy01、app01 與 pg01 等服務雖然用途不同，底層都能從同一份經過驗證的 Debian 基準建立。日後遇到問題時，也比較容易判斷差異來自服務設定，而不是某台 VM 在安裝時少做了一個步驟。
在建立範本以前，要先分清楚一台 PVE VM 實際上由哪些技術組成。PVE 提供 Web UI、權限、儲存、叢集與 VM 生命週期管理，但真正執行 VM 時，底層還會使用 QEMU 與 KVM。
核心型虛擬機（Kernel-based Virtual Machine，KVM）是 Linux 核心的虛擬化功能。處理器開啟 Intel VT-x 或 AMD-V 後，KVM 可以讓客體作業系統（Guest）的 CPU 指令直接在實體處理器上執行，不必全部交給軟體逐條模擬。
KVM 主要處理的是 vCPU、客體記憶體、中斷與硬體虛擬化加速。若主機沒有開啟硬體虛擬化，或巢狀 Lab 沒有把虛擬化能力傳入 L1 PVE，就可能看到 KVM virtualisation configured, but not available。
QEMU 負責建立實際執行 VM 的使用者空間行程，並向客體作業系統呈現虛擬主機板、CPU、記憶體控制器、磁碟控制器、網卡、顯示卡與序列埠等裝置。QEMU 可以單獨進行完整軟體模擬，但在 PVE 的一般 x86 VM 中，通常會搭配 KVM 取得接近原生的 CPU 虛擬化效能。
圖（二）QEMU 單獨模擬硬體，以及 QEMU 搭配 KVM 使用硬體虛擬化加速的差異。
圖片來源：Top of Mind，〈Virtualization〉。
這張圖把左右兩側分別標成 KVM 與 QEMU，是在比較兩種執行方式。右側是 QEMU 單獨進行軟體模擬，客體作業系統的虛擬硬體與指令轉換都由 QEMU 處理。左側則是 QEMU 負責建立 VM 與虛擬裝置，再把適合直接執行的 CPU 與記憶體操作交給 Linux 核心中的 KVM 加速。PVE 一般建立的 x86 VM 使用的是左側組合，因此介面與文件常寫成 QEMU／KVM VM。
換句話說，PVE 負責管理 VM 設定、儲存、權限與生命週期。QEMU 依照這些設定建立 VM 行程與虛擬硬體。KVM 則利用處理器的硬體虛擬化功能加速 CPU 與記憶體執行。三者位於不同層次，不是互相取代的產品。
PVE 的 qm 指令就是 QEMU／KVM VM 的管理工具。當我們執行 qm create、qm set、qm start 或在 Web UI 修改 Hardware 時，PVE 會更新 VM 設定，再依設定啟動對應的 QEMU 行程。
PVE 需要同時保存 VM 設定、虛擬硬體、磁碟資料與網路連接方式：
| 項目 | PVE 中的設定 | 實際作用 |
|---|---|---|
| 身分 | Node、VMID、Name、SMBIOS UUID | 決定 VM 位於哪個節點，以及 PVE 如何識別它 |
| CPU | Socket、Core、CPU Type | 決定客體作業系統看見的 vCPU 數量與 CPU 指令集 |
| 記憶體 | Memory、Ballooning、NUMA | 決定配置容量與是否允許動態回收記憶體 |
| 系統 | Machine、BIOS／UEFI、EFI Disk | 決定虛擬主機板與開機韌體 |
| 磁碟 | Storage、Bus、Format、Discard、IO Thread | 決定 VM 磁碟放在哪裡及如何呈現給客體作業系統 |
| 網路 | Model、Bridge、VLAN Tag、Firewall | 決定虛擬網卡型號與接入哪個網路 |
| 管理通道 | QEMU Guest Agent、Serial Port | 讓 PVE 取得客體作業系統狀態或提供 Console |
| 個別化資料 | Cloud-Init Drive | 提供主機名稱、帳號、SSH 金鑰與網路設定 |
這些設定大多保存在 PVE 的 VM Configuration 中。VM 磁碟則位於選定的儲存。只複製設定檔不代表磁碟也跟著複製。
Node 決定 VM 目前由哪一台 PVE 節點管理。VMID 是叢集內不能重複的數字識別碼。Name 則是方便人閱讀的名稱。正式服務可以叫做 pg01 或 proxy01，但 PVE 真正用來定位設定與磁碟名稱的核心識別仍是 VMID。
執行 Clone 時，PVE 會替新 VM 產生新的 VMID、MAC 位址與 SMBIOS UUID。
Machine Type 決定 QEMU 向客體作業系統呈現哪一種虛擬主機板與晶片組。常見的 i440fx 模擬較傳統的 PCI 架構，存在時間較長，適合重視舊系統相容性的情境。q35 則模擬較新的晶片組並提供 PCI Express 架構，較適合需要 PCIe 裝置、GPU 裝置直通或較新作業系統的 VM。它代表客體作業系統開機後看見的虛擬硬體平台。
BIOS 與 UEFI 則是 VM 開機後，作業系統啟動以前執行的韌體。傳統 BIOS 會依開機順序尋找磁碟，讀取開機區並交給開機載入程式（Bootloader）。PVE 使用 SeaBIOS 提供這種模式。UEFI 會直接辨識 EFI 系統分割區（EFI System Partition）內的開機程式，並可支援安全開機（Secure Boot）等較新的功能。PVE 使用 OVMF 提供 UEFI，另外建立 EFI Disk 保存開機項目、安全開機金鑰與其他 UEFI 變數。
選擇哪一種韌體應在安裝或匯入系統以前決定。已用 BIOS 模式安裝的磁碟不一定能在改成 UEFI 後直接開機。
CPU Type 選 host 時，客體作業系統可以看見較完整的實體 CPU 指令集，通常能取得較好的效能。代價是 VM 會更依賴目前主機的 CPU 特性。若叢集節點的 CPU 型號或世代不同，線上遷移（Live Migration）到另一台節點時可能因指令集不相容而失敗。
若需要跨不同 CPU 節點遷移，應選擇所有節點共同支援的 CPU Model。簡單來說，CPU Type 決定 VM 看得見哪些處理器指令。開放的主機指令集越完整，效能與功能可能越好，但 VM 對該 CPU 的依賴也越高。目的節點缺少其中任何必要指令時，線上遷移就可能失敗。
Memory 是 VM 可使用的最大記憶體。啟用記憶體氣球（Ballooning）後，還可以設定 VM 保證保留的最小記憶體。當主機記憶體不足時，PVE 透過客體作業系統內的記憶體氣球驅動程式（Balloon Driver）要求 VM 交回部分目前沒有使用的記憶體，而需求增加時再把容量還給 VM。因此 PVE Summary 看到的實際用量可能低於設定的最大值。
記憶體氣球需要客體作業系統驅動程式配合，也只能回收客體作業系統能釋放的記憶體。它可以提高主機的記憶體利用率，但實體 RAM 依然有上限。當所有 VM 同時需要記憶體，主機仍可能開始使用交換空間（Swap）、產生延遲，甚至因記憶體不足（Out of Memory，OOM）終止行程。所以要根據使用情境決定是否開啟。
NUMA 主要用於較大的多 Socket 主機與大型 VM，讓 vCPU 優先使用相近的記憶體節點。只有少量 vCPU 與 1～2GB RAM 的 Lab VM 不需要特別開啟。
下載的 Debian 雲端映像是 .qcow2 映像檔，但匯入 PVE 後會由目標儲存空間決定實際保存方式。若放在目錄型儲存空間，通常會看到 qcow2 或 raw 映像檔。匯入 local-lvm 後，則會成為 LVM-thin 管理的虛擬磁碟區，不會再以原本的 qcow2 檔案形式提供給 VM。這不會改變裡面的系統，只是底層保存方式不同。
磁碟匯流排（Disk Bus）決定客體作業系統透過哪一種虛擬控制器看見磁碟。IDE、SATA 會模擬傳統硬體，相容性較高，但額外模擬成本也較多。VirtIO 是為虛擬化設計的半虛擬化介面，客體作業系統安裝對應驅動程式後，通常能以較少的模擬成本完成磁碟 I/O。
SCSI 定義作業系統如何向磁碟送出讀取、寫入與寫回（Flush）等儲存命令。VirtIO 則是虛擬機與虛擬化管理程式（Hypervisor）交換資料的半虛擬化傳輸機制。VirtIO SCSI 是把兩者組合：客體作業系統仍把裝置視為 SCSI 磁碟，但命令透過 VirtIO 傳給 QEMU 與底層儲存，省去模擬一整套實體 SCSI 硬體的成本。
其中 single 表示 PVE 讓每顆 SCSI 磁碟使用各自的 VirtIO SCSI 控制器，方便分別啟用 IO Thread，避免多顆磁碟共用同一條 I/O 執行路徑。Debian 雲端映像已具備所需驅動，因此可以直接使用。
圖（三）PVE 新增 SCSI Disk 時使用 VirtIO SCSI single Controller，並可設定 Discard、IO Thread 與 Cache。
VirtIO NIC 是為虛擬化設計的半虛擬化網卡，不需要完整模擬特定實體網卡，通常比 E1000 等模擬裝置更有效率。Bridge 決定 VM 接到哪一座 Linux Bridge。VLAN Tag 則讓 PVE 將該 VM Port 視為指定 VLAN 的 Access Port。詳細的話請複習上一篇。
安裝 ISO 是可開機的安裝媒體。建立 VM 後從虛擬 CD／DVD 開機，再像實體主機一樣選語言、磁碟、帳號與套件。這種方式適合需要自訂分割區、安裝選項或發行版沒有提供雲端映像的情境，但每台 VM 都走一次安裝精靈，很難保證結果完全一致。
雲端映像則是發行版預先安裝完成的系統磁碟。Debian Generic Cloud Image 已包含可開機系統與 Cloud-Init，不需要再掛 ISO 執行安裝。在 PVE 中可以先把 qcow2 匯入儲存，再把匯入的磁碟接成 scsi0。
Cloud-Init 原本設計成可以從不同雲端平台取得初始化資料，例如 AWS、Azure 或 OpenStack。NoCloud 是其中一種不依賴雲端 API 的資料來源：初始化資料直接放在 VM 可以讀取的本機磁碟或光碟映像中。PVE 會建立一顆小型 Cloud-Init Drive，把主機名稱、帳號與網路等資料放進去。客體作業系統開機後辨識到 NoCloud 資料來源（Data Source），再由 VM 內的 Cloud-Init 讀取並套用。
這裡有兩個容易混淆的地方：
scsi0 保存 Debian 系統，ide2 的 Cloud-Init Drive 只保存初始化資料。Cloud-Init 的開機流程可以概略分為：
圖（四）Cloud-Init 依序經過 Detect、Local、Network、Config 與 Final 五個開機階段。
這五個名稱來自 Cloud-Init 官方流程。Detect 會由 ds-identify 辨識目前平台與可用的資料來源，決定是否啟用 Cloud-Init。Local 會在網路啟動前尋找資料來源並準備網路設定。其餘階段再依序處理需要網路的資料、設定模組與較晚期的初始化工作。
不同模組（Module）的執行頻率可能是每次開機、每個執行個體（Instance）一次，或只執行一次。Cloud-Init 會保存執行個體狀態，並用執行個體識別碼（Instance ID）判斷這是同一台 VM 的重新開機，還是由映像建立的新執行個體。
Cloud-Init 處理的是客體作業系統第一次開機與每個執行個體的初始化。QEMU Guest Agent 則是在 VM 已經運作後，持續提供主機與客體作業系統之間的管理通道。
要讓 QEMU Guest Agent 正常工作，PVE VM Options 必須啟用 QEMU Guest Agent，客體作業系統裡也必須安裝並啟動 qemu-guest-agent。只完成其中一邊，PVE 都無法正常取得回報。
QEMU Guest Agent 可協助 PVE：
把 VM 轉成範本後，它會成為建立新 VM 的共同基準，不再當成一般服務 VM 直接開機使用。
PVE 常見的 Clone 方式如下：
| 類型 | 儲存方式 | 優點 | 需要注意的地方 |
|---|---|---|---|
| Full Clone | 建立完整且獨立的 VM 磁碟 | 複製完成後不依賴來源範本，適合正式服務 VM | 建立時間較長，也會使用較多空間 |
| Linked Clone | 以來源磁碟為基礎，只保存後續差異 | 建立快速、節省空間，適合短期測試 | 依賴基底映像（Base Image），儲存必須支援，不能任意刪除來源 |
範本的價值是把重複且應一致的內容固定下來，例如作業系統版本、套件來源、QEMU Guest Agent、時區、紀錄基準與安全更新。主機名稱、IP、SSH 主機金鑰與使用者金鑰則應在複製後產生。
PVE 的 Clone 會替新 VM 產生 VMID、MAC 位址、SMBIOS UUID 與 VM 世代識別碼（VM Generation ID），但它不會進入客體作業系統修改檔案。換句話說，範本磁碟中若已經存在 Shell 歷史紀錄、暫存憑證、服務資料或測試密碼，這些內容仍會原樣進入 Full Clone，必須在轉換範本前自行清除。
機器識別碼、Cloud-Init 狀態與 SSH 主機金鑰則由客體作業系統端的映像準備流程處理。本系列使用的 Debian 雲端映像已安裝 Cloud-Init，而 Cloud-Init 的 SSH 模組預設會刪除映像內既有的主機金鑰，再為新執行個體產生新的金鑰。不過 VM 9001 曾經開機更新，轉成範本前仍要執行 cloud-init clean --logs --machine-id，清除 Cloud-Init 快取並重設機器識別碼，確保下一台複製 VM 被視為新的執行個體。這項清理是 Cloud-Init 在客體作業系統內完成的。
範本不能建立一次就永久使用。若範本長時間沒有更新，每次複製都要重新下載大量安全更新，也可能把已知漏洞、過期套件來源或不再使用的設定繼續複製下去。
可以替範本記錄下列資訊：
正文已經拆開雲端映像、範本、Cloud-Init 與 QEMU Guest Agent 的責任。本次 Lab 不再重述每一個建立欄位，而是完成一份 Debian 範本，再用測試複製 VM 證明三件事：範本保存共同基準、Cloud-Init 注入每台 VM 的個別設定，QEMU Guest Agent 則讓 PVE 能與已開機的客體作業系統溝通。
GitHub 詳細部署文件：Day 06｜Template 與 Cloud-Init
這一天屬於部署驗證，驗證重點是部署結果能否重複，以及複製 VM 是否真的取得獨立身分。
本次實作先使用 Debian 雲端映像建立 VM 9001，完成共同套件與 QEMU Guest Agent 後清除主機身分，再將它轉換成範本。接著建立 VMID 902 測試複製 VM，透過 PVE 與客體作業系統兩側的結果完成三項核心驗證：
先取得 Debian 官方雲端映像，並確認下載檔案不是空檔。完整實作還會保存來源、版本與校驗碼，避免日後無法確認範本是由哪一份映像建立。
圖（五）在 pve01 確認 Debian 雲端映像已下載完成，且檔案大小不是 0 Byte。
VM 9001 匯入雲端映像後，硬體清單應包含作為系統磁碟的 scsi0、位於 ide2 的 CloudInit Drive、VirtIO Network Device 與 Serial Port。Options 中也要啟用 QEMU Guest Agent。這些 PVE 介面項目分別對應正文介紹的虛擬硬體、初始化資料來源與主機／客體作業系統管理通道。
圖（六）VM 9001 保存系統磁碟、CloudInit Drive、虛擬網卡與 Serial Port 等共同硬體基準。
VM 9001 第一次開機只用來安裝更新與 QEMU Guest Agent。關機前執行 cloud-init clean --logs --machine-id，再轉換成範本，避免把這次開機的 Cloud-Init 狀態與機器識別碼當成所有複製 VM 的共同身分。建立空白 VM、匯入 qcow2、調整磁碟容量及轉換範本的完整操作留在實作文件。
範本提供共同基準，每台複製 VM 的主機名稱、使用者、SSH 公開金鑰、DNS 與網路設定則由 Cloud-Init 提供。PVE 會把這些資料寫入獨立的 CloudInit Drive，客體作業系統第一次開機時再讀取並套用，因此不必為每台服務 VM 各做一份作業系統映像。
圖（七）PVE 的 Cloud-Init 頁面用來準備客體作業系統第一次開機需要的個別設定。
在 PVE 主機查閱測試複製 VM 的實際資料，可以確認介面顯示的設定已經產生，而不是只停留在輸入欄位：
qm cloudinit dump 902 user
qm cloudinit dump 902 network
qm cloudinit pending 902
圖（八）PVE 已為 VM 902 產生主機名稱、使用者、DHCP、DNS Server 與 Search Domain 等 Cloud-Init 資料。
圖中的
10.77.10.1是後續環境的 DNS。Day 06 驗證時請以目前可連線的 DNS 為準。
dump 顯示即將交給客體作業系統的使用者資料與網路資料。pending 則用來確認是否還有修改尚未重新產生或套用。VMID 902 僅作為本次驗證用的複製 VM。
測試複製 VM 開機後，Cloud-Init 狀態應為 done，主機名稱與 IP 應符合這台 VM 的設定，QEMU Guest Agent 也應為 active。這些結果共同證明 VM 不只成功開機，也完成了第一次初始化並建立主機／客體作業系統管理通道。
圖（九）測試複製 VM 已取得自己的主機名稱與 IP，Cloud-Init 和 QEMU Guest Agent 也正常運作。
在測試複製 VM 內保留下列證據：
cloud-init status --long
hostnamectl --static
cat /etc/machine-id
ip -4 -br address
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
systemctl is-active qemu-guest-agent
最後回到 PVE 主機執行：
if qm agent 902 ping; then
echo 'OK: QEMU Guest Agent responded'
else
echo 'ERROR: QEMU Guest Agent did not respond'
fi
圖（十）PVE 成功透過 QEMU Guest Agent 管理通道向 VM 902 發出請求。
qm agent 902 ping 成功時本身不會輸出內容，因此由條件判斷顯示 OK: QEMU Guest Agent responded。這項結果證明 PVE 可以透過管理通道向客體作業系統發出請求。未來建立多台服務 VM 時，還要互相比較主機名稱、MAC 位址、IP、機器識別碼與 SSH 主機金鑰指紋，避免範本中殘留的身分資料被複製到每台 VM。
| 正文概念 | Lab 證據 | 可以證明的結果 |
|---|---|---|
| 雲端映像與範本 | VM 9001 的磁碟、硬體與清理紀錄 | 共同作業系統與虛擬硬體已形成可重複使用的基準 |
| Cloud-Init | qm cloudinit dump、客體作業系統的主機名稱與 IP |
每台 VM 的個別設定由範本外部注入並在第一次開機套用 |
| QEMU Guest Agent | 客體作業系統服務狀態與 qm agent 902 ping |
PVE 與客體作業系統之間的管理通道可以運作 |
| 執行個體身分 | 機器識別碼與 SSH 主機金鑰指紋 | 測試複製 VM 已具備自己的作業系統身分。多台複製 VM 仍須交叉比對 |
下一篇是 Day 07｜三台 PVE 如何組成叢集：Corosync、法定票數與 Ceph 共享儲存。VM 範本完成後，我們會把三台 L1 PVE 組成叢集，確認 Corosync 與法定票數如何維持叢集決策，再使用 Day 05 準備的網路與空白磁碟部署 Ceph 共享儲存。
iThome鐵人賽
看影片追技術