VMware Workstation 4.5.3 Build 19414

　メインで使っている DynaBook G7/X19PDEW です。 VMware Workstation 4 のページの環境から 4.5 に更新しました。

　VMware Workstation 4 以降では， ベンダーの開発方向が『PC を忠実に再現し， いろいろな OS を使える』というものから『複数の仮想環境 (ゲスト PC。) を 1 つの物理環境で動作させることにより効率化を図る』というものに変わりつつあります。 『ホストと同じレベルの OS を遜色ない仮想環境で動作させる』べく現行 OS 動作の効率化を重視するようになっているので， 古い OS が切り捨てられつつあります。

[Jul.13,2009：追記]

　VMware Workstation 4.5 は Windows Vista 以降の環境では実行できません。 インストールが普通に行え VMware Workstation 5 等と異なりシステムによる互換性の警告も表示されないことから一見動作するように思えます。 が， 実際にゲスト PC を起動しようとした段階で VMware 側のバージョンチェックにより起動が無効となります。 VMware 5.0 よりも Vista への対応度は低いでしょうから， たとえ VMware による決め打ちのバージョンチェック (メジャーバージョン 5。) が行われなかったとしても， 正常に動作しないと思われます。

　VMware Workstation 4 と同じく Ver 3 となっています。 VMware Workstation 3.2 と比べると， チップセットが 440BX である点は同じですが， BIOS (ちなみに Phoenix。) が ACPI 対応になり AGP も認識するようになっています。 結局はホスト側しだいではありますが， ホストに近い構成のほうが何かと便利なので， ビデオドライバー辺りが AGP の配下となっていない辺りは， ちょっと残念な気がします。

　ゲスト OS を新規インストールした場合にユニプロセッサーマシンとして構成される辺りは VMware 4.0 と変わっていません。

　上述のとおり VMware 4.0 と同じくゲスト PC の版は Ver 3 なのですが， 内部動作が変更されていて， 大きなところでは 1GB 超のメモリーを仮想 PC に割り当てることができたり， 一部の OS の動作が速くなったりしているのですが， その変更が影響して不具合の出てしまう場合があるようです。 私の環境では， VMware 4.0 までは全く問題なく動作していた Win95 OSR 2.5 が VMware Workstation 4.5 ではリソースの競合を起こすようになってしまいました。 おそらく APM マシンとして構成されていたからでしょう。 他の ACPI で構成されているものでは問題が出ていません。

　ちなみに， 競合の回避はできたのですが， VMware が直接エラーダイアログを吐くパターンだったので， 最初は Win95 への対応が打ち切られたのかと思ってしまいました。(笑)

　私の環境での不具合はともかく， VMware 4.5 では 4.0 と比べてもゲストの動作が軽くなっている…ようなのですが (巷での評価。)， ホストがノートパソコンである限り HDD の遅さがすべての足を引っ張ってしまうので， 高速化の恩恵に浴するのは無理みたいです。 残念…。(笑)

　VMware 4.5 へのアップグレードの際は， 4.0 からであってもバックアップをしっかりとった上テストを十分に行ってから移行を行ったほうがいいです。 安易に実行してしまうと大ハマリします。 当然ですが， PC 構成が異なるので 3.2 等からのアップグレードの場合は， WinXP 等のアクティベーション組は全滅します。 注意しましょう。

　ACPI マシンとして構築された Longhorn での構成は次のような感じ：

　VMware Workstation 4 以降では ACPI に対応しているわけですが， 少し試してみた程度ではありますが， VMware 4.0 よりも気軽に ACPI で構築できるような気がします。 少なくとも『新からの新規インストール』では VMware 4.0 と違って ACPI での構成に失敗することはありませんでした。

　実際『電源が自動で切れるか切れないか』くらいの差しかないわけですが， これが大きいんですよね， ゲスト OS と言えども。 まぁ， 設定ファイルという伝家の宝刀を使えば WinXP/2k については自動で切れるようにできるわけですし， Win9x 系は APM でも元から切れてくれるので， こだわる必要がないのかもしれません。 ちなみに呪文は以下のとおり：

　ゲスト PC 設定の対象 OS については， VMware 4.0 と同様実際に入れる OS と合わせる必要があります。 VMware 3.x では設定の初期値が異なるくらい…としか感じられませんでしたが， 4.0 では， たとえば WinXP の設定で Win9x を起動したりすると途中でハングしてしまいます。

　この辺りも効率化に伴う弊害なんでしょうね。 デュアルブート環境のゲスト PC は 4.5 では使えないかもしれません。 もちろん， その都度 OS 設定を変えれば使えるでしょうけれど…。

　そうそう。 VMware 4.0 では鬼門だった Longhorn については， さすがに対象 OS として設定できるだけあって， 謳い文句どおり動作が速くなっているようです。

[Jul.21,2009：改変]

　SVGA II のドライバーについては 10.10.7.0 となっていますが， VMware Workstation 4 と基本的に同じものとなっていて， ホストに直接描画させる…というのが基本です。 ゲスト側のドライバー段階で早々にホスト側へ処理を渡すので比較的描画は速いです。 が， ゲスト PC 自体は VESA VBE に対応しているものの， 専用ドライバーが用意されない OS では結局多くが VGA でしか使えない上に描画も相当遅く， 特に DOS でのハイメモリーへのアクセスの遅さが響く Win3.1 等では描画が死ぬほど遅くなってしまいます。

　欲を言えば Virtual PC のようにボード段階でエミュレートしたタイプのものを基本として， VMware Tools の導入で専用ドライバーを使用…というようにしてほしいところだったのですが， そのような形態が採用されることは ありませんでした。

　この専用ドライバーですが， DirectDraw に対応しているだけで Direct3D 等には対応していません。 なので『ゲスト PC を使って古いゲームを…』とか言った用途に使うとしても限度があります。 DirectDraw については， 7.0a～8.0 を想定しているらしく， その辺りに対応した DirectDraw 専用ソフトであれば， 右上画像のように比較的新しいものでも動作が可能となっています。 反対に， 6.1 レベルのソフトは正常に動作しないことが多く， ゲスト PC が直接落ちたりブルーサンダーとなったりしています。

　VRAM 容量の初期値は 16MB となっています。 この頃既に 16MB では動作しないソフトも登場していましたから， そのようなソフトを使用する場合には次の設定が使えます：

この例では 32MB を指定しています。 ホストの VRAM 容量にもよると思いますが， 64MB でも動作しない場合がありましたので， 容量を増やすとしても 32MB 辺りに抑えておいたほうが良いでしょう。

　一部の OS では， Ver 3 ゲスト PC 利用の最大の問題点となりそうなのが， サウンド周りです。

　Ver 3 では Sound Blaster 16 から Sound Blaster Ensoniq Audio PCI (ES1371) 相当に変更になっています。 ところが， 困ったことに WinMe 未満の Win9x， Win2k 未満の NT 系 OS には， この ES1371 用のドライバーが用意されていません。 Web 上やマニュアルには『Creative Labs の Web ページに転がっているから落として使ってね』と書かれているのですが， (少なくとも普通に探す限りでは) 今ではなかったりします。

　と， ここまでなら困ってしまうところなのですが， 実は VMware Workstation 4 でのトラブルシューティングを逆手にとり， 設定ファイルを利用して強制的に従来の Sound Blaster 16/Pro 相当にすることが可能です。 スペックは下がってしまいますが， 使えないよりはマシでしょう。 ちなみに， 呪文は以下のとおり：

　VMware 4.0 で改善したはずの問題が 4.5 では再発してしまいました。 ボリュームレベルがホスト/ゲスト間で異なってしまっています。 あと， 他の OS では大丈夫なのですが， WinXP 系だけは， Virtual PC 2004 並に使い物にならなくなっています。 鳴らないほうがマシです。(笑)

　今回は『設定ダイアログを使ってネットワークアドレス等を自由に設定』できる点に助けられました。 セキュリティー設定等の絡みもあって VMware Workstation 4 と同じネットワークアドレスに設定したかったもので…。 ただ， 設定画面があちこちに散らばっているというか， もう一つ操作体系がすっきりしていない感じがします。

　引き続き無線 LAN にも対応していますが， 別に直接無線 LAN のデバイスを扱う必要はなく， ホストが無線 LAN に対応してさえいれば， ゲスト PC でメリットを享受できるわけなので， この方面は試していません。

　VMware Workstation 4 から特に構造が変わっていません。 相変わらず更新に時間が掛かっています。 この辺りは早期に改善してほしいところです。 といっても， これは『ホストがノートパソコン』である時点で終わっているような気がしますけれど…。 まぁ， VMware Workstation 3.2 の頃並に…ということで…。

　VMware 4.0 と同じで， ゲスト PC を Ver 2 等から Ver 3 にアップグレードする場合は， 仮想 HDD の利用には注意が必要です。 Ver 2 の頃には， 仮想 HDD 用の作業ディレクトリーを別のパーティションやドライブに設定して， アクセスの高速化やフラグメントの解消を図ることもありましたが， Ver 3 ではこの方法は使えません…というか無意味です。

　というのは， Ver 3 では， たとえ別のドライブ等に作業ディレクトリーを設定しても， Snap 作成時に一旦仮想 HDD と同じディレクトリーに作業イメージがコピーされ， そのコピーされた仮想イメージを基にして新しい Snap が作成されます。 つまり， 実際に Snap を作成する前に作業イメージ分のコピーが延々と行われるわけで， しかも， 仮想 HDD の存在するドライブには『元の仮想 HDD のサイズ + 更新後の仮想 HDD のサイズ』くらいの空きが最低でも必要になってしまうことになります。

　結果として， Ver 3 では作業ディレクトリーの設定を行わず， 空きを十分確保しておくしかないような気がします。 でも， (実サイズが) 8GB 程度の仮想 HDD なら 18GB くらいは空きがないといけないわけで…。 これは結構辛いです。 『+ 更新後のサイズ』である 10GB 程度の空きでエラーになったことがあるので， 『元のサイズ + 更新後のサイズ』が必要みたいです。

　なお， 途中で空きがなくなった場合， その仮想 HDD が失われる覚悟をしてください。 ゲスト PC を実行中， VMware Workstation 4.5 は作業ディレクトリー上に "Longhorn-s001.vmdk.REDO_a00208" といったような作業イメージを作成します。 そして Snap 作成時に， 先ほど書いたように仮想 HDD の存在するディレクトリーにコピーを行い， 仮想 HDD のファイル名を "0_longhorn-s001.vmdk" というような名前に変更した上で Snap の作成作業に入ります。

　ところが， 空きが足りないなどのエラーが発生した場合に， この "0_longhorn-s001.vmdk" の復旧を行わないことが多いのです。 更新作業中にエラーとなったことから作業ファイルが使えないわけなので VMware は『Revert してね』と言ってくるのですが， 復旧が行われていないことから肝心の "0_longhorn-s001.vmdk" が先ほどのエラー終了時に抹殺済みなわけで， Revert を行った結果は空の仮想 HDD が残るのみ…ということになってしまいます。 実験してみたところ， VMware 4.5 でも現象が発生しました。相変わらず， このとんでもないバグを抱えたままのようです。 仮想 HDD のバックアップは確実に作成しておきましょう。(笑)

　Ver 2 ゲスト PC のまま使っている場合， Persistent が使えません。 つまり Shrink ができないことになります。 この点も VMware 4.5 で改善されることはありませんでした。 次の VMware Workstation 5 辺りでは Ver 2 への対応が打ち切られるような気がします。

　VMware Workstation 4 と同じで， (見かけ上は) ホスト OS のものが表示され続けるようになっています。

　が， これが個人的には嫌いだったりします。 ポインターが端のほうにきたときにゲスト OS の枠をはみ出してポインターが表示されるのも気持ち悪いし， 第一， Win2k 以降の OS だと， ホスト OS 上のポインターなのかゲスト OS 上のポインターなのか判らなくなってしまいます。

　ポインターに影がないのは使ったソフトの仕様なのですが， このとおり， ホストとゲスト， どちらのマウスなのか見分けがつきません。

　この新型マウスは VMware Tools で導入されるものなので， どうしても嫌な方は通常の PS/2 互換マウスのドライバーを使用することで， 以前のポインター表示にすることが可能です。

　VMware 4.0 以降のマウスポインターは， ゲスト PC 側で表示している従来のマウスポインターにホスト側のポインターをかぶせて表示しています。 なので， 何らかの拍子でゲスト・ホスト間の整合性がとれなくなると， 2 つのポインターが表示されてしまいます。 おまけに両方のポインターが有効なので， たとえば， ゲスト側のポインターを使ってゲスト PC の操作を行ったときに， たまたまホスト側のポインターが (ホスト側の不特定の) ウインドウの『閉じる』ボタンを指していた…なんてことになると， そのウインドウが閉じられてしまうことになります。
　幸い VMware Workstation 4.5 では改善されているらしく， Ver 3 のゲスト PC では一度もこの現象に遭遇したことがないのですが， 遭遇した場合は， 必ずホスト・ゲストの切り替えを行ってポインターの復旧を図ってから操作を続けるようにしましょう。

　あと， マウスポインターが飛びまくる現象も出なくなっています。

　内部動作が一部変更されているものの， PC 構成自体は同じなので VMware Workstation 4 同様 EMM386 が使えるようになっています。 Win9x 系のインストール時にも， やれ『EMM386 を無効にする』だとか『ソフトウェアスクロールに設定する』だとか苦労させられることはありません。

　ただし， このメリットを享受できるのは Ver 3 ゲスト PC の場合です。 Ver 2 だと VMware Workstation 3.2 よりもワケが悪いのは VMware 4.0 と同じです。

　UMA の状況は以下のとおり：

　使うことのないモノクロ表示用の B000-B7FF を有効にしています。 DC00-DFFF， E400-E7FF の RAM は拡張ボードの領域なので使えません。 当初は使っていなかったのですが， このせいで不安定だったわけではなさそうなので， 今では C800-CBFF についても有効にしています。

　CONFIG.SYS の内容は次のとおり：

　FILES が 8 のままですが， これは addfiles というツールを使って UMB に 32 確保してあります。 後継の OS では最初から UMB での確保が可能ですが， 純粋な DOS では不可能なので。 あと， 東芝版 の EMM386.EXE なので， MS 版とはオプション等が異なっているかもしれません。 BC++ や OPTASM 等にプロテクトメモリーを回す必要があった当時の名残で， EMS のサイズが 6144KB に制限されていたりします。

　VMware Workstation 4 以降では， 流行なのか， タブでゲスト PC の切り替えが可能になっています。 複数の PC が同時に見えないと困る利用法ばかりなので， この画面占有率が高くなるだけのような仕様が個人的には嫌いだったりします。

　専用の子ウインドウを有効にしないとゲスト PC の一覧が表示されないのも (というか， こちらのほうが凶悪。) 改悪でしかないと思うんですけれど…。 『SXGA+ の環境で XGA のゲスト PC の表示がやっと…』というのは問題でしょう。

　見てのとおり， SXGA くらいの領域を占めてしまっています。 ウインドウなしとの差が結構あります。

　VMware 4.0 での変更も気にくわなかったのですが， 4.5 で， さらに改悪されて『ホーム』タブなるものが追加されています。 VMware 3.x の頃のようにゲスト PC の一覧が表示されるものであれば解りますが， 仮想 PC の新規又は既存オープンという 2 つのアイコンが付加されただけのウインドウに何の意味があるのでしょう。 何を意図して付加したのか理解に苦しみます。 まさか VMware を使えるはずもない初心者用ということはないでしょうし。

　反対に， 一般的には， まさしくこの『ウインドウを複数開かずに済む』点がメリットとなります。

　同時に複数のゲスト PC を操作したり， 起動・終了・切り替え等を頻繁に行わないのであれば， 余計な一覧画面は必要なく， タブだけで切り替えできたほうが便利ですし， 余計なウインドウリソースを使わずに済みます。

　VMware 4.1β (4.5) での謳い文句となっていた Longhornβ と Linux kernel 2.6 への対応化ですが， Longhorn は確かに謳い文句どおり動作が速くなっていました。 Linux のほうは， 少なくとも turbolinux 10 desktop は VMware Workstation 4 の頃から問題なく使えていたので， 個人的には関係ありませんでした。

　ゲスト PC の使用メモリーの総計が 1GB を超えられる点については， 使う前はメリットが判らなかったのですが， 使ってみたら非常に便利でした。 というのも， 当然ながら動作は遅くなるものの， 仮想 PC に割り当てられたメモリーについてもスワップが行われるようになっているので， 各仮想 PC のメモリー設定を気にする必要がなくなりました。

　VMware Workstation 4 でのデーターですが， HDBENCH 3.40β6 の数値を上げておきます。 体感速度とは随分違った数値が出てしまうのですが， ゲスト PC の傾向を多少は表しているので…。 左側がホストの通常状態 (雑誌等のデーターに近くするため， フルの 1.9GHz で稼働させています。)， 真ん中が VMware でゲスト PC を動作させている状態 (こちらは， いつも使っている 1.2GHz 稼働です。)， 右が， そのゲスト PC 上の数値です。

===================================================================
                |    DynaBook    |    DynaBook    |   VMware 4.0
                |   G7/X19PDEW   |   G7/X19PDEW   |   DynaBook G7
----------------+----------------+----------------+----------------
  CPU           |  Pen4 1.9GHz   |  Pen4 1.2GHz   |  Pen4 1.2GHz
  Set           |     845MP      |     845MP      |      440BX
  Memory        |   DDR PC2100   |   DDR PC2100   |
                |     512MB      |      1GB       |      256MB
  LCD           |  1400x1050x32  |  1400x1050x32  |   1024x768x32
  GPU           | GeForce4 460Go | GeForce4 460Go | VMware SVGA II
  VRAM          |    DDR 32MB    |    DDR 32MB    |      16MB
  IDE           |    82801CAM    |    82801CAM    |    82371EB
  HDD           |   MK6021GAS    |   MK6021GAS    |   VMware HDD
                |      60GB      |      60GB      |      8GB
  CD            |     UJ-810     |     UJ-810     |     UJ-810
                |   DVD マルチ   |   DVD マルチ   |     コンボ
  LAN           |   100BASE-TX   |   100BASE-TX   |   100BASE-TX
  WLAN          |    802.11b     |    802.11b     |      ――
  USB           |    2.0 * 3     |    2.0 * 3     |      ――
  IEEE 1394     |       1        |       1        |      ――
===================================================================
  HDBENCH 3.40  |   SXGA+ Full   |   SXGA+ Full   |   XGA  Full
---------------------------------+----------------+----------------
  ALL           |       27249    |       22367    |       12097
  Integer       |       43263    |       26666    |       21864
  Float         |       72473    |       45005    |       37162
  MemoryR       |       87832    |       82561    |       60216
  MemoryW       |       36123    |       42330    |       31993
  MemoryRW      |       69795    |       81094    |       57503
  DirectDraw    |          57    |          58    |          14
  Rectangle     |       56284    |       42170    |        1196
  Text          |        4341    |        3737    |        1741
  Ellipse       |        9711    |        6758    |         658
  BitBlt        |         203    |         191    |          30
  Read          |       21827    |       21476    |        8211
  Write         |       17490    |       18354    |        2178
  RRead         |        7499    |        6386    |        4013
  RWrite        |        7255    |        7056    |        1502
===================================================================
	

　まず全体として言えるのは『いかに HDD が足を引っ張っているか』です。 ホスト段階で， すでに頭が 1.9GHz だろうが 1.2GHz だろうが全く変わらない頭打ち状態です。 (笑)　その遅い HDD がトランザクション的処理を行っているゲスト PC は…キャッシュが意味をなさない書き込みが悲惨で， 体感速度も数値どおりだったりします。

　反対に， 描画は数値のような悲惨な状況ではなくて， DynaBook で言えば A1 に載っている S3 Savage IX クラスの体感速度があったりします。 が， どれだけゲスト側で頑張ってもホスト側にとっては所詮『ソフトが普通に描画しているだけ』なのも事実で， ベンチの数値の差は， ある意味ゲスト PC の限界を示しているとも言えます。

　私は， 通常ゲスト PC のプライオリティーを Normal/Normal にしているのですが， これを High/Normal にすると， ゲスト PC の数値・体感速度とも 1 割ほど向上 (HDD を除く。 ^^;) するので， マニュアル等でのチューニングの説明は， 伊達に存在しているわけではないようです。 が， 見方を変えれば最終的に各種処理を行うホスト側の優先度を下げることに他ならないわけで， VMware Workstation 4.5 では， それによるデメリットが意外と大きいような気がします。 サウンドなどは途中で切れてしまったりしますし…。 VMware Workstation 3.2 のほうは High にしても大丈夫なのですが…。

　なお， ホストの Text の数値が低いのは Clear Type を有効にしているからで， これを切ると約 10 倍の巷と同じ数値になります。 反対に言えば， Clear Type を有効にするとフォントの描画が 1/10 になってしまうわけです。 (^^;;