企业官网建设流程全解析

简介：面向VMware虚拟化运维与基础架构工程师的 ESXi 7.0.0 离线安装包，适合在无外网、网络受限的机房或企业内网中完成 vSphere Hypervisor 的初始安装、版本升级与组件补充，也可作为排查硬件驱动兼容性时的离线包来源。包体共75个文件，以72个VIB组件包为主体，覆盖网络、存储、NVMe、RAID等常见驱动以及VMware Tools、esx-update等核心模块，另含2个XML描述文件和1个ZIP离线元数据仓库，压缩后约344.44MB，可直接用于离线安装或仓库挂载。已有5612人学习下载。相比在线安装VMware PowerCLI、在线升级时容易出现的超时或依赖下载失败问题，该离线包提供了更稳妥的安装与补丁路径；也可配合ESXCLI软件仓库命令完成组件查看与注入，便于按硬件环境构建自定义ESXi镜像，适合需要反复部署多台主机的场景，对批量装机与标准化交付有实用价值。

1. VMware-ESXi-7.0.0.zip 到底是什么：不是普通压缩包，是给 ESXi 做升级和定制的“离线药包”

很多搞虚拟化运维的朋友第一次看到“VMware-ESXi-7.0.0.zip”，会习惯性地右键解压，想把它像 VMware Workstation Pro 那样双击装上。这是我在交流群里见过最多的一次误读。这个 zip 不是给 Windows 用的安装包，也不是一个能引导裸机的镜像文件，而是 VMware ESXi 7.0.0 的 offline bundle，官方叫“离线包”。它的正确用途是：把一台已经在跑 ESXi 的宿主机升级到 7.0.0，或者把它当原料，定制进网卡驱动、补丁、厂商 VIB，最后再导出成 ISO 装到新机器上。

如果你正在搜 vmware 虚拟机安装教程，目标是装一台能在 Windows 里跑的虚拟机，那应该找的是 VMware Workstation Pro 的 exe 安装包，不是这个 zip。如果你手里已经有一台 ESXi 宿主机，或者正准备在旧服务器上重装虚拟化平台，这个 zip 才是真正值得研究的文件。它能解决的核心问题很简单：不重装系统，把现有 ESXi 的软件集整体替换成 7.0.0，并且保留数据存储和配置。

2. 拆开 VMware-ESXi-7.0.0.zip：离线包结构和升级原理

2.1 为什么 VMware 用 zip 而不是 ISO 发布离线包

ESXi 的安装介质有两种形态：一是 ISO，适合裸机引导、交互式安装或无人值守脚本安装；二是这个 zip 形式的 offline bundle，适合给已经运行的 ESXi 做软件集的“整包替换”。这两种东西的工作方式完全不同，我见过不少新人在 ESXi 6.7 的 Web 管理界面上传了这个 zip，然后在虚拟机选项里翻来翻去，以为可以直接挂载光驱启动，这种用法从一开始就不对。

打开这个 zip，里面不是散落一地的安装文件，而是几个 VIB 包、一个 profiles 目录和一个 metadata.zip。VIB 是 VMware 的软件安装单元，类似 Linux 的 rpm 包；profiles 目录里放的是 image profile，也就是一组 VIB 的“组合套餐”。当你指定一个 profile 时，ESXi 会按照这个清单去检查依赖、签名和接受级别，然后把整个系统状态切过去。这样做的价值在于一致性：不会因为单独装了一个驱动，导致升级到某个补丁后内核模块互相冲突。

ESXi 启动时用两个系统分区：bootbank 和 altbootbank。当前跑的是 bootbank，另一个分区作为待写入区域。离线包升级的流程大致是：主机进入维护模式，关闭所有虚拟机，esxcli 把新的 VIB 写入 altbootbank，更新启动配置，重启后切换。如果新系统启动失败，还可以通过启动菜单回滚到旧版本。这个机制决定了 zip 离线包比直接在运行系统中覆盖文件安全得多，也是官方推荐用 profile install 而不是手动拷文件的原因。

2.2 用 unzip 和 esxcli 检查这个 zip 的真实状态

拿到 zip 后第一步不是传到生产环境，而是先在 Linux 工作站上校验。很多下载工具会“好心”把文件名改掉，或者有些网盘中转会把 zip 重新压缩过，导致 ESXi 无法解析。这里用到的就是标准的 linux 解压缩命令 zip 校验方式：

# 先校验压缩包完整性，损坏或改动过的 zip 在这里会直接报错 unzip -t VMware-ESXi-7.0.0.zip # 再看顶层目录结构，确认它是 offline bundle 而不是普通压缩档 unzip -l VMware-ESXi-7.0.0.zip

unzip -t会逐条读取压缩包内文件并做 CRC 校验，输出末尾出现No errors detected in compressed data of this file才算正常。如果报错，说明文件下载不完整或者被二次压缩过。这里我要多说一句：有人喜欢用加密工具给 zip 加密码，或者用“压缩为 zip”再包一层，结果就是 ESXi 软件仓直接解析失败。这种情况和 zip 伪加密类似，文件能解压，但元数据已经被改掉了，ESXi 不会认。

把 zip 传到 ESXi 主机的数据存储后，还需要确认它能不能被软件仓识别：

# -d 指定 depot 路径 esxcli software sources profile list -d /vmfs/volumes/datastore1/VMware-ESXi-7.0.0.zip

这个命令会列出 zip 里所有可用的 image profile，输出里会有 profile 名称、版本、厂商、接受级别。看到列表正常，说明离线包结构没问题。如果这条命令返回空列表或提示Depot is not valid，问题通常不在主机，而在 zip 文件本身，重新下载原文件比在主机上排查更省时间。

为什么要坚持用 profile 而不是单独装 VIB？因为 profile 打包好了整套系统的依赖关系。比如 ESXi 7.0.0 的standardprofile 会解决 vmware-esx-base、网络栈组件、存储驱动之间的兼容性问题。单独esxcli software vib install只适合临时加一个驱动，升级或重启后容易状态不一致，后面章节会单独讲怎么把驱动做成镜像。

3. 用 VMware-ESXi-7.0.0.zip 把版本从 6.x 升到 7.0.0：命令与参数说明

3.1 上传离线包到数据存储并让宿主机进入维护模式

实际操作中，我通常会先在 Web UI 的数据存储浏览器里上传 zip，路径一般是/vmfs/volumes/datastore1/。如果是在命令行环境，也可以用 scp：

# 从本机传到 ESXi 的数据存储，保留原始 zip 文件名 scp VMware-ESXi-7.0.0.zip root@esxi-host:/vmfs/volumes/datastore1/ # 上传后确认空间够不够，离线包一般在几百 MB 级别 df -h /vmfs/volumes/datastore1

升级期间要求所有虚拟机处于关机或迁移状态，所以先确认主机没有运行关键业务虚机，然后进入维护模式：

# 进入维护模式，ESXi 会拒绝再启动新的虚拟机 vim-cmd hostsvc/maintenance_mode_enter # 确认当前维护模式状态 vim-cmd hostsvc/host_summary | grep MaintenanceMode

如果主机在 vCenter 集群里，最好先把虚拟机迁移到其它宿主机，或者使用 vCenter 的进入维护模式功能，让 DRS 自动迁移。直接敲命令进入维护模式只影响单机，不会等集群做负载均衡，这点要自己判断。进入维护模式后，不能立刻开装，先跑一次 profile list，确保 zip 路径和 profile 名称都没有问题，这一步能省掉后面一半的报错。

3.2 执行 profile install 跨版本升级

确认主机已经在维护模式后，安装命令其实不长，核心是三步：指离线包、指 profile、执行 install。先列出 zip 里的 profile：

esxcli software sources profile list -d /vmfs/volumes/datastore1/VMware-ESXi-7.0.0.zip

输出的Name列就是安装参数，常见名称是ESXi-7.0.0-15843807-standard，不同 build 会有差异，务必以实际输出为准。然后执行升级：

esxcli software profile install \ -d /vmfs/volumes/datastore1/VMware-ESXi-7.0.0.zip \ -p ESXi-7.0.0-15843807-standard

这条命令的-d指定 depot 路径，-p指定 profile 名称。执行时 ESXi 会把新 profile 里定义的所有 VIB 与当前系统比对，缺失的安装、差异的替换、多余的如果被 profile 排除则标记移除。如果提示需要移除某些 VIB 但被拒绝，可以追加：

esxcli software profile install \ -d /vmfs/volumes/datastore1/VMware-ESXi-7.0.0.zip \ -p ESXi-7.0.0-15843807-standard \ --ok-to-remove

--ok-to-remove的含义是允许 esxcli 删除不包含在新 profile 中的旧 VIB。跨版本升级时经常遇到，尤其是老版本里的厂商定制组件被新 profile 抛弃的情况。除非你明确知道这个 VIB 还需要，否则不建议把--force当后悔药，强制安装会绕过依赖和接受级别校验，系统能起来但状态可能很脏。如果你是从 6.7 升上来，通常不需要--allow-downgrade，这个参数只在你想降级时才需要。

安装完成后，退出维护模式并重启：

vim-cmd hostsvc/maintenance_mode_exit reboot

重启过程会等约两三分钟，ESXi 7.0.0 首次启动可能比老版本慢，这是正常的。重启完成后用vmware -v看版本，确认 build 已经切到 7.0.0。如果重启后卡在紫色界面或反复重启，可以在启动菜单里选择旧版 bootbank 回滚，这也是离线包升级相对安全的原因。

4. 只有一个 zip 怎么装到裸机：转 ISO 和驱动定制两条落地路径

4.1 裸机安装和 VMware Workstation Pro 虚拟机安装：先转成 ISO

很多人拿到 VMware-ESXi-7.0.0.zip 后，是想把它装在一台还没任何系统的物理服务器上。ESXi 的 zip 离线包不能直接引导，因为引导 ISO 里有启动加载器、安装程序和一堆初始化驱动，而这些都不在这个 zip 里。正确做法是用 VMware PowerCLI 把它导出成可引导 ISO。

在一台安装了 VMware PowerCLI 的 Windows 机器上，管理员身份打开 PowerShell，执行：

Add-EsxSoftwareDepot -DepotUrl C:\offline\VMware-ESXi-7.0.0.zip Get-EsxImageProfile Export-EsxImageProfile -ProfileName "ESXi-7.0.0-15843807-standard" -ExportToIso -FilePath C:\ISO\ESXi-7.0.0.iso

Add-EsxSoftwareDepot的作用是把本地 zip 注册为软件仓库。Get-EsxImageProfile会列出所有可以导出的 profile。Export-EsxImageProfile -ExportToIso则会把 profile 对应的启动文件、VIB 包和安装器打包成 ISO。这样得到的 ISO 既可以用 Rufus 写进 U 盘做裸机安装，也可以挂载到 VMware Workstation Pro 里创建 ESXi 虚拟机。如果你之前搜过 vmware esxi 8.0 安装教程，会发现 8.0 离线包转 ISO 的命令和这个完全一样，只是 profile 名称不同。

这里有个细节：PowerCLI 的Export-EsxImageProfile会下载所有需要的组件，所以首次执行时最好保持网络畅通。本地 zip 里包含了全部 VIB，但生成 ISO 时仍然需要读取 metadata 并重新封装，这个过程比较吃内存，建议机器预留至少 4GB 空闲内存。

4.2 给 7.0.0 集成第三方网卡驱动或厂商 VIB

很多小服务器装 ESXi 7.0.0 会遇到网卡不识别的问题，比如板载 Realtek 网卡或老款 Intel 网卡不在原生驱动列表里。单独在已安装的系统里esxcli software vib install确实能装上，但以后升级 profile 时这个驱动很容易被覆盖，更牢固的做法是把驱动打进镜像。

我常用的流程是准备两个 zip：一个是 VMware-ESXi-7.0.0.zip，另一个是驱动厂商给的 offline bundle，然后一起注册到 PowerCLI：

Add-EsxSoftwareDepot -DepotUrl C:\offline\VMware-ESXi-7.0.0.zip Add-EsxSoftwareDepot -DepotUrl C:\offline\driver-offline.zip # 找到目标 profile $base = Get-EsxImageProfile -Name "ESXi-7.0.0-15843807-standard" # 克隆一个新 profile，避免改坏官方原始包 $custom = New-EsxImageProfile -CloneName "ESXi-7.0.0-custom" -Vendor "example-lab" -ProductLongName "ESXi 7.0.0 with custom driver" # 把驱动包加入自定义 profile Add-EsxSoftwarePackage -ImageProfile $custom -SoftwarePackage "net-community-driver" # 导出成可引导 ISO Export-EsxImageProfile -ImageProfile $custom -ExportToIso -FilePath C:\ISO\ESXi-7.0.0-custom.iso

命令里的net-community-driver只是一个占位名，实际使用时要先用Get-EsxSoftwarePackage | Where-Object {$_.Name -like "*realtek*"}之类的命令确认 VIB 名称。加驱动时最容易踩的坑是接受级别，官方 profile 默认可能是PartnerSupported，第三方社区驱动的接受级别是CommunitySupported，直接添加会报错。解决方法是新建 profile 后调整接受级别，或者只选择与基础 profile 接受级别兼容的驱动包。

如果你不想走 PowerCLI，临时方案也可以直接在 ESXi 主机上装 VIB：

esxcli software vib install -d /vmfs/volumes/datastore1/vib-package.zip -n net-community-driver

-d指定包含 VIB 的包，-n指定要安装的 VIB 名称。但请注意，这种方式安装的驱动在下次 profile 升级时大概率会被裁掉，而且本身也不推荐当成长期维护方式。线下装机我更倾向一开始就做自定义 ISO，后面不管装几台都是同一个镜像，省心很多。

5. 从下载到升级的避坑记录：5 个常见翻车现场

5.1 下载与校验阶段：Depot is not valid和空列表

现象：在 ESXi 主机上执行esxcli software sources profile list -d /vmfs/volumes/datastore1/VMware-ESXi-7.0.0.zip，返回Depot is not valid，或者列出的 profile 是空的。

原因：zip 文件被改过，最常见是下载工具改名、浏览器二次下载、网盘中转重新压缩，或者是有人用压缩软件给 zip 加了密码。ESXi 软件仓对 zip 的目录结构和压缩方式有严格校验，任何多余的外层包装都会导致解析失败。另一种可能是文件没下完，只是大小看起来差不多。

解决：回到原下载目录，用unzip -t校验一次，确认输出末尾没有错误。如果系统里只有 zip 压缩大师之类的工具，也不要习惯性重新压缩。我是直接用 Linux 的 unzip 命令校验，得到No errors detected后再上传，通常能避开这一类问题。还遇到过文件名被改成VMware-ESXi-7.0.0.zip.zip的情况，后缀多一层，ESXi 同样不认。

5.2 升级执行阶段：提示当前主机不在维护模式

现象：执行esxcli software profile install时报错，提示要求主机处于维护模式，但自己明明已经在 vCenter 界面上把主机设成了维护模式。

原因：vCenter 里的维护模式状态和主机本机的 esxcli 状态没有完全同步，或者原来进入维护模式后因为某些任务超时自动退出了。如果主机参加了 vSAN 集群，还会出现 vSAN 数据重新同步导致始终无法进入维护模式。

解决：在 ESXi Shell 里直接确认状态，不要只信 UI：

vim-cmd hostsvc/host_summary | grep MaintenanceMode

返回"miniMode" = false或者MaintenanceMode字段为空就说明没进去。此时重新执行vim-cmd hostsvc/maintenance_mode_enter，并确认所有虚拟机都已关机或迁移。单机环境只有一台虚拟机还开着也会导致无法进入维护模式。

5.3 跨版本升级报错：老系统版本不够

现象：从 ESXi 6.0 或 6.5 直接执行 7.0.0 zip 升级，报错内容包含Unsupported upgrade path或者提示 VIB 依赖无法满足。

原因：ESXi 跨大版本升级有路径前提，7.0.0 官方要求前置版本至少是 6.5 后期 build，最好升到 6.7 U3 再往上走。直接跨两个大版本，很多 VIB 的依赖和格式都不兼容。

解决：老老实实分两步。先下载一个 6.7 U3 的离线包，把主机升到 6.7 U3，稳定运行一段时间后再执行 VMware-ESXi-7.0.0.zip 的 profile install。这个坑我在帮朋友整一台老戴尔服务器时翻过一次，当时以为离线包能像游戏补丁一样任意跨版本，结果系统进入不断重启的循环，好在 altbootbank 回滚救回来了。

5.4 升级完成后网卡消失或管理 IP 不通

现象：升级到 7.0.0 成功，重启后vmware -v也显示新版本，但 SSH 连不上，Web UI 也打不开，机房现场接显示器发现网卡状态是 down。

原因：老版本里的网卡 VIB 在 profile install 过程中被移除了，或者新版本内核不再支持这个型号的网卡驱动。ESXi 7.0.0 对很多老网卡收紧了支持，比如部分 BCM 网卡和旧款 Realtek。

解决：如果还能进 ESXi Shell，先看网络状态：

esxcfg-nics -l

确认网卡是否被识别。如果列表里没有，说明驱动确实没进系统。这时候要回到 4.2 节的做法，用驱动离线包重新生成自定义 ISO，或者直接在 Shell 里临时装回驱动。装命令执行顺序有讲究：先装驱动，再vmkload_mod加载模块，最后esxcli network nic set把管理网卡重新绑定到 vSwitch。如果网络彻底不可用，就只能在控制台操作了。

5.5 把这个 zip 当成虚拟机镜像导入 PVE 或 Workstation

现象：有人下载了 VMware-ESXi-7.0.0.zip，然后去搜 esxi 导入到 pve 的教程，发现怎么都导不进，甚至把它直接解压后用 qemu 引导，报各种格式错误。

原因：目标文件不对。PVE 导入的是 VMware 虚机的 OVF/OVA 模板或磁盘镜像，不是 ESXi 宿主机本身的离线包。Workstation Pro 要跑 ESXi，同样需要的是 ESXi 安装 ISO，而不是这个 zip。

解决：先明确意图。想在 PVE 里开一台 ESXi 虚拟机，去下载 ESXi 的 ISO 并把它当系统盘安装；想把现有 VMware 虚拟机迁到 PVE，去找该虚拟机的 OVF 或 vmdk 文件，用 PVE 的导入向导操作。这个 zip 存在的意义是宿主机升级和镜像定制，不是拿来导入任何虚拟机平台的。

6. 升级后的三段验证法：用三条命令确认 7.0.0 真的跑稳

升级完别急着把业务虚拟机迁回来，先做三个层面的验证。第一是版本层，确认当前活跃 profile 和 build 号正确；第二是 VIB 层，确认关键驱动在升级后没有被意外替换；第三是硬件层，确认网卡和存储设备都被新内核识别。

# 第一段：确认 profile 和 build esxcli software profile get vmware -v # 第二段：确认关键 VIB 处于 active 状态 esxcli software vib list | grep -E "net-drivers|scsi-drivers|em driver" # 第三段：确认网卡和存储设备被内核接管 esxcfg-nics -l esxcli storage core device list

我自己的习惯是看完这三条命令后，再把虚拟机逐个开机，每开一台就观察一两分钟系统事件日志。如果发现某台虚机的 CPU 兼容性报错，检查 CPU 模式是否设置了 EVC。如果网卡工作正常但协商速率不对，去 vSwitch 安全策略里检查是否启用了混杂模式。这些看起来和升级无关的小事，往往比升级本身更耗时。

最后说一个我养成的习惯：升级前一定先把原版本的 profile 用esxcli software profile get > /tmp/old-profile.txt存一份，升级后 diff 一下。这样即使新系统看起来正常，也能一眼看出哪些 VIB 被换掉了。毕竟离线包升级只是切换了软件集合，硬件的兼容性边界才是真正需要人判断的部分。希望这些路径和坑能帮到你少走一段弯路。

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