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 能不能跑”,互操作性矩阵管“软件和软件能不能搭”。升级前两类都要查,缺一不可。
二、核查 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 升级或确认支持状态 |
完成上述核查后,你会得到一张清晰的“版本支持地图”:哪些组件可以直接升级,哪些需要先升级外围软件,哪些硬件需要先更新固件,哪些 Guest OS 需要提前迁移或升级。这张地图就是后续升级迁移计划的输入依据。只有把兼容性核查做扎实,升级过程才不会在半夜因为一个未签名的 VIB 或一个过旧的备份代理而中断。