企业官网建设流程全解析

简介：VMware 官方发布的 ESXi 6.7 月度补丁包 ESXi670-202210001.zip，面向虚拟化管理员、运维工程师及企业 IT 基础架构团队，用于修复近期披露的安全漏洞、解决性能问题并增强系统整体稳定性。压缩包共 152 个文件，总大小约 443.53MB；其中 149 个 VIB 组件文件覆盖系统基础包、VSAN、CPU 微码、esx-ui 等核心模块，另有 index.xml、vendor-index.xml 索引文件与 metadata.zip 元数据包，可配合 VMware Update Manager 或 esxcli 命令行完成离线扫描、依赖校验与批量升级。已有 1409 人学习下载。通过该补丁，管理员可快速补齐官方最新安全修复，同时深入理解 ESXi 补丁包的标准目录结构和 VIB 机制，为后续独立排查更新问题打下基础。建议先在测试环境验证兼容性，再对生产集群分批滚动升级，并提前做好配置备份与快照。资源适合有一定 vSphere 基础、需要保持虚拟化平台安全合规的运维人员。

1. 从补丁包名字说起：ESXi670-202210001.zip 到底在更新什么

VMware ESXi 6.7 是一款在很多生产环境里服役多年的虚拟化宿主机系统，虽然 6.7 的 General Support 已经结束，但很多机房和老旧服务器上它依然是主力。就拿我手头这批机器来说，六台 Dell R740 至今还跑着 ESXi 6.7 U3，不是因为不想升级，而是业务系统对旧版虚机兼容性要求太高，升级牵一发动全身。这种情况下，持续打补丁就成了保障安全和高可用的唯一现实选择。

那 ESXi670-202210001.zip 具体是干什么的？简单说，这是 VMware 在 2022 年 10 月发布的 ESXi 6.7 累积补丁包，也就是我们常说的 Offline Bundle（离线捆绑包）。它一次性打包了该时间点之前所有的安全修复、驱动更新、Bug 修复和部分硬件兼容性改进。换言之，如果你的 ESXi 6.7 还是老旧的 2020 年甚至 2019 年版本，直接打上这个补丁，就能把系统推进到 2022 年 10 月的安全水平，无需一个一个补丁去叠加。

我特别说明一点：这类补丁包的名字并非随意命名，而是有严格规则的。ESXi670 代表版本主线是 6.7.0，202210 代表 2022 年 10 月，001 是当月发布序号。看懂了这个规则，你就能判断一个补丁包的新旧和适用版本。比如碰到 ESXi670-202204001，就知道是 2022 年 4 月的补丁。官网下载时还会看到 ESXi670-202210001.zip 旁边标注了 Build Number（构建号），一般是 20910077 左右，这个构建号是判断系统是否已包含该补丁的关键依据。

这篇文章适合谁？如果你是正在用 ESXi 6.7 做生产虚拟化的运维、或者手头有跑着 6.7 的测试环境，想把系统安全补丁打全，可以把这篇文章当作一份可以直接照着操作的实战笔记。我会把补丁安装的完整流程、原理、坑点和排查方法都过一遍，保证你从下载到验证能一次走通。

2. 打补丁前必做的三件事：版本确认、备份和驱动盘点

2.1 确认当前系统的 Build 版本

很多人在打补丁前连自己的系统版本都没确认就开干，这是最容易翻车的操作。ESXi 补丁不是通用的，它基于指定的 Build 基线。你需要先登录 vSphere Client，进入主机管理界面，在"摘要"页面找到"Hypervisor"信息，里面会明确写着版本号和构建号；也可以直接通过 SSH 连上 ESXi 主机后执行下面这条命令：

vmware -v

输出类似这样：

VMware ESXi 6.7.0 build-17700523

这里 17700523 就是当前的构建号。如果构建号高于 20910077，说明你的系统已经包含该补丁甚至更新的内容，不需要重复安装。如果构建号远低于这个值，比如只有 14320384（6.7 U1），那打补丁前就要特别注意：中间跨了多个版本，补丁包会一次性把系统推送到 20910077，这个过程虽然设计为可逆的，但期间出现问题的概率会略高，务必做好备份。

我的建议是，无论在哪个构建号基础上执行，都先走一遍"备份——下载——检查——安装"的完整流程，不要因为嫌麻烦就跳过备份，补丁安装中断导致的宿主机无法启动，这种事故我见过不止一次。

2.2 备份配置和虚拟机清单

ESXi 补丁安装最大的风险点在于：安装完成后宿主机的管理网络可能发生不可预期的变化，或者某些第三方 VIB（vSphere Installation Bundle，即 VMware 的扩展安装包）与新补丁不兼容导致系统服务无法正常启动。因此备份是必须的。

备份分两个层面：第一层是配置级别备份，最可靠的方式是通过 vSphere CLI 工具备份主机配置。在任意一台装有 PowerCLI 或 vSphere CLI 的 Windows/Linux 机器上执行：

Get-VMHost -Name "你的ESXi主机IP" | Export-VMHostProfile -Destination C:\backup\config.txt

第二层是虚拟机层面的保险，最关键的操作是确保所有正在运行的虚拟机都有独立的备份或者快照。补丁安装过程中，ESXi 主机需要进入维护模式，这会导致所有虚拟机在线迁移到其他主机上（如果有 vCenter 和 DRS）或者关机。如果是单机环境，虚拟机只能先关机再打补丁，这个过程一旦主机出现问题，虚拟机数据受影响的可能性是存在的。所以，重要虚拟机的备份或快照，一定不要省。

2.3 盘点第三方驱动和 VIB 的兼容性

ESXi 系统的一大特色就是允许通过 VIB 来扩展硬件驱动、加入自定义组件。很多服务器上的网卡驱动、阵列卡驱动，都是装好系统后手动打进去的。而 ESXi 累积补丁包在升级时，会同时重新评估这些第三方 VIB 的兼容性。

在打补丁之前，建议先登录到 ESXi 主机的 SSH，执行以下命令查看当前所有 VIB：

esxcli software vib list

重点关注不带 "VMware" 标志的项目，比如 emulex、bnx2x、i40en、igb 这类第三方网卡驱动。务必到官网确认这些驱动版本是否兼容 esxi 6.7 build 20910077。我曾经遇到过一次 i40en 网卡驱动过旧，打补丁后直接导致 10G 网卡消失的情况，最后只能通过引导宿主机进入旧版本（Boot Bank Rollback）才恢复。所以，这一步是在打补丁前花时间最值得的地方。

3. 补丁安装全流程实操：从上传到验证一次跑通

3.1 补丁包上传到 ESXi 主机或数据存储

拿到 ESXi670-202210001.zip 之后，需要把它上传到 ESXi 主机的可访问位置。我常用的做法是上传到数据存储（datastore）根目录下的临时文件夹，比如/vmfs/volumes/datastore1/。最简单的上传方式是通过 vSphere Client 的"存储"页面，选择目标数据存储，点击"上载文件"，把 zip 包拖上去即可。也可以使用 scp 直接传到主机磁盘目录，比如：

scp ESXi670-202210001.zip root@你的ESXi主机IP:/vmfs/volumes/datastore1/

这里我推荐你使用 datastore 路径来保存补丁包，因为这样补丁包不占用宿主机的内存盘空间（ESXi 根文件系统空间很小，经常只有几个 GB），也不容易因为空间不足导致后续操作失败。

3.2 检查补丁包签名和完整性

这一步很多人会忽略，但恰恰是排查一切诡异问题的起点。补丁包在下载过程中可能因网络原因损坏，或者被安全软件拦截导致文件不完整。压缩包损坏时，esxcli 在安装阶段会报出各种莫名其妙的错误。因此，在上传完成后，建议先执行一次 MD5 校验。

在 ESXi 的 SSH 终端中，进入文件所在目录，执行：

md5sum ESXi670-202210001.zip

把输出的 MD5 值与官网页面上提供的校验值进行比对。如果一致，说明文件完好，再进行后续操作。千万别嫌这一步多余，损坏的离线包在安装时经常报"Metadata file not found"或"Invalid bundle"的错误，白白浪费时间排查。

3.3 专业前置检查：dry-run 模式

ESXi 补丁安装命令支持 dry-run，也就是预演模式，可以提前检查系统依赖是否满足、是否存在 VIB 冲突等情况，而不做任何实际修改。我强烈建议第一次接触 esxcli 补丁命令的朋友一定要执行这一步。

命令格式如下：

esxcli software profile update --depot=/vmfs/volumes/datastore1/ESXi670-202210001.zip --profile=ESXi-6.7.0-202210001-standard --dry-run

执行后，系统会输出一份完整的检查报告，包括将要安装、升级、降级或移除的 VIB 列表，以及是否存在依赖冲突。如果报告显示"Conformance Check: PASSED"，那么就可以放心安装。

顺便说明一下--profile参数的作用。每个补丁包 zip 中，其实包含多个 profile 文件，最常见的是ESXi-6.7.0-202210001-standard和ESXi-6.7.0-202210001-no-tools。前者是标准版配置，会附带 VMware Tools 更新；后者则不会把 VMware Tools 的更新打包进去，通常用于需要严格控制客户机内工具版本的环境。一般生产环境使用 standard 版本即可。如果你不确定自己该选哪一个，可以先用 unzip 查看补丁包内容：

unzip -l ESXi670-202210001.zip | grep metadata

打开 metadata 文件查看 profile 名称，再决定用哪一个。不过大多数情况下，直接用 standard 就是对的。

3.4 进入维护模式并执行补丁安装

确认 dry-run 没有报错后，接下来就是正式安装了。安装前需要先让 ESXi 主机进入维护模式。在 vSphere Client 中，选中主机，右键选择"维护模式"->"进入维护模式"。如果是通过命令行，可以先查看当前是否有虚拟机在运行：

esxcli vm process list

确认无 VM 运行后，执行：

vim-cmd hostsvc/maintenance_mode_enter

然后检查主机是否确实进入维护模式：

vim-cmd hostsvc/hostsummary | grep maintenanceMode

返回类似true就对了。接下来，正式执行补丁安装命令：

esxcli software profile update --depot=/vmfs/volumes/datastore1/ESXi670-202210001.zip --profile=ESXi-6.7.0-202210001-standard

这个过程会输出每个 VIB 的安装进度。快的时候几分钟，慢的时候十几分钟，取决于你当前的构建号离目标版本多远，以及磁盘 I/O 速度。安装完成后，命令行会提示你重启系统。此时先别急着重启，可以再跑一遍：

esxcli software profile get

确认当前活动的 profile 名称和 build 是否已经变为 20910077。由于 ESXi 是有双 boot bank 机制的，刚更新完 active 的 profile 可能还没切换过来，需要重启后才会真正生效。所以，确认 profile 信息无误后，执行：

reboot

3.5 重启后的验证流程

重启完成后，再次通过 SSH 登录系统，第一件事就是执行：

vmware -v

确认构建号已经变为 20910077。然后查看开机模块和驱动加载是否正常：

esxcli hardware status get

重点关注主机传感器信息、网络模块和存储模块的状态，确保没有异常故障。虚拟化环境里最常见的隐性 bug 就是补丁升级成功，但某些第三方驱动没有正确加载。你可以用以下命令查看最近一次引导的日志，查找与"error"、"warning"相关的异常信息：

less /var/log/vmkernel.log

如果系统正常，再通过 vSphere Client 将主机退出维护模式：

vim-cmd hostsvc/maintenance_mode_exit

之后启动各虚拟机，逐一确认业务恢复正常。整个流程走完，补丁工作才算真正画上句号。

4. 常见安装失败问题与排查技巧实录

4.1 空间不足导致的安装失败

ESXi 的系统盘空间非常有限，很多机器的系统盘只有几十 GB 甚至 8GB 的老配置。补丁包在解压和安装过程中需要额外的临时空间，一旦磁盘不足，esxcli 会在写入 VIB 时报出insufficient space错误。

排查方法：执行df -h查看/bootbank和根分区的使用情况。如果空间紧张，理论上可以清理/scratch/log下的大日志文件，但如果平时日志已经很大，说明主机运行时间很久。我更推荐另一种方案：将补丁包放到共享存储或 datastore 上，只让系统盘负责解压临时文件，可以减少部分空间压力；实在不行，就清理掉一些不再使用的旧 ISO、临时文件再重试。如果依然装不上，直接考虑扩容系统盘或者重新安装系统。

4.2 VIB 冲突或依赖不满足

补丁安装时，最烦的就是遇到VIB ... requires ... which conflicts with ...这种错误。这通常是因为你之前装了某个第三方 VIB，其版本与补丁包中同组件的版本不一致导致的。这类问题的解决办法有一个通用套路：

先查看冲突的 VIB 是谁，执行：

esxcli software vib list | grep 冲突的组件名

如果确定这个 VIB 已经不再需要，可以主动移除。比如旧版的第三方 USB 网卡驱动导致冲突，可以先执行：

esxcli software vib remove --vibname=xxx

然后重新执行补丁安装。如果这个 VIB 在业务中必须保留，那就得去这个驱动的厂商官网找适配新 build 的驱动版本，先单独升级驱动，再打补丁。

需要特别提醒的是，esxcli software vib remove操作有一定风险，移除的过程中会卸载内核驱动模块，如果移除的是存储或网卡驱动，正在进行的 I/O 可能中断。所以，建议在维护模式下、所有虚拟机迁移或关机后再执行。

4.3 网络服务异常，SSH 连不上或管理网不通

打补丁重启后，偶尔会遇到管理 IP 无法 ping 通、SSH 登录不了主机的情况，但虚拟机业务却正常。这时候不用慌，大概率是管理网络服务（hostd 或 vpxa）没起来，或者 VLAN 配置在重启后没有生效。

在重启完成但 SSH 不可用的极端情况下，只能通过 vSphere Client 的"主机控制台"或者服务器厂商的带外管理（iDRAC/iLO）来访问。进入 ESXi 的本地控制台，按 F2 进入系统自定义界面，检查管理网络配置。如果显示网络服务已停止，可以按提示重启管理网络组件。等网络恢复之后，再进入 SSH 检查 vmkernel 日志：

tail -100 /var/log/hostd.log

常见的原因是之前手工改过网络配置文件，补丁升级后配置校验没通过，hostd 启动失败。这时只能回退配置文件或者重新配置标准网络。这里也侧面说明：补丁前一定确认主机的网络配置是标准做法，不要用各种"野路子"工具改管理网络，否则补丁后等待你的就是深夜加班。

4.4 补丁安装成功后虚拟机出现"模块 DevicePowerOn 打不开"

这个问题在 ESXi 6.7 中并不少见，经常在补丁升级或重启之后出现：原本能正常启动的 Windows 虚拟机，突然报错提示"模块 DevicePowerOn 打不开"。

出现这个问题的常见诱因是：补丁更新后，PCI 直通设备的配置或者虚拟机的固件类型与当前 host 驱动不兼容。比如不少用户会在热词里提到的 Intel I350 网卡直通问题，就是典型的驱动不兼容造成的。排查时，先去查看虚拟机的.vmx配置文件，看看有没有直通设备的配置项：

grep -i "passthru" /vmfs/volumes/datastore1/虚拟机目录/虚拟机.vmx

发现直通配置后，可以尝试先把直通设备从虚拟机中移除，或者将虚拟机固件从 BIOS 切换为 EFI（需确认客户机操作系统支持）。这两种方法都无效的话，再考虑从补丁中回退版本。这个坑我在生产环境踩过数次，经验就是：打含有驱动更新的补丁前，一定先去补丁发布说明中查看该补丁是否包含你所用网卡驱动模块的更新，如果有，主动准备对应版本驱动做备用。

4.5 常见错误速查表

5. 两条个人经验总结

我在实际打补丁的操作中养成的一个习惯是：保留每次补丁安装前的esxcli software profile get输出和补丁包校验值，记录在运维档案里。别看这点小信息，出了问题回退时非常省事。ESXi 补丁回退并不难，重启时在引导界面选择上一个 boot bank 就能回到升级前状态，前提是你得清楚自己是从哪个版本来升级的。

另外一个小技巧是，如果主机上有多个 ESXi 6.7 需要打补丁，可以先挑一台非核心机器跑通流程，确认无问题后，再批量推进。批量操作时，可以提前把补丁文件放到共享存储中，每台主机上只执行 profile update 和 reboot 即可，省去反复上传文件的时间，也避免每次都用 SSH 拷贝造成不必要的网卡流量。

ESXi 6.7 虽然已经过了主要支持期，但它的存量用户依然庞大。只要注意做好备份、确认 VIB 兼容性、认真跑一遍 dry-run，补丁升级完全可以安全流畅地完成。希望这份实操笔记能帮你少走弯路，也欢迎在评论区聊聊你遇到的补丁相关奇葩问题。

本文还有配套的精品资源，点击获取