"Windows 8" への Hyper-V 導入
この投稿では Windows の "クライアント" 製品での仮想化サポートについて説明します。仮想化という技術は、もともと Windows Server 向けにリリースされ、たいへんな人気と成功を博しました。この技術を、Windows を使用するプロフェッショナルのもっと一般的なシナリオに対応できるようにしたいと考えたのです。最も一般的なシナリオとして、ソフトウェア開発者が複数のプラットフォームやクライアントとサーバーの両方を扱うケース、そして IT プロフェッショナルが仮想化されたクライアントやサーバーをシームレスに管理したいと考えているケースの 2 つに注目しました。この投稿を執筆した Mathew John は、Hyper-V チームに所属するプログラム管理者です。1 つ申し添えておくと、他の機能の場合と同様、ここでは最終的なパッケージングではなく、エンジニアリングの部分について話したいと思っています。最終的なパッケージングについての決定はプロジェクトのもっと後の段階で行われます。–Steven
追記: 予定外の連続投稿になりましたが、今後はもう少し継続しやすいペースに落としたいと思います。期待値が上がってしまっていた場合はご容赦ください。目下、BUILD の準備に全力を注いでいるところです!!
ソフトウェア開発者や IT 管理者なら、または一般のヘビー ユーザーの場合でも、複数のオペレーティング システムを (通常はいくつものマシンで) 動かしたい場面は多いと思います。もちろん、それだけの数のマシンを完備したラボを持っている人ばかりではありませんので、スペースと時間を節約できる仮想化に期待が集まることになります。
Windows 8 の構築にあたって、私たちは過去 2 つの Windows Server のリリースに組み込まれていたマシン仮想化技術である Hyper-V をクライアント OS に対応させる作業に取り組みました。Hyper-V とは、簡単に言うと、複数の 32 ビットまたは 64 ビットの x86 オペレーティング システムを 1 つのコンピューターで同時に動かすことを可能にする技術です。各オペレーティング システムは、コンピューターのハードウェアと直接連動する代わりに、"仮想マシン" (VM) の中で動作します。
Hyper-V を利用すると、開発者はハードウェアへの追加投資を行うことなく、複数のテスト環境を簡単に管理し、シンプルなメカニズムによってこれらの環境をすばやく切り替えることができます。たとえば、Web 開発者をサポートするため、以前のバージョンの Internet Explorer を組み込んだ事前構成済みの仮想マシンが提供されています。さらに IT 管理者には、仮想マシン パリティというメリットがあるほか、Windows サーバーと Windows クライアントの両方で Hyper-V による共通の管理エクスペリエンスを得ることができます。また、普段使っている PC に変更を加えるリスクを回避しつつ、何か新しいことを試してみるために、仮想化を活用される方も多いかと思います。
Hyper-V の紹介
Hyper-V には、Second Level Address Translation (SLAT) を備えた 64 ビットのシステムが必要です。SLAT 機能は、Intel と AMD の最新世代の 64 ビット プロセッサに組み込まれています。また、64 ビット版の Windows 8 と 4 GB 以上の RAM も必要になります。Hyper-V で VM 内に作成するオペレーティング システムについては、32 ビットと 64 ビットの両方がサポートされます。
Hyper-V の Dynamic Memory 機能では、VM が必要とするメモリを (最小値と最大値を指定して) 動的に割り当てまたは割り当て解除することができ、使用されていないメモリを複数の VM 間で共有することができます。4 GB の RAM を搭載したマシンでは 3 つから 4 つの VM を実行することができますが、5 つ以上の VM を実行するにはより多くの RAM が必要です。一方、1 つの VM のサイズという観点では、32 個のプロセッサと 512 GB の RAM を搭載した、大きな VM を作成することが可能です。
VM のユーザー エクスペリエンスについて言えば、Windows では VM コンソールとリモート デスクトップ接続という 2 つの方法で、仮想マシンをのぞき見ることができます。
VM コンソール (VMConnect) は、VM のコンソール ビューです。最大 1600 x 1200 の解像度と 32 ビット カラーで、VM をシングル モニター表示できます。このコンソールでは、VM の起動プロセスも見ることができます。
リモート デスクトップ接続 (RDC) を使って VM に接続すると、さらにリッチなエクスペリエンスが得られます。RDC を使用すると、物理マシンの能力を VM で活用できます。たとえば、複数のモニターがある場合、VM はこれらのモニターをすべて使ってグラフィックを表示できます。同様に、PC がマルチタッチ対応のインターフェイスを備えていれば、VM でもこのインターフェイスを利用してタッチ エクスペリエンスを実現できます。物理マシンのスピーカーとマイクを利用して、VM に完全なマルチメディア機能を持たせることも可能です。ルート OS (VM を管理しているメインの Windows OS) では、各 VM とクリップボードやフォルダーを共有することができます。また、RDC では、すべての USB デバイスを直接 VM に接続することが可能です。
ストレージに関しては、VM の IDE コントローラーまたは SCSI コントローラーに複数のハード ディスクを追加できます。仮想ハード ディスク (.VHD または .VHDX ファイル) を利用することも、実際のディスクを仮想マシンから直接利用することもできます。VHD はリモートのファイル サーバーに置くこともできるため、事前定義した共通の VHD のセットをチーム内で共有および管理するのも簡単です。
Hyper-V の "Live Storage Move" 機能により、格納先ストレージへの VM の依存をかなり弱めることができます。この機能により、VM のストレージを 1 つのローカル ドライブから別のローカル ドライブへ、または USB メモリやリモートのファイル共有スペースへ、VM を停止することなく移動できます。実際に使ってみると、これは VM をすばやく配備する際にかなり便利です。たとえば、急いで VM を利用したいときに、まずファイル共有スペースで管理している VM ライブラリから VM を起動し、それから VM のストレージをローカル ドライブに移動します。
Hyper-V の優れた特長の 1 つとして、実行中の仮想マシンの "スナップショット" を取得する機能があります。スナップショットとは仮想マシンのすべての情報を保存したもので、これを呼び出すことで VM の過去の状態を再現することができます。これは、トリッキーな問題の解決が必要な場面で強力な武器となります。また、Hyper-V の仮想マシンは、管理のしやすさという面においても、Windows が持つ性能をすべて備えています。Windows Update によって Hyper-V コンポーネントに修正プログラムを適用できるので、追加のメンテナンス プロセスを導入する必要はありません。また、Windows が本来持っている能力は、Hyper-V をインストールした状態でもすべて発揮することができます。
一方で、仮想化を使用する際の制約もあります。特定のハードウェアに依存する機能やアプリケーションは、VM ではうまく動作しません。たとえば、Windows の BitLocker や Measured Boot は TPM (トラステッド プラットフォーム モジュール) に依存するため、VM では正常に動作しない可能性があります。GPU による処理を要求する (かつソフトウェア フォールバックを用意していない) ゲームやアプリケーションも同様です。また、10 ミリ秒未満のタイマーを利用するアプリケーション (音楽のリアルタイム ミキシングなど、レイテンシが影響する処理を行う精密なアプリケーション) は、VM で実行すると問題が発生する可能性があります。ルート OS はすべてのハードウェアに直接アクセスできるという点で特殊ですが、Hyper-V 仮想化レイヤーの上で実行されている点は同じです。このため、ルート OS なら特殊なハードウェア要件を持つアプリケーションも不自由なく動作しますが、レイテンシが関係する精密なアプリケーションの場合はルート OS でも問題が起きる可能性があります。
VM で使用する各オペレーティング システムにライセンスが必要であることには変わりありません。
次のビデオで、Windows 8 における Hyper-V の動作の簡単なランスルーをお見せします。
ビデオをダウンロードしてお好みのメディア プレーヤーで再生することができます:
高画質 MP4 | 低画質 MP4
ワイヤレス NIC を使った VM での通信のサポート
デモでお見せしたように、外部ネットワーク スイッチの作成はとても簡単で、ドロップダウン リストから物理的なネットワーク アダプター (NIC) を選んで [OK] をクリックするだけです。これは Window Server の Hyper-V では既に問題なく機能していましたが、Windows 8 で同様の結果を得るためには、ワイヤレス NIC への対応という新たな課題をクリアする必要がありました。
課題
Hyper-V の仮想スイッチは "レイヤー 2 スイッチ" です。これはつまり、スイッチ処理 (イーサネット パケットの経路決定) を、各ネットワーク アダプター カード (物理的/仮想的ともに) を一意に特定する MAC アドレスを使って行うということです。各イーサネット パケットには送信元と宛先の MAC アドレスが含まれており、レイヤー 2 スイッチはこれを利用して着信パケットの送信先を判断します。VM の場合は "外部" 仮想スイッチがあり、これは物理 NIC を通して外部の世界に接続されています。VM から外部の世界にあるマシンに向けて送信されたイーサネット パケットは、この物理 NIC を通して送信されます。これは、その物理 NIC が、仮想スイッチに接続されたすべての VM からのトラフィックに対応しなければならないということで、物理 NIC を通るパケットに複数 (各 VM の仮想 NIC の数だけ) の MAC アドレスが含まれることを意味します。有線の物理 NIC では NIC を無作為検出モードにすることによってこれに対応できますが、WiFi NIC とそのアクセス ポイントによって確立されたワイヤレス チャネルでは、その WiFi NIC の MAC アドレスを持つイーサネット パケットしか許可されないため、対応できません。つまり、従来の仮想スイッチ アーキテクチャを使い続ける限り、Hyper-V では外部スイッチに WiFi NIC を使用できなかったのです。
図 1: 有線接続を使った VM と外部マシンとの間のネットワーク
解決策
この制約を回避するために、Microsoft Bridging ソリューションを使用しました。これは、ARP プロキシ (IPv4 の場合) と近隣探索プロキシ (IPv6 の場合) を使って、発信パケットに含まれる "仮想" NIC の MAC アドレスを WiFi アダプターの MAC アドレスに置き換えるものです。ブリッジによって仮想 NIC の IP アドレスと MAC アドレスとの間の内部マッピングが維持され、外部の世界からのパケットが適切な仮想 NIC に送られます。
Hyper-V ではこのブリッジ処理が仮想スイッチ作成の一環として組み込まれており、WiFi アダプターを使った外部仮想スイッチを作成すると次の処理が行われます。
- WiFi アダプターに接続された単一のアダプター ブリッジを作成する
- 外部仮想スイッチを作成する
- WiFi アダプターを直接使用するのではなく、ブリッジを使用するように外部仮想スイッチをバインドする
このモデルでは、イーサネット スイッチングが仮想スイッチで行われる点は変わりませんが、MAC アドレスのトランスレーションがブリッジで行われます。エンド ユーザーにとっては、有線の NIC を使ってもワイヤレス NIC を使っても、外部ネットワークを作成するワークフローは変わらないことになります。
図 2: WiFi 接続を使った VM と外部マシンとの間のネットワーク
結論として、Windows サーバーだけでなく Windows クライアントにも Hyper-V を導入することにより、ほとんどのデータ センターで必要とされるスケーラビリティ、セキュリティ、信頼性、およびパフォーマンスを備えた、堅牢な仮想化技術の提供に成功したと言えると思います。開発者や IT プロフェッショナルは Hyper-V を使用することで、複数マシンに対するより効率的でコスト パフォーマンスの高い、使用環境やテスト環境を構築することができます。
--Mathew John