SR-IOV とは何か – 高速化ではなく物理 NIC の制約を設計する技術

SR-IOV は、よく「NIC を仮想化して高速化する技術」と説明されます。この説明は完全に間違いではありませんが、それだけで理解すると設計を誤ります。

SR-IOV で本当に見るべきなのは、速くなるかどうかだけではありません。どの抽象化を捨て、どの物理 NIC の制約をワークロードへ持ち込むのかです。

SR-IOV は、仮想化基盤や Kubernetes の抽象化された世界に、PCIe デバイス由来のリソースを意図的に露出させる技術です。だからこそ、PF / VF、driver、firmware、NUMA、Device Plugin、CNI、物理ネットワーク側の設計を分けて見なければなりません。

SR-IOV とは何をする技術か

SR-IOV は Single Root I/O Virtualization の略です。1 つの PCIe デバイスを、複数の仮想的な PCIe 機能として見せる仕組みです。ネットワークカードで使う場合、物理 NIC の機能を複数に分割し、仮想マシンや Pod へ割り当てます。

用語	意味
PF	Physical Function。物理 NIC 本体に相当する機能
VF	Virtual Function。PF から作成される仮想機能
SR-IOV	1 つの PCIe デバイスを複数の機能として見せる仕組み
sriov_totalvfs	作成可能な VF 数
sriov_numvfs	実際に有効化している VF 数

通常の仮想 NIC は、ホスト OS 上の仮想スイッチ、bridge、overlay network などを経由します。一方、SR-IOV で割り当てられた VF は、より物理 NIC に近い形でワークロードから利用されます。

この違いが性能面のメリットになります。しかし、VF は「普通の仮想 NIC の高性能版」ではありません。物理 NIC から切り出された PCIe 機能です。ここを曖昧にすると、SR-IOV の設計を誤ります。

高速化技術とだけ呼ぶことの問題

SR-IOV を高速化技術と呼ぶこと自体は間違いではありません。問題は、「高速化」という言葉が、何を犠牲にしているのかを隠してしまうことです。

SR-IOV は、仮想化レイヤやソフトウェアデータパスの一部を避けることで性能面のメリットを得ます。その代わりに、仮想化基盤が提供していた柔軟性や抽象化の一部を手放します。

通常の仮想ネットワークでは、物理 NIC の詳細は利用者から見えにくくなります。どの PCIe スロットに挿さっているのか、どの NUMA node に近いのか、firmware version は何か、driver は何か、といった情報はある程度隠蔽されます。

しかし SR-IOV では、その物理の事情が戻ってきます。VF は特定の物理 NIC から作成され、VF 数には上限があり、VF は特定のノードに存在し、挙動は NIC、firmware、driver、kernel に依存します。

SR-IOV で得るものと失うもの

SR-IOV では、性能だけを見るのではなく、得るものと失うものを並べて見る必要があります。

観点	得るもの	失うもの
性能	低遅延・高スループットを狙いやすい	ソフトウェア処理の柔軟性
抽象化	物理 NIC に近い I/O	CNI や仮想スイッチによる抽象化の一部
可搬性	特定用途に最適化された NIC 利用	どのノードでも同じように動く性質
運用	データパスを明確にしやすい	driver / firmware / 物理層まで管理範囲が広がる
スケジューリング	高性能 NIC を持つノードを活用できる	VF を持つノードへの配置制約が生まれる

Kubernetes では、本来 Pod は抽象化されたワークロードとして扱われます。しかし SR-IOV を使う Pod は、VF を持つノードでしか動けません。さらに VF 数は有限です。この時点で、Pod の可搬性は下がります。

これは SR-IOV の欠点というより、性質です。SR-IOV は Kubernetes の抽象化をさらに強める技術ではありません。抽象化だけでは満たせない性能要件に対して、物理 NIC に近いリソースを意図的に露出させる技術です。

VF が見えることと使えることは違う

SR-IOV で特に危険なのは、「VF が見えているから使える」という判断です。VF が作成できること、OS で見えること、正しい driver で扱われること、通信できること、安定して性能要件を満たすことは別です。

• VF が作成できる
• VF が OS 上で認識される
• VF が正しい driver で扱われる
• VF がワークロードへ割り当てられる
• VF で通信できる
• VF が安定して通信できる
• VF が性能要件を満たす

この段階を分けずに「SR-IOV は設定した」と判断すると、障害時に切り分けができません。SR-IOV で見るべきなのは、VF が存在するかではなく、その VF が目的のワークロードに対して正しい条件で安定して使えるかです。

driver と firmware は設計要素である

SR-IOV では driver 確認を後追いの障害対応にしてはいけません。PF driver、VF driver、firmware、kernel の組み合わせが、そのまま安定性と再現性に影響します。

確認項目	内容	なぜ見るのか
PF driver	物理 NIC 本体が正しい driver で認識されているか	PF が VF 生成や NIC 制御の起点になるため
VF driver	作成された VF が正しい driver で認識されているか	VF が見えていても期待した driver で扱われていなければ意味がないため
driver version	OS 標準 driver か vendor driver か	対象 NIC や firmware との組み合わせで挙動が変わるため
firmware 互換性	driver と NIC firmware の組み合わせに問題がないか	同じ NIC でも firmware 差異で挙動が変わるため
kernel 互換性	使用中 kernel で SR-IOV 機能が安定しているか	driver は kernel と切り離して考えられないため
VF bind 状態	VF が期待した driver に bind されているか	OS 上に見えることと正しく使えることは別だから
ノード間差異	driver / firmware / kernel に差異がないか	同一クラスタ内の挙動差を避けるため

同じ NIC 型番であっても、firmware version が違えば挙動が変わることがあります。同じ OS であっても、kernel version や driver version が違えば、利用できる機能や安定性が変わることがあります。

SR-IOV で確認すべき観点

SR-IOV を導入する場合、コマンドを覚えることよりも、何を確認しているのかを理解する方が重要です。

分類	確認内容	理由
ハードウェア	NIC 型番、SR-IOV 対応、PCIe 構成、NUMA 配置	VF は物理 NIC 由来のリソースであり、物理構成の影響を受けるため
BIOS / UEFI	SR-IOV、IOMMU、VT-d / AMD-Vi の有効化	OS や Kubernetes 以前にサーバー側で機能が使える必要があるため
OS	kernel version、IOMMU 有効化状態	SR-IOV は kernel と PCIe デバイス制御に依存するため
firmware	NIC firmware / NVM version	driver や機能対応、既知不具合に影響するため
driver	PF driver、VF driver、driver version	PF / VF が正しく扱われるかを決めるため
VF	作成可能数、作成数、OS 上での認識状態	必要なワークロード数に対して VF が足りるかを見るため
Kubernetes	Device Plugin、CNI、NetworkAttachmentDefinition	VF を Pod へ割り当てるための基盤側設定を確認するため
運用	ノード交換時の firmware / driver 差異、更新方針	稼働後の差異や再現性の崩れを防ぐため

sriov_totalvfs を見るのは、単に数字を確認するためではありません。その NIC で作成可能な VF 数を確認し、設計上必要な VF 数を満たせるかを見るためです。driver を確認するのも、OS から NIC が見えているかだけではなく、想定した PF driver、VF driver で動作しているかを見るためです。

Kubernetes で SR-IOV を使う場合

Kubernetes で SR-IOV を使う場合、ノード上で VF を作成するだけでは不十分です。Pod に VF を割り当てるには、Kubernetes 側で VF をリソースとして認識し、Pod 作成時に適切に接続する必要があります。

要素	役割	注意点
物理 NIC	PF / VF を提供する	ノードごとの NIC 差異がそのまま SR-IOV の差異になる
VF	Pod に割り当てる物理 NIC 由来のリソース	無限に作れるものではなく、物理 NIC に依存する
SR-IOV Device Plugin	VF を Kubernetes リソースとして広告する	VF を見せる仕組みであり、物理層の問題を解決するものではない
SR-IOV CNI	VF を Pod の network namespace へ接続する	Pod へ接続できても driver / firmware 問題は残る
Multus CNI	Pod に複数ネットワークを付与する	複数 IF 構成になるため、経路や通信設計の整理が必要になる
NetworkAttachmentDefinition	追加ネットワークの定義	定義とノード側 VF 構成が対応している必要がある

Device Plugin や CNI は、物理層の問題をすべて吸収するものではありません。Kubernetes 上で VF がリソースとして見えていても、その VF がどの NIC から作成されたものか、どの driver で動作しているか、どの NUMA node に属しているか、firmware に差異がないか、という問題は残ります。

よくある誤解

誤解	実際
SR-IOV を有効化すれば速くなる	実際の性能は NIC、driver、firmware、NUMA、CPU、設計に依存する
VF が作成できれば利用可能	VF driver、bind 状態、VF 設定、ネットワーク側設定も確認が必要
Kubernetes 側で見えれば問題ない	ノード OS、driver、firmware、物理 NIC の問題は残る
Operator や Device Plugin が全部吸収する	物理・OS・driver 差異までは完全には吸収できない
SR-IOV はクラウドネイティブな抽象化技術	実際には物理 NIC 由来の制約をワークロードへ持ち込む技術
SR-IOV は設定だけの問題	設計、互換性、運用、障害切り分けまで含む問題

SR-IOV の問題をすべて Kubernetes の設定ミスや CNI の問題として見ると、原因に到達できません。実際には、NIC、firmware、driver、kernel、NUMA、物理ネットワーク側に原因があることもあります。

SR-IOV は何が高度なのか

SR-IOV が高度なのは、難しいコマンドを打つからではありません。抽象化された基盤の中で、物理デバイスの制約を意識的に扱う必要があるからです。

Kubernetes や仮想化基盤は、多くの物理的な差異を隠してくれます。しかし、性能要件が厳しくなると、その抽象化だけでは足りない場面が出てきます。そこで SR-IOV を使うと、隠されていた物理の事情が戻ってきます。

NIC は何か。firmware は何か。driver は何か。VF はいくつ作れるのか。どのノードにあるのか。どの NUMA node に近いのか。scheduler はそれをどう扱うのか。障害時にどのレイヤから切り分けるのか。これらを設計に含めて初めて、SR-IOV は扱える技術になります。

まとめ

SR-IOV は、物理 NIC の機能を PF / VF として分割し、仮想マシンや Pod へ物理 NIC に近い形で割り当てる技術です。これにより、仮想スイッチやソフトウェアデータパスの一部を避け、低遅延・高スループットを狙いやすくなります。

しかし、SR-IOV を「高速化技術」とだけ理解すると本質を見誤ります。SR-IOV を使うということは、仮想化基盤や Kubernetes の抽象化された世界に、物理 NIC 由来の制約を持ち込むということです。

重要なのは、VF が見えるかどうかではありません。その VF が、目的のワークロードに対して、正しい driver、正しい firmware、正しい kernel、正しいノード構成、正しいネットワーク設計の上で安定して使えるかです。SR-IOV は単なる高速化設定ではなく、仮想化基盤と物理 NIC の境界を設計する技術です。