简介面向虚拟化运维与管理人员提供 ESXi 8.0 Update 2 的离线 Depot 升级包版本号为 22380479适用于无外网或网络受限环境下的补丁安装、主机升级及集群批量维护。压缩包共包含 124 个文件主体为 121 个 VIB 驱动与功能组件覆盖基础内核、虚拟化底层、vSAN 分布式存储、vSAN 健康检查、集群存储、传输通信、加密驱动等模块另有 2 个 XML 描述文件用于元数据解析以及 1 个 ZIP 内层离线仓库文件可通过 vSphere Lifecycle Manager 或 ESXCLI 命令直接离线导入与部署。资源整体约 587.17 MB已有 845 人学习下载。该离线包可帮助管理员获得官方 8.0U2 补丁基线搭建内部软件源以批量升级多台主机避免外网下载超时或合规风险也适合在隔离测试环境验证新版本特性、演练升级回退为生产环境补丁维护提供可靠保障。1. 拿到 VMware ESXi 8.0U2 离线包先搞清楚它到底是干什么的很多刚接触虚拟机管理的同行一看到VMware-ESXi-8.0U2-22380479-depot.zip这种文件就以为是 ESXi 的安装镜像直接拿它去装系统结果折腾半天装不上。这个文件确实是 ESXi 8.0 U2 的东西但它的定位是离线升级包不是安装盘。它的真实用途是让你在没有外网、没有 VMware 官方源的情况下把一台已经运行的 ESXi 主机从旧版本升级到 8.0U2 build 22380479。只要你有这个 zip再配合esxcli software命令就能在隔离网络里完成整台宿主机内核、驱动、VMware Tools 的一体化更新。适合机房在内网、无法访问官方仓库的虚拟化运维场景也适合离线批量给多台主机打补丁的团队。2. 选型之前先理解 depot 包它和 ISO 镜像、在线仓库到底差在哪2.1 depot 包的文件形态zip 里装的是 VIB 和 profile这个 zip 不是普通压缩包它的内部结构是 VMware 定制的 depot 仓库格式。解开之后里面是 metadata 文件、一堆.vib文件VMware Installation Bundle也就是驱动、内核模块、工具集的小安装包以及描述整个版本面貌的 profile 文件。用unzip -l看文件列表会看到类似这样的结构unzip -l VMware-ESXi-8.0U2-22380479-depot.zip | head -40 # 输出里会有一堆 vmw-* 开头的 .vib 文件 # 以及 metadata.xml 这样的包描述文件为什么要理解这个结构因为升级时你执行的是esxcli software profile install -d depot路径 -p profile名这里的-p参数指向的就是 depot 包里的 profile 名称而不是 zip 文件名本身。很多人第一次升级时随便写了一个 profile 名结果提示找不到就是因为没先列出 depot 里的 profile 列表。profile 相当于一个「版本快照」它定义了安装这个版本时默认选哪些 VIB、不选哪些。同一个 depot 包里可能有多个 profile比如标准版、带定制驱动的版本升级前必须确认目标 profile 的名称和你的授权模式一致。然后要注意一点depot 包是用于esxcli命令的升级场景而 ESXi ISO 镜像用于全新安装installer.sh也能用 ISO 做升级但那是走 Installer 的安装引导程序适用面比esxcli窄尤其是在已有大量配置和 VM 运行的-production 环境中操作起来很别扭。所以我一般只在裸机装机时用 ISO生产环境升级一律用 depot 包。2.2 离线升级与在线升级的取舍为什么非要用离线包在线升级走的是esxcli software profile update -d https://host/vmware-depot这种形式也就是说主机要能直接访问 VMware 官方在线仓库。但实际运维环境里真正允许 ESXi 管理网络直连公网的机房少之又少——要么是等保要求隔离要么是客户网络策略禁止主机出外网要么是跨地域的网络延迟实在无法接受。这个时候离线包就成了唯一能走通的路。离线升级还有个隐含好处版本可控。在线升级每次拉到的 profile 状态是动态的如果仓库端点调整了可能这回升级的内容和上回不一样出了问题不好复现。depot 文件一旦下载下来就固定了测试环境和生产环境用同一个文件、同一个 profile升级行为可以完全一致。所以选型结论很简单内网隔离环境、批量多主机升级、要求版本可复现就选离线 depot 包方案单台实验机器且网络可达官方源在线升级更省事但生产环境我建议还是走离线路线稳。3. 升级前必须做足的功课版本确认、兼容性检查和配置备份3.1 先确认当前版本和 profile别拿错升级路径拿到离线包之后第一件事不是上传而是确认当前主机的版本基线。这一步决定了你是原地升级、跨版本升级还是需要先升到中间版本。ESXi 8.0U2 之前还有 8.0、8.0U1理论上 7.0U3 可以直接升 8.0U2但如果你是 6.x 的老版本就必须要先升级到 7.0U3再升到 8.0U2。这个坑在实际项目里踩过不少次有一次某个机房的几台旧机器还在 6.7同事直接拷 8.0U2 的包过去升级结果esxcli报了一堆 VIB 依赖错误最后老老实实先升 7.0U3 再升 8.0。# 查看详细版本信息包含 build 号和更新级别 vmware -vl # 查看当前激活的 profile 名称这个要和升级后的目标对比 esxcli software profile get执行vmware -vl会输出类似VMware ESXi 8.0U1 build 21495797这样一行字重点看 build 号。esxcli software profile get则展示当前主机应用的 profile 名称和对应的 VIB 数量这个就是旧版本的全家桶清单。参数说明vmware -vl没有参数就是个版本打印工具esxcli software profile get的核心意义是告诉你当前这台机器处于什么「软件组合状态」升级完成后可以拿输出和升级前做对比快速确认有哪些 VIB 更新了。3.2 硬件兼容性这是升级翻车的头号原因别省这一步ESXi 8.0 的一大特点是网络驱动变化巨大。8.0 开始 vmnic 的命名规则变了很多老网卡驱动被移除部分只在 ESXi 7.0 时代还正常跑的板载网卡升级到 8.0 之后直接识别不出来导致主机重启之后管理 IP 消失、失联。所以升级前必须做两件事一是对照兼容性列表HCL核对服务器型号、网卡型号、存储控制器型号二是检查当前主机上的网卡驱动 VIB 情况。# 列出当前主机所有 VIB 中跟网卡相关的驱动 esxcli software vib list | grep -i net # 列出存储控制器驱动 esxcli software vib list | grep -i sata esxcli software vib list | grep -i nvme这里解释一下grep -i net的作用把 VIB 名称里包含 net 字样的驱动都筛查出来比如net50、net-e1000e、net-ixgbe等。如果目标主机用的是比较老的 e1000e 驱动而 8.0U2 的 depot 包里已经把它移出默认 profile你就需要额外确认自己的网卡是否还能被新版本支持或者考虑打定制驱动。别在这上面想当然很多「升级完主机失联」的血泪教训本质上就是驱动兼容性问题不是升级过程的问题。还有一个细节存储控制器。如果服务器用的是老款 SAS 控制器或非主流厂商的 RAID 卡升级前一定要核对 HCL。ESXi 7.0 还能靠兼容模式驱动跑起来的8.0 里可能直接不加载。升级完成后主机无法从本地存储引导就只能进维护模式重新分区非常痛苦。3.3 配置备份花五分钟做一次备份给自己留张后悔药升级本质上是替换系统分区里的软件组合。虽然 ESXi 的设计是升级不会动配置和 VM 文件但实际操作中因为意外断电、驱动异常导致的引导失败并不少见。所以备份配置是升级前必须走的一步而且这一步成本极低。# 将当前主机的配置备份打包到指定目录 vim-cmd hostsvc/firmware/backup_config # 或者备份到远程位置 mkdir -p /vmfs/volumes/datastore1/backup # 将生成的备份文件拷贝到共享存储防止本机磁盘损坏时丢失 cp /tmp/configBundle-*.tgz /vmfs/volumes/datastore1/backup/vim-cmd hostsvc/firmware/backup_config会把主机的网络配置、存储配置、用户权限、vSwitch 设置打包成一个 tgz 文件输出路径会直接显示在命令回显里。这个备份是回滚配置的基础万一升级后需要恢复到升级前的网络状态用vim-cmd hostsvc/firmware/restore_config就能还原。参数说明backup_config没有额外参数但它生成的文件名里带主机名和时间戳。注意备份文件默认生成在/tmp而/tmp是内存盘重启后内容会丢所以必须立刻拷贝到持久化存储里。这一点很多人不知道备份完就放那里了结果主机一重启备份也没了。4. 核心动手环节上传 depot 包、校验 profile、执行升级4.1 把 depot 包传到数据存储并验证文件完整性先把 zip 包上传到 ESXi 主机的 datastore 里。一般是传到本地 VMFS 卷也可以传到共享存储。上传方式很多我常用的是 WinSCP 或 SCP路径放在/vmfs/volumes/datastore1/下面建一个upgrade目录单独存放避免和数据文件混在一起。# 先看 datastore 名称和可用空间确认空间足够 df -h /vmfs/volumes/datastore1 # 创建一个专门存放升级包的目录 mkdir -p /vmfs/volumes/datastore1/upgrade # 用 scp 从管理机推送到 ESXi在管理机上执行 scp /local/path/VMware-ESXi-8.0U2-22380479-depot.zip rootesxi-ip:/vmfs/volumes/datastore1/upgrade/文件传完之后最好做一次 MD5 校验防止传输过程中文件损坏。有些离线包体积在 3GB 左右大文件长时间传输难免出错。校验方法是在 ESXi 端用esxcli自带的校验或者依赖 depot 包安装时的内部元数据完整性检查如果包损坏esxcli会直接报错不会动到系统。4.2 列出 depot 包内可用 profile确认升级目标这一步是升级操作前的最后一道检查。执行下面的命令depot 包里的所有 profile 名称会列出来。需要重点关注的是 profile 名称末尾是standard、s-standard还是别的定制串这决定了命令怎么写。# 列出 depot 包里的所有 profile 版本 esxcli software sources profile list -d /vmfs/volumes/datastore1/upgrade/VMware-ESXi-8.0U2-22380479-depot.zip这个命令输出比我们肉眼从文件名猜到的要多。同一个 depot 包往往会包含多个类似但不完全相同的 profile比如ESXi-8.0U2-22380479-standard和ESXi-8.0U2-22380479-no-tools。-d参数指定 depot 路径路径必须是绝对路径且要能被当前 ESXi 直接读取。确认好你要的 profile 名称之后再执行正式的升级安装。4.3 执行升级安装install 命令的完整参数解读这里有一个关键概念——esxcli software profile install和update的区别install是强制将当前主机切换到指定 profile 的状态无论旧版本是什么它会升级、降级或删除所有不一致的 VIB把主机最终校准到目标 profileupdate则只升级版本号更高的 VIB不会处理降级或删除。我们离线升级的场景下通常用install因为它能处理跨小版本的依赖变化更彻底。# 将主机升级到 ESXi 8.0U2 目标 profile并允许自动移除冲突的旧 VIB esxcli software profile install \ -d /vmfs/volumes/datastore1/upgrade/VMware-ESXi-8.0U2-22380479-depot.zip \ -p ESXi-8.0U2-22380479-standard \ --ok-to-remove参数拆解-d指向 depot 包完整绝对路径位置不能写错。-p指定目标 profile 名称必须来自上一步profile list的输出不能自己凭记忆写。--ok-to-remove允许升级过程移除不再被依赖的旧 VIB。不加这个参数时如果系统检测到有旧 VIB 会被新 profile 替换掉会直接中止。建议加上但要注意它会删除可能影响其他软件的功能如果是特殊定制驱动环境要谨慎。执行完成后系统会提示你是否需要重启。升级命令执行完毕输出类似Installation Result的消息里面会列出每个 VIB 的状态VIBs Installed、VIBs Updated、VIBs Removed。看到这些字段后主机的软件组合就已经变成 8.0U2 了但生效必须重启。# 确认没有报错后重启主机 reboot这里提醒一个细节如果这台主机是被 vCenter 纳管的重启前最好先把主机置于维护模式然后在 vCenter 里把该主机断开再重启否则 vCenter 那边会有连接告警虽然不影响最终升级但会给监控带来噪音。我自己习惯的操作是在 vCenter 里通过「进入维护模式」把主机负载迁走再通过 SSH 执行升级命令最后让 vCenter 自动处理主机的重连。4.4 升级命令失败时先从日志里找原因执行升级过程中如果输出报错信息不要慌着反复重试先去翻日志。ESXi 会把升级过程的详细日志写在/var/log/esxupdate.log和/var/log/hostd.log里。最常见的失败原因是 VIB 依赖不满足、空间不足、depot 包损坏这几类。# 查看升级日志的最后 100 行 tail -100 /var/log/esxupdate.log空间不足是离线升级里比较容易翻车的点ESXi 系统分区预留空间很小部分老版本升级 8.0U2 时需要的临时空间比较大如果系统分区可用空间不足会在初始校验阶段就报Not enough space on filesystem。遇到这种情况要先清理/bootbank和/altbootbank下不再需要的旧 VIB 文件或者用esxcli software vib remove清理冗余驱动。不过这个操作要小心别把还在用的驱动删了。5. 避坑指南离线升级 ESXi 8.0U2 最容易踩的六个坑5.1 网卡驱动兼容性导致升级后失联现象主机升级完成后重启管理 IP ping 不通主机直接黑了需要物理接显示器或者通过 iLO/IPMI 才能看到系统已经起来了但网卡状态是 down。原因ESXi 8.0 默认移除了部分老旧网卡驱动的支持尤其是部分旧版板载 Realtek、Intel I219 系列网卡原本在 7.0 下用的驱动在 8.0U2 的默认 profile 里直接不存在了。解决升级前往/etc/vmware/esx.conf和esxcli software vib list里确认网卡驱动名提前去厂商官网下载对应 ESXi 8.0 驱动 VIB打进 depot 包生成新 profile或者在升级命令中额外指定-d多个 depot 源让它一起安装。有人说「升级后加驱动不就行了」但那是马后炮主机都失联了你还怎么加驱动所以驱动检查必须前置。5.2 vCenter 纳管的主机升级后在 vCenter 里显示连接不上现象升级完成并重启后主机本身正常、虚拟机也正常跑但 vCenter 里这台主机显示「未响应」或「已断开连接」。原因升级期间主机和 vCenter 之间的 agent 通信中断并且软件组合变化后 vCenter 需要重新识别。正常流程应该先在 vCenter 里把主机置于维护模式再升级重启后 vCenter 会自动重连如果跳过了这些步骤重连偶尔会失败。解决在 vCenter 里对这台主机执行「断开连接」再「重新连接」一般就能恢复。如果还是不行重启 hostd 服务/etc/init.d/hostd restart和/etc/init.d/vpxa restart注意 vpxa 是从 vCenter 安装后才有的服务检查别遗漏。5.3 profile 名写错导致命令直接报错现象执行esxcli software profile install后报Profile not found或No such profile。原因-p参数要求的是 depot 包 metadata 里的 profile 名称不是 zip 文件名。很多文档里写的一定要确认但总有人图省事自己猜一个。解决严格执行「先 list 再 install」两步走把esxcli software sources profile list的输出复制粘贴进-p参数不要手打。这条看起来很简单但确实是高频翻车点。5.4 VIB 依赖报错提示需要其他驱动才能继续现象升级执行到一半报某个 VIB 需要依赖另一个不存在的 VIB 从而中止。原因环境里有第三方定制驱动、旧版驱动和新版 depot 包的 VIB 形成依赖循环或缺口。离线包只是官方标准 VIB 集如果宿主机有额外安装的 OEM 驱动这个矛盾就会暴露。解决先执行esxcli software vib list把所有非官方 VIB 名称找出来确认升级过程中是否会被移除。需要保留的驱动必须找到对应 8.0 版本重新封装进 depot再执行升级。这个过程比较繁琐建议在测试机先做一遍。5.5 升级后提示无法引导或引导卡死现象重启后状态停留在引导加载器界面或者反复重启。原因ESXi 双引导分区的机制导致升级时/bootbank写入了新内核但/altbootbank里还是旧内核校验不一致时引导器无法找到可用的内核。这个原因相对少见多发生在磁盘异常或升级中途断电。解决在引导菜单选择「旧版本」先进入系统然后重新执行一次升级命令让它重写两个引导分区。如果两个分区都进不去就得用 ESXi 安装 ISO 启动进入救援模式从备份恢复。这正是升级前备份配置的价值所在。5.6 磁盘空间满导致升级中途中断现象升级初始阶段报Not enough space或者是升级到一半提示写入失败。原因ESXi 系统分区容量很小旧版系统上可能堆积了多轮补丁留下的临时文件。离线包体积大解压和写入需要临时空间翻倍。解决升级前用df -h /bootbank和df -h /altbootbank查看余量。如果空间不足在/bootbank里清理以vmtb-或vmw-开头的临时 VIB 文件。保守做法是先把当前正常运行的配置做好备份删除/var/log里超过一个月的日志再重试升级。这里尤其注意不要手动删除/bootbank里的.vib文件只清除临时文件。6. 升级完成后的验证清单与回滚技巧主机重启之后先别急着跑业务验证按顺序走一遍下面的检查。先是版本确认登录 ESXi 后执行# 确认版本号和 build 号已经更新到目标版本 vmware -vl # 确认当前激活的 profile 是 ESXi-8.0U2-22380479-standard esxcli software profile get如果版本和 build 号和 depot 包对应上了说明系统层面升级成功。接下来要验证的是网络和虚拟机状态。esxcli network ip interface list确认管理 IP 正常esxcli vm process list确认所有虚拟机都在运行列表中。有些时候升级后 host 正常但虚拟机没自动拉起来这通常是因为主机在维护模式下重启。驱动验证别只看vmware -vl要确认具体的关键驱动版本确实变了# 查看所有网卡驱动当前版本和升级前的输出做对比 esxcli network nic list # 查看存储适配器是否正常识别 esxcli storage core adapter list最后一步是功能冒烟测试登录虚拟机内部看网络和存储正常在 vCenter 里确认主机连接正常、属性和告警全部清除。到这里整个升级流程才算真正走完。回滚这件事很多人以为能像软件升级那样「一键还原」但 ESXi 的情况特殊。如果你升级后发现问题第一时间执行# 将主机恢复到升级前的 profile前提是你还留着旧版本 depot 包 esxcli software profile install \ -d /vmfs/volumes/datastore1/upgrade/VMware-ESXi-8.0U2-22380479-depot.zip \ -p 旧profile名 \ --ok-to-remove注意这套回滚方法只适用软件组合层面的异常比如某个驱动在 8.0U2 有 bug、某些 VM 出现兼容性问题之类。如果升级中引导分区已经损坏回滚就只能靠配置备份和 ISO 安装盘。所以升级前那一份configBundle备份就是整个操作真正的兜底保障。给新手的建议是第一次做 ESXi 8.0U2 离线升级时先在测试机上完整走一遍上面这套流程记录升级过程各阶段命令的输出特别是 VIB 变化量和报错信息。再把正式升级时的差异点写下来晾在一边对照着执行。从那以后我每次做升级都强制走一遍「备份配置 → 检查驱动 → list profile → install → 验证版本通知」哪怕操作过 N 次也同步做这台机器升级前和升级后的所有状态都留有记录出了问题能在五分钟内判定要不要回滚。希望这些踩坑记录能帮你在离线升级 ESXi 的路上少走几次弯路。本文还有配套的精品资源点击获取