ESXi 6.7 還能用嗎？停止支援的風險、升級路徑與老主機問題

ESXi 6.7 還能用，但已經沒有任何支援：它的通用支援（General Support）在 2022 年 10 月 15 日結束，技術指導期（Technical Guidance）在 2023 年 11 月 15 日結束。主機和虛擬機器照常執行，授權也不會失效，失去的是補丁、驅動和廠商支援：此後公開的 ESXi 漏洞，常規渠道不再為 6.7 釋出修復，新出的網路卡、陣列卡也不會再有 6.7 的驅動。結論很直接：還在跑 ESXi 6.7 的主機，按 8.0 規劃升級；7.0 不適合作為終點，它的通用支援也已在 2025 年 10 月 2 日結束；硬體過不了 8.0 門檻的，換硬體或者遷到其他虛擬化平台。文末另外解答老主機上兩個常見問題：啟動停在 ssh，以及混用不同代 CPU 時 EVC 怎麼設。

ESXi 6.7 的支援時間線

時間	事件	對維運的影響
2018 年 4 月	ESXi 6.7 釋出	—
2019 年 8 月	6.7 Update 3 釋出，是 6.7 的最後一個 Update	之後只有補丁版本，不再增加新功能和新硬體支援
2021 年 11 月 15 日	原定的通用支援結束日，後來與 6.5 一起延期	—
2022 年 10 月 15 日	通用支援結束	不再發布補丁和安全修復
2023 年 11 月 15 日	技術指導期結束	官方不再提供任何形式的支援
2025 年 10 月 2 日	ESXi 7.0 通用支援結束	從 6.7 升到 7.0，同樣拿不到新補丁
2027 年 10 月 11 日	ESXi 8.0 計劃結束通用支援	現階段升級的合理目標

以上日期按 Broadcom（原 VMware）公佈的產品生命週期整理，以官方生命週期頁面為準。主機多的環境，先用 PowerCLI 把版本拉一遍，弄清還有多少台 6.7：

Connect-VIServer vcenter.example.internal
Get-VMHost | Sort-Object Version | Select-Object Name, Version, Build, Model, ProcessorType

單台主機在 ESXi Shell 裡執行 esxcli system version get，看 Version、Update 和 Build 三行。

繼續執行 6.7 有哪些風險，怎麼臨時加固

風險	具體表現	能否緩解
新漏洞沒有補丁	2022 年 10 月以後公開的 ESXi 漏洞，安全公告一般不再給出 6.7 的修復版本，漏洞掃描報告裡的高危項會一直留著	只能靠網路隔離減少暴露面，無法消除
已有的補丁沒打	2023 年 2 月的 ESXiArgs 勒索事件，利用的是 OpenSLP 漏洞 CVE-2021-21974，補丁 2021 年就已釋出，中招的多是管理口暴露在公網、長期沒打補丁的主機	升到 6.7 的最後一個補丁版本，關閉 SLP
硬體與備件	新型號的網路卡、陣列卡、NVMe 盤不會再有 6.7 的驅動；老配件停產後買到的替換件可能是新型號，裝上識別不了	囤同型號備件只能拖延
客戶機系統	6.7 之後釋出的作業系統不會進入它的客戶機支援列表；虛擬機器硬體版本最高到 15	新系統可能裝得上，但出了問題沒有依據可查
周邊軟體	備份、監控、儲存外掛的新版本陸續不再支援 6.x，只能停在舊版本，而舊版本自己也不再更新	無
故障無處求助	不能再向廠商提交支援請求	無

對 IDC 來說還多一層風險：一台 ESXi 上跑著多個客戶的虛擬機器，宿主機被攻破，影響的是這台機器上所有客戶的資料。

暫時不能升級：先做這五項加固

採購、授權或業務視窗的原因暫時升不了，至少把暴露面壓到最小：

1. 升到 6.7 的最後一個補丁版本。 停止支援前釋出的補丁仍然有效，核對當前構建號和 6.7 最後釋出的補丁，差幾個就補幾個。離線包能否下載，取決於你的 Broadcom 帳號是否有對應的授權。
2. 管理口只放在管理網，並在 ESXi 防火牆上限定來源。 443、902、22、427 都不應對公網開放。ESXi 自帶的防火牆可以按規則集限制來源，以 SSH 為例：

esxcli network firewall ruleset list                      # 所有規則集及是否啟用
esxcli network firewall ruleset allowedip list            # 每個規則集允許的來源
esxcli network firewall ruleset set --ruleset-id=sshServer --allowed-all=false
esxcli network firewall ruleset allowedip add --ruleset-id=sshServer --ip-address=10.10.0.0/24

--allowed-all=false 執行後，允許列表之外的位址就無法再建立 SSH 連線，最好在伺服器控制檯的 ESXi Shell 裡操作，或者先確認自己的來源位址在 allowedip add 填的網段裡。其他規則集照此處理，個別規則集不允許修改。限制 Web 管理和 vCenter 相關的規則集之前，先把 vCenter 的位址加進允許列表，否則主機會和 vCenter 失聯。

3. 關閉 SLP 服務。 不用 CIM 的 SLP 服務發現，就把它停掉，這是 ESXiArgs 事件後 VMware 給出的臨時措施：

/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off
chkconfig --list | grep slpd        # 顯示 slpd off 表示開機不再啟動

4. SSH 和 ESXi Shell 用完就關。 排查結束後執行 vim-cmd hostsvc/stop_ssh、vim-cmd hostsvc/disable_ssh，ESXi Shell 對應 stop_esx_shell、disable_esx_shell。由 vCenter 管理的主機可以開啟鎖定模式（Lockdown Mode），正常鎖定模式下只能經 vCenter 或 DCUI 管理。
5. 備份放到宿主機之外。 勒索軟體加密的是資料儲存裡的虛擬機器檔案，備份如果也在同一套儲存上、或者備份伺服器和 ESXi 共用一套管理員密碼，會被一起加密。至少保留一份離線或不可改寫的副本。

這些措施只能降低風險，不能替代升級。

6.7 升級路徑：能直接升到哪個版本

目標	能否從 6.7 直接升級	前提	適用情況
7.0	可以	vCenter 先升到 7.0 或更新；網路卡、儲存控制器都有原生驅動	不建議作為終點：7.0 已結束通用支援，升上去只換來更新的驅動和客戶機支援
8.0	以 Broadcom 的 ESXi 8.0 升級文件和互操作性矩陣為準，核對你的 6.7 構建號是否在支援的升級來源裡；不能直接升的，先升 7.0 再升 8.0	vCenter 先升到 8.0；CPU、驅動過 8.0 的門檻；準備 8.x 授權	硬體達標的主機首選
9.x	不能直接升級，要先到 8.0	新硬體、新訂閱	新採購的伺服器另建叢集
新硬體裝 8.0，遷移虛擬機器	不升級舊主機	新舊主機能由同一個 vCenter 管理時可以線上遷移，CPU 代際不同要用 EVC，見最後一節；不能時關機後複製虛擬機器檔案到新主機重新註冊	舊硬體過不了門檻
遷到其他平台	—	例如 Proxmox VE 8.2 起自帶 ESXi 虛擬機器匯入嚮導；也可以用 qemu-img convert -f vmdk -O qcow2 轉換磁碟；Windows 虛擬機器先裝好 virtio 驅動再改磁碟匯流排，否則會藍色畫面無法啟動	不再續訂 VMware

按 8.0 升級時的順序：

1. 清點每台主機的版本、CPU 和驅動。 命令見下一節，結果填進一張表，逐台標出能升、要換卡、要換機。
2. 查相容性指南。 在 Broadcom Compatibility Guide 裡分別查整機型號、CPU 系列、網路卡和陣列卡在 8.0 下是否列出，任何一項不在都不要硬升。
3. 先升 vCenter。 vCenter 的版本不能低於它管理的主機。Windows 版 vCenter 6.7 不能原地升級：7.0 起只有裝置版（vCSA），要用安裝程式的遷移（Migrate）功能轉換過去，能一步遷到哪個版本以升級文件為準。vCenter 8.0 能否管理尚未升級的 6.7 主機，同樣以互操作性矩陣為準；不能的話，按“vCenter 升 7.0、主機升 7.0、vCenter 升 8.0、主機升 8.0”分步走，每一步都在 7.0 和 8.0 各自的支援範圍內。
4. 每台主機先演練。 用離線包執行 esxcli software profile update ... --dry-run，重點看輸出裡的 VIBs Removed：被移除的如果是網路卡或陣列卡驅動，正式升級後這張卡就會消失。
5. 逐台升級。 進入維護模式、遷走虛擬機器、升級、重啟、檢查網路卡和資料儲存，確認無誤再做下一台；升級後分配 8.x 授權。
6. 收尾。 升級 VMware Tools；虛擬機器硬體版本按需升級，不是必須。6.7 時期建的 VMFS5 資料儲存在 8.0 上仍能掛載使用，但不能原地升級成 VMFS6，要新建 VMFS6 資料儲存，再用儲存遷移把虛擬機器搬過去。

硬體門檻：6.7、7.0、8.0 對照

專案	6.7	7.0	8.0
最低記憶體	4 GB	4 GB，建議 8 GB 以上	8 GB，執行虛擬機器建議 12 GB 以上
啟動裝置	U 盤、SD 卡都可以，容量要求很低	新的分割槽佈局，建議 32 GB 以上的本地持久儲存；7.0 U3 起不再推薦只用 U 盤或 SD 卡啟動	至少 32 GB；U 盤、SD 卡作為唯一啟動裝置已被棄用
裝置驅動	原生驅動和舊式 vmklinux 驅動都能用	只支援原生驅動	只支援原生驅動
TPM	支援 1.2 和 2.0	支援 1.2 和 2.0	不再支援 1.2
引導方式	傳統 BIOS、UEFI	傳統 BIOS、UEFI	傳統 BIOS 已被列為棄用，新裝用 UEFI
虛擬機器硬體版本上限	15（6.7 U2 起）	19（7.0 U2 起）	21（8.0 U2 起）

6.7 主機最常卡在兩處：CPU 代際和 vmklinux 驅動。

CPU。 下表是常見至強代際的大致情況，具體型號以 Broadcom 知識庫 CPU Support Deprecation and Discontinuation In vSphere Releases 的最新表格為準：

處理器	常見機型	7.0	8.0
至強 5600 系列（Westmere）及更早	Dell R610、R710，HPE G7	不支援	不支援
至強 E5 v1（Sandy Bridge-EP）	Dell R620、R720，HPE Gen8	能裝，提示將來可能不支援	不支援
至強 E5 v2（Ivy Bridge-EP）	Dell R620、R720，HPE Gen8	支援	能裝，提示將來可能不支援
至強 E5 v3、v4（Haswell、Broadwell）	Dell R630、R730，HPE Gen9	支援	能裝，較老的代際可能出現同樣的提示
至強可擴充套件處理器、AMD EPYC	Dell R640、R740，HPE Gen10 及更新	支援	支援

驅動。 7.0 起刪除了 vmklinux 相容層，6.7 上靠舊式驅動工作的網路卡和陣列卡，升級後會直接消失。先看每張卡用的是什麼驅動：

esxcli hardware cpu list | grep Brand | head -n 1   # CPU 型號
esxcli network nic list                       # 看 Driver 一列
esxcli storage core adapter list              # 看 Driver 一列

舊式驅動名	對應的原生驅動	常見裝置型別
igb	igbn	Intel 千兆網路卡，如 I350
ixgbe	ixgben	Intel 萬兆網路卡，如 82599、X540
tg3	ntg3	Broadcom BCM57xx 千兆網路卡，伺服器板載常見
bnx2x	qfle3	QLogic、Broadcom 萬兆網路卡，如 57810
megaraid_sas	lsi_mr3	LSI、Broadcom MegaRAID 陣列卡
mpt2sas、mpt3sas	lsi_msgpt2、lsi_msgpt3	LSI SAS HBA
hpsa	nhpsa	HPE Smart Array

Driver 列顯示的是左列的名字，說明這張卡在用舊式驅動。有對應的原生驅動，不等於你這張卡的具體型號被它支援，老型號常常不在原生驅動的支援列表裡，最終以相容性指南中 8.0 對該裝置列出的驅動為準。

ESXi 6.7 主機啟動停留在 ssh 怎麼辦

ESXi 啟動時，進度條下方會滾動顯示正在載入的模組和服務名稱。畫面長時間停在 ssh 這類字樣上，只能說明啟動卡在這一帶，SSH 服務本身很少是原因；常見的是儲存超時、啟動介質損壞這類問題，螢幕上看不出來，要看日誌才能確定。按下面的順序排查：

1. 先別急著斷電。 儲存路徑超時會讓啟動拖很長時間，這期間強制重啟只會從頭再等一遍。同時 ping 一下管理 IP，試著開啟 https://管理IP/ui，確認主機是不是其實已經起來了。
2. 看即時日誌。 在伺服器控制檯按 Alt+F12，切換到 VMkernel 日誌的即時輸出，看最後幾十行在報什麼；啟動完成後按 Alt+F2 回到 DCUI。按了沒有切換畫面，就等主機起來後檢視 /var/log/vmkernel.log。機房裡的伺服器透過 BMC 遠端控制檯傳送這組按鍵即可。
3. 對照日誌判斷原因：

日誌裡的線索	可能原因	處理
反覆出現 iSCSI 登入失敗、NFS 掛載超時	外部儲存或儲存網路不可達，主機在逐個等待超時	先恢復儲存網路；儲存確實已下線的，等超時走完主機一般能起來，之後移除失效的目標
大量針對某幾個 LUN 的預留衝突（reservation conflict）	虛擬機器用 RDM 磁碟組建了 Windows 故障轉移叢集，這些 LUN 沒有標記為長期預留	啟動完成後，在每台能看到這些 LUN 的主機上設定 perennially reserved，命令見下方
啟動裝置報讀寫錯誤或超時，裝置名多為 vmhba32 一類的 U 盤或 SD 卡	6.7 時期常用的 U 盤、SD 卡啟動介質老化損壞	換啟動介質重灌並保留資料儲存；順手把啟動盤換成本地 SSD 或 M.2，為升級 8.0 做準備
日誌停止滾動，或出現硬體錯誤	陣列卡、記憶體、硬碟故障	查 BMC 的系統事件日誌（SEL）和陣列卡狀態

esxcli storage core device list | grep -i -E '^naa|Display Name'    # 找到叢集磁碟的裝置 ID
esxcli storage core device setconfig -d naa.600601601e203a00b4c5d6e7f8091a2b --perennially-reserved=true
esxcli storage core device list -d naa.600601601e203a00b4c5d6e7f8091a2b | grep -i perennially

裝置 ID 換成實際值，每個叢集磁碟都要設定。如果是打完補丁後第一次啟動就卡住，在啟動畫面出現時按 Shift+R 進入恢復模式，可以切回補丁前的版本，先讓業務恢復，再查原因。

混用不同代 CPU：EVC 與 Per-VM EVC 怎麼設

同一個叢集裡放了不同代的 CPU，例如 E5 v2 的老主機和至強可擴充套件處理器的新主機，虛擬機器在它們之間線上遷移時會報 CPU 不相容。原因是虛擬機器開機時看到了新 CPU 的指令集（如 AVX2），遷到不支援這些指令的老主機上就無法繼續執行。EVC（增強型 vMotion 相容性）的作用，是把所有主機對虛擬機器呈現的 CPU 特性統一降到某一代的水平。它要求 vCenter，叢集裡的 CPU 必須是同一廠商，Intel 和 AMD 不能混用。

叢集 EVC。 在 vSphere Client 裡選中叢集，進入“配置 → VMware EVC → 編輯”，模式選叢集裡最老那一代 CPU 對應的基線，比如最老的是 E5 v2，就選 Intel Ivy Bridge Generation。對話方塊會逐台檢查主機是否相容。注意兩點：

• 已經在執行的虛擬機器，如果用到了高於新基線的特性，開啟 EVC 前要先關機；
• 以後退役了老主機、把 EVC 調高，正在執行的虛擬機器要完全關機再開機才會用上新特性，在作業系統裡重啟不算。

Per-VM EVC（6.7 新增）。 6.7 起可以給單台虛擬機器設定 EVC 模式，設定儲存在虛擬機器自身，跟著它跨叢集、跨 vCenter 遷移，適合“老叢集裡的虛擬機器要遷到新的 8.0 叢集，又不想動整個叢集的 EVC”這種過渡場景。條件和限制：

專案	要求
虛擬機器硬體版本	14 或更高，即 6.7 及之後建立或升級過的虛擬機器
修改時機	虛擬機器必須關機
設定位置	選中虛擬機器，“配置 → VMware EVC → 編輯”
與叢集 EVC 的關係	虛擬機器位於開啟了 EVC 的叢集時，它的模式不能高於叢集的模式
能開機的主機	只能在 CPU 支援該模式的主機上開機和遷入

設完以後，可以在 Linux 虛擬機器裡確認基線是否生效：

grep -o -w -E 'avx2|avx512f' /proc/cpuinfo | sort -u

基線設為 Ivy Bridge 時這條命令沒有輸出，因為 Ivy Bridge 還沒有 AVX2。反過來也要權衡：EVC 基線定得太低，資料庫、壓縮、加解密這類用得上新指令的業務會損失效能，所以混用只適合遷移過渡期，老主機退役後及時把基線調高。

在機房裡怎麼落地

升級 6.7 的工作量主要在清點和現場操作。清點階段，要把每台宿主機的型號、CPU 和網路卡、陣列卡對上號。在 機櫃與資產 裡，每台伺服器的 CPU、記憶體、硬碟配置都記在台帳上，人工錄入的配置和下發指令碼自動採集的結果同時保留，對照著就能整理出哪些機器還是 E5 v1、v2 這一代；換下來、換上去的啟動盤、硬碟等部件按批次入庫，型號和去向都有記錄。操作階段，掛載 8.0 的 ISO、看啟動卡在哪一步、傳送 Shift+R 這類按鍵，都可以在 IPMI 遠端管理 的瀏覽器控制檯裡完成，不必為每台主機跑一趟機房。