NIC Teaming与SR-IOV不可共存，前者通过软件聚合提升带宽冗余，后者通过硬件直通降低延迟、减少CPU开销；选错方案会导致性能下降或功能失效。
hyper-v 环境下实现网络带宽聚合，核心路径只有两种：nic teaming（网卡聚合）和 sr-iov（单根 i/o 虚拟化），但二者不可共存，适用场景和底层机制完全不同，选错会导致性能不升反降甚至功能失效。
NIC Teaming：面向高可用与带宽叠加的软件层聚合
NIC Teaming 将多个物理网卡逻辑绑定为一个接口，主要目标是提升冗余性与总吞吐量。它工作在主机操作系统层，流量仍需经过 Hyper-V 虚拟交换机处理。
- 支持最多 32 块不同厂商、不同速率的网卡（包括有线/无线，但不建议混用无线）
- 提供两种主流模式：与交换机无关模式（适合无管理交换机或仅需故障切换的场景）和依赖交换机模式（推荐 LACP，自动协商链路状态，更健壮）
- 负载分发策略影响实际效果：地址散列模式出站均衡、入站单卡；Hyper-V 端口模式按虚拟机绑定到特定物理网卡，适合多 VM 场景但单 VM 不超单卡带宽
- 注意：Teaming 必须在宿主机上配置，不能在虚拟机内做；且启用后，虚拟交换机的“带宽管理”和 QoS 策略仍可叠加使用
SR-IOV：面向低延迟与高吞吐的硬件直通方案
SR-IOV 绕过虚拟交换机，让虚拟机直接访问物理网卡的虚拟功能（VF），获得接近物理网卡的性能，特别适合对延迟敏感、CPU 利用率偏高的场景。
- 必须满足三要素：BIOS 中启用 SR-IOV、网卡固件/驱动支持、Windows Server 支持（2016 及以上更稳定）
- 创建外部虚拟交换机时即需勾选“启用 SR-IOV”，已建的普通 vSwitch 无法后期开启
- 一旦启用 SR-IOV，虚拟交换机上的 ACL、扩展策略、端口镜像等功能将自动禁用——因为流量不再流经交换机
- 宿主机层面禁止对两个 SR-IOV 网卡做 Teaming；但可在虚拟机内部对两个 VF 网卡做聚合（如 Linux 的 bond 或 Windows 的 LBFO）
vRSS 与 dVMQ：提升多核并行处理能力的关键补充
单纯堆叠带宽不够，还要让虚拟机真正“吃得下”。vRSS（虚拟接收端扩展）和 dVMQ（动态虚拟机队列）就是解决单 vCPU 瓶颈的核心技术。
- vRSS 在虚拟机内部启用，将入站网络中断分散到多个 vCPU，实测可使 10 Gbps 网卡带宽从不足 2 Gbps 提升至接近满速
- dVMQ 作用于宿主机，按 MAC 地址哈希把流量分配到不同 CPU 队列，避免单核饱和，对多 VM 入向密集型负载（如 Web 前端、API 网关）效果显著
- 注意：主机分区（即宿主机本身）不支持 vRSS；若在宿主机上运行服务并连接虚拟交换机，其每个虚拟网卡仍受限于单核处理能力
实际配置中的关键避坑点
很多性能问题不是技术不行，而是组合错误或细节遗漏。
- Teaming 和 SR-IOV 互斥：两者资源调度逻辑冲突，强行共存会导致 SR-IOV 失效或 Teaming 降级为单卡模式
- 网卡驱动和固件必须更新：旧版驱动常导致 LACP 协商失败、VF 分配异常或 vRSS 不生效
- 不要在启用了 SR-IOV 的 vSwitch 上设置 VLAN 或 QoS：这些策略无效，还可能引发不可预知的转发行为
- 虚拟机网卡类型要匹配：SR-IOV 只支持合成网卡（Synthetic NIC），传统网卡（Legacy NIC）无法使用；vRSS 也仅对合成网卡生效
