お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

1日5分のXen理解: 第2回仮想マシンモニタXenの特徴

高橋　浩和, VA Linux Systems Japan, ITmedia

概要： ここでは、仮想マシンモニタ「Xen」を取り上げ、その特徴を見ていくことにしましょう。

タグを付ける!

日付: 2007年 5月 18日
レベル: 初級
アクティビティー： 2798 ビュー
お気軽にご意見・ご感想をお寄せください：

仮想マシンモニタXenの特徴

先日リリースされた最新版のXen 3.0を取り上げ、その特徴を見ていくことにしましょう。Xenは複数の仮想マシン環境を作り、それらをスケジューリングします。Xenでは、仮想マシン環境一つ一つをドメインと呼んでいます。

準仮想化（paravirtualization）

Xenはハードウェアの準仮想化という実装手法を標準採用しています。実在のハードウェアを完全にエミュレートする代わりに、仮想マシン環境を実現するのに都合の良い仮想的なハードウェアを再定義するのです。この仮想ハードウェアは、実在のハードウェアに良く似ていますが、操作をするためにはハイパーバイザコール*を呼び出す必要があります。Xenはこのハイパーバイザコールの要求に応じて、仮想マシン環境に変更を加えます。

この準仮想化という手法は、Xenの上で動作させるゲストOSに手を加えることを要求します。つまり、ゲストOSをXen仮想ハードウェア上に移植しなければなりません。この方法はあらゆるOSに適用できるわけではないためデメリットといえます。しかし、大きなメリットもあります。エミュレーションのオーバーヘッドを最小限に抑えることができるため、性能面で大きなアドバンテージを得られるのです。

ハードウェアを完全にエミュレートするには、OSからハードウェアやCPUに対し発行された要求を分析し、本来やりたかったことを推測し、実際の処理を実行する必要があります。一方、準仮想化の環境では、ゲストOSはXenに対して本来やりたいことを直接要求できるため、処理を単純化できます。

完全仮想化（full virtualization）

Xenはハードウェアの完全仮想化機能も提供しています。この機能を利用すると、実ハードウェア用に用意されたOSをそのままXen上で動作させることが可能となります。ただし、完全仮想化機能を利用するためには、VT対応のIntelCPU上でXenを動かす必要があります*。

この完全仮想化機能が提供する仮想マシン環境内のOSは、自分では特権モードで動作しており完全に物理ハードウェアを支配していると思っています。しかし、実際には特殊なモード*の中で、OSは動作させられています（図3）。

図3　準仮想化と完全仮想化

OSが仮想ハードウェアを制御する命令を実行したとき、CPUはそれを検出し、例外のようなものが発生してXenに制御を渡します*。制御を渡されたXenは、OSが行おうとした処理を分析し、仮想ハードウェアの動作をエミュレートします。

完全仮想化の環境は、準仮想化方式に比べると、エミュレーションのためのコストが大きくなります。しかし、ソースコードに手を入れることのできないWindowsなどのOSも動かせることは、大きなメリットです。Part3では、VT対応CPUを塔載したマシンを利用して、実際に完全仮想化されたマシン環境でWindowsを動かす実験をお見せしたいと思います。

デバイスドライバのモデル

Xen自体は、デバイスドライバを持ちません。Xenの上で複数のドメインが動作しますが、そのうちの1つに特別な役目を担わせ、そのドメインをドメイン0と呼びます（図4）。

図4　Xenのモデル

Xen 3.0.0では、ドメイン0で動かすことのできるOSはLinux 2.6カーネルだけです*。Xenの仕組みでは、物理デバイス制御とXenのマネジメント機能を、このドメイン0上のLinuxカーネルに任せています*。

これは非常にうまい実装方針です。Xen本体の構造を単純化することに加え、新しい各種デバイスへの追従はLinuxカーネルに任せておけば良いからです*。

つまり、Linuxが動作するハードウェアなら、どこでもXenを動作させることができます*。現在のx86版Solarisは動作するハードウェアが非常に限られていますが、Xen上のドメインUとしてSolarisが動作すれば、ほとんどすべてのPCサーバでSolarisを利用できることを意味します。

参考までに、VMware ESX ServerもXenと同じ仮想マシンモニタ構成を取っています。ただし、Xenとは違ってすべてのデバイスドライバをVMwareの配下で管理しています。ゲストOSからのI/O処理依頼は、すべてVMwareが代行処理することになるため、利用時には、VMware ESX Serverがサポートするハードウェアであるか否かに注意を払う必要があるでしょう。

オープンソース

仮想マシンモニタXenはオープンソースとして開発されています。これも非常に大きな特徴です。開発を進めるために、Linuxカーネルのコードや、CPUエミュレータQEMUのコードなど、ライセンスがGPLであるオープンソースソフトウェアの成果もどんどん流用しています。ケンブリッジ大学のIanPrattがプロジェクトリーダーを務めており、開発は非常に活発で、参加したい人はどなたでも参加可能です。

こちらのURLにはさまざまな情報が置かれています。Xenのソースコードおよびバイナリコード、各種ドキュメント、FAQが入手可能で、メーリングリストへの参加方法も記されています。

準仮想化技術というオーバーヘッドの少ない仮想化技術が可能となった背景として、オープンソースの普及は大きな要因になっています。準仮想化技術を導入するには、その上で動作させるOSのソースコードを入手し、変更する必要があるからです。オープンソースOSであるLinuxや、BSD系UNIXとXenの登場の間には、切っても切れない関係があるといえるでしょう。XenとオープンソースOSは、今後も互いに影響を与え合いながら、成長していくと思われます。

それ以外の特徴

Xenが提供する仮想マシン環境はマルチプロセッサに対応しているので、仮想マシン環境（ドメイン）の中で、マルチプロセッサ対応のOSを動かすことができます。現在IA-32用Xenでは32CPUまで対応しています。また、各仮想マシン環境（ドメイン）に対する資源割り当て量を動的に変更できます（現在は、CPU時間とメモリ量のみ制御できる）。

このほか、物理マシンの間で仮想マシン環境（ドメイン）を移動できます。ドメイン内で動作しているOSは、移動したことにほとんど気がつかないでしょう。この機能を利用すると、物理マシン間にまたがった負荷分散や、OSを無停止のまま物理マシンを交換したりすることが可能となります。

上に戻る

このページで出てきた専門用語

ハイパーバイザコール: hypervisor call。プロセスがLinuxに要求を出すときに呼び出すシステムコールのようなものです。
VT対応のIntel CPU上でXenを動かす必要があります: Xen 3.0では、マイナーバージョンアップでAMDのSVM（Secure Virtual Machine）にも対応する予定。これは、開発コードPacificaで知られていた機能で、これによって、AMDCPU上でも完全仮想化機能を利用できるようになります。
特殊なモード: x86では、VMXオペレーションモードと呼ばれるリングプロテクションと直交する新しいCPUモードが導入されました。リング0（特権モード）であっても、VMXnon-rootオペレーションモードでは、特権命令の利用などに制限が加わります。
Xenに制御を渡します: Xenは、VMX rootオペレーションモードで動作します。特権命令の利用などに制限はありません。
ドメイン0で動かすことのできるOSはLinux 2.6カーネルだけです: 原理的には、ドメイン0を、Linuxカーネル以外のOSと交換することも可能です。実際、Xen 2.0では、BSD系のOSをドメイン0として動作させた実績があります。
ドメイン0上のLinuxカーネルに任せています: 特権的な処理を一手に引き受けるため、特権ドメインと呼ぶこともあります。
各種デバイスへの追従はLinuxカーネルに任せておけば良いからです: もちろん、NetBSDのカーネルでも良い。
どこでもXenを動作させることができます: Xen 3.0では、IA-32/EM64T/AMD64アーキテクチャーのCPUが搭載されたハードウェアに限られているが、現在ほかのCPUへも移植が進んでいます。