怎麼確認主機現在是哪個版本、哪個構建號？

開啟 SSH 或 ESXi Shell 後執行 esxcli system version get，會列出產品名、版本號和構建號（Build），也可以執行 vmware -vl；Host Client 登入後的首頁同樣能看到。打補丁前後各看一次，就能確認補丁有沒有裝上。

ESXi 9 還有免費版嗎？

免費的 vSphere Hypervisor 是 2025 年 4 月隨 8.0 U3e 重新提供的，不能接入 vCenter，使用條款也有限制。9.x 是否提供免費版、條款如何，以 Broadcom 支援門戶當前的下載頁面為準。確認之前，需要零授權成本的單機實驗環境只能用 8.0 的免費版，要注意它同樣在 2027 年 10 月 11 日結束常規支援。

vCenter 8 能管理 ESXi 9 主機嗎？

不能。vCenter 的版本不能低於它管理的主機，9.0 主機必須由 9.0 或更新的 vCenter 管理，所以升級順序永遠是先 vCenter、後主機。反過來，vCenter 9 能管理哪些補丁級別的 8.0 主機，以 Broadcom 互操作性矩陣為準。

ESXi 9 更新了什麼：新特性、系統要求與是否值得升級

ESXi 9（版本號 9.0）於 2025 年 6 月隨 VMware Cloud Foundation 9.0 釋出，是 Broadcom 收購 VMware 之後的第一個大版本。和 8.0 相比，ESXi 9 更新了什麼，落到一台台主機上主要是五點：隨 VCF 9 和 VMware vSphere Foundation（VVF）9 訂閱交付，文件裡改稱 ESX；版本號改為四段式；叢集補丁管理只保留映像（image）方式；NVMe 記憶體分層從技術預覽變成正式功能；對 CPU、引導方式和 I/O 裝置驅動的要求更嚴。值不值得升級，看三個條件：硬體在 9.0 的相容列表裡，訂閱包含 9.x，vCenter 和備份軟體已經就緒。任何一項不滿足，就先留在 8.0，並按 8.0 的支援期規劃下一步。

ESXi 9 和 ESXi 8.0 對比

對比項	ESXi 8.0	ESXi 9.0
釋出	2022 年 10 月；8.0 U3 於 2024 年 6 月釋出	2025 年 6 月，隨 VCF 9.0、VVF 9.0 釋出
名稱	ESXi	Broadcom 的文件和釋出說明裡寫作 ESX（不是早年帶 Linux 服務控制檯的那個 ESX）
版本號	8.0 U3 加字母后綴的補丁，如 8.0 U3e	四段式，形如 9.0.0.0，更新和補丁體現在後幾段
獲取方式	訂閱；8.0 U3e 起重新提供功能受限的免費版	隨 VCF、VVF 9 訂閱交付；是否有免費版以 Broadcom 門戶為準
叢集補丁管理（vLCM）	基線（baseline）和映像兩種方式，基線已列為棄用	只支援映像方式
NVMe 記憶體分層	8.0 U3 中為技術預覽	正式支援
CPU	停止支援 Sandy Bridge（至強 E5 v1）等老平台，Ivy Bridge（E5 v2）等安裝時出棄用警告	門檻繼續提高，具體代際以 Broadcom 知識庫為準
引導方式	UEFI 為主，傳統 BIOS 已列為棄用	按 UEFI 規劃
常規支援	到 2027 年 10 月 11 日	以 Broadcom 產品生命週期頁面為準

表中 9.0 一列只寫確定的變化方向。哪些 CPU、網路卡和陣列卡被移除，Broadcom 會隨補丁持續更新清單，不要憑網上的二手列表下結論，下文給出逐台核實的方法。

新特性裡對機房維運影響大的四項

補丁管理只剩映像方式

8.0 的 vSphere Lifecycle Manager 有兩種管理方式：基線方式沿用早年 Update Manager 的做法，給主機掛上補丁基線、缺什麼補什麼；映像方式給整個叢集定義一個“期望狀態”，由 ESXi 基礎映像、伺服器廠商附加元件（vendor add-on）、驅動和韌體元件組成，所有主機必須與它一致。9.0 起只保留映像方式。

對機房的實際影響是：主機上那些零散裝進去的第三方驅動、管理代理，都必須能放進同一個映像裡。建議在升級之前，就在 8.0 的 vCenter 裡把叢集從基線轉換為映像管理。轉換向導會檢查每台主機上的元件能否組成統一映像，驅動版本對不上、廠商元件衝突，會在這一步暴露出來，比升級到一半才發現好處理得多。不受 vCenter 管理的單台主機，可以用 9.0 的 ISO 引導升級，也可以用 Broadcom 提供的離線包升級，支援哪些方式以 9.0 的升級文件為準。

NVMe 記憶體分層正式可用

記憶體分層（Memory Tiering）把一塊 NVMe 盤作為第二層記憶體：存取頻繁的熱頁留在 DRAM，長時間不用的冷頁放到 NVMe 上。它在 8.0 U3 中是技術預覽，9.0 轉為正式支援。

對 IDC 和私有云來說，宿主機能放多少台虛擬機器，瓶頸常常是記憶體而不是 CPU。很多業務虛擬機器分配了 16 GB、32 GB 記憶體，真正頻繁存取的只是一小部分，這類負載用記憶體分層可以提高單機密度。它不適合記憶體存取密集、對延遲敏感的負載，例如大型資料庫的緩衝池。啟用前要注意三點：需要單獨的 NVMe 裝置，Broadcom 對它的耐久度和效能有要求；NVMe 層能佔多大比例由主機引數控制；哪些虛擬機器配置不能使用記憶體分層。這三項都以 9.0 文件為準。

交付方式和授權

9.0 主要隨 VCF 9、VVF 9 訂閱套件交付。和以往大版本一樣，許可證按大版本區分：8.x 的許可證不能用於 9.0，主機升級前要確認訂閱包含 9.x 的權益。授權的分配方式也隨 VCF 9 做了調整，按 Broadcom 的 VCF 9 授權文件操作，不要直接套用 8.0 時代逐台填許可證金鑰的教程。

名稱和版本號

搜資料時，ESX 9.0 和 ESXi 9.0 指的是同一個東西。版本號從 8.0 的“U3e”這種寫法改成四段數字，和 Broadcom 溝通、核對安全公告時，同樣以構建號為準。

系統要求：CPU、引導方式、驅動和系統盤

CPU：8.0 上的棄用警告就是訊號

VMware 一貫分兩步淘汰 CPU：先在某個大版本里列為“棄用”，安裝和升級時給出警告但允許繼續；再在後續版本里“停止支援”，安裝程式直接拒絕。Broadcom 知識庫裡 CPU Support Deprecation and Discontinuation In vSphere Releases 一文按版本列出了這兩類代際。判斷標準很簡單：在 8.0 上安裝或升級時出現過 CPU 棄用警告的主機，升級 9.0 前必須逐台核對這篇知識庫，不要預設能裝。

不想只看文件，可以讓 9.0 的安裝程式自己檢查，而且不會動硬碟：透過 BMC 掛載 9.0 的 ISO 並從它啟動，選盤、設密碼之後，安裝程式會掃描硬體並列出錯誤和警告。這時還沒有寫盤，看完結果直接重啟，主機原樣回到 8.0。如果安裝程式連啟動都完成不了，同樣說明這台機器過不了 9.0 的門檻。

引導方式和系統盤

UEFI：傳統 BIOS 引導在 8.0 已列為棄用，準備上 9.0 的主機一律按 UEFI 規劃。ESXi 裝好後不能直接切換引導方式，從傳統 BIOS 轉到 UEFI 需要重灌，重灌時選保留 VMFS，虛擬機器檔案不受影響。
系統盤：7.0 U3 起，只用 U 盤或 SD 卡作為啟動裝置已被列為棄用，準備上 9.0 的主機不要再沿用這種做法。新規劃直接用本地 SSD 或 M.2 做系統盤，和放虛擬機器的資料儲存分開。
分割槽佈局：7.0 起的系統盤由引導分割槽、兩個輪換使用的啟動區（bootbank）和系統資料分割槽 ESX-OSData 組成，8.0 沿用。9.0 各分割槽的預設大小有沒有調整，以 9.0 安裝文件的系統儲存一節為準。升級前可以先看一眼現有主機的佈局和剩餘空間：

ls -l /vmfs/volumes/                  # 可以看到 BOOTBANK1、BOOTBANK2、OSDATA- 開頭的卷和各資料儲存
esxcli storage filesystem list        # 各卷的型別、容量和剩餘空間

驅動和 I/O 裝置

每個大版本都會移除一批老裝置的驅動，7.0 去掉 vmklinux 相容驅動就是一例。8.0 上工作正常的網路卡和陣列卡，不代表在 9.0 上有驅動。比較可靠的核對方法是拿裝置的 PCI ID 去相容性指南里查：

vmkchdev -l | grep -E 'vmnic|vmhba'   # 每個網路卡、儲存控制器的 VID:DID SVID:SSID
esxcli network nic get -n vmnic0      # 驅動名、驅動版本和網路卡韌體版本
esxcli software vib list | grep -v -i -E 'vmware|vmw'   # 第三方驅動和元件

vmkchdev -l 每行的格式類似 0000:3b:00.0 8086:1572 8086:0006 vmkernel vmnic0，前一組是 VID:DID，後一組是 SVID:SSID。在 Broadcom Compatibility Guide 的 I/O 裝置頁面按這四個 ID 搜尋，看有沒有 9.0 的條目，以及條目要求的驅動和韌體版本。網路卡、陣列卡的韌體不滿足時，先按伺服器廠商的說明升級韌體，再升級系統。

管理介面與中文支援

安裝程式和 DCUI 只有英文。 9.0 的 ISO 不分語言版本，鍵盤佈局選 US Default。不存在單獨的“ESXi 9 中文版”映象。
單台主機仍用 Host Client。 瀏覽器開啟 https://管理IP/ui，建虛擬機器、上傳 ISO、看日誌都在這裡；多台主機用 vCenter 的 vSphere Client。VCF 9 還把原來的 Aria Operations 更名為 VCF Operations，作為整套平台的維運入口，只用 vSphere 的環境日常仍以 vSphere Client 為主。
介面語言以釋出說明為準。 Host Client 和 vSphere Client 的介面語言一般跟隨瀏覽器的首選語言。9.0 提供哪些介面語言，以 9.0 釋出說明的語言支援部分為準，裝好後切換一下瀏覽器的首選語言就能確認；沒有中文時就用英文介面，查文件、搜報錯反而更方便。
中文客戶機系統不受影響。 中文版 Windows Server、中文 Linux 在 9.0 上照常安裝。虛擬機器名稱可以用中文，但資料儲存、連接埠組、ISO 檔名建議只用英文字母和數字，備份軟體、指令碼和命令列處理路徑時更少出問題。

升級前自查清單

找一台非生產主機做試點。 同型號的機器先升一台，跑一到兩週，確認網路卡、儲存、監控和備份都正常。
核對硬體。 整機型號和 CPU 在相容性指南的 9.0 列表裡；用 9.0 ISO 做一次不落盤的硬體掃描。
核對驅動和韌體。 用 vmkchdev -l 的 ID 逐個查網路卡和儲存控制器；按伺服器廠商的 9.0 支援說明升級 BIOS、BMC 和各板卡韌體，品牌伺服器準備廠商的 9.0 定製映象或附加元件。
整改引導。 確認是 UEFI 引導、系統盤不是 U 盤或 SD 卡，不滿足的先整改。
理順管理鏈路。 vCenter 先升到 9.0；叢集先從基線轉換為映像管理；備份、監控、儲存外掛都確認支援 9.0。
確認授權。 訂閱包含 9.x 的權益。
做好備份。 備份主機配置（vim-cmd hostsvc/firmware/sync_config 後執行 vim-cmd hostsvc/firmware/backup_config，按輸出的連結下載配置包），確認虛擬機器備份能恢復，記下管理網路配置。
留好退路。 主機升級出問題時，通常可以在啟動時按 Shift+R 進入恢復模式，切回啟動區裡儲存的上一個版本（只保留一個）；大版本升級後能否這樣回退、有什麼限制，以 9.0 升級文件為準，不要把它當成唯一的退路。虛擬機器的硬體版本一旦升級就不能降回去，主機升級後先不要動虛擬機器硬體版本，等確認不再回退。

老硬體先留在 8.0：判斷標準

情況	建議	理由
8.0 上出現過 CPU 棄用警告，知識庫或 9.0 安裝程式顯示不支援	留在 8.0，按 2027 年 10 月前換機規劃	9.0 裝不上，只能換機
網路卡、陣列卡在相容性指南里查不到 9.0 條目	留在 8.0，或先換卡	升級後可能找不到網路卡或資料儲存
只能用 U 盤、SD 卡引導，或只支援傳統 BIOS	先整改，做不到就留在 8.0	9.0 按 UEFI 和本地持久盤規劃
用的是免費版，或訂閱不含 9.x	留在 8.0	沒有 9.x 授權
vCenter、備份軟體還沒支援 9.0	等它們先就緒	先 vCenter、後主機，備份不能中斷
伺服器計劃在 2027 年 10 月前退役	不升級，到時隨硬體一起換	8.0 的常規支援到 2027 年 10 月 11 日，覆蓋剩餘服役期
新採購，整機在 9.0 相容列表裡，訂閱含 9.x	直接裝 9.0，新建叢集	少做一次大版本升級

要強調的是，“留在 8.0”是過渡，不是終點。8.0 的常規支援到 2027 年 10 月 11 日結束，之後的技術指導期到 2029 年 10 月 11 日，只有自助資料，不再發布補丁。宿主機上跑著客戶的虛擬機器，不應長期執行沒有安全補丁的系統；留在 8.0 的老機器，換機或遷移計劃要在 2027 年 10 月之前落實。

在機房裡怎麼落地

升級評估的第一步是弄清每台宿主機是什麼 CPU、什麼網路卡。Toplink DCIM 的機櫃與資產管理會把自動採集到的 CPU、記憶體、硬碟資訊寫進資產台帳並保留歷史，對照知識庫裡的 CPU 代際表，就能先圈出哪些宿主機在 9.0 門檻之外。剩下的候選機，用 IPMI 遠端管理遠端掛載 9.0 的 ISO，設定下一次從 ISO 啟動，在瀏覽器的 VNC 控制檯裡看安裝程式的硬體掃描結果，看完直接重啟回 8.0，整個評估不用進機房，也不會動到機器上的資料。