從 VMware 搬過來的虛擬機器無法開機：磁碟還在，通往磁碟的路不在了

匯入完成了，磁碟也列出來了，虛擬機器啟動後卻停在一則訊息上，說它找不到可用的開機裝置。這時的直覺是轉換過程中弄丟了什麼。但幾乎每一次，什麼都沒有遺失。

磁碟就在它該在的位置。改變的是通往磁碟的路。

為什麼會發生

虛擬機器並不是直接和磁碟溝通，而是和磁碟控制器溝通，而控制器是虛擬化平台呈現給它的硬體之一。VMware 呈現的是一種，Proxmox 呈現的是另一種。

如果客體會載入它可能需要的每一個驅動程式，這就無傷大雅。但它不會。作業系統在能存取自己的磁碟之前，只會載入一小組驅動程式，而這一組是在安裝當天就決定好的。如果磁碟前方的控制器不在這一組裡，客體就看不到任何可以開機的東西，只能用它唯一的方式表達：沒有開機裝置。

所以症狀指向磁碟，原因卻在磁碟前面那一層。

兩種看起來很像的不同故障

這兩種常被當成同一個問題處理，但其實不是。

完全沒有開機裝置。通常是韌體的問題，不是控制器。在 EFI 下建立的虛擬機器無法用傳統 BIOS 開機，反過來也一樣。磁碟本身沒有任何問題，只是虛擬機器被用一種從未針對它安裝過的方式啟動。

開機已經開始，接著停下來抱怨開機裝置。這才是控制器的情況。韌體是對的，載入程式也執行了，但核心接著無法存取被指定使用的那顆磁碟。

在改動任何東西之前先分辨這兩種情況，可以省下一整個下午，因為兩者的修法不同，套用錯誤的修法會在第一個症狀上再疊出第二個症狀。

動手之前的三個問題

磁碟真的連接到虛擬機器上了嗎？要看的是虛擬機器的設定，而不是儲存區。匯入的磁碟有可能存在於儲存區上卻沒有連接，這是兩秒鐘就能修好、看起來卻像災難的問題。

這台虛擬機器當初是在哪一種韌體下安裝的？如果它來自 EFI 環境，就需要 EFI，也需要一個存放開機項目的地方。

客體裡到底有沒有新控制器的驅動程式？問的不是有沒有安裝，而是那個磁碟映像裡到底有沒有這個驅動程式。從未接觸過 VirtIO 控制器的 Windows 虛擬機器沒有這個驅動程式，而且在無法開機的狀態下也沒辦法取得它。

可以復原的出路

有兩種做法，但安全程度並不相同。

給客體一個它已經認得的控制器。把磁碟接在客體從安裝當天就支援的介面上，正常開機，在執行中的系統裡安裝新的驅動程式，關機，然後再切換控制器。每一步都很小，每一步都可以復原。

讓這件事毫不費力的訣竅：切換之前，先用新的控制器類型連接第二顆很小的磁碟。客體沿著舊路開機，看到不認識的硬體，就能從容地為它安裝驅動程式。之後切換真正的磁碟就平靜無波，因為驅動程式已經在那裡了。

從外部把驅動程式注入映像。比較快，也有效，但如果沒成功，就得對一個已經和最初不同的映像除錯。在虛擬機器很多、又有既定做法的時候，這是對的工具。對第一台虛擬機器來說，這是錯的工具。

⚠️ 一次只改一件事。同時改動韌體和控制器，是把可以解決的問題變成理不清的問題最常見的方式：虛擬機器依然無法開機，而現在有兩個嫌疑對象。

Linux 客體：原因相同，症狀比較安靜

同樣的事情也會發生，只是表現方式不同。開機載入程式執行了，接著系統停下來，等待一個永遠不會出現的根裝置。原因完全相同：早期開機映像在建立時沒有包含新控制器的驅動程式，因為在舊的虛擬化平台上從來不需要它。

修法的樣子也相同。從救援映像開機，重新建立包含該驅動程式的早期開機映像，然後才切換控制器。

不該做的事

不要重建虛擬機器再把舊磁碟接上去。新的虛擬機器會有同樣的控制器和同樣的結果，而且現在要追蹤的虛擬機器變成兩台。

先不要刪除來源虛擬機器。新的虛擬機器開機成功、做過實際工作並完成備份之後，遷移才算完成。不是複製結束的那一刻。

不要等到事後才發現快速啟動設定。在啟用快速啟動的狀態下關機的 Windows 客體並不會完全關機，因此在這種狀態下做的硬體變更，面對的是一個以為自己正在繼續執行、而不是重新開機的系統。

Atlas 的做法

Atlas 把這個問題所牽涉的兩件事放在同一個畫面上。虛擬機器的硬體檢視會同時顯示磁碟、它所連接的控制器以及韌體設定，所以兩者之中哪一個出錯，看一眼就能回答，不必靠反覆嘗試。

資源鏈也直接回答了三個問題中的第一個：地圖會把虛擬機器一路畫到實體磁碟，因此匯入後從未連接的磁碟會明顯地從鏈上缺席，而不是藏在儲存區清單裡。

在套用這類變更之前，Atlas 會先建立快照，所以即使客體反應不佳，可以復原的路徑依然可以復原。受影響的資源會在變更執行前列出，正是這一點讓一次只改一件事成為可行的做法，而不只是一句建議。