KVM 遷移失敗排查指南

發布日期：2026-10-23

在日常虛擬化維運中，KVM 遷移失敗排查並不是靠記住某一條「萬用指令」就能解決，而更像是像閱讀系統拓撲圖一樣去理解整個環境。虛擬機之所以無法遷移，通常並不是毫無原因，而往往是來源宿主機、目標宿主機、傳輸路徑、虛擬機定義以及磁碟存取這幾個環節之間的銜接出了問題。對於在香港伺服器環境中運行叢集工作負載的技術人員來說，遷移穩定性非常關鍵，因為維護視窗通常很短，服務連續性要求很高，一次遷移失敗就可能讓原本例行的操作演變為一次高噪音故障事件。

從平台層面來看，虛擬機遷移依賴管理工具、虛擬化程序、宿主機通訊路徑以及磁碟可見性之間的緊密協同。官方虛擬化文件指出，遷移既可以使用原生傳輸，也可以透過隧道化路徑完成，而不同模式在防火牆、加密與效能上的要求並不相同。相關文件同樣明確說明，共享儲存前提、URI 解析以及宿主機之間的連通性，都會直接影響遷移能否順利開始。這也意味著，最佳的排查方式不是靠猜，而是把問題拆解為多個層次，依序逐一驗證。

為什麼 KVM 遷移會在真實環境中失敗

在實驗室示範中，遷移看起來總是很順暢：宿主機完全一致、儲存路徑統一、網路已全部打通，而且虛擬機體量小、記憶體變化可預測。但正式環境從來不會這麼理想。工程師面對的往往是混合世代的 CPU、漂移的 XML 定義、被改名的網橋、失效的 DNS、只記錄了一半的儲存掛載，以及會靜默攔截 socket 建立或傳輸流量的安全策略。即便遷移指令本身語法正確，周邊狀態也未必正確。

一個常見誤區是把遷移當成單一功能來看待。實際上，它更像是一條依賴鏈。只要其中某一個環節薄弱，虛擬機就可能拒絕遷移、在傳輸中途暫停，或是在目標宿主機落地後無法正常啟動。官方說明也提醒，某些傳輸方式需要額外的網路配置，而隧道化遷移雖然能簡化網路設定，卻可能限制某些遷移模式下的功能可用性。在實際維運中，這意味著你需要在簡潔性與吞吐能力之間做出權衡。

來源宿主機與目標宿主機之間的網路路徑不完整，或存在非對稱通訊。
磁碟映像未共享、無法存取，或沒有對應到相同路徑。
CPU 暴露模式導致相容性檢查失敗，或阻止虛擬機遷移後啟動。
存取控制、守護程序狀態或安全標籤打斷遷移交接。
目標宿主機缺少對應的網橋、可用記憶體，或虛擬機所需裝置。

常見的失敗現象通常代表什麼

故障現象往往決定了你應該先從哪裡開始排查。如果遷移在一開始就失敗，問題通常出在驗證、URI 解析、守護程序可達性或防火牆策略上；如果遷移已經啟動但中途終止，那麼更可能與磁碟存取、記憶體傳輸或目標端準備過程有關；如果遷移顯示完成但虛擬機無法存取，那麼根因可能並不在遷移傳輸本身，而是在網橋對應、MAC 策略或虛擬機定義不一致上。

工程師應當把結果區分為以下三類：

預檢階段失敗：在虛擬機狀態傳輸開始之前，指令就已被拒絕。
遷移過程中失敗：遷移開始後卡住、逾時，或被回滾。
遷移後失敗：虛擬機已到達目標端，但無法正常啟動或無法提供服務。

這樣的分類可以讓排查更有落點。它能避免把時間浪費在無關項上，例如目標端守護程序根本不可達時卻去檢查儲存，或者實際上是目標網橋不存在，卻在 CPU 特性上兜圈子。

先從傳輸路徑開始排查

遷移本質上是宿主機到宿主機的操作，因此傳輸路徑必須先確認。上游文件說明，原生傳輸通常需要額外的虛擬化網路設定，並且防火牆開放範圍更大；而隧道化傳輸則可以依賴較為簡潔的遠端守護程序存取方式，同時減少防火牆暴露面。在實務中，這意味著你首先應該確認目前環境設計使用的是哪一種傳輸模型，然後核實環境是否仍然符合這套設計。

驗證來源宿主機與目標宿主機之間的名稱解析是否正確。
檢查遷移流量是否走了預期網卡，而不是落到預設路由上。
確認在目前工作流程需要的情境下，相關守護程序存取是否雙向可用。
排查防火牆是否放行了管理存取，卻阻斷了遷移資料路徑。
如果啟用了 Jumbo Frame，還需要檢查延遲抖動、封包遺失或大幀設定不穩定問題。

URI 產生值得特別關注。官方文件指出，當主機名稱解析異常，或者宿主機存在多張網路介面卡時，自動產生的遷移 URI 可能是錯誤的。換句話說，即便遷移引擎本身沒有問題，資料傳輸也可能被導向錯誤位址。在多網路的伺服器租用環境中，這不是低機率的邊緣問題，而是反覆出現的常見故障點。

在修改虛擬機 XML 之前，先驗證儲存前提是否成立

儲存是第二個主要故障域。上游文件指出，除非明確使用非共享磁碟複製選項，否則遷移通常預設虛擬機磁碟映像在宿主機之間是共享的。它還說明，除非你明確提供更新後的 XML，否則映像路徑通常也應保持一致。因此，「在某台宿主機上能跑」並不能說明問題，真正需要確認的是目標宿主機是否以相同方式看到了同一份底層資料。

對儲存的檢查應該直接且務實：

目標宿主機是否真的能看到該磁碟映像或區塊裝置？
路徑是否完全一致，還是環境已經發生漂移？
檔案擁有者、標籤和讀寫權限是否與虛擬化程序匹配？
是否存在 backing chain、快照鏈或鎖定狀態，從而阻止安全遷移？
如果使用非共享儲存遷移，目前傳輸方式是否支援所選模式？

這裡還要避免一個危險的捷徑：不要因為虛擬機磁碟是共享的，就想當然耳地認為設定目錄本身也應該共享。官方遷移文件明確警告，不應在宿主機之間共享 libvirt 設定目錄。共享磁碟與共享管理狀態不是同一回事，把兩者混為一談，往往會製造出看似是遷移問題、實則是持久化狀態錯亂的隱患。

CPU 相容性問題並不只是硬體問題

很多被歸因於「CPU 不匹配」的遷移失敗，實際上真正的問題在於 CPU 的暴露策略。虛擬化文件說明，類似 host-passthrough 這類更貼近實體處理器的 CPU 暴露方式，可能會讓遷移前的相容性檢查無法執行，儘管它在效能特性上更接近真實硬體。由此就形成了一個典型取捨：單機特性更完整，但在共享資源池中的可遷移性更差。

工程師需要檢查的不僅是實體 CPU 世代，還包括虛擬機「看到」的 CPU 形態。某台虛擬機在來源宿主機上運行正常，並不代表它一定能在目標宿主機上啟動。如果其設定中啟用了較為具體的 CPU 特性，目標端很可能無法滿足這些要求。官方工具通常也提供 CPU 模型比對和基線檢查能力，這應當成為任何混合集群環境中遷移前檢查流程的一部分。

比較虛擬機 CPU mode，而不僅僅是處理器系列名稱。
檢查某些新指令集是否只在部分節點上被暴露出來。
核對叢集內 BIOS 與虛擬化支援設定是否一致。
在共享資源池中使用接近直通的設定時應保持謹慎。

權限、守護程序與安全層往往會靜默失敗

當傳輸路徑和儲存看起來都正常時，下一個重點懷疑對象就是控制平面狀態。遷移依賴健康的虛擬化守護程序、正確的遠端存取方式，以及允許建立程序、存取 socket 和掛載磁碟的權限模型。官方文件之所以專門列出遠端存取、驗證、日誌、存取控制和防火牆設定等章節，正是因為遷移會同時觸及這些層面。

一個比較隱蔽的故障來源是 socket 與檔案的安全標籤。上游文件提到，在啟用了強化安全機制的系統裡，只有在 socket 上下文設定正確時，虛擬化程序才能正常連線。這會造成一種很迷惑的現象：網路路徑存在、守護程序在線，但遷移依然失敗，因為阻斷並不發生在封包層，而是發生在策略層。

一次完整的權限稽核應至少包括：

來源宿主機與目標宿主機上的守護程序狀態。
遠端驗證方式，以及兩端是否都接受這種方式。
發起遷移的帳戶具備怎樣的存取策略。
虛擬化相關程序所使用的檔案與 socket 標籤。
故障發生精確時間點前後的雙端日誌。

檢查虛擬機定義與目標宿主機的一致性

很多遷移失敗並不是因為資料無法移動，而是因為目標宿主機無法按照目前定義完整實例化這台虛擬機。例如網橋名稱不一致、本地 ISO 仍然掛載、某個直通裝置在目標端不存在，或者過期的 XML 引用了無法存取的路徑。這類問題並不「高大上」，但非常常見。

工程師應該把虛擬機定義看作一份部署契約。每一個宣告的網卡、磁碟路徑、控制器和附加裝置，都必須在目標宿主機上成立。如果環境設計目標是支援靈活遷移，那麼虛擬機定義就應盡量避免與單一節點產生不必要的綁定。

確認目標宿主機存在相應的網橋名稱和虛擬交換對應。
在遷移前移除過時的安裝媒體或宿主機本地裝置。
檢查快照及 backing file 的關聯鏈。
確認目標宿主機擁有足夠的可用記憶體與 CPU 餘量。
驗證這台虛擬機即使不走遷移流程，是否也能在目標端正常啟動。

一套實用的排查工作流程

一套可重複執行的方法，永遠比零散的「靈感式」判斷更有效。如果你需要一套適合現場維運的步驟，可以按照以下順序執行：

先判斷故障階段。 是在傳輸前失敗、傳輸中失敗，還是在切換後失敗？
同時讀取兩端資訊。 收集來源端與目標端的指令輸出及同一時間點日誌。
驗證傳輸路徑。 檢查主機名稱解析、目標介面以及防火牆開放範圍。
驗證儲存。 確認路徑、存取權限、標籤、backing chain 以及共享模型。
驗證 CPU 策略。 比較虛擬機需求與目標端能夠暴露的 CPU 能力。
驗證虛擬機定義。 檢查網橋、裝置、安裝媒體及本地引用路徑。
先做小規模測試。 選一台策略相似的非關鍵虛擬機進行遷移，以隔離平台層級問題。

這套順序刻意設計得比較機械化。它的價值在於降低主觀偏見。絕大多數遷移失敗之所以看起來神秘，只是因為依賴鏈還沒有被逐項驗證。

面向香港伺服器環境的特別注意事項

在香港部署業務的工程師，通常更關注區域低延遲存取、跨境應用行為以及緊湊的維護視窗。在這樣的背景下，遷移設計應當優先保證內部網路的確定性和儲存效能的可預測性，而不是一味追求功能堆疊。無論部署模式是伺服器租用還是伺服器託管，工程原則都一樣：底層越乾淨，遷移越穩。

內部路由一致性往往比看起來華麗的架構圖更重要。如果遷移網路和備份突發流量、複寫流量或東西向應用通訊競爭同一資源，那麼所謂「隨機」逾時其實並不隨機，而是容量規劃問題的外在表現。同樣，如果節點是逐步加入叢集的，卻沒有同步統一網橋名稱、CPU 策略和磁碟掛載結構，那麼每增加一台宿主機，未來遷移發生漂移的機率就會上升。