05-vSwitch 与网络配置

概述

前一篇完成了虚拟机生命周期管理，重点解决“虚拟机如何标准化交付、变更和退役”。到了生产环境，虚拟机能不能稳定运行，很大一部分取决于网络：端口组是否一致、VLAN 是否正确、上联是否冗余、VMkernel 服务是否隔离、vMotion 和存储网络是否被错误地混在管理网络里、分布式交换机变更是否有回退手段。

vSphere 网络最容易被低估。很多人把它理解成“给 VM 选一个网络标签”，但在 ESXi 主机里，这个标签背后至少包含四层关系：虚拟机网卡连接到端口组，端口组挂在标准交换机或分布式交换机上，交换机通过物理网卡上联到真实交换网络，VLAN、MTU、NIC Teaming、Failover、Security Policy 和流量整形共同决定数据包能不能按预期到达对端。

本文目标：

1. 建立 vSphere 虚拟网络的完整模型，区分标准交换机和分布式交换机的边界。
2. 完成标准 vSwitch、端口组、VLAN、上联和 VMkernel Adapter 的配置。
3. 设计适合中小型 vSphere 环境的管理、业务、vMotion、存储和备份网络分离方式。
4. 理解 NIC Teaming、Failover、MTU、Port Channel、IP Hash 和上游物理交换机之间的依赖。
5. 掌握从标准交换机迁移到分布式交换机的安全节奏，以及失联时的 CLI/DCUI 恢复方法。

本文默认环境延续前文：vCenter Server Appliance 8.0 Update 3 系列，ESXi 8.0 Update 3 系列，至少两台 ESXi 主机，每台主机至少 4 个物理上联；如果只有单台 ESXi 或只有 2 个上联，也可以完成标准交换机、端口组和 VMkernel 配置，但分布式交换机、vMotion、vSAN、iSCSI 多路径和生产级冗余需要按实际硬件收敛设计。

vSphere 网络的基础模型

vSphere 网络可以从两个视角理解：虚拟机流量和 VMkernel 服务流量。虚拟机流量来自 VM 的虚拟网卡，服务于业务系统访问；VMkernel 流量来自 ESXi 自身，服务于管理、vMotion、NFS、iSCSI、vSAN、Replication、NFC 备份、Provisioning 等平台能力。两者都通过虚拟交换机转发，但治理重点不同。

图中把虚拟机、VMkernel、虚拟交换机、物理网卡和上游交换机放在同一个边界里。后续所有配置步骤都围绕这几层关系展开。

标准交换机与分布式交换机

vSphere 支持两类虚拟交换机：

Broadcom 的知识库说明，标准交换机配置存在于每台 ESXi 主机上，管理员需要手工保证多台主机之间端口组名称、VLAN 和策略一致，否则 vMotion 等跨主机操作会出问题。分布式交换机则把配置集中在 vCenter，由 vCenter 将配置下发给加入该 vDS 的主机，虚拟机和 VMkernel 接口可以连接到 distributed port group。

这并不意味着所有环境都应该立刻迁移到 vDS。标准交换机的价值是简单、主机本地可控、License 和 vCenter 依赖更低；分布式交换机的价值是统一管理、多主机一致性、网络健康检查、LLDP、LACP、Port Mirroring、NetFlow、Private VLAN、Network I/O Control 等能力。小环境可以先用标准交换机把基础网络做稳；集群规模扩大、端口组增多、迁移频繁、网络策略需要统一时，再引入分布式交换机。

端口组不是普通标签

端口组是 vSphere 网络里最重要的抽象之一。虚拟机网卡连接的不是“VLAN 10”本身，而是一个端口组；端口组上定义 VLAN ID、安全策略、流量整形、NIC Teaming、Failover 和可见名称。VMkernel Adapter 也会挂在端口组上，并通过服务标签声明用途。

一个端口组至少要回答这些问题：

端口组命名建议清楚表达用途和 VLAN。例如：

PG-MGMT-VLAN10
PG-VM-PROD-VLAN20
PG-VM-TEST-VLAN30
PG-VMOTION-VLAN40
PG-NFS-VLAN50
PG-BACKUP-VLAN60

不要只命名为 Network 1、Production、业务网。这类名称在单主机实验中看起来没问题，一旦跨主机、跨机房、跨团队维护，就会让配置审查和故障排查变得困难。

VMkernel 网络与客户机网络要分清

虚拟机客户机网络服务业务系统；VMkernel 网络服务 ESXi 自身。两者不能混淆。比如一台虚拟机访问数据库失败，排查目标通常是虚拟机端口组、VLAN、客户机 IP、网关、防火墙和上游路由；而 ESXi 主机无法被 vCenter 管理，排查目标则是管理 VMkernel、管理端口组、主机路由、DNS、物理上联和 vCenter 可达性。

VMkernel Adapter 常见用途如下：

如果只有两块物理网卡，所有流量都要复用，这时更应明确 VLAN、Failover 和带宽优先级，而不是把所有端口组都放在同一个默认 vSwitch 上。复用不是问题，失去边界才是问题。

标准 vSwitch 配置 walkthrough

标准交换机适合作为入门和兜底配置。即使未来采用分布式交换机，也建议每个环境至少保留一条可控的管理网络恢复路径，尤其是机房远程运维、异地站点、只有少数上联的集群。

图中把从 VLAN 规划到连通验证的步骤串起来。实际变更时应按这个顺序推进，而不是先创建端口组再回头猜 VLAN 和上联。

1. 规划网络清单

先写清楚网络清单，不要直接进入 vSphere Client 点配置。一个中小型集群可以从下面的表开始：

这个表要和物理交换机配置一一对应。如果 ESXi 上配置了 VLAN 50，但上游 Trunk 没有放行 VLAN 50，VMkernel 再怎么配置也不通。如果 ESXi 配置了 MTU 9000，但物理交换机、存储接口或中间链路仍是 1500，结果可能是小包能通、大包异常、NFS/iSCSI 性能抖动或 vMotion 失败。

2. 查看当前网络状态

在 ESXi Shell 或 SSH 中先导出现状：

esxcfg-vswitch -l
esxcli network vswitch standard list
esxcli network ip interface list
esxcli network nic list
esxcli network ip route ipv4 list

这些命令用于确认当前有哪些标准交换机、端口组、VMkernel 接口、物理网卡链路和默认路由。任何可能影响管理网络的变更，都应先保存这组输出，必要时截图 vSphere Client 的网络配置。

建议将变更前基线写入工单：

主机：esxi01.lab.example.com
变更前管理 vmk：vmk0 / PG-MGMT-VLAN10 / 192.168.10.11
管理上联：vmnic0 active, vmnic1 standby
默认网关：192.168.10.1
待新增：vSwitch-Services, PG-VMOTION-VLAN40, PG-NFS-VLAN50
回退方式：保留 vmnic0/vmk0 管理链路不变；新增网络验证失败则删除新增对象

3. 创建标准交换机

如果要新增一个服务交换机：

esxcli network vswitch standard add --vswitch-name=vSwitch-Services
esxcli network vswitch standard uplink add --uplink-name=vmnic2 --vswitch-name=vSwitch-Services
esxcli network vswitch standard uplink add --uplink-name=vmnic3 --vswitch-name=vSwitch-Services

创建标准交换机时默认没有物理上联，需要显式添加 vmnic。添加前确认物理网卡状态：

esxcli network nic list

不要把已经承载管理网络的唯一上联直接移走。若只有两块网卡，建议先在维护窗口完成物理交换机端口确认，再按“一次只移动一个非关键上联”的方式推进。

如果需要 Jumbo Frame：

esxcli network vswitch standard set -m 9000 -v vSwitch-Services

MTU 9000 不是越大越好，必须从 ESXi vSwitch、VMkernel Adapter、物理交换机端口、上游链路、存储控制器或对端服务器全链路一致。存储和 vMotion 网络可以使用 9000，但不要为了追求“专业感”在管理网络上随意启用。

4. 创建虚拟机端口组并设置 VLAN

为生产 VM 网络创建端口组：

esxcli network vswitch standard portgroup add \
  --portgroup-name=PG-VM-PROD-VLAN20 \
  --vswitch-name=vSwitch-Services

esxcli network vswitch standard portgroup set \
  --portgroup-name=PG-VM-PROD-VLAN20 \
  --vlan-id=20

测试网络同理：

esxcli network vswitch standard portgroup add \
  --portgroup-name=PG-VM-TEST-VLAN30 \
  --vswitch-name=vSwitch-Services

esxcli network vswitch standard portgroup set \
  --portgroup-name=PG-VM-TEST-VLAN30 \
  --vlan-id=30

VLAN ID 的常见含义：

普通业务 VM 不建议使用 4095。它会把 VLAN 边界推给客户机或虚拟网络设备，排查复杂度明显增加。除非是在虚拟防火墙、NSX Edge、路由器或网络实验场景，否则按端口组划分 VLAN 更可控。

5. 创建 VMkernel Adapter

为 vMotion 创建 VMkernel：

esxcli network vswitch standard portgroup add \
  --portgroup-name=PG-VMOTION-VLAN40 \
  --vswitch-name=vSwitch-Services

esxcli network vswitch standard portgroup set \
  --portgroup-name=PG-VMOTION-VLAN40 \
  --vlan-id=40

esxcli network ip interface add \
  --interface-name=vmk1 \
  --portgroup-name=PG-VMOTION-VLAN40

esxcli network ip interface ipv4 set \
  --interface-name=vmk1 \
  --ipv4=192.168.40.11 \
  --netmask=255.255.255.0 \
  --type=static

Broadcom KB 列出的 VMkernel 服务标签包括 Management、VMotion、faultToleranceLogging、vSphereReplication、vSphereReplicationNFC、vSphereProvisioning、VSAN、VSANWitness、vSphereBackupNFC、PrecisionTimeProtocol、NVMeTCP、NVMeRDMA 等。CLI 可以为 VMkernel 接口添加服务标签：

esxcli network ip interface tag add \
  --interface-name=vmk1 \
  --tagname=VMotion

查看 VMkernel 服务标签：

esxcli network ip interface tag get --interface-name=vmk1

如果通过 vSphere Client 操作，路径通常是：选择 ESXi 主机，进入 Configure，展开 Networking，在 VMkernel adapters 或 Virtual switches 中添加 VMkernel Adapter，并选择对应服务。不同版本 UI 文案可能略有差异，生产操作以当前 vSphere Client 页面为准。

6. 配置上联策略

标准交换机和端口组都可以设置 Failover Policy。先查看当前策略：

esxcli network vswitch standard policy failover get -v vSwitch-Services

设置 vSwitch 级别 active/standby：

esxcli network vswitch standard policy failover set \
  -a vmnic2 \
  -s vmnic3 \
  -v vSwitch-Services

设置端口组级别覆盖：

esxcli network vswitch standard portgroup policy failover set \
  -p PG-VMOTION-VLAN40 \
  -a vmnic2 \
  -s vmnic3

逗号分隔多个上联时不要加空格，例如 -a vmnic2,vmnic3。如果配置写成带空格的字符串，命令可能解析失败或结果不符合预期。

NIC Teaming 与上游交换机的关系

vSphere 上联策略不能脱离物理交换机讨论。ESXi 里把两个 vmnic 设为 active，不代表上游就能随便接到任意两个端口；上游是否是独立 Access/Trunk、是否加入 Port Channel、是否启用 LACP、VLAN 允许列表是否一致，都会影响结果。

这张图对比了主备、双活、IP Hash 和分布式交换机负载感知几种常见策略。核心判断点不是“哪种最高级”，而是上游物理链路是否匹配。

Route based on originating virtual port

这是常见默认策略。ESXi 根据虚拟端口选择一个上联，虚拟机或 VMkernel 在正常情况下固定走某个上联；上联故障时切换到其他可用上联。它不要求上游 Port Channel，适合绝大多数标准交换机配置。

优点：

1. 配置简单。
2. 物理交换机端口可以独立配置。
3. 不容易因为链路聚合不匹配导致环路或黑洞。

限制：

1. 单个虚拟网卡不会同时利用多个上联。
2. 负载均衡粒度较粗。
3. 多主机多端口组场景需要人为规划流量分布。

Active/Standby

管理网络、存储网络或关键 VMkernel 网络经常使用 Active/Standby。它牺牲一部分带宽，换取更清晰的故障边界。例如管理网络使用 vmnic0 active、vmnic1 standby；vMotion 使用 vmnic2 active、vmnic3 standby；NFS 使用 vmnic3 active、vmnic2 standby。这样两个服务可以在正常情况下分摊不同上联，故障时互相兜底。

Route based on IP hash

IP Hash 只有在上游物理交换机将 ESXi 对应物理端口配置成同一个 Port Channel 时才应使用。Broadcom KB 也强调，如果物理 NIC 面向 ESXi 的链路在 Port Channel 中，使用这些 NIC 的端口组需要将负载均衡策略设置为 Route Based on IP Hash；如果只是临时把其中一块 NIC 移到标准交换机，也可以从物理交换机 Port Channel 中移除该端口。

常见错误是：ESXi 设置 IP Hash，但物理交换机端口仍是普通独立 Trunk；或者物理交换机配置了聚合，但 ESXi 仍使用默认基于虚拟端口的策略。这两种不匹配都可能造成 MAC 学习混乱、单向不通、间歇丢包或 VM 迁移后异常。

分布式交换机的 Load-Based Teaming

分布式交换机提供更多能力，其中包括基于物理 NIC 负载的策略、集中端口组配置、LLDP、LACP、Port Mirroring 和 Network I/O Control 等。对于多主机集群，vDS 的价值在于减少“每台 ESXi 配一遍”的漂移风险。

但 vDS 并不会自动修好物理网络。物理交换机的 VLAN、MTU、Port Channel、LLDP、QoS 和端口安全策略仍然必须一致。vDS 只是把 vSphere 侧配置集中化，不是让网络基础设计消失。

VMkernel 服务网络分离

VMkernel 网络分离的目标是让不同平台服务有清晰边界：管理流量保持可达，vMotion 有足够带宽，存储流量稳定低延迟，备份流量不压垮管理网，vSAN 或 NVMe/TCP 这类关键路径按官方设计单独规划。

图中把管理、vMotion、存储、vSAN 和备份放到不同服务通道中。实际环境可以复用物理链路，但不应丢掉 VLAN、端口组和上联策略边界。

管理网络

管理网络承载 vCenter 到 ESXi 的管理通信、vSphere Client/Host Client、SSH、HA 管理心跳等。它的第一优先级是稳定，不是吞吐最大。建议：

1. 管理 VMkernel 使用独立 VLAN。
2. 至少两个上联，Active/Standby 或可解释的 Active/Active。
3. 不与高吞吐备份、vMotion、存储复制混跑在无控制策略的同一网络。
4. 变更管理网络前必须确认 DCUI、带外管理卡、机房远程控制或现场人员可用。
5. 任何管理网络 VLAN、MTU、上联策略变更都放入维护窗口。

vMotion 网络

vMotion 会迁移虚拟机内存状态，吞吐需求高，且可能在维护窗口内集中发生。建议：

1. 使用独立 VLAN 和独立 VMkernel Adapter。
2. 多主机之间端口组名称、VLAN、MTU、IP 网段保持一致。
3. 如果启用多 NIC vMotion，按官方设计为多个 VMkernel 设置相应服务并规划上联分布。
4. vMotion 网络一般不需要默认网关，跨三层 vMotion 另行设计。
5. 高负载环境中避免 vMotion 与存储网络争抢同一单链路。

验证 vMotion VMkernel：

vmkping -I vmk1 192.168.40.12

如果使用 Jumbo Frame：

vmkping -I vmk1 -s 8972 -d 192.168.40.12

-s 8972 -d 的含义是发送不分片的大包，用于验证 9000 MTU 链路是否端到端可用。不同 ESXi 版本命令选项可能略有差异，实际以主机 vmkping --help 为准。

NFS/iSCSI/NVMe over TCP 存储网络

存储网络对稳定性更敏感。配置 NFS、iSCSI 或 NVMe/TCP 前，要先确认存储阵列、物理交换机、ESXi VMkernel、MTU 和路径策略都一致。

存储网络建议：

1. 使用独立 VLAN。
2. 存储 VMkernel 与业务 VM 网络分离。
3. MTU 如果使用 9000，必须端到端验证。
4. iSCSI 多路径不要只靠 NIC Teaming，应按 iSCSI 端口绑定和多路径设计。
5. 存储网络不要随意通过默认网关跨复杂三层路径。
6. 对存储端口启用合适的物理交换机特性时，要按存储厂商和 VMware 指南确认。

验证 NFS/iSCSI 对端连通性：

vmkping -I vmk2 192.168.50.100

查看 VMkernel 路由：

esxcli network ip route ipv4 list

如果某个 VMkernel 配置静态地址时误填或漏填网关，Broadcom KB 提醒没有网关 IP 时可能被重置为 0.0.0.0，需要重新设置后才能恢复对应通信。通常同网段 VMkernel 不需要默认网关，但跨网段服务必须有明确路由设计。

备份与 NFC 网络

备份系统如果通过 vCenter/ESXi 管理网络读取虚拟磁盘，可能在备份窗口内给管理网络造成压力。中小环境可以先从监控管理网络带宽开始；当备份吞吐明显影响 vCenter、ESXi 管理或业务性能时，应考虑独立备份网络、代理部署位置、HotAdd、SAN 模式或备份专用 VMkernel 标签。

备份网络不要只看“能不能备份成功”，还要看恢复演练。很多网络配置在备份阶段能跑，恢复到隔离网络、跨主机恢复、即时恢复或大规模恢复时才暴露问题。

分布式交换机的引入节奏

当集群超过两三台主机、端口组数量增加、VM 频繁跨主机迁移时，标准交换机的主要成本是漂移：同名端口组在 A 主机是 VLAN 20，在 B 主机是 VLAN 200；某台主机上联策略忘记改；某台主机 MTU 没同步；某个测试网络只在一台主机上存在，vMotion 后 VM 掉线。

vDS 的引入可以解决这类一致性问题。建议按以下顺序推进：

1. 盘点所有主机标准交换机、端口组、VLAN、上联、VMkernel。
2. 在 vCenter 中创建 vDS，选择与 ESXi 版本兼容的 Distributed Switch 版本。
3. 创建 distributed port group，先只承载非关键 VM 网络。
4. 将一台非关键主机加入 vDS，先迁移一块非管理上联。
5. 迁移测试 VM 网络，验证 VLAN、网关、跨主机 vMotion。
6. 迁移 vMotion、备份等服务网络。
7. 最后再评估是否迁移管理网络和存储网络。

Broadcom 的 VDS 版本说明显示，Distributed Switch 8.0.0 兼容 ESXi 8.0.0 及之后版本，8.0.3 兼容 ESX/ESXi 8.0.3 及之后版本，并引入与网络卸载相关的增强。生产升级时不要只升级 vCenter/ESXi，还要检查 VDS 版本、主机兼容性、vDS 告警和配置同步状态。

迁移管理网络要保守

管理 VMkernel 放在 vDS 上是可行的，但风险边界更高。Broadcom 关于 vSphere 7.0 及之后版本网络回退和恢复的 KB 指出，如果 VDS 环境中管理端口组配置错误，可能导致多台主机与 vCenter 断开；vCenter 无法连接主机时，也无法集中下发修复配置。恢复方式可能需要逐台进入 DCUI，把管理网络恢复到可用状态。

如果主机物理网卡数量允许，一个保守设计是：管理网络保留在标准交换机，其他 VM、vMotion、备份和部分存储网络使用分布式交换机。KB 中也提到，在不受物理网卡数量限制时，可以让管理网络使用 VSS，其他虚拟基础设施和虚拟机流量使用 VDS；这类部署至少需要足够的物理网卡支撑冗余。

在只有 2 个上联的小环境里，不一定能把管理和业务物理隔离。此时更现实的策略是：

1. 保留 DCUI/带外管理可用。
2. vDS 变更前导出配置。
3. 先迁移一台主机和非关键网络。
4. 每次只迁移一个 VMkernel 或一个端口组。
5. 不在无人值守窗口批量迁移所有主机管理网络。

迁移前导出与回退

迁移到 vDS 前，至少准备三类回退材料：

esxcfg-vswitch -l
esxcfg-vmknic -l
esxcli network ip interface list
esxcli network nic list
esxcli network ip route ipv4 list

同时在 vSphere Client 中导出分布式交换机配置。对于涉及管理网络的迁移，确认 DCUI 可访问，确认物理交换机侧 VLAN 和 Port Channel 已准备，确认至少一条管理链路没有被同时变更。

Broadcom 的 vDS 到 vSS CLI 迁移 KB 给出了一个典型恢复思路：记录 VMkernel IP，查看 vSwitch 配置，从 DVS 中移除一块上联，用该上联创建标准交换机，创建同配置端口组，重新创建 VMkernel 并设置 IP/VLAN，再恢复主机连接。这个路径不是日常操作的首选，但它解释了为什么变更前必须知道 vmnic、dvPort、vmk、VLAN 和网关。

安全策略与常见特殊场景

端口组安全策略经常被忽略。标准端口组和分布式端口组通常都有以下策略：

普通业务 VM 应保持默认拒绝。需要放开的场景通常包括嵌套虚拟化、虚拟防火墙、虚拟路由器、负载均衡器、某些集群浮动 MAC、网络抓包或 IDS/IPS 镜像。即使需要放开，也应只在专用端口组放开，不要在全局生产 VM 网络放开。

虚拟防火墙或路由器

虚拟防火墙经常需要多个端口组，甚至需要 VLAN Trunking。建议：

1. 为虚拟防火墙单独建立端口组。
2. 如果使用 VLAN 4095，让客户机明确处理 VLAN 子接口。
3. 不要让普通业务 VM 接入 Trunk 端口组。
4. 安全策略按厂商要求放开，但只限专用端口组。
5. 变更前准备旁路和回退路径，避免虚拟防火墙策略错误导致整个虚拟化网络不可达。

嵌套虚拟化

在 ESXi 上跑嵌套 ESXi、实验 Kubernetes、虚拟网络设备或多层虚拟化时，可能需要 Promiscuous Mode、Forged Transmits 或 MAC Address Changes。生产环境应将这类实验放在隔离网络中，不要与真实业务端口组混用。

物理交换机端口策略

上游物理交换机至少要对齐：

1. Access/Trunk 模式。
2. VLAN 允许列表。
3. Native VLAN。
4. MTU。
5. Port Channel/LACP。
6. STP 边缘端口策略。
7. LLDP/CDP 可见性。
8. 端口安全和 MAC 限制。

很多 vSphere 网络故障最终不在 ESXi，而在上游物理交换机：VLAN 没放行、Trunk Native VLAN 不一致、Port Channel 一端配置了另一端没配、MTU 只改了 ESXi、端口安全限制了 MAC 数量、交换机模板把某个端口改回 Access。

连通性验证

网络配置完成后，不要只看 vSphere Client 里对象存在。至少做四层验证：主机侧配置、VMkernel 连通、虚拟机连通、跨主机迁移。

主机侧配置验证

esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network ip interface list
esxcli network ip interface tag get --interface-name=vmk1
esxcli network nic list

检查点：

1. vSwitch 是否存在。
2. 端口组 VLAN 是否正确。
3. VMkernel IP、掩码和服务标签是否正确。
4. 物理 NIC 是否 Link Up。
5. Active/Standby 是否符合规划。

VMkernel 连通验证

管理网络：

vmkping -I vmk0 192.168.10.1
vmkping -I vmk0 192.168.10.20

vMotion：

vmkping -I vmk1 192.168.40.12

存储：

vmkping -I vmk2 192.168.50.100

Jumbo Frame：

vmkping -I vmk2 -s 8972 -d 192.168.50.100

如果普通 ping 通而 Jumbo 不通，不要继续挂载 NFS 或配置 iSCSI 多路径，应先修 MTU。否则后续表现可能是性能差、任务超时、迁移失败，而不是立即报“网络不通”。

虚拟机连通验证

部署一台测试 VM，连接到 PG-VM-PROD-VLAN20，在客户机内检查：

ip addr
ip route
ping <default-gateway>
ping <same-vlan-test-vm>
ping <dns-server>

Windows 可用：

ipconfig /all
Test-NetConnection <default-gateway>
Test-NetConnection <dns-server> -Port 53

验证顺序是：同端口组同主机 VM、同 VLAN 跨主机 VM、网关、DNS、业务对端。不要一开始就 ping 互联网地址，否则无法区分是端口组问题、VLAN 问题、路由问题还是出口策略问题。

vMotion 验证

选择一台非关键测试 VM，执行跨主机迁移。迁移前确认：

1. 源主机和目标主机有同名或同一 distributed port group。
2. VM 所在端口组在目标主机存在且 VLAN 一致。
3. vMotion VMkernel 互通。
4. CPU 兼容性、存储可达性、DRS/HA 状态正常。

迁移后在客户机里持续 ping 网关和业务对端，观察是否丢包过多或迁移后完全失联。若迁移后失联，优先检查目标主机同名端口组 VLAN 和上游 Trunk 允许列表。

变更验收记录

网络变更完成后，建议保留一份可追溯的验收记录。它不需要很复杂，但必须能回答“改了什么、在哪里验证、失败时怎么回退、谁确认业务恢复”。一个可复用模板如下：

这份记录的价值在后续排障时会非常明显。比如三个月后某个 VLAN 迁移后异常，运维人员可以快速判断当时是标准交换机还是分布式交换机、端口组是否做过覆盖策略、物理 Trunk 是否同步调整过、是否曾经为了临时恢复把某个 vmnic 从 Port Channel 中移出。没有验收记录时，很多网络故障会退化成凭记忆排查。

故障排查 runbook

vSphere 网络故障要避免“同时改很多地方”。先定位是 VM 侧、端口组/VLAN、VMkernel、上联、物理交换机还是路由问题，再只改一个变量。

这张图提供一个从症状到证据的排查路径。实际处理时可以按它逐层收敛，而不是直接怀疑 vCenter 或重启主机。

场景 1：VM 无法访问网关

症状：某台 VM 迁移或改端口组后无法 ping 网关。

排查顺序：

1. VM 网卡是否 Connected、Connect at Power On。
2. VM 是否连接到正确端口组。
3. 客户机 IP、掩码、网关是否正确。
4. 端口组 VLAN ID 是否正确。
5. 源/目标主机是否都有该端口组。
6. 目标主机上联是否 Link Up。
7. 物理交换机 Trunk 是否允许该 VLAN。
8. 上游网关是否在该 VLAN 正常工作。

常用命令：

esxcli network vswitch standard portgroup list
esxcli network nic list

如果只有迁移到某台 ESXi 后不通，通常不是 VM 自身问题，而是目标主机端口组、VLAN、上联或物理交换机端口差异。

场景 2：ESXi 主机从 vCenter 断开

症状：vCenter 显示主机 disconnected 或 not responding。

排查顺序：

1. 主机 DCUI 是否可访问。
2. 管理 IP 是否还能 ping 通。
3. 管理 VMkernel 是否存在。
4. 管理端口组 VLAN 是否改错。
5. 物理上联是否 Link Up。
6. 默认网关是否正确。
7. DNS/NTP 是否影响服务启动。
8. 管理代理是否需要重启。

命令：

esxcli network ip interface list
esxcli network ip route ipv4 list
esxcli network nic list
vmkping -I vmk0 <vcenter-ip>

如果配置看起来正确但管理连接仍未恢复，可以按官方 KB 建议考虑重启管理代理；但在生产环境中，先确认 HA/DRS/任务状态和变更窗口，避免在故障中制造新的影响。

场景 3：迁移到 vDS 后管理网络失联

症状：管理 VMkernel 迁移到分布式端口组后，主机无法被 vCenter 管理。

处理思路：

1. 通过 DCUI 或带外管理进入主机。
2. 检查管理 VMkernel 当前连接的端口、VLAN 和上联。
3. 若 vSphere 7.0 及之后版本自动回退生效，等待任务失败并回到上一有效配置。
4. 若未恢复，使用 DCUI 的 Network Restore Options 尝试恢复 vDS 或管理网络。
5. 必要时按 CLI 路径建立临时标准交换机，重新挂接管理 VMkernel。

临时标准交换机恢复的核心命令形态：

esxcfg-vswitch -l
esxcli network vswitch standard add --vswitch-name=vSwitch-Recovery
esxcli network vswitch standard uplink add --uplink-name=vmnicX --vswitch-name=vSwitch-Recovery
esxcli network vswitch standard portgroup add --portgroup-name=PG-MGMT-RECOVERY --vswitch-name=vSwitch-Recovery
esxcli network vswitch standard portgroup set --portgroup-name=PG-MGMT-RECOVERY --vlan-id=10
esxcli network ip interface add --interface-name=vmk0 --portgroup-name=PG-MGMT-RECOVERY
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=192.168.10.11 --netmask=255.255.255.0 --type=static

实际恢复时不要机械照抄 vmk0。如果原管理 VMkernel 仍存在，先确认是否需要删除或迁移；如果有多个 VMkernel，先用 esxcli network ip interface list 确认接口编号。错误地删除存储或 vSAN VMkernel，可能把问题扩大。

场景 4：vMotion 失败

常见原因：

1. vMotion VMkernel 未启用服务标签。
2. 源/目标主机 vMotion VLAN 不通。
3. MTU 不一致。
4. 端口组名称或 distributed port group 不一致。
5. 目标主机 VM 网络不可达。
6. CPU/EVC、存储可达性或权限问题被误认为网络问题。

先做：

esxcli network ip interface list
esxcli network ip interface tag get --interface-name=vmk1
vmkping -I vmk1 <target-vmotion-ip>
vmkping -I vmk1 -s 8972 -d <target-vmotion-ip>

如果 Jumbo 不通，先把 MTU 改回 1500 验证基础连通，或修复端到端 MTU。不要在存储、vMotion、物理交换机、VM 配置之间来回猜。

场景 5：只有部分 VM 掉线

如果同一主机上只有部分 VM 掉线，重点看端口组和 VLAN；如果同一端口组所有 VM 掉线，重点看上联和物理交换机；如果迁移到某台主机后才掉线，重点看目标主机配置漂移；如果所有主机同一 VLAN 都异常，重点看上游网关、核心交换或防火墙。

一个快速判断表：

运维基线与自动化审计

当网络配置稳定后，应把它纳入周期审计。vSphere 网络漂移通常不是一次大变更造成的，而是日常小改动累计出来的：某台主机临时加了端口组、某个 VLAN 只放行了一半、某个 VMkernel 地址被手工改过、某台主机的 vmnic active/standby 与其他主机相反。

每周检查：

1. 主机物理 NIC 是否存在 Link Down。
2. 同一集群端口组名称和 VLAN 是否一致。
3. 管理 VMkernel 是否只有预期 VLAN 和上联。
4. vMotion、存储、备份 VMkernel 是否互通。
5. 是否有 VM 连接到临时端口组或错误端口组。
6. vDS 是否有配置不同步、Host out of sync 或告警。

每月检查：

1. 物理交换机 Trunk 允许列表是否与 vSphere 端口组清单一致。
2. 是否存在长期不用的端口组。
3. 是否有端口组安全策略被放开但没有业务依据。
4. 是否需要导出 vDS 配置备份。
5. vDS 版本是否与 ESXi/vCenter 升级计划匹配。

重大变更前检查：

1. 是否导出 esxcfg-vswitch -l 和 esxcli network ip interface list。
2. 是否确认 DCUI 或带外管理可用。
3. 是否只改一台主机或一个端口组做试点。
4. 是否准备物理交换机回退命令。
5. 是否有测试 VM 做迁移和连通性验证。
6. 是否避开备份、批处理、月结和生产高峰。

PowerCLI 或自动化平台可以定期采集端口组、VLAN、VMkernel、物理上联、vDS 状态和 VM 网络连接关系。对中小环境来说，不一定要一开始就做复杂自动化，先把“端口组清单 + VLAN + 上联策略 + 物理交换机端口”维护成可审计表格，就已经能减少大量排障时间。

生产设计建议

小型环境：2 个上联

适用于实验室、小分支、单台或两台 ESXi：

小环境的关键是文档和回退。不要因为硬件少就不分 VLAN；也不要把 vMotion、备份、存储大流量安排在生产高峰。

标准中小集群：4 个上联

适用于常见 2-8 台主机集群：

如果有 IP 存储，可以把 vmnic2/vmnic3 用于存储和 vMotion 分时复用，或增加独立存储上联。关键业务环境建议至少 6-8 个物理上联或 2 个以上高速上联，便于分离管理、业务、vMotion、存储和备份。

较成熟集群：VSS 管理 + VDS 业务

这是一个稳健折中：

这种设计保留了主机本地管理恢复能力，又获得了业务端口组的一致性。缺点是上联数量要求更高，物理交换机配置也要更规范。

常见反模式

反模式 1：所有网络都放在默认 VM Network

默认 VM Network 适合初始实验，不适合长期生产。管理、业务、测试、vMotion、存储、备份都混在一个端口组里，会让权限、审计、故障排查和容量规划失去边界。

反模式 2：只改 ESXi，不改物理交换机

虚拟网络和物理网络是一体的。ESXi 配了 VLAN，不代表上游允许；ESXi 改了 MTU，不代表中间链路支持；ESXi 配了 IP Hash，不代表物理 Port Channel 已经正确建立。

反模式 3：同名端口组不同 VLAN

这是标准交换机环境中最危险的漂移之一。VM 在 A 主机连接 PG-VM-PROD 是 VLAN 20，迁移到 B 主机后同名端口组实际是 VLAN 30，结果可能是迁移后立即失联或进入错误安全域。

反模式 4：管理网络和 vDS 一起批量迁移

如果没有 DCUI、带外管理、试点主机和回退材料，批量迁移管理网络是高风险操作。即使 vSphere 有网络回退能力，也不能把它当作变更设计的替代品。

反模式 5：把 Jumbo Frame 当性能万能药

Jumbo Frame 只有在端到端一致、业务确实受益、监控能验证时才有价值。不一致的 MTU 会制造间歇性问题，比一直不通更难排查。

总结

vSwitch 与网络配置的核心不是记住几个菜单，而是建立四个边界：虚拟机流量与 VMkernel 流量的边界，标准交换机与分布式交换机的边界，虚拟端口组与物理交换机 VLAN/上联的边界，日常配置与故障恢复路径的边界。

标准交换机简单、主机本地可控，适合小环境、管理网络和恢复兜底；分布式交换机集中、一致、功能更完整，适合集群化运营。端口组必须用清晰命名、明确 VLAN、明确上联策略来治理。VMkernel 服务要根据管理、vMotion、存储、vSAN、备份等用途分离。NIC Teaming 必须与上游物理交换机策略一致，尤其是 IP Hash 和 Port Channel。任何涉及管理 VMkernel、VLAN、MTU、vDS 的变更，都应先准备导出、DCUI/带外访问、试点和回退步骤。

完成这一篇后，vSphere 环境已经具备比较完整的计算、存储、虚拟机和网络基础。下一篇将回到数据存储管理，继续把 VMFS、NFS、vSAN、容量治理、数据存储集群和存储告警纳入可运营的虚拟化平台基线。

验证环境说明：

• vCenter 版本：vCenter Server Appliance 8.0 Update 3 系列
• ESXi 版本：VMware ESXi 8.0 Update 3 系列
• 管理方式：vSphere Client、ESXi Shell、DCUI、ESXCLI
• 实验拓扑：两台 ESXi 主机，每台 4 个物理上联，管理/生产 VM/vMotion/NFS/备份 VLAN 分离
• 本文撰写日期：2026-06-04

参考资料

1. Broadcom Knowledge Base: Overview of vNetwork Distributed Switch concepts - https://knowledge.broadcom.com/external/article?legacyId=1010555
2. Broadcom Knowledge Base: Configuring Standard vSwitch (vSS) or virtual Distributed Switch (vDS) from the command line in ESXi - https://knowledge.broadcom.com/external/article/326175/configuring-standard-vswitch-vss-or-virt.html
3. Broadcom Knowledge Base: Understanding network rollback and recovery in vSphere 7.0 and later - https://knowledge.broadcom.com/external/article?legacyId=2032908
4. Broadcom Knowledge Base: Migrating ESXi host networking from Distributed Switch (vDS) to Standard Switch (vSS) via CLI - https://knowledge.broadcom.com/external/article/376245/migrating-esxi-host-networking-from-dist.html
5. Broadcom Knowledge Base: VDS Improvements and Features per Version - https://knowledge.broadcom.com/external/article/416520/vds-improvements-and-features-per-versio.html
6. Broadcom TechDocs: VMware vSphere 8.0 Product Documentation - https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0.html