カスタム静止スクリプト

かつて VCB (VMware Consolidated Backup)のころ、アプリケーションレベルでの静止点を取得するためにスクリプトを走らせる機能が存在した。これがカスタム静止スクリプトだ。

これは VCB時代のドキュメントの仮想マシンバックアップガイド(PDF) の P.44 に記載がある。VCBによるバックアップ開始時に  %WINDIR%\pre-freeze-script.bat が実行され、終了時に %WINDIR%\post-thaw-script.bat が実行される。

ただ、当時試したところ動いている様子がなく気になっていたのだが、その時は急ぎ確認する理由もなかったのでそのままにしておいた。

そして、先日 カスタム静止スクリプトについて調べる機会ができたので少々確認をしてみた。

ご存じの通り、VCB のサポートは vSphere 4 までで終了し、現在では VADP (vStorage API for Data Protection) が利用されている。VCBはコマンドベースの技術でバックアップソフトからVCBのコマンド(vcbMounter.exe)を呼び出して連携をとっていたが、VADPはライブラリで提供され、バックアップソフトはこのライブラリのAPIをコールする事で連携をとっており、より密接な制御が可能となった。

さて、では VADPでカスタム静止スクリプトがあるかというと、まだ存在する。これについては、KB1006671が詳しい。

ESX/ESXi のバージョン	カスタム静止スクリプトのパス
3.5U1 とそれ以前	%WINDIR%\pre-freeze-script.bat %WINDIR%\post-thaw-script.bat
3.5U2 とそれ以降	C:\Program Files\VMware\VMware Tools\backupScripts.d\
4.x	%WINDIR$\backupScripts.d\
5.0	両方の場所を確認する
5.1, 5.5	%WINDIR%\pre-freeze-script.bat %WINDIR%\post-thaw-script.bat

なお、backupScripts.d フォルダはデフォルトでは作成されていないので、利用する場合は自分で作成する必要がある。backupScripts.d フォルダ以下にあるバッチファイルなどが全て実行されるが、その順序はバックアップ作成時はアルファベットの昇順(A-Z)で、終了時は降順(Z-A)となる。
Windows XP では 3.5U2 以降で実行していても旧来の pre-freez-script.bat 等が使われるようだ。

見ての通り、実は ESX/ESXi 3.5U2 以降でパスが変わっているのだ。これで当時うまく動かなかった理由が判明した。

私が VMware Infrastructure 3.5 を使い出したのは U2 の頃からで、それ以前は 3.0.3 を中心に 3.5 は様子見をしていたからだ。

なお、Linux など Windows 以外のOSの場合は、/usr/sbin/pre-freeze-script, /usr/sbin/post-thaw-script が実行されるようだ。これについては VMware DataRecovery 管理ガイドの P.8〜9 あたりに記載がある


追記: VCB サポートは vSphere 4.0 までではなく 4.1 までだったので訂正。そういえば 4.1 も VCB1.5u2 でサポートされていたのでした。
追記:20150106, 気がついたら対応表が変わってたのでこちらも更新

Mac で ESXi は動くのか?

結論から言うと、「動作はする、サポート機種なら」となる。

サポート機種があるのか? といわれると1機種だけ実は存在する。Xserve だ。

VMware 社の HCL で確認すると「Xserve3,1」が記載されている。

しかし、多くの人は「Xserve3,1」というのが何かさっぱりだろう。

これは、Apple での「機種ID」を意味する。マックをお持ちの方なら、アップルメニューから「このMacについて」を選択、「詳しい情報」を押すと「Apple プロファイラ」というアプリケーションが立ち上がり、その Mac の詳細情報が表示される。

メインウィンドウで 「ハードウェア」の項目を選択、右側を見ると「機種ID」というのがあり、「MacBookPro6,1」とか記載があるはずだ。

また、フリーソフトの Mactracker を使うと機種IDを調べる事が出来る。

機種IDはハードウェアとしての世代を表す。概ね「ハードウェア名」.「メジャーバージョン」,「マイナーバージョン」ともいえる形になっている。同時期に売られている機種でも、iMac10,1 と iMac11,1 という感じでマイナーバージョンは異なることがある。
(これは2009年度後半に発売された iMac の場合で、Core2Duo 搭載は iMac10.1, Core i5, i7 搭載は iMac11,1 であった)

Xserve の場合、この機種IDは少々数奇な運命を辿っている。2002 年に発売された初代 Xserve は、「RackMac1,1」であった。どうもぎりぎりまで Xserve という名前が決まらなかったようで RackMac というコード名のままになっている。翌年発売された第二世代は RackMac1,2 で、仕様にほとんど差はない。筐体の剛性が上がり共振が押さえられたのと、ファンの回転制御がOS側から行えるようになり、騒音で悪名高かった初代より静かになったぐらいだ。

機種IDが  Xserve1,1 となったのは 2006 年の Intel 版の Xserve のリリースからだ。これは Xeon5100 を搭載していた。2008年に Xeon5400 にアップデートされた Xserve (Early2008) がリリースされたが、これが Xserve2,1 の機種IDをもつ。

で、問題の Xserve3,1 を持つのは 2009年1月にリリースされた Xserve(Early2009)で、Xeon 5500 をCPUに搭載している。おそらく「Early2009」で調べるか、Xeon 5500 搭載で調べると見つけやすいだろう。

なお、この Xserve (Early2009)は Xserve の最終機種である。

そう、Apple は 2011年1月に Xserve という1Uサーバそのものをディスコンにしている。

そもそも Xserve はサーバ用途という Mac としては極めて特殊なため、出荷台数は極めて少ない。Early2009 に至っては「どれだけ国内にあるのか?」 と疑問を持つぐらい少ない。

Xeon5500 で今でも十分に利用可能なCPUで、さらに最終機種となったのもあってまだまだ現役で動作しているのだろう。中古市場でも見かけることはまずないぐらいレアだ。

私も残念ながら1台しか所有していない。出物があったらもう1台欲しいものだが...。


● Xserve への ESXi のインストール

インストール自体は通常の ESXi と変わらない。

ただ、ESXi のバージョンによっては最初の起動に失敗することがある。

VGA 640x480 などという標準解像度を持たない Mac では、解像度情報を本体側NVRAMに記憶しており、起動時にその解像度で起動しようとする。この解像度によっては vmkernel 側がうまく追従できずそこで止まることがあるようだ。

通常の Mac なら nvram のクリア(SMUリセット)を行えばいいが、これが Xserve では上手くいかない。
 私が試した限り、上手くいくのは  Xserve Intel ユーザーズガイド の P.12 にある方法だ。

1. 一旦電源を落とした状態にする
2. 全面にあるシステムIDボタンを押し続ける
3. そのまま電源を投入すると、フロントのCPU負荷を示す青いランプが順番に点滅する
4. これは起動時チェックを行っているのだが、その間システムIDボタンを押しっぱなしにする。
5. 順番の点滅が終わったところで通常行われる起動が行われないので、そこでシステムIDボタンを離す。
6. 上記マニュアルにあるようにシステムIDボタンを押すと一個ずつ青いランプが点灯するので、下の左から3つ目だけが点灯する状態にする。(NVRAMリセットして起動可能なドライブから起動する。)
7. そして、システムIDボタンをまた押しっぱなしにして、上の列が全て点灯するまで待つ

この方法でやっと ESXi のリリースメディアから起動することができた。

● Xserve 以外では動かないのか?

とりあえず、Macbook や iMac, Mac mini といった通常の Mac ではベアメタルに ESXi をインストールすることは出来ないと考えた方がいい。ESXi側が適切なドライバを持っていないためだ。

私が試したのは Mac mini だが、USBデバイスの認識がおかしく、vmkernel 起動した瞬間にキーボードのキー入力を受け付けなくなった。スクリプトインストールで切り抜けようとしたが、オンボードNICを認識しない時点でハマってしまった。

意外に知られていないが、ESX/ESXi は「vmkernel が認識できるNICが一つもない場合、インストールできない」という仕様がある。これに引っかかった訳だ。

コンシューマ向けの Mac では上記から諦めた方がいい。

ベアメタルではなく、仮想環境の上なら容易に動作する。VMware Fusion 4 では ESXi を仮想環境上で動作させることができるようになっている。ご丁寧にも仮想マシンの作成時に選択可能だ。さらに Virtual  Hardware Virtualization (vhv) を有効にすれば Fusion 上の ESXi で 64bit の仮想マシンを動かすことも出来る...、メモリとCPUが耐え切れれば、だが。

● 6/3 追記
上記に Mac mini ではインストールできなかったと記載したが、ドライバーを整えることでインストールに成功した人がいる。
また、Mac mini を入手できたら試してみたい。

Ubuntu Linux で VMware View Client を動かす

さて、前回 Ubuntu Linux 版の ViewClient が出たという話をしたが、手元の環境では少々動かすのに苦労したのでメモ代わりに。

● 本来の手順

手順としては、 http://downloads.vmware.com から「VMware View Client」を選択

クライアント一覧から「VMware View Client for Ubuntu Linux」のダウンロードをクリック

 すると、Ubuntu ソフトウェアセンターが起動、パッケージが選択されているのでそれをインストール...するはずが、以下のように「見つかりません」と言われてしまう。

さて、どうしてだろうと調べてみた。

● 問題その1: サポートOS

まあ、一つはリリースノートを読むと書いてある。サポートOSだ。

以下に、Ubuntu Linux 版の ViewClient のリリースノート(和訳)だ。
http://www.vmware.com/jp/support/support-resources/pubs/viewclients_pubs/viewclient-linux-release-notes.html

Ubuntu 32 ビット 10.04 および 10.10 のサポート

私が試した Ubuntu  は 11.04 と 11.10 のため、新しすぎた、というのが一つ目の敗因だ。
このため、10.10 日本語 Remix をダウンロード、LiveCDで起動して試してみた。

● 問題その2: レポジトリ

10.10 でもやはり「見つかりません」と言われるので少々確認をしてみた。
どうも、Ubuntu の vmware-view-client は 「Canonical Partners」 というレポジトリにあるらしい。
そこで、10.10 のアップデートセンターでレポジトリを追加した。

通常、 Canonical Partners は「その他ソース」の項目に設定されており、チェック一つでレポジトリとして有効になるようだ。( 参考: http://vpc.uconn.edu/help/linux/ )

しかし、日本語Remix のアップデートセンターの設定では、この項目が見当たらない。

そこで、下の「追加」ボタンを押し、以下のCanonical Partners の APTラインを追加する。

deb http://archive.canonical.com/ lucid partner

これで準備完了だ。

Ubuntu Linux の Firefox で再び、VMware 社のサイトにアクセス、Download ボタンを押すと、以下のように「ソフトウェアの追加インストールを行いますか」のパネルが表示された。

そしてダウンロードが終わると、 インターネットメニューに「VMware View Client」が追加されている。

やっとインストール完了だ。

なお、このAPTラインを追加しても 11.10 などサポートより新しい UbuntuLinux では vmware-view-client が選択肢に出てこない。当分は 10.10 と 10.4 しか使えないようだ。

● VMware View Client for Ubuntu

初回起動時にはライセンス条項の表示と、確認が行われる。

 

こちらをOKすると、ConnectionServer / SecurityServer のURLを入力するパネルが表示される。見た目こそ異なれ、他の ViewClient と同じだ。

URLを入力、「Continue」 ボタンを押すと認証処理が行われる。これも他の ViewClient と同じだ。

認証に成功すると、かなり大きなアイコンが並び、デスクトップVMを選択する画面になる。
これは Mac 版の ViewClient に近い。アイコンの下にプロトコルが表示、選択になるのも同じだ。

アイコンを選択すると、デスクトップが表示される。もちろん PCoIP を使っての接続も可能だ。

ここまでくると非常に快適に利用できる。

課題としては、キーボードについてだ。今回 UbuntuLinux はFusion上の仮想マシンで、かつ LiveCD のため 106 キーボードに設定されており、かつ Mac 側が英語キーボードで配列が厄介な状態だったため確認できていない。

しかし、PCoIP のためおそらくデスクトップVM側に設定したキー配列がそのまま使われるのではないかと思われる。
混乱を防ぐためにも配列を統一しておいた方がいいだろう。

VMware View で RDP 接続しているとデスクトップVMが再起動してしまうことがある

出張が続いたのと、あと VMware Fusion がとある事情から一時的に動かなくなってしまってて更新が遅れてしまった。

さて、VMware View のクライアントソフトウェアが非常に拡充してきたのはご存じだろうか?

詳細は以下にあるので確認して欲しいが、Mac 用のクライアントが新しくなり、また Ubuntu Linux 用の公式クライアントが追加されている。
http://downloads.vmware.com/d/info/desktop_end_user_computing/vmware_view_clients/1_0

実のところ、これまでも Linux 用のクライアントがなかった訳ではない。

ただ、それは Googles Codes にソースコードの形で提供されていた。
http://code.google.com/p/vmware-view-open-client/

クライアントソフトウェア単体として動かすのではなく、Linux ベースのシンクライアント製品に組み込まれるためにこういうソースコード形態での提供がなされていた。

Linux は、今風に言うなら「断片化が激しい」ため、数多のディストリビューションをサポートするには手に余るし、それらを寄せ集めても Windows, Mac ほどの需要はなかったという訳だ。
しかし、ここ数年 Ubuntu Linux は(例のデスクトップ環境のごたごたはあるにせよ) Linux をデスクトップ端末として使う際の定番になっている。何か一つ Linux で ViewClient をサポートするなら、これは順当なところだろう。

また、 iPad 向けのソフトウェアも着実にアップデートされており、Android 用も増えている。

これらは全て PCoIP をサポートしており高精細の画面を効率よく転送することが出来る。
ここまで PCoIP 対応のクライアントソフトウェアが充実すると、VMware View で RDP を使うことはほとんどないだろう。

また今回紹介する以下の話からも、今後はRDPを使わない、PCoIP専門に持っていく方が良いといえる。
さて、前書きが長くなってしまったが本題に入りたい。

● 問題

非 Windows 環境の RDP クライアントで WindowsXP SP3 を実行する仮想マシンに接続した場合、接続先の WindowsXP SP3 がクラッシュすることがある。

● 原因

これは、Windows XP SP3 に含まれる RDPDD.DLL のバグである。
詳細は以下のKB963038 に記載があるので参照して欲しい。

・WindowsXP を実行しているリモートコンピューターへのリモートデスクトップ接続を確立すると、エラーメッセージ:"停止:0x1000008E"

また、以下の Blog にも類似の記載がある。

・リモートデスクトップを利用していてリモート先PCがSTOPエラーでブルースクリーン
・リモートデスクトップでOSが落ちる

確認方法としてはブルースクリーンを見るのが一番であるが、そもそもリモートアクセスしてるのだから vSphereClient でコンソールを見るなど難しいであろう。

事後の検証としては Nirsoft の BlueScreenView というソフトを使うと便利だ。
http://www.nirsoft.net/utils/blue_screen_view.html

これはクラッシュに生成される minidump を確認してくれるというものだ。
以下の図のように、ダンプ時の状況を表示してくれるが、ここで Bug Check Code を見ると確かに 0x1000008E であるのが分かる。

● 対応

ここまで分かれば話は早い。つまりはこの RDPDD.DLL の問題を解決すればいいのだ。
これには三つの手段がある。

1. RDPを使わない
2. マイクロソフトの 修正プログラム を適用
3. RDPDD.DLL を差し替える

一番いいのは 1. だ。冒頭に触れたように PCoIP 対応のクライアントは増えてるのだからわざわざRDPを使うことはない。


二つ目は、先に紹介したマイクロソフトのKBにリンクされている 修正プログラム を適用するというもの。Fix253552 というそれをあてればこの問題は発生しなくなる。

ただし、この修正プログラムは WindowsUpdate でははいってこず、先のKB963038のページの「この技術情報に対応する修正プログラムのダウンロードのリスト」にあるリンクからしか手に入らない上、メールアドレスは取られるわ、CAPTCHA はあるわで少々面倒だ。

三つ目は、先ほどリンクしたブログにあるように、WindowsXP SP2 の RDPDD.DLL に置き換えてしまうことで問題が消えるというもの。実際に消えるのは確認したが無理矢理DLLを置き換えるのもあまりよろしくないし、なにより他の問題を引き起こさないかが未知数だ。
だったら、2つめの修正プログラムをあてた方がまだいいだろう。

あと、この問題は WindowsXP SP3 でしか発生しない。つまり Windows7 ならば問題はないのだ。仮想デスクトップも Windows7 にしてしまうというのも解法としてはアリだろう。

[余談] MacOS X のVPN接続をコマンドラインから実行する

仮想化とは関係ないけど、余談で。

MacOS X では VPN接続機能が用意されており、システム環境設定の「ネットワーク」にて、左下の「+」ボタンを押すことで設定が可能になる。標準で用意されているのは、L2TP over IPsec, PPTP, Cisco IPSec の三つだ (Lion の場合)

それぞれを選択、アカウントなど適宜情報を記入することで L2で VPNを張ることができる。

ただ、その接続がシステム環境設定を開いて該当するネットワーク設定を選択、「接続」ボタンを押すか、メニューバーにVPN設定のアイコンをあらかじめ表示させておき、そこから選ぶか、になる。

そう頻繁にVPNを張らない人や、MacBookAir を利用しててメニューバーの横幅が足りないのであまりアイコンを表示させたくない人からすれば、一々システム環境を開くのは面倒だ。

そこで、ターミナルのコマンドラインから VPNを張れないかを調べてみた。
とりあえず、ざっと調べた限りではそれっぽいコマンドは見つけられなかった。のでスクリプトで対応させることとした。

#!/bin/sh
DoScript() {
/usr/bin/osascript << __EOF__
tell application "System Events"
   tell current location of network preferences
       set VPNservice to service "$2"
       if exists VPNservice then $1 VPNservice
   end tell
end tell
__EOF__
    return 0 ;
}
case $1 in
"connect")
    DoScript "connect" $2 ;;
"disconnect")
    DoScript "disconnect" $2 ;;
esac

DoScript 関数がこのシェルスクリプトの実体で、osascript にヒアドキュメントで AppleScript を流し込み、実行している。

tell application "System Events" により SystemEvents に対して指示を送り、さらにその中で「current location of network preferences」、つまり現在のネットワーク設定に指示を送っている。
OS X をあまり使われてない方には馴染みのないことだが、OS X では「場所」ないしは「ネットワーク環境」という名前で、使用するネットワークインターフェイスやインターフェイス冠の優先順位、IPアドレス、DNS、デフォルトルート、プロクシーなどの設定をまとめて切り替えることができる。ネットワーク管理をやってた頃はいく先々ごとにこのネットワーク環境を作り、ついたら切り替えることでたとえ固定IPアドレスや特別なプロクシの設定が必要でも一気に切り替えられたので便利なのだ。
ThinkPad など一部のベンダーのPCにも同様の機能はあるが、OS標準でないため細かいところで面倒だったのと、やはりUNIXコマンドが標準搭載なのもあり Macのノートは私の回りのネットワーク管理者にとっては必須のデバイスであった。

何を送ってるかというと $2 にはVPNサービス名が入り、$1 には connect か disconnect が入るため、set VPNservice to service "何らかのVPNサービス名" で、VPNService という変数にサービス名を突っ込む。

それから、if exist VPNservice でそのサービス名に該当する設定があるかを確認、あれば $2, つまり connect(接続)もしくは disconnect(切断)を行う。

case でくるんでるのは、コマンドラインからは connect でも start でもよくしようとして、途中で面倒になったからそうなっているだけだ。( "connect") を "connect"|"start") とかするだけなのだが)

さて、このスクリプトを vpnc という名前でパスの通るところに保存、実行フラグを立てる。システム環境設定のネットワークから「MyOffice」というVPN設定を作った後

$ vpnc connect MyOffice

とコマンドを叩けば、接続される訳だ。
なお、厳密には「接続を指示する」ところでこのスクリプトは終了してしまう。VPNの接続確立までに時間がかかる場合は、そのぶん待った方がいい。

私は接続先に既知のサーバがあるので、ちょっと待ってから ping を打って繋がってる確認した後に利用するようにしている。

もう少し頑張ればVPN明があるかをチェックしてなければエラーを返すとか、色々改善もできるだろうが私の用途ではこれで十分なのでそこから直していない。

USBメモリから起動するOSを仮想マシンで利用する(1)

先日、とある事情にてUSBメモリに書き込まれたOS (Linux) を仮想環境上で起動することになった。その時の手順のメモ。

残念ながら、VMware Fusion は、いや VMware Workstation もその他製品も、USBメモリからのブートを直接対応していない。起動可能なデバイスは仮想環境上で

HDD, 光学ドライブ, FD と認識されるものか、ネットワークブート(PXE)だけだ。

これは、VMware が実現している仮想ハードウェアが Intel 440BX という90年代中盤に存在したチップセットのエミュレーションをしていることが遠因だ。

当時は CD-ROM ブートですらできるとは限らなかった。( Windows NT4 や OS/2 Warp など当時のOSはフロッピーで起動、ドライバを読み込んでからインストール用のCDを認識したものだ。)
そもそも USBについては  Windows 98 の登場までほとんど利用できず、実質的な普及は98年末の iMac の爆発的な普及の後からだ。USB起動は考えられてなかったのは仕方のないことだ。

この時はあまり時間もなかったので手っ取り早い手段で解決した。

● Plop Boot Manager

Plop Boot Manager はその名の通りOSの起動を制御するブートマネージャで、HDD や CD-ROM, USB メモリからOSを読み込み、起動させることができる。

この記事を書いてる時点の最新は 5.0.14 。実は試したときは 5.0.13 だったがそう大きな差はない。上記のダウンロードページから zip ファイルをダウンロード、展開すると iso イメージが入っている。

この iso イメージを、仮想マシンの設定の CD/DVD にて選択、仮想マシンに割り当てる。

そして仮想マシンを起動する。

まだOSを入れていない、空の仮想マシンならそのまま PLoP Boot Manager が起動する

なお、VMware は HDD にOSが入ってるとそちらから優先して起動される。CD/DVD ドライブから起動したい場合は設定の「起動ディスク」から選択するか、仮想マシンの起動直後、VMware のロゴの BIOS初期化中にタイミング良くウィンドウをクリックしキーボードのフォーカスを入れて F2 を押すと表示される Phonix BIOS の Boot メニューから CD-ROM の優先順位を上げるといい。後者は VMware  製品共通だが、タイミングが難しいので Fusionなら前者を選ぶのが良いだろう。

ともあれ、PLoP Boot Manager が起動すると星の流れる校歌の右上に「FLOPPY」「CDROM」「USB」といったメニューが表示されている。おもむろにUSBメモリを挿し、仮想マシン側へ割り当てた後にこのメニューからUSBを選択すると、USBメモリ内のOSで起動される。

ただし、製品にもよるが USB メモリからの起動は決して速くない。

結局のところ、Ubuntu Linux のインストールメディアから仮想マシンを起動、dd コマンドで USBメモリの内容を頭から丸ごと仮想ハードディスクに丸々コピーし、そちらから起動するようにしてしまった。フロッピーや CD/DVD-ROM などと異なり、USB メモリのレイアウトはHDDと同様なので、MBRから丸ごと全部コピーしてやればだいたい動いてしまうのだ。

VMware Fusion で XP Mode は動くの?

VMware Fusion 上の Windows7 で XP Mode は動作するかどうか、というと動作する。
これは VMware の KB(ナレッジベース)で説明されている。

・Using Windows 7 Virtual PC XP Mode in Fusion
http://kb.vmware.com/kb/1017526

英文を読むと「ハードウェア仮想化機能が仮想マシン上にはないので XP Mode が動かない」とある。さらに読めば「MSからパッチが出てるので適用せよ」となっている。

以下は XP Mode のダウンロードページだが、持っている Windows7 のエディションと言語を選択すると 3つのコンポーネントがダウンロードできる。

「最初にインストール」とあるのは XP Mode の仮想マシン。VHD 形式のイメージと構成ファイルが用意されている。

「2番目にインストール」とあるのが Windows Virtual PC 。フリーで配布されている Virtual PC 2007 と違い、Windows7 専用のホスト型仮想化ソフトウェアで、エクスプローラとの統合されてて扱いやすい一方、同時に1つしか仮想マシンを実行できないという違いがある。細かい違いは MSのFAQを参照。

なお、この時点ではまだ Intel-VT や AMD-V といったハードウェア仮想化機能が CPU に搭載されている悲痛用がある。

元々はこの2つをダウンロード、実行すれば良かったのだが、Windows7 登場時は思いの外 ハードウェア仮想化に対応したCPUを持つデスクトップマシンが少なかった。

また、ハードウェア仮想化機能は BIOSでPC起動時に有効化する必要があるのだが、対応CPUを搭載していてもほとんどの場合BIOSでは無効化されており、BIOS設定を変更して有効化する必要がある。一部PCに至っては BIOSにこの設定がなく(削除されており)、ハードウェア仮想化機能を有効化することができない。

デフォルトで無効なのは、使わないのにハードウェア仮想化機能が有効化されていると、そこにウィルスが入り込みOSの下に潜みこむことができてしまうから、つまりはセキュリティ上の要請からなのだが、さすがにどうやっても有効化できない、ってのはやり過ぎた。

筆者は Windows7 の登場時、何度も「このパソコンは XP Mode が利用できるか」や「XP Mode が利用できるパソコンを見積もって欲しい」という依頼を受けたが、ハードウェア仮想化機能を有効化できるかはメーカに聞いても教えてくれない事があまりに多く閉口したことがある。

普段扱っているサーバ機器でメーカ窓口が Intel-VT を有効化できるかできないかを知らないなんてあり得ない話だが、当時のデスクトップ/ノートPC側のサポート窓口ではまだそのような情報は出回ってなかったようだ。

結局、オンラインでダウンロードできるマニュアルをさがし、BIOS設定項目を探したものなのだ。

閑話休題。

ともあれ、マイクロソフトが思った以上にハードウェア仮想化機能はデスクトップ環境に広まってなかった。そこで「ハードウェア仮想化機能がなくても Windows Virual PC を動かせるパッチ」( KB977206 )が提供された。

上記ページで、「三番目にインストール」とある Windows XP Mode update が、この KB977206 のパッチなのだ。

つまり、3つ目までインストールした時点で、ハードウェア仮想化機能がなくても Windows Virtual PC が使えるようになる。

VMware の KB に記載されているのはこの KB977206 を適用せよ、という事なのだ。

なお、Windows Virtual PC が起動する際に NICをプロミスキャスモードに設定する。

VMware Fusion で Windows7 を実行、その上で XP Mode を使おうと Windows Virtual PC を起動すると仮想NICをプロミスキャスモードに設定しようとして、Fusion が警告パネルを表示するだろう。

全くの余談だが vSphere (ESX/ESXi) 上の Windows7 で XP Mode を使おうとするとこの点が問題になる。ESX/ESXi の仮想スイッチ上にポートグループのデフォルト設定では、プロミスキャスモードの設定を許可していない。リモートデスクトップなどで Windows7 仮想マシンに接続しながら XP Mode を有効にするとプロミスキャスモードへの移行を拒否する余波でリモートデスクトップが切れてしまい、何が何だか分からなくなる。

対処法はプロミスキャスモードを許可したポートグループに仮想NICを接続すること、だ。