 |
 |
|
 |
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
|
|
|
|
|
|
|---|---|---|
| このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 | ||
Xen 関係の用語をまとめてみた。憶測や推測も交えており、本当に正しい解釈かどうかは分からないのであまり信用しないように。
「ハイパーバイザこそ Xen の本体であり、Xen とは Xen Hypervisor のことである」。Hypervisor はまた、VMM (Virtual Machine Monitor = 仮想マシンモニタ) とも呼ばれる。Xen Hypervisor は一個の OS であり、実は Linux とは全く別の Nemesis というオペレーティングシステムだ。
事象的にとらえると、Xen版 dom0 カーネルのブート設定に見る通り、Xenホスト実マシンのブート時には、まず Xen そのもののカーネルイメージ xen.gz が起動され、そいつが Nemesis の上で Xen版 dom0 カーネルを起動させる。この xen.gz が Hypervisor だ。ハイパーバイザはハードウェアと全ての仮想ドメイン (dom0 も含む) との間に横たわり、仮想ドメインからの割り込み要求 (IRQ) を受け取って実際のハードウェアと遣り取りをし、結果なりリソースなりを仮想ドメインに返す (このへんの解説や図解は Xen特集 - VA Linux Systems Japan にどんどん頼ってしまう)。準仮想化 (paravirtualization) では、仮想ドメインの OS のカーネルは Xen 用に改変されたもの (kernel-xen や kernel-domU) になっており、それら OS の発する割り込み要求はハイパーバイザコールというものに置き換えられている。ハードウェアを直接操作するのではなく、ハイパーバイザへの要請に置き換わっているわけだ。ただし、一部例外がある。それはバックエンドドライバおよびフロントエンドドライバというもので、バックエンドドライバを dom0 が持ち、その他の domU はフロントエンドドライバを介して dom0 の持つバックエンドドライバへ要求を投げる。そうしたものに、ネットワークデバイスやディスクデバイスがある。
概念的にとらえると、Xen はコンピュータサイエンスでいうリング (ring) という概念をアプリケーションの層で応用したもといえる。(ここからはかなりの付け焼き刃で、ほとんど Xen.org - XenInfo の受け売りだが勘弁していただきたい)。ring は権限の分離/階層化の理論で、保護モード (Protection Modes) あるいは権限モデル (Privilege Model) とも呼ばれ、よく、ダーツの的のような4重円で図式化される。ring-0 は最も大きな権限、つまり致命的なエラーをもたらし全機能を止めてしまうかもしれないような操作もでき、リング番号が大きくなるほど小さな権限しか与えられていない。外側のリングは、そのひとつ内側のリングの備える特別なゲートを通してしか内側にアクセスできない。そのため、例えば ring-2 が、致命的なエラーを起こすような操作を行ったとしても、ring-0, ring-1 は影響を被らずに動き続けることができる。ただしその時、ring-3 は道連れになって死ぬ可能性がある。
この ring 構造を最もローレベルで持っているのが CPU。その上で走る OS も ring を持っていて、カーネルが ring-0、アプリケーションが ring-3 にあたる。ring-1 と 2 は、一部の アーキテクチャや OS を除いて、長らく使われてこなかった (OS/2 では ring-1 や ring-2 が使用されているそうな)。
そして、そのさらに上層でこの構造を形成しているのが Xen だ。Xen では、ハイパーバイザが ring-0、仮想OS が ring-1、仮想OS上のアプリケーションが ring-3 に位置する。Xen の根底にあるこの概念をつかむと、幾つかの Xen 用語の意味合いが自ずと見えてくる。ring理論の ring-0 はスーパーバイザモード (Supervisor Mode)、階層 1以上のリングはユーザーモード (User Mode) とも呼ばれる (※)。つまり domU, domain-U の U は User Mode の U だ。一部ハードウェアの管理や他の domU の起動/停止の権限を持つ特別な仮想ドメインである dom0 は、監督者 (Supervisor) であり、或る意味 ring-0 だから 0 の名を冠する。仮想マシンモニタはスーパーバイザのさらに上を行くハイパーな権限を持つ存在だからハイパーバイザ -- というわけだ。
※ 例外もあって、PPC では ドメイン0 にあたるものもユーザアプリケーションもスーパーバイザモードで動いているそうな。
長くなったついでにもうひと下り、聞きかじりの情報を。Xen virtual Machine Monitor つまり Xen Hypervisor は、その先にある壮大な計画の一環に過ぎない。その計画を Xenoserver Project (ゼノサーバ・プロジェクト) という。"xeno" は foreign (外国、異世界の) とか stranger (他人) 的な意味を持つ接頭辞で、これを持った英単語に xenophobia (対人恐怖症、外国人恐怖症) がある。今日のインターネットでは、ネットワーク的/地理的に遠いサーバと遣り取りする際の遅延の問題がある (例えば顕著に表れるのがオンラインゲーム)。それならば、サーバを OS ごとクライアント近くのコンピュータ上に引き寄せられるようにしてしまえ、というのが Xenoserver の考え方らしい。リソースの移動先つまりゼノサーバとなるマシンは、仮想マシンマネージャ (VMM) つまり Xen Hypervisor を稼働させていれば、その Migrate (移住) 機能 (Relocation とも呼ぶ) を使って他サーバの OS の乗り移り先になれる。どこに最適なゼノサーバが空いているかやリソース貸し出しの課金情報などは、Xenocorp (ゼノコープ) という仕組みで実現しようとしている。面白いことに、ゼノコープ自体も、中央集権的なサービスでなく随所のゼノサーバ上を動的に移動できる分散サーバなのだという。Xen の名前の由来はもう言うまでもあるまい。
Xenoserver はケンブリッジ大学で研究されている。Xen もまたそこで誕生した。イアン・プラット上級講師 (Ian Pratt, senior lecturer) 率いる Xen 研究部門は XenSource Inc. という会社形式をとっていたが、2007年、Citrix社が買い取った。Citrix社は Xen Hypervisor を専用チップ内に搭載したアプライアンスを幾つか発売しているが、Xen は今もオープンソースであり、その諮問機関には IBM, Intel, HP, Novell, Red Hat, Sun Microsystems といった錚々たる IT企業が名を連ねている。
なお、Linux でない Nemesis という OS をハイパーバイザにしていることに対して、Linux の開発メンバの中には「Linux ベースのハイパーバイザを作ることも可能なはずであり、これは Linux の怠慢。ディストリビューションが Xen を含めてしまっているのは急ぎすぎだ」という意見を持つ人もいる。
Xen とともに古くから開発/利用されてきた Xen用 API。フロントエンドプログラム (例えば xm) からの指示を Xenドライバを通してハイパーバイザや XenStore に伝える。xend は python 言語で書かれており、通常はシステムの rcスクリプトからデーモンとして起動される。今のところ、xend がないと xm コマンドも virsh コマンドも働かない。
Xen および xend に付属している旧来の Xen 操作ユーティリティ。xm も python で書かれている。
libvirt (リブヴァート) は、xend の後に開発が進んだ仮想環境 API。その libvirt の提供する API を介して Xen ハイパーバイザや XenStore に命令や問い合わせを行うユーティリティが、 virsh (ヴァーシュ) だ。つまり、libvirt が稼働していないと virsh は機能できない。 libvirt は通常、システムの rcスクリプトから libvirtd というデーモンとして起動される。また、今のところ、virsh の動作には xend の稼働も求められる。libvirt および virsh は主に C言語で書かれている。
libvirt は Xen に代表される様々な仮想化技術の共通 API となることを目指しており、 libvirt がバックエンドの違いを吸収してくれるため、フロントエンドプログラムは、バックエンドが Xen だろうが KVM だろうが UML だろうが VMWare だろうが気にする必要がなくなるらしい。時代の流れとしては、 xm は (部分的に残るとしても) 過去のものとなりつつあり、virsh が中心になっていく様子が見て取れる。virsh のコマンドが xm のものと酷似しているのも、 xm からの移行をスムーズにしようという意図からだろう。
Xen.org Wiki - XenStoreReference より和訳
「XenStore は階層構造を持ったネームスペース (sysfs や OpenFirmware と相通ずるもの) で、ドメインがいくつあっても XenStore は共通でひとつだ。Xen によって提供される基礎的なドメイン間コミュニケーションはごくローレベルのもの (仮想IRQ や共有メモリ) だが、その上に位置して Xen そのものよりも高次のオペレーション (キーの読み書きや要素の列挙、キーの値が変化した際の通知など) を提供するのが XenStore だ。
XenStore は domain-0 上で稼働する一種のデータベースで、トランザクションを備え、アトミックなオペレーション [訳者註： グループ化された不可分なデータベース操作] に対応している。XenStore へのアクセスは 、domain-0 上の UNIX ドメインソケット経由でも、カーネルレベルの API でも、/proc/xen/xenbus を通じた ioctl インターフェイスでも行うことができる。アクセスは必ず <xs.h> で定義された関数を使って行うべきである。XenStore は各ドメインの実行時の情報を記録するものであるとともに、Domain-U のデバイスの作成や管理のためのメカニズムとしても機能する。
XenBus とは、仮想 IO デバイスドライバが XenStore と情報を遣り取りする際に利用される、カーネル内 API である。」
ファイルシステム上の実体としては、/usr/sbin/xenstored が実行ファイル、/var/lib/xenstored/tdb がデータベースファイル。xenstored は xend の rcスクリプトの中で起動される。Xen パッケージには、XenStore の内容を読み取ったり操作したりできるユーティリティも付属している。例えば xenstore-ls, xenstore-list, xenstore-read などがある。
Windows など Xen のことを知らない OS を Xen 上で動かすには、完全仮想化 (Full Virtualization) が必要となる。それを実現するためには CPU やチップセットが特別な機能を備えていなければならない。そうしたハードウェア技術を総称して x86仮想化 (x86 virtualization) と呼ぶ。 ハードウェア仮想化 (Hardware virtualization) とも呼ばれる。CPUメーカーの仮想化技術名はいろいろあって分かりづらいので下にまとめておく；
この言葉は、libvirt に付属する文書 libvirt-api.xml に出てくる virtDomainCreate ファンクションの注釈にある "moves from the defined to running domains pools" という記述からの単なる思いつきだ。説明上便利なので筆者が勝手に使っている。virsh で define を行うと、そのゲストドメインの定義がドメイン定義プールに登録される。定義プールは、Fedora Core 8 での観察によると /var/lib/xend/domains/ 配下で、その下の <UUID>/config.sxp というファイルに S形式 (S-expression) で定義が記述される。(<UUID> はそのドメイン固有の uuid を名前とするディレクトリ)。`virsh undefine GUEST ' すると <UUID> ディレクトリごと削除されることも確認できた。本当の意味での "defined pool" や "running pool" はおそらく別の空間にある。