简介VMware ESXi 7.0 Update 3v depot离线补丁包专为虚拟化运维人员与基础设施管理员准备可在无互联网环境下对ESXi主机进行离线升级、漏洞修复与驱动补充。包内共99个文件整体约584.13MB主体为96个vib组件包覆盖esx-base、vsan、crx等核心模块以及ixgben、lpfc、pvscsi、nvme-pcie等主流网卡与存储控制器驱动另有2个xml元数据文件和1个zip文件用于辅助补丁依赖解析与离线仓库组织。当前已有663人学习下载。该depot包可配合vSphere Lifecycle Manager或esxcli软件命令完成批量升级也可用于构建自定义ESXi安装镜像在批量主机运维、特定硬件兼容性适配和内网隔离环境中尤其实用可显著缩短升级维护窗口降低在线操作风险。 说实话我第一次拿到这种命名格式的文件时也愣了一会儿VMware-ESXi-7.0U3v-24723872-depot。它既不是ISO镜像也没有双击就能跑的安装向导就是一个zip压缩包。后来才搞明白这个就是ESXi的depot离线包也叫Offline Bundle是VMware专门用来给已有ESXi主机做版本升级和补丁更新的东西。这篇文章我就围绕这个文件名展开把depot包是什么、版本怎么核对、怎么用它升级ESXi、升级中那些容易翻车的点一次说清楚。不管你是拿Workstation跑ESXi虚拟机练手还是管理机房里的物理服务器这套思路都能直接套用。1. depot包不是ISO先搞清楚这个文件到底解决什么问题1.1 把zip解压出来里面到底装了什么ESXi 7.0的depot包看起来是个zip但内部结构其实很有章法。解压之后你看到的应该是这样一组内容VMware-ESXi-7.0U3v-24723872-depot/ ├── metadata.zip ├── ... └── vib20/ ├── ... └── ...metadata.zip里面装的是所有VIB的描述信息和依赖关系相当于整个升级包的目录和说明书。vib20目录下则是各个VIB文件本体。VIB的全称是vSphere Installation Bundle你可以把它理解成ESXi环境里的驱动和组件包——有的VIB负责网络驱动有的负责存储驱动有的负责核心系统组件。depot包的作用就是把这一堆VIB按依赖关系打包好再由esxcli工具统一安装到系统里。这个机制跟Windows的MSU补丁包思路有点类似但ESXi的VIB管理更严格每个VIB都有签名、依赖关系、版本号安装时会做完整性校验。所以你从非官方渠道下载的包只要里面某个VIB的签名不对esxcli会直接拒绝安装这个设计很实用。1.2 拆解文件名每个字段都有含义VMware-ESXi-7.0U3v-24723872-depot这个命名拆开看其实很直白VMware厂商标识。ESXi产品类型说明这是虚拟化Hypervisor。7.0U3v版本和更新级别。7.0是大版本U3是Update 3后面的小写v代表Update 3生命周期里第22个修订版本。24723872build号即构建号。每个官方发布的ESXi版本都有唯一build号。depot包类型说明是离线补丁仓库包。理解了命名规则你就能大概判断手里这个包是干嘛的。但这里有一个很多新手容易忽略的点文件名里的build号不一定可信。ESXi 7.0 U3v这个版本对应的官方build号是22088125如果文件名写的是24723872那就要警惕了——可能是第三方重新打包过也可能纯粹是文件名被改过。怎么验证我下面单独讲。1.3 depot包最常见的三个使用场景depot包跟ISO的分工完全不同。ISO镜像主要用来全新安装或重装系统depot包则专门服务原地升级场景典型用途有三个给已有ESXi主机打补丁、升级小版本用esxcli software profile install一条命令完成。导入vCenter的Lifecycle Manager创建基线批量升级集群里的所有主机。配合Image Builder组件用depot包里的VIB生成带定制驱动的自定义ISO。另外还有一个很实在的场景当你遇到在线更新失败、无法在更新服务器上找到组件这类问题时depot包就是最靠谱的离线方案。网络环境再差只要能把zip传上去升级就不受影响。2. Build号才是版本真相从文件名到实际版本核对2.1 7.0 U3v到底站在哪个时间点先说清楚7.0U3v这个版本的位置。ESXi 7.0 Update 3是在2021年10月发布的此后VMware一直在给这个Update 3做增量修订从U3a、U3b一直推到U3v。每推一个字母都会修复一批安全问题或功能缺陷。U3v作为7.0时代比较靠后的维护版本稳定性和安全性都已经打磨得相当好了。这也是为什么很多还在7.0线上的机器最终都会选择停在U3v或更靠后的修订上。我整理了一份从U3到U3v的build号对照方便你核对版本build号7.0 U3186442317.0 U3a191957007.0 U3c194825377.0 U3e200365897.0 U3g203283537.0 U3i205885287.0 U3k209335977.0 U3m211173607.0 U3o213142717.0 U3q215500077.0 U3s217804277.0 U3u219305087.0 U3v22088125所以如果你拿到的文件名叫VMware-ESXi-7.0U3v-24723872-depot但查下来U3v的官方build号是22088125那就要留个心眼了。我之前就踩过类似的坑从某个下载站拿到的包文件名写着U3g结果一查build对应的是U3e等于白白装了个旧版本。2.2 三种核对真实版本的方法检查一个depot包的真实版本我常用的方法有三种方法一如果包已经传到ESXi主机上直接执行profile list命令esxcli software sources profile list -d /vmfs/volumes/datastore1/VMware-ESXi-7.0U3v-24723872-depot.zip输出里会出现类似ESXi-7.0U3v-22088125-standard的profile名称Version字段会明确显示build号。这一步能直接区分文件名和包内真实版本。方法二如果ESXi已经在运行直接在主机上查看当前版本vmware -v输出类似VMware ESXi 7.0.0 build-22088125简单直接。方法三在ESXi shell里用profile get命令查看正在运行的profile详情esxcli software profile get2.3 文件名和包内版本对不上怎么办如果你的文件名叫U3v但profile list查出来build对应的是另一个版本我的建议很明确先别用回到官方渠道重新下载。VMware官方下载页面对每个版本都有明确的build号标注下载时对照一下就能发现问题。如果实在只能用手里这份那就以包内实际的profile版本为准不要信文件名。升级前先确认当前主机版本和depot包内profile版本之间跨度是否合理。ESXi的小版本升级也可以用profile install完成但如果两个版本之间隔了太多修订建议先看release notes里有没有已知的跳跃限制。另外官方出的depot包在metadata里会带VMware的签名信息。执行profile list不报错、VIB签名能通过校验基本可以确认这个包是完整且未被篡改的。跑完列表没报错再动手去装这是最稳妥的节奏。3. 离线升级实操用depot包给ESXi原地打补丁3.1 升级前必须做好的检查和准备拿到一个确认可用的depot包之后先别急着传文件我建议按这个顺序做一遍检查确认当前版本。执行vmware -v记录当前build号。确认硬件兼容性。去VMware Compatibility Guide查一下你的服务器型号和关键硬件网卡、存储卡是否在目标版本的支持列表里。物理机上尤其要注意别升完发现阵列卡驱动没了。做配置备份。执行下面命令生成主机配置备份vim-cmd hostsvc/firmware/backup_config生成的备份文件在/home/目录下下载保存好。这一步花不了一分钟但真出问题的时候能救命。检查空间。执行df -h确认bootbank分区有足够空间。depot zip传到datastore上一般要占几个GB升级过程中VIB安装还需要临时空间。如果这台主机还在vCenter集群里建议把主机置于维护模式后通过vCenter的Lifecycle Manager导入depot做升级而不是直接在ESXi shell里操作。不是说不可以而是集群环境下有HA、DRS这些逻辑直接在主机上操作容易触发vCenter层面的告警或意外迁移。3.2 上传depot包到数据存储用WinSCP或其他SCP工具把zip文件传到datastore的某个目录路径不要带中文和空格。我习惯放在/vmfs/volumes/datastore1/software/VMware-ESXi-7.0U3v-24723872-depot.zip上传完成后确认文件大小和源文件一致别传一半断了还硬着头皮继续。3.3 让主机进入维护模式在ESXi shell执行esxcli system maintenanceMode set --enable true如果上面有运行中的虚拟机先在vCenter里迁移到其他主机或者正常关机。在Workstation里跑ESXi虚拟机练手的话同样要把虚拟机内的业务机关掉再执行这条命令。确认维护模式生效可以执行esxcli system maintenanceMode get输出Enabled就对了。3.4 用esxcli命令完成安装先说清楚profile install和vib update的区别这两个命令很多人会混淆profile install按整个profile来升级会统一协调VIB之间的依赖关系适合大版本或跨维护版本的升级。vib update只更新指定的VIB适合只想修某个具体补丁的微操作。升级场景推荐用profile install。先做一次预演不加--ok-to-removeesxcli software profile install -d /vmfs/volumes/datastore1/software/VMware-ESXi-7.0U3v-24723872-depot.zip -p ESXi-7.0U3v-22088125-standard --dry-run--dry-run参数会模拟整个安装过程把所有可能的错误提前暴露出来。输出提示没问题之后再执行正式安装esxcli software profile install -d /vmfs/volumes/datastore1/software/VMware-ESXi-7.0U3v-24723872-depot.zip -p ESXi-7.0U3v-22088125-standard --ok-to-remove这里解释两个关键参数-p指定要安装的profile名称。标准版一般是xxx-standard如果你需要装别的profile先用profile list看有哪些可选。--ok-to-remove允许移除与新版本存在冲突的旧VIB。不加这个参数安装时遇到VIB冲突会直接终止。加了这个参数后esxcli会把不兼容的旧VIB标记为移除。安装过程中会打印一条条VIB的安装日志看到Installation Result里有Reboot Required: true就说明装上了。3.5 重启并验证版本安装完成后退出维护模式esxcli system maintenanceMode set --enable false reboot重启时间取决于硬件一般五到十分钟。重新连上之后执行vmware -vVMware ESXi 7.0.0 build-22088125build号变成目标版本就是成功了。4. 我升级时翻过的车四个最容易出问题的环节4.1 bootbank空间不足导致安装失败ESXi的bootbank分区很抠门通常就几百MB到几个GB。VIB装多了或者之前升级残留的旧VIB没清理干净就会出现空间不足报错信息往往很隐晦。我的血泪教训是升级前先执行esxcli software vib list看看已安装VIB的数量再用df -h看一下bootbank使用率。如果已经80%以上先清理没用的VIB再动升级的念头。另外datastore上也要留足够空间zip解压过程中的临时文件会占不少地方。4.2 证书状态异常Web界面登不上这是升级后最让人头疼的问题之一。升级过程中主机的证书会重新生成导致SSH、Web界面提示证书不匹配甚至在浏览器里直接显示无法访问此页面或证书状态未知。遇到这种情况不要慌独立主机清掉浏览器缓存重新用https://ESXi-IP/ui访问确认IP和主机名匹配。vCenter管理的主机在vCenter里刷新主机证书或者重新设置信任关系。如果之前导入过自定义证书升级后需要重新导入一次因为系统内的证书库已经变了。我之前遇到过升级完Web界面彻底打不开的情况最后是通过SSH进去重启了hostd服务才恢复。先重启hostd再清浏览器缓存按这个顺序排查能省不少时间。4.3 VIB冲突和硬件兼容问题最典型的情况是第三方厂商的VIB比如服务器厂商自带的定制驱动和标准profile里的VIB冲突。执行profile install的时候esxcli可能会因为冲突直接中止。这时要判断这台机器是不是跑着厂商定制的VIB如果是建议去下载对应的厂商定制ISO或对应的VIB包别硬套标准profile。还有一种情况是升级后网卡不认了、存储控制器不见了这通常是硬件不在目标版本的驱动支持列表里。所以我在前面反复强调HCL检查物理服务器上这一关真的不能省。在Workstation里跑虚拟机反而没这些问题因为虚拟硬件都是VMware自己的驱动兜底。4.4 升级失败后没有现成的回滚菜单ESXi不像Windows有个回滚按钮。一旦profile install写了一半失败系统可能处于半新半旧的状态。所以升级前一定做配置备份这台机器如果有余量最保险的做法是升级前把旧版本ISO准备好万一真到无法挽回的程度直接重装再恢复配置。另外--dry-run预演真的别跳过。我第一次升级时偷懒没跑--dry-run结果安装到一半卡在VIB依赖上现场折腾了一个多小时。预演虽然不能覆盖所有运行时错误但能避免90%的弱智问题。5. 升级完成之后我必做的三件事5.1 重启后第一时间验证硬件和网络主机重启回来第一件事不是急着跑业务而是确认硬件都被正确识别esxcli network nic list检查网卡是否全部识别、链路状态是否正常。然后看存储esxcli storage core device list确保阵列卡、硬盘、SSD都还在。最后看健康状态esxcli hardware status这一步能发现大部分驱动或固件层面的异常。如果业务虚拟机启动后网络不通大概率是网卡驱动没加载或启用的端口没起来。5.2 确认版本后删掉datastore上那个depot包升级确认没问题就可以把上传的depot zip删掉了。一个包好几个GB留在datastore里既占空间又没意义。同时检查一下VIB列表里有没有没用的旧VIB残留有需要可以用esxcli software vib remove -n vib名称清理。这些都是看着不起眼但能避免后续麻烦的操作。5.3 处理证书和许可证状态升级后如果登录Web界面提示您当前正在评估模式下使用ESXi。此许可证将在60天后过期说明许可证信息没被继承或者需要重新激活。这时把许可证密钥重新加进去esxcli license add -k 许可证密钥 esxcli license list之前我在群里看到好几个人升级完第二天被这个提示吓到其实就是许可证没重新导入而已。证书方面独立主机直接生成新的自签名证书就行vCenter管理的则在vCenter里刷新证书状态。说实话ESXi的升级流程里depot包其实是相当省心的一个方案。我自己在Workstation里用depot包练过很多次手也帮朋友处理过生产环境升级翻车的问题。这套流程最核心的思路其实就三条认准官方来源、核对build号、升级前做好配置备份。只要这三条落实了剩下的大多只是时间问题。最后再啰嗦一句不管你手里的文件名多像官方货先执行一次profile list看一眼包内真实的版本信息再动手这个习惯能帮你避开绝大多数坑。本文还有配套的精品资源点击获取