简介这是一份介绍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 RDMAPVRDMA就是冲着这个场景来的让虚拟机里的程序直接走 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这些场景量大但不追求极限延迟不适合的是小包高频交易这类每笔都在意几微秒的敏感业务——那类负载虚拟机化本身就不是主流玩法。下表是三类方案的典型差异方案延迟带宽vMotion快照一台物理机支持的虚拟网卡数PCIe Passthrough物理级物理级不支持不支持受限于物理端口PVRDMA高物理约 30%约物理 80%支持支持可多台vmxnet3 TCP高一个数量级约物理 50%支持支持无限制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 依赖无损网络物理交换机必须开启 PFCPriority Flow Control和 ECN网卡上要配置 QoS 策略否则高负载下丢包RDMA 的带宽和延迟一起崩。这也就是为什么 PVRDMA 更适合整机房一起规划的 HPC 项目而不是随便往现有虚拟化平台上插一张网卡就能跑的场子。下面是 ESXi 侧要满足的最低条件清单缺一项就能看出来vSphere 6.5 及以上版本ESXi 6.5 是 PVRDMA 的首个支持版本物理网卡为支持 RoCE v2 的 Mellanox ConnectX-4 或后续型号物理交换机启用 PFC/ECN物理链路 MTU 9000 或至少 4096ESXi 主机的 nmlx5_core VIB 与物理网卡固件版本匹配虚拟机硬件版本 13 及以上VMware Tools 为完整安装不是只装 open-vm-tools条件齐了接下来才是配置阶段。很多人死在第一步在 vSphere Client 里点了一圈找不到 PVRDMA 网卡类型Measurement 还真不是那个下拉框。3. ESXi 侧把 PVRDMA 交到虚拟机手里这张网卡不是点出来的3.1 物理机准备先确认网卡、驱动、固件处于可用状态我见过最快的翻车案例是网卡买了 ConnectX-5ESXi 从旧版本升级到 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 状态这里经常出现物理口 LinkDown而机房还以为没问题的情况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 中给虚拟机 VMID100 添加 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_coreRDMA 核心模块 lsmod | grep ib_corelspci 输出中正常情况应该出现类似15b3:0000Mellanox 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 虚拟环境提供的专用 OFEDMLNX_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 可以设到 4092IPoIB 理论最大值这是一个长期被忽略的性能拐点——默认的 2044 会限制单消息大小让带宽卡在某个上不去的值。在 RHEL/CentOS 系直接写 ifcfg-ib0# /etc/sysconfig/network-scripts/ifcfg-ib0 DEVICEib0 TYPEInfiniBand ONBOOTyes BOOTPROTOstatic IPADDR10.0.1.11 NETMASK255.255.255.0 MTU4092在 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 tlsrc,ud,self \ --ucx ib_devicesmlx5_0 \ -np 2 ./osu_pingpong参数含义--mca pml ucx让消息层走 UCX--ucx tlsrc,ud,self指定传输列表——rc可靠连接是主力ud不可靠数据报作为兜底self 指本回环--ucx ib_devicesmlx5_0把设备锁死在 PVRDMA 网卡上防止 OpenMPI 自动选择 vmxnet3 或非 RDMA 设备。这里有一个踩坑点UCX 的 tls 列表顺序会影响性能。如果把tcp放在列表里部分流量会路由到 TCP 通道表现为带宽时好时坏。HPC 集群里我一般把它禁用--ucx tlsrc,ud,self不带tcp。如果跑 OSU 基准出现连接拒绝或 timeout先用ucx_info -d看设备状态再用rdma_cm工具做端到端验证——这一步把故障范围缩小到MPI 配置问题还是底层 PVRDMA 链路问题非常重要。5. 验证与调参把 PVRDMA 的带宽和延迟榨出来5.1 用 perftest 量化收益别拿感觉当结论配置完成后第一件事是跑 perftestMellanox 官方性能测试套件自带在 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 生产环境还要处理四个参数缺一个都可能让性能打折扣。这里列一个实际生产环境里我会优先检查的参数表参数默认值推荐值影响ib0 MTU20444092低于 4092 时单包小大消息吞吐下降 20%QP 队列深度1281024高并发队列深度不足 → 发送队列满 → 重试风暴NUMA node任意和 vCPU 所在 Node 绑定跨 NUMA 访问网卡内存 → 延迟陡增 1.5 倍中断合并默认高吞吐场景调低合并过度 → 延迟大增关闭 → CPU 中断风暴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 tlsrc,ud,self \ -np 8 ./osu_allreduce -m 1048576-m 1048576指定消息大小为 1MB这是大数据 AllReduce 场景的典型规模。跑出来之后和同规模的物理机对照如果延迟差在一个可控范围内就说明这套虚拟化 HPC 方案是可行的。真实应用层的验证更直接把 Horovod 或 TensorFlow 的分布式训练脚本搬上来看 NCCL 的选择是否走了 RoCE。运行前设置NCCL_DEBUGINFO日志里会出现类似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 出错的无用功。希望帮到你。本文还有配套的精品资源点击获取 vSphere虚拟机跑HPC：PVRDMA网卡配置与性能调优实战
简介这是一份介绍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 RDMAPVRDMA就是冲着这个场景来的让虚拟机里的程序直接走 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这些场景量大但不追求极限延迟不适合的是小包高频交易这类每笔都在意几微秒的敏感业务——那类负载虚拟机化本身就不是主流玩法。下表是三类方案的典型差异方案延迟带宽vMotion快照一台物理机支持的虚拟网卡数PCIe Passthrough物理级物理级不支持不支持受限于物理端口PVRDMA高物理约 30%约物理 80%支持支持可多台vmxnet3 TCP高一个数量级约物理 50%支持支持无限制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 依赖无损网络物理交换机必须开启 PFCPriority Flow Control和 ECN网卡上要配置 QoS 策略否则高负载下丢包RDMA 的带宽和延迟一起崩。这也就是为什么 PVRDMA 更适合整机房一起规划的 HPC 项目而不是随便往现有虚拟化平台上插一张网卡就能跑的场子。下面是 ESXi 侧要满足的最低条件清单缺一项就能看出来vSphere 6.5 及以上版本ESXi 6.5 是 PVRDMA 的首个支持版本物理网卡为支持 RoCE v2 的 Mellanox ConnectX-4 或后续型号物理交换机启用 PFC/ECN物理链路 MTU 9000 或至少 4096ESXi 主机的 nmlx5_core VIB 与物理网卡固件版本匹配虚拟机硬件版本 13 及以上VMware Tools 为完整安装不是只装 open-vm-tools条件齐了接下来才是配置阶段。很多人死在第一步在 vSphere Client 里点了一圈找不到 PVRDMA 网卡类型Measurement 还真不是那个下拉框。3. ESXi 侧把 PVRDMA 交到虚拟机手里这张网卡不是点出来的3.1 物理机准备先确认网卡、驱动、固件处于可用状态我见过最快的翻车案例是网卡买了 ConnectX-5ESXi 从旧版本升级到 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 状态这里经常出现物理口 LinkDown而机房还以为没问题的情况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 中给虚拟机 VMID100 添加 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_coreRDMA 核心模块 lsmod | grep ib_corelspci 输出中正常情况应该出现类似15b3:0000Mellanox 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 虚拟环境提供的专用 OFEDMLNX_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 可以设到 4092IPoIB 理论最大值这是一个长期被忽略的性能拐点——默认的 2044 会限制单消息大小让带宽卡在某个上不去的值。在 RHEL/CentOS 系直接写 ifcfg-ib0# /etc/sysconfig/network-scripts/ifcfg-ib0 DEVICEib0 TYPEInfiniBand ONBOOTyes BOOTPROTOstatic IPADDR10.0.1.11 NETMASK255.255.255.0 MTU4092在 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 tlsrc,ud,self \ --ucx ib_devicesmlx5_0 \ -np 2 ./osu_pingpong参数含义--mca pml ucx让消息层走 UCX--ucx tlsrc,ud,self指定传输列表——rc可靠连接是主力ud不可靠数据报作为兜底self 指本回环--ucx ib_devicesmlx5_0把设备锁死在 PVRDMA 网卡上防止 OpenMPI 自动选择 vmxnet3 或非 RDMA 设备。这里有一个踩坑点UCX 的 tls 列表顺序会影响性能。如果把tcp放在列表里部分流量会路由到 TCP 通道表现为带宽时好时坏。HPC 集群里我一般把它禁用--ucx tlsrc,ud,self不带tcp。如果跑 OSU 基准出现连接拒绝或 timeout先用ucx_info -d看设备状态再用rdma_cm工具做端到端验证——这一步把故障范围缩小到MPI 配置问题还是底层 PVRDMA 链路问题非常重要。5. 验证与调参把 PVRDMA 的带宽和延迟榨出来5.1 用 perftest 量化收益别拿感觉当结论配置完成后第一件事是跑 perftestMellanox 官方性能测试套件自带在 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 生产环境还要处理四个参数缺一个都可能让性能打折扣。这里列一个实际生产环境里我会优先检查的参数表参数默认值推荐值影响ib0 MTU20444092低于 4092 时单包小大消息吞吐下降 20%QP 队列深度1281024高并发队列深度不足 → 发送队列满 → 重试风暴NUMA node任意和 vCPU 所在 Node 绑定跨 NUMA 访问网卡内存 → 延迟陡增 1.5 倍中断合并默认高吞吐场景调低合并过度 → 延迟大增关闭 → CPU 中断风暴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 tlsrc,ud,self \ -np 8 ./osu_allreduce -m 1048576-m 1048576指定消息大小为 1MB这是大数据 AllReduce 场景的典型规模。跑出来之后和同规模的物理机对照如果延迟差在一个可控范围内就说明这套虚拟化 HPC 方案是可行的。真实应用层的验证更直接把 Horovod 或 TensorFlow 的分布式训练脚本搬上来看 NCCL 的选择是否走了 RoCE。运行前设置NCCL_DEBUGINFO日志里会出现类似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 出错的无用功。希望帮到你。本文还有配套的精品资源点击获取