虚拟交换机想要让多台物理主机上的虚拟机自由互通，靠的是把二层数据包封装进三层隧道里，典型实现就是VXLAN，由虚拟交换机与物理网络设备协同完成转发。
在传统物理网络里，两台主机上的虚拟机要通信，物理交换机靠MAC地址表决定转发，但在虚拟化环境中，虚拟交换机先接管虚拟机流量，再决定是本地转发还是发往外部，单台主机内的vSwitch可以直接桥接虚拟机网卡，但跨主机后，虚拟交换机必须把虚拟机的二层帧转换成能穿越物理网络的三层包,这也就是Overlay网络的本质。
虚拟交换机的两个层级：本地交换与隧道转发
虚拟交换机首先承担的是本地交换职责，当同一台物理机上的虚拟机A和B通信时，vSwitch检查MAC地址表后直接内部转发，不产生外部流量，这个逻辑和物理二层交换机完全一致，一旦目标MAC不在本地表中，vSwitch需要将帧交给物理网卡，发往目标虚拟机所在的主机，跨主机路线就出现了分叉：既能走传统VLAN,也能走Overlay隧道。
VLAN方案要求物理网络预先规划好VLAN划分，虚拟机迁移时若跨网段就受限。Overlay方案则对物理网络透明，把整张物理网络当成一个虚拟转发通道，2026年的主流选型中,VXLAN隧道已成为最普遍的跨主机虚拟机交换实现方式。
VXLAN隧道：跨主机虚拟机通信的核心封装机制
VXLAN将虚拟机的二层帧封装在UDP包中，外层IP头指向对端物理主机的地址，这个外层信封由虚拟交换机上的VTEP（VXLAN隧道端点）完成，VTEP可以是虚拟交换机本身，也可以是物理网络设备，每个VTEP维护一个映射表,记录虚拟机MAC地址与远端VTEP的对应关系。
数据包如何从虚拟机A走到虚拟机B
- 虚拟机A发送ARP请求,vSwitch广播泛洪。
- 若目标虚拟机B不在本地，VXLAN模块将该ARP包封装为组播或单播包,发给其他主机上的VTEP。
- 对端VTEP解封装后，在本地虚拟交换机内广播,虚拟机B响应。
- 响应包同样被封装回源VTEP，源VTEP收到后学习到B的MAC地址和其VTEP的IP地址,更新映射表。
- 后续数据流直接通过单播隧道持续传输,不再泛洪。
这个过程中，虚拟交换机实际扮演了翻译官角色，既要保持虚拟机看到的MAC地址不变，又要在外层添加物理网络可寻址的IP头，行业共识认为，VXLAN的24位VNI标识符能支撑海量租户隔离,这是传统VLAN的4096个标签难以做到的。
控制平面：组播学习与控制中心形态的较量
早期的VXLAN实现依赖物理网络组播，让VTEP自动发现对端，实际部署中，多数物理网络并未全面开启组播，因此后来流行的是中心化控制平面，例如用OVSDB或分布式控制器统一分发MAC与VTEP映射关系，虚拟交换机从自学成才变为听中央调度，收敛速度更快,也避免广播风暴。
以Open vSwitch为例，它通过VXLAN端口与本地模块配合，把隧道端口当作普通虚端口加入桥组，管理员只需指定对端IP和VNI,流量就会按照上面流程转发。
跨主机虚拟交换机选型对比：OVS与vSphere VDS哪个更合适
这是运维人员经常问到的对比问题，Open vSwitch和VMware vSphere VDS分别代表开源与商业的两条路线。
| 对比维度 | Open vSwitch | VMware vSphere VDS |
|---|---|---|
| 部署成本 | 免费，随服务器操作系统部署 | 需要vSphere Enterprise Plus授权 |
| 隧道协议 | VXLAN、Geneve、STT | VXLAN（NSX集成） |
| 控制平面 | OVSDB可选中心化 | 依赖vCenter或NSX管理器 |
| 性能优化 | DPDK加速后接近线速 | 内核级优化，适配vSphere生态 |
| 可编程性 | 调用OpenFlow流表，可深度定制 | 通过VMware API维护，集成成本高 |
单看功能，两者都能完成跨主机通信，但实际选型要结合现有虚拟化平台，若是KVM或容器场景，OVS配合OpenStack或Kubernetes的CNI插件，配置起来更顺手；若是企业级VMware环境，VDS与vMotion、HA等特性深度联动,这时强行用OVS反而割裂管理面。
Open vSwitch的典型部署拓扑
在物理机上创建桥br-int，虚拟机接入该桥，同时创建VXLAN端口vxlan0，指定远端VTEP地址，所有发往远端虚拟机的帧会从该端口走，多主机之间建立完整VXLAN矩阵后，虚拟机迁移无需改IP和MAC,跨主机通信完全由vSwitch接管。
VMware VDS跨主机通信的落地方式
VDS把虚拟交换机配置下沉到vCenter，多台ESXi主机共享同一份端口组定义，启用VXLAN后，vSphere统一分配VTEP地址，并随主机迁移自动更新映射，管理员在vCenter里看到的还是一台大型虚拟交换机,但内部已经在各主机间动态建立隧道。
手把手配置：虚拟交换机跨主机通信的实操路径
下面以最常见的开源环境为例，给出OVS配置VXLAN隧道的具体命令，假设两台物理机IP分别为192.168.10.10和192.168.10.11,VNI为100。
- 在两台主机上安装OVS并启用模块：
modprobe openvswitch systemctl start ovsdb-server systemctl start ovs-vswitchd - 每台主机创建桥：
ovs-vsctl add-br br-int - 将虚拟机虚拟网卡（假设为vnet0）加入桥：
ovs-vsctl add-port br-int vnet0 - 添加上行物理链路：
ovs-vsctl add-port br-int eth0 - 添加VXLAN端口（在主机1上指向主机2）：
ovs-vsctl add-port br-int vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=192.168.10.11 options:key=100主机2上反向配置，remote_ip指向192.168.10.10。
- 为隧道端口配置VLAN透明：确认br-int的普通端口与VXLAN端口处于同一转发域。
- 用ovs-ofctl dump-flows br-int查看流表,确认匹配规则正确。
这套配置完成后，两台不同主机上的虚拟机就能互通，关键检查点有三个：物理网卡MTU需要支持外层包，内层包可能只有1450字节；防火墙需放行UDP端口4789；VNI要一致,否则流量被丢弃。
vSphere分布式交换机上的配置路径
在vSphere环境中，先创建VDS并添加ESXi主机，然后为每个主机启用VMkernel网卡作为VTEP，再在VDS上启用VXLAN，具体路径为：vCenter Web Client 中选中VDS，点击网络 -> VXLAN -> 启用，之后按照向导指定端口组和VNI，若后续使用NSX，虚拟交换机则直接由NSX策略驱动,管理员不用手动配置隧道。
跨主机虚拟交换机通信的三大隐患与排查思路
MTU黑洞导致虚拟机互相丢包
物理网络若未开启巨型帧，VXLAN封装的约40字节开销会让1500字节的内层帧超出标准以太网限制，路由器可能直接丢弃，排查方法：在虚拟机内逐步降低MTU进行ping测试，常见解决方法是把物理网络MTU调至1600以上,或让虚拟机复制流量控制在MTU安全范围。
组播依赖带来的泛洪风暴
组播模式下，每台主机上的vSwitch需要处理大量未知MAC广播，虚拟机数量增多后，组播组携带的泛洪流量会明显拖慢物理网络，业界对策是改用控制中心下发映射，或在虚拟交换机里开启ARP抑制,让隧道端口只转发已知目标MAC的帧。
多归属冗余虚拟交换机选路不一致
当虚拟交换机与物理网卡做链路聚合时，若VXLAN封装后外层IP头的哈希字段不均衡，可能造成隧道流量集中在单条链路上，建议在虚拟交换机上配合启用基于隧道端口的哈希选路,同时保证物理交换机侧的LACP配置一致。
2026年虚拟交换机跨主机通信的演进方向
近期主流的虚拟交换机开始向可编程管道方向升级，OVS引入更细粒度的流表缓存，配合DPDK与SmartNIC卸载，VXLAN封装的CPU开销逐渐被硬件接管，云数据中心里，越来越多的负载均衡和防火墙功能从物理设备迁移到虚拟交换机内嵌执行，国产虚拟化平台方面，华为CloudEngine与华三的虚拟化方案都提供自研Overlay能力，与VXLAN兼容且支持集中管理，适合国内数据中心使用，据工信部公开资料显示,国内新建数据中心网络普遍将VXLAN与控制平面作为基础底座。
虚拟交换机跨主机通信常见问题解答
虚拟交换机跨主机通信只能用VXLAN吗？
不是，VLAN也能实现跨主机通信，但VLAN标签上限为4096个，且需要逐台配置物理交换机端口，跨三层网络场景则完全依赖VXLAN或Geneve这类Overlay协议，多数新部署选择VXLAN的原因是兼容性好、生态成熟，虚拟交换机只负责封装与解封装,对底层链路没有特殊要求。
Open vSwitch与物理交换机的VXLAN性能差多少？
物理交换机原生支持VXLAN卸载，转发时延更低，OVS结合DPDK后，在小包转发率上也能接近硬件水平，性能差异取决于CPU核数与网卡队列数量，若业务流量极大且不希望占用服务器CPU，建议在物理网络侧终结VXLAN,虚拟交换机只负责基础桥接。
虚拟交换机跨主机通信的配置成本大约多少？
纯软件OVS方案为零授权成本，只需承担运维人力，vSphere VDS则需购买Enterprise Plus授权，价格随物理CPU数量浮动，云环境下，用户无需关心底层虚拟交换机配置，按VPC与安全组计费，月消费取决于带宽与实例规模，本地部署时，建议优先评估现有物理交换机是否支持VXLAN,这直接影响硬件改造预算和项目实施周期。