简介面向使用 VMware ESXi 6.7.0 的运维与虚拟化管理人员这是一份用于更新主机用户界面组件的离线升级包针对升级过程中可能出现的未捕获拒绝异常提供可本地部署的组件与索引依据。压缩包共 4 个文件约 3.63MB包含 2 个 XML 索引、1 个 VIB 组件包和 1 个元数据 ZIP分别用于描述组件版本与依赖、核验供应来源、承载 UI 组件及签名发布信息。已有 530 人学习下载适合需要离线维护 ESXi 环境、核对补丁适用性的人员参考。借助其中的索引与元数据读者可确认组件匹配关系和包完整性并结合异常提示排查版本兼容、认证通信等问题为 ESXi 6.7.0 的 UI 更新与故障定位提供较清晰的依据。1. 一个 zip 烧不出启动盘先把离线包和安装镜像分清楚上个月又碰到一次有人拿到esxui-offline-bundle-6.x-12086396.zip习惯性打开写盘工具烧进 U 盘结果机器起来只剩一个闪烁光标。这个动作几乎每个月都会重演一遍。ESXi 的离线升级包不是安装镜像压缩包里没有引导扇区也没有启动用的镜像文件它就是一组 VIB 加一份metadata.zip唯一面向的消费者是esxcli。它解决的是「内网没有外网、主机需要打补丁或跨小版本升级、几十台机器要统一基线」这类问题适合已经跑着 ESXi 6.x、想把版本钉在某个 build 上的运维和虚拟化实施人员。把它当 ISO 用第一步就走歪了把它当 depot 用剩下的都是参数和顺序问题。2. 拆包核对metadata.zip、vib20 与 build 号三件套拿到一个几百兆的离线包先别急着往主机上传。包里到底装了什么、build 号跟你的目标版本对不对得上、profile 名长什么样这三件事在解压后的十分钟内就能全部搞清楚而它们决定了后面所有命令能不能跑通。跳过这一步直接esxcli software profile update最常见的结局是敲了个不存在的 profile 名或者升级完发现网卡驱动被换掉了。2.1 离线 depot 和在线源的差别在哪在线源esxcli software sources profile list -d https://...本质上也是拉同一套 depot 元数据只不过元数据从网络上来VIB 按需下载。离线 bundle 把这套东西整体打包成一个 zip顶层是metadata.zip同级有vib20/目录每个 VIB 自己又是一个小 zip里面装着 payload 和描述文件。metadata.zip里存的是 profile 定义和 VIB 依赖关系esxcli读它来判断「这个包能不能装在这台机器上」「装完哪些 VIB 会被替换」。理解这一点很关键离线包不是「一堆文件的集合」它是一个带依赖求解的软件仓库快照。所以升级时esxcli会做依赖检查、会拒绝降级、会因为 CPU 或已有 VIB 冲突而中途退出。很多人以为 zip 解开扔进去就行卡在这一层认知上。另一个差别是体积。在线源只下载缺失的 VIB离线包是全量的通常比实际需要的大几倍。这也是为什么它不能放在/tmp里——后面第 5 章会专门讲这个坑。2.2 用 unzip 和 Python 把包结构摊开先做完整性校验再看清单最后解压。三步分开做出问题时能立刻定位是下载坏了还是包本身结构不对。# 1) 校验完整性把结果跟发布方给的 SHA256 对一下 sha256sum esxui-offline-bundle-6.x-12086396.zip # 2) 只看清单不落盘确认顶层结构 unzip -l esxui-offline-bundle-6.x-12086396.zip | head -40 # 3) 解压到独立目录别直接解到当前路径 mkdir -p /tmp/esx-bundle unzip -q esxui-offline-bundle-6.x-12086396.zip -d /tmp/esx-bundle find /tmp/esx-bundle -maxdepth 2 -type d | head -20 du -sh /tmp/esx-bundlesha256sum的结果必须跟来源方公布的一致不一致就重下别抱侥幸——半个包解压到中途报End-of-central-directory signature not found是最浪费时间的一种失败。unzip -l只看不写能快速判断这个 zip 是 depot 结构顶层有metadata.zip和vib20/还是别的什么东西。第三步用find加du是为了确认解压后目录深度和总大小正常应该在几百兆量级。如果手上没有 Linux 环境用 Python 直接读 zip 更省事也不用担心解压污染磁盘import zipfile, io, re BUNDLE esxui-offline-bundle-6.x-12086396.zip with zipfile.ZipFile(BUNDLE) as outer: names outer.namelist() print(顶层条目数:, len(names)) # depot 包的元数据固定叫 metadata.zip找不到就说明这不是升级包 metaname next((n for n in names if n.rstrip(/).endswith(metadata.zip)), None) if metaname is None: raise SystemExit(未找到 metadata.zip这个 zip 不是 esxcli 能吃的 depot 包) # 元数据本身也是一个 zip用内存流读避免落盘 meta zipfile.ZipFile(io.BytesIO(outer.read(metaname))) profiles [n for n in meta.namelist() if n.startswith(profiles/)] print(profile 条目:, len(profiles)) for p in profiles: text meta.read(p).decode(utf-8, ignore) # profile 的显示名在 name 标签里升级命令的 -p 参数要的就是它 for m in re.finditer(rname([^])/name, text): print( profile:, m.group(1))这段脚本的重点在两个地方。BUNDLE换成你的实际路径即可其余不用改rstrip(/)是防某些打包工具在目录名后多加斜杠导致匹配失败。profiles/前缀筛选出来的是 profile 定义文件一个包里通常有多条standard、no-tools之类各一条有的人只记standard却敲了个latest就会直接报No matching profile found。脚本打印出来的名字原样复制到-p后面不要手打。2.3 build 号、profile 名和硬件兼容性核对包名里的12086396是 build 号它必须和你要升到的目标版本一致也必须和你主机当前版本形成「升级」关系而不是「降级」。下面这张表是我每次升级前必填的填不满就别按回车。核对项在哪看判断标准目标 build 号包名 / metadata 里的 profile 名与变更单上的目标版本一致当前 build 号vmware -v低于目标 build否则是降级profile 名2.2 脚本输出逐字符复制注意standard后缀CPU 支持esxcli hardware cpu list型号不在被移除支持的老架构内网卡与存储控制器esxcli network nic list、esxcli storage core adapter list驱动来自标准包还是后装 VIB已装异步 VIBesxcli software vib list升级后会不会被标准 profile 抹掉最后两行是重灾区。标准 profile 只保证包含官方基础驱动服务器原厂定制镜像里那批异步驱动不在其中升级完成后会被直接移除——机器重启网卡没了管理地址ping不通只能去机房接显示器。所以升级前务必把esxcli software vib list的完整输出存一份重点看名字里带厂商前缀、版本号又跟标准包对不上的条目。3. 三条落地路径U 盘装机、esxcli 就地升级、内网本地源同一个离线包在不同场景下有三种完全不同的用法选错了不是效率问题而是能不能用的问题。全新装机需要的是安装镜像就地升级用的是esxcli直接指向 zip批量部署则要把 zip 变成内网可访问的本地源。三条路径的工具链和前置条件都不一样下面逐条拆。3.1 只有 zip 的时候怎么做可引导介质先明确结论这个 zip 本身无法做成启动盘。要装机必须另取对应的安装镜像ISO或者用厂商提供的部署镜像。zip 的用途是升级不是安装。如果你手上确实同时有 ISO写盘这一步别用图形工具里的「镜像模式」容易写成文件拷贝而丢掉引导记录。Linux 下用dd最稳# 先确认 U 盘设备名看容量和型号别认错盘 lsblk -o NAME,SIZE,MODEL,TRAN # of 后面必须是整盘设备如 /dev/sdb不能带分区号 sudo dd ifesxi-installer.iso of/dev/sdb bs4M statusprogress oflagsync syncbs4M是吞吐和内存占用的平衡点再大提升有限oflagsync保证写完再返回不加这行拔盘太早会得到一个「能启动但装到一半报错」的介质排查起来极其费劲。of写成分区例如/dev/sdb1是新手最常见的翻车点写完盘还能挂载但机器根本起不来。装完之后的引导顺序也要确认。有的机器 BIOS 里 U 盘排在本地磁盘后面装完重启又从旧盘进了系统看起来像「装了个寂寞」。装完第一次重启前把 U 盘拔掉或者进 BIOS 把本地磁盘提到第一位。3.2 esxcli 就地升级的完整命令序列这是离线包最主要的用法主机已经在跑版本往上升一个小版本或打补丁业务停机窗口内完成。整条链路是「进维护模式 → 放包 → 干跑 → 真跑 → 重启 → 出维护模式」中间任何一步失败都不要往下走。# 1) 进维护模式确认状态 vim-cmd hostsvc/maintenance_mode_enter vim-cmd hostsvc/maintenance_mode_get # 2) 把 zip 放到数据存储不要放 /tmp原因见第 5 章 # 假设数据存储挂在 /vmfs/volumes/datastore1 ls -lh /vmfs/volumes/datastore1/iso/esxui-offline-bundle-6.x-12086396.zip # 3) 列出包里的 profile把名字原样记下来 esxcli software sources profile list \ -d /vmfs/volumes/datastore1/iso/esxui-offline-bundle-6.x-12086396.zip # 4) 干跑只做依赖求解不落盘 esxcli software profile update \ -d /vmfs/volumes/datastore1/iso/esxui-offline-bundle-6.x-12086396.zip \ -p ESXi-6.7.0-12086396-standard \ --dry-run # 5) 干跑无报错再真跑 esxcli software profile update \ -d /vmfs/volumes/datastore1/iso/esxui-offline-bundle-6.x-12086396.zip \ -p ESXi-6.7.0-12086396-standard # 6) 重启并确认版本 reboot参数逐个说清楚。-d指向 depot可以是本地路径也可以是http://地址本地路径必须能被 root 读到放在数据存储上最稳。-p是 profile 名示例里的ESXi-6.7.0-12086396-standard只是示意格式6.5 和 6.7 的 profile 前缀不同一律以第 3 步输出为准别照抄。--dry-run最关键它会把「哪些 VIB 被升级、哪些被移除、有没有依赖冲突」全部打印出来却不改动系统输出里的Removed VIBs一栏如果出现了你的网卡或存储驱动立刻停下先解决驱动来源问题见 2.3。这一步省掉的不是时间是去机房的机会。第 5 步执行时间通常几分钟到十几分钟别中途 CtrlC。中断在写入阶段会留下半装状态的 VIB重启后可能直接进不了系统。执行完不要立刻重启先看esxcli software vib list有没有明显缺失再重启。重启后vmware -v输出里的 build 号应该等于包名里的数字对不上说明升级没生效去看/var/log/esxupdate.log末尾几十行。3.3 内网无外网时把 zip 变成本地源管理十几台主机的时候一台台传 zip 效率太低。常见做法是找一台内网 HTTP 服务哪怕是个临时起的静态文件服务把 zip 放上去所有主机用同一个 URL 升级# 在内网一台 Linux 上起个临时静态服务端口自定 cd /srv/depot python3 -m http.server 8080 # 主机侧直接用 http 地址作为 depot esxcli software sources profile list -d http://10.0.0.10:8080/esxui-offline-bundle-6.x-12086396.zippython3 -m http.server只适合临时用升级窗口结束就关掉别长期挂在生产网段。如果内网有正式的软件源服务把 zip 放进目录即可主机侧命令里的-d换成对应 URL。这种做法的额外好处是所有主机升级的是同一个文件、同一个 profile基线天然一致不用再逐台核对 SHA256。要注意的是主机访问 HTTP 源需要解析和路由都通先在最远端的主机上用esxcli network diag ping确认能到再跑profile list。反过来先跑升级命令再排查网络日志里只会给你一句Could not download from depot信息量很低。4. 升级前后的可回滚设计备份、维护模式和顺序升级这件事真正的风险不在命令本身而在「出问题之后能不能退回去」。ESXi 主机的回滚能力和虚拟机的快照完全不是一回事把两者混为一谈是很多人第一次升级失败后最想抽自己的地方。这一章讲三件事配置怎么备份、快照为什么救不了宿主机、以及多主机环境下的升级顺序。4.1 配置备份与恢复的实际命令ESXi 提供配置导出包含网络、存储、认证等设置导出的文件很小恢复起来也快属于必做项# 同步并导出配置文件会生成在 /downloads 下 vim-cmd hostsvc/firmware/sync_config vim-cmd hostsvc/firmware/backup_config # 把生成的文件挪到数据存储避免主机重启后丢失 ls -lh /downloads/ cp /downloads/configBundle-*.tgz /vmfs/volumes/datastore1/backup/sync_config先把运行时配置刷到持久存储不跑这一步直接backup_config导出的可能是几分钟前的旧状态。backup_config成功后终端会打印Downloading to /downloads/configBundle-xxx.tgz路径记下来然后立刻复制到数据存储或直接 scp 到外部机器——/downloads在部分版本里位于内存盘重启就没了这算个不大不小的坑。恢复用vim-cmd hostsvc/firmware/restore_config /vmfs/volumes/datastore1/backup/configBundle-xxx.tgz恢复过程会自动重启主机。注意恢复的是配置不是二进制版本——它救不了「升级后驱动丢失」只能救「配置文件被改乱了」。4.2 快照救不了宿主机回滚边界在哪虚拟机快照拍的是虚拟磁盘的状态宿主机的 VIB 层、内核、驱动完全不在快照范围内。升级 ESXi 之前给虚拟机上拍快照保护的是虚拟机数据不是主机系统。主机升坏了快照帮不上任何忙你面对的是重装系统再用 4.1 的配置包恢复网络和存储设置。真正的主机级回滚手段有三个按可靠性排序第一升级前记录完整esxcli software vib list输出出问题时可以按名单逐个补装被移除的 VIB第二保留上一版本的离线包理论上可以尝试回到旧 profile但 ESXi 对降级限制严格多数情况下会被拒绝不要把它当成常规手段第三重装加配置恢复这是最后一道也是实际最可靠的一道。把这三点想清楚再动手比事后找后悔药有用得多。维护模式也是回滚设计的一部分。进维护模式之前确认所有虚拟机已经迁走或关机vim-cmd hostsvc/maintenance_mode_get返回state true才算到位。带着运行中的虚拟机动升级命令esxcli会拒绝执行并提示主机不在维护模式这是它在保护你。4.3 多主机环境的升级顺序单机升级是技术问题多机升级是顺序问题。通用原则是先升集中管理端、再升被管主机因为高版本的管理端能管低版本主机反过来会有兼容告警。实际排期时按「管理端 → 测试主机 → 生产主机分批」推进每批之间留观察期。分批的时候有个细节容易被忽略同一集群内不要同时把多台主机置于维护模式升级容量不够会导致虚拟机无法迁移升级卡在迁移步骤上。按集群承载能力算一下一次动一台或两台剩下的容量能兜住全部虚拟机再开工。升级完成后主机退出维护模式检查三件事网卡是否全部 up、数据存储是否全部挂载、虚拟机能否正常开机。三件事都过了再动下一台别一口气全升完再统一验证——到那时候出问题你已经分不清是哪台哪个参数导致的。5. 排查手册五条踩坑记录从报错到根因/var/log/esxupdate.log是这套流程的黑匣子几乎所有失败都能在里面找到原因问题是日志信息偏底层需要对着现象翻译。下面五条是我自己踩过或者帮别人定位过的按「现象 → 原因 → 解决」写遇到对应情况可以直接对号入座。5.1 报 No space left on device现象esxcli software profile update刚跑几秒就退出日志末尾是No space left on device但数据存储明明还有几百 GB。原因包被传到了/tmp。ESXi 的/tmp是内存盘容量受主机内存限制通常只有几百兆。离线包动辄几百兆到 1 GB 以上解压阶段必然写爆。数据存储的空间和/tmp完全无关看df -h里的数据存储容量没有意义。解决把 zip 放到数据存储路径下-d直接指向/vmfs/volumes/datastore1/...。如果已经写爆先rm -rf /tmp/*清掉残留注意别删正在用的临时文件最好重启一次再重新执行。顺便看一眼df -h /tmp的可用空间比升级包大两三倍才保险。5.2 报 VIB 不兼容或主机不受支持现象干跑阶段直接失败日志里出现is not compatible with或主机不受支持的提示命令连写入都没开始。原因两种可能。一是 CPU 架构被目标版本移出支持列表较老的处理器在新版本上直接不予安装二是已有 VIB 与包内 VIB 存在版本或依赖冲突比如某个后装的驱动依赖旧版内核模块。解决先用esxcli hardware cpu list看处理器型号对照目标版本的硬件支持说明确认CPU 不支持的话没有绕路只能停在当前大版本。如果是 VIB 冲突从日志里抄出冲突的 VIB 名esxcli software vib remove -n 名称卸载后重试卸之前确认这个 VIB 不是网卡或存储控制器驱动。5.3 升级成功但重启后管理地址不通现象命令返回成功vmware -v也显示新 build 号重启后 ping 不通接显示器发现网卡列表是空的。原因原厂定制镜像里带的是异步网卡驱动标准 profile 不包含它升级过程中被当作「非标准 VIB」移除。CPU 和存储都可能中同样的问题只是网卡最先暴露。解决升级前导出esxcli software vib list把厂商前缀的驱动单独记一份。升级后用esxcli software vib install -d 原厂驱动包把驱动补回去或者直接改用厂商定制 profile 升级。已经失联的话只能接显示器用 DCUI 恢复网络或者走 4.1 的配置恢复。5.4 报 No matching profile found现象profile update立刻失败提示找不到匹配的 profile包明明是好的。原因-p后面的 profile 名和包里定义的不一致。手打容易把standard打成latest或者把 build 号里的某几位敲错也有的人把-p和-nVIB 名两个参数搞混了。解决跑esxcli software sources profile list -d 包路径把输出里的 profile 名整行复制过来别手打。如果输出为空说明包结构不对或者路径写错回到 2.2 用脚本确认顶层有没有metadata.zip。5.5 重启后又回到了旧版本现象升级过程无报错重启后vmware -v显示的 build 号还是旧的。原因主机从旧介质启动。多见于 U 盘安装的测试机或者多盘机器 BIOS 引导顺序在升级后被重置从备份盘或旧系统盘起了机。解决进 BIOS 确认启动顺序把装有新系统的盘提到第一位U 盘安装的机器直接拔掉 U 盘再重启。确认后重新跑一次vmware -v还不生效就去看/var/log/esxupdate.log里那次升级有没有真的写入日志显示成功但版本不变多半是引导介质问题。6. 把离线包做成可复用基线体检脚本与上线验证一个离线包只用一次是浪费。真正省事的状态是包里有什么、能不能装、装完该是什么样全部固化成脚本和清单下次换个 build 号直接跑。下面这套东西不复杂二十行脚本加四条验证命令但它能把你从「每次升级都像开盲盒」里拽出来。6.1 一个二十行的包体检脚本每次拿到新包先跑一遍输出存档跟变更单一起走审批#!/bin/bash # 用法: ./check_depot.sh 离线包路径 set -euo pipefail BUNDLE$1 echo 文件指纹 sha256sum $BUNDLE ls -lh $BUNDLE echo 顶层结构 unzip -l $BUNDLE | awk NR3 $4! {print $4} | head -20 echo 是否含 metadata unzip -l $BUNDLE | grep -q metadata.zip \ echo OK: depot 结构 \ || { echo FAIL: 不是 depot 包; exit 1; } echo 包内 VIB 数量 unzip -l $BUNDLE | grep -c vib20/.*\.vib || trueset -euo pipefail保证任何一步失败就停不会出现「校验没过但脚本继续跑完给了个假 OK」。第一个参数是包路径必须传绝对路径相对路径在set -u下如果变量拼错会直接退出。grep -q metadata.zip是最关键的判断——它区分「这是 depot 升级包」和「这是别的东西」比看文件名可靠得多。最后统计vib20/下的 VIB 数量和上一次的包对比数量骤降往往意味着这个包是增量小补丁而不是累积更新升级范围要重新评估。输出别只留在终端重定向到文件里跟变更单一起归档。半年后有人问「当时升的那个包里面到底有什么」这份输出就是答案。6.2 升级后必跑的四条验证命令升级成功不等于升级正确。重启后按顺序跑下面四条全部通过才算收工顺序命令期望结果1vmware -vbuild 号等于包名里的数字2esxcli network nic list所有物理网卡 up数量与升级前一致3esxcli storage core adapter list所有控制器 online数据存储全部可见4esxcli software vib list | wc -l与升级前记录的数量偏差在预期内第 1 条看版本第 2、3 条看驱动是不是被抹掉了第 4 条看整体 VIB 集合有没有意外变化——数量对得上但内容替换了也有可能所以更稳的做法是跟升级前导出的那份名单做diff。第 4 条如果数量明显减少基本可以判定异步驱动被移除回去看第 5.3 条。这套验证我做成了固定动作升级窗口结束前必须跑完跑不完就不算完成宁可多占十分钟窗口也不带着未知状态收工。有一次省了第 2 条第二天业务反馈某台机器链路聚合少了一条腿回头查才发现升级把副卡的驱动换成了通用版本性能掉了一半。从那以后我每次动主机都强制把这份清单从头到尾走一遍一条不落。希望帮到你。本文还有配套的精品资源点击获取