Ottawa Linux Symposium 3日目リポート（2/5 ページ）

[David-，japan.linux.com]

　仮想化したカーネルは2種類の時間を理解する必要があるが、通常のカーネルは1種類の時間だけを理解していればよい、とプラット氏は指摘した。

　仮想マシン内にない通常のカーネルは、システム上のすべてのハードウェアにいつでもフルアクセスできる。このカーネルが認識している時間は、実際の時間と同じである。カーネル時間が1秒進む間に、壁にかかっている時計も1秒進むことになる。しかし、カーネルが仮想化されている場合には、同じコンピュータ上にある他のすべてのカーネルとハードウェアを共有しているため、カーネル時間が1秒進む間に、実際の時間は数秒進んでいる可能性がある。したがって、仮想化したカーネルは、実際の壁掛け時計の時間と仮想的なプロセッサ時間（ハードウェアに実際にアクセスする時間）の両方を認識していなければならない。

　Xen 3.0の機能には、X86_64システムとSMPシステムのサポートが含まれている。Xenで近々実現されると期待されているのは、ゲストカーネルがシステムごとに最大32の仮想CPUを（実際のCPU数がそれほどなくても）使用でき、それらの仮想CPUを実行中に追加および削除できるという機能である。これは、ホットスワッピングをまったく新しい仮想化レベルへと進化させるものだ。

　メモリリングについてはよく理解できなかったが（おそらく誰かが詳しく説明してくれるだろう）、プラット氏は、32ビットx86環境と64ビットx86環境でのXenの動作の違いをメモリリングというコンテキストにおいて説明してくれた。32ビットx86環境では、Xenはリング0で動作し、ゲストカーネルはリング1で動作し、仮想マシンに提供されるユーザー領域はリング3で動作する。64ビットx86環境では、Xenはリング0で動作し、仮想マシンのユーザー領域はリング3で動作するが、64ビット環境の場合はゲストカーネルもリング3で動作する。これは、32ビット増えたことでメモリアドレス空間が大きくなったからだ。8Tバイトのメモリアドレス領域が利用可能であるため、Xenは大きく離れたアドレスを使用し、別の大きなメモリブロックを割り当てることができる（32ビットモデルはメモリアドレス空間がもっと制限されていた）。

　XenのSMPサポートの目的は、Xenの堅牢性と安全性を高めることだ。しかし、SMPのスケジューリングは難しい処理である。ギャング・スケジューリング（プラット氏によると、複数のジョブを複数のCPUに同時に送信すること）ではCPUサイクルを無駄に消費することになるので、効率を保つためにはプロセスを動的に管理する必要がある。

　同氏によると、Xenのメモリ管理は他の仮想化システムとは異なるそうだ。Xenは仮想マシン内のカーネルとユーザー領域にページテーブルを割り当てるが、いったん割り当てた後は制御を行わない。しかし、カーネル領域メモリとユーザー領域メモリとのやり取りに関しては、Xenサーバを通じて要求を作成しなければならない。仮想マシンは自身の割り当てメモリ内に制限されており、自身のメモリ領域を離れることができない。唯一の例外は、仮想マシン間の特殊な制御された共有メモリ環境である。

　Xenの開発チームは、目下、Xen環境でオリジナルのカーネルを無修正で実行できるようにすることを目指して作業中だ。これにより、仮想マシン内にあることを意識せずに、レガシーのLinuxカーネルやWindowsなどのOSをXen上で実行可能になる予定だ。しかしそれが実現するまでは、Xenは障害を発生させる可能性があるゲストカーネルからのすべてのシステムコールをインターセプトし、まるでXenが存在していないかのように処理しなければならない。

　プラット氏はここでロードバランスの話に戻り、仮想マシンをXenクラスタ内のあるホストから別のホストに引き渡すプロセスについて説明した。

　クラスタの2つのノードが同じ正常なネットワーク上にあり、理想的な環境で、1GBのメモリイメージが相手側のホストに転送されて再開可能な状態になるまでに8秒かかるとしよう。ダウン時間がこのくらい長いとミッション・クリティカルなサービスやユーザーに気付かれてしまうので、より良いソリューションを目指すならば、実行中の仮想マシンを一方のノードから他方のノードに転送できるようなシステムを構築しなければならない。

　1つのソリューションでは、まず、移動対象のプロセスで使用されているリソースの10％を使用して、そのプロセスを宛先ノードに転送する。これならば、当面の間はパフォーマンスに大きな影響はない。次に、仮想マシンが動作しているメモリブロック全体を宛先ノードに繰り返し転送する。1回1回の転送では、前回の転送後に変更されたメモリ内の要素だけを送信する。すべての変更を転送するわけではないので、各サイクルが短時間で済み、変更箇所も少なくなる。最終的には、仮想マシン（終了しようとする仮想マシン）の移行元ホストと移行後ホストのメモリにはほとんど違いがなくなるので、メモリ内の最新の変更内をコピーすれば、その仮想マシンを新しい位置で再開できるようになる。プラット氏が示した統計では、多忙なWebサーバの場合でも、準備段階としてメモリをコピーするのに約1分半かかった後は、約165ミリ秒の合計ダウン時間で済むということだ。

　Quake 3サーバを実行しており、大学院生らがゲームをプレーしている最中の仮想マシンを移行してみたところ、この移行に伴うダウン時間は40〜50ミリ秒であり、大学院生らは移行が行われたことに気付きもしなかった。

　プラット氏はXen 3.1に向けたロードマップとして、パフォーマンスの向上、制御ツールの改良、チューニングと最適化の改良、稼動させるまでの手動構成の減少という点を挙げた。加えて、Xenには活発な開発者コミュニティーと強力なベンダー・サポートがあり、それが同プロジェクトの開発に大いに役立っていると語った。

　Xenプロジェクトについてはxen.sf.netまたはxensource.comを参照。プラット氏によると、Xenはケンブリッジ（イギリス）、パロアルト（カリフォルニア）、ニューヨークで採用されているそうだ。