简介：面向虚拟化运维与管理人员，提供 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 root@<esxi-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，把主机最终校准到目标 profile；update则只升级版本号更高的 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 的路上少走几次弯路。
本文还有配套的精品资源，点击获取
