Xenのモデルと構造：仮想マシンモニタ Xen 3.0解読室

複数の仮想マシン環境を作り上げ制御するために、仮想マシンモニタであるXenが具体的に何をやっているのか、興味がある方に向け、Xenの設計思想と実装について連載で解説していく。

[高橋浩和（VA Linux Systems Japan），ITmedia]

「仮想マシンとは何か？」で、わたしは「Xenは仮想マシンモニタである」と断言しました。複数の仮想マシン環境を作り上げ制御するために、仮想マシンモニタであるXenが具体的に何をやっているのか、興味を持たれた方も多いと思います。今回からは、そのXenの設計思想と実装について解説していきます。

Xenはどんな動きをしているのだろう？

　現在読者の皆さんは、「Xenは仮想マシンモニタであり、複数のOSを制御するプログラムだ」という漠然としたイメージを持たれていると思います。このイメージを、もう少し、ハッキリと感じられるようにしたいと思います。

　そのためにはまず、この仮想マシンモニタというプログラムと、普通のOSとを比較してみましょう。

• OS：アプリケーションからハードウェアを隠蔽するものとして生まれた。マルチタスクをサポートするようになり、複数のアプリケーションプログラムをOS上で同時に実行できるようになった*。アプリケーションは、タスクやプロセスという環境を与えられ、その中で動作する（図1）

図1　OSとタスク

• 仮想マシンモニタ：OSからハードウェアを隠蔽するものとして生まれた。複数のOSを、仮想マシンモニタの上で同時に実行できる。OSは仮想マシンモニタから与えられた仮想マシン環境の中で動作する（図2）

図2　仮想マシンモニタとOS

　何か気づかれませんか？　そう、前者のOSとアプリケーションプログラムの関係が、後者では仮想マシンモニタとOSの関係に入れ替わっているだけということが見えてきます。そうです、仮想マシンモニタも一種の小さなOSなのです。

　仮想マシンモニタは、OSに対してCPU時間やメモリなどの資源を割り当てます。一方、OSはその上で動作しているアプリケーションプログラムに対して資源を割り当てます。実は、これら2つの目的は同じものです。「仮想マシンモニタはゲストOSをスケジューリングするOS」と考えておけば良いと思います。

　これからXenの設計思想や実装を理解していくとき、Linuxカーネルなど、ほかのOSの実装の知識が非常に役に立ちます。書籍「Linux 2.6カーネル解読室」のうち、前半の記事は特に役立つと思います。ただしXenが管理する資源は、Linuxが管理しなければならない資源と比べてはるかに小さなものとなります。

Xenのモデル

　Xenは、実ハードウェアを隠蔽し、その上に複数の仮想マシン環境（仮想的なハードウェア環境）を作り出します。この仮想マシン環境を、Xenではドメインと呼んでいます。OSは、ドメイン内で動作することになります。Linuxはプログラムを実行するための器（うつわ）としてプロセス*を作り、その中でプログラムを実行します。Xenのドメインは、LinuxやUNIXでいえばプロセスに相当します。

　Xenの大きな特徴は、2つあります。1つは仮想マシン環境構築に、準仮想化（paravirtualization）という手法を採用していることです。もう1つの特徴は、Xen自体がデバイスドライバを持たない点です。

準仮想化ドメイン

　各ドメインは、実在のハードウェアを完全にエミュレートするのではなく、エミュレートに適した新しい仮想的なハードウェアを定義しています。このハードウェアは実在のハードウェアに良く似ていますが、ハードウェアの制御を行うためには、ハイパーバイザコールを利用するという約束になっています。

　実ハードウェア上で動作するOSは、特権命令を利用してハードウェアを制御します。一方、Xenの上で動作するゲストOSは、ハイパーバイザコールでXenに仮想的なハードウェアの制御を依頼します。これは、プロセスがLinuxやUNIXに対して発行するシステムコール*と良く似ているといえるでしょう。プロセスは、システムコールを通じてプロセスという抽象的な環境を制御しますが、Xen上のドメインは、ハイパーバイザコールを用いて仮想的なハードウェア環境を制御します。

　また、逆にハードウェアからOSへのイベント（事象）通知方式も変更されています。実ハードウェア上で動作するOSは、割り込み*を利用して、ハードウェアからの事象を受け取りますが、Xenでは割り込みも仮想化して、ドメイン上のゲストOSに通知します。この方法は、ちょうどLinuxやUNIXにおけるシグナル*の仕組みに良く似ていて、Xenではさらに、この割り込み通知方式を汎用化した「イベントチャネル」という仕組みも用意しています（図3）。

図3　Xenの構造

I/Oデバイス管理

　仮想マシンモニタは、CPUだけでなくI/Oデバイスも仮想化する必要があります。Xenの仕組みでは、I/Oデバイスの仮想化に当たって、実在のデバイスではなく、Xen環境専用の仮想的なデバイスを定義しています。ドメイン上のゲストOSは、この仮想デバイスに対してI/Oアクセス要求を行います。この要求は、実デバイスへのI/Oアクセス要求に変換しなければなりません。

　ところがXenは、自分自身では実デバイスを管理しておらず、ドメイン0と呼ばれる特別なドメインに実デバイスの制御を任せています*。ゲストOSが仮想デバイスにI/Oアクセスを要求すると、そのままドメイン0に転送し、ドメイン0が代わりに実デバイスを操作するという仕組みになっています*。これは、非常に特徴のあるI/Oデバイス管理方式といえるでしょう。

完全仮想化

　Xenは、標準で準仮想化されたドメインを提供しますが、Xen 3.0からは完全仮想化されたドメインも提供するようになりました。完全仮想化ドメインでは、実在のハードウェアを完全にエミュレートします。完全仮想化ドメイン上で動作しているゲストOSは、自分自身が実ハードウェアで動作していると思い込んでいます。XenはゲストOSのハードウェアの操作を捕捉し、これをエミュレートします。捕捉後にXenが行う仕事は、準仮想化ドメインに対するものとほぼ同じです（図4）。

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

　x86 CPUは、仮想マシン環境を提供できるよう、VTと呼ばれる機能のサポートを2005年11月に追加しました。Xenの完全仮想化ドメインは、このVT機能を利用して実現しています。この機能を利用すると、ゲストOSには特権モードで動作させていると見せつつ、特権的な操作をCPUで捕捉して、Xenに制御を渡すことが可能となります。

　ゲストOSは、VTによって提供されるVMX non-rootオペレーションモードで動作させ、XenはVMX rootオペレーションモードで動作させます。VMX non-rootオペレーションモードでは、リング0で動作していたとしても、利用できる特権処理に制限がかかります。VMX non-rootオペレーションモード内で特権処理を行うと、VM exitと呼ばれる状態遷移が起こり（例外のようなものです）、VMX rootオペレーションモードで動作するXenに切り替わります。

　またI/Oデバイス操作のエミュレートは、ioemuという機能で実現しています。これは、ゲストOSが発行するI/O命令を解析し、仮想デバイスへの要求に組み直すというもので、QEMU*のコードを利用して実現しています。

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

OS上で同時に実行できるようになった

もちろん、組み込み機器用のハードウェアを隠蔽しないOSや、MS-DOSのようにマルチタスクをサポートしないOSなども存在する。

プロセス

書籍「Linux 2.6カーネル解読室」の「Part2 プロセス管理」参照。

システムコール

書籍「Linux 2.6カーネル解読室」の「Part1 カーネルプリミティブ」内「第5章 システムコール」参照。

割り込み

書籍「Linux 2.6カーネル解読室」の「Part1 カーネルプリミティブ」内「第2章 割り込み処理」参照。

シグナル

書籍「Linux 2.6カーネル解読室」の「Part2 プロセス管理」内「第7章 プロセス管理」（「7.5 プロセス狩猟後の処理」以降）、「第8章 シグナル処理」参照。

特別なドメインに実デバイスの制御を任せています

ドメイン0以外のドメインは、ドメインUと呼んで区別する。しかし、Xenから見た場合どちらも同じドメインに見える。

ドメイン0が代わりに実デバイスを操作するという仕組みになっています

Xen自体がデバイスドライバを持たないこの設計は、ハードウェアへの追従性を向上させる効果がある。ドメイン0として動作するゲストOSがサポートしているハードウェアであれば、どこでもXenの環境を動かせることになる。

QEMU

CPUエミュレータQEMUは、CPUのエミュレートだけでなく、PC/ATアーキテクチャーのデバイスのエミュレーション機能も持っている。このデバイスエミュレーション機能をXenに移植したもの。

本記事は、オープンソースマガジン2006年4月号「仮想マシンモニタ Xen 3.0解読室」連載第1回を再構成したものです。