仮想化でプリセールスしてるSEの一日

VMware から Azure まで、インフラや仮想化の最新情報をベンダー色をできるだけ抑えて綴っていきます

トップ > Hyper-V > Windows Server 2012 Hyper-V の SR-IOV 構築手順 (3)

Windows Server 2012 Hyper-V の SR-IOV 構築手順 (3)

Hyper-V ハードウェア 検証レポート

f:id:ogawad:20190203195637p:plain:right

(1) (2) (3) (4)

「IovSupport」が True になれば
ゲストに SR-IOV NIC を割り当てていきましょう。


ゲストに SR-IOV NIC を割り当てる

通常の VMBus NIC と同様の手順で、Hyper-V マネージャーからゲストに「ネットワーク アダプター」を割り当てますが、WS2012 で新しく追加された「ハードウェア アクセラレータ」画面で「SR-IOV を有効にする」にチェックを入れてください。
海外の資料で「Set-VMNetworkAdapter -IovWeight 1」という PowerShell を実行するよう指示されていることがあります。これは Beta の際に下記画面が開発中であった名残で、現在は GUI のみで設定できます。


SR-IOV 対応の仮想 NIC を割り当てたら、ゲスト OS を立ち上げます。
Hyper-V マネージャの下ペインで SR-IOV の稼働状態を確認可能です。


SR-IOV NIC のゲスト内での見え方

SR-IOV NIC がゲストOS上でどのように見えるか確認してみましょう。


こちらは通常の VMBus NIC を割り当てた場合。


こちらが SR-IOV NIC の場合です。ネットワーク接続画面で NIC は1つのままですが、物理っぽい名前のミニポートドライバが増えています。


デバイスマネージャーを「接続別」に並べるとこんな感じ。



各々のミニポートドライバの Function を見てみましょう。


こちらは、通常の VMBus NIC のものです。


こちらが、先ほど増えたミニポートドライバ。物理 NIC の Function を引き継いでいることが分かります。また「SR-IOV」「VMQ」「VLAN Tag*1」など、ホスト用の Function はゲスト側ではきちんとマスクされています。


1つの仮想 NIC に対して、2つのミニポートドライバが認識される理由

このように、仮想 NIC（仮想スイッチ）1個に対して、2つのミニポートドライバが認識されています。

  • 通常の VMBus NIC
  • SR-IOV によるパススルー NIC （SR-IOV では Virtual Function: VF と呼ばれます）


実は、この2つのミニポートドライバが WS2012 Hyper-V における "実用的な SR-IOV 実装" のキーと言えるところです。思い返してみれば、ハイパーバイザーを避けるための NIC パススルーなのに、ハイパーバイザー層で動く仮想スイッチ割り当てる自体おかしな話... というか矛盾しています。


では、なぜ仮想スイッチが必要かというと、
「パススルーでもライブマイグレーションを実現させるため」です。


ゲストが物理 NIC をそのままパススルーさせると、Live Migration で問題が生じます。理由は Live Migration で仮想マシンのメモリ内容はコピーされますが、物理 NIC 内のメモリデータまでは移動先の物理 NIC に転送できないからです。物理 NIC のメモリデータを吸い上げられないため、仮想マシンのサスペンドやスナップショットも同様に利用できません。

類似のパススルー技術で先行していた VMware の VMDirectPath I/O も、vMotion を利用できないのがネックで、当初の期待より普及が進んでいません*2。Hyper-V は同じ轍を踏まないよう、仮想 NIC 1個ごとに VMBus と SR-IOV の2つの通信経路を持たせています。


言葉では分かりにくいので絵にしてみました。


こちらが SR-IOV 環境での普段の I/O イメージです。
VMBus NIC を介して仮想スイッチはつながっているものの、実際の I/O は Intel VT-d2 や AMD IOMMU を通じて物理 NIC と直接通信します。


こっちは Live Migration や Suspend / Snapshot 中の I/O イメージ。
この間の通信経路を VMBus の仮想スイッチ経由に切り替えることで、突然の物理 NIC 変更による SR-IOV のエラーを回避します。

SR-IOV と NIC Team を併用したい場合はゲストチーミングで

SR-IOV を使うシステムではチーミングも併用するケースがほとんどだと思います。
WS2012 ではようやく OS 側に NIC Team 機能「LBFO」が付きましたが、LBFO でチーミングしてしまうと SR-IOV の機能がフィルタされて利用できなくなってしまいます。このため、ホストではなく ゲスト内でチーミングする ことが重要です。


まずは、ゲストに SR-IOV を有効にした仮想 NIC を複数個割り当てます。
デバイスマネージャーで見るとこのような感じ。


そして「高度な機能」で NIC Teaming も有効すると...


ゲスト内で LBFO によるゲストチーミングが可能になります。

*1:Hyper-V の場合はゲスト内ではなく、仮想スイッチをマップする際に設定します

*2:2012.06.17 追記　vMotion に対応した「VMDirectPath I/O Gen2」という VMware 独自規格もありますが、Cisco UCS/VIC のみの対応です