我们在 Ubuntu 16.04 上运行 OpenNebula 5.0.2 环境，使用 OpenvSwitch 2.5 桥接虚拟接口和 LACP 中继两个 Gbit 端口，运行良好。
但是当我在虚拟机和它的主机之间运行 iperf3 带宽测试时，htop 显示运行该虚拟机的 qemu 的 CPU 负载为 100%，而 iperf3 仅获得 100-200 Mbps，即使没有其他高带宽需求的虚拟机正在运行。两个 VM 主机之间的 iperf3 让我几乎满载 1 Gbps 并且没有 CPU 负载。
当我们还在 2.0.2 上时，我曾经认为这是一个 OpenvSwitch 问题，但现在我认为它缺少一些虚拟网络优化......
我可以成功（并且轻松地，无需更换 NIC 等）应用的一项巨大优化是默认情况下对 VM 模板中的所有 NIC 或每个 NIC 使用 virtio 模型，如下所述：
对于已经实例化的 VM，请将其关闭，分离所有 NIC 并使用“virtio”模型重新连接它们。
在我的第一次测试中，它将主机和来宾之间的 iperf3 带宽增加到 5.6 Gbps，并且在测试期间将主机 CPU 负载降低到每个 qemu 线程约 50-60%（< 5% @ 几乎 1 Gbps 从 Gbit 连接的主机运行 iperf3 客户端）。
如果您知道进一步的优化，请随时添加它们！
任何必须通过虚拟桥梁的东西都会受到很大的打击。ovs 和 linux 桥接也是如此，因为它们都必须在混杂模式下执行数据包检查以确定需要去哪里（本质上是第 2 层交换机）。
在高性能场景中，例如使用 10Gib 以太网，执行 srv-io 设备传递而不是让主机操作系统在第 2 层上切换有时是谨慎的做法。这样做的缺点是只有这个来宾可以使用传递的以太网卡片。PCI passthrough 非常适合网卡，而 KVM / libvirt 在这方面表现出色。
Macvtap 还可以将流量直接传递到来宾 VM，几乎没有开销，并且不使用 srv-io PCI 直通（因此您不必将硬件专用于单个 VM）。Macvtap 的局限性在于它永远无法提供主机到客户的通信，甚至是同一管理程序中的客户到客户（因为它使用主机的相同 MAC 地址，而不是通过虚拟交换机为每个客户使用不同的 MAC 地址）。解决此问题的一种方法是在交换机级别执行“发夹”（如果您的交换机支持它），允许设备通过单个端口和单个 MAC 地址上的某种环回与自身通信。
对于使用我上面提到的这些方法中的任何一种时的主机和来宾相互通信，通常会为不用于高性能通信的网络提供额外的桥接网络。这实际上是在 VM 上使用 >=10Gib 以太网时非常常见的配置。