ここ半年ほどの仮想化をめぐる状況の進展は著しい。米Intelと米AMDは仮想化を支援する命令をプロセッサに追加し，VMwareなどの仮想化ソフトも対応を進めている。米MicrosoftはLonghorn ServerでOS自体に仮想化機能を組み込む予定という。「技術的には優れているが，パフォーマンスが低下するなどの理由で主流にはならないだろう」と考えていた記者としては，見る目がなかったと反省しきりである。と同時に，10年近く前にも似たような状況があったことを思い出した。Javaがサーバーサイドでメインストリームへと躍り出たときである。
1995年に登場した当時のJavaは，ネットワークからダウンロードしたプログラムがクライアント上でそのまま動くことを売りにしていた。Java仮想マシンをはじめとする実行環境がプロセッサやOSの違いを吸収することで，クライアントへの依存性をなくそうとしたのである。だが，ネイティブ・アプリケーションに対するパフォーマンスの低下やOSに対する細かい依存性などのためにクライアント・アプリケーション，特にグラフィックス描画が中心のアプリケーションがJavaに移行することはとても期待できなかった。実際，クライアント・アプリケーションでJavaベースのものは今なお少数派だ。
転機が訪れたのは，Javaアプリケーション・サーバーが各社から出荷され，Javaで構築したWebアプリケーションをサーバー上で動作させる環境が整いつつあった1998～1999年ころである。サーバーサイド・アプリケーションであれば，グラフィックス描画は関係がない。多少パフォーマンスが低下するにしても，J2EEの豊富なクラスが使える，OSやハードウエアに依存しない，開発生産性が高い，といったメリットがデメリットを上回る。結果，Webアプリケーションの多くがJavaで開発されるようになったのである。
仮想化ソフトの場合はどうだろうか。仮想化ソフトでは単純な演算速度が低下することはない。だが，グラフィックスやネットワークなどのデバイスへのアクセスについては遅くなったり，動かなかったりする可能性がある。
問題となるのは，デバイス・アクセスの中に状態に依存するものがあることだ。各デバイスの状態を管理するのはOSやデバイス・ドライバの責任だが，これらはすべて自分だけがアクセスしていることを前提に動作する。自分の知らない間に状態が変わってしまっては，正常に動作しないのである。つまり仮想化環境では，(1)仮想化ソフトがデバイスのエミュレーションを行う，(2)デバイス自体にOSごとに状態を覚えておくといった機能を実装する，(3)OS間でデバイスを共有するのをやめて，OSごとに別々のデバイスを用意する，のいずれかの対応が必要になる。
クライアントの場合，(1)は仮想化ソフトがすべてのコンシューマ・デバイスに対応してくれるとはとても期待できないし，(3)はコスト的に見合わない。PCI SIGが標準化を進めている(2)はパフォーマンス上のメリットが大きいが，実装されるのは当分先になる。Intelも，チップセット内蔵デバイスの対応時期は未定という。まして，すべてのコンシューマ・デバイスが対応する時期など，いつになるのか分からないといった感じだろう。
対してサーバーであれば，ディスクやネットワークなど一部のデバイスが対応すれば十分である。クライアントではコスト的に見合わない(3)も，サーバーであればペイする可能性がある。確かに，I/Oアクセスを集中的に行うアプリケーションなど，仮想化によるパフォーマンスの低下が容認できないこともあるかもしれない。だが，管理コストを削減できる，低コストで動的負荷分散が可能になる，といったメリットがデメリットを上回るケースは多いはずだ。
“仮想”という言葉にどことなく怪しげな感じを抱く人は少なからずいらっしゃると思う。しかし，仮想化はメインフレームで古くから使われてきた技術であり，その点では仮想メモリーと同じである。現在，パフォーマンスが低下するからといってスワップを禁止する人がほとんどいないように，数年後には仮想化も当たり前になっているかもしれない。
