简介VMware-ESXi-8.0U2-22380479-depot.zip 是面向虚拟化运维工程师的 ESXi 8.0 Update 2 离线 Depot 包尤其适合无外网或安全隔离环境下的 vSphere 主机安装、版本升级与补丁管理。资源共包含124个文件以121个 VIB 驱动与功能组件为主体VIB 是 ESXi 可独立安装和卸载的软件单元可覆盖核心 hypervisor、vSAN、集群存储与健康检查等模块另辅以2个 XML 元数据文件用于描述组件依赖关系以及1个 ZIP 归档文件便于扩展驱动分发压缩包整体约587.17MB适合离线备存与批量交付。实施人员可借助 esxcli 命令或 VMware Update Manager 将 depot 作为软件源在无外网环境完成 ESXi 主机的离线安装、标准化升级与驱动补充避免在线源不稳定或安全合规方面的风险。已有821人学习/下载对于正在规划虚拟化平台上线、需要批量初始化 ESXi 主机或严格管控补丁来源的运维团队是一份实用且可追溯的离线源资料。 你们这些做企业虚拟化运维的最近手里应该都陆续拿到了或至少听说过这个包VMware-ESXi-8.0U2-22380479-depot.zip。这是VMware在2023年下半年发布的ESXi 8.0 Update 2版本的官方离线补丁包也是一个被很多运维同行私下里叫“最省心的升级包”的东西——它解决了我们在无外网或弱外网环境下给ESXi主机打补丁、做版本升级时的最大痛点。这篇就专门聊聊这个离线包本身以及围绕它展开的离线升级、部署、踩坑和排查的完整思路。整个过程我是实际在机房环境里反复操作过多次的从命令行到图形界面到日志排查都有涉及你可以把这篇文章当成一份可直接参考的实战笔记而不是纯粹的功能罗列。如果你正面临“ESXi 8.0 U2离线包怎么用”、“depot.zip和普通补丁有什么区别”、“离线升级ESXi需要注意什么”这类问题这篇文章应该能帮你把整个链路捋清楚最后自己也敢上手操作。1. 版本解读与离线包应用场景拆解先把这个文件名拆开看VMware-ESXi-8.0U2-22380479-depot.zip其实透露了很多关键信息。如果你能正确解读这个命名规则以后看到任何ESXi离线包都能第一时间判断它的版本、用途和适用范围不用手忙脚乱去官网查半天。1.1 depot.zip是什么depot.zip是VMware官方发布的ESXi软件仓库包格式里面不只是一个补丁文件而是包含了完整的VIBvSphere Installation Bundle组件集合、元数据描述文件以及升级所需的所有依赖。简单说它是给ESXi主机做版本升级或补丁更新用的“全家桶”。这和我们平时下载ESXi安装ISO是完全不同的逻辑。ISO是用来做全新安装或者交互式安装的而depot.zip是给已经运行中的ESXi主机做原地升级In-Place Upgrade用的。它的威力在于配合esxcli命令行工具后可以完全不需要图形界面通过SSH就能把主机从一个版本升级到另一个版本非常适合批量管理多台主机的场景。提示depot.zip全称叫“offline bundle”官方术语是“Offline Patch Bundle”意思是它不需要联网下载额外依赖所有需要的组件都打包在里面了。这个设计对那些有严格安全隔离要求、无法访问外网的机房来说简直是救命稻草。1.2 版本号22380479的含义与版本演进文件名中的22380479是VMware的Build Number构建号这个是判断具体版本的最准确依据光看“8.0U2”其实还不够严谨。我见过有同行拿着U2的ISO结果给一台已经是U2但Build号更新的主机做“升级”最后命令行提示没有可用更新搞得一头雾水。ESXi 8.0系列的版本演进大致是这样ESXi 8.0 GABuild 205130972022年11月发布ESXi 8.0 Update 1Build 214957972023年4月发布ESXi 8.0 Update 2Build 223804792023年10月发布每次U版本发布通常包含安全补丁、驱动更新、Bug修复以及部分功能增强。所以如果你现在还是8.0 GA或者8.0U1这个U2的离线包就是你应该重点关注的升级目标。1.3 离线包的核心价值场景这类离线包实际应用最多的是下面三类场景第一生产环境的内网隔离网络。很多企业的VMware集群跑在内网没有外网权限甚至vCenter的补丁库都无法访问。这时候depot.zip就是唯一合规、安全的升级路径。你只需要从开发环境或一台允许访问外网的机器上把包下载下来拷贝到内网存储或直接传到ESXi主机的本地存储上就可以完成升级。第二批量标准化升级。如果你同时管理几十台甚至上百台ESXi主机用图形界面一台台升级会累死人。通过depot.zip配合esxcli命令可以写脚本批量执行整体效率会高很多。第三等保合规与安全加固。ESXi 8.0U2这个版本修复了多个已知安全漏洞包括一些高危的远程代码执行漏洞在等保测评或安全审计前把主机版本统一升到U2是一个很常见的动作。离线包的方式能保证所有主机升到完全一致的版本避免出现“除了版本号不同其他都不同”的混乱局面。2. 升级前的环境准备与风险评估每次做ESXi升级我都不建议直接上来就执行命令。准备工作做的到位不到位决定了你这次升级是“一次过”还是“折腾半天回滚”。这里面的门道不少我逐步拆开说。2.1 硬件兼容性和驱动检查ESXi 8.0整体告别了传统BIOS启动模式这算是一个分水岭。如果你还在用老旧的服务器特别是那些只有Legacy BIOS启动方式、不支持UEFI的设备即使处理器和其他硬件配置达标也装不上8.0。升级前你要检查的第一件事就是启动模式。接下来是处理器支持。ESXi 8.0最低要求是支持64位x86架构的处理器至少两颗核心同时CPU必须支持Nehalem或更新的微架构。更关键的是CPU必须支持LMCELocal Machine Check Exception特性。我遇到过一个案例一台搭载了较老款Xeon E5-2600 v2系列CPU的服务器虽然硬件规格看起来还行但死活无法完成8.0U2的升级最后查日志发现就是CPU不支持LMCE导致的。驱动方面ESXi 8.0U2对网卡、阵列卡HBA卡、NVMe控制器的兼容性有更新的要求。你要做的是去VMware官网的兼容性指南页面VMware Compatibility Guide查询你的服务器型号、网卡型号、存储控制器型号是否在8.0U2的兼容列表里。特别提醒几个容易踩坑的点Realtek瑞昱板载网卡ESXi 8.0原生支持很不友好很多型号不认或者装了以后管理网络不稳定。Intel i210/i211网卡部分早期版本驱动有Bug升级后可能出现管理网络丢包。老旧SAS控制器比如LSI 9240-8i这一类的卡8.0的驱动vmkata或sata-xahci支持情况需要提前确认。2.2 重要数据备份与快照策略很多人总觉得ESXi主机层面没什么好备份的虚拟机不都在存储上吗这个想法很危险。ESXi主机的配置文件、虚拟交换机配置、存储映射关系、内核启动参数这些内容一旦在升级过程中出现异常轻则网络中断重则虚拟化层无法正常启动所有虚拟机都没有办法通过ESXi主机管理。我的建议是升级前至少做四件事第一通过vCenter或ESXi Web界面导出主机的配置备份。路径大致是“管理” - “系统” - “备份与恢复” - “备份”这个操作会生成一个.tgz配置文件。这个备份必不可少而且最好下载到本地电脑不要只存在同一台ESXi上。第二如果条件允许对主机进入维护模式前给关键虚拟机做一次快照或备份。从高可用角度讲这个不是必须但求心安。第三截图或文字记录当前主机的网络配置、虚拟交换机vSwitch设置、iSCSI或NFS存储挂载参数。万一升级后配置被重置或异常你有参照能快速恢复。第四确认该主机上的虚拟机是否设置了自动启动。如果设置了升级完成后主机重启虚拟机可能会自动开机。某些场景下比如业务系统需要人工确认启动顺序这反而会带来麻烦。2.3 维护模式与迁移规划ESXi升级过程中主机需要重启重启期间这台主机上的虚拟机必须全部迁移到其他主机上或者关机。这也是维护窗口期要做的核心操作之一。如果你有vCenter管理集群且启用了vSphere HA高可用和DRS分布式资源调度可以把主机置入维护模式vCenter会自动把虚拟机迁移到其他主机上。具体步骤是选中主机 - 右键 - “维护模式” - “进入维护模式”。但请注意如果主机上有“独立”非共享存储上的虚拟机或者有直通设备PCI Passthrough的虚拟机DRS无法自动迁移需要你手动处理。没有vCenter的环境用的是ESXi单机版那就需要提前通知相关业务方计划停机时间将虚拟机关机后再执行升级。对于单机环境我的习惯是升级前记录所有虚拟机的开机关机顺序和依赖关系升级完成后按顺序开机避免出现业务系统之间因启动顺序导致的服务异常。实战补充进入维护模式时ESXi会先迁移虚拟机的内存状态如果配置了vMotion这个过程里我遇到过“虚拟机卡在正在迁移中”的情况。排查方法也不复杂去该虚拟机所在的主机VMkernel日志里看存储迁移的进度确认是网络问题还是存储问题必要时把虚拟机手动断电重新迁移。3. 离线升级实操全流程准备工作做完接下来就是实际操作了。整个离线升级过程不复杂但细节快不得。我会用最常用、也最稳的esxcli命令行方式来演示同时也提一下vCenter生命周期管理器Lifecycle Manager的图形化方式。3.1 离线包的上传与校验拿到VMware-ESXi-8.0U2-22380479-depot.zip之后第一件事不是解压实际上这个zip不建议手动解压而是把它上传到ESXi主机的存储上。你可以用WinSCP、FileZilla这类SFTP工具连接到ESXi主机的管理IP默认是SFTP服务开启的把zip包传到/tmp目录或者/vmfs/volumes/datastore1/下的某个文件夹。个人习惯是传到/tmp下用完即删不占用数据存储空间。上传完成后建议先做个校验防止文件损坏。在ESXi Shell中执行MD5或SHA256校验把它和官方提供的校验值对比。ESXi默认自带的md5sum命令可以直接用md5sum /tmp/VMware-ESXi-8.0U2-22380479-depot.zip如果和你查到的官方MD5值不一致这个包基本就是下载过程中损坏了或者被篡改了就不要继续用了。这一步能帮你省去后续很多莫名其妙的报错。3.2 用esxcli命令实施离线升级升级命令的核心思路是先查询可用profile再执行profile更新。先让我们看看depot.zip里包含了哪些配置文件esxcli software sources profile list -d /tmp/VMware-ESXi-8.0U2-22380479-depot.zip执行后会列出类似这样的输出Name Vendor Acceptance Level ----------------------------- ------------- ---------------- ESXi-8.0U2-22380479-standard VMware, Inc. PartnerSupported ESXi-8.0U2-22380479-no-tools VMware, Inc. PartnerSupported其中ESXi-8.0U2-22380479-standard是标准版包含VMware Tools的集成包等no-tools版本通常不常用除非你有特殊需求不想要VMware Tools。确认profile名称后执行升级esxcli software profile update -d /tmp/VMware-ESXi-8.0U2-22380479-depot.zip -p ESXi-8.0U2-22380479-standard这里-d指定depot包路径-p指定要升级到的profile名称。命令执行过程中会先检查依赖关系然后安装VIB包最后提示你重启主机生效。整个过程中如果遇到报错会直接显示在界面上你需要根据报错信息做处理。重要提示这个命令一定要在主机处于维护模式下执行。否则ESXi会提示“The host is not in maintenance mode”拒绝执行。不要试图强上这个限制是合理的保护机制。升级完成后重启主机reboot重启后ESXi会完整加载新版本内核和驱动。重启完成登录Web界面在“主机 - 摘要”里就能看到版本号已经变成8.0.0 Build 22380479说明升级成功。3.3 vCenter生命周期管理器的图形化替代方案如果你不喜欢命令行环境里也有vCenter Server且版本支持8.0U2完全可以用vCenter的“生命周期管理器”来做升级操作更直观、更符合部分运维团队的管理习惯。方法也很简单在vCenter的“生命周期管理器”里导入这个离线包depot.zip作为基准Baseline把需要升级的主机添加到基准组然后执行“扫描”和“修复”。这个做法的优势在于vCenter会帮你做更细致的依赖检查、主机兼容性检查并在修复操作里自动帮主机进入维护模式、迁移虚拟机。整个过程不需要SSH登录ESXi对没有命令行基础的团队成员也友好。缺点是需要vCenter本身在线、能正常管理主机如果你连vCenter都还没环境那就老老实实用单机esxcli命令行速度反而更快。4. 升级后的核验、驱动检查与常见问题排查升级结束不代表任务结束。一台ESXi主机从8.0U1升到8.0U2系统提示成功、版本号显示正确还远远不够。你需要做一系列核验动作确保主机真正健康运行。这里我把踩过的坑和排查经验一并整理出来。4.1 升级后的健康状态核验清单升级后我习惯按下面的顺序做系统性检查# 查看ESXi版本和构建号 vmware -v # 查看系统运行时间和内核模块加载状态 uptime esxcli software vib list | grep -i esx-base # 查看存储是否全部正常挂载 esxcli storage vmfs extent list esxcli storage nfs list esxcli storage iscsi session list # 查看虚拟交换机状态 esxcli network vswitch standard list # 查看管理网络是否正常 esxcli network ip interface list如果上面某一步出现异常比如某个VMFS数据存储加载失败、NFS挂载丢失、虚拟交换机丢包率上升先不要急着恢复虚拟机优先排查清楚再继续。这里要特别强调一下管理网络。升级过程中如果底层网卡驱动有问题管理网络可能会出现“能ping通但vSphere Web Client打不开”或者“SSH连不上”的情况。一旦遇到管理网络异常不要慌直接去服务器物理控制台iLO、iDRAC、IPMI或者本地显示器登录ESXi的Direct Console User InterfaceDCUI在DCUI里按F2重置管理网络配置。ESXi的DCUI永远是最后一道控制通道练熟它不吃亏。4.2 版本升级与许可证的坑ESXi 8.0U2升级完成后另一个很容易引发后续问题的点是许可证。如果你升级前用的是某种评估版或特定功能License升级后License可能不匹配、功能特性被降级。ESXi 8.0的许可证机制和旧版本有较大差异。从8.0开始VMware调整了销售模式vSphere的许可证从“按CPU插槽”改为“按核心数”许可。如果你之前用的是vSphere 7的许可直接升级到8.0U2可能面临License不兼容的提示。遇到这类情况第一种处理方式是到vCenter的“许可证”管理里重新分配许可如果无法分配联系VMware客服或代理商申请8.0版本的License Key。生产环境务必在升级前先确认License是否支持8.0版本别到时候因为License问题回滚折腾一大圈。4.3 Web界面无法登录或证书状态异常“ESXi Web界面无法登录”是社区里问得最多的问题之一尤其升级后。表现通常有两种一种是访问HTTPS地址能弹出页面但输入账号密码后一直提示认证失败另一种是浏览器直接报不安全连接、证书错误。升级后出现的认证失败大部分情况是主机的时间不对了。ESXi系统和vCenter之间、浏览器和ESXi之间都有时间同步要求时间偏差过大会导致Kerberos票据、证书验证、SSO认证失败。这个排查优先级排第一# 在ESXi shell查看时间确认是否和当前时间相差太大 date确认时间偏移后手动调整或用NTP同步。手动调整命令# 举例把时间设置为2024-01-15 10:30:00注意ESXi时间不能随意跨越太远最好配合NTP同步 esxcli system time set -d 2024-01-15 10:30:00如果是证书状态异常打开vSphere Client后看到“证书状态无法验证”的警告并且SSH登录时也提示证书指纹不匹配这是常见的告警一般不影响使用。究其原因升级可能覆盖或重置了一些证书文件。如果介意这个告警可以在vCenter里为主机重新“刷新”或“续订”信任关系。如果是单机ESXi也可以通过DCUI重置证书。4.4 升级后虚拟机无法启动或启动异常升级完成后比较常见的启动异常有几种第一种虚拟机提示“此虚拟机使用了不受支持或无效的配置”。这通常是因为升级前虚拟机硬件版本太老8.0U2默认的虚拟机兼容性版本提升了老版本虚拟机配置文件可能跟不上。这种场景一般不建议直接去强行修改虚拟机的.vmx配置文件很容易把虚拟机搞坏。正确姿势是确认ESXi主机升级成功后在vCenter或Web Client里把虚拟机关机然后升级虚拟机硬件版本Upgrade VM Compatibility。第二种虚拟机开机后卡在VMware引导界面或直接蓝屏。升级后出现这种大概率是虚拟机的操作系统和新的VMware Tools或BIOS/UEFI设置不兼容。排查方法是先看看虚拟机的“高级参数”里有没有特殊配置如果有可以将虚拟机关机后把虚拟机的引导模式切换成和之前一致Legacy BIOS或UEFI。另外查看虚拟机日志.vmx所在目录的vmware.log能看到具体的报错原因这个日志信息量非常大排查问题必看。第三种虚拟机内操作系统网络不通。这种情况多和数据存储映射或虚拟交换机配置有关。先检查ESXi主机层面的端口组PortGroup配置和数据存储是否正常再到虚拟机内部看网卡状态、IP配置等。不要在虚拟机内部乱改一通先定位是虚拟化层问题还是Guest OS问题。4.5 各种离线包报错与依赖问题的快速定位执行升级命令时esxcli可能会抛出一堆眼花缭乱的报错。最常见的是以下几种[DependencyError] VIB ... requires ... 因为某些原因无法满足。这类问题的实质是depot包里的VIB和你当前系统的其他VIB版本有冲突。解决方法通常是先升级到中间版本再升级到目标版本或者用--force参数强制安装但只在明确知道风险的情况下才建议force生产环境不要轻易用。还有一类是[MetadataError] Could not find a trusted signer这通常是证书信任问题。depot里的VIB包签名不受当前ESXi版本信任。出现这类报错先确认你下载的depot.zip来源是否正规是不是在VMware官网下载的如果确定来源无问题可以检查主机的Acceptance Level接受级别。命令是esxcli software acceptance get如果当前级别是CommunitySupported社区支持部分签名验证流程不一致。一般建议将接受级别设置为PartnerSupported或VMwareAccepted再重试。如果确实是离线包本身有问题或来源不正规该放弃就放弃不要硬上。5. 实际操作中的经验总结与扩展建议整个离线包升级的过程走完你会发现只要前期准备做扎实实际执行命令的时间其实只有几分钟真正耗时的是前面的硬件检查、兼容性核对、维护模式规划和升级后的核验。我这里分享几条实战经验供你参考。第一离线包升级前务必先用vCenter或esxcli做一次“软件源扫描”。很多问题其实升级前就能暴露。通过esxcli software sources profile list不仅能看到depot包里有哪些profile还能看出是否有缺依赖、版本冲突等隐患提前规避。第二批量升级多台主机的时候不要同时启动所有主机的维护模式。如果共享存储上有大量虚拟机同时迁移会导致存储网络拥塞。建议分批操作一台主机升级完成、确认正常后再操作下一台。有条件的话先拿一台测试机或非核心机试一次跑通了再铺开。第三升级depot包的文件名务必保留原样不要随手改成esxi8.zip之类的名字。因为包的元数据内部记录了版本信息文件名改动虽然不影响注释和安装过程但不利于后续你查日志、排查问题时定位。运维环境里一切信息都要有利于追溯文件名就是最简单直接的追溯点。第四做一次完整的升级记录。我自己的习惯是每次升级维护都建一个文本文档记录主机IP、原版本号、目标版本号、升级命令输出、升级后的版本号、主要核验结果、遇到的问题和解决过程。下次再升级或者遇到类似问题时翻查这个记录会是很好的参考。这个离线包后续还可以扩展到其他用途。比如你可以基于depot.zip做一个基线配合vCenter的“主机配置文件Host Profile”功能在多台新主机上线时批量部署完全一致的ESXi系统配置。也可以把depot包传到一台内部HTTP服务器上配置一个内部ISO镜像源实现全集群范围内的快速补丁分发这对超大规模集群的维护特别有用。另外提醒一点VMware已经多次强调无限期支持和订阅模式下的产品演进方向。ESXi 8.0U2不是最后一个版本后续的8.0U3、9.0等版本陆续会来。掌握depot.zip离线包的各种操作细节之后后面再遇到新版本升级操作逻辑基本是相通的变的只是版本号和build号模型不变心态不要慌。本文还有配套的精品资源点击获取