このドキュメントでは、Cisco 仮想インターフェイス カード(VIC)をネットワーク アダプタに統合した Hyper-V 仮想ファイバ チャネルの使用時に、誤った論理ユニット番号(LUN)の列挙が原因で発生する仮想マシン(VM)のライブ マイグレーションの失敗を防ぐ方法を説明します。
Hyper-V 仮想ファイバ チャネルを使用することで、VM をファイバ チャネル接続ストレージに直接接続できます。 ユニファイド コンピューティング システム(UCS)リリース 2.1(2a) で導入された N_Port ID 仮想化(NPIV)のサポートにより、Hyper-V 仮想ファイバ チャネルを有効にすることができます。 Hyper-V 仮想ファイバ チャネルを使用する場合、仮想ファイバ チャネル スイッチを作成して、ホスト(親パーティション)上のホスト バス アダプタ(HBA)にバインドする必要があります。 その上で、VM 内に仮想ファイバ チャネル アダプタを作成し、仮想ファイバ チャネル スイッチに接続します。
VIC 統合ネットワーク アダプタで Hyper-V 仮想ファイバ チャネルが使用されている場合、ライブ マイグレーションが失敗することがあります。 この問題は、仮想ファイバ チャネル スイッチにバインドする際に、ストレージ エリア ネットワーク(SAN)からのブートとクラスタ共有ボリューム(CSV)LUN へのアクセスに、Hyper-V ホスト上の同じ HBA ペアを使用すると発生します。 このような状況では、仮想ファイバ チャネル HBA を使用した VM のライブ マイグレーションを試行すると、誤った LUN 列挙が発生して、ライブ マイグレーションが完了しません。
この障害が発生すると、ディスク管理スナップインに、親パーティション内の VM にマッピングされた LUN がオフライン状態であると示されます。 この問題の詳細については、Cisco Bug ID CSCup40056 を参照してください。
以下の図に、オペレーティング システムの観点から見た設定問題の論理トポロジ ビューを示します。
Hyper-V ホストを SAN からブートして Hyper-V 仮想ファイバ チャネルを実装することを予定している場合、Hyper-V ホスト上に 2 つの HBA ペア(ファブリックごとに 2 つの HBA)を設定することを推奨します。 最初の HBA ペアは、SAN およびクラスタ共有ボリューム(CSV)からのブートなど、Hyper-V ホストのトラフィックに使用します。 2 つ目の HBA ペアは、仮想ファイバ チャネルに使用します。 このように設定して Hyper-V ホストの I/O トラフィックと VM I/O トラフィックを区分化することが、Hyper-V 仮想ファイバ チャネルを導入する際のベスト プラクティスです。
現在 VM で発生している負荷に与える影響を抑えて、この設定を適用するには、以下の手順に従います。
上記の変更を行った後の vHBA の配分は、以下の図に示されるようになります(ファブリックごとに 2 つ、合計 4 つの vHBA)。
vH1 から vH4 までの番号が付けられた 4 つの vHBA のうち、SAN からブートするように設定されているのは vH1 と vH2 だけです(下図を参照)。
両方の仮想ファイバ チャネル SAN のインターフェイスが正しい vHBA に関連付けられていることを確認します。 たとえば以下の図で VSAN_110 がバインドされているのは、ステップ 2 の図に vH3 として示されている「WWPN 20:00:00:25:b5:00:aa:1f」のインターフェイスです。
このドキュメントで説明した設定の変更を完了すると、誤った LUN 列挙による障害が発生することなく、VM のライブ マイグレーションを完了できるようになります。
以下の図に、このドキュメントで説明した手順を完了した後の新しい設定の論理トポロジ ビューを示します。