VM パフォーマンス Day5 – virtio-net の構造と仮想 NIC の性能特性

VM のネットワーク I/O は、CPU やストレージとは違う形で性能が頭打ちになります。帯域だけでなく、pps、割り込み、コピー回数、QEMU スレッド、ホスト側ネットワークスタックが重なるためです。

virtio-net は KVM / QEMU 環境で標準的に使われる仮想 NIC です。汎用性が高く扱いやすい一方で、パケット処理の経路が長く、pps が増えると CPU 側の負荷が見えやすくなります。

Day5 では、virtio-net の構造と限界を整理し、Day6 以降で扱う vhost-net、vhost-user、SR-IOV、DPDK がなぜ必要になるのかを確認します。

virtio-net は仮想 NIC の標準的な入口

virtio-net は、ゲスト OS に仮想 NIC を見せるための paravirtualized device です。ゲスト OS は virtio-net ドライバを通じてパケットを送受信し、QEMU やホスト側の datapath が実際の物理 NIC へ処理をつなぎます。

レイヤ	役割
ゲスト OS	virtio-net ドライバで仮想 NIC を扱う
virtqueue	ゲストとデバイス側が共有するリング構造
QEMU	virtqueue 処理とホスト側 I/O への橋渡し
ホスト OS	bridge、tap、OVS、物理 NIC へ転送する
物理 NIC	実際の Ethernet フレームを送受信する

この構造は汎用性が高く、ライブマイグレーションや通常の仮想ネットワーク構成と相性が良いです。一方で、パケットごとに複数のレイヤを通るため、高 pps 環境では処理コストが積み重なります。

virtqueue は共有リングで I/O を受け渡す

virtio-net の中心には virtqueue があります。virtqueue は、ゲスト OS とデバイス側が共有するリング構造で、パケットバッファの場所や処理状態を受け渡します。

• descriptor はバッファのアドレスや長さを示す
• available ring はゲスト側が処理してほしいエントリを示す
• used ring はデバイス側が処理済みエントリを返す
• 送信用 queue と受信用 queue が分かれる
• multiqueue により複数 CPU へ処理を分散できる

ストレージ I/O と同じく、virtio は共有メモリ上のキューを使うことでエミュレーションの負荷を下げます。ただし、ネットワーク I/O は小さいパケットが高頻度に流れるため、キュー更新や割り込みの頻度が問題になりやすいです。

virtio-net が遅くなる理由

virtio-net の性能問題は、帯域不足というより、パケット処理に必要な CPU コストとして現れることが多いです。特に小さいパケットが多い環境では、Gbps より pps が先に限界になります。

QEMU スレッドが処理を抱える

単純な virtio-net 構成では、QEMU が virtqueue の処理やホスト側 I/O への橋渡しを担います。pps が増えると、QEMU スレッドが忙しくなり、VM のネットワーク性能が QEMU 側の CPU 処理に引っ張られます。

ユーザー空間とカーネル空間を行き来する

QEMU はユーザー空間で動作し、tap、bridge、OVS、物理 NIC などはホストカーネル側の処理と関係します。この境界を行き来することで、コンテキストスイッチやデータ受け渡しのコストが発生します。

割り込みとキュー処理が増える

ネットワーク I/O では、パケット到着、送信完了、queue 更新などのイベントが高頻度に発生します。割り込みや通知が多すぎると、実データ転送よりも制御処理に CPU を使う状態になります。

コピー回数が増える

パケットが複数のレイヤを通るほど、メモリコピーやバッファ管理が増えます。ゼロコピーに近づける方式ほど性能は上がりやすくなりますが、その分、構成や運用の自由度は下がります。

virtio-net のメリット

virtio-net は高性能 dataplane の最終形ではありませんが、汎用 VM の標準構成としては非常に優れています。

• 多くの Linux 環境で標準的に使える
• 仮想ネットワーク構成と組み合わせやすい
• ライブマイグレーションや通常運用と相性が良い
• SR-IOV や DPDK より制約が少ない
• 性能と運用性のバランスが良い

つまり、virtio-net は低性能な方式ではなく、汎用性と運用性を重視した標準的な方式です。問題は、高 pps、低遅延、NFV、パケット処理集約のような用途では、標準構成の経路が長すぎることです。

multiqueue と CPU 配置も重要になる

virtio-net では multiqueue を使うことで、複数の queue を複数 CPU に分散できます。これにより、単一 queue や単一 QEMU スレッドに処理が集中することを避けやすくなります。

ただし、multiqueue も CPU / NUMA / IRQ の配置と合わせて考える必要があります。queue を増やしても、割り込み処理や vCPU が別 NUMA に散っていれば、期待した効果は出にくくなります。

• vCPU 数と queue 数の関係を見る
• IRQ の処理 CPU を確認する
• NUMA をまたがないように配置する
• QEMU thread と vCPU の配置を確認する
• pps と CPU 使用率を合わせて見る

virtio-net の限界が vhost へつながる

virtio-net の限界は、QEMU がパケット処理の中心に残ることです。そこで Day6 では、virtio の処理をカーネル側へ寄せる vhost-net と、ユーザー空間 dataplane へ寄せる vhost-user を扱います。

方式	考え方	位置づけ
virtio-net	QEMU を中心に仮想 NIC を処理する	標準的で運用しやすい
vhost-net	virtio 処理をカーネル側へ寄せる	QEMU の負荷を減らす
vhost-user	ユーザー空間 dataplane と接続する	DPDK / OVS-DPDK へつながる
SR-IOV	NIC の VF を VM に直接割り当てる	仮想化レイヤを大きく迂回する
DPDK	ユーザー空間で高速 dataplane を作る	NFV や高 pps 用途に向く

設計時の確認ポイント

virtio-net の性能を見るときは、帯域だけではなくパケット処理の負荷を確認します。

• 問題は Gbps なのか pps なのか
• 小さいパケットが多いのか、大きいパケット中心なのか
• QEMU スレッドが CPU ボトルネックになっていないか
• 割り込みや softirq が偏っていないか
• multiqueue が有効で、CPU 配置と合っているか
• virtio-net の運用性を残すべきか、vhost / SR-IOV / DPDK へ進むべきか

まとめ

virtio-net は、KVM / QEMU 環境における標準的な仮想 NIC です。汎用性、運用性、移動性に優れており、多くの VM では十分に合理的な選択肢です。

一方で、高 pps、低遅延、NFV、パケット処理集約のような用途では、QEMU、virtqueue、割り込み、コピー、ホスト側 datapath のコストが目立ちます。

ネットワーク I/O 最適化では、まず virtio-net の構造と限界を理解し、そのうえで vhost-net、vhost-user、SR-IOV、DPDK のどこまで進むべきかを判断する必要があります。Day6 では、virtio の処理を QEMU から外へ逃がす vhost-net / vhost-user を整理します。

VM パフォーマンスシリーズ

• VM パフォーマンス最適化 – NUMA / CPU / I/O / ネットワークの設計ハブ
• VM パフォーマンス Day1 – VM の性能ボトルネックとは何か
• VM パフォーマンス Day2 – CPU 最適化と NUMA / CPU ピニングの考え方
• VM パフォーマンス Day3 – メモリ最適化と HugePages / TLB / NUMA の考え方
• VM パフォーマンス Day4 – ストレージ I/O 最適化と virtio / raw / qcow2 / io_uring の考え方
• VM パフォーマンス Day6 – vhost-net / vhost-user と kernel bypass の考え方
• VM パフォーマンス Day7 – SR-IOV / PCI Passthrough による仮想化の迂回
• VM パフォーマンス Day8 – DPDK による高速 dataplane と NFV の基本

関連記事

• VyOS VPP 導入検討 – 実運用ルーターに VPP をそのまま適用する難しさ
• パブリッククラウド上で NFV 型 NF は成立するのか – アンダーレイ / オーバーレイ / 帯域制約で考える
• AWS EC2 は帯域確保サービスの基盤として使えるのか – baseline / burst / flow 制約で考える