Longhornを待たず仮想化技術導入を目指すIntel（1/2 ページ）

[本田雅一，ITmedia]

　Vanderpool Technology改めIntel Virtualization Technology（いずれにしろ頭文字はVTだが）は、今後のIntel製プロセッサ上で幅広くサポートされていく重要な技術だ。それはおそらく、デュアルコアを有効に活用する初期の応用例でもある。同様の技術はAMDも、Pacificaの名称で開発中であることも明らかになった。

VTがLonghorn登場前に一部利用可能に

　VTに関する詳細は、前回のIDFでも紹介したため、ここではごくごく簡単に触れる程度にしておきたい。

　VTはOSが動作するx86プロセッサでは最上位となる特権モード（Ring 0）のさらに上位の特権モード（Intelは仮に“Ring -1”と話している）を利用し、プロセッサ内に複数の仮想x86マシンを作ることができる。このとき、仮想マシンの管理を行うソフトウェアが「Virtual Machine Monitor（VMM）」だ。今回のIDFの資料にはRing -1というモードは登場しないが、ここでは話を単純化する上で、Ring -1という言葉を使わせていただく。

　IntelはRing -1を利用するアプリケーションを、かなり以前から検討していたようだ。VTよりも先に発表されていたセキュリティ技術の「LaGrande Technology（LT）」や先日発表された「Intel Active Management Technology（AMT）」も、同じRing -1を活用する技術である。

　IntelはRing -1構想を最初のPentium 4の時から温めていたようで、LT、VT、AMTといった技術が明らかになるずっと以前から機能としては入っていたようだ。ただし、各技術をサポートするプロセッサは（Intel側でRng -1のハードウェア的な実装とは関係なく、マーケティング的に）決められている。VTの場合、サポートされるのはすべてデュアルコアのプロセッサ以降である。

　なお、前回のIDFでVTについてレポートして以降、変化したことが2点ある。

　ひとつはSilvervale Technologyと言われたサーバ向けの仮想マシン技術名は、今回のIDFでは使われなくなり、すべてVTに名称が統一されたこと。もうひとつは、VTはLTとともにLonghornにてサポートされるとアナウンスされていたが、Longhorn前にも「Part of Technology（技術の一部）」を利用可能と言い始めたことだ。ではなぜ「一部」なのだろう？

本来のVTと今回のVT、何が違う？

　本来、VTはOSを立ち上げる前にVMMを起動し、そこから各仮想マシンを起動するものだった。しかし、ブートアップ時にVMMを起動するためには、システムの起動方法が「EFI（Extensible Firmware Interface）」へと移行していなければならない。EFIは本来、非x86システム向けのブートアップ手順として開発されたものだが、x86 PCでも互換性を維持したままEFIのメリットを享受できるEFI32が技術としては存在している。

　ところがEFI32でOSが起動するためには、OS自身がEFIをサポートしていなければならない。EFIでの起動を前提に作られているItanium向けのWindowsはEFIをサポートする。しかし、x86向けのOSでEFIをサポートしているのは一部のLinuxディストリビューションのみ。WindowsはLonghorn以降での対応ということになっている。

　このため、同じVTでもMontecitoでのVTのデモと、SmithfieldでのVTのデモは本質的に異なる。前者のシステムではEFIが使われるため、ホストOS、ゲストOSの区別が存在しないが、後者のデモでは必ずホストOSが起動されてからVMMをアプリケーションとして立ち上げ、その上でゲストOSを動作させる仕組みだ。

　IntelはVTの存在を明らかにして以降、クライアント向けのVTでは「Virtual PC」や「VMware」のような製品がVMMの役割をすると話してきた。従ってEFI上で切り替えられないから“VTの一部”と言っているわけではないだろう。これは推測だが、IntelはEFIでVMMをロードする手法と、ホストOS上でアプリケーションとして起動する手法、両方を同時にサポートしたかったのではないだろうか？

　というのも、EFIからロードされたVMMとホストOS上で起動されたVMMでは本質的なところでの違いがあるからだ。ホストOS上で実行されている仮想マシンは、ホストOSが落ちてしまえば消えて無くなってしまう。

　クライアントの場合でも、バックグラウンドでセキュリティパッチを当てたり、ネットワークを監視したりといった、普段使っているユーザーOSのパーティションを管理するエージェント仮想マシンを動かす、といった使い方を想定してみよう。エージェント仮想マシンがゲストOSのままでは、ホストOSがウイルスやワームなどで機能不全になった時、肝心のエージェント仮想マシンまで道連れになる可能性がある。

　バックグラウンドのサービスとして起動する仮想マシンはゲスト／ホストの区別なく起動されるべきで、ユーザーが明示的に仮想マシンとして使い分けをしたい場合は、アプリケーションとしてVMMを起動する、といった振る舞いの方がわかりやすい。