AssistVirtualization一通り環境チェックをしてくれるので便利でいいんだけれども、vMotionネットワークをvMotion専用のTCP/IPスタックで構成していると失敗ステータスになるのが微妙。ま、そのうち治るんだろうけれども。これはリリースノートにも明記されているので、既知の問題扱い。Checkを無効化するかって...オイ(^_^;)。Pluginもきっちり提供されている。こちらも追加コストなどなく利用頂くことが可能。...とはいえ、ここではこのプラグインの全体像の説明とかはしない。Path情報をPluginの画面で確認できるところについてだけ。用語重なりが混乱の元凶なのだが、このエントリー内で書くvNICは仮想マシンにとってのネットワークアダプタを意味するvNICではなく、UCSにインストールしたOS/Hypervisorにとってのネットワークアダプタを意味する。イメージ的には世間一般には物理NIC。UCSではVICによって論理的に構成された仮想NICなのでvNIC。UCSではVICを搭載する構成が一般的なので、結果的にVIF/論理インターフェイスを使用することが一般的といえる。UCSにインストールしたOSやHypervisorからはVIFと紐付いたvNICはネットワークアダプタそのものとして認識される。UCS側でVIFを10個構成すれば、OS/Hypervisorからは10個のvNICを搭載したサーバで動作していると認識される。VICを使う場合、VIFのない構成はない。2ポートの口があるVICで2ポートのネットワークアダプタをOS/Hypervisorが認識している場合であっても、1つのポートに1つのVIFが紐付いているデフォルト構成のまま使っている、というだけの話で、つまり実際にはVIFを使っている。他のNICベンダーのネットワークアダプタでも論理インターフェイスを構成する機能はあったりするが、おそらくここまで一般的に論理インターフェイスを構成して使用する仕組みを活用しているサーバはUCSだけだろう。論理インターフェイスを活用するためにはサーバ側の構成(=VICの構成)だけでは不十分で、上位スイッチ側も含めて構成して初めて活用できるからだ。Manager)を加えた特殊なNexusスイッチをあわせて使用する。ManagerはUCS全体を管理する。UCSのサーバ部分だけではなく、自身が実行されている環境であるFIも管理している。これによって、VICにVIFを構成すると自動的にFI側も構成されているため、UCSの利用者はサーバとネットワークを意識することなく、シンプルにVIFを構成して利用することができる。VIFはOS/Hypervisorから見た論理ネットワークアダプタ(=vNIC)であるというだけではなく、論理ネットワークケーブルによって上位スイッチの論理ポートに接続されるまでの全体を意味しているということだ。図示するとこんな感じ。Plug-inでVIF情報を確認できると何が嬉しいの?という話。VIFによって構成されているvNIC、つまりはOS/Hypervisorから見たNICについてのプラグインの画面。ここでは6ポートのNICがあるという情報になっているが、これらは当然ながら物理NICが6ポートあるのではなく、VICによってvNICが6ポート構成されているということを意味する。この画面でUCS側で管理名として設定しているvNICの名前とMACアドレスの情報を参照できる。以下がVIFのパス情報を表示するプラグインの画面。この2つの画面によって、VIFがどの経路のポートに紐付いているかがわかる。仮想マシンと仮想スイッチのアップリンクポートの関係性みたいな、VIFにおけるvNICとパス(=ポート)の紐付けを確認できる。ちなみに、ESXiホストとして認識している[物理アダプタ]は、UCS的には物理アダプタではない(^_^;)。ここでもMACアドレスは表示されているので、ここを識別子としてUCSとしてのVIFのvNICと、ESXiとしてのvmnicの紐付けを確認することができる。Client側だけで確認できて便利だね、ということが、言いたかったこと。vCenterのプラグインはさておき、この仕組自体はUCS登場時からのお家芸。Managerによる統合管理だ!というのはもちろんなのだけれども、それを支えるハードウェア的な仕組みとしてVICがある。このソフトウェアとハードウェアの組合せで実現している仕組みだからこそ、他社の追随を未だに許さない、UCSならではのネットワークの管理性、構成の自由度などを実現しているのだろう。Channel接続している)。