我自己找到解決方案後才寫這篇文章，因為這是一個奇怪的“陷阱”，值得記錄下來。
儘管我在執行還原時遇到了此問題，但在 ESXi 安裝的引導磁碟機連接到系統時引導到另一個作業系統的其他情況下，可能會出現此問題，特別是在磁碟大小發生變更的情況下。
我最近剛恢復了 VMware ESXi 安裝的開機驅動器，其中還包含一個保存大部分虛擬機及其虛擬開機/系統磁碟的資料存儲，卻發現這個所謂的已知良好狀態在某種程度上被破壞了。
根據伺服器本地控制台上的顯示，ESXi 似乎正常啟動，但它表現出許多有問題的症狀：
無法使用 vSphere Client 登入，並顯示訊息「vSphere Client 無法連線到主持人。發生未知連線錯誤。 （由於連線失敗，請求失敗。（無法連接到遠端伺服器））」。
vSphere Client 的日誌包含錯誤：
System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it嘗試使用網頁瀏覽器登入伺服器時，瀏覽器報告連線被拒絕。
即使在本機控制台上啟用此功能後，也無法透過 SSH 連線到伺服器。
透過本機控制台重新啟動管理網路和管理代理程式並不能修復該問題。
在本機控制台上，discovery
hostd沒有運行，並且重新啟動也無法修復它。esxcli命令總是給出：Connect to localhost failed: Connection failure目錄下的目錄比預期少
/vmfs/volumes，而且它們似乎都不是我的任何資料儲存。即使本地用戶介面中的“重置系統配置”也無法修復它。 （我之所以嘗試這樣做，是因為我有一個已知良好的圖像，可以再次恢復，這是我在解決問題後所做的，儘管我不確定它是否改變了任何東西。）
我要恢復的備份副本是在伺服器關閉時拍攝的 RAID 邏輯磁碟的低階映像。刪除可能損壞的 RAID 陣列並重新建立它後，我使用連接在 HBA 上的單獨磁碟機啟動到實體 Windows Server 安裝，將映像複製到新的 RAID 上。我使用了 HDD Raw Copy Toolhddguru.com，這基本上是 Linux 命令的一個不那麼神秘和棘手的替代方案dd。
（這確實是一種野蠻的——儘管相當完整的——備份VMware的方式，但是這個磁碟主要只存儲虛擬機啟動/系統磁盤，而不是數據，所以無論如何，除非進行重大更改，否則它不會經常備份。
我使新的 RAID 邏輯磁碟比已備份的磁碟更大，因為我們已升級到 RAID 中更大的驅動器，並且資料存儲區有點滿。在確認備份有效後，我一直計劃擴大資料儲存。
我剛完成原始副本，就啟動到 ESXi，發現它很無聊。發生了什麼事？
這是一台相當舊的 ESXi 5.0 U3。 （它已經很好地滿足了我們目前的需求，我們沒有任何全職 IT 人員來管理為了升級而升級、修復它們經常引起的問題等）
答案1
就我而言，損壞可能來自 Windows，但其他軟體也可能導致相同的問題。
這絕對適用於 ESXi 5.0 U3，也可能適用於任何 ESXi 5.x，我猜可能也適用於任何 ESXi 6.x。它不太可能適用於 ESXi 7，它使用不同的、更簡單的分區佈局。
調查背景
當我終於開始弄清楚時，我非常接近進行全新安裝。
在 中查看，我注意到一件奇怪的事情是，所有目錄中/vmfs/volumes都有目錄，並且這些目錄包含文件，其內容與 Windows 資源管理器 shell 擴展一致。在不是也從未基於 Windows 的虛擬機器管理程式的系統分割區中發現這一點有點奇怪。$RECYCLE.BINDESKTOP.INI
我立即開始懷疑我用來複製磁碟映像的 Windows 作業系統對其做了什麼。 ESXi 在其啟動磁碟上使用多個 FAT 分割區，因此 Windows 可能會使用它們。考慮到磁碟映像是從已知良好的狀態獲取的，但在沒有執行任何操作的情況下失敗了之內ESXi，這似乎是最有希望的研究方向。
當我透過十六進位編輯器發現這些$RECYCLE.BIN目錄也出現在磁碟映像中時，我最初感到沮喪。起初，我認為這意味著在拍攝影像之前就已經造成了損壞——在 Windows Server 中也是如此。然而，這些結果證明是良性的，儘管它們引導我走向正確的方向。 Windows 可能會在看到原始邏輯磁碟（該磁碟尚未擴容）後立即新增這些內容，儘管磁碟一直保持「離線」狀態。
在十六進位編輯器中進一步探索（HxD - 十六進位編輯器和磁碟編輯器，非常好的工具）揭示了磁碟映像中的 GPT 分割區表與新 RAID 磁碟上的 GPT 分割區表之間的一個奇怪的小差異。這不是分區編輯器會顯示的差異，因為實際上邏輯上沒有什麼差別， 據我所知。這是你必須在原始十六進制轉儲中查找才能找到的東西。
根本原因
在這兩種情況下，分區數組中都有七個非空白條目。然而，根據 ESXi 最初寫入數組的方式，前三個條目之後存在一個空條目（所有 128 位元組均歸零）的間隙，因此最後四個有效條目落入其自己的 512 位元組扇區中。在 ESXi 中斷的即時磁碟上，最後四個有效條目已上移一個條目以縮小差距。這些條目在其他方面是相同的。
我不知道是誰幹的，是 Windows 還是 HDD Raw Copy Tool，但我有點懷疑是 Windows。我再次測試了它，這個變化將會出現立即地複製完成後，即使在複製期間和複製之後 RAID 邏輯磁碟機在磁碟管理 MMC 管理單元中處於「離線」狀態。這顯然是有意的更改，因為 CRC 都是正確的，而且備份 GPT 也同樣發生了更改。
我的理論是，無論是誰這樣做，都是在重寫GPT，因為它與磁碟的大小不匹配，並且它不是僅僅精確地複製現有陣列，而是將分區存儲為某種內部結構中的列表，然後重新 -直接寫數組，當然不會產生間隙。
附帶說明一下，ESXi 寫入的陣列中的條目的順序與磁碟上實體分割區的順序不同，但無論哪種程式至少縮小了間隙，都不會擅自對條目進行排序，謝天謝地！
手動修復
我不知道有什麼簡單的方法可以重新建立此間隙，因為通常任何分區編輯器都會執行相同的操作：將現有表轉換為該工具使用的內部表示形式，對該表示形式執行您請求的更改，然後然後以 GPT 格式寫回表，使其具有正確的資料。據我所知，數組條目在磁碟上的確切位置不應該是相關的，因此不會成為它寫回的所述“正確資料”的一部分。
但是，我有預感 ESXi 可能對確切的陣列佈局很挑剔，因此我決定手動修復它，看看會發生什麼。程序是：
- 確保磁碟在磁碟管理 MMC 管理單元中處於「離線」狀態（作為預防措施）。
- 在十六進制編輯器中開啟磁碟。在 HxD 中，它位於附加功能→開啟磁碟...你必須從“物理磁碟”中選擇它。請務必取消選取“以唯讀方式開啟”，該選項預設為啟用狀態。您將收到有關此行為危險的適當警告。
- 在主 GPT 陣列中，通常從 LBA 2 開始（在 48h 處的標頭四字處確認），透過複製範圍、進一步向下貼上，然後將間隙歸零，向下滑動應該位於間隙之後的條目。更好的是，只需從備份映像複製實際表（如果有的話）；但請注意，如果 LUN 的大小已更改，則不能只複製 GPT 標頭，否則這種情況可能會重複出現，因為該標頭的 20h 和 30h 字段的值會錯誤。
- 選擇全部的GPT 數組的範圍。從技術上講，您必須使用 GPT 標頭中 50h 和 54h 處的雙字的乘積來確定範圍，但該數字通常為 16,384 位元組。
- 採用步驟 4 中選擇的範圍的 CRC32。您可以使用線上計算器計算它這裡，確保將“輸入類型”設定為十六進制。將其以小端方式放入 GPT 標頭中的 58h 處。
- 暫時將零放入 10h 處 GPT 標頭的四個位元組中。
- 取標頭的 CRC32，其長度在標頭本身中由 0Ch 處的雙字指定。將其放入 10h 的標題中。
- 對備份 GPT 重複步驟 3 到 7。陣列及其 CRC 是相同的，因此您可以複製它們，但標頭會不同，因此具有不同的 CRC。備份標頭通常位於磁碟的最後一個磁區，陣列就在其前面，但從技術上講，您應該檢查主 GPT 標頭中的四字 20h 和備份標頭中的四字 48h 進行確認。
- 如果你是完全確定您已完成所有操作，點選「儲存」。同樣，HxD 會在這裡給你一個合適的警告提示。
您可以諮詢維基百科文章了解 GPT 格式的基本技術細節。
截圖
這是「損壞的」GPT 陣列的一部分；請注意，有效條目以 77Fh 結束，並且在此之前沒有長時間的零運行：
這是我修復它的方法；請注意，有效條目現在以 7FFh 結束：
結果
我真的沒想到這會起作用。我還沒有研究過它，但預計 UEFI 規範對數組條目的順序或間距沒有任何意義。事實上，每個分割區都有一個唯一的GUID恰恰這樣你不必須依賴這種脆弱的啟發法。因此，依賴數組索引與編寫表時的索引相同將是一個壞主意。
（話又說回來，這不是我第一次看到企業級軟體和韌體有不好的想法。似乎每次我戴上系統管理員的帽子時，我都會遇到一個或另一個愚蠢的想法一段程式設計......但讓我不要咆哮。
因此，我小心翼翼地保存了調整後的表，重新啟動到 RAID，啟動 ESXi，連接 vSphere Client，一切都恢復正常。
理想情況下，您通常最好使用 Veeam Backup 等工具，但在某些情況下更多特別指定解決方案可能是有序的，在這種情況下您可能會遇到此錯誤。