2012/04/24
2012/04/14
VMware Tools のアップデート追記
昨日公開した VMware Tools のアップデート情報だが、間の悪いことにこれに関係するもう一つ新しいアドバイザリ VMSA-2012-0007 が出ていたので追記したい。
これは、Windows 向けの VMware Tools のフォルダの権限付けにミスがあり、これを突くことでゲストOS上の特権を奪えるというものだ。
上記のアドバイザリを参照して頂ければ分かるが、この脆弱性をもつ製品は非常に幅が広い。
まぁ、要するにこの脆弱性への対応パッチやアップデートを含まれてない製品全て、ということになる。ホスト製品の場合はそれぞれ後継製品に、ESX/ESXi の場合は該当パッチを適用することで内蔵される VMware Tools に更新されるので、アップデートやパッチ適用後、Windows をゲストOSとする仮想マシン全ての VMware Tools をアップデートする必要がある。手間がかかるが必ず実施した方が良い。
なお、VMware Fusion 4.1.2 をダウンロード、その中の VMwareTools を確認したところ、バージョンは 8.8.3 (8.8.3.12575)、ビルド番号は 683185 のようだ。
これは、Windows 向けの VMware Tools のフォルダの権限付けにミスがあり、これを突くことでゲストOS上の特権を奪えるというものだ。
上記のアドバイザリを参照して頂ければ分かるが、この脆弱性をもつ製品は非常に幅が広い。
- VMware Workstation 8.0.1 とそれ以前
- VMware Player 4.0.1 とそれ以前
- VMware Fusion なら 4.1.1 とそれ以前
- ESX/ESXi なら 3.5, 4.x, 5.0
まぁ、要するにこの脆弱性への対応パッチやアップデートを含まれてない製品全て、ということになる。ホスト製品の場合はそれぞれ後継製品に、ESX/ESXi の場合は該当パッチを適用することで内蔵される VMware Tools に更新されるので、アップデートやパッチ適用後、Windows をゲストOSとする仮想マシン全ての VMware Tools をアップデートする必要がある。手間がかかるが必ず実施した方が良い。
なお、VMware Fusion 4.1.2 をダウンロード、その中の VMwareTools を確認したところ、バージョンは 8.8.3 (8.8.3.12575)、ビルド番号は 683185 のようだ。
2012/04/13
VMware Tools のアップデート
少々旧聞だが、VMware 製品のセキュリティアップデートを通知する Security Advisories & Certifications に掲載された VMSA-2012-0004, VMSA-2012-0005 にて 「Windows版VMwareTools に含まれるディスプレイドライバ(XPDM, WDDM双方)にてメモリ管理の脆弱性があり仮想マシン内の Windows で特権を奪われる可能性がある」旨が告知されている。
対策としてはパッチ適用(ESXi500-201112402-BG など)になるが、これは ESX/ESXi に含まれる VMwareTools のイメージをアップデートするだけだ。具体的にこのパッチでのアップデート事項は KB 2007672 を参照して欲しい。
すぐに気がつかれたかと思うが、ただパッチを当てるだけでは問題は解決しない。各仮想マシンの VMware Tools をアップデートする必要がある。
逆に言えば、パッチを当てなくても VMware Tools さえ最新版を入手、アップデートすればこの問題については回避できる。
最新版の VMware Tools (Windows版)は以下ページから入手できる。
x86(32bit)と x64(64bit)があるのでそれぞれ入手して欲しい。
また、VMSA-2012-0005 では VMware Workstation 等ホスト製品については問題がないとされているが、これはその環境で仮想マシンを動かしている場合に限られる。
VMware Workstation 7.1.5 より前、Player 3.1.5 より前、VMware Fusion 4 より前の各製品で作成、当時の VMware Tools をインストールしている仮想マシンを ESX/ESXi 環境に持って行った場合、VMware Tools のバージョンが古くてやはり問題が発生する。
もちろん、そもそも仮想マシンを ESX/ESXi 環境に転送しないなら問題はない。
対策としては、VMware Workstation なら 8へアップグレードする、7.x なら 7.1.5 にする、Player なら 3.1.5 をダウンロードしてアップデートする、VMware Fusion なら 4 を購入し、その上で VMware Tools をアップデートしておくといい。
とはいえ、仮想化製品をそうもアップデートできない、購入できない場合もあるだろう。その場合はやはり上記のページから VMware Tools をダウンロード、アップデートしておいた方が安全だ。
なお、VMSA-2012-0004 では同じ問題を記述しているが、こちらは VMware View に対するアドバイザリで、対策として「View 5.0 か 4.6.1 へアップグレード後、各仮想マシンごとの ViewAgent をアップデートする」という手順が記載されている。
脆弱性は VMware Tools 内のディスプレイドライバなので奇妙な話だが、View を使ってる場合は ViewAgent もあわせてアップデートしておいた方がいいだろう。
カスタム静止スクリプト
かつて 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が詳しい。
なお、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, 気がついたら対応表が変わってたのでこちらも更新
これは 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, 気がついたら対応表が変わってたのでこちらも更新
2012/04/08
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 にある方法だ。
● 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 を入手できたら試してみたい。
サポート機種があるのか? といわれると1機種だけ実は存在する。Xserve だ。
VMware 社の HCL で確認すると「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 にある方法だ。
- 一旦電源を落とした状態にする
- 全面にあるシステムIDボタンを押し続ける
- そのまま電源を投入すると、フロントのCPU負荷を示す青いランプが順番に点滅する
- これは起動時チェックを行っているのだが、その間システムIDボタンを押しっぱなしにする。
- 順番の点滅が終わったところで通常行われる起動が行われないので、そこでシステムIDボタンを離す。
- 上記マニュアルにあるようにシステムIDボタンを押すと一個ずつ青いランプが点灯するので、下の左から3つ目だけが点灯する状態にする。(NVRAMリセットして起動可能なドライブから起動する。)
- そして、システムIDボタンをまた押しっぱなしにして、上の列が全て点灯するまで待つ
● 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 を入手できたら試してみたい。
2012/03/21
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
このため、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ラインを追加する。
これで準備完了だ。
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側に設定したキー配列がそのまま使われるのではないかと思われる。
混乱を防ぐためにも配列を統一しておいた方がいいだろう。
● 本来の手順
手順としては、 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側に設定したキー配列がそのまま使われるのではないかと思われる。
混乱を防ぐためにも配列を統一しておいた方がいいだろう。
2012/03/18
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 の問題を解決すればいいのだ。
これには三つの手段がある。
- RDPを使わない
- マイクロソフトの 修正プログラム を適用
- RDPDD.DLL を差し替える
二つ目は、先に紹介したマイクロソフトのKBにリンクされている 修正プログラム を適用するというもの。Fix253552 というそれをあてればこの問題は発生しなくなる。
ただし、この修正プログラムは WindowsUpdate でははいってこず、先のKB963038のページの「この技術情報に対応する修正プログラムのダウンロードのリスト」にあるリンクからしか手に入らない上、メールアドレスは取られるわ、CAPTCHA はあるわで少々面倒だ。
三つ目は、先ほどリンクしたブログにあるように、WindowsXP SP2 の RDPDD.DLL に置き換えてしまうことで問題が消えるというもの。実際に消えるのは確認したが無理矢理DLLを置き換えるのもあまりよろしくないし、なにより他の問題を引き起こさないかが未知数だ。
だったら、2つめの修正プログラムをあてた方がまだいいだろう。
あと、この問題は WindowsXP SP3 でしか発生しない。つまり Windows7 ならば問題はないのだ。仮想デスクトップも Windows7 にしてしまうというのも解法としてはアリだろう。
登録:
投稿 (Atom)