简介VMware ESXi 6.7.0的UI离线升级包面向虚拟化运维人员与VMware管理员适用于vSphere环境下的主机UI组件更新、升级前检查及故障排查可解决UI版本落后、升级中触发Possibly unhandled rejection报错等问题。压缩包体积仅3.63MB共含4个文件两个xml索引文件分别用于描述包内组件的名称、版本与依赖关系以及校验升级包提供方的合法信息一个vib格式的esx-ui核心组件包版本1.33.1-12086396负责实际更新ESXi的用户界面另一个zip文件则记录签名、发布日期、描述等元数据用于确认升级包的完整性与正确性。目前已有526人学习下载。通过拆解这套离线升级包管理员可以理解VIB离线安装机制和esxcli软件的部署逻辑掌握索引文件、元数据与组件包之间的协作关系同时结合Possibly unhandled rejection错误的排查思路可逐步检查网络连接、认证状态、主机运行情况以及升级包与当前ESXi版本的兼容性在升级前预防失败在升级失败后快速定位并恢复。1. 先想清楚再动手esxui-offline-bundle 到底是拿来干嘛的「esxui-offline-bundle-6.x-12086396.zip」这串文件名第一次见到的人很容易把它当成一个 ESXi 系统补丁包其实它不升级系统内核也不碰驱动基线。它是 ESXi 6.x 的 UI 服务组件离线包esxui 指的是 vSphere Client 网页端依赖的那套嵌入式 UI 服务6.x 是适用版本线12086396 是 build 号。它的价值在于给不连外网的隔离网络送上一颗后悔药——不需要配置软件源、不需要拉在线仓库一个 zip 就能通过 esxcli 把 UI 组件装上、升级或回滚。适合正在维护 vSphere 6.x 环境的运维也适合第一次接触离线安装包的初学者沿着这个包把 depot、VIB、bootbank 这套概念完整过一遍。2. 拆开 zip 验货offline bundle 的结构、版本线与上机前检查2.1 offline bundle 不是普通压缩包zip 里装的是 VIB拿到手先别急着传主机第一件事是把包拆开看看里面是什么。ESXi 的 offline bundle 虽然以 .zip 结尾但它不是给你解压了拷来拷去的普通压缩包而是一个 depot 结构里面是若干个 .vib 文件和一个 metadata.zipvib 是 ESXi 的软件单元格式metadata 则记录着这些 VIB 的依赖关系、兼容性声明和安装级别。esxcli 之所以能直接拿 .zip 当安装源就是因为它能同时读到这两个部分。unzip -l esxui-offline-bundle-6.x-12086396.zip unzip -l esxui-offline-bundle-6.x-12086396.zip | grep -E \.vib$第一条命令列出 zip 内全部条目你会看到 metadata.zip 和若干以 .vib 结尾的文件。第二条把 VIB 文件单独筛出来方便你数一数这个包里到底有几个组件、命名是否符合预期。如果你拿到的包在解压列表里连 .vib 都看不到那这个文件大概率是损坏的或者根本不是 offline depot后面所有步骤都不用继续了。这里有个关键认知esxcli 能直接消费 zip不代表解压后的目录也一定能被消费。depot 目录模式下esxcli 要求 metadata.zip 必须按特定层级放在目录里很多人在这一步踩坑后面第 5 章会展开讲。2.2 版本线不是万能钥匙用 build 号对基线文件名里的 6.x 是一个版本线代号很多人想当然地认为「6.x 的包ESXi 6.0、6.5、6.7 都能装」。这是一个危险的直觉。ESXi 同一大版本线内会有多个 build 基线UI 服务组件依赖的是当前基线上其他内置 VIB 的版本跨小版本硬塞esxcli 在依赖检查阶段就会拒绝执行报出类似 VIB 依赖无法满足的信息。在主机上确认当前版本和 build 号标准做法vmware -v esxcli software vib get | grep -i version第一条输出形如 VMware ESXi 6.x build-xxxx给出你这台主机的真实版本线第二条列出核心 VIB 的版本信息配合当前 build 号一起看。把文件名里的 12086396 和主机当前 build 放一起比对再结合官方兼容列表确认这个包适用于哪个子版本线这一步不要凭感觉。另一个容易忽略的是 acceptance level接受级别。离线包里的 VIB 有 CommunitySupported、PartnerSupported、VMwareAccepted、Certified 四档而每台 ESXi 主机也有自己的接受级别设置。用esxcli software acceptance get查主机当前值如果包的级别高于主机的设定esxcli 会拒绝安装。装之前顺手把这个也查了能省掉一次报错来回。2.3 上机前验包校验和与包内容确认包从网上下载、从 U 盘拷贝、从同事手里转手一路上任何一次中断都可能让文件悄悄坏掉。zip 能解压不代表字节没问题尤其是几百 MB 的大文件解压工具有时会容忍部分尾部损坏但 esxcli 在解析 metadata 时不会。所以上机前先算校验和。sha256sum esxui-offline-bundle-6.x-12086396.zip把输出的哈希值和发布方提供的值比对。没有提供值怎么办至少保证你手上两个不同来源的文件哈希一致。我习惯在下载完成、上传主机前、安装前各算一次三次一致再往下走成本极低但能挡掉绝大多数「装到一半报错」的尴尬。包内容确认也值得顺手做unzip -p esxui-offline-bundle-6.x-12086396.zip metadata.zip /tmp/metadata_check.zip unzip -l /tmp/metadata_check.zip | head -20第二条命令把 zip 内嵌的 metadata.zip 解出来看目录结构。正常时你能看到类似 profiles 和 vibs 的目录层级。如果这里面的结构不完整说明包本身有问题别浪费时间在主机上排错了。这一步做完包的质量基本心里有数再进入传输环节。3. 把包送进主机scp、本地 depot 与上传后的现场确认3.1 最稳的方式scp 直接把 zip 送进 /tmp离线包要装进 ESXi第一步是让目标主机能「够到」这个文件。最常见也是我最推荐的方式是 scp 到 /tmp 目录。ESXi 的 /tmp 在脱机安装场景下是 esxcli 最友好的落点路径短、权限足、不用纠结 vmfs 卷名。scp esxui-offline-bundle-6.x-12086396.zip root192.168.10.20:/tmp/把 192.168.10.20 换成目标主机的管理 IP。如果 SSH 端口不是默认的 22加-P 端口号如果内网带宽紧张加-l 4096限速到 4Mbps免得 scp 把管理网络带宽吃满。前提是目标 ESXi 的 SSH 服务已开启。没开的话登录 vSphere Client在主机 → 服务里找到 TSM-SSH临时启动它传完包再关掉。别为了省事长期开着 SSH这是安全习惯问题。这里有个基本原则把 zip 放在 /tmp然后再装。有人图省事用 vSphere Client 直接把 zip 上传到 datastore然后让 esxcli 指向那个路径不是不行但路径要写成 /vmfs/volumes/datastore1/xxxx.zip 这种完整形式少写一层就容易报找不到文件属于典型的黑匣子路径问题。新手阶段统一走 /tmp 最不容易翻车。3.2 多台主机共享配一个本地 HTTP depot如果只有一两台主机scp 逐个传没问题。但如果手头是一批 ESXi 集群节点每台传一份几百 MB 的包浪费时间也占空间。常见做法是搭一个内网 HTTP depot让所有主机从同一个地址拉取离线源。把 zip 放在一台内网机器上然后cd /data/esxui-depot python3 -m http.server 8000 --bind 0.0.0.0这台机器只要能被 ESXi 管理网络访问到即可。之后在任意一台 ESXi 主机上验证esxcli software sources vib list -d http://192.168.10.5:8000/esxui-offline-bundle-6.x-12086396.zip能列出来 VIB 信息说明 depot 通了。后续安装时把 -d 参数指到这个 http 地址就行不用再往每台主机传文件。depot 目录结构要注意我之前直接放 zip 在 HTTP 根目录esxcli 能识别但如果把 zip 解压后放目录需要保证 metadata.zip 和各 VIB 在同一个目录层级下否则 esxcli 解析不到依赖关系。HTTP 服务方式还有一个好处可以先跑esxcli software sources vib list确认仓库状态再决定装不装比直接闷头安装多一道缓冲。3.3 传完先看现场大小、空间、完整性三查文件到了主机上不等于可以放心装了。ESXi 的 /tmp 目录在不同版本和配置下空间差异很大有的只有几百 MB有的挂的是内存盘。一个几百 MB 的 zip 加上安装时解压产生的临时文件空间不够会装到一半失败。ls -l /tmp/esxui-offline-bundle-6.x-12086396.zip df -h /tmp sha256sum /tmp/esxui-offline-bundle-6.x-12086396.zip第一条看文件是否完整落盘大小应该和本机原文件一致第二条看 /tmp 剩余空间建议至少留出 zip 大小两倍的余量第三条重新算校验和和原文件比对确认传输过程没有损坏。如果 /tmp 空间不够我一般会把包改放到 datastorecp /tmp/esxui-offline-bundle-6.x-12086396.zip /vmfs/volumes/datastore1/后面的安装命令 -d 参数指向 /vmfs/volumes/datastore1/esxui-offline-bundle-6.x-12086396.zipesxcli 同样能识别。注意ESXi 默认 shell 不支持 Tab 补全 vmfs 路径别偷懒路径拼写错了不报错只会在安装时给你一句冷冰冰的找不到 depot。4. 安装与回滚esxcli 装 VIB、挑组件装与后悔药4.1 标准安装命令与参数逐项说明包到位、空间确认、校验通过开始正式安装。最常见的安装方式是用 esxcli software vib install把整个 zip 作为 depot 安装esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-12086396.zip --maintenance-mode先解释几个参数这个命令值得逐字段理解因为很多人只会照抄出了问题不知道从哪查。参数作用使用时机-d / --depot指定安装源可以是 zip、目录或 http(s) URL--maintenance-mode让主机进入维护模式后再安装生产主机强烈建议加--dry-run只预检不真正安装首次接触的包必经步骤--no-live-install禁止热安装标记需要重启生效某些 VIB 无法在运行中替换时--force跳过依赖和级别检查出事概率最高的参数非必要不用生产环境里我强烈建议先跑一遍 dry-run 再真正装esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-12086396.zip --dry-rundry-run 会把将要安装的 VIB、依赖检查结果、是否需要重启的结论一次性打印出来。你会提前看到两个信息一是这个包要装哪些组件二是主机上是否缺它依赖的东西。这一步能拦截掉绝大多数失败场景代价为零。真正安装产生的大量日志信息在 /var/log/esxupdate.log安装失败时第一个去这里找线索而不是在屏幕上反复试命令。tail -n 80 /var/log/esxupdate.log日志会明确写出哪一步失败、涉及哪个 VIB、依赖缺什么。这一步是排查问题的起点比猜省时间得多。4.2 不装整包只挑一个 VIB 拆着装有的 offline bundle 里面不止一个 VIB有些顺手还捎带了配套组件。但你的诉求可能只是更新 UI 服务不想让同包里的其他组件动主机的当前状态。esxcli 支持从同一个 depot 里挑着装单个 VIB前提是先看清包里有哪些可装项。esxcli software sources vib list -d /tmp/esxui-offline-bundle-6.x-12086396.zip这条命令会把 depot 里所有 VIB 的名字、版本、厂商、接受级别列出来。找到 UI 服务对应的那个 VIB 名记下来然后esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-12086396.zip -n 上一步列出的VIB名 --maintenance-mode-n 参数后面填的是 VIB 的 Name 字段不是文件名。踩过坑的人都明白我说什么有人把 xx.vib 当作 -n 的参数esxcli 直接报找不到指定 VIB。如果拆装后还想看到完整依赖关系把--dry-run加上提前跑一遍。拆装适用的典型场景整包里的某个驱动 VIB 和当前硬件不兼容但你只想升级 UI 组件。此时整包安装会被驱动 VIB 挡下来拆开装反而能绕过冲突。4.3 装坏了怎么办vib remove 与回滚流程装了之后发现 UI 服务起不来、登录页报错、甚至是误装了不该动的组件别慌ESXi 的软件管理支持反向操作。esxcli software vib list | grep -i esx esxcli software vib remove -n VIB名第一步找到刚装进去的 VIB 准确名字第二步把它移除。移除操作同样会做依赖检查如果有其他 VIB 依赖它esxcli 会拒绝这时候要评估是不是必须先移掉依赖方或者只能选择重新安装旧版本。ESXi 上旧版本 VIB 的安装方式和装新的一样把旧版 depot 用 -d 指过去带上 --force 覆盖安装但 --force 的使用要非常克制。另一种常见后悔药是 reboot 后引导到旧 bootbank。ESXi 的 VIB 写入会落在当前 bootbank 槽位重启时如果新配置起不来可以在引导界面选择上一个槽位。这意味着安装前最好先记录当前 VIB 清单esxcli software vib list /tmp/vib-before-install.txt这个文件就是你的回滚依据里面记录了装包前主机的完整软件状态。真出了问题对比装前装后两份清单能精确知道哪些组件变了、哪些是本来就在的定位问题的速度完全不一样。5. 常见问题与排查从装不上到打不开的六个踩坑点5.1 把 zip 解压后指向目录esxcli 不认现象esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-12086396/直接报错提示找不到 depot 或 metadata 解析失败。原因offline bundle 的 depot 识别依赖 metadata.zip 与 VIB 的相对位置关系随手解压后目录层级对不上esxcli 自然读不出依赖关系。zip 格式本身就是被 esxcli 直接支持的最稳形态。解决不折腾直接指 zipesxcli software vib install -d /tmp/esxui-offline-bundle-6.x-12086396.zip如果确实要用目录模式按规范解压 metadata.zip 到 zip 同级目录且保持原层级环境受限时再考虑。5.2 6.x 的包在特定小版本上报依赖缺失现象安装到一半输出类似 VIB 依赖无法满足的报错列出某个组件要求的版本和当前主机实际的版本不一致。原因文件名里的 6.x 只是版本线UI 服务组件对 build 基线敏感。你的主机 build 和这个包对应的 build 差距过大时依赖检查不会通过这是保护机制不是 bug。解决先对 build 号再做决定。用vmware -v查主机实际 build对照包的 12086396 确认匹配关系。如果只是 UI 服务试试用-n只装对应组件如果依赖仍然冲突找与主机 build 匹配的包别在 --force 上死磕。5.3 /tmp 空间不够装到一半失败现象安装进度走了大半然后退出码直接非 0日志里写着磁盘空间不足。原因ESXi 的 /tmp 空间有限zip 本身几百 MB安装过程还要解压临时文件、写日志空间很快见底。本地空间不足是最容易被忽视的离线安装杀手。解决装之前先做一步空间检查df -h /tmp剩余空间低于包体积两倍时把包挪到 datastore从 /vmfs/volumes/datastore1/ 路径安装同时盯一眼 datastore 的剩余空间。5.4 UI 装好了浏览器里看的还是旧界面现象esxcli 返回装成功VIB 列表里也有对应组件但打开 vSphere Client 看到的 UI 和之前一模一样。原因浏览器缓存了旧的 CSS 和 JS 资源。ESXi UI 更新经常表现为「后台版本号变了前台毫无变化」因为浏览器根本没用新资源。解决先开一个隐私窗口强制无缓存访问确认是不是缓存问题。如果是清一次浏览器缓存再登录。如果隐私窗口下还是旧 UI再检查对应服务进程是否已重启。5.5 维护模式退不出来现象装完执行退出维护模式长时间停在 exiting任务没有报错但也不完成。原因有虚拟机还在迁移或者 HA、DRS 正在做资源重新平衡主机的维护模式退出被挂起。ESXi 不会强制打断这些任务。解决去 vCenter 的任务面板看有没有挂起的 vMotion 或检测任务等它们结束再重试退出维护模式。如果长时间卡死看主机事件里的具体阻塞项必要时重启主机后再退出维护模式。5.6 忽略 dry-run直接上 --force 翻车现象用了 --force 跳过依赖检查VIB 装上去了但服务起不来或者主机出现异常状态。原因--force 把保护机制全部绕过了依赖不满足的组件被强塞进去运行时就出问题。跳过检查的每一秒事后都要用双倍时间排错。解决这个坑的解法就一条——永远先跑 dry-run。它不耗时、不改动系统能提前暴露九成的问题。实在要 --force先确保主机有快照或配置备份再把翻车后的回滚路径提前想好。6. 装完只是开始验证、留痕和一次装成的好习惯确认 UI 组件真正生效靠两条命令足够esxcli software vib list | grep -i esx esxcli software profile get第一条看对应 VIB 的版本号是否和离线包里一致第二条看当前主机 profile 的 build 信息。两者都对上再登录 vSphere Client 看 UI 版本变化一套验证流程走完。我更想说的是留痕这件事。离线包不像在线 depot 那样随时可查装完过两个月你可能完全忘了哪台主机装了什么、为什么装。我的习惯是把包改名后归档mv esxui-offline-bundle-6.x-12086396.zip esxui-6x-build12086396-installed-20250115.zip名字里带上版本线、build 号、安装日期配合一个简单的文本清单记录装前装后 VIB 数量、是否重启、对应主机 IP。下次排查问题翻这份记录比翻聊天记录高效得多。最后一次翻车经历让我彻底养成了 dry-run 的习惯。当时图省事没跑预检直接 --force 塞了一个包结果依赖链乱了主机重启后服务起不来最后靠引导到旧的 bootbank 槽位才捞回来。一台生产主机折腾了大半夜从那以后不跑 dry-run 的离线安装在我这里等于没做。这个习惯花不了三十秒换来的是一次「绝对不会在依赖上翻车」的确定性。这套流程从验包、传包、装包到回滚每一步都有对应的命令和检查点。按顺序走下来esxui-offline-bundle 这类离线包基本不会有意外。希望帮到你。本文还有配套的精品资源点击获取