简介针对高性能计算对低延迟、高带宽网络的严苛要求这份关于 VMware 半虚拟化远程直接内存访问PVRDMA的 PDF 技术文档系统介绍了在虚拟化环境中部署 RDMA 的完整方案涵盖实现原理、环境配置、故障排查与性能测试四大部分可帮助 HPC 集群运维和虚拟化管理员解决物理网卡直通与虚拟机迁移功能难以兼顾的问题。内容按 vCenter Server、ESXi 主机、虚拟机及客户操作系统四个层级逐一展开详细说明了启用单根输入输出虚拟化以获得直接硬件访问、指定支持 RDMA 的网卡设备模型、在客户系统内安装 iWARP 或 InfiniBand Verbs 驱动等关键步骤并整理出部署前需要核对的硬件兼容性要点针对连接失败、性能下降等常见故障给出了基于日志分析和性能监控工具的系统排查方法。文档还以开源计算流体动力学软件 OpenFOAM 为测试基准设计并运行了多节点 PVRDMA 测试床通过对比启用前后的计算耗时、网络带宽、延迟及资源利用率验证了虚拟化 RDMA 在真实 HPC 负载下的扩展性表现为网络调优提供了可复现的实证数据。资源为单个 PDF 文件大小约 1.08MB已有 97 人学习下载无论用于方案预研还是实际部署调优都具有较强的参考价值。1. 在一台 vmware 虚拟机里跑 RDMA为什么绕不开 PVRDMA做 HPC 的人把 MPI Allreduce 压到一套虚拟化集群上时最先爆炸的往往是网络而不是 CPU。物理机上早就普及的 RDMA到了虚拟机里就变得别扭虚拟机想拿同等级别的 RDMA verbs 能力不可能靠给普通 vNIC 打补丁得靠 VMware 的 Paravirtual RDMAPVRDMA这条半虚拟化路线。它不算新但知根知底的人不多很多 vmware esxi 管理员对它的理解还停留在“加一块网卡试试”。PVRDMA 解决的是这样一类刚需客户机里的 MPI 库走 RDMA 通信绕开虚拟交换机和软件协议栈的两次拷贝让延迟从上百微秒压回微秒级带宽也尽量贴近物理网卡。它适合两种人——正在 vSphere 里搭训练集群、跑分子动力学或 CFD 的工程师以及已经把物理机跑得很好、想往虚拟机迁移 HPC 作业的运维。这篇文章按“原理是什么—怎么一步步配起来—参数怎么设—坑在哪”的顺序讲清楚中间会直接给出可复制的命令和参数表。2. PVRDMA 的原理边界半虚拟化到底让 HPC 网络多了什么、少了什么2.1 直通 vs 半虚拟化HPC 为什么不无脑选 passthrough如果只看峰值性能把物理 RNIC 以 PCI passthrough 方式直通给虚拟机是最直接的做法。VM 里的 OFED 栈直接访问硬件延迟和带宽都能做到和裸机几乎一致。但直通的问题不在性能在运维一块物理网卡只能给一台虚拟机用vMotion、快照、热迁移全部失效CPU 热添加也要看平台脸色。HPC 集群只要超过四五台机器管理员无论如何都想要在线迁移和统一镜像直通的边际成本就上来了。PVRDMA 是 VMware 在半虚拟化框架里给出的折中方案虚拟机里看到的是一块虚拟 RDMA 网卡QEMU/vmkernel 后端把 guest 的 RDMA 请求转成一组受控的 hypercall再由 ESXi 的 vmkernel RDMA 协议栈转发到物理 HCA。这里要冷静一点它不会比直通更快但它把“可迁移、可快照、可热插拔”这几项 HPC 基础设施的刚需保住了。对于大部分 MPI 工作负载PVRDMA 的带宽损耗可以压到个位数百分比延迟会落在 2~5 微秒量级远好过模拟 TCP。另一个常见误区是把 SR-IOV 和 PVRDMA 对立起来。SR-IOV 在 ESXi 里也能用把物理网卡拆成 VF 直通进 VM延迟很好但每个 VF 仍然占死一条物理链路而且 vMotion 还是受限管理面复杂度更高。PVRDMA 的定位就是把 RDMA 的语义保留给客户机把迁移和运维的自由度保留给平台。2.2 从 guest verbs 到物理网卡PVRDMA 数据路径上的两次减法理解 PVRDMA 的关键是看清数据从客户机里的 verbs API 到物理网卡之间走哪条路。在普通虚拟化网络里数据路径是这样的guest 进程 - 内核 TCP/UDP 栈 - vmxnet3 虚拟网卡 - vSwitch - 物理交换机RDMA 语义被丢掉了你在客户机里看到的“RDMA 网卡”其实只是一块以太网网卡MPI 库检测不到 RDMA被迫退化成 TCP socket。PVRDMA 把中间链路上的两层冗余逻辑砍掉了。第一guest 里的 OFED 驱动通过一个虚拟 RDMA 设备vRDMA直接注册内存和创建队列对不需要把数据先拷贝进 vmnic 的环形缓冲区第二hypervisor 后端拿到宿主机的物理 HCA跳过软件模拟的以太网转 VLAN 的过程把物理层语义直接接到 RoCE v2 或 InfiniBand 网络上。用一句话概括客户机认为自己拿到了一个真实的 RDMA 端口这个端口由 vmkernel 里的一个虚拟化代理在背后搬运。这个代理并不是简单的转发。它要做内存注册、DMA 映射、队列对的状态同步还要在多个 VM 之间复用同一块物理 HCA。所以 PVRDMA 迁移 VM 时不是冷迁移而是把 vRDMA 状态连同队列对信息一起打包迁移这就要求虚拟机和 ESXi 主机两侧都处于兼容的协议版本。这也是后面章节反复强调“别混装驱动”的原因。2.3 PVRDMA、SR-IOV 与软件 RoCE三条路线怎么选三条路线各有所长我按实际选型建议整理成一张表方便在方案评审时直接拿去对照对比维度PCI passthroughSR-IOV VFPVRDMA峰值性能最好接近直通约 90%-95%vMotion/快照不支持受限正常多 VM 共享一张物理卡不行可以看 VF 数可以运维复杂度低但死板高中等典型 HPC 场景单机极致性能网络团队已有 SR-IOV 规范需要迁移/管理弹性的生产集群软件 RoCESoftRoCE走的是纯模拟路线不碰物理 HCA延迟根本谈不上 HPC只适合没有硬件的功能验证我没放进对比表。如果你的集群已经有标准的 Mellanox/ConnectX 环境、物理网卡又多直通反而最省事但只要你需要 vMotion就老老实实规划 PVRDMA。做虚拟化 HPC 平台这两年我自己的默认选择就是全集群 PVRDMA物理网卡只负责上联VM 完全不感知具体宿主机。3. 从 ESXi 物理网卡到虚拟机 vNICPVRDMA 的最小部署路径3.1 把物理 RDMA 网卡放进 vSphere驱动与固件的两个前置检查在 vCenter 里看见“RDMA 网卡”之前物理主机先得让 ESXi 认识这块卡。大多数生产环境用的是支持 RoCE 的 ConnectX 系列或 QLogic 的 HCAESXi 里对应的驱动模块名通常是 nmlx5_coreMellanox 25G/100G或 qedf/qed。别一上来就配虚拟机先把物理主机的状态确认了再说。# 在 ESXi 主机 shell 里检查物理网卡是否能被 ESXi 识别 esxcli network nic list | grep -Ei mlx|roce|connectx|qed # 查看已安装的 RDMA 相关驱动模块 esxcli software vib list | grep -Ei rdma|mlx|qed这段命令不是配置动作是前置体检。第一句是确认 ESXi 已经看到物理 NIC 的 vendor 和型号第二句是看驱动是否有版本冲突。如果 grep 结果为空先别找虚拟机的问题物理驱动都没装上PVRDMA 后端代理根本没有可用的 HCA。常见做法是先到硬件厂商的 ESXi 兼容列表里核对 NIC 型号再把主机固件和 vSphere 版本更新到同一代。另外要检查主机 BIOS 里的 SR-IOV/IOMMU 开关。PVRDMA 依赖虚拟化 DMA如果 IOMMU 没开后面的队列对初始化会隔三差五报错。这个坑我是真踩过当时一台 Dell 服务器 BIOS 默认把 VT-d 关了PVRDMA 配置全对一跑 ib_write_bw 就断连开完 VT-d 后一切正常。3.2 在分布式交换机上给 RDMA 留一条 VMkernel 通道PVRDMA 在 vSphere 里不是建一个独立网卡就完事它需要一条从 VM 到物理 HCA 的转发路径。最省事的方式是直接把物理 RDMA 网卡添加到一个 vSphere Distributed SwitchVDS再给 VDS 配置一个承载 RDMA 流量的 VMkernel 适配器。在 vCenter 里的操作路径一般是主机 - 网络 - 虚拟交换机 - 添加分布式交换机把物理 RDMA 网卡设为上行链路然后在该 VDS 上新建 VMkernel 适配器指定一个与 RoCE 网络同网段的 IP。这里要注意RoCE 流量通常要求无损网络所以 VDS 上的 MTU 建议直接设成 9000不要用默认 1500 让 RDMA 报文被分片。配置完以后在 ESXi shell 里验证一下# 查看 VMkernel 地址是否就绪 esxcli network ip interface list # 看看 VDS 上物理网卡是不是已成功绑定 esxcfg-vmknic -l如果看到 VMkernel 口有地址、物理链路是 up但 VDS 上没有任何上行链路激活通常是因为物理网卡被 vSphere 默认当成了普通以太网口没有开启 RDMA 标记。在 VDS 的物理网卡设置里需要确认“RDMA 卸载”或“PVRDMA”相关的策略项为启用这个参数在标准交换机上不存在必须用分布式交换机。所以别拿 vSwitch0 硬扛。3.3 新建一台带 PVRDMA 网卡的虚拟机参数表与客户机要求干净环境下的最小部署就是三件事建 VM、加一块 PVRDMA 网卡、在客户机里装 RDMA 驱动。网络适配器类型选择里VMware 会把这块虚拟网卡列成 “VMXNET3PVRDMA” 或 “PVRDMA”看 vSphere 版本显示略有差别本质都是同一个半虚拟化 RDMA 设备。给一个我常用的参数表参数项建议值说明网卡类型PVRDMA / VMXNET3 PVRDMA选错成普通 VMXNET3 就没有 RDMA 语义队列对数量4起步生产按 vCPU 数上调太多反而增加 vmkernel 上下文切换MTU9000不设置会在 RoCE 交换机上产生分片客户机驱动与 ESXi 驱动同版本线混版是“大头”见第 5 章内存全部保留/锁定优先防止 balloon 回收影响延迟网卡 MAC分配一个新的 MAC不要克隆克隆会引入链路层冲突客户机这边Linux 建议直接用发行版仓库里的 rdma-core 或官方 OFEDWindows 则要装 WinOFED 且注意和 vSphere 的版本匹配。装完后不要急着配 IP先ibstat看设备如果客户机里根本没有 ib 设备返回去查网卡类型。一个很容易忽略的步骤是给 VM 的 vCPU 设置 NUMA 亲和性。PVRDMA 的 DMA 通路会绑定到物理 HCA 所在的 NUMA node如果虚机 vCPU 跑在另一个 node跨 node 访问 HCA 内存会让延迟涨一倍不止。vSphere 里开启“每插槽核心数”并按物理机的 NUMA 拓扑来分配核能显著降低尾部延迟。4. 客户机内的性能验证与三个必调参数用数字代替“感觉很快”4.1 先确认你看到的确实是 RDMA 设备而不是一块普通 vNIC不少人在客户机里装完驱动就跑结果 MPI 默默走 TCP 也不知道。判断标准很简单看看客户机里有没有一个真实存在的 RDMA 设备。Linux 下用ibstat和ibv_devinfo两个命令几十秒就能看出真相。# 输出所有 RDMA 设备状态Port 1 的 State 必须是 ACTIVE ibstat # 查看设备细节端口数、固件版本、MTU 上限 ibv_devinfo -v | head -50如果ibstat显示没有设备多半是选错了网卡类型回去把网卡改成 PVRDMA如果设备存在但 State 是 DOWN问题在物理链路或者 vSwitch 的 MTU而不是客户机配置。设备名通常是 mlx5_0 或 rdma0取决于客户机的驱动模型。看到 ACTIVE 之后再确认一下是否有多余的普通以太网卡占着 MPI 的首选路径MPI 库往往会按接口名找设备这一步最好通过ibv_devinfo -p拿到端口对应的 GID 索引再和你期望的 RoCE 网络对一下。4.2 用 ib_write_bw 跑通一套最小读写基准确认设备 ACTIVE 以后下一步就是让两台 VM 之间跑通 RDMA 读写用数字说话。Mellanox OFED 自带的 perftest 里ib_write_bw是测写带宽、ib_read_bw是测读带宽两个都要跑一次才算完整。先在一台 VM 上起服务端# 服务端监听 rocev2 网络 ib_write_bw -d mlx5_0 -p 18515 --report_gbits -D 60 # 关键参数解释 # -d 指定设备名-p 指定端口--report_gbits 以 Gb/s 展示带宽-D 60 表示跑 60 秒另起一台 VM 做客户端# 客户端指定对端 IP ib_write_bw -d mlx5_0 -p 18515 --report_gbits -D 60 10.20.30.40 # 这里 10.20.30.40 是服务端的 VMkernel IP 或客户机 IP取决于你的 RoCE 网络规划第一次跑通后先看报告末尾的 average 带宽。物理 100Gb RoCE 网卡在 PVRDMA 下跑到 80~90 Gb/s 是合理的50Gb 网卡跑到 40 Gb/s 上下也算正常。如果带宽只有个位数别怀疑优化先按下面的必调参数从头捋一遍。测试时建议把两台 VM 放在不同宿主机上验证跨主机路径放同一台宿主机上测出来的数字只能代表 vmkernel 内部的转发能力对生产环境意义不大。还有一个容易误判的点ib_write_bw默认用单队列对单连接测的是极限带宽MPI Allreduce 这类短消息场景更要关注延迟得用ib_write_lat或ib_send_lat测。这两个命令参数结构一样只是结果单位换成了微秒。PVRDMA 的单向延迟能做到 3~5 微秒比裸机高一点但远低于虚拟交换机的 20 微秒以上。4.3 三个必调参数队列对数量、MTU 与 NUMA 亲核很多人在 PVRDMA 上“感觉慢”其实不是虚拟化层慢是参数没对。第一个必调参数是队列对数量。perftest 里可以用-q 4指定多个 QPMPI 库里则通过UCX_IB_NUM_PATHS或 OpenMPI 的--mca pml_ucx控制。切记别一上来开 16 个 QP多 QP 在多 vCPU 上确实能提升并行度但 PVRDMA 后端要为每个 QP 维护状态过量后 vmkernel 的上下文切换反而吃掉吞吐。第二个必调参数是 MTU这可能是 HPC 里最不值得犯却最常犯的错。客户机的ibv_devinfo能看到 MTU 上限RoCE v2 通常支持 4096底层网络要按 4096 配 VDS 的 MTU9000 是以太网 MTU 的说法RDMA 的 MTU 单位是字节指的是 BTH 不超过 4096两者不要混。如果底层交换机没有开 PFC 或有损转发大 MTU 的报文在重传时损耗会放大所以要在交换机侧和无损配置一起调。第三个必调参数是 NUMA 亲核。HCA 上一个 PCIe 功能和 PCIe root complex 的 NUMA node 是固定的虚拟机要尽量把 vCPU 和客户机内存都钉在同一个 node。vSphere 里在虚机属性里设置“NUMA 亲和性”并选“指定和物理机一致的拓扑”同时通过numactl --cpunodebind0 --membind0起 MPI 进程能稳定改善 10% 到 20% 的延迟。这个参数在测试时要固定调优时否则分不清是 NUMA 作用还是负载波动。5. PVRDMA 上线前最容易翻车的 5 个现场现象与排查5.1 guest 能看到 IPibstat 却看不到端口现象客户机里 IP 配好了ping 对端也通但ibstat就是报 no device或者 Port 显示 DOWN。原因这通常是网卡类型选错了排第一。vCenter 里默认加的是 VMXNET3PVRDMA 和 VMXNET3 会共享同一张虚拟网卡的外观但语义完全不同。VMXNET3 只提供以太网收发没有 RDMA 后端代理客户机的 OFED 拿到设备列表时自然看不到 RDMA 端口。也有一种情况是 PVRDMA 网卡加对了但物理主机的 HCA 没有被加入 VDS 上行链路导致后端没有可用的链路。解决先把虚拟机关机在 vCenter 里把网络适配器改成 PVRDMA开机再查ibstat。如果只是链路 down去 VDS 的物理网卡配置里把 RoCE 策略打开或者检查上行链路是否被 vSphere 标记为已激活。5.2 带宽只有直通的一半延迟毛刺明显现象ib_write_bw 测出来带宽 40Gb 的卡只有 20Gb延迟抖动却比直通高一倍。原因最大的嫌疑是 MTU 没对齐。RoCE v2 的报文到了客户机网络接口时如果 MTU 低于 RDMA 需求底层就会把报文拆成 Ethernet frames性能直接腰斩。另一个常见原因是 vCPU 数量太少或 NUMA 不亲和。PVRDMA 需要在数据路径上做 DMA 映射和队列调度这个开销度和 vCPU 调度是强相关的VM 只给 2 个 vCPU 时会频繁产生 vm-exit。解决在 VDS 和 VM 两侧同时把 MTU 调成 9000对应 Ethernet MTU再按第 4 章里的 NUMA 方法设置亲和性。如果还不行把队列对数量从默认 1 逐步加到 4 试试但别超过 vCPU 数量。这一套组合在我经手的集群里消化了九成以上的性能抱怨。5.3 迁移或快照后 RDMA 通信中断现象一台 VM 做了 vMotion 或打了快照之后回滚MPI 作业立刻断连重试几次才能恢复。原因PVRDMA 的设计目标是支持迁移但迁移过程会回收和重建队列对。客户机里的 OFED 驱动如果对状态重建的处理不健壮或虚拟机和宿主机之间的 PVRDMA 协议版本不一致迁移后队列对就起不来。有时候是 vMotion 过后物理 HCA 更换了 GUID客户机里的 GID 表没刷新。解决迁完之后先跑一遍ibv_devinfo确认设备状态变成 ACTIVE。如果挂了重启客户机里的 RDMA 服务是最快的恢复手段。要根治的话注意 ESXi 主机版本要一致别在混版本集群里做 vMotion生产环境建议对 RDMA VM 关闭自动 vMotion改为维护窗口里手动迁移。5.4 客户机 mlx5 驱动与 ESXi 固件版本打架现象客户机 OFED 装好后加载驱动时报Cannot initialize RDMA device或firmware version mismatch。原因PVRDMA 后端和客户机驱动本质上是一对约定好协议的通信端不完全是同一颗芯片的驱动层。少数情况下宿主机上的 nmlx5_core 驱动较旧客户机里新装 OFED 的某种协议用不上于是加载失败。这类问题在混合使用官方 OFED 和发行版 rdma-core 的机器上特别多。解决先看 ESXi 里 RDMA 驱动版本和 OFED 的兼容矩阵两边对齐之后再重装。一个稳妥习惯是凡是打算上 PVRDMA 的 VM都用同一套安装脚本装 OFED别今天 apt 装明天源码装。下次升级内核前先看驱动兼容说明优先跑一次modinfo mlx5_ib确认版本再动。5.5 内存回收导致的 latency spike被 HPC 作业放大现象运行时间一长MPI 的延迟尾标从 5 微秒涨到 100 微秒带宽没掉但任务卡顿明显。原因PVRDMA 需要把 guest 内存 pin 住才能做 DMA 操作如果加了气泡虚拟机内存或用到了 vSphere 的透明页共享内存管理线程会不定期回收这些页触发一次 RDMA 重注册。开销不大但每次都会压住数据路径。解决虚机内存设置成“全部锁定”或“预留”同时把它放到不开启 TPS 的集群里。更彻底的做法是限定客户机内存大小别让 balloon driver 介入。这个坑不容易被监控发现要看好 lat spike 的周期性节奏再反查宿主机内存统计。6. 把验证动作固化让 PVRDMA 性能不靠“玄学”到了这里原理、部署和排错都有了最后我习惯做一件事把验证动作变成一套固定脚本每次新建 RDMA 虚拟机后直接跑一遍把输出留档。这样既能在交付时给用户一个确认基准也方便后面做性能回归。#!/bin/bash # rdma_selftest.shPVRDMA 部署后的最小健康检查 echo RDMA device ibstat || exit 1 echo I/O bandwidth quick test # 对端 IP 作为第一个参数传入 ib_write_bw -d mlx5_0 -q 4 --report_gbits -D 10 $1 echo latency quick test ib_write_lat -d mlx5_0 -q 4 $1脚本逻辑很简单但覆盖面足够先确设备存在再验证带宽和延迟基准。它在团队新成员加入时特别有用——不需要理解 vmkernel 细节照着脚本跑一遍就知道这块 PVRDMA 是不是健康。这套脚本执行完把输出归档到集群配置库里作为网络层的基线数据。我个人的习惯是每次物理机换固件或 vSphere 小版本升级之后都挑一台最小 VM 跑这个自检再做集群级别升级。因为 PVRDMA 是半虚拟化协议宿主机的行为变更很难从 UI 里看出端倪只有端点间基准数字的变化最诚实。你不需要把每个 RDMA 参数都背下来但你要有办法让每次改动后的结果可见。这些年折腾下来最大的教训其实是参数少比多好队列对数量从 4 起步MTU 对齐到 4096NUMA 明确绑定比在虚拟交换机上堆一堆 QoS 策略更管用。希望这些实测经验能帮到正在和虚拟化 HPC 延迟较劲的各位。本文还有配套的精品资源点击获取