さて、わかりづらい？Hyper-Vのネットワーク第2弾。今回はチーミングまわりについて…なんて少し思っていたのですが、タイミング良く素晴らしい記事をHP小川さんが@ITで公開されましたので、そちらを参照頂ければもう書くことないです^_^; …ということで、今回のエントリーではHyper-Vにおける仮想スイッチまわりにフォーカスを当ててみます。
前回書いた通り、Hyper-Vの仮想スイッチはネットワークアダプタ―における機能として実装されています。実装というよりも概念的な構成図を描いてみました。この図は物理・論理・仮想のネットワークアダプタ―を中心に書いてあります。実際には、Hyper-VのParent Partitionは仮想スイッチの役割を果たすネットワークアダプタ―を共有しなくてもよいので、必ずしもこのような構成にはなりませんし、またチーミング機能と仮想スイッチ機能は別ですので、このように3段構成とする必要があるわけでもありませんが、いわゆる良くある構成例、といった感じです。
ちょっと脱線すると、チーミング機能と仮想スイッチ機能はWindowsの中でそれぞれ独立した機能でありながら組み合わせた設計が必要であるところも、Hyper-Vのネットワークまわりをわかりづらくしている1つの要因といえるかと思います。…でありながら、上記の@ITの記事にも記載がありますが、VLAN対応をする実装がチーミング機能と仮想スイッチ機能の2つHyper-V環境で使用するWindowsの中に存在しており、Hyper-V環境でVLANを使用する場合はチーミング側でVLAN仮想アダプターを構成してはいけないといった点があることもまた、Hyper-Vをちょっと使いづらいものにしている気がします。こうした細かい事項の蓄積で、Hyper-Vは全体的にちょっとわかりづらかったり、使いづらかったりしてしまっているところは、ちょっと残念なところです。この取っつきずらさ？が、実はHyper-Vの普及を阻害してしまっている最も大きな理由なのかもしれません。個別の機能面や全体的に備えている機能の総合力としてはだいぶいい感じだと思うんですけれどもね…。
また、上図 下の方の、Cisco UCS、およびVirtual Interface Card (VIC)については、また別のエントリーで詳しく！書くことにしたいと思いますが、物理的には1つでも、Hyper-V/Windowsホストが物理NICだと思い込んで認識するネットワークアダプタ―(これまで、物理ネットワークアダプターとして表記してきたもの)を好きな数、自由に構成することができる優れものです。…が、こういうこと書いちゃうから、ますますどこの階層を物理というのか等がわかりづらくなってしまうんですよね、はい。
さて、本題に戻りましょう。
Hyper-Vマネージャで構成することができる仮想スイッチは、とてもシンプルです。仮想スイッチを新規に作成しようとすると、「外部」「内部」「プライベート」の3種類いずれかの仮想スイッチを構成できます。
外部こと「外部ネットワーク」を選択した場合は、その名の通り、外部と通信可能な仮想スイッチを構成します。そのため、仮想スイッチにとってアップリンクポートとなるネットワークアダプタ―の指定が必要となります。前回のエントリーで書いた通り、ここで「管理オペレーティングシステムにこのネットワークアダプタ―の共有を許可する」にチェックを付けると、この仮想スイッチに対して接続するための仮想ネットワークアダプタ―がParent Partitionの役割を持ったWindows Serverに対して構成されることになります。
「内部ネットワーク」と「プライベートネットワーク」は、ちょっと違いが分かりづらい。要はParent PartitionのWindows Serverも接続できる仮想スイッチを構成するか、仮想マシンに対してのみ接続を提供するか、の違いです。ただ、個人的には、この2つはわざわざ用意しなくてもいいのではないかと思っています。なぜなら、内部ネットワークは、外部ネットワークにおいて「アップリンクポートとなるネットワークアダプターを選択しない」という選択肢を用意すればいいですし、プライベートネットワークは、「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」のチェックをつけないことと基本的には同じことを意味するからです。VMwareでは、仮想スイッチにこれらを区別する選択肢は用意されていません。直感的には、その方が分かりやすいのではないかと思います。
なお、VLANの構成については、仮想スイッチではParent Partitionを接続する場合に割り当てるVLAN使用の有無と使用する場合のVLAN IDの指定だけを構成します。各仮想マシンのVLANについては、仮想マシン毎の仮想ネットワークアダプターにおいて構成するためここでは設定しません。つまり、VMware vSphereの場合におけるポートグループのような論理グループは、ここでは設定しません。VMwareな人にとっては、ポートグループ的な概念ないの？って思ってしまうところですね*1。
さて、まだSCVMMについては改めて今後のエントリーで扱うこととしたいと思いますが、今回のエントリーではSCVMMを通じて仮想スイッチを構成する部分についてだけ、見てみたいと思います。
このように、SCVMMを通じて仮想スイッチを構成する場合には、Hyper-Vマネージャでの仮想スイッチの作成とは違い、「標準スイッチ」と「論理スイッチ」の2つから選択して仮想スイッチを作成することになります。
標準スイッチは、基本的にはHyper-Vマネージャによって作成する仮想スイッチと同じものです。以下の画面のように、構成内容もHyper-Vマネージャでの場合とまったく同じです。Hyper-Vマネージャを通じて作成した仮想スイッチも、SCVMMでは標準スイッチとして分類されます。
対して、論理スイッチは基本的にはSCVMMを通じてのみ構成される仮想スイッチです。以下の画面のように、論理スイッチでは標準スイッチの場合とは構成するパラメータが異なります。各パラメータについては、今後のエントリーで詳しく見ていきたいと思いますが…設定する項目は、標準スイッチの場合とまったく異なります。スイッチとしての定義は、仮想スイッチ自身から分離されているため、最終的な仮想マシンのための仮想スイッチとしては最小限、アップリンクとして使用するネットワークアダプターとアップリンクポートグループのみとなります。この辺りの詳細は、また追々。
ところで、VMware vSphereの分散仮想スイッチも、実際には各ESXiホストに仮想スイッチを構成し、それを透過的に統合管理することによって「論理的には」ホストをまたいで構成された仮想スイッチを構成します。これと同様に、Hyper-Vにおける論理スイッチもまた、ホストをまたいでSCVMMによって統合管理される仮想スイッチとなります。しかし、分散仮想スイッチで管理されている個別ホスト側の仮想スイッチが上手く隠蔽されているのに対して、Hyper-VではParent PartitonとしてWindows Serverを使用している宿命と言えるかもしれませんが、普通にHyper-Vマネージャから見えてしまいます。
さらに、ここがまたHyper-Vのややこしいところなのですが、Hyper-Vマネージャでは標準スイッチと論理スイッチの2つを識別しないため、Hyper-Vマネージャを通じてそのスイッチを参照しても、違いはありません。
このように、論理スイッチの場合は設定についてはSCVMMからHyper-Vホストに対して定義が行われますが、仮想スイッチとしては外部ネットワークと同じように扱われます。そういうものだと理解すればまぁ別に困りはしないのですが、Hyper-Vのネットワークはこんな感じで、標準スイッチと論理スイッチがあるということをまず押さえておかないとHyper-Vマネージャによる管理の先には進めません。
そんな感じで、ではまた次回。
*1:SCVMMを通じて、の場合には事実上のポートグループ的な概念は存在するのですが…この段階ではない、というところも、数あるわかりづらい？気がする点の1つ…。
