3. 兼容性矩阵与互操作性核查

在旧版本 vSphere 平台升级迁移项目中,最容易被低估、却最容易导致回滚的环节,不是升级操作本身,而是升级前的兼容性核查。很多团队把注意力放在“怎么升”,却忽略了“能不能升、升完还能不能互相通信”。VMware 生态由 vCenter、ESXi、vSAN、NSX、备份软件、监控工具、存储阵列和客户机操作系统共同组成,任意两个组件之间的版本错配,都可能在升级后表现为集群无法挂载、备份任务失败、NSX 控制平面失联等严重问题。因此,本节的核心任务是:学会用 VMware 官方兼容性指南(Compatibility Guide)和互操作性矩阵(Interoperability Matrix)逐项核查,把“版本能不能共存”这件事在动手之前就确认清楚。

一、先分清两类核查对象:兼容性与互操作性

VMware 官方提供两个容易混淆但用途不同的查询入口。第一个是 VMware Compatibility Guide(VCG),主要回答“某个硬件、固件、驱动、客户机操作系统或 vSAN 就绪节点,是否被某个 ESXi 版本支持”。它偏向硬件与底层平台,例如服务器型号、HBA 卡、网卡、存储阵列型号、阵列固件版本、Guest OS 版本。第二个是 Product Interoperability Matrix(互操作性矩阵),主要回答“VMware 产品之间、以及 VMware 产品与第三方产品之间,哪些版本组合是被支持的”。例如 vCenter 8.0 能否管理 ESXi 7.0,vSAN 版本与 vCenter 版本的对应关系,NSX 与 vCenter 的版本搭配,备份软件(如 Veeam、NetBackup)与 vSphere 版本的兼容关系。

简单记忆:VCG 管“硬件和 Guest OS 能不能跑”,互操作性矩阵管“软件和软件能不能搭”。升级前两类都要查,缺一不可。

vSphere 升级兼容性核查双入口模型 VMware Compatibility Guide (VCG) 回答:硬件 / Guest OS 能否被 ESXi 版本支持 服务器 / 主板型号 如 PowerEdge R750、ProLiant DL380 Gen10 I/O 设备:HBA / NIC / HCA 型号 + 固件版本 + 驱动版本 三者都要匹配 存储阵列 / SAN 型号 阵列固件、多路径插件 (NMP/PSP) 版本 vSAN 就绪节点 / HCL 磁盘控制器、SSD/NVMe 型号是否在 vSAN HCL Guest OS 支持列表 Windows / Linux 版本 + VMware Tools 版本 查询维度:产品 → 版本 → 型号 → 固件/驱动 Product Interoperability Matrix 回答:软件与软件之间哪些版本组合被支持 vCenter ↔ ESXi 如 vCenter 8.0 可管理 ESXi 7.0 及 8.0 vSAN ↔ vCenter / ESXi vSAN 版本随 vCenter 版本绑定,需同步升级 NSX ↔ vCenter / ESXi NSX-T 版本与 vCenter 版本有严格对应表 备份 / 监控 ↔ vSphere Veeam、NetBackup、vRealize Operations 版本 第三方插件 / VIB 存储插件、安全代理、硬件管理 VIB 签名 查询维度:产品 A → 版本 → 产品 B → 版本 互补

二、核查 vCenter 与 ESXi 的版本对应关系

这是升级路径的起点。VMware 的互操作性矩阵明确规定:高版本 vCenter 可以管理低版本 ESXi,但低版本 vCenter 不能管理高版本 ESXi。例如 vCenter Server 8.0 可以管理 ESXi 7.0、7.0 U3、8.0 等版本,但 vCenter 7.0 无法管理 ESXi 8.0。这条规则直接决定了升级顺序:先升 vCenter,再升 ESXi。

实际操作中,登录互操作性矩阵页面后,选择 “VMware vCenter Server” 作为产品 A,选择目标版本(如 8.0 U2),再选择 “VMware ESXi” 作为产品 B,矩阵会以绿色对勾标出所有被支持的 ESXi 版本组合。需要特别注意的是,矩阵中标注的支持状态分为 “Supported”“Not Supported”“Deprecated” 等,其中 Deprecated 表示当前仍可用但下一个大版本将移除,升级规划时应尽量避免停留在 Deprecated 组合上。

三、vSAN 与 NSX 的绑定关系核查

vSAN 的版本与 vCenter 版本是强绑定的。vSAN 8.0 必须运行在 vCenter 8.0 和 ESXi 8.0 之上,不能出现 vCenter 8.0 + ESXi 7.0 却启用 vSAN 8.0 特性的情况。核查时要在互操作性矩阵中同时确认三者的版本一致性,并额外检查 vSAN HCL(硬件兼容性列表)中磁盘控制器、SSD、NVMe 的型号和固件版本是否在支持范围内。如果磁盘控制器固件过旧,即使 ESXi 版本支持,vSAN 也可能在升级后出现磁盘组无法挂载。

NSX 的核查更为严格。NSX-T 每个版本都有明确的 vCenter 和 ESXi 版本对应表,且 NSX 的升级通常要求先升级 NSX Manager,再升级传输节点。如果 vCenter 先升级到 8.0,而 NSX 仍停留在不支持 8.0 的旧版本,NSX 控制平面可能无法与 vCenter 通信,导致整个网络虚拟化层失效。因此 NSX 的版本核查必须与 vCenter 升级计划同步进行。

四、备份、监控与第三方组件的核查

备份和监控软件往往是最容易被遗漏的环节。以 Veeam Backup & Replication 为例,其每个版本都有明确支持的 vSphere 版本范围。如果 vSphere 升级到 8.0,而 Veeam 仍停留在只支持到 7.0 的版本,备份任务会在升级后直接失败。核查方法是:在 Veeam 官方文档或互操作性矩阵中,确认 “Veeam 版本 ↔ vSphere 版本” 的对应关系,并提前规划 Veeam 的升级窗口。

监控工具同理。vRealize Operations(现 VMware Aria Operations)的版本必须与 vCenter 版本匹配,否则可能无法采集性能数据。此外,存储阵列的多路径插件(NMP/PSP)、硬件管理 VIB(如 Dell OpenManage、HPE iLO 驱动)、安全代理等第三方 VIB,都需要在 VCG 中确认其是否支持目标 ESXi 版本,并检查 VIB 的签名状态。未签名或签名过期的 VIB 在 ESXi 8.0 中可能被拒绝加载。

五、客户机操作系统与 VMware Tools 核查

Guest OS 的核查常被忽略,但影响面很广。VCG 中列出了每个 ESXi 版本支持的 Guest OS 列表,包括 Windows Server 2012 R2、2016、2019、2022,以及各主流 Linux 发行版的具体版本号。如果虚拟机运行的是已不在支持列表中的旧系统(如 Windows Server 2008 R2),升级后可能无法获得官方支持,甚至出现驱动不兼容。

VMware Tools 同样需要核查。ESXi 升级后,旧版 VMware Tools 可能无法正常工作,导致虚拟机无法正常关机、时间同步异常或网络性能下降。建议在升级 ESXi 之前,先将所有虚拟机的 VMware Tools 升级到与目标 ESXi 版本匹配的版本,或至少确认其兼容性。

六、核查结果记录与决策

为了把核查结果转化为可执行的升级决策,建议使用一张核查表逐项记录。以下是一个可直接参考的示例结构:

核查项 当前版本 目标版本 支持状态 风险与动作
vCenter Server 7.0 U3 8.0 U2 Supported 先升级,作为升级链起点
ESXi 主机 7.0 U3 8.0 U2 Supported vCenter 升级后逐台升级
vSAN 7.0 U3 8.0 U2 Supported 需同步升级,检查磁盘控制器固件
NSX-T 3.2 4.1 需确认 先升 NSX Manager,再升传输节点
Veeam 11a 12 需确认 升级 Veeam 后再升级 vSphere
存储阵列固件 厂商版本 A 厂商版本 B 需查 VCG 固件过旧需先升级阵列固件
Guest OS Win 2012 R2 Win 2019 2012 R2 可能 Deprecated 规划 Guest OS 升级或确认支持状态
核查顺序建议:先查 vCenter 与 ESXi 的对应关系,确定升级顺序;再查 vSAN、NSX 等平台组件;然后查备份、监控等外围软件;最后查硬件固件、驱动和 Guest OS。任何一项出现 “Not Supported”,都必须先解决该组件的版本问题,再启动升级。
常见误区:只查 ESXi 与硬件的兼容性,忽略 vCenter 与 ESXi 的版本对应关系;或者只查 VMware 产品,忽略备份、监控等第三方软件。这两类遗漏是升级后故障的主要来源。

完成上述核查后,你会得到一张清晰的“版本支持地图”:哪些组件可以直接升级,哪些需要先升级外围软件,哪些硬件需要先更新固件,哪些 Guest OS 需要提前迁移或升级。这张地图就是后续升级迁移计划的输入依据。只有把兼容性核查做扎实,升级过程才不会在半夜因为一个未签名的 VIB 或一个过旧的备份代理而中断。