3. 补丁与更新的类型
在 vSphere 环境中，“打补丁”从来不是单一动作。ESXi 主机、vCenter Server、驱动与固件分属不同交付通道，更新包的性质也完全不同。如果把它们混为一谈，就会出现“补丁都打了，为什么漏洞还在”“升级后网卡反而掉了”这类典型问题。本节先把五类更新拆开，再说明 VMSA 与补丁之间的对应关系，为后续的基线、合规扫描和升级顺序打基础。
五类更新的本质差异
安全补丁（Security Patch）用于修复已公开披露的安全漏洞，通常对应 CVE 编号。它的特点是“必须尽快、可单独评估、影响面明确”。在 vSphere 中，安全修复往往以 VIB（vSphere Installation Bundle）形式随公告发布，可能只替换某个组件，例如 OpenSLP、ESXi 的某个用户态服务或 vCenter 的某个 Java 库。
Bug 修复（Bug Fix）解决的是功能异常、性能退化或稳定性问题，例如某型号 HBA 在高 IO 下超时、vMotion 偶发失败、vCenter 任务卡住。它不一定有 CVE，但会直接影响生产可用性。Bug 修复常以累积补丁（Cumulative Patch）或 Express Patch 形式发布，后者体积小、只含少量修复。
功能更新（Feature Update）带来新能力或行为变化，例如新增设备支持、引入新的 API、调整默认策略。它通常出现在 Update 版本（如 ESXi 7.0 Update 3）中，而不是单个补丁。功能更新需要评估兼容性与运维流程变化，不能当作“顺手打一下”的补丁。
驱动更新（Driver Update）针对存储、网络、GPU 等硬件驱动。它必须与服务器型号、固件版本、ESXi 版本三者匹配。驱动常以 Async Driver 形式单独发布，例如 nenic、lpfc、bnxtnet 等。驱动更新最容易被忽略，也最容易在升级后引发紫屏（PSOD）或链路抖动。
固件更新（Firmware Update）作用于 BIOS、iDRAC/iLO、RAID 控制器、网卡固件等，运行在 ESXi 之下，不由 ESXi 补丁机制管理。它通常通过厂商工具（如 Dell iDRAC、HPE iLO、Lenovo XClarity）或离线 ISO 完成。固件与驱动存在严格的配套矩阵，先固件后驱动是常见顺序。
VMSA 与补丁的对应关系
VMSA（VMware Security Advisory）是 VMware 发布安全漏洞信息的官方公告，每条 VMSA 对应一个或多个 CVE，并明确列出受影响的产品、版本范围、修复版本以及可用的缓解措施。理解 VMSA 的关键在于：VMSA 本身不是补丁，而是“漏洞—修复”的索引。真正落地时，需要把 VMSA 中的修复版本映射到具体的 ESXi Build 号或 vCenter 版本。
例如某条 VMSA 声明“ESXi 7.0 受影响，修复版本为 7.0 Update 3k（Build 21930508）”。这意味着：如果当前主机 Build 低于该值，就存在该漏洞；升级到该 Build 或更高版本即可修复。若公告同时给出“临时缓解措施”，例如禁用某服务或修改高级参数，则可在无法立即升级时先降低风险，但不能替代补丁。
实际工作中，建议按以下顺序处理 VMSA：
- 读取 VMSA 的 CVE 列表与 CVSS 评分，判断严重等级；
- 核对受影响产品与版本范围，确认自己的 ESXi/vCenter 是否在列；
- 找到“Fixed Version”字段，记录目标 Build 号；
- 在 VMware Patch Release Notes 或 KB 中确认该 Build 包含的 VIB 与已知问题；
- 结合厂商固件/驱动矩阵，确认升级后硬件仍受支持；
- 在测试环境验证后，再进入生产维护窗口。
驱动与固件的配套关系
驱动和固件是五类更新中最容易被低估的部分。ESXi 的驱动由 VMware 或硬件厂商以 Async Driver 形式发布，而固件由服务器厂商发布。两者之间存在明确的兼容矩阵。以某型号 25GbE 网卡为例，若固件版本为 A，而 ESXi 驱动版本为 B，可能工作正常；但固件升到 C 后，旧驱动 B 可能出现链路反复 up/down。因此，正确的做法是：先查厂商兼容矩阵，确定固件与驱动的目标版本组合，再按“先固件、后驱动、最后 ESXi 补丁”的顺序推进。
需要特别注意的是，固件更新通常需要重启主机，且部分 RAID 控制器固件升级会重建缓存策略。因此固件更新应单独安排维护窗口，不要与 ESXi 补丁升级混在同一次重启中草率完成。
更新类型速查表
| 更新类型 | 典型来源 | 是否含 CVE | 交付方式 | 关键风险 |
|---|---|---|---|---|
| 安全补丁 | VMSA / Patch Release Notes | 是 | VUM / vLCM / 离线 Depot | 延迟修复导致暴露窗口扩大 |
| Bug 修复 | KB / 累积补丁 | 通常否 | VUM / vLCM | 修复引入回归，需看已知问题 |
| 功能更新 | Update 版本发布说明 | 可能含 | ISO / vLCM 映像 | 行为变化影响自动化与运维流程 |
| 驱动更新 | VMware 兼容性指南 / 厂商 | 否 | Async Driver VIB / 离线包 | 与固件不匹配导致 PSOD 或断链 |
| 固件更新 | 服务器厂商 | 否 | iDRAC / iLO / 厂商 ISO | 升级失败或需重启，影响面大 |
一个可执行的判断示例
假设运维人员收到一条 VMSA，CVE 评分为 9.8，影响 ESXi 7.0 至 7.0 Update 3j，修复版本为 7.0 Update 3k（Build 21930508）。当前环境为 7.0 Update 3f（Build 21313628），且主机为某品牌双路服务器，网卡固件版本为 20.31.10，驱动为 nenic 1.0.25.0。
处理思路如下：先确认 7.0 Update 3k 是否在厂商兼容列表中；再查该品牌服务器对 7.0 Update 3k 的固件最低要求，若要求网卡固件不低于 20.35.20，则需先升级固件；随后确认 nenic 驱动在 3k 中的内置版本是否满足矩阵，若不满足则需额外注入 Async Driver；最后在测试主机上完成升级，观察 vmkernel.log 中是否有驱动告警、网络链路是否稳定，再推广到生产。整个过程的核心不是“打补丁”，而是把 VMSA、补丁 Build、驱动、固件四者对齐。
掌握这五类更新的差异与 VMSA 的对应逻辑后，后续的基线定义、合规扫描和升级编排才有可靠依据。补丁治理的第一步，永远是先分清“打的是什么”。