企业官网建设流程全解析

简介：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软件仓库包格式，里面不只是一个补丁文件，而是包含了完整的VIB（vSphere 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 GA：Build 20513097（2022年11月发布）
• ESXi 8.0 Update 1：Build 21495797（2023年4月发布）
• ESXi 8.0 Update 2：Build 22380479（2023年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必须支持LMCE（Local 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 Interface（DCUI），在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号，模型不变，心态不要慌。

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