企业官网建设流程全解析

简介：面向服务器虚拟化运维人员与VMware学习者的ESXi 7.0安装配置指南，聚焦裸金属hypervisor的部署全流程，帮助解决从零搭建vSphere虚拟化环境时遇到的介质制作、系统安装与网络配置难题。资源包含1个PDF文档，整体仅752KB，内容紧凑清晰，适合在安装现场用移动设备或打印稿随时对照。已有2661人学习，适用于初次接触ESXi的IT技术人员，也适合需要快速重装或升级服务器的运维者。文档详细介绍了镜像下载、Windows与macOS下引导盘刻录、U盘启动与存储选择，以及升级保留VMFS数据存储和全新安装覆盖磁盘的差异；管理员密码的字符复杂度要求、管理网络IP与网关配置、网卡顺序识别方法也均有图文步骤说明，可引导读者完成从物理服务器到可远程访问ESXi管理界面的完整过程，有效规避安装后的网络失联风险。

1. ESXi 7.0 到底解决什么问题：不是装个系统那么简单

服务器虚拟化这个方向，很多团队是带着情绪入场的：要么是机房里的老旧物理机堆到机柜承重告急，要么是某个关键业务一宕机就是全体加班。vSphere ESXi 7.0 的价值在于把你从「一台服务器一个业务」的取款机模式，换到「一台服务器跑十个业务」的资源池模式，顺手把高可用、负载均衡、模板发放这些运维动作标准化。它本质上是一层裸金属 hypervisor，安装后直接管理服务器内存、CPU、磁盘和网卡，上面的虚拟机互相隔离，下面不依赖任何宿主操作系统。

但这里有个反直觉的结论：真正难住团队的往往不是 ESXi 本身的安装——那个流程界面友好了很多年——而是安装前的硬件兼容判断、安装后的网络与存储规划。很多团队卡在「系统装上了，网卡驱动没了」「管理 IP 配上了，一改 vSwitch 整台主机失联」这种问题上。这篇文章就按一条完整落地路径来讲：选型怎么判断、部署怎么执行、配置怎么不踩坑、以及最终怎么验证这套虚拟化环境真的值得托付业务。适合正在做服务器整合、机房改造、或者打算从物理机迁移到虚拟化的一线运维和架构师，不适合只想随便装个虚拟机玩玩的场景。

2. 先想明白为什么是 7.0：架构变化与选型判断

2.1 7.0 的架构变化让旧的运维习惯要改

ESXi 7.0 相比 6.x 最显著的变化不在外表，而在内核和外围服务的整理。从 7.0 开始，VMware 彻底抛弃了旧版 vSphere Web Client 里基于 Flash 的界面，统一走 HTML5 的 vSphere Client。这不只是好看，而是意味着你在 6.x 时代背下来的 Flash 插件安装步骤、旧版客户端兼容性报错，全套作废。管理端只需要浏览器，这对现场运维是实打实的减负。

另一个关键变化在安全模型。7.0 把 TPM 2.0（可信平台模块）纳入了核心安全基线，支持 Secure Boot 和加密虚拟机。如果你的环境有等保要求，或者业务方要求虚拟机磁盘加密，7.0 的这套能力可以直接用，不需要额外引入第三方加密产品。但这只对 2016 年以后的服务器硬件友好，老平台缺 TPM 2.0 或者固件不支持嵌套虚拟化，装 7.0 会很吃力。

内核层面的变化也多。7.0 重构了 VMkernel 的调度器和内存管理，对大内存页的支持更激进。我习惯把它理解成：同样的 CPU 核数，7.0 跑高密度虚拟机时内存超分比例可以比 6.x 调得更大。而且 7.0 原生支持 NVMe over TCP，存储向全闪和远端 NVMe 演进时不用额外打驱动。

2.2 什么硬件适合装 7.0：兼容性判断优先于一切

选型排错第一课永远是查兼容性列表。ESXi 7.0 对硬件的挑剔程度比 6.x 高一个量级，尤其集中在网卡和存储控制器。我见过不少团队把 6.5 甚至 6.7 上运行良好的老服务器直接放 7.0 的镜像，结果安装器走到设备扫描阶段就报错。原因通常是网卡驱动没打进官方 ISO，或者 RAID 控制器的驱动在 7.0 里被移除了。

判断一台物理机能不能跑 7.0，我有一套固定的检查顺序：先看 CPU 是否支持 64 位 x86 和硬件虚拟化，再看网卡型号是否在驱动支持清单里，然后看 RAID 卡或直通卡型号，最后查该厂商服务器型号是否出现在兼容列表的服务器分类中。前三项都能过，最后一项即使没列名，多数情况下也能装，只是出了问题厂商不背书。下面是 7.0 时代我常用的判断表：

这里多说一句：如果你手头是 2015 到 2018 年之间的服务器，7.0 正好是甜点版本。再往后出的 8.0 对 CPU 指令集有更苛刻的要求，老至强 E5 v2/v3 那代很可能装完启动就 panic。而 6.x 已经进入生命周期末期，安全补丁越收越紧。所以对于既有硬件更新不上、又不想被老版本锁死的团队，7.0 是目前最务实的一代。

2.3 别急着升 8.0：哪些坑让我留在 7.0

8.0 出来以后，很多人问要不要直接跳。我的建议是：新采购硬件、且业务能接受更严格兼容限制的，可以直接上 8.0；但存量服务器或者对稳定性要求极高、不想频繁重启的环境，7.0 更稳。8.0 的 vCenter 和 ESXi 对内存和 CPU 指令集要求更高，尤其是老平台的 AVX 指令集缺失会导致 VMkernel 启动失败。这不是配置问题，是硬件物理能力不够。

另一个现实是驱动生态。部分厂商的网卡和存储驱动在 8.0 下长期停留在兼容模式，性能不如原生驱动，而 7.0 的驱动生态经过两三个 update 版本已经很成熟。企业环境里，稳定比新功能值钱，这个判断在虚拟化选型时尤其成立。

3. 从 U 盘到第一台主机：ESXi 7.0 安装全流程拆解

3.1 安装前要备齐的三样东西

安装 ESXi 之前，我会强迫自己确认三件事都在手边，缺一个都不开工。第一是官方 ISO 镜像，别用第三方改过的版本，改过的镜像有时候会塞进去一些你不知道的东西，虚拟化层被污染风险极高。第二是管理主机的网络规划——管理 IP、子网、网关、VLAN ID，最好写成一张纸贴服务器上，现场容易慌，尤其是一堆线插在机柜里分不清哪根是管理口的时候。第三是硬件兼容性列表查询结果，装到一半发现控制器不认，再回头查就晚了。

存储规划也要提前想。ESXi 安装盘要选一块至少 16 GB 的存储，但我强烈建议用独立的 SSD 装系统，不要把安装目标选在存放虚拟机磁盘的大容量 HDD 阵列上。系统盘和数据盘分离是虚拟化环境的基本卫生习惯。系统盘坏了只影响 hypervisor 本身，虚拟机磁盘在另一组存储上，恢复成本低很多。

3.2 安装步骤：每一步在做什么

安装流程本身不复杂，但我会把每个交互界面背后做了什么讲清楚，方便你出问题时知道去哪排查。用 U 盘启动服务器，进入引导界面后，安装器会加载 VMkernel 到内存。这一步如果卡住，多数是 BIOS 里没开 VT-x，或者 UEFI 和传统引导模式不对。

接着进入欢迎界面和相关许可协议界面，之后是磁盘选择。这是第一个容易翻车的地方：磁盘列表只显示当前系统识别到的控制器和硬盘。如果你能看到目标 SSD，直接选中；如果列表是空的或者只有 USB 盘，说明 RAID 控制器驱动没加载，后面避坑章节会专门讲。选择磁盘后，安装器并不会格式化整块盘，而是按需创建分区，我们不需要手动干预。随后设置 root 密码，这一步要注意密码策略：长度和复杂性不够，安装器会直接拒绝。最后确认安装并重启，重启后进入 DCUI 主界面，安装阶段就结束了。

提示：安装过程中按 F11 是接受协议，按其他功能键在有的品牌服务器上会触发 UEFI 启动菜单而不是 ESXi 的交互，别混淆。

3.3 初始化配置：管理 IP、DNS、SSH

重启完成后，DCUI 屏幕上会显示当前主机的默认管理地址（通常来自 DHCP）。企业环境不推荐依赖 DHCP，手动固定管理 IP 是第一步。按 F2 进入自定义配置界面，选择 Configure Management Network，这里可以设置 IPv4 地址、子网掩码、网关和 DNS。改完网络配置后建议重启管理网络，用 ping 网关的方式验证。

SSH 在 7.0 里默认是关闭的，需要去 DCUI 的 Troubleshooting Options 里启动。这个设计是为了安全，但也挡住了很多远程排查路径。我一般会在部署阶段就把 SSH 打开，等全部配置稳定后再关掉，只在需要维护窗口时临时开启。启动 SSH 后，可以用本机的 ssh 命令测试登录，注意第一次连会提示确认主机指纹，这是正常行为。

下面是我在一个干净环境里做初始化时的命令序列，作为基线记录。

# 查看当前管理网络配置 esxcli network ip interface ipv4 get # 手动配置管理接口 IP（vmk0 是默认管理口） esxcli network ip interface ipv4 set -i vmk0 -t static \ --ipv4 192.168.10.20 --netmask 255.255.255.0 --gateway 192.168.10.1 # 配置 DNS esxcli network ip dns server add --server=192.168.10.2 # 启用 SSH 服务并设置开机自启 vim-cmd hostsvc/enable_ssh # 测试管理网络连通性 vmkping -I vmk0 -c 4 192.168.10.1

这里解释一下参数：-i vmk0指定了管理内核端口，-t static表示静态地址，--gateway只在网关上配置一次，如果主机有多个 VLAN 网关时要小心，别配错。vmkping是 VMkernel 层的 ping，和我们常用的普通 ping 不一样，它走的完全是内核网络栈，更能反映管理口物理链路和上游交换机的连通情况。如果vmkping能通管理网关但普通 ping 不通，问题往往不在 ESXi，而在上方防火墙或路由策略。

3.4 让安装少走弯路的两个习惯

装完第一台之后，我通常不会直接往里创建虚拟机，而是先把这台主机加入到 vCenter 管理域里，再打一次补丁基线。原因是 ESXi 7.0 的早期 update 版本在网络性能上有已知问题，装完立刻打补丁能省去后面排查的功夫。但这个步骤对单机场景不是必选，如果你打算跑嵌套实验，先不装 vCenter 也能做基础验证。

另一个习惯是记下每台主机的 Service Tag 和 MAC 地址，写成表格贴机柜。虚拟化环境最大的痛点就是「主机失联了不知道是哪台」，物理标识清楚，能省下大量现场时间。

4. 网络、存储和 vCenter：让 ESXi 从玩具变成平台

4.1 标准交换机的边界：别把管理口玩丢

ESXi 网络的核心是虚拟交换机。7.0 里有标准交换机（vSwitch）和分布式交换机（vDS）两种，单机场景用标准交换机就够，多主机集群建议上 vDS，因为配置可以一次推给所有主机。标准交换机的逻辑不复杂：一个 vSwitch 可以有多个上行链路（物理网卡），一个上行链路可以被多个端口组共用，端口组上的 VLAN ID 决定了虚拟机流量走哪个 VLAN。

最容易出事故的操作是改管理网络的上行链路。管理口（vmk0）默认绑在 vSwitch0 上，vSwitch0 默认的上行链路是物理网卡 vmnic0。如果你想给管理口加冗余，把另一块网卡也加入 vSwitch0 的上行链路，操作本身没问题；但如果你先新建了一个 vSwitch1 并绑定了 vmnic1，然后把 vmnic0 从 vSwitch0 解绑，这个动作会导致管理口和所有依赖 vmk0 的服务瞬间断开。没有带外管理通道的话，你只能跑机房。

我处理这类操作有一个原则：永远先加后减。先增加新的上行链路，确认 vmkping 通了，再移除旧的链路。如果要改管理口 IP 或者 VLAN，先把新的网络配置配好且验证无误，再删除旧的。顺序反了，就要付出跑机房的代价。

下面的命令展示了如何给标准交换机增加上行链路：

# 查看当前 vSwitch 和上行链路绑定 esxcli network vswitch standard list # 将 vmnic1 加入 vSwitch0 的上行链路 esxcli network vswitch standard uplink add --vswitch-name=vSwitch0 \ --uplink-name=vmnic1 # 确认链路状态 esxcli network vswitch standard uplink list --vswitch-name=vSwitch0

uplink add这个命令只做绑定，不重启网络，所以相对安全。执行后敲一下esxcli network vswitch standard uplink list，就能看到两个网卡都处于 up 状态。此时就算 vmnic0 的物理线缆被拔掉，管理流量也能自动切到 vmnic1 上。这里有个进阶细节：ESXi 的负载均衡策略默认是「基于源端口 ID」的路由，意思是每个虚拟机固定走某一个上行链路，不是负载均衡叠加。如果想要真正的链路聚合，需要在物理交换机上做 LACP，并在 vSwitch 里设置对应的绑定策略，双方不匹配会造成流量黑洞。

4.2 存储规划：VMFS 6 与远端存储的取舍

ESXi 7.0 的本地存储文件系统是 VMFS 6，它把一块磁盘格式化后作为一个数据存储（datastore）来用。VMFS 6 最大的特点是支持更大容量（单卷上限到了 64 TB 级别）和更细粒度的锁机制，多台主机共享同一个数据存储时锁开销更低。这对集群场景友好，但在单机场景下其实感觉不到太多区别。

考虑到企业场景几乎不会只在一台主机上跑业务，我更推荐把远端存储作为虚拟机磁盘的主存放点。常见方案有 NFS、iSCSI 和光纤通道三种。NFS 部署成本最低，只要有一台文件服务器就能用，适合中小环境；iSCSI 走标准 TCP/IP 网络，性能比 NFS 好一些，但在万兆网络普及前高位延迟问题明显；FC 性能最好，但需要专用的光纤交换机，成本最高。我个人的分法是：跑数据库等高 IO 业务的虚拟机放本地 NVMe 或 FC 存储，普通应用服务放 NFS 或 iSCSI，利用存储层的性能差异做分级。

创建 VMFS 数据存储最常用的方式是在 vSphere Client 界面完成，也可以用命令行vmkfstools在本地 shell 里操作：

# 查看主机识别到的磁盘 esxcli storage core device list # 在指定设备上创建 VMFS 数据存储 vmkfstools -C vmfs6 -S datastore1_local /dev/disks/naa.6000c29e123456789abcdef # 查看数据存储信息 df -h | grep datastore

-C vmfs6指定文件系统类型为 VMFS 6，-S后面是数据存储的名字。注意naa.6...是设备的 WWN 标识，不是 Linux 里的 sda 那种短名，因为底层是 SCSI 协议，WWN 才是稳定的设备标识。一个常见坑是：有时候创建完了，df -h看不到数据存储容量，那是因为 vmkfstools 创建的 VMFS 卷挂在 /vmfs/volumes 下，df -h不显示挂载点。要看真实使用量，用df -h /vmfs/volumes/datastore1_local。

4.3 单机 ESXi 只是起点：vCenter 解锁完整能力

我见过不少团队把 ESXi 装好、能开虚拟机，就觉得虚拟化搞定了。但单台 ESXi 只能提供虚拟化最基础的能力：跑虚拟机、快照、导出 OVA。真正让这套环境产生业务价值的是 vCenter Server。装上 vCenter 之后，你才能做 vMotion（虚拟机跨主机热迁移）、HA（主机宕机自动重启虚拟机）、DRS（负载均衡自动调度）、模板和内容库（批量发放虚拟机）这些核心功能。

vCenter 在 7.0 时代有两种部署方式：一种是装成 Windows 服务，另一种是内置了 Photon OS 的 vCenter Server Appliance（VCSA），现在官方主推后者。VCSA 是部署在 ESXi 主机上的一台虚拟机，要在 Web 界面里输入目标 ESXi 的信息来完成部署。部署完成后再用浏览器访问 vCenter 的 5480 端口做配置，登入管理界面后添加 ESXi 主机。

这里有一个容易被忽略的点：vCenter 本身也是虚拟机，意味着你也需要在它身上做高可用。vCenter HA 功能在三台 ESXi 主机上各放一个 vCenter 副本，一旦主节点出问题自动切换。中小环境如果资源紧张，至少要用 vSphere 的虚拟机 HA 给 VCSA 做保护，否则 vCenter 挂了，整个管理面就断了。

5. 七夜谈避坑：ESXi 7.0 部署与上线的四个常见事故

5.1 事故一：安装界面显示没有可用磁盘

现象：安装步骤走到磁盘选择，列表里什么都没有，或者只看到一个 U 盘，服务器自带的 RAID 磁盘完全看不到。

原因：ESXi 7.0 安装 ISO 里没有目标 RAID 控制器的驱动。7.0 的驱动裁剪比 6.x 激进，很多老 LSI/Avago 控制器的驱动被移出了默认包。驱动器没有被识别，磁盘列表当然为空。

解决：先确认 RAID 控制器型号，然后找到对应厂商提供的 offline bundle 驱动包，用打包工具把驱动注入 ISO。常见做法是使用 VMware 官方的 PowerCLI 组件准备新镜像，或者找一台已经能联网的 ESXi 主机用esxcli software vib install命令临时安装驱动后，再作为安装源。注意驱动注入 ISO 要在干净系统上操作，避免混入其他版本杂物。装好后安装器就能看到磁盘了。

5.2 事故二：SSH 开着却连不上

现象：DCUI 里已经启用了 SSH，从笔记本 ssh 到管理 IP，连接超时或者提示拒绝。

原因：三层原因，按发生频率排。第一，管理网络配置改了但没重启管理网络，DHCP 分配的舊 IP 已经不在了；第二，ESXi 的防火墙默认规则里，SSH 服务虽然开了服务，但没放行对应端口，只有从 DCUI 的 Troubleshooting 里启用服务才能顺带录入防火墙，直接改配置文件不会放行；第三，上游交换机做了 ACL，隔离了管理网段。

解决：按顺序检查。在 DCUI 里确认当前管理 IP 是否正确，在笔记本上 ping 一下。能通但 ssh 拒绝，检查 DCUI 的 Troubleshooting Options 里 SSH 是否显示已启用。如果已经启用还不行，用esxcli network firewall ruleset set --ruleset-id=sshServer --allowed-all=true放行。都不行就去查上游交换机。

5.3 事故三：改完 vSwitch 之后管理 IP 失联

现象：在 vSphere Client 或命令里调整了 vSwitch 的端口组配置，点击确定的那一瞬间，ssh 断开，ping 管理 IP 不通，主机彻底失联。

原因：当前管理口绑定的端口组所在 vSwitch 上，你修改了上行链路或 VLAN 配置，导致管理口失去了可用的物理路径。常见于把管理口从 vSwitch0 摘除并绑到了新的 vSwitch 上，而新 vSwitch 还没有可用的上行链路，或者 VLAN ID 和物理交换机不匹配。

解决：没有带外管理（如服务器厂商的远程管理卡）的话，只能去机房接显示器键盘。用 DCUI 的 Network Restore Options 功能把网络配置恢复为出厂默认值，这个动作会把所有 vSwitch 配置清空，重新变回 vSwitch0 + 默认端口组。这也说明了一个铁律：高风险网络操作前，一定要确保有带外通道或者先备份配置文件。备份命令是vim-cmd hostsvc/export_vmbackup，把生成的配置文件放到安全位置。

5.4 事故四：CPU 不满足指令集导致启动 panic

现象：ESXi 安装成功，但重启进入 VMkernel 后屏幕出现紫色背景的 panic 错误，信息里能看到类似 unsupported CPU 或者指令集缺失的字样。

原因：ESXi 7.0 要求 CPU 支持某些现代指令集（比如 SMAP、SMEP 之类），老处理器如果物理不支持，VMkernel 直接拒绝运行。这个不是配置问题，是 CPU 功能不足。

解决：查服务器 CPU 型号，在官方兼容性列表里搜该型号，确认是否支持 7.0。如果确认支持但还 panic，检查 BIOS 是否开了虚拟化扩展和 EPT，部分品牌服务器出厂默认关闭。更新 BIOS 后多数能解决。如果 CPU 本身确实太老（比如 2013 年前后的嵌入式级别处理器），转型思路是换台服务器或者回退到 6.7，没有别的软件层办法。

5.5 事故五：数据存储格式化后空间看起来变小

现象：创建 VMFS 6 数据存储后，容量比磁盘标称值小一截，比如 1 TB 硬盘显示只有 930 GB 左右可用。

原因：这是正常的。硬盘厂商按 1000 进制算容量，操作系统按 1024 进制算，加上 VMFS 文件系统自身有一定的元数据开销。实际上不算事故，但第一次接触的人容易误以为数据存储创建出了问题。

解决：不需要解决。用df -h查看挂载目录下的具体空间，确认虚拟机能正常创建文件即可。如果空间跟预期差得离谱（比如只剩一半），再怀疑是不是创建时选了不正确的分区方式或者存储被另一份快照占用。

6. 验证环境健康度：一套我常用的 7.0 上线自检流程

环境装完、vCenter 接入、第一台虚拟机成功启动，这只是起点。我现在的习惯是再做一轮系统验证，把隐藏问题在业务接入前揪出来。

先做性能基线记录。登录 ESXi 的 shell，用esxcli hardware status查看系统健康状态，包含 CPU、内存、风扇、电压、温度，这一步能看到硬件层面的报警和传感器异常；再执行esxtop观察 CPU 和内存的实时占用，这是排查性能问题的核心命令，可以按c切换 CPU 视图，按m切内存视图。记录下空闲状态下的 CPU 占用率（通常会在 5% 以下）和内存占用，这份数据后面业务跑起来做对比很有用。

然后验证存储路径是冗余的：

# 确认多路径策略和活动路径状态 esxcli storage nmp path list # 确认所有数据存储健康 esxcli storage vmfs extent list

storage nmp path list输出里要看每个设备有多少条活动路径，以及路径状态是否为 active。如果只有一条路径，说明存储链路没有冗余，重要的数据库虚拟机别放这里。vmfs extent list确认数据存储对应的底层磁盘，避免出现两块同名数据存储导致路径混淆。

最后验证迁移能力。在 vCenter 里做一次 vMotion 测试：把一台测试虚拟机从主机 A 迁移到主机 B，再迁回来。vMotion 成功意味着网络配置、CPU 兼容性、存储格式都满足集群要求。这一步做一次，后面再扩主机就有底了。测试虚拟机建议用一台没有任何业务的空白虚拟机，别拿生产机器做首次迁移演练。

做完这一轮，我会把每台主机的序列号、管理 IP、存储 WWN、网卡固件版本整理成表格存档，这个习惯让我在后面集群扩容、更换硬件时能直接定位，不用再爬机房。ESXi 7.0 是一个稳定度极高的版本，但它不免疫配置错误。整个部署流程走完，你收获的不只是一台能跑虚拟机的服务器，而是一个有验证依据、有排查路径、有备份习惯的虚拟化基础。希望帮到你。

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