简介ESXi670-202210001.zip 是 VMware 针对 ESXi 6.7 发布的官方安全与功能更新补丁主要面向虚拟化运维人员与 vSphere 管理员旨在修复已知安全漏洞、性能缺陷提升系统整体稳定性与合规性。压缩包共含 152 个文件整体大小约 443.53MB其中以 149 个 VIB 安装包为主涉及 esx-base、vsan、vsanhealth、cpu-microcode 等核心组件另有两个 XML 索引文件 index.xml、vendor-index.xml用于供 VMware Update Manager 识别补丁构成及供应商信息metadata.zip 则封装补丁描述、适用性与依赖关系便于自动化更新流程使用。该资源已有 1431 人学习反映出其在 ESXi 补丁管理场景中的参考价值。通过解压对照这些文件管理员可以清楚了解离线补丁的打包结构和 VIB 机制从而在真实环境中更规范地完成补丁扫描、应用与回滚保障虚拟化集群持续处于安全且稳定的运行状态。1. 这是ESXi 6.7的什么补丁先搞懂ESXi670-202210001再动手某天你的监控平台跳出一条告警ESXi 6.7 主机旧 Build 存在安全漏洞而修复下载链接指向 ESXi670-202210001.zip。这个文件是 VMware 在 2022 年 10 月针对 ESXi 6.7 发布的补丁包一次补齐该年 10 月前的安全修复与稳定性问题。它解决的是生产环境最头痛的事主机一直裸奔在旧版本上想升级又怕翻车。适合运维和虚拟化管理员尤其是没有 vCenter 统一管理、只能一台台 SSH 处理的主机。先说个反直觉的结论打这个补丁不一定要走 VUM命令行操作反而更可控也更容易留后路。2. 拆开 ESXi670-202210001 补丁包结构、命名与升级前的三查2.1 从文件后缀和内部结构判断补丁的适用范围VMware 给 ESXi 6.7 的补丁通常有两种分发格式一个完整安装 ISO和一个 zip 格式的 offline bundle。标题里的 ESXi670-202210001.zip 就是后者。它不是安装镜像而是面向运行中的 ESXi 主机的补丁包。zip 里包含若干个 VIBvSphere Installation Bundle以及描述这些 VIB 依赖关系的 metadata。用解压工具先看一遍不会坏还能确认没有混入奇怪文件。# 列出补丁包内的文件确认 depot 结构 unzip -l ESXi670-202210001.zip输出里通常有 metadata.zip、profile 目录、vibs 目录和 vendor 相关文件。这些文件被 ESXi 的软件栈统称为 depot。depot 中定义了一个或多个 profile例如 ESXi-6.7.0-202210001-standard。standard 表示标准版不带 no-tools 后缀no-tools 会在升级时跳过 VMware Tools 更新。这里有一个选型经验如果虚拟机里的 VMware Tools 都是手动更新或另有渠道那么选 no-tools 可以减少重启后的验证动作但一般我仍然推荐 standard因为它是 VMware 默认测试过的组合。选错也不会造成严重后果只是升级行为不同。这里有一个常见误用有人把 zip 当成安装包在 Windows 上双击解压然后试图用 vSphere Client 的“升级包”界面导入。导入本身没问题但真正生效必须由 profile 驱动不能直接解压到本地。ESXi 主机只认 depot zip不认解压后的目录。所以后续操作全部围绕 zip 本身展开。2.2 升级前必须确认当前 Build、受支持路径与兼容性执行 ESXi 6.7 补丁升级前我一般会先记录现状。最少三条命令# 查看版本和 build 号 vmware -v # 查看更详细信息和上次更新时间 vmware -vl # 查看当前激活的 profile esxcli software profile get第一条只能看到版本第二条会带出 build 号第三条显示当前 profile。如果当前主机已经是 6.7 的最终补丁之一再装 202210001 只是把少量延期修复补上。如果是从很早的 6.7 GA 直升就需要确认 VMware 支持路径是否允许跨多个 Update。通常 offline bundle 可以跨版本直接升但前提是主机硬件和厂商定制驱动不干涉。另一个要确认的是 vCenter 版本ESXi 升级到 202210001 后vCenter 至少要能管理该版本的 ESXi否则会出现主机连接跟随失败。还有一个人容易忽略的点是第三方 VIB。用服务器厂商定制镜像装机的环境里往往有厂商的驱动或监控组件。esxcli software profile update 会重新评估整个 profile 的依赖如果厂商 VIB 与补丁中的同名 VIB 版本冲突升级会直接报错。所以升级前把当前 VIB 列表导出一份留底# 导出当前 VIB 列表升级后用于对比 esxcli software vib list /tmp/vib_before.txt这个文件在升级后用来对比哪些组件被替换或增加。不要只在屏幕上扫一眼直接存文件后续排查会省时间。2.3 从官网下载到校验别让一个坏 zip 毁掉维护窗口补丁下载入口在 VMware 的 Patch Download Center搜 ESXi670-202210001 就能找到。下载需要 VMware 账号且账号需要有补丁下载权限。文件名很容易记但不同地区下载到的内容一样校验值才是区分完整的关键。先看官方页面给出的 SHA1 或 SHA256如果你是 Linux 终端用# 计算补丁包 SHA256与官方页面核对 sha256sum ESXi670-202210001.zip把输出和官方核对。平时我还会顺手跑一下 zip 完整性测试# 测试 zip 的 CRC 校验排除下载损坏 unzip -t ESXi670-202210001.zipunzip -t 能发现下载中途断流或传输工具破坏的情况。这里有一个细节ESXi 6.7 补丁包的签名体系是 SHA-2如果你的校验脚本还是多年前写死的 SHA-1对不上不代表文件错了先换命令再怀疑文件。到这里准备还没完。如果打算用 VUM 升级zip 可以直接导入 VUM 的更新存储库如果打算用 SSH 命令行就需要先把 zip 放到主机能访问的位置。这一步放到下一章展开。3. 用 esxcli 把 ESXi670-202210001 装上上传、维护模式与重启3.1 把补丁包传上主机并安全进入维护模式先决定传输方式。常见做法是直接 scp 到 ESXi 主机的 /tmp也可以放到某台 HTTP 服务器上由主机远程拉取。我图省事时用 scp但会先确认 /tmp 空间够不够。# 查看 /tmp 可用空间至少要是补丁包两倍大小 df -h /tmp如果空间不够建议传到一个 datastore 目录。datastore 路径中带空格时命令里要用引号包住例如# 列出 depot 中的 profile注意 datastore 路径空格用引号 esxcli software sources profile list -d /vmfs/volumes/datastore1/ESXi670-202210001.zip传输完成之后升级前把主机上的虚拟机全部迁移走或关闭。如果是加入集群且启用了 DRS可以逐个主机进入维护模式由 DRS 自动迁走。如果发现迁移卡住手动关掉非关键虚拟机。在维护窗口里强行打补丁而虚拟机还在运行这是最容易踩雷的动作。进入维护模式# 开启维护模式 esxcli system maintenanceMode set --enable true # 确认已经进入维护模式 esxcli system maintenanceMode getset 命令把主机标记为维护模式get 用来确认当前状态输出显示 Enabled 再继续。如果主机上有 vCenter 的主动任务进入维护模式可能被延迟多等几秒再查。3.2 先列出 profile再用 profile update 而不是 vib update开始安装之前先把 zip 里的 profile 都列出来确认名称与自己的预期一致。# 列出 depot 中所有 profile 名称和版本 esxcli software sources profile list -d /tmp/ESXi670-202210001.zip拿到列表之后选择 standard 即可。接下来执行更新# 用指定 profile 更新主机-d 指定 depot-p 指定 profile esxcli software profile update -d /tmp/ESXi670-202210001.zip -p ESXi-6.7.0-202210001-standard这里 -d 指向补丁包-p 指定 profile。update 不会立即切换引导索引但会把增量 VIB 安装进去并标记需要重启。为什么不推荐用 vib update因为 vib update 一次只装单个 VIB而 profile update 会处理整组依赖。手动逐个装很容易把依赖装乱最后主机反而不在一个被 VMware 验证过的组合里。如果碰到 VIB 版本回退问题profile update 也会给出清晰错误。看到 Install Success 再准备重启。3.3 按计划重启、退出维护模式并核验版本esxcli software profile update 结束时不代表万事大吉ESXi 会在下次启动时完成 bootbank 切换。很多人在成功后立刻退出维护模式等到真正重启时才发现状态不对。稳妥顺序是先重启主机再退出维护模式。# 重启 ESXi-r 记录重启原因方便审计 esxcli system shutdown reboot -r ESXi670-202210001 patch reboot重启完成后SSH 重新连上先查看维护模式状态再退出# 关闭维护模式 esxcli system maintenanceMode set --enable false退出后主机恢复正常调度虚拟机。这时再用 vmware -v 和 esxcli software profile get 查看当前版本。理想状态下build 时间应该落在 2022 年 10 月profile 名字里带 202210001。如果输出还是旧版本不要重新跑 update优先检查是否真的重启了ESXi 的软件更新是在启动时落盘的不是安装命令执行的瞬间。执行 uptime 看开机时间辅助判断。4. ESXi670 补丁升级踩坑现象、原因与解决4.1 “一个或多个 VIB 不兼容”导致 profile update 中断现象执行 update 时终端报错提示某些 VIB 与主机当前状态不兼容后面跟了一大串依赖项。原因最常见的是当前系统里存在第三方 VIB比如服务器厂商的带外管理模块或旧版驱动这些 VIB 的版本可能与补丁包里的同名组件冲突。解决先执行 esxcli software vib list 找出冲突的 VIB看它是否与补丁包里同名 VIB 重复。如果业务上不依赖它可以直接移除后重试# 移除指定 VIB冲突解决后再执行 profile update esxcli software vib remove -n vib_name如果是在生产环境确认该 VIB 属于监控或硬件管理升级后可以由新版替代再移除。移除后问题仍存在说明还有别的依赖需要看完整错误信息不要用 --force 强行推进否则可能把系统搞到半可用状态。4.2 升级后虚拟机找不到引导磁盘现象补丁升级完成主机重启后虚拟机全部起不来提示找不到磁盘或 BIOS 无法识别引导设备。原因很多服务器使用 OEM 提供的 AHCI 或 SAS 控制器驱动补丁包里的原生驱动版本会覆盖厂商定制版导致驱动在开机阶段没有正确加载。解决升级前先记录当前存储控制器驱动版本# 查看存储控制器相关 VIB留意 vmw_ahci 等模块名 esxcli software vib list | grep -i ahci如果升级后翻车需要从 LiveCD 或进入紧急模式用旧补丁 zip 重新执行 profile update 回到上一版本。关键点保留旧补丁包不要只留着 ESXi670-202210001 一个 zip。回滚方式我会在下一章讲。4.3 vCenter 报 ESXi 主机证书不受信任或 SSL 错误现象补丁升级完成后vCenter 里主机状态显示“证书错误”主机连接告警SSH 能连但 Web Client 打不开。原因ESXi 升级会重写主机的部分配置如果之前换了自签 CA 证书且没同步到 vCenter trust store升级动作可能触发证书信息变化。另外vCenter 6.7 Windows 版如果 VECS 证书与 VMDIR 状态不一致会出现类似报错这其实是管理栈被更新时的连带问题。解决先确定是哪一侧。在 ESXi 主机上可以重置证书并重新下发# 重置主机机器级 SSL 证书 esxcli system ssl certificate reset --level machine执行后主机 SSL 证书会重新生成需要在 vCenter 中重新获取证书。vCenter 侧的 VECS 不一致通常要在 vCenter 的证书管理界面修复如果是 Windows 版 vCenter检查 vmdir 服务状态必要时重启后再同步。注意不要在业务高峰期做证书重置它会导致虚拟机网络短暂中断。4.4 已经提示需要重启但重启后版本没变现象esxcli 完成更新也重启了但用 esxcli software profile get 看到 build 还是旧的始终提示需要重启。原因大概率是安装命令被会话中断了比如 SSH 窗口超时或补丁包放在一个重启后会丢失的临时目录里导致开机时没有拿到正确的 bootbank 信息。解决重新执行 profile update这次不要断开 SSH等待完整的安装日志出现后再重启。确认方法是重新查看 esxcli software profile get 输出中的 build。如果还是旧的再跑一次 update。不要在同一窗口反复按 CtrlC那样会造成更新过程中断。4.5 用错补丁包把 8.0 的集成驱动盖在 6.7 上现象下载时搜到的是 ESXi 8.0U3k 集成驱动版本文件名或页面描述里明显带 8.0但有人没看就导进 6.7 主机然后报“无法识别 depot”。原因ESXi 补丁包与系统版本的匹配是硬性的。6.7 的主机软件栈只能接受匹配 6.7 release 的 profile。解决核对 zip 文件名中的 ESXi670 前缀以及 profile list 里的版本号。如果已经导入报错不需要担心esxcli 会拒绝安装通常不造成破坏。真正的风险是使用第三方集成驱动包提权安装那种包不按正常 depot 校验有可能把系统搞坏。非必要不要用集成驱动版给生产 6.7 打补丁用官方 zip 最稳妥。5. 补丁装完不是结束验证、回滚与后续巡检5.1 三个对账命令确认补丁生效升级后不要只看 vmware -v。我把下面三条命令一起跑# 确认版本和 build vmware -v # 确认当前激活 profile esxcli software profile get # 确认关键 VIB 版本 esxcli software vib list | grep -i vmware第一条看 build第二条看 profile 名第三条看 VIB 版本。如果 profile 里出现 202210001且 VIB 版本与 release notes 一致才算装到位。顺便用 uptime 对比重启时间确认主机不是从遗留的快照启动。5.2 留着后悔药怎么回滚补丁升级后如果出现驱动或性能问题理想情况是用之前的补丁 zip 回滚。我一般会把上一版补丁 zip 留在 datastore然后执行# 用旧 profile 覆盖回滚--allow-downgrade 是关键 esxcli software profile update -d /vmfs/volumes/datastore1/旧补丁.zip -p 上一版profile名 --allow-downgrade这里的 --allow-downgrade 是允许降级的开关VMware 默认不接受 profile 版本回退不指定这个参数会直接拒绝。回滚后也要重启主机并再次验证。如果连上一版 zip 都没有就只能重新安装系统那就真翻车了。5.3 升级后的巡检清单最后例行巡检确认虚拟机的开机自启动策略没有被重置检查 vCenter 中没有新报警查看 /var/run/log 或 vmkernel 日志里有没有驱动相关的 warning。我自己的习惯是升级后至少观察两个小时把手头该保留的日志留一份。我每次打完补丁都会犯同一个毛病急着验证版本忘了看主机启动时间。后来养成了一个习惯把补丁 zip 放到固定的补丁目录版本名留在同目录的 README 里。这样下次再升级打开目录就知道当前 baseline 和上次改动少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取
ESXi 6.7补丁升级实战：esxcli离线安装与回滚避坑指南
简介ESXi670-202210001.zip 是 VMware 针对 ESXi 6.7 发布的官方安全与功能更新补丁主要面向虚拟化运维人员与 vSphere 管理员旨在修复已知安全漏洞、性能缺陷提升系统整体稳定性与合规性。压缩包共含 152 个文件整体大小约 443.53MB其中以 149 个 VIB 安装包为主涉及 esx-base、vsan、vsanhealth、cpu-microcode 等核心组件另有两个 XML 索引文件 index.xml、vendor-index.xml用于供 VMware Update Manager 识别补丁构成及供应商信息metadata.zip 则封装补丁描述、适用性与依赖关系便于自动化更新流程使用。该资源已有 1431 人学习反映出其在 ESXi 补丁管理场景中的参考价值。通过解压对照这些文件管理员可以清楚了解离线补丁的打包结构和 VIB 机制从而在真实环境中更规范地完成补丁扫描、应用与回滚保障虚拟化集群持续处于安全且稳定的运行状态。1. 这是ESXi 6.7的什么补丁先搞懂ESXi670-202210001再动手某天你的监控平台跳出一条告警ESXi 6.7 主机旧 Build 存在安全漏洞而修复下载链接指向 ESXi670-202210001.zip。这个文件是 VMware 在 2022 年 10 月针对 ESXi 6.7 发布的补丁包一次补齐该年 10 月前的安全修复与稳定性问题。它解决的是生产环境最头痛的事主机一直裸奔在旧版本上想升级又怕翻车。适合运维和虚拟化管理员尤其是没有 vCenter 统一管理、只能一台台 SSH 处理的主机。先说个反直觉的结论打这个补丁不一定要走 VUM命令行操作反而更可控也更容易留后路。2. 拆开 ESXi670-202210001 补丁包结构、命名与升级前的三查2.1 从文件后缀和内部结构判断补丁的适用范围VMware 给 ESXi 6.7 的补丁通常有两种分发格式一个完整安装 ISO和一个 zip 格式的 offline bundle。标题里的 ESXi670-202210001.zip 就是后者。它不是安装镜像而是面向运行中的 ESXi 主机的补丁包。zip 里包含若干个 VIBvSphere Installation Bundle以及描述这些 VIB 依赖关系的 metadata。用解压工具先看一遍不会坏还能确认没有混入奇怪文件。# 列出补丁包内的文件确认 depot 结构 unzip -l ESXi670-202210001.zip输出里通常有 metadata.zip、profile 目录、vibs 目录和 vendor 相关文件。这些文件被 ESXi 的软件栈统称为 depot。depot 中定义了一个或多个 profile例如 ESXi-6.7.0-202210001-standard。standard 表示标准版不带 no-tools 后缀no-tools 会在升级时跳过 VMware Tools 更新。这里有一个选型经验如果虚拟机里的 VMware Tools 都是手动更新或另有渠道那么选 no-tools 可以减少重启后的验证动作但一般我仍然推荐 standard因为它是 VMware 默认测试过的组合。选错也不会造成严重后果只是升级行为不同。这里有一个常见误用有人把 zip 当成安装包在 Windows 上双击解压然后试图用 vSphere Client 的“升级包”界面导入。导入本身没问题但真正生效必须由 profile 驱动不能直接解压到本地。ESXi 主机只认 depot zip不认解压后的目录。所以后续操作全部围绕 zip 本身展开。2.2 升级前必须确认当前 Build、受支持路径与兼容性执行 ESXi 6.7 补丁升级前我一般会先记录现状。最少三条命令# 查看版本和 build 号 vmware -v # 查看更详细信息和上次更新时间 vmware -vl # 查看当前激活的 profile esxcli software profile get第一条只能看到版本第二条会带出 build 号第三条显示当前 profile。如果当前主机已经是 6.7 的最终补丁之一再装 202210001 只是把少量延期修复补上。如果是从很早的 6.7 GA 直升就需要确认 VMware 支持路径是否允许跨多个 Update。通常 offline bundle 可以跨版本直接升但前提是主机硬件和厂商定制驱动不干涉。另一个要确认的是 vCenter 版本ESXi 升级到 202210001 后vCenter 至少要能管理该版本的 ESXi否则会出现主机连接跟随失败。还有一个人容易忽略的点是第三方 VIB。用服务器厂商定制镜像装机的环境里往往有厂商的驱动或监控组件。esxcli software profile update 会重新评估整个 profile 的依赖如果厂商 VIB 与补丁中的同名 VIB 版本冲突升级会直接报错。所以升级前把当前 VIB 列表导出一份留底# 导出当前 VIB 列表升级后用于对比 esxcli software vib list /tmp/vib_before.txt这个文件在升级后用来对比哪些组件被替换或增加。不要只在屏幕上扫一眼直接存文件后续排查会省时间。2.3 从官网下载到校验别让一个坏 zip 毁掉维护窗口补丁下载入口在 VMware 的 Patch Download Center搜 ESXi670-202210001 就能找到。下载需要 VMware 账号且账号需要有补丁下载权限。文件名很容易记但不同地区下载到的内容一样校验值才是区分完整的关键。先看官方页面给出的 SHA1 或 SHA256如果你是 Linux 终端用# 计算补丁包 SHA256与官方页面核对 sha256sum ESXi670-202210001.zip把输出和官方核对。平时我还会顺手跑一下 zip 完整性测试# 测试 zip 的 CRC 校验排除下载损坏 unzip -t ESXi670-202210001.zipunzip -t 能发现下载中途断流或传输工具破坏的情况。这里有一个细节ESXi 6.7 补丁包的签名体系是 SHA-2如果你的校验脚本还是多年前写死的 SHA-1对不上不代表文件错了先换命令再怀疑文件。到这里准备还没完。如果打算用 VUM 升级zip 可以直接导入 VUM 的更新存储库如果打算用 SSH 命令行就需要先把 zip 放到主机能访问的位置。这一步放到下一章展开。3. 用 esxcli 把 ESXi670-202210001 装上上传、维护模式与重启3.1 把补丁包传上主机并安全进入维护模式先决定传输方式。常见做法是直接 scp 到 ESXi 主机的 /tmp也可以放到某台 HTTP 服务器上由主机远程拉取。我图省事时用 scp但会先确认 /tmp 空间够不够。# 查看 /tmp 可用空间至少要是补丁包两倍大小 df -h /tmp如果空间不够建议传到一个 datastore 目录。datastore 路径中带空格时命令里要用引号包住例如# 列出 depot 中的 profile注意 datastore 路径空格用引号 esxcli software sources profile list -d /vmfs/volumes/datastore1/ESXi670-202210001.zip传输完成之后升级前把主机上的虚拟机全部迁移走或关闭。如果是加入集群且启用了 DRS可以逐个主机进入维护模式由 DRS 自动迁走。如果发现迁移卡住手动关掉非关键虚拟机。在维护窗口里强行打补丁而虚拟机还在运行这是最容易踩雷的动作。进入维护模式# 开启维护模式 esxcli system maintenanceMode set --enable true # 确认已经进入维护模式 esxcli system maintenanceMode getset 命令把主机标记为维护模式get 用来确认当前状态输出显示 Enabled 再继续。如果主机上有 vCenter 的主动任务进入维护模式可能被延迟多等几秒再查。3.2 先列出 profile再用 profile update 而不是 vib update开始安装之前先把 zip 里的 profile 都列出来确认名称与自己的预期一致。# 列出 depot 中所有 profile 名称和版本 esxcli software sources profile list -d /tmp/ESXi670-202210001.zip拿到列表之后选择 standard 即可。接下来执行更新# 用指定 profile 更新主机-d 指定 depot-p 指定 profile esxcli software profile update -d /tmp/ESXi670-202210001.zip -p ESXi-6.7.0-202210001-standard这里 -d 指向补丁包-p 指定 profile。update 不会立即切换引导索引但会把增量 VIB 安装进去并标记需要重启。为什么不推荐用 vib update因为 vib update 一次只装单个 VIB而 profile update 会处理整组依赖。手动逐个装很容易把依赖装乱最后主机反而不在一个被 VMware 验证过的组合里。如果碰到 VIB 版本回退问题profile update 也会给出清晰错误。看到 Install Success 再准备重启。3.3 按计划重启、退出维护模式并核验版本esxcli software profile update 结束时不代表万事大吉ESXi 会在下次启动时完成 bootbank 切换。很多人在成功后立刻退出维护模式等到真正重启时才发现状态不对。稳妥顺序是先重启主机再退出维护模式。# 重启 ESXi-r 记录重启原因方便审计 esxcli system shutdown reboot -r ESXi670-202210001 patch reboot重启完成后SSH 重新连上先查看维护模式状态再退出# 关闭维护模式 esxcli system maintenanceMode set --enable false退出后主机恢复正常调度虚拟机。这时再用 vmware -v 和 esxcli software profile get 查看当前版本。理想状态下build 时间应该落在 2022 年 10 月profile 名字里带 202210001。如果输出还是旧版本不要重新跑 update优先检查是否真的重启了ESXi 的软件更新是在启动时落盘的不是安装命令执行的瞬间。执行 uptime 看开机时间辅助判断。4. ESXi670 补丁升级踩坑现象、原因与解决4.1 “一个或多个 VIB 不兼容”导致 profile update 中断现象执行 update 时终端报错提示某些 VIB 与主机当前状态不兼容后面跟了一大串依赖项。原因最常见的是当前系统里存在第三方 VIB比如服务器厂商的带外管理模块或旧版驱动这些 VIB 的版本可能与补丁包里的同名组件冲突。解决先执行 esxcli software vib list 找出冲突的 VIB看它是否与补丁包里同名 VIB 重复。如果业务上不依赖它可以直接移除后重试# 移除指定 VIB冲突解决后再执行 profile update esxcli software vib remove -n vib_name如果是在生产环境确认该 VIB 属于监控或硬件管理升级后可以由新版替代再移除。移除后问题仍存在说明还有别的依赖需要看完整错误信息不要用 --force 强行推进否则可能把系统搞到半可用状态。4.2 升级后虚拟机找不到引导磁盘现象补丁升级完成主机重启后虚拟机全部起不来提示找不到磁盘或 BIOS 无法识别引导设备。原因很多服务器使用 OEM 提供的 AHCI 或 SAS 控制器驱动补丁包里的原生驱动版本会覆盖厂商定制版导致驱动在开机阶段没有正确加载。解决升级前先记录当前存储控制器驱动版本# 查看存储控制器相关 VIB留意 vmw_ahci 等模块名 esxcli software vib list | grep -i ahci如果升级后翻车需要从 LiveCD 或进入紧急模式用旧补丁 zip 重新执行 profile update 回到上一版本。关键点保留旧补丁包不要只留着 ESXi670-202210001 一个 zip。回滚方式我会在下一章讲。4.3 vCenter 报 ESXi 主机证书不受信任或 SSL 错误现象补丁升级完成后vCenter 里主机状态显示“证书错误”主机连接告警SSH 能连但 Web Client 打不开。原因ESXi 升级会重写主机的部分配置如果之前换了自签 CA 证书且没同步到 vCenter trust store升级动作可能触发证书信息变化。另外vCenter 6.7 Windows 版如果 VECS 证书与 VMDIR 状态不一致会出现类似报错这其实是管理栈被更新时的连带问题。解决先确定是哪一侧。在 ESXi 主机上可以重置证书并重新下发# 重置主机机器级 SSL 证书 esxcli system ssl certificate reset --level machine执行后主机 SSL 证书会重新生成需要在 vCenter 中重新获取证书。vCenter 侧的 VECS 不一致通常要在 vCenter 的证书管理界面修复如果是 Windows 版 vCenter检查 vmdir 服务状态必要时重启后再同步。注意不要在业务高峰期做证书重置它会导致虚拟机网络短暂中断。4.4 已经提示需要重启但重启后版本没变现象esxcli 完成更新也重启了但用 esxcli software profile get 看到 build 还是旧的始终提示需要重启。原因大概率是安装命令被会话中断了比如 SSH 窗口超时或补丁包放在一个重启后会丢失的临时目录里导致开机时没有拿到正确的 bootbank 信息。解决重新执行 profile update这次不要断开 SSH等待完整的安装日志出现后再重启。确认方法是重新查看 esxcli software profile get 输出中的 build。如果还是旧的再跑一次 update。不要在同一窗口反复按 CtrlC那样会造成更新过程中断。4.5 用错补丁包把 8.0 的集成驱动盖在 6.7 上现象下载时搜到的是 ESXi 8.0U3k 集成驱动版本文件名或页面描述里明显带 8.0但有人没看就导进 6.7 主机然后报“无法识别 depot”。原因ESXi 补丁包与系统版本的匹配是硬性的。6.7 的主机软件栈只能接受匹配 6.7 release 的 profile。解决核对 zip 文件名中的 ESXi670 前缀以及 profile list 里的版本号。如果已经导入报错不需要担心esxcli 会拒绝安装通常不造成破坏。真正的风险是使用第三方集成驱动包提权安装那种包不按正常 depot 校验有可能把系统搞坏。非必要不要用集成驱动版给生产 6.7 打补丁用官方 zip 最稳妥。5. 补丁装完不是结束验证、回滚与后续巡检5.1 三个对账命令确认补丁生效升级后不要只看 vmware -v。我把下面三条命令一起跑# 确认版本和 build vmware -v # 确认当前激活 profile esxcli software profile get # 确认关键 VIB 版本 esxcli software vib list | grep -i vmware第一条看 build第二条看 profile 名第三条看 VIB 版本。如果 profile 里出现 202210001且 VIB 版本与 release notes 一致才算装到位。顺便用 uptime 对比重启时间确认主机不是从遗留的快照启动。5.2 留着后悔药怎么回滚补丁升级后如果出现驱动或性能问题理想情况是用之前的补丁 zip 回滚。我一般会把上一版补丁 zip 留在 datastore然后执行# 用旧 profile 覆盖回滚--allow-downgrade 是关键 esxcli software profile update -d /vmfs/volumes/datastore1/旧补丁.zip -p 上一版profile名 --allow-downgrade这里的 --allow-downgrade 是允许降级的开关VMware 默认不接受 profile 版本回退不指定这个参数会直接拒绝。回滚后也要重启主机并再次验证。如果连上一版 zip 都没有就只能重新安装系统那就真翻车了。5.3 升级后的巡检清单最后例行巡检确认虚拟机的开机自启动策略没有被重置检查 vCenter 中没有新报警查看 /var/run/log 或 vmkernel 日志里有没有驱动相关的 warning。我自己的习惯是升级后至少观察两个小时把手头该保留的日志留一份。我每次打完补丁都会犯同一个毛病急着验证版本忘了看主机启动时间。后来养成了一个习惯把补丁 zip 放到固定的补丁目录版本名留在同目录的 README 里。这样下次再升级打开目录就知道当前 baseline 和上次改动少走很多弯路。希望帮到你。本文还有配套的精品资源点击获取