VirtualBox 5 と VMware player 7 の比較

投稿者名: 
Aqualight
ホストOS: 
N/A
ゲストOS: 
N/A
本文: 

 読者の皆様、こんにちは、こんばんは。 Aqualight です。
こちらのサイトで VMware の話を書くのは論外とも思えますが、仮想マシンは目的に対する手段そのものです。
どちらを選ぶかは目的次第と言えます。
足りない情報もあるかもしれませんが、私が調べた範囲で一覧表にしてみました。

 

VirtualBox 5 と VMware player 7 との比較表
比較項目 VirtualBox 5 VMware player 7 備考
CPU 最大 32
上限:論理コア数
最大 ?
上限:論理コア数 x 2
ハイパースレッド 1 コアは
2論理コアとしてカウント
Memory 上限:ホスト搭載量の90%
最大:ホスト搭載量の70%
全ての仮想マシンで
最大 64 GB
実質は
仮想マシンの合計=ホストの70%
V-RAM 最大 256 MB
ワーク含め 384 MB
最大 2 GB 実際にはゲストOS依存
32 bit OS:32 ~ 768 MB
64 bit OS:512 MB ~ 2GB
スナップショット機能 ツリー状サポート なし
この機能は Workstation で
サポート
 
仮想HDDユーティリティ ○:但し vdi のみ ○:但し vmdk のみ 自社オリジナル形式のみ対応
3D 拡張 Hardware 可:但し不完全 software emuration
遅いが ほぼ再現
但し Windows は 2000 以降
Player は 95系 Windows の
3D 拡張を Ver 7 から切り捨てた
ウィンドウ・モード
カスタマイズ機能
有り 無し メニューやアイコンの 表示/非表示 機能
画面動画キャプチャ 有り 無し 但し、マウスカーソル無し
音声も録音されない
対応ホスト x86 CPU 搭載機 かつ OS が
Linux、Windows、Solaris、Macintosh
x86-64 CPU 搭載機 かつ OS が
64 bit の Linux、Windows
VirtualBox:32 bit ホストでは
    64 bit ゲストは不可
Player:ホストは 64 bit のみ
対応ゲスト x86系OSほぼ全て
但し16bitコード混在不可
x86系OSほぼ全て
一部機能制限あり
 

 

 一覧表では詳細が不明になりがちですので、以下に補足します。

 

VMware Player 7 とは

 VMware Player 7 とは VMware 社が販売している VMware Workstation 12 という仮想環境のサブセットです。
VMware Workstation 12 をインストールすると、自動的に Player 7 がインストールされますが、Player 7 は単独でも
インストール可能です。
Player は、言わば仮想マシン再生専用ユーティリティではありますが、仮想マシン自体も作成可能です。
販売物の一部ではあるものの、 Player は単独で、しかもライセンス無しでも利用可能になっています。
VirtualBox と比較すると、Player はサブセットであるため、ユーティリティや管理機能は貧弱です。
しかし、一般ユーザーの利用するデスクトップを仮想化し運用する分には十分な機能を持っています。
(ライセンス的に無償での利用は商用不可ですが、機能制限は僅かです。)
販売物ゆえプロプライエタリなソフトウェアなのですが、ソースの非公開をもって製品としての信頼性を保証し、
仮想マシン上で動作するOSやアプリの多さや、その再現性には定評があります。

 詳しくは以下のリンク(Wikipedia)より お確かめ下さい。

Wikipedia("VMware Player")

 

VirtualBox 5 と VMware Player 7

 

  VMware Player 7 以降は 64 bit ホスト上でしか動作しません。
このため、比較対象の VirtualBox 5 も 64 bit ホスト上で動作している物として記述します。

 

仮想CPU

 VirtualBox は1仮想マシンあたり最大で 32 仮想CPUを仮想マシンに与える事が可能です。
ですが実際にはホストマシンの論理CPUコア数が上限です。
つまり、仕様では最大 32 コアであっても、ホストマシンのCPUコア数が4だと最大が4、
その CPU がハイパースレッド(H/T)仕様だと設定可能なコア数は最大8となる訳です。
因みにハイパースレッド(H/T)とはインテルの開発した技術で、物理コア1個を2個の論理コアとして利用可能な技術です。
(但し、完全に2倍のパフォーマンスではなく、実測 120% 最大 150% 程度だとか。)
新規仮想マシン作成ウィザードでも、ホストの論理CPUコア数が上限となります。

 一方 VMware はホストマシンの論理CPUコア数の2倍を上限としています。
つまり、ホストマシンの CPU が4コアだと仮想マシンに8コアまで与えられます。
両者に共通する部分では H/T への対応です。
両者とも論理コア数が与えられるため、H/T 仕様の4コアCPUだと8コアを基準にした最大コア数で利用可能です。
つまり H/T の4コアCPU だと VMware では 16コア、VirtualBox だと8コアが上限となります。
但し、両者とも仮想マシンに物理コア数以上のCPUを与えると、パフォーマンスが落ち、実用的な上限は
ホストの物理CPUコア数と同じです。
イメージとしては、VirtualBox ではホストマシンの CPU の H/T をそのまま使い、VMware では H/T の無い CPU のために、
仮想マシンとして H/T 機能を付加している感じです。

 

仮想マシンのメインメモリー

 メインメモリーに関しても興味深い違いがあります。
先ずは OS のメモリー管理の概要について考察してみます。
ご存じの方は読み飛ばしてください。

 32 bit OS で利用可能な最大メモリーは 4 GB です。
これは汎用レジスタ幅が 32 bit として作られた事による制約で、アドレス計算が 4 GB の範囲でしか表現できないからです。
この範囲には V-RAM や システム領域と その作業領域を含んでいるので、ユーザーが利用可能な範囲は更に小さくなり、
最大ユーザーメモリーは 2~3 GB 程度になるのが一般的です。
この概要を公式化すると以下になります。

最大搭載メモリー量 = 4 GB - ( V-RAM + OS領域とOSワーク)
利用可能メモリー量 = 搭載メモリー量 - (V-RAM + OS領域とOSワーク)

 続いて CPU に PAE 機能が存在する場合です。
PAE/NX に関しましては以下のリンク(私の前回投稿)を参照して下さい。

 ・PAW/NX:http://vboxmania.net/content/paenx
 ・ゲストOSとPAE/NX:http://vboxmania.net/content/ゲストos-と-paenx

 32 bit OS でもサーバー用途なら PAE/NX が有効に使われ、メモリー範囲は 4 GB を超えます。
しかしブロック単位でメモリーを扱うため、最大ブロックサイズを超える情報の扱いには苦労します。

 64 bit OS の場合、与えたメモリーが全て有効に活用されます。
仮にメモリー不足が発生しても、それは純粋に搭載メモリーが足りなかっただけで、メモリーを追加すれば簡単に解消します。
利用可能メモリー範囲に対して V-RAM や システム/ワーク は非常に小さく、現状では巨大テータや大量データを扱うための
OS とも言えます。
 64 bit CPU でも PAE 機能は搭載されていますが現状では利用しません。
むしろ同時に有効化される NX ビット(インテルでは XD ビット)を利用するために PAE 機能を使います。
因みに NX ビットとは、アドレス変換時にOSから認識されなくなったメモリー範囲に置かれたプログラムの実行を禁止し、
OS管理領域外からの攻撃を防ぐセキュリティ機能に利用します。

 

 OS のメモリー管理の概要を再確認したところで仮想マシンのメモリーの話です。
仮想マシンでも V-RAM は実機のビデオカードをイメージした形で与えられ、ゲストOS に相応しい容量が与えられます。
このため「32 bit OS の最大メモリーは 4 GB だ。」とは言っても、実際には 4 GB - V-RAM が最大メモリーになります。

 ゲストOS が 64 bit なら与えた全てがメインメモリーとして利用されます。
32 bit OS で PAE 利用の場合は、ホストのメモリー搭載量の制限はありますが、最大 63 GB 程度まで可能です。
これは一般論ですが、 VirtualBox と VMware では微妙に異なります。

 VirtualBox の場合は…
仮想マシンに与えられる最大メモリー量は資料が見つからなかったので不明ですが、PAE 機能の利用を前提に 64 GB 程度だと
思われます。
しかし仮想マシン生成時には、その時点でホストマシンに搭載されている全メモリー量の 90% が設定可能最大メモリー量となります。
とは言え、ホストマシンのメモリーの 70% が運用上の最大で、それ以上を設定すると警告が出るし、90% 以上だと設定不能です。
 また複数の仮想マシンを同時に運用する場合は、それぞれの仮想マシンで利用する(V-RAM を含む)メモリーの合計がホスト搭載
メモリーの 70% 以下であれば運用可能です。

 VirtualBox 仮想マシンでは、ゲストOSの挙動はリアルOSと同じで、「メモリーは力なり」がそのまま通用します。
メモリー不足が発生すると暗黙にページングファイルによる仮想記憶を利用するOSがあります。
このようなOSをゲストにした場合、VirtualBox 仮想マシンでは、このページングファイルを 仮想HDD 内に確保します。
結果としてパフォーマンスが極端に低下します。
この場合、パフォーマンスが低下するのはゲストOSだけで、ホストのパフォーマンスには影響しません。
実際、32 bit のゲスト OS で「ハイビジョン動画をオンメモリーで編集する」などしない限りメモリー不足にはなりません。
かと言って与えるメモリーをケチると、どうしてもパフォーマンスが低下します。
このパフォーマンス低下を避けるには、やはり利用可能な最大メモリー量を与えるのが適切で、対策としては…

  ・仮想マシンに利用可能最大メモリーを与える
  ・ページングファイルを利用しない またはページングファイルを最小限にする
  ・意識して巨大なデータを扱わない

というのが動作効率を高める定石で、まさに「メモリーは力なり」です。
この様にすると、メモリー不足を起こさない限り、ハードウェアによるメモリー・アクセス速度向上分だけ高速化されます。

 ゲストOSが PAE 機能をサポートしている場合は 32 bit OS であっても 4 GB を超えるメモリーを利用可能です。
それでも運用方法を誤るとパフォーマンスが低下します。 そして、この場合にはホスト側にも影響が及びます。
また、そうならないために仮想マシン作成ウィザードでは、メモリーの設定に制限が課されています。
但し、この制限は仮想マシン単体における設定なので、複数の仮想マシンを起動した場合には簡単にメモリー不足を引き起こします。

 次に Player 7 の場合です。
Player 7 では どんな仮想マシンであっても、最大 64 GB のメモリーを設定可能です。
但し、これが可能な条件は…

  ・ホスト側は 70 GB を超えるメモリーが必要
  ・ホスト用メモリーが独立して十分に確保されている

上記のどちらかになります。

 VMware 仮想マシンの場合は、ホストのメモリー量に関係なく最大 64 GB をページングファイルとして確保します。
しかし、運用上はパフォーマンス向上のため、出来るだけホストから実メモリーを確保し、不足分をページングファイルで
補います。
このため、ホストにも十分なメモリーが必要ですし、常にファイル操作が伴います。
これが VirtualBox よりも体感速度が遅く感じる原因です。
 一般的なホストOSは可能な限りアプリにメモリーを供給します。
だから、利用可能な全てをアプリに与えてしまうと自らの動作に必要なメモリーが不足してしまいます。
このため VMware 仮想マシンにホスト搭載量以上のメモリーを与えると、ホスト/ゲストともにメモリー不足になり
両者ともパフォーマンスが極端に低下し、運用不能になってしまいます。
 ホストOSが、自身が十分に動作可能なワークメモリーを確保して、残りが全てユーザー利用可能なOSの場合、
上記のような状態にはならず、ゲストOSだけがパフォーマンス低下を起こします。

 この事から VMware 仮想マシンはファイル上にメインメモリーを確保するとも言えますが、VirtualBox にも言える事として
「仮想マシンには潤沢なメモリーが必要」という事です。

 因みに、メモリーを 24 GB 搭載した Win 7 64 bit をホストに Player 7 仮想マシンに 64 GB 与える実験を行った結果、
ホストもゲストもフリーズしたかのような極度のパフォーマンス低下を起こし、全く運用出来ません。
その原因を簡単に言えば、ホストとゲストでメモリーの奪い合いが起きるからです。
ホスト側はメモリー不足が発生し何も出来なくなって現状維持だけが可能になりますがフリーズには至りません。
ゲスト側はホストから与えられたメモリーで足りる筈もなく、仮想マシン自体が提供するページングファイルを使うため
極端にパフォーマンスが落ちます。
しかも、そのページングファイルにアクセスするためにホストのAPIを使うため、ホストの側でもメモリー不足が発生します。
それでもメモリー不足なだけで、ゲストを終了すればホストは元の状態に戻ります。
やはりホスト動作に必要なワークメモリーを確保可能なOSでない限り、ホストよりも大きなメモリーを与えるのは危険です。

 メモリー不足時の挙動はメモリーの不足した量によって異なります。
そして不足量が少ない場合はパフォーマンスの低下だけで済む場合もあります。
具体的に言えば 4 GB 搭載したホストにて ゲストに 4 GB 与えた場合です。
両者ともメモリー不足なのは確かですが、ページングファイルが小さい分だけ待たされる時間が短くなるからです。

 Player 7 の仮想マシン設定画面には「 32 bit OS の場合、8 GB 以上では起動しません。」と警告が出ます。
ですが実際は起動可能です。 但しそのメモリーを使いきれるかどうかは別問題で、OS に依ります。
実際、 32 bit の サーバOS など PAE 機能によって 4GB 以上をアクセス可能な物があり、警告自体は無意味です。
しかし「可能だ」というだけで実用的にはホスト搭載メモリー量の 70% が限度でしょう。

 このように VirtualBox とはメモリーの管理仕様が異なるため、 64 bit ゲストではメモリーの制限が非常に緩やかで
しかもその制御がユーザーに任されている部分が異なります。
特徴的なのは、ゲストが確保するメモリーはホストから与えられたメモリーの他に Player 仮想マシン側で
自前のページングファイルを用意する事です。
このため、ゲストOSからメモリーを確認すると、全メモリーがユーザー領域として認識されページングを意識させない仕様です。

 

 VirtualBox と VMware のメモリーに関する差異のまとめです。
最大 RAM 容量
  ・VirtualBox:ホスト依存(ホスト RAM の 70% 程度)
  ・VMware:仮想マシン1台当たり最大 64 GB (運用上は ホストの 70% 程度)
特徴的な仕様
  ・VirtualBox:仮想マシンはオンメモリー(高速性追求)
  ・VMware:メインメモリーのファイル化(安定性・互換性追求)

VMware はメモリーに関して必ずファイルアクセスが介在するようで、これが VirtualBox との体感速度差に現れるのでしょう。
しかし Player 7 になって、高速性も向上し、 VirtualBox 5 との差は縮まっています。
どちらが良いのかは個人の嗜好のレベルではありますが、それでも仮想マシンの運用目的によって決まると思えます。
私の場合は互換性と安定性から VMware を運用に供していますが、VirtualBox の高速性には捨て難いものがあります。
オンメモリーで突っ走る(最速)のは、やはりマニアのロマンなのでしょう。 (笑)

 両者の共通点としては、やはり「大量のメモリーを必要とする」という部分です。
VMware の場合、ホストのメモリー量よりも大量のメモリーをゲストに与える事は可能ですが、
Player では実験的利用であり、ただ「可能だ。」と言うだけで、通常の運用には そのような設定を行いません。
ゲスト・マシンがメモリー不足にならない程度で、かつホストのメモリーよりも少なく設定します。
どちらにしても「大量にメモリーが必要」という点で、「仮想マシンは 64 bit 環境を要求する」と言えるでしょう。

 

V-RAM

 VirtualBox 現時点での最大の弱点は、最大 V-RAM 容量が 256 MB な事です。(I/O 含めて 384 MB)
これは VirtualBox では単一のビデオアダプターしか存在せず、ゲストOSに相応しい(と思われる)容量を固定的に
与えているだけだからです。
私は以前に裏技的手法による Windows XP の V-RAM 増加を公表しています。
VRAM増やしてゲームに対応
通常 XP の最大 V-RAM 容量は 128 MB なのですが、その方法で 256 MB に拡張可能です。
ですが 10 含む Vist 以降でも最大 256 MB で、それ以上大きく出来ません。
また Windwos 10 では ビデオアダプターは「VirtualBox Graphic Adapter for Windows 8 」というシグのままで
仮想マシンマネージャ(VMM)で 3D 機能 を有効化しても ゲストからは使用不能です。
Vista では 3D 機能は可能だと思いますが、ゲームをプレイするには絶対的に足りません。
当座の ウインドウ・モードでの表示では利用可能ですが、複数モニターによるマルチモニター機能をフル活用すると
絶対的に V-RAM が不足します。
VirtualBox では最大モニター数 8 を実装し、かつ1モニターあたり フルHD が可能だからです。
現状の VirtaulBox 5 は Windwos 10 に対して未対応ですが、完全 3D拡張を実装し、少なくとも V-RAM は 2 GB 必要だと思われます。
という事で、この常態では「仮想マシンではゲームをプレイするな」と言われている状況です。

 対する VMware ですが…
Player 7 では V-RAM の最大は 2 GB です。
しかも、どんな仮想マシンであっても設定可能です。 但し全てのゲストで利用できるとは限りませんが。
32 bit OS なら 64 MB ~ 768 MB 、64 bit OS なら 512 MB ~ 2 GB が適正範囲と覚えておけば良いでしょう。
この V-RAM 容量とメモリー容量の和がOS管理範囲内であればOKなのですが、32 bir OS だと V-RAM の巨大化は
ユーザーメモリーの縮小を意味し、運用目的によっては気にすべき部分です。

 両者の差が理解できたところでメリット&デメリットです。
 VirtualBox のメリットは… 実は従来どおりで特筆すべき事はありません。
むしろ 64 bit ゲストではデメリットの方が大きいと思えます。
それは V-RAM 容量が 最大でも 256 MB で、32 bit OS をゲストOSをターゲットにしていると思われます。
言い換えれば 64 bit ゲストではグラフィック機能を多用したアプリには対応出来なくなる公算が大きいと言う事です。
この状態は将来的に改善される可能性はあるものの、現時点ではデメリットでしかありません。
善意で解釈すれば「仮想環境では重いアプリは使わない」を前提に運用可能という事でしょうか。
悪意で解釈すれば「仮想マシンはビジネス以外に使うな」という事でしょう。

 VMware ではゲストOSに 64 bit 版を意識した仕様だと思えます。
そのため、95系 Windows の 3D機能の再現難易度が上がり、利用不能として切り捨てています。(後述)
実際、64 bit のゲストOSでは確かに高速化も果たし使い勝手も良くなっています。
何より巨大とも言える V-RAM のためゲームも再現可能な点も再現性を向上させていると思えます。
惜しむらくは、その 3D機能がソフトウェア・エミュレーションだという事です。
メリットとしては 64 bit ゲストOS を利用しやすい環境である事です。
デメリットとしては 16 bit 環境の再現性を切り捨てた事でしょうか。

 

VMare Player の特徴

何と言っても仮想マシン自体に【仮想ハードウェア・バージョン】が存在する事です。

 VirtualBox では仮想マシンは1種類で、バージョンなどありません。
強いて言うなら VirtualBox のバージョン番号が それに該当し、その理屈は簡単です。
仮想マシンの設定は自作機同様に仮想ハードウェアの選択が可能だからです。
選択肢は少ないですが、この選択によってゲストOSの要求する仕様を実現している訳です。
ですが Windows 10 のような最新のゲストOSから見れば大部分がレガシーデバイスです。

 Player 7 で仮想マシンを生成すると、仮想マシン(仮想ハードウェア)自体にもバージョンが付加され、その番号は 11 です。
これは WorkStation 12 にて与えられた番号です。
なぜなら Player 7 は WorkStation 12 のサブセットであり、WorkStation 12 での互換性を保証するためだからです。
このため、それ以前の WorkStation や Player では仮想マシン自体が動作しない事もあります。
また、この番号で仮想ハードウェアを管理しています。
 基本的な仮想ハードウェアは VirtualBox と同じようにレガシー・デバイスだと思われますが、ゲストOSインストール後に
インストールされる VM Tools を指定する番号で、これによって仮想ハードウェアが微妙に異なります。
また、Player 7 で旧仮想マシンを開くと互換性があれば動作可能ですが、旧仮想マシン仕様で動作します。
このため、そのままでは新機能が利用不能な場合があり、仮想マシン自体のバージョンもアップする必要もあります。
(もちろん制限を知った上で、一部の旧仮想マシンを使い続ける事も可能です。)

 元来 VMware は売り物なので「どんなハードウェアを仮想化しているか」という情報は完全に開示されてはいません。
そのため、仮想マシン自体から仮想環境のバージョンを検出し、適合させる必要がある訳です。
この適合機能は「仮想マシンのバージョンアップ」と呼ばれ、WorkStation の機能であって Player にはありません。
ですが、仮想マシンファイル(テキストファイル)を編集する事によって対応可能です。

但し、仮想マシンをバージョンアップすると旧環境では運用不可能になる場合もあると VMware 社はアナウンスしています。
ですが、(試してはいませんが)旧仮想環境に戻す方法もあって、面倒ですが可能な筈です。
仮想マシン・バージョンを書き変えると追加・改変された機能についてはデフォルトで設定されます。
このような面倒はありますが、「Workstation や Player はそのバージョン毎に微妙にハードウェアが異なる」と
解釈して良いかと思われます。

 

 仮想マシン生成の実態は自作機作成と同じようなものですが、VirtualBox は手動、VMware は自動的に行われ、
ユーザーを悩ますデバイス選択の手間が軽減されているのが特徴と言えますが、だからこそのバージョン管理だと思われます。

 

VMware:バージョン違いによる弊害

 例えば Player 3 で ゲストに Windows 2000 pro を選んだ場合、自動的に Ver 7 の仮想マシンが生成されます。
これは Player 7 では運用不能で、仮想マシンのバージョンは 7 のままです。
しかし仮想マシンを Ver 11 に設定し直すと運用可能になり、 V-RAM も 2 GB まで可能になります。
運用は可能になりますが、この仮想マシンの V-RAM に 2 GB 与えるとメモリー管理上、何らかの障害が出ます。
やはり V-RAM 容量は 32 bit OS に相応しい 128 MB ~ 512 MB に留めておく事になり、特にメリットはありません。
メリットを強いて言うなら、アップグレードした分だけ高速化する事でしょうか。
 95系 の Windwos をゲストにした場合、Player 6 環境で 仮想マシンバージョンは 10 までです。
これを Player 7 で 仮想マシンバージョン 11 にすると3Dアクセラレーション機能が失われ、
6では可能だったゲームが動作しなくなります。

なぜ弊害が出るのか?

理屈は簡単です。 と言うよりも実体験からの方が理解が早いです。
まず、以下の質問に回答してみてください。

現行の 64 bit マシンに 95系 Windwos をインストールして運用出来るか?

要するに、そういう事なのです。
ハードウェアの進歩によって、当時のOSに対応可能なプログラム・コードやデバイスが無くなり、
エミュレーションが多数を占め、仮想マシン開発コストが高まるにも関わらず、用途が限定されます。
その結果、さらにコストアップになるからです。

 

ゲストの実行コードに関して

 まず仮想マシンの動作の概要から…
現在の仮想マシンは両者とも CPU エミュレーションではなく、出来るだけダイレクトに 実CPUを利用しようとします。
また仮想マシンが世に出た頃から比べるとハードウェアも進化しています。
このため、当時のプログラムコードが実行不能になり、仮想マシンの製造コストが上がります。
 それだけではありません。
古いOSの需要は年々低下し、そのOSを動作させる機構自体が無駄になる傾向です。
また、新OSに対応させると、以前の機構はレガシーデバイスとして使われなくなったりします。
簡単に言えば、新しいマシンで古いOSを稼働させる事自体が経済的にも困難になってくる訳です。
このような理由から、再現可能なOSの範囲も制限されます。

 VirtualBox は 32 bit ホスト上でも運用可能です。
しかし、その場合は 64 bit ゲストを利用出来ません。
その理由は至極簡単で、「 32 bit マシン(CPU)には 64 bit 命令が実行不能」だからです。
95 系の Windows をサポートしていない理由も同様で 16 bit コードの混在が、その理由です。
 一方 VMware Player 7 は 64 bit ホスト上でのみ運用可能で 32 bit ホスト上では動作しません。
32 bit ホスト上で動作しないのは残念だとは思いますが販売物としては致し方ないと思います。

 

共通する制限事項

 VirtualBox では 95系 Windows ゲストはサポートしていません。
(投稿時点では最新の Windows 10 はホストもゲストもサポートしていませんが。)

 VMware Player 7 では 95系 Windows のみ 3D アクセラレーションのサポートを廃止しました。
その理由は、「ハードウェアの進化によって、そのマシンでは再現出来なくなった。」とアナウンスしています。

 旧 OS でのゲームの再現性は VMware の方が高かったのですが、これで VirtualBox 程度になったと言えます。
結果からすれば そう言えるのですが、実は仕様上の問題という事で切り捨てたようです。
具体的には、95系 Windows で DirectDraw と Direct 3D が利用不能になり Direct X が使えなくなりました。
つまり Direct X 利用のゲームが実行不能になったという事です。

 この理由は両者とも CPU エミュレーションによる再現ではないからです。
両者とも可能な限り、ソースコードをホストの CPU で処理し、特殊な命令のみ代替する方法で実行しているからです。
このため仮想マシンで旧OSを再現する手間はハードウェアが新しくなる程増えます。
また、ゲスト OS が古ければ古いほど、実際に運用される事も少なくなり複雑性が増え、コストも上昇するからです。
このような理由によって VMware では 95系 Windows を見限り、VirtualBox 同様 Windows 2000 以降のゲストとなっています。

 

VMware player 7 は 95系 Windows の再現性が低下した

 前出の内容で「後述」とした部分で、 Player 7 の特徴でもあります。
Player 7 では 95系 Windows ゲストの 3D 機能拡張を廃止しました。
このため、以前のバージョンではプレイ可能だった3Dゲームの大部分が動作しなくなりました。
VMware 社は「仮想マシンの構造上、出来る限りのプログラムコードをホストCPUに処理させているため、
新しいCPUではコード自体が実行不能になったため。」とアナウンスしています。
しかし、技術的には可能な筈で、むしろ代替コード置き換え処理の実装と3D機能実装に掛かるコストからの判断であろうと
思われます。
このため、ゲーム目的で Player を利用する場合、ゲストOSによって仮想マシンのバージョンを選択する必要が生まれました。
95 系 Windwos をゲストとしてゲームをプレイしたい場合、Player のバージョンは 6 を選択するしかありません。
また 95系 Windows のゲームを諦め、 win2k 以降に絞るなら Player 7 に移行すべきでしょう。

 

疑問点など

 VMware player は Ver 4 以降、 64 bit ソフトウェアしか存在しません。
ホストOSが Windows の場合、32 bit アプリと 64 bit アプリは明確に区別してインストールされます。
64 bit アプリなら C:\Program Files
32 bit アプリなら C:\Program Files (x86)

 VMare Player は 64 bit アプリであるにも関わらず、デフォルトでは Program Files (x86) にインストールされてしまいます。
Ver 3 までの Player では 32 bit 版も存在しますが、64 bit 版のみになったにも関わらず Program Files (x86) です。
恐らくですが、最初にインストーラを作った段階で誤りに気付かず、誤りのまま踏襲されている気がします。
もちろんインストール先の変更は可能ですが、64 bit 版しか存在しなくなった段階で訂正しておくのが本来だと思います。

 もう一つ…
製品とドキュメントに矛盾が多い事も気になります。
ドキュメントや警告には「32 bit ゲストの最大メモリーは 8 GB に制限され、それ以上だと起動できない。」とされていますが、
実際には 64 GB 与えても起動可能なのです。
その理由は 32 bit OS であってもサーバー用途のOSが存在し、32 bit OS であっても 4 BG を超えるメモリーが利用可能である事を
保証するためです。

 最近の仮想環境は用途をビジネスに絞った発展をしているようで民生機器としては軽視している気がします。
私など、普及の面からは特定企業用途よりも民生品としての普及を心掛けるべきと思っています。
「なぜ?」という点に付きましては誰でも気づく事なのですが、なぜ そうならないのでしょう?

 

 

最後に

 このサイトは VirtualBox 情報専門サイトであり、VMware の情報は本来的ではありません。
ですが「比較」という意味でなら、このような情報もアリだと思います。
では、なぜ比較を行ったのでしょう?
それは両者の特徴を知り、適切に仮想環境を運用して欲しいからです。
例えば VirtualBox ではスナップショットが常識的に可能ですが VMware では有料の Workstation でしか利用できません。
これは Player は VirtualBox と比べて管理機能が貧弱だという話ですが、この情報からも用途に対する適性が分かります。
 それぞれに特徴があり、最も目的に沿った仮想マシンを利用するのがベストな訳です。
一応 一覧表にはしてみましたが、表は簡潔であっても理解の助けになるとは言えません。
ここまでのテキストは その詳細部分ですが、私の確認した部分と憶測が混在しています。
過信は禁物ですが参考になればと公開します。

 

 

 Aqualight です。
編集後記と言いますか、何と言いますか…

 これ、業界人や内部が想像可能な方々にとっては肝心な部分は冒頭の比較表だけで十分す。
実際、表以降は重複も多く説明が回りくどいのですが言い訳をさせて頂きます。

 そもそもなのですが、このテキストを公開すると予告したしたのは以下の投稿内です。

ゲストOSと PAE/NX

VirtualBox 5 も VMware も 新OS である Windows 10 への対応を勤(いそ)しんでいた頃です。
両者の比較を行い「現状はどうなのか?」という情報は仮想マシン・ユーザーとしては興味深いものです。

 という訳で原稿を書き始めたのが、一覧表以降の部分なのです。
書き終わってから「文章としてダラダラ書くよりは一覧表の方が…」と気付き、それ以前に書いた部分を
説明文として添付したのが現状です。

 一覧表以降の説明や解説は、単なる雑談としてご理解頂ければという言い訳です。
重要なのは一覧表であって、それ以降は どちら様も「駄文」として扱って頂ければと思います。

 

コメントを追加

Filtered HTML

  • ウェブページアドレスとメールアドレスは、自動的にハイパーリンクに変換されます。
  • 使用できるHTMLタグ: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <br />
  • 行と段落は自動的に折り返されます。

Plain text

  • HTMLタグは利用できません。
  • ウェブページアドレスとメールアドレスは、自動的にハイパーリンクに変換されます。
  • 行と段落は自動的に折り返されます。
CAPTCHA
スパム投稿防止の為以下のテキストを入力してください
Image CAPTCHA
Enter the characters shown in the image.