VM パフォーマンス Day7 – SR-IOV / PCI Passthrough による仮想化レイヤの迂回

Day6 では、virtio の処理を QEMU からカーネル側やユーザー空間 dataplane へ逃がす vhost-net / vhost-user を整理しました。Day7 では、さらに一段進んで、仮想化レイヤそのものを大きく迂回する SR-IOV / PCI Passthrough を扱います。

SR-IOV や PCI Passthrough は、性能面では強力な選択肢です。一方で、ライブマイグレーション、可観測性、ネットワーク制御、障害切り分け、リソース管理の前提を大きく変えます。

ここで重要なのは、速いかどうかだけではありません。物理デバイスを VM へ近づけるほど、仮想化基盤が提供していた抽象化と運用自由度を手放すことになります。

SR-IOV は NIC が VF を生成する仕組み

SR-IOV は Single Root I/O Virtualization の略で、1 つの物理 NIC から複数の Virtual Function を作り、それを VM に直接割り当てる仕組みです。

用語	意味
PF	Physical Function。物理 NIC の管理側機能
VF	Virtual Function。VM に割り当てる軽量な PCIe デバイス
IOMMU	デバイス DMA を VM のメモリ空間へ安全に割り当てるための仕組み
DMA	デバイスが CPU を介さずメモリへ直接アクセスする仕組み

VF はゲスト OS から PCIe デバイスとして見えます。そのため、virtio-net や QEMU の datapath を通らず、NIC のハードウェアキューに近い形で通信できます。

SR-IOV の datapath

SR-IOV の datapath は、virtio-net や vhost-net より短くなります。VM は VF を通じて NIC のハードウェアキューを扱い、パケットは仮想 NIC の抽象化レイヤを大きく迂回します。

方式	datapath の考え方
virtio-net	VM から QEMU / ホスト datapath を経由する
vhost-net	virtio 処理を kernel 側へ寄せる
vhost-user	ユーザー空間 dataplane と接続する
SR-IOV	VF を VM に割り当て、NIC ハードウェアに近づける

この短い datapath により、pps や latency の面で有利になりやすくなります。特に NFV、仮想ルーター、仮想 Firewall、低遅延用途では有力な選択肢になります。

SR-IOV のメリット

• QEMU や virtqueue の処理を大きく迂回できる
• CPU 使用率を抑えやすい
• pps や latency を改善しやすい
• NIC のハードウェアキューや offload を活用しやすい
• NFV や高性能ネットワーク VM と相性が良い

ただし、これらのメリットは構成とワークロードに依存します。VF の NUMA、IRQ、ドライバ、NIC 世代、offload 設定、ホスト側の PCIe 構成が合っていなければ、期待した性能にはなりません。

SR-IOV のデメリット

SR-IOV の最大の注意点は、仮想化基盤の抽象化を一部手放すことです。VM が VF に依存するため、通常の virtio-net VM と同じ運用では扱えません。

• ライブマイグレーションが難しくなる
• VF の割り当て管理が必要になる
• ホスト障害時の復旧設計が複雑になる
• 仮想スイッチ上の詳細な制御を迂回しやすい
• 標準的な仮想ネットワーク監視で見えにくくなる
• NIC やドライバへの依存が強くなる

SR-IOV を使う VM は、通常の汎用 VM ではなく、物理デバイスに近い特別な VM として扱うべきです。

PCI Passthrough はデバイスを丸ごと VM に渡す

PCI Passthrough は、NIC や NVMe などの PCIe デバイスを丸ごと VM に割り当てる方式です。SR-IOV が 1 つの NIC から VF を分割して VM に渡すのに対し、PCI Passthrough は物理デバイスそのものを VM 側へ渡します。

方式	割り当て単位	特徴
SR-IOV	VF 単位	1 つの NIC を複数 VM へ分けやすい
PCI Passthrough	物理デバイス単位	デバイスを VM が専有する

PCI Passthrough は非常に短い I/O 経路を作れますが、その分、VM の移動性、ホスト側管理、共有利用は難しくなります。NVMe passthrough や GPU passthrough も同じ系統の考え方です。

IOMMU は必須の前提

SR-IOV や PCI Passthrough では、デバイスが VM のメモリへ DMA でアクセスします。そのため、IOMMU によって DMA の範囲を制御し、VM ごとのメモリ空間を分離する必要があります。

• Intel VT-d や AMD-Vi を有効化する
• IOMMU group を確認する
• デバイス分離が適切か確認する
• VF と vCPU / メモリの NUMA を合わせる
• VFIO などのデバイス割り当て方式を理解する

IOMMU group が期待通りに分離されていない場合、単独で割り当てたいデバイスだけを安全に VM へ渡せないことがあります。これは性能以前の設計条件です。

NUMA と PCIe 配置を合わせる

SR-IOV / PCI Passthrough では、CPU とメモリだけでなく、PCIe デバイスの NUMA も重要です。VF や物理 NIC が接続されている NUMA ノードと、VM の vCPU / メモリが離れていると、DMA や割り込み処理の経路が遠くなります。

• VF がどの NUMA ノードの NIC から作られているか確認する
• vCPU を同じ NUMA ノードへ寄せる
• メモリと HugePages も同じ NUMA ノードへ寄せる
• IRQ の処理 CPU を確認する
• 複数 NIC を使う VM ではデバイス配置を設計する

仮想スイッチを迂回する意味

SR-IOV は、仮想スイッチや Linux bridge / OVS の datapath を大きく迂回します。これは性能面では利点ですが、ネットワーク制御や観測の面では制約になります。

通常の仮想ネットワークでは、仮想スイッチ上で mirror、ACL、QoS、flow 観測、Firewall 連携などを行える場合があります。SR-IOV では、これらを同じ場所で扱えないことがあります。

観点	virtio / vhost	SR-IOV / Passthrough
性能	仮想化レイヤの影響を受ける	短い datapath を作りやすい
移動性	比較的高い	低い
可観測性	仮想スイッチで見やすい	NIC / 外部ネットワーク側へ寄りやすい
制御	仮想ネットワークで制御しやすい	ハードウェアや外部制御に依存しやすい
運用	汎用 VM として扱いやすい	専用 VM として扱う必要がある

採用判断の軸

SR-IOV / PCI Passthrough は、性能が必要だからすぐ採用するものではありません。性能要件と運用要件の両方を見て判断します。

• virtio-net / vhost-net では性能要件を満たせないか
• 要求は bandwidth か、pps か、latency か
• ライブマイグレーションを捨てられるか
• VF / 物理デバイスの割り当て管理を運用できるか
• 障害時に同等構成のホストへ復旧できるか
• 仮想スイッチを迂回しても監視と制御を維持できるか

まとめ

SR-IOV と PCI Passthrough は、VM の I/O 経路を短くし、物理デバイスに近い性能特性を得るための強力な方式です。特に高 pps、低遅延、NFV、専用ネットワーク VM では有力な選択肢になります。

一方で、これらは仮想化基盤が提供する移動性、抽象化、可観測性、柔軟なネットワーク制御を一部手放す方式でもあります。

SR-IOV / PCI Passthrough を使う VM は、通常の汎用 VM ではなく、物理デバイスに依存する専用 VM として設計する必要があります。Day8 では、さらにユーザー空間で高速 dataplane を作る DPDK を整理します。

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 パフォーマンス Day5 – virtio-net の構造と仮想 NIC の性能特性
• VM パフォーマンス Day6 – vhost-net / vhost-user と kernel bypass の考え方
• VM パフォーマンス Day8 – DPDK による高速 dataplane と NFV の基本

関連記事

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