虚拟化环境网卡选型：SR-IOV 直通方案完全解析

虚拟化环境网卡选型：SR-IOV 直通方案完全解析

凌晨两点，运维老周被监控告警吵醒——生产集群里三台虚拟机的网络延迟同时飙到了 80ms，数据库写入超时，前端页面报 502。登录 vCenter 一看，宿主机 CPU 的 %steal 时间跑到了 27%，物理网卡吞吐已经顶到了 980Mbps。

这不是偶发。每次业务高峰期批量创建快照或部署 VM，网络就剧烈抖动。加了四台物理服务器分摊负载，问题只是从"彻底瘫痪"变成了"间歇性抽风"。

问题不是网卡坏了，而是传统软件交换路径在密集虚拟化场景下根本撑不住。

虚拟化网络 IO 瓶颈到底在哪

虚拟机之间的网络流量要经过一条很长的路径：

VM 内应用发数据 → 虚拟网卡驱动 → vSwitch（软件交换）→ Hypervisor IO 栈 → 物理网卡驱动 → 网卡硬件

每多一层转发，就多一次 CPU 中断和内存拷贝。一台宿主机跑 20 台 VM 都在做网络 IO 时，vSwitch 成了单点瓶颈——所有流量串行通过软件处理，CPU 核心被网络中断占满，VM 自己的计算任务反而抢不到时间片。

这就是 %steal 时间飙高的直接原因。hypervisor 在和 VM 争 CPU，因为网络 IO 占用了太多核心资源。

更隐蔽的问题是尾延迟（tail latency）。软件交换的延迟均值也许只有几百微秒，但峰值可以跳到几十毫秒——排队的包多了处理不过来。对数据库和实时应用来说，峰值延迟比均值更致命。

SR-IOV 为什么能绕过这个瓶颈

SR-IOV（Single Root I/O Virtualization）的思路很直接：让网卡硬件替 hypervisor 干虚拟交换的活，VM 直接和硬件对话。

网卡上电后注册一个 Physical Function（PF），同时创建多个 Virtual Function（VF）。每个 VF 是一份"轻量级网卡"，拥有独立的队列、中断和内存映射空间。hypervisor 把 VF 直通分配给 VM 后，VM 内的驱动可以直接操作 VF 的寄存器，数据进出不经过 hypervisor 的软件栈。

传统路径像是所有 VM 共用一个收发室，所有包裹都要经过收发室分发；SR-IOV 相当于给每个 VM 开了一个专属通道，包裹直接送到门口。

代价是 VM 之间的流量隔离要靠物理网卡的硬件交换能力。如果网卡不支持硬件桥接，同宿主机 VM 互访的流量也要绕到外部交换机再回来。所以选型时要注意网卡是否支持嵌入式交换（L2 forwarding）。

适合 SR-IOV 的网卡怎么选

不是所有网卡都支持 SR-IOV。选型时看三个指标：芯片方案是否原生支持 SR-IOV、PCIe 带宽是否够用、端口密度是否匹配 VM 数量。

以下四款 LR-LINK 网卡在主流 hypervisor（VMware ESXi、KVM、Hyper-V）下 SR-IOV 功能正常：

LRES1001PF-2SFP28 是目前虚拟化场景的甜点级选择。25G 每端口线速转发，单根 PCIe 3.0 x8 插槽吞吐余量充足，单端口可创建 64 个以上 VF。如果服务器有 OCP 插槽，LRES3029PF-OCP 提供相同的 SR-IOV 能力，不占标准 PCIe 槽位。

LRES1027PF-4SFP28 适合 VM 密度超过 40 台的场景。四口 25G 最多可分配 256+ 个 VF，但 PCIe x8 3.0 总带宽约 64Gbps，四个端口共享。实际部署时建议拆分：两个端口做 VM 业务，一个做存储网络，一个留作管理或热备。

从 BIOS 到 VM 的部署要点

SR-IOV 部署不复杂，但有几个容易踩坑的地方。

BIOS 层： 打开 VT-d（Intel）或 SVM（AMD），确保 PCIe ACS（Access Control Services）启用。这一步漏了 SR-IOV 根本起不来。

网卡层： 安装驱动后，用 lspci 或 ESXi 的 esxcli 确认 PF 已识别。VF 数量按 VM 数量加 20% 余量配置：

# Linux 下创建 16 个 VF
echo 16 > /sys/class/net/ens785f0/device/sriov_numvfs

Hypervisor 层： vCenter 中进入主机设置 → 网络 → SR-IOV，设置 PF 的 VF 数量。给 VM 添加"直通设备"类型的网卡，选中对应的 VF。

Guest OS 层： VM 内安装 VF 驱动。Windows 下通常自动识别，Linux 执行 modprobe iavf。用 ethtool -i eth0 确认驱动是 VF 版本。

热迁移限制： SR-IOV 直通后标准 vMotion 无法迁移绑定了 VF 的 VM。需要 ESXi 6.5 以上配合 vMotion with SR-IOV pass-through 特性，迁移前卸载 VF，迁移后重新挂载。频繁热迁移的场景建议保留部分 VM 走传统 vSwitch。

SR-IOV 架构与传统路径对比

切换到 SR-IOV 直通后关键指标改善明显：CPU 开销从 20%+ 降到 3% 以下，25G 端口线速转发，尾延迟（P99）从数毫秒稳定在 50μs 以内。这些改善是结构性的——SR-IOV 的原理决定了只要配置正确都能达到类似效果。

直通还是软件交换：按场景决定

SR-IOV 不是万能的，有些情况更适合传统 vSwitch：

适合全量直通：

• 数据库集群节点（延迟敏感）
• 分布式存储节点（带宽敏感，需要 RDMA）
• 视频转码 / 媒体处理（吞吐量大）

建议保留软件交换：

• 需频繁 vMotion 热迁移的 VM
• 网络策略复杂、需要分布式防火墙的 VM
• 监控 / 安全扫描类 VM（流量需经过 hypervisor 做包检测）

折中方案是混合部署——同台宿主机上，部分 VM 走 SR-IOV 直通，部分走 vSwitch。网卡端口够多的话可以给两种路径分配不同物理端口，互不干扰。

技术选型的目标不是选"最先进的"，而是选"最合适的"。

常见问题

SR-IOV 需要什么样的网卡支持？

需要网卡硬件原生支持 SR-IOV，通常是 Intel X710 / XXV710 / E810 等方案。LR-LINK 的 LRES1001PF-2SFP28 和 LRES1012PT 均通过验证，在主流 hypervisor 下 SR-IOV 功能正常。消费级网卡（如 Intel I210、Realtek 系列）不支持 SR-IOV，选购时注意区分。

SR-IOV 直通后 VM 还能做 vMotion 热迁移吗？

可以，但有条件。VMware ESXi 6.5 以上支持 SR-IOV pass-through 热迁移，迁移前需卸载 VF，迁移后重新挂载。KVM 环境需要 libvirt 配合。频繁热迁移的场景建议对部分 VM 保留传统 vSwitch 路径。

一个 PF 能创建多少个 VF？

不同芯片上限不同。Intel X710 系列单端口最多 128 个 VF，XXV710 和 E810 系列最多 256 个。实际使用按 VM 数量加 20% 余量配置即可——VF 太多每个分到的队列反而少，影响性能。

25G 和 10G SR-IOV 网卡实际差距大吗？

取决于 VM 密度和 IO 模型。每台宿主机只跑 5-6 台轻量 VM 的话，10G 配 SR-IOV 已够用。跑 20 台以上 VM 或有数据库/存储节点时，25G 的价值明显——带宽翻 2.5 倍，更多队列数意味着每台 VM 分到独立硬件队列，延迟隔离更好。

本文涉及产品

• LRES1001PF-2SFP28 — 25G / SFP28 / 双口 / PCIe 3.0 x8
• LRES1027PF-4SFP28 — 25G / SFP28 / 四口 / PCIe 3.0 x8
• LRES1012PT — 10G / RJ45 / 双口 / PCIe 3.0 x8
• LRES1025PT — 10G / RJ45 / 双口 / PCIe 2.0 x8
• LRES3039PF-OCP — 10G / SFP+ / 双口 / OCP 3.0
• LRES3029PF-OCP — 25G / SFP28 / 双口 / OCP 3.0