ESXi 7.0裸金属虚拟化安装、网络存储配置与避坑自检

简介：VMware-ESXi-7.0.0 离线安装包面向需要部署或研究 ESXi 7.0 的运维人员、虚拟化学习者与实验环境搭建者，提供离线安装与驱动组件补充所需的基础文件，适合单机实验、小型虚拟化测试及无外网条件下的安装准备。压缩包共 75 个文件，以 72 个 vib 驱动与模块包为主，覆盖网卡、存储控制器等组件；另含 2 个 xml 元数据文件和 1 个内层 zip，整体约 344.44MB，目录按组件归类，便于按需检索与核对。已有 5622 人学习或下载，说明其在 ESXi 7.0 离线部署场景中具有一定参考价值。读者可据此了解 ESXi 7.0 安装包的文件构成与组件清单，用于离线环境部署、驱动适配研究和实验复现；结合元数据信息，也能辅助排查驱动缺失、封装兼容性等问题，为虚拟化平台的搭建与维护提供资料支撑，并便于安装前核对文件。

1. 你在旧服务器上立的第一台裸金属 hypervisor

拿到 VMware-ESXi-7.0.0.zip 的人，大多不是要在机房铺一整套新集群，而是手边正好有一台退役服务器、一台工控机，或者一台内存插满的工作站，想在上面直接跑虚拟化，把几台测试虚机、几个内部服务塞进去。ESXi 7.0 就是这个场景里最省事的一层地基：它不做桌面，不带图形界面，装完只剩一个 IP、一个 Web 控制台和一堆命令行工具，剩下的全交给虚机。难的地方从来不是"装不上"，而是装完之后管理网卡选错、板载网卡不认、存储卡在 RAID 后面看不见，以及 7.0 这条版本线在授权和分区上给你埋的几道坎。下面按我实际装机的顺序，从硬件对齐一路拆到上线自检。

2. 从 ISO 到第一个管理 IP：三条装机路径的取舍

装机方式的选择其实比安装过程本身更影响后面三个月的稳定性。同样是拿那个 ISO，往 U 盘里一写、挂远程虚拟介质、走 PXE 批量推，三条路对应三种完全不同的使用场景，踩的坑也不一样。这一章先把硬件门槛对齐，再走一遍安装向导，最后落到首次开机的 DCUI 配置。

2.1 硬件清单先对齐，七项门槛逐条过

ESXi 7.0 对硬件的要求不玄学，但每一项踩中都是安装界面直接把你拦下来，连日志都不给你留。我把这些年装机前必看的几项整理成表，装之前花五分钟对一遍，比装到一半发现网卡不认要省事得多。

两个最容易被忽略的点。第一是引导设备容量，7.0 这条线把门槛提到了 32 GB，很多人翻出一个 16 GB 的老 U 盘写完镜像，装到选盘那一步才发现根本不给选，白折腾一遍。第二是网卡，消费级主板板载的 Realtek 网卡基本不在兼容列表里，表现是系统装完、DCUI 里网卡列表空空如也，只能重装并额外准备驱动 VIB。我一般的做法是装机前先确认板载网卡型号，主板上如果有 Intel 的 i210/i350 或者独立的服务器网卡，直接用那个；实在只有 Realtek，就提前把对应版本的驱动 VIB 准备好，装机流程不变，只是多一步封装。

还有一条是隐藏门槛：如果打算在这台 ESXi 里再跑 ESXi 做实验，CPU 必须开嵌套虚拟化，且外层虚机的虚拟网卡建议用 E1000e，VMXNET3 在部分版本组合下会出现链路状态异常。这不是 7.0 独有的问题，但在实验环境里出现频率很高。

2.2 启动盘制作与安装向导逐屏对照

制作启动盘没有太多花活，关键只有一点：用 DD 模式写入，不要用 ISO 解压模式。ISO 解压模式会把镜像里的文件铺到 U 盘的 FAT 分区上，丢掉引导记录，开机就是"No bootable device"。Windows 下用写盘工具选 DD 模式，Linux 下直接 dd，macOS 下用 balenaEtcher 一类工具也走原始写入。

# Linux/macOS 下确认 U 盘设备名，务必核对，写错盘会毁数据 lsblk -o NAME,SIZE,MODEL # 假设 U 盘是 /dev/sdb，用 dd 原始写入，bs=4M 兼顾速度与稳定 sudo dd if=VMware-ESXi-7.0.0.zip of=/dev/sdb bs=4M status=progress conv=fsync sync

if指向镜像文件，of指向整块设备而不是分区（/dev/sdb而不是/dev/sdb1），conv=fsync保证写完落盘再返回，避免拔盘拔早了导致引导区残缺。写完用lsblk再看一眼，U 盘上应该出现多个小分区而不是一个 FAT 分区，这是写对了的标志。

安装向导一共七屏左右，值得停下来看的只有三处。第一屏是选择安装目标盘，这里会列出所有被识别到的设备，注意看容量和 naa 标识，别把要做数据盘的那块选成系统盘。第二屏是键盘布局和 root 密码，密码必须满足复杂度，7.0 对弱密码是直接拒绝的。第三屏是确认写入，会明确提示"该磁盘将被分区并覆盖"，这一步之后就没有后悔药了。

安装完成后第一次重启，记得把 BIOS 引导顺序里的 U 盘项去掉或者拔掉 U 盘，否则又会从安装介质引导一次，看到"Press F11 to reboot"之类的提示会让人以为装失败了。引导模式上我倾向 UEFI：7.0 对 UEFI Secure Boot 的支持是完整的，后续打签名补丁不会因为引导模式卡住；Legacy 模式虽然也能装，但在一些新主板上会遇到安装完找不到引导项的情况，排查起来很费时间。

2.3 首次开机的 DCUI 配置与 SSH 打通

装完第一次进系统，屏幕上只有一个黄灰色的直接控制台界面（DCUI），显示主机版本和当前网络状态。这时候主机还没有可用的管理 IP，所有操作都得在物理屏幕前完成。按 F2 输入 root 密码进入配置菜单，路径是 Configure Management Network → IPv4 Configuration，选第三项设置静态地址。

管理地址建议在装机前就规划好，不要图省事用 DHCP。ESXi 的很多功能（证书、vCenter 注册、NTP）都依赖地址稳定，DHCP 续租换一个 IP，轻则 Web 控制台打不开，重则证书主体不匹配，后面要手工重签证书，得不偿失。同一层菜单里把 DNS 服务器和主机名一起设好，主机名用完全限定域名格式，比如esxi01.lab.local，反向解析最好也配上，不然加 vCenter 时会报警告。

配完 IPv4 还要在 DNS Configuration 里确认解析顺序，然后回上一层选 Test Management Network，用默认网关和 DNS 各 ping 一次，通了再退出。这个测试动作很便宜，但能立刻把 VLAN 划错、网线插错口、网关写错这三类问题挡住。

网络通了以后，去 Troubleshooting Options 里把 ESXi Shell 和 SSH 打开。生产环境我一般只在装机当天开、配完就关，实验环境可以长期开着。开完用同网段的机器连上去：

# 首次登录用 root，装完先确认版本与构建号 ssh root@192.168.10.20 vmware -v esxcli system version get # 确认管理网卡与链路状态，vmk0 是默认管理接口 esxcli network ip interface list esxcli network nic list

vmware -v输出形如VMware ESXi 7.0.0 build-xxxxxxxx，esxcli system version get会额外给出 Product、Version、Build、Update 四个字段，打补丁前后对比这四个值最直观。esxcli network nic list里的 Link Status 一栏必须是 Up，Speed 显示千兆或万兆；如果显示 Down，先查网线和交换机端口，再查 VLAN。命令行的好处是从这一步开始，后面的配置都可以写成脚本重复执行，不用再回到物理屏幕前按键。

3. 装完只是开始：vSwitch、VMkernel 与存储的 esxcli 落地

刚装完的 ESXi 只有一个 vSwitch0、一个 vmk0 管理接口，所有流量挤在一条路上。跑一两台测试虚机没问题，一旦上 iSCSI 存储或者做迁移，问题就全出来了。这一章讲清楚为什么要分开、怎么用命令分、分完怎么验证。

3.1 为什么要在装机当天就把流量分开

ESXi 的网络模型分三层：物理网卡（vmnic）、虚拟交换机（vSwitch）、端口组与 VMkernel 接口。虚机接端口组，主机服务（管理、迁移、存储、容错）接 VMkernel 接口。默认只有一个 vSwitch0 和 vmk0，意味着管理流量、虚机流量、存储流量共用一个上行链路和一个队列。

这条单链路在三种场景下会立刻翻车。其一是 iSCSI 或者 NFS 存储，存储流量是突发的大块 IO，和管理流量抢同一个上行口，表现是 Web 控制台转圈、虚机卡顿，但 CPU 和内存看着都不高，新手很容易往存储性能上找原因。其二是 vMotion，迁移时内存页成片复制，把管理链路打满，vCenter 那边会看到主机心跳超时。其三是网络策略，虚机需要混杂模式或者改 MAC 的场景（比如跑嵌套虚拟化、做网络实验），如果端口组挂在管理 vSwitch 上，安全策略要么不敢开、要么开了影响主机本身。

所以合理的做法是至少两个 vSwitch：vSwitch0 只留管理和虚机流量，vSwitch1 挂独立物理网卡，专门跑存储和迁移。有条件再给 iSCSI 单独一个 vSwitch，物理口分开。这不是过度设计，一台双口网卡的机器就能做到，成本只是多插一根网线。MTU 也要在这一步定下来，存储网络普遍用 9000 巨帧，从物理交换机到 vSwitch 到 VMkernel 三层必须一致，任何一层漏了都会出现"能 ping 通但吞吐上不去"的怪现象。

3.2 用 esxcli 建 vSwitch 与 VMkernel 的完整命令链

图形界面点几下也能建，但命令行的好处是可复制、可回滚、可写进装机脚本。下面这段是我在一台双口机器上的完整配置，第二块网卡vmnic1挂到新建的 vSwitch1，上面建两个端口组，分别给迁移和存储。

# 1. 新建 vSwitch1，把 vmnic1 挂上去，MTU 设为 9000 esxcli network vswitch standard add -v vSwitch1 esxcli network vswitch standard uplink add -u vmnic1 -v vSwitch1 esxcli network vswitch standard set -v vSwitch1 -m 9000 # 2. 建两个端口组，存储走 VLAN 100，迁移走 VLAN 200 esxcli network vswitch standard portgroup add -p PG-Storage -v vSwitch1 esxcli network vswitch standard portgroup set -p PG-Storage --vlan-id 100 esxcli network vswitch standard portgroup add -p PG-vMotion -v vSwitch1 esxcli network vswitch standard portgroup set -p PG-vMotion --vlan-id 200 # 3. 建 VMkernel 接口并打标签 esxcli network ip interface add -i vmk1 -p PG-Storage -M 9000 esxcli network ip interface ipv4 set -i vmk1 -t static -I 10.10.20.21 -N 255.255.255.0 esxcli network ip interface tag add -i vmk1 -t iSCSI esxcli network ip interface add -i vmk2 -p PG-vMotion -M 9000 esxcli network ip interface ipv4 set -i vmk2 -t static -I 10.10.30.21 -N 255.255.255.0 esxcli network ip interface tag add -i vmk2 -t VMotion esxcli network ip interface tag add -i vmk2 -t Provisioning

几条参数容易混。portgroup add里的-v指的是 vSwitch 名字，而portgroup set里的--vlan-id必须写全称，因为短参数-v在这个子命令里已经被占用了，混用会提示参数错误。interface add的-M是 MTU，建的时候就要给对，事后改需要先删再建。tag add的标签决定了哪些服务能走这个接口：VMotion让迁移服务识别它，Provisioning允许它承载克隆和快照流量，iSCSI绑定存储流量。标签没打对，图形界面里那个"允许"的勾选框就是灰的，你会以为是权限问题。

配完立刻验证三件事：接口状态、路由、巨帧连通性。

# 看 VMkernel 接口是否都是 Up esxcli network ip interface ipv4 get # 巨帧验证：8972 字节负载 + 禁止分片，通说明整条链路 MTU 9000 vmkping -I vmk1 -s 8972 -d 10.10.20.1 # 管理网络到存储网络的隔离验证，预期不通 vmkping -I vmk0 10.10.20.1

vmkping的-I指定从哪个 VMkernel 接口发出，-s是负载大小，8972 加上 ICMP 头部正好 9000，-d置不分片位。如果 8972 不通但 1472 通，说明链路上有设备 MTU 还停在 1500，去查物理交换机的端口配置和中间的路由设备。第三条命令验证隔离，如果管理网络能直接 ping 到存储网络，说明 VLAN 没生效或者两个端口组挂在了同一个 vSwitch 上，需要回头检查portgroup set那一步。

3.3 数据存储识别与 VMFS6 容量边界

存储这块，7.0 默认文件系统是 VMFS6，块大小 1 MB，单文件上限和 6.7 一致。新盘接上来第一件事是确认主机到底认到了什么设备，很多时候"盘不见了"其实是阵列卡把盘吞了。

# 看控制器和物理设备，先确认盘在不在 esxcli storage core adapter list esxcli storage core device list # 看已有文件系统和 VMFS 卷信息 esxcli storage filesystem list esxcli storage vmfs extent list # 新增设备后重新扫描，不用重启主机 esxcli storage core adapter rescan --all

adapter list列出所有被识别的存储控制器，如果阵列卡是做了 RAID 的，这里会显示成一块逻辑盘，没做单盘 RAID 的直通盘则可能一块都看不到。这是新手最容易卡住的地方：装完系统发现只有系统盘，以为驱动缺失，实际上是阵列卡没给每块盘建逻辑卷。处理方式进阵列卡管理界面给每块盘建一个单盘 RAID0，或者把控制器切到 HBA/JBOD 模式，再回来 rescan。

设备认到之后建 VMFS 卷：

# 用整块设备建 VMFS6 数据存储，标签和名称分开写 esxcli storage vmfs create -V VMFS_Datastore01 -l DATA01 -d naa.600508b1001c1234567890abcdef # 创建后确认卷状态和剩余容量 esxcli storage filesystem list

-V是卷标，-l是数据存储显示名，-d是设备标识，三者在图形界面里也能设，命令行适合批量。容量规划上有个经验值：VMFS6 上单个虚拟磁盘文件建议不超过 2 TB，超过之后快照和克隆操作的耗时增长很明显；备份软件对超大 VMDK 的处理也更容易出问题。如果确实有大容量需求，拆成多块盘或者用多个数据存储，比硬上一个 8 TB 的 VMDK 稳。

4. 授权、补丁与版本线：7.0 的规矩和升级代价

装好能跑，只是完成了前半程。ESXi 7.0 这条版本线有几条明确的规矩，关于授权能用什么、补丁怎么打、从 6.7 上来要注意什么，提前搞清楚能省下大量返工。

4.1 免费许可卡在哪几个功能

ESXi 装完默认是 60 天评估期，到期后虚机还能开，但配置改不了。输入免费许可密钥之后就进入 vSphere Hypervisor 模式，这个模式的功能边界得先弄清楚，别等架构设计完了才发现做不了。

免费许可的正向能力：单机跑虚机、本地存储、标准虚拟交换机、快照、克隆、Web 控制台管理，这些都不受限。核心限制在三个地方。一是单台虚机的 vCPU 上限是 8 个，主机本身有多少核都不管，只卡单虚机，跑数据库或者编译机的时候要算清楚。二是 vStorage API 只读，绝大多数商业备份软件需要写权限，免费版下用不了，只能退回到基于 SSH 或者快照的手工备份，或者选明确支持免费版的备份方案。三是没有 vMotion、HA、DRS，也不需要 vCenter 来做统一管理——单机场景本来就用不上，但如果你后面打算扩到两台做迁移，就得换授权。

查当前授权状态：

# 查看当前许可状态和到期时间 vim-cmd vimsvc/license --show # 查看主机 CPU 与内存总量，用于规划免费版下的虚机规格 esxcli hardware cpu global get esxcli hardware memory get

vim-cmd vimsvc/license --show输出里的 Product 字段能看出是 evaluation 还是 vSphere Hypervisor，ExpirationDate 对免费许可显示为 none。评估期和免费许可的区别在于评估期能解锁全部功能，所以合理的做法是评估期内把该测的功能测完，再切免费许可。

4.2 离线 depot 打补丁的正确姿势

7.0 的补丁以 depot 压缩包形式发布，一个 zip 里包含多个 profile。离线环境不能连外网，全程手工操作，流程是：上传 depot 到数据存储 → 列出 profile → dry-run → 正式升级 → 重启 → 验证版本。

# 1. 把 depot 上传到数据存储后，先列出里面有哪些 profile esxcli software sources profile list \ -d /vmfs/volumes/DATA01/updates/VMware-ESXi-7.0U3-depot.zip # 2. 干跑一次，只做依赖检查不落盘，最容易被跳过但最不该跳过 esxcli software profile update \ -d /vmfs/volumes/DATA01/updates/VMware-ESXi-7.0U3-depot.zip \ -p ESXi-7.0U3-standard --dry-run # 3. 确认无误后正式升级，过程约 10 到 20 分钟 esxcli software profile update \ -d /vmfs/volumes/DATA01/updates/VMware-ESXi-7.0U3-depot.zip \ -p ESXi-7.0U3-standard

-d指向 depot 包的绝对路径，路径里不能有空格；-p是 profile 名，一般选-standard那个，-no-tools版本不含 VMware Tools，除非你有明确理由否则别选。--dry-run这一步的价值在于它会提前把空间不足、VIB 冲突、依赖缺失全部报出来，正式执行时才失败的话，主机可能已经进了半升级状态，处理起来麻烦得多。

升级完成后必须重启，重启后核对：

# 三个值必须一致，profile 名要和 dry-run 时选的一致 esxcli system version get vmware -v # 检查有没有残留的第三方 VIB 影响后续升级 esxcli software vib list | grep -v VMware

第三条命令是关键。第三方 VIB（网卡驱动、监控代理、硬件厂商工具）在升级时经常成为拦路虎，报依赖冲突或者把 bootbank 撑爆。升级前把这些 VIB 记下来，升级后用同一份清单回装，比升级完发现网卡不认再回头查要快得多。

4.3 从 6.7 上来：bootbank 与第三方 VIB 的账要提前算

7.0 相比 6.7 在引导分区布局上有调整，直接表现是升级时容易卡在空间不足或者 bootbank 相关报错。这不是 7.0 的 bug，是分区容量和第三方 VIB 占用共同作用的结果。

处理顺序是：先清 VIB，再确认空间，最后升级。清 VIB 用esxcli software vib remove -n <vib名>，移除前确认这个 VIB 不是网卡或存储驱动，否则移除后主机直接失去网络或者丢盘。清完之后用esxcli storage filesystem list看 bootbank 所在分区的剩余空间，再用 depot 的--dry-run让升级程序自己判断够不够。如果 dry-run 明确报空间不足，就不要硬上，先考虑重装或者换引导设备。

另一个高频问题是降级。ESXi 不支持从 7.0 平滑降回 6.7，唯一的办法是重装。所以在动手升级之前，虚机配置文件和数据盘要单独留一份，系统盘怎么动都无所谓，数据盘上的 VMFS 卷不要碰。这条经验听起来像废话，但我在实验环境里见过不止一次有人升级失败后直接重装，结果把数据盘一起格式化了。

5. 避坑与排查：七条血泪记录

前面几章的流程照着走，大部分机器能一次装通。真正消耗时间的是那些装到一半、跑了一段时间才冒出来的问题。下面五条是我踩过或者帮人排查过的，按现象、原因、解决三段写，能对号入座最好。

5.1 装机阶段：引导、网卡与磁盘的三个坑

第一条：写盘成功但开机 "No bootable device"。U 盘在写盘工具里看着写完了，进度条走满，插到目标机上一引导就报找不到可引导设备。原因是写盘工具用了 ISO 解压模式，把镜像内的文件释放到 FAT 分区，引导记录没有写进去。解决方式是换 DD 模式重写，Linux 下直接用dd if=... of=/dev/sdb bs=4M conv=fsync；写完执行lsblk，U 盘上应该出现多个分区而不是单个 FAT 分区。如果 DD 模式写完仍然不引导，去 BIOS 里确认引导模式与介质匹配，UEFI 装的机器把 Legacy 关掉。

第二条：装完 DCUI 里没有任何网卡。系统装完，进 DCUI 的 Configure Management Network，网卡列表是空的，只能看到"Network Adapters"下面什么都没有。原因是板载网卡不在兼容列表内，最常见的是消费级主板上的 Realtek 芯片。确认方式是在安装界面按 Alt+F1 进 shell，用lspci -v看网卡型号，对照兼容列表。解决办法是准备对应版本的驱动 VIB，用esxcli software vib install -v /path/xxx.vib装上后重启。这里有个连锁风险：第三方网卡驱动在跨大版本升级时经常是新版本还没跟上，升级前务必确认驱动有对应版本，否则升级完成主机直接失联。

第三条：安装器看不到数据盘。机器上插了四块盘，安装器只显示一块。原因基本都在阵列卡：要么没建逻辑卷，要么建了但没初始化，要么控制器工作在需要专用驱动的模式。排查顺序是先看esxcli storage core adapter list确认控制器被识别，再进阵列卡管理界面看物理盘状态，给每块盘建单盘 RAID0 或者把控制器切成 HBA 模式，回到 shell 执行esxcli storage core adapter rescan --all再刷新安装界面。这一步不做，后面建 VMFS 卷的时候同样看不到盘。

5.2 运行阶段：失联、掉盘与时间漂移

第四条：改完网络配置，Web 控制台和 SSH 全断。在 DCUI 里改管理 IP，改完确认，页面刷新不出来，SSH 也连不上。原因是改地址的同时把网关或者 VLAN 改错了，主机本身还在正常运行，虚机也没停，只是管理面失联。这时候别急着重启，去物理屏幕前按 F2 进 DCUI，看当前生效的地址是多少，用 Test Management Network 逐个测网关和 DNS。如果 VLAN 改错了，DCUI 里没法改回带 VLAN 的配置，需要在同交换机的对应 VLAN 里找一台机器接上去改，或者临时把交换机端口改成 access 模式救回来，再重新配 trunk。这条的预防手段很简单：改管理网络之前先确认带外管理（iLO/iDRAC 一类）可用，没有带外就留一台同网段的机器待命。

第五条：跑了两三个月，主机突然紫屏，日志指向引导设备。主机运行中紫屏，屏幕上一堆寄存器信息，重启后能起来，过几天又来一次。原因是系统装在消费级 U 盘或者 SD 卡上，这类介质没有掉电保护，写入放大之后块损坏，写到关键区域就崩。ESXi 7.0 起对引导设备的容量要求提到 32 GB，但容量达标不代表介质合适，官方推荐的顺序是 NVMe/SATA DOM > SAS/SATA 盘 > 企业级 U 盘，消费级 U 盘和 SD 卡从来不在推荐列表里。解决方式是迁移引导设备：把当前配置备份出来，用安装介质重装到一块小容量 SSD 上，再恢复配置。迁移成本不高，但要在出事之前做，紫屏的时候才想起来就晚了。

第六条：虚机时间越跑越偏，证书报错、日志时间对不上。主机和虚机的时间差出几分钟，vCenter 注册时提示证书时间无效，或者日志里的事件顺序看着不对劲。原因是 ESXi 默认没有配 NTP，靠 BIOS 时钟走，主板电池老化或者时区设置有偏差就会漂。解决办法是配 NTP 并确认同步状态：

# 配置两个时间源并启用，然后重载服务 esxcli system ntp set --server=ntp1.lab.local --server=ntp2.lab.local --enabled=true esxcli system ntp get # 查看同步状态，remote 前面有星号表示已同步 ntpq -p

--server可以写多次，至少配两个源；--enabled=true是必须的，只填服务器不启用等于没配。ntpq -p输出里如果所有 remote 前面都是空格没有星号，检查 123 端口的出站策略和 DNS 解析。虚机侧还要在 VMware Tools 里勾选与主机同步，两层都做才彻底。

6. 上线前的一次自检：把十二条命令串成可复现的验收脚本

装完、配完、打完补丁，很多人就直接把业务虚机往里扔了。我吃过这个亏：一台机器装完看着一切正常，跑了两周才发现存储链路只有一条在工作，另一条因为交换机端口没配 trunk 一直闲着。从那以后我每次装完都强制走一遍自检，把所有"看着正常"的地方用命令核一遍。下面这段可以直接存成脚本在主机上跑，输出贴到工单里作为交付记录。

#!/bin/sh # ESXi 7.0 交付前自检，只读操作，可重复执行 echo "=== 版本 ==="; esxcli system version get echo "=== 硬件 ==="; esxcli hardware memory get; esxcli hardware cpu global get echo "=== 物理网卡 ==="; esxcli network nic list echo "=== 虚拟交换机 ==="; esxcli network vswitch standard list echo "=== VMkernel 与标签 ==="; esxcli network ip interface list; esxcli network ip interface tag get -i vmk1 echo "=== 存储适配器 ==="; esxcli storage core adapter list echo "=== 文件系统 ==="; esxcli storage filesystem list echo "=== 时间同步 ==="; esxcli system ntp get; ntpq -p echo "=== 防火墙规则 ==="; esxcli network firewall get echo "=== 已装 VIB ==="; esxcli software vib list | grep -v "^VMware" echo "=== 运行中虚机 ==="; esxcli vm process list

读输出的时候重点看四处。nic list里每块网卡的 Link Status 必须全是 Up，Speed 要对称，一条千兆一条万兆混插是常见误配。vswitch standard list里每个 vSwitch 的 MTU 要和挂在上面的 VMkernel 接口一致，uplink 数量要和物理接线对得上。filesystem list里数据存储的 Mounted 必须是 true，容量和预期一致。ntpq -p里至少有一个带星号的源。

脚本之外再补两个动作：用vmkping对每条存储链路做一次 8972 字节的巨帧测试，用esxcli network diag ping从每个 VMkernel 接口各 ping 一次网关。这两步能把"链路起来了但跑不通"的情况提前暴露。做完这些再去装虚机，心里才踏实。这套流程我从第一次被存储单链路坑过之后就一直保留，宁可多花二十分钟，也不想在业务跑起来之后收到半夜的告警。希望帮到你。

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