OpenNebula (KVM) + OpenvSwitch，高頻寬使用時的高 CPU 負載
我們在 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 模型，如下所述：
NIC_DEFAULT = [ MODEL = "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 乙太網時非常常見的配置。