マイクロソフトの仮想化戦略を担うMED-V【後編】

MED-V V2を試す

　前回は、MED-Vの概要に関して説明した。今回は、実際にMEDｰVをテストしていこう。

■MED-V バージョン2とバージョン1の違い

　現在、MED-Vは、バージョン2（以下V2）のRC版がマイクロソフトコネクトで公開されている。ちなみに、現状ではメニューなどは、英語のままだ。正式リリース時には、日本語化されていると期待したい。

　MED-V V2は、バージョン1（V1）と比べると大きくアーキテクチャが異なる。MED-V V2は、仮想マシンを配布、管理するための専用サーバーは必要ない。このため、仮想マシンを配布するのは、System Center Configuration Manager（SCCM）などのソフトウェア配布システムを利用する。MED-V専用のサーバーが必要なくなったため、システム構築もやりやすくなった。

　クライアントPC側の仮想化システムも、MED-V V1で使用していたVirtual PC 2007からWindows 7が採用しているVirtual PC（XP Modeで使用する仮想化システム）に変わっている。このため、MED-V V2を利用してきるクライアントPC側のシステムは、Windows 7のみになる。

　当初、Virtual PCはCPUの仮想化支援機能（Intel VT、AMD-V）が必須となっていた。しかし、PCによっては、CPUが仮想化支援機能を持っていても、BIOSでサポートしていない場合があり、動作するかどうかはPC環境によって差があった。いろいろとトラブルが起こったため、マイクロソフトは、Virtual PCの仕様を変更して、CPUの仮想化支援機能がなくても動作するように変更した。

　ただし、CPUの仮想化支援機能がなければ、仮想マシンの動作性能がダウンする（CPUに相当負荷がかかる）。できれば、MED-V V2でも、CPUの仮想化支援機能があるPCを使うことが望ましい。

　もう1つ重要なのは、MED-V V2の動作環境としてActive Directory（AD）が必須になっている。MED-V V1では、ワークグループ環境で動作したが、MED-V V2ではADが必要になっている。これは、MEDｰV V1は、MED-Vの管理サーバーがあったが、MED-V V2では管理サーバーがなくなっている。このようなアーキテクチャの変更のため、MED-V V2では管理のためADが必要になっているのだと思う。

■Virtual PCにXP SP3をインストール

　MED-V V2を使用するには、MED-VをインストールするPC以外に、仮想マシンを作成する管理コンソールPCが必要になる。管理コンソールPCでは、MED-Vの仮想イメージを作成する。この仮想イメージをパッケージ化して、最終的にMED-V V2を動作させるPCに配布する。配布の仕方としては、SCCMなどを使う方法もあるが、今回は1番手っ取り早く、パッケージ化した仮想イメージをUSB-HDDなどのコピーして配布する。

　ちなみに、パッケージ化した仮想イメージは、どのようなアプリケーションを仮想イメージにインストールするのかということによって容量が異なってくる。USBメモリにコピーすることもできるが、環境によって容量が大きくなるため、USBメモリよりもUSBｰHDDの方が便利だろう。

　まずは、Windows 7環境にVirtual PCをインストールする。Virtual PCは、XP Mode（Windows XP SP3のOSイメージ）も同梱されているが、今回は新たにWindows XP Professional SP3をインストールした。

　Windows 7上で仮想環境を使用するため、仮想環境をある程度の性能で動かすためには、ある程度のCPU性能が必要になる。さらに、メモリとHDDもある程度必要になる。

　そこで、今回は、仮想マシンを作成する管理コンソールPCには、CPUには、Phenom Ⅱ x4 955（3.2GHz）、メモリは8GB、HDDは1TBというPC環境を使用した。また、MED-Vの実行環境としては、同じPCに別の異なる1TB HDDをインストールして使用した。

　Windows XPをインストールする仮想マシンには、メモリ1GBを割り当てた。Windows XPをインストールするため、それほどメモリもHDDも必要ない。

　今回はTech-NetからダウンロードしたWindows XPのISOイメージを使用して、Virtual PCにインストールした。インストール自体は、簡単に終了するが、問題はWindows Updateだ。Windows XP SP3リリース以降、さまざまなアップデートがバグフィックスが提供されているため、完全に終了するまでには、1時間ぐらいかかった（MED-Vの動作には、.NET Framework 3.5 SP1が必要）。

　さらに、Windows XP SP3でRemoteAppを使用できるようにXPのホットフィックス（KB961742-v3　http://www.microsoft.com/downloads/details.aspx?FamilyID=e5433d88-685f-4036-b435-570ff53598cd&displaylang=ja）をインストールする。

　なお、MED-VでWindows XPを使用する場合、ログオンに時間がかかる場合があるので、このトラブルを回避するために、レジストリを変更する。HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinlogonにBufferPolicyReadsというエントリーをDWORDで作成する。値は、1でOK。


XP ModeはWindows 7のメディアに入っていないので、マイクロソフトのWeb際とからダウンロードする	ダウンロードしたXP ModeをWindows 7にインストール	XP Modeに対応した更新プログラムをインストール

XP Modeは、Windows 7 Professional以上のエディションが必要になる	XP Modeをインストール	Virtual PCに新たな仮想マシンを作って、XP SP3をインストール

Windows XPでRemote Appが利用できるように、修正プログラムをインストール	MED-V環境でログオンするときに時間がかかるトラブルが起こる可能性がある。このトラブルを回避するために、Windows XPのレジストリを変更する	HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinlogonにBufferPolicyReadsというエントリーをDWORD値で作成する。値は1

■管理コンソールPCにMED-Vをインストール

　Virtual PCにWindows XP SP3をインストールしたら、今度はマイクロソフトコネクト（https://connect.microsoft.com/medv/MED-Vv2Beta）からMED-V RC版をダウンロードする。マイクロソフトコネクトは、Windows Live IDがあれば、誰でもダウンロードできる。

　管理コンソールには、仮想マシンをパッケージ化するMED-V_WorkspacePackager_SetupをWindows 7環境にインストールする。

　MED-V Workspacepackagerを起動する前に、仮想環境のXP上で、XPのインストールメディアのSupport￥ToolsディレクトリーにあるDEPLOY.cabを解凍し、その中にあるsetupmgr.exeを実行し、sysprep.infを作成する。

　sysprep.infを作成する中で、追加コマンドとして"wmic /namespace:\\root\default path SystemRestore call Disable %SystemDrive%\" "c:\Program Files\Microsoft Enterprise Desktop Virtualization\FtsCompletion.exe"を入れる。

　次に、VHDイメージをコンパクト化するために、不必要なドライバーやページングファイルの設定、VHDイメージの圧縮などを行う。今回は、USB HDDなどのMED-Vパッケージをコピーして使用するため、VHDイメージのコンパクト化は行わなかった。実際に、MED-Vを使用する場合は、MED-Vパッケージをコンパクト化した方が、配布が簡単に行える。ただ、MED-Vの動作テストだけなら、VHDイメージのコンパクト化を行わなくても問題ない。

　その後、仮想マシンのWindows XP上でSysprepを実行して、OSの初期化を行う。

　最後に、Windows 7上で、MED-V_Workspacepackager_Setupを実行して、MED-Vパッケージを作成する。

　MED-V Workspacepackagerは、日本語化されていないが、Windows 7の日本語版でキチンと動作する。

　MED-Vパッケージを作成すると、msiパッケージどの複数のファイルが作成させる。このファイルをディレクトリーごと、USB HDDにコピーしておく。


MED-V V2のRC版は、マイクロソフトコネクトからダウンロードできる	Windows XPのインストールメディアからDeploy.cabをXP上に解凍する。そのディレクトリーにあるsetupmgr.exeを実行して、Sysprep.infを作成する	追加のコマンドに、"wmic /namespace:\\root\default path SystemRestore call Disable %SystemDrive%\" "c:\Program Files\Microsoft Enterprise Desktop Virtualization\FtsCompletion.exe"を追加する

作成したsysprep.infを保存する	XPのSysprepを実行して、OSを初期化する	インストールしたMED-V_Workspacepackager_Setupを実行する

パッケージ化する仮想イメージのWorkspace名などを指定する	MED-Vを利用する上でのセットアップメッセージやオンラインヘルプをカスタマイズすることもできる	MED-Vパッケージ化する仮想マシンが使用するネットワークの設定などを行う

MED-Vパッケージを行う	MED-Vパッケージ化が終了。ここでエラーがあったら、トラブルが起こっているので、再度設定などを見直して、再度実行する	作成したMED-Vパッケージ。今回は、VHDのコンパクト化は行っていないが、XPにほとんどアプリケーションをインストールしていないため、それほどディスク容量は消費していない

■ターゲットのPCにMED-Vパッケージをインストール

　次に、MED-VパッケージをインストールするPC（Windows 7）に、Virtual PCをインストールしておく。MED-Vでは、自動的にVirtual PCをインストールすることはしない。

　次に、MED-V_HostAgent_Setupをインストールしておく。

　最後に、管理コンソールPCで作成したMED-VパッケージのSetup.exeを実行して、MED-Vでパッケージ化した仮想マシンをインストールする。


ターゲットPCにMED-V_HostAgent_Setupをインストール。MED-V_HostAgent_Setupをインストールする前に、Virtual PCをターゲットPCにもインストールしておく必要がある	作成したMED-VパッケージをターゲットPCにコピーして、Setupを実行する	MED-Vパッケージをインストール中

■MED-Vを動かしてみる

　今回は、あらかじめ管理コンソールで、XPのWindows SearchとSecurity EssentialsをRemoteAppで動かすように設定したおいた。

　ターゲットのPCでMED-Vパッケージをインストールと、自動的にVirtual PCにRemoteAppとして登録されている。

　Security Essentialsをクリックすると、動作しているのが分かる。ただし、このSecurity Essentialsは、XP上で動作している。

　また、Windows Searchを動かしてみると、仮想マシン上のXPで動作しているのがよく分かる。


このSecurity Essentialsは、XP上で動作している。左のMED-V User SettingでMED-Vを管理する	XPのWindows Search。システムプロパティを見ると仮想環境でXPが動作しているのが分かる。RemoteAppで動作しているため、Windows 7のアプリケーションとしてシームレスに利用できる

■MED-V V2は使えるシステムか？

　実際にMED-V V2を使ってみると、ターゲットPCとMED-Vパッケージを作成する管理コンソールPCだけでOKなので、以前のV1よりも必要するPCが少なくなっている（このほか、AD環境が構築されている必要があるが）。MED-Vパッケージの配布に関しては、SCCMなどのアプリケーション配布システムをそのまま利用する。もし、テストだけなら、MED-Vパッケージを手動でコピーすればOKだ。

　MED-VパッケージをインストールしたターゲットPCは、特殊なXP Modeを動かしているのとほとんど変わらない。このため、仮想化システムとして、MED-VといえどもVirtual PCがベースとなっているため、使い勝手はユーザーにとっては全く違和感ないだろう。

　ただ、MED-Vパッケージを作成するための手順としては、全くオートマチックとはいかない。まだMED-V V2がRC版という状況のためか、管理者がさまざまな設定を行う必要がある。この部分は、分かりにくいし、面倒な部分だ。

　単一のOSイメージを配布し、自動的にRemoteApp環境を構築できるのは便利だが、MED-Vパッケージを作成するまでにいろいろ面倒な部分があるのは、MED-Vにとってはデメリットといえるのではないか。

　ではMED-V自体はどうだろう。MED-Vは、Windows 7上でXPのアプリケーションを動かし、利用することができる。実際、古いXPアプリケーションを利用するには、便利なソリューションだ。Windows XP上でアプリケーションをどうしても使うことが必要な企業にとっては、MED-Vは気になるソリューションだろう。

　しかし、XPアプリケーションをいつまでも企業内で利用しているわけにもいかないだろう。そういった意味では、MED-Vは緊急避難的なシステムだ。やはり、将来的には、XPでしか動かないアプリケーションをWindows 7に移行していく必要がある。

　このとき重要なのが、スタンドアロンのアプリケーションとIE6などを使ったWebアプリケーションだろう。スタンドアロンのアプリケーションは、Windows 7上で動作しないアプリケーションも多いため、パッケージソフトならバージョンアップするか、企業内部で作成したアプリケーションなら作り替える必要がある。企業内部で作成したアプリケーションの場合、作成したときのソースコードや開発したときのドキュメントがキチンと残っていれば何とか移行できるが、外注に依頼したり、ドキュメントやソースコードが残っていないことも多い。そうなると、全く新たに開発するしかなくなる。

　企業の多くのユーザーが頻繁に利用しているなら、開発コストもなってくできるだろう。しかし、それほど利用されていないアプリケーションをWindows 7に移行するには、コスト的に無駄になる可能性がある。ここまでくると、互換性などのテクニカルの問題ではなく、ITシステムに対する戦略になる。

　それほど多くのユーザーが利用していないなら、Windows 7の別のアプリケーションに変更することが可能なのか、古いデータをコンバーターソフトで移行することができるのか、などを考えるべきだろう。

　IE6でしか動作しないWebアプリケーションは、将来を考えれば、さまざまなブラウザーに対応できるWebアプリケーションに変更していくべきではないか。

　MED-V自体は、企業にとって便利なソリューションだが、どうしてもMED-Vを導入しなければならないのかというのは、キチンとITに対する戦略を考えていくべきだろう。むやみやたらに、互換性だけを考えていくのではなく、日々変化していくITシステムを長期的にどうしていくのかを考えていく必要がある。その上で、短期的にMED-Vのような互換性が必要になるなら、導入した方がいいだろう。ある意味、MED-Vのようなシステムは、短期的なつなぎのシステムといえる。