■ 第280回 ■ すべての問題はLonghornへと繋がる

　それはたとえば、Windows以外の自社製品の方向にさえ影響を与えているほどだ。最も大きな影響を受けたのは、おそらくOfficeだろう。次期Officeは当初、セキュリティを最重視してマネージドコード(.NETフレームワークで使われる中間バイナリ)で書かれ、LonghornでサポートされるWinFSをフルに活用して大幅に機能を強化したものになる、という触れ込みだった。しかしLonghornでのWinFSのサポートがなくなり、スケジュールも後ろへとスリップした今、次期Officeは全く別の方向での付加価値向上を目指しているようだ(ちなみにMicrosoftはこれまで、Officeの開発スケジュールをスリップさせたことはない)。

　だがLonghornのスケジュールは、Intelの戦略にまで大きな影響を与えている。先日、サンフランシスコで開催されたIDF Spring 2005では、パット・ゲルシンガー氏の基調講演にMicrosoft上席副社長のジム・オルチン氏がゲストとして招かれ、両社が協力しながら業界を盛り上げていく姿勢を見せた。

　しかしIntelは、少なくとも2006年というLonghornの出荷予定を信じてはいないようだ。

●32bitプロセッサでのVTは機能限定版?

　Intelはこれまで、“T's”と称してプロセッサに関連するさまざまな周辺技術を発表してきた。しかし最も発表が早かったLaGrande Technology(LT)は、いまだに実現されていない。機能としては実装されているが、その機能を使いこなすソフトウェアがないためだ。

　昨年、秋のIDFの段階で、Intel社長兼COOのポール・オッテリーニ氏は、LTはVanderpool Technology(VT。現在はIntel Virtualization Technologyと名を変えた)共々、Longhornから利用可能になると話していた。

　ところが、今回のIDFでは「VTの一部分」を、先行してLonghorn前に投入するという。もちろん、その背景にはVTのような仮想マシン技術が、今年大々的に進めるデュアルコアプロセッサの魅力をアピールする上で重要という側面はある。しかし、それにしては少々、急場しのぎの印象が強すぎる。

　LTの場合、システム全体のセキュリティアーキテクチャに関わる部分のため、先行して対応することは難しいがVTの場合ならば対処できないことはない。Microsoftの予定に付き合うのではなく、できるところは自らが動こう。おそらく、Intelはそう考えたのではないだろうか。IntelはLTに関しては基調講演の中でも「2006年にLonghornと一緒に出てくる」と一言話しただけで、スライドもほんの少しだけ表示しただけだった。2006年中に、新しい技術を立ち上げる事は不可能。そう判断して「VTの一部分」を切り出す事にしたのだろう。

　では何が本来のVTと異なるのか?

　その違いは仮想マシンマネージャ(VMM)が動作する場所だ。本来、VTではVMMがOSよりも高い特権モードで動作し、すべてのOSが仮想マシンの中で動く。このため、通常のVMMアプリケーション(VMwareやVirtual PC)のように、ホストOS、ゲストOSといった区別もない。しかし、今回発表された「VTの一部分」は、VMMをホストOSから起動する仕組みになっている。

●機能限定版VTのパフォーマンス

　なぜLonghornでなければVTを完全に実現できないか。その理由はブートアップのシーケンスにある。VMMをOSが動作する特権モードよりも上の特権モードで動作させるためには、OSがまだロードされていないブートアップシーケンスの中で、直接VMMを起動する仕組みが必要になる。

　そのためには、32bitモードで動作し、すべてのハードウェアに対してのアクセスも可能にするEFIが必須だ。実際、最初からEFIによるブートアップで設計されているItanium 2のプラットフォームではVTの導入に何ら障害はない。実際、IDFの展示会でもMontecito向けにはVTのデモが順調に動作しており、ほぼ製品に近いレベルの仕上がりであることを感じさせた。しかし32bit環境でEFIをサポートするには、まずOS側がEFIに対応しなければならない。Windowsの場合、それがLonghornのタイミングとなる。

　そこでIntelは方針を転換し、ホストOS上で動作するVMMでVT向けに拡張した命令セット「VMX」をVMMベンダーに使ってもらうことで、現行のWindowsユーザーでもVMXを活用可能にしたのが今回の発表だ。VMXに対応予定の32bitのVMMソフトは、VMware、Virtual PC、Xenの名が上がっている。

　IDF展示会場でこれらのベンダーに話を聞いてみたところ、VMXによって次の点が改善できるという。

・従来は完全に仮想化できず、OSに対する動的なパッチで対処していた部分を仮想化可能になりパッチが不要に。結果、PC向けのあらゆるOSを動作させることが可能に

・ソフトウェアでエミュレートしていたハードウェアイベント処理の大部分をハードウェアで処理(ただしI/O処理を除く)

　これだけでも、かなりのパフォーマンス向上を図ることが可能だ。IntelはVT使用時と未使用時のハードウェアイベントのエミュレーション回数を公表しているが、I/Oイベント以外、特に割り込み処理が劇的に減少している事がわかる。

　I/O処理が減少しないのは、ディスクやグラフィックスなどのハードウェアが、仮想化されることを前提に設計されていないためだ。IDFではハードウェアの開発者に「グラフィックスもディスクも、あらゆるハードウェアを仮想化していこう」と呼びかけた。

　I/Oイベント以外の仮想にハードウェアで対応することで、どこまでパフォーマンスアップが図れるのか? 実はホストOS上で動作するVMMソフトのベンダーも、まだデモ版さえも完成させていない段階で予想はしにくいようだ。しかし、VMMソフトウェアでOSを動かした時特有の反応の鈍さは無くなり、デュアルコアによるパフォーマンスゲインも含め、ゲームなどを行なわない限り仮想マシンであることを意識させないレベルにはなると、VMwareの担当者は話す。

VT使用時のパフォーマンス

●VTの将来像

　これに対してEFI起動が前提のMontecitoでは、ホストOSを必要としない真のVTで既に動作している。Itanium 2版のVMMを開発した日立製作所によると、マシン上で処理可能な同時スレッドを、仮想マシンに対してそれぞれ任意の数を割り当てることも可能だという。

　つまり、CPUを仮想化し計算機としてのリソースを仮想マシンに完全に再割り当てできているわけだ。実力面でも大量のI/O処理が各VMで同時に集中するような事がない限り、仮想マシンであることすら意識しないだろうと話す。リリースの次期もMontecitoと同時のアナウンスとなる見込み。

　Intelによると、将来的にはハードウェアベンダーが、それぞれのハードウェアを仮想化することで、I/O処理イベントのソフトウェアによるエミュレートが不要となりパフォーマンスが上がるのはもちろん、VTが実現する仮想化機能の範囲も大きく変わっていくだろうと話している。

　たとえば3Dグラフィック処理の場合、グラフィックの処理パイプラインを仮想マシンごとに任意数を割り当てたり、処理内容に応じてVMMが動的に割り当てるリソースを変化させたりといった事が可能になる。同様の処理をネットワークの帯域やファイルI/Oに対して行なうこともできるだろう。

　しかし、そのためには早期にVTが“本来の姿”にならなければならない。Itanium 2の世界では、すでにそれが始まっているが、我々エンドユーザーが使うPCの場合、まずはLonghornの出荷を待ち、EFI起動のPC(あるいはマザーボード)へと買い換えた段階でやっと入り口に立てる。さらにプロセッサ以外のハードウェアを仮想化するまでを考えると、まだまだ先は長い。

　以前、この連載でIntelのウィリアム・スー氏に話を伺った時、同氏は「当初提供されるのはVT1。本来のI/O周りまでのパフォーマンスを引き出せる第2世代のVT2はその数年後になる」と話していた。しかしまだ、我々はVT0.5の世界へとやっと入ろうとしている段階なのだ。

●“Longhorn待ち”が生む弊害

　Longhorn待ちによる弊害は、VTやLT以外にもたくさんある。

　たとえば、ピクセルが視認できなくなるほどの高解像度が可能になってきている液晶パネルに対して、適度な内部処理解像度でスケーラブルに表示を行ないつつ、従来のアプリケーションとの互換性も取れるように表示を行なうためには、グラフィック表示のAPIが変化しなければならない。

　たとえばさまざまな異なるカラーフォーマットの画像を、ユーザーが意識することなく表示できるようになるには、やはりAPIの変化が必要。現行のGDI+は、複数のディスプレイや、異なるプリンタ用紙ごとの色の違いに対して異なる特性を割り当てることすらできない。マルチディスプレイで違う機種を並べて使うと、その違和感に気付くだろう。これらは周辺ハードウェアとも密接に関連する部分であり、Intelだけでなく多くのハードウェアベンダーが“Longhorn待ち”で、製品計画の変更を迫られている。

　無論、Microsoftにも言い分はある。LonghornはWin16に作られたAPIの基本アーキテクチャを見直す最大のチャンスだ。ここで妥協をしては、後々の発展が阻害される可能性もある。だからリリース時期よりも機能の実装が重要なのだと説明してきた。

　しかし、Longhornの最初のバージョンからストレージシステムのWinFSが削られるなど、これ以上のスケジュールの遅れが業界全体に及ぼす影響について考え始めているようだ。リリースへのプレッシャーが高まるにつれ、現実的なアプローチへと寄ってきたとも言える。彼らがどこまで“妥協”するのかは、今年の4月にあるWinHECである程度、明らかになってくるだろう。MicrosoftはWinHECにおいて、WinFSなど機能縮小を行なった開発者向けのビルド(一部にはβ版の配布という話もあるが、現実的にはWinHEC専用のスナップショットビルドと予想するのが妥当だろう)を配布する。

　だが、Longhornが機能縮小を伴う早期開発に動けば、それで話が解決するという問題でもない。WinFSをベースにしたソフトウェアを計画していたベンダーは、その計画を再検討しなければならない。また、この先を考えたときに、果たしてこれまでのWindowsのように、何でもかんでもを取り込んで統合化していく開発の方向性が正しいのか、という議論もわき上がってきて当然だろう。

　Windowsの進化が立ち止まっていた期間、PCのシステムパフォーマンスは大幅に向上した。MicrosoftはWindows NT 3.1/3.5/3.51時代のマイクロカーネル思想に立ち戻り、サブシステムごとに別々に機能モジュールを提供するなど、近年のWindows開発とは異なるアプローチについて、可能性を考えるべきではないだろうか。

　Windowsの価値が、そのサブシステムが提供する機能(とそこにアクセスするためのAPI)にあるのだとすれば、カーネルを完全に分離して、少々立て付けの悪くなったOSの核に大幅な手を加えてもいいハズなのだが。

□関連記事
【2004年8月28日】次世代Windows「Longhorn」は2006年発売へ
http://pc.watch.impress.co.jp/docs/2004/0828/ms.htm
【2004年5月9日】【本田】WinHEC配布版Longhorn インストールレポート
http://pc.watch.impress.co.jp/docs/2004/0509/mobile241.htm
【2003年11月13日】【本田】Longhornへの期待と懸念
http://pc.watch.impress.co.jp/docs/2003/1113/mobile219.htm
【2003年10月1日】【本田】Vanderpool Technology、最初の対応プロセッサは1～2年内
http://pc.watch.impress.co.jp/docs/2003/1001/mobile216.htm

□バックナンバー

(2005年3月10日)

[Text by 本田雅一]