企业官网建设流程全解析

简介：这是一份介绍VMware Paravirtual RDMA的英文技术PDF文档，面向HPC平台运维、虚拟化与远程直接内存访问方向的工程师及学习者。内容先说明PVRDMA在保留vSphere HA、DRS、vMotion等虚拟化特性前提下提供接近物理RDMA性能的优势，随后从vCenter Server、ESXi主机、虚拟机、客户操作系统四个层面给出详细配置步骤，并梳理了连接失败、性能下降等常见问题的排查思路。文档后半部分以开源CFD软件OpenFOAM为基准应用，介绍了测试床搭建方法，以及带宽、延迟、计算时间等性能测试结果的对比分析，可帮助读者评估虚拟化环境中的RDMA收益。资源共1个PDF文件，大小1.08MB，章节由浅入深、便于按需查阅，适合作为HPC网络虚拟化部署的参考资料。目前已有97人学习浏览，对需要PVRDMA配置与调优实战参考的人有实用价值。

1. 先得说清：VMware Paravirtual RDMA 到底是干嘛的

在高性能计算集群里跑 MPI 作业的人，多半都撞过同一堵墙：虚拟机里的网络性能上不去。物理机上用 InfiniBand 或 RoCE 跑消息传递，延迟能压到微秒级，数据一进虚拟机，走的是 vmxnet3 模拟出来的虚拟网卡，经过 TCP/IP 协议栈和 vSwitch，延迟立刻涨十倍，带宽也只剩一半。Virtualization 的算力隔离做得越好，网络开销就越碍眼。VMware Paravirtual RDMA（PVRDMA）就是冲着这个场景来的：让虚拟机里的程序直接走 RDMA 语义访问物理网卡，既保留 vMotion、HA 这类虚拟化特性，又不用忍受 TCP 那套复制拷贝的冤枉路。

这套东西适合的人很明确：在 vSphere 上跑 MPI 分布式训练、大数据 shuffle、需要低延迟 RPC 的从业者。不适合谁，页面上写着 High Performance Computing，但你要是只跑个 Web 服务或者数据库同步，根本用不上 RDMA，别给自己找罪受。要理解 PVRDMA，先得明白它到底绕开了什么。

2. 为什么要为 HPC 把 RDMA 做成半虚拟化：先看透这套黑匣子

2.1 物理 RDMA 是怎么绕过内核的，虚拟化后又为什么失灵

物理机上的 InfiniBand 和 RoCE 网卡能跑出几微秒延迟，靠的是 kernel bypass：应用把内存区域注册到网卡，网卡直接 DMA 读写用户态缓冲区，数据不经过内核协议栈，连 CPU 都很少参与。但这个模型在虚拟化环境里有一个天然障碍——DMA 操作要经过 hypervisor 的 IOMMU 做地址映射，Hypervisor 不可能让虚拟机里的 guest OS 直接拿物理内存地址去操作网卡，否则一台物理机上的多个虚拟机可以互相踩内存。

于是三条路线摆在 VMware 面前：一是 PCIe Passthrough，把物理网卡整个交给某台虚拟机独占，性能最好，但这台 VM 不能 vMotion，也不能做快照，一台物理机配几张网卡就服务几台 VM，这在大规模集群里不可接受；二是完全模拟，虚拟机看到的是一个不存在的网卡，所有操作由 hypervisor 翻译，兼容性最好但性能灾难；三是半虚拟化，也就是 PVRDMA——虚拟机里看到一个前端设备，ESXi 内核里有一个后端驱动，两者通过共享内存环形队列通信，Guest 侧仍然保留 RDMA 的用户态管理接口，但实际 DMA 映射和门铃操作由 VMware 的 vMM 接管。这个方案牺牲了一点点绝对性能，换来了虚拟化能力与 RDMA 语义的共存。

2.2 PVRDMA 的性能定位与适用负载：别拿它和直通比延迟

PVRDMA 出来后，很多人把它当成 Passthrough 的替代品，用 ib_write_bw 一测就开骂：延迟比物理机高了 30%，带宽少了一截，觉得 VMware 吹牛。这个心态本身就是误解。PVRDMA 的价值不是追平物理 RDMA，而是把 RDMA 的能力从"物理机专属"变成"虚拟机也能用"，而且能用到的程度远超 TCP。

我一般这样评价这套方案：单流带宽能跑到物理网卡的八成以上，延迟比同机的 vmxnet3 TCP 低一个数量级，但比直通仍高 30% 左右。它适合的负载是 MPI 消息传递、NCCL 的 AllReduce、Spark 的 Shuffle，这些场景量大但不追求极限延迟；不适合的是小包高频交易这类每笔都在意几微秒的敏感业务——那类负载虚拟机化本身就不是主流玩法。下表是三类方案的典型差异：

2.3 跑 PVRDMA 的前提条件：网卡、交换机、固件，一个都别省

PVRDMA 不是装上就能用的。物理链路要求是 RoCE v2（当前主流版本，UDP 封装，可跨三层），也就是所谓 RDMA over Converged Ethernet。网卡以 Mellanox ConnectX-4/Lx、ConnectX-5、ConnectX-6 系列为主，NVIDIA 收购 Mellanox 后，后续的 BlueField 系列同样支持。ESXi 侧需要对应的 nmlx5_core 驱动，这套驱动随 vSphere 的 VIB 包分发，不是随便装个驱动就认设备。

网络端是大多数 HPC 集群翻车的重灾区：RoCE 依赖无损网络，物理交换机必须开启 PFC（Priority Flow Control）和 ECN，网卡上要配置 QoS 策略，否则高负载下丢包，RDMA 的带宽和延迟一起崩。这也就是为什么 PVRDMA 更适合"整机房一起规划"的 HPC 项目，而不是随便往现有虚拟化平台上插一张网卡就能跑的场子。下面是 ESXi 侧要满足的最低条件清单，缺一项就能看出来：

• vSphere 6.5 及以上版本，ESXi 6.5 是 PVRDMA 的首个支持版本
• 物理网卡为支持 RoCE v2 的 Mellanox ConnectX-4 或后续型号
• 物理交换机启用 PFC/ECN，物理链路 MTU 9000 或至少 4096
• ESXi 主机的 nmlx5_core VIB 与物理网卡固件版本匹配
• 虚拟机硬件版本 13 及以上，VMware Tools 为完整安装（不是只装 open-vm-tools）

条件齐了，接下来才是配置阶段。很多人死在第一步：在 vSphere Client 里点了一圈找不到 PVRDMA 网卡类型，Measurement 还真不是那个下拉框。

3. ESXi 侧把 PVRDMA 交到虚拟机手里：这张网卡不是点出来的

3.1 物理机准备：先确认网卡、驱动、固件处于可用状态

我见过最快的翻车案例是：网卡买了 ConnectX-5，ESXi 从旧版本升级到 7.0，没刷固件就开机，结果虚拟机永远识别不到设备。Mellanox 网卡的固件对 vSphere 的版本兼容性很挑，旧固件 + 新 ESXi 会直接导致 vmkernel 不加载 nmlx5 系列驱动。所以第一步永远建立在"确认环境真实状态"上，而不是急着去 vSphere Client 找网卡。

在 ESXi 主机上开 SSH，逐条确认三件事。

# 1. 确认 ESXi 版本与 build vmware -v # 2. 确认 Mellanox 网卡的驱动是否加载 esxcli software vib list | grep -i nmlx5 # 3. 确认物理网卡是否处于联机状态，Link 速度是否是期望值 esxcfg-nics -l

第一组命令逻辑：先看 ESXi 基线版本，PVRDMA 对 6.5 以下版本根本不可用；第二步确认 nmlx5_core 的 VIB 是否装好，有时候网卡厂商提供的自定义 ESXi 镜像不带这个 VIB，需要单独下载并 esxcli software install 安装；第三步看网卡的 Link 状态，这里经常出现"物理口 Link=Down"而机房还以为没问题的情况，RoCE 网卡要求链路两端都对，光模块、线缆不兼容最常在这里暴露。

顺便提一句网络热词里那些"vmware 虚拟机安装教程"式的步骤，到了 HPC 环境全都不适用——教程教你怎么装 vmxnet3、怎么调网卡高级属性，PVRDMA 要卡在驱动层级，比那些教程深一层。如果第三步发现 Link Down，先查线缆模式和光模块，证明物理链路干净再往下走。

3.2 给虚拟机添加 PVRDMA 虚拟网卡：选对类型、选对交换机

物理机准备好了，接下来在 vSphere Client 里给虚拟机添加网卡。关键点：网卡类型要选"VMware Paravirtual RDMA"，不是"SR-IOV"，也不是 vmxnet3——下拉框里这三个选项长得像，行为完全不同。

但这里有两个前置条件容易被忽略：虚拟机的硬件版本必须 13 以上（vSphere 6.5 的默认 VM 版本可能不满足，新建 VM 时选兼容性为 ESXi 6.5 及以上）；虚拟机必须关机和开机各一次，让 VMX 配置里真正的 PCI 设备注册进去。

我一般不在 GUI 操作，直接在 vmk 命令行加，反而可控性更高。命令如下：

# 在 ESXi Shell 中，给虚拟机 VMID=100 添加 pvrdma 网卡 vim-cmd vmsvc/getallvms vim-cmd vmsvc/device.conn.add 100 pvrdma 88:44:33:22:11:00

这里参数的含义：vmsvc/device.conn.add是 vim-cmd 提供的虚拟设备添加入口，第一个数字是虚拟机在 ESXi 里的 VMID（不是名字），第二个参数指定设备类型为 pvrdma，后面的 MAC 地址建议自定义而不是用默认随机生成的。指定 MAC 的意义在于：HPC 环境里这些 RDMA 流量需要被物理交换机的 ACL 规则识别，固定 MAC 才能把网络策略锁在这一台虚拟机上。

命令执行后，还必须在虚拟机所在的端口组（Port Group）把 MTU 改成 9000，这是 vSphere 虚拟交换机一个很容易忽略的配置维度。在 vSphere Client 里"分布式交换机"或"标准交换机"编辑设置，把 MTU 从默认的 1500 改为 9000。如果不做这一步，后面的 IB 子网运行正常，但大包会被物理网卡分割成一串 1500 字节的碎包，RDMA 性能直接崩到几十 Gbps 以下。

3.3 虚拟机里确认硬件已经挂上：lspci 就是你的第一道照妖镜

添加完网卡并开机后，不要急着装驱动。先进入虚拟机（要求 VMware Tools 已经安装），确认操作系统看到了 PCI 设备。这一步是根因判断的分水岭：如果 lspci 看不到"VMware Paravirtual RDMA"字样，后面的 OFED 安装、ib0 配置全是空中楼阁。

# 在 Linux 虚拟机中确认 PCI 设备列表 lspci | grep -i rdma # 确认内核是否已经加载了 ib_core（RDMA 核心模块） lsmod | grep ib_core

lspci 输出中，正常情况应该出现类似15b3:0000（Mellanox vendor ID）的条目，设备名字里含 "VMware Paravirtual RDMA" 或 "Mellanox ConnectX" 之类的字样，取决于 ESXi 的具体实现。如果 lsmod 里没有任何 ib_core 模块，说明这台机器的内核还没有 RDMA 子系统，或者还没安装 OFED 包——这是下一章的活。

这里给一个判断经验：ESXi 的 PVRDMA 在虚拟机里看起来是一个标准的 RDMA PCI 设备，不依赖 PCIe SR-IOV 的 VF；所以物理机不需要开启 SR-IOV 也能用。这个特性对很多现有 vSphere 集群是友好的：很多老机房的 BIOS 里没开 SR-IOV，但 PVRDMA 完全能绕过这个前提条件。

4. 虚拟机侧把 PVRDMA 用起来：从 OFED 到 MPI 跑通一条龙

4.1 在虚拟机里装 OFED 驱动：这一步的坑最深

虚拟机里的 Linux 看到了 PVRDMA 设备，接下来要安装对应版本的 OFED。在虚拟机里，这个驱动包实际上有两种来源：Mellanox 官方给 VMware 虚拟环境提供的专用 OFED（MLNX_OFED for VMware），以及 Linux 发行版自带的普通 OFED/MLNX_OFED。两者不能混用——Linux 发行版自带的 mlx5_core 驱动是给物理机用的，装在 PVRDMA 虚拟设备上会加载失败或直接不识别设备。

正确做法是安装 Mellanox/NVIDIA 官方针对 VMware 虚拟化版本的 OFED 驱动包。RHEL 系系统用 rpm 安装，Ubuntu 系用 deb。安装之前先明确内核版本和发行版版本，官方仓库里每个版本都有对应的编译包，选错了在 make rpm 阶段就会报错。

# Ubuntu 举例：下载对应内核的 deb 包后安装 apt-get install -y libibverbs-dev librdmacm-dev dpkg -i MLNX_OFED_LINUX-5.8-1.0.1.1-ubuntu22.04-x86_64.tgz 2>/dev/null || true # 安装完成后的核心步骤：重新生成 kernel module 依赖 /etc/init.d/openibd restart # 验证模块加载 lsmod | grep -E "ib_(core|vmac|veth)"

上面命令里有一句是dpkg -i ... || true，是为了防止在没有实际安装包时中断脚本。实际部署时，解压 OFED 包后建议先执行包里的./mlnxofedinstall --with-verbs --with-rdma-cm --without-mlnx-nfs-rdma。--without-mlnx-nfs-rdma是 HPC 环境的常见选项，它跳过 NFS over RDMA 的支持，减少模块编译时间，也更适合集群只跑 MPI 的场景。

模块ib_core是 RDMA 子系统的基石，ib_vmac是 VMware 半虚拟化设备的端到端驱动，ib_veth负责虚拟以太网模拟——三个模块缺一个，ibstat命令看到的设备状态就会异常。在这里，热词里那条"vmware tools 启动脚本未能在虚拟机中成功运行"几乎成了标准前奏：Tools 没装好，PVRDMA 设备根本不会注册到 PCI 总线上，OFED 装得再完整也白搭。

4.2 配置 IPoIB：给 RDMA 网卡一个可路由的身份

RDMA 设备在 Linux 里注册出ib0接口后，还不具备 IP 通信能力，因为 PVRDMA 设备默认工作在 InfiniBand 语义下，需要 IPoIB 协议栈把 IP 包封装成 InfiniBand 消息。

配置 IPoIB 的要点有三个：子网前缀（P_Key）、MTU、IP 地址。P_Key 默认用0xffff（全通键），表示这台虚拟机加入默认子网；MTU 必须和物理链路协商，RoCE v2 下物理链路 MTU 是 9000 时，ib0 可以设到 4092（IPoIB 理论最大值），这是一个长期被忽略的性能拐点——默认的 2044 会限制单消息大小，让带宽卡在某个上不去的值。

在 RHEL/CentOS 系直接写 ifcfg-ib0：

# /etc/sysconfig/network-scripts/ifcfg-ib0 DEVICE=ib0 TYPE=InfiniBand ONBOOT=yes BOOTPROTO=static IPADDR=10.0.1.11 NETMASK=255.255.255.0 MTU=4092

在 Ubuntu 系用 netplan，格式不同但关键项一致：applet和glibc都不需要，关键是addresses和mtu。配置完重启网络服务或直接ip link set ib0 up。验证命令用ibstat或ibv_devinfo——ibv_devinfo -d mlx5_0如果显示state: PORT_ACTIVE，说明链路已经起来；如果显示PORT_DOWN，查物理交换机的 PFC 配置。

有个细节很多新手会栽跟头：IPoIB 下ping走的是 IP 层，能 ping 通不代表 RDMA 能建连。这是两码事——ping用的是 IPoIB 的 UD（不可靠数据报），RDMA 应用程序很多用 RC（可靠连接）。所以配置完成后，先做一次rdma_cm测试，或者跑 ib_write_bw，确认真的能建 RC 连接，再上 MPI，否则后面 MPI 报错你都不知道在哪查。

4.3 让 MPI 真正走 RDMA：选对传输层比写好代码还重要

MPI 程序跑在 PVRDMA 上，最大的变数是 OpenMPI 或 MPICH 的传输层选择。默认情况下，OpenMPI 会优先检测到 vmxnet3 提供的 TCP 通道，然后傻乎乎地走 TCP，完全发挥不出 RDMA 网卡的价值。要在 HPC 场景榨出 PVRDMA 的性能，必须显式指定 RDMA 通道。

OpenMPI 4.x 时代的主流做法是通过 UCX 或 libfabric 作为中间层。以下是 MPI 基准测试的最小命令，能跑通说明准备阶段全对：

# 两台虚拟机之间跑 OSU pingpong 基准 mpirun --host vm01,vm02 \ --mca pml ucx \ --mca osc ucx \ --ucx tls=rc,ud,self \ --ucx ib_devices=mlx5_0 \ -np 2 ./osu_pingpong

参数含义：--mca pml ucx让消息层走 UCX，--ucx tls=rc,ud,self指定传输列表——rc（可靠连接）是主力，ud（不可靠数据报）作为兜底，self 指本回环；--ucx ib_devices=mlx5_0把设备锁死在 PVRDMA 网卡上，防止 OpenMPI 自动选择 vmxnet3 或非 RDMA 设备。

这里有一个踩坑点：UCX 的 tls 列表顺序会影响性能。如果把tcp放在列表里，部分流量会路由到 TCP 通道，表现为带宽时好时坏。HPC 集群里我一般把它禁用：--ucx tls=rc,ud,self不带tcp。

如果跑 OSU 基准出现连接拒绝或 timeout，先用ucx_info -d看设备状态，再用rdma_cm工具做端到端验证——这一步把故障范围缩小到"MPI 配置问题"还是"底层 PVRDMA 链路问题"，非常重要。

5. 验证与调参：把 PVRDMA 的带宽和延迟榨出来

5.1 用 perftest 量化收益：别拿感觉当结论

配置完成后，第一件事是跑 perftest（Mellanox 官方性能测试套件，自带在 OFED 里）。测试方案设计为三组对照：物理机直连 RoCE、虚拟机 PVRDMA、虚拟机 vmxnet3 TCP，这样能明确地回答"PVRDMA 到底带来多大提升"。

# 节点 A 作为服务端 ib_write_bw -d mlx5_0 -a -F # 节点 B 作为客户端 ib_write_bw -d mlx5_0 -a -F 10.0.1.11

-d mlx5_0指定设备，-a让 perftest 自动探测所有可用属性，-F是 fast mode，不跑全参数矩阵。输出结果看两个指标：BW带宽和Latency延迟。测出来的带宽如果能到物理网卡标称的 70%～85%，说明链路状态健康、MTU 配置正确；如果只有 30% 左右，且延迟还不低，先怀疑 MTU，再怀疑队列深度。

对照实验里，虚拟机内 vmxnet3 + TCP 用 iperf3 跑同样大小包，PVRDMA 的 iB（线路速率）和延迟在多数情况下能碾压它一个数量级。这也给上面每章反复强调"别把 vmxnet3 当 RDMA 用"做了一次实证。

5.2 四个必调参数：MTU、队列深度、NUMA、中断合并

perftest 跑通了只是起点，HPC 生产环境还要处理四个参数，缺一个都可能让性能打折扣。这里列一个实际生产环境里我会优先检查的参数表：

QP 队列深度的设置：在 perftest 里-q参数指定，默认是 128，大规模 MPI 场景改到 1024 或 2048。但注意，深度越大，虚拟机里为每对 QP 预留的内存越高，这个和虚拟机内存配额直接相关，别设太猛导致内存不足。

NUMA 绑定这一项，ESXi 里用numactl做不到——虚拟机内部看不到物理机的 NUMA 拓扑，绑定的活要放在 ESXi 侧做。vSphere Client 里给虚拟机配置 CPU 亲和性，把 vCPU 和物理核锁在同一个 NUMA 节点上，同时 PVRDMA 网卡的 PCIe 通路也要落在那个节点。这个配置粒度很难通过命令行一次到位，我一般用 vSphere 的"高级 CPU 特性"配合 DRS 规则，让虚拟机始终运行在同一组物理核上。

中断合并（interrupt coalescing）在虚拟化环境下最玄学。Mellanox 物理机上常用ethtool -C ens2 rx-usecs 16，但到了 PVRDMA 上，这个值往往不听 ethtool 的，而是在 ESXi 的后端驱动里控制。常见做法是调 ESXi nmlx5_core 的模块参数，或直接保持默认不折腾——除非你明确测出延迟在高压下抖动剧烈，否则不建议动这个参数。

5.3 高层验证：跑一遍 OSU 基准和真实应用

perftest 是底层验证，MPI 用户最终关心的是应用层的延迟和带宽。OSU 的 osu_latency、osu_bw、osu_allreduce 是 HPC 集群的业界标配。

# 跑 allreduce 基准，模拟分布式训练场景 mpirun --host vm01,vm02 \ --mca pml ucx \ --ucx tls=rc,ud,self \ -np 8 ./osu_allreduce -m 1048576

-m 1048576指定消息大小为 1MB，这是大数据 AllReduce 场景的典型规模。跑出来之后和同规模的物理机对照，如果延迟差在一个可控范围内，就说明这套虚拟化 HPC 方案是可行的。

真实应用层的验证更直接：把 Horovod 或 TensorFlow 的分布式训练脚本搬上来，看 NCCL 的选择是否走了 RoCE。运行前设置NCCL_DEBUG=INFO，日志里会出现类似NET/IB : Using mlx5_0的字样，如果出现NET/Socket字样，说明 NCCL 完全没走 RDMA——回去查 UCX 和 NCCL 的通信插件。

6. PVRDMA 最常见四个翻车点，我都替你踩过

6.1 vMotion 一迁移，RDMA 连接全部断掉

现象：虚拟机用 vMotion 从一台物理机迁到另一台，迁移后 RDMA 应用全部超时重连。原因：PVRDMA 是半虚拟化设备没错，但它映射的底层物理网卡和 DMA 映射关系在迁移时不会保持，vSphere 的 vMotion 对 RDMA 连接的状态保留能力有限，标准做法是迁移后重新建连。解决：接受这个约束，在应用层面做好断线重连逻辑；或者用 vSphere 的"仅迁移计算资源"选项，把存储和网络留在原物理机上，避免 RDMA 链路中断。

6.2 装完 OFED 依然没有 ib0，查到最后是 VMware Tools 没装完整

现象：lspci能看到设备，但ibstat显示设备不存在或状态异常。原因：PVRDMA 的 PCI 设备注册依赖 VMware Tools 里的设备驱动组件，如果只装了 open-vm-tools（轻量版），PCI 驱动部分缺失。这正好撞上热词里那条"vmware tools 启动脚本未能在虚拟机中成功运行"的常见状况。解决：用完整版 VMware Tools 覆盖安装，重启后重新检查 lspci——设备正常后，再回头装 OFED，否则 OFED 装得再对也是空转。

6.3 MTU 不一致：物理口 9000、ib0 只有 1500，带宽像被掐了脖子

现象：perftest 测出来带宽只有标称的三成，延迟还带波动。原因：物理交换机和 ESXi 虚拟交换机的 MTU 已经设了 9000，但虚拟机里 ib0 没设置，可能反而继承了一个错误的默认 MTU。解决：三层 MTU 一把梭——物理口、vSwitch、虚拟机 ib0 全部对齐。ib0 在 IPoIB 模式下最大 4092，物理链路必须要能承载这个尺寸的帧。

6.4 RDMA-CM 建连失败，但 ping 完全通畅

现象：ping 正常，MPI 跑起来报rdma_cm连接超时。原因：IPoIB 的 ping 走的是 UD 数据报，而 RDMA-CM 建连要过 QP 的 RC 路径，还要依赖 GID 索引和 P_Key 表匹配。在 vSphere 环境里，多块虚拟网卡共存时最容易出 P_Key 冲突。解决：用ibv_devinfo -v看所有 port 的 P_Key 和 GID 表，确认两端虚拟机落在同一个 P_Key 子网下；再检查 MTU 是否在有的网卡上被某种策略改了，确认后再跑 rdma_cm 测试。

血的教训是：别在 RDMA 链路没验证清楚时就怀疑 MPI 配置。我习惯的排查顺序永远是硬件网卡 → 链路层（perftest）→ 传输层（rdma_cm）→ MPI。这套顺序让我省掉了太多"调了半天 MPI 参数结果是底层网卡 MTU 出错"的无用功。希望帮到你。

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