Xenとは何か

!! 注意 !!

このドキュメントは書きかけです。精査も検証もされていません。誤字脱字も多数残っています。

このドキュメントは現状のままで提供され、更新や修正されるか否かも含めて無保証です。 この内容により生じた一切の影響、損失、被害の責任を筆者は負わないものといます。

この文書は各種の公開された資料を参考にして独自に記述しています。

OSと仮想マシン

アプリケーション実行環境

コンピュータに何かを実行させるために、通常はアプリケーションソフトを動作させます。このアプリケーションが動作するためには、当然のごとく実行に必要なハードウェアが必要です。かつてはアプリケーションがハードウェアを直接操作していた時代もありましたが、これは非常に効率が悪く、また、異なるハードウェアではそのまま動作させられません。現在では一般的にこれらハードウェアを抽象化し、アプリケーションが利用しやすいように管理し、また、便利な機能を集めて「実行環境」を提供するのがOSの役割です。

一般的なOS環境は、他にもCPU資源やメモリなどのリソース管理やマルチタスク管理、使用者の実行権限管理など、各種のアプリケーション実行環境を提供しています。 よって、アプリケーションはOSの機能を使ってハードウェア上で実行されることになるため、当然実行するOSに強く依存することになります。 その一方で、色々な理由によりアプリケーション毎にOS環境を別々に用意したいことがあるでしょう。これを実現する方法としては物理的に複数のハードウェアを用意することでもできますが、単一のハードウェアだけで可能とするのが仮想化(仮想マシン)です。

仮想マシンの種類


仮想マシンは大きく、ハイパーバイザ型仮想マシン、アプリケーション型仮想マシン、ラッパーOS型の3つがあります。

ハイパーバイザ型はその名のとおりハイパーバイザといわれる仮想マシンマネージャ(VMM)がハードウェアを管理し、その上で仮想化されたハードウェア環境を提供してゲストOSを動作させます。各ゲストOSは互いに独立しており、ハイパーバイザが割り当ててくれたハードウェアなどのリソース以外は使用することができません。

アプリケーション型は、普通のOS環境(ホストOS)の上で、そのOSのアプリケーションとして仮想マシンマネージャを動かして仮想ハードウェアを作り出し、そこでゲストOSを動作動作させます。仮想マシンマネージャ内の各ゲストOS環境は互いに独立していますが、仮想マシンマネージャ自身がホストOSのアプリケーションであるため、そのホストOS上で動作する別のアプリケーションと同じ環境で動作します。

ラッパーOS型は、アプリケーションに対して﹁あたかもOSが独立して稼働しているような環境﹂を提供するものです。厳密には仮想マシンではなく、OS環境そのものの仮想化です。SolarisのZone(Solarisコンテナ)、jailのようなchroot環境進化型、あるいはDragonFlyBSDのvkernelやNetBSD/usermode、また、BSD上で動作するLinuxバイナリ実行環境もこの一つといえるかもしれません。

一般的なOS環境に対し、それぞれの概念を示した図を次に示します。
virtual machine type

それぞれの方式には長所も短所もあり、どの方式が良いというものではありません。また、現実にはこれらの3種類に完全に分類できるものでも ありません。

Xen仮想マシン

Xenの仮想化手法

Xenはハイパーバイザ型の仮想マシンマネージャ(VMM)です。本質的な部分は単独で動き主にCPUやメモリ、タイマーなどの基本的なハードウェアを管理し、Xen仮想マシンというハードウェア環境を提供します。この仮想マシンは複数作り出すことができるため、Xen仮想マシン用のOSを何個も同時に動作させることができます。

つまりアプリケーション型の仮想化のように「あるOSの上で別のOSを動かす」ことは決してなく、「Xenハイパーバイザが提供する仮想ハードウェアの上で対応したOSを同時に複数動かす」ことができるものです。注1

Xen 1.0ではハイパーバイザ内にハードウェアに対応したデバイスドライバを持ち動作させていました。しかし、これでは新しいハードウェアが出来る度にドライバを作成せねばなりません。同じ事は既に既存のOSで使われています。そのため、Xen2.0ではその成果を外部から利用できるようにハイパーバイザ内にドライバを持つことを止め、特別なゲストOSにデバイスを直接割り当てる(権限移譲)ことで対処しました。この特別なゲストOSのことをXenでは特権ドメインと呼びます。通常、特権ドメインでは特別はデバイスと共にXenハイパーバイザの制御も任されます(ただし、ハイパーバイザそのものがこのドメイン上に存在するわけではありません。ハイパーバイザに対して指令を送る口を持っていると考えればよいでしょう)。なお、Xen2.0ではハードウェア資源を物によって別のゲストOS(Domain-U)に割り当てることができます。例えば、USBだけをDomain-0ではない特定のドメインに与えてることができます。

Para-Virtualization

XenではDomain-UはXen仮想マシンという特別なハードウェアを提供します。この特別なハードウェアは、一般的な現実に存在するPCアーキテクチャとは異なっています。具体的には、Xen Busと呼ばれる仮想的なバスを提供し、そこを通して仮想デバイスにアクセスするためのHyperVisor Callと呼ばれる特別なソフトウェアインターフェースを使ってデバイスにアクセスします。また、PCアーキテクチャでは歴史的経緯によりBIOSや16bit命令が使われる場合が残っていますが、Xen仮想マシンではそのようなものはありません。 このため、既存のPCアーキテクチャ用のOSそのままでは動作させることができません。つまり、Xen仮想マシン専用のOSが必要となります。ただし、これは一般的にOSカーネルと言われる部分で吸収できるため、通常のOSで動く一般的なアプリケーションには影響を与えません。このように、既存のOSをそのままではなく一部を仮想マシン用に手直しして仮想マシンを動作させる方法のことをPara-Virtualization(準仮想化)と呼びます。注2

(Para-Virtualizaion説明図)

Full-Virtualization


Para-Virtualizaionでは、当然既存のバイナリしか提供されていないOSをDomain-U上で動作させることはできません。そこで、Xen 3.0ではXenの仕組みの上に、ハードウェアエミュレータを組み合わせることで、Xen仮想マシン用OSではないPCハードウェア用OSをそのまま動作させる方法を付け加えました。これを一般的に完全仮想化(Full-Virtualization)と呼びます。
(Full-Virtualizaion説明図)
Full-Virtuallizationを実現するためには、仮想マシン上ではそのまま実行できない部分を実行できるようにしなければなりません。具体的には、本来OSの中でなければ実行できないCPUの命令(特権命令)や機能を何とかして実行できるように、それもCPUやメモリ、各種ハードウェア、同時に実行する別のOSに影響を与えないようにしなければなりません。

この実現方式としては、﹁実行できない命令を実行しようとしたら割り込みを発生させ、割り込みルーチンであたかも正常に実行したようにみせかける(トラップ)﹂方法と、﹁実行できない命令をあらかじめメモリ上などで検索しておき、実行できる命令に置き換えてしまう方法(ダイナミックトランスレーション)﹂が考えられます。一般的にも、また、Xenが採用した方法も前者の仕組みです。しかし、伝統的なIntel x86-32bitアーキテクチャのCPUには一部トラップできない命令がある等機能的な不足がありました。そのため、これらを補ったIntel VT-xやAMD-Vといった追加命令セットが登場しました。このような理由により、Full-Virtuallizationは、Intel VT-xやAMD-Vといった拡張命令をサポートするCPUでしか動作させられません。

Full-VirtualizationではDomain-0上でエミュレータをプロセスとして動作させるため、多数のFull-Virtualizationを同時に動作させると、結果としてDomain-0ではハイパーバイザからの要求により多くのエミュレータプロセスが動作することになります。これは、Domain-0に負荷が集中、増大することにも繋がります。こソースの仮想化や分離性といった意味であまりこれは好ましいことではないと言えるでしょう。

このような状況を改善するために、Domain-U上にXen仮想マシンの仮想ハードウェアに対応するデバイスドライバを用意することもできます。これはPara-Virtualizationドライバと呼ばれており、Para-Virtualizationの仕組みで動作します。このドライバは当然それぞれのOSに依存したもので、動作させるOS毎に別々に用意する必要があります。
(PV Driver説明図)

参考文献

注1:
これを勘違いすると、boot時や各種ハードウェアの制御方法について理解できなかったり、誤った対処をしてしまうなど根本的な問題を引き起こします。しかし現実にはWeb上や雑誌記事、書籍などでも間違った説明が溢れているので、注意が必要です。
注2:
準仮想化という言葉は既に定着しているのですが、この言葉からはまるでちゃんと仮想化できていない(きちんと仮想化されていない)というイメージを受けてしまう場合があります。実際、確かに「既存のPC上のすべてのハードウェアを仮想化しているか」という視点でみるとその通りです。
が、別の視点で見ると、Xen仮想マシンという仮想ハードウェアを定義(ここがハードウェアの仮想化)し、そのハードウェア仕様に従ってOSを移植するのは至極真っ当な考え方でもあると言えます。
個人的な感覚では、むしろXenにおける完全仮想化はPCハードウェアという別のアーキテクチャのOSをXen仮想マシンという異なるアーキテクチャのハードウェア上で動かすためにエミュレータを導入して無理矢理実行できるようにしているように思え、とても完全とは言えないと思えてしまうからです。例えるなら、同じIntel製CPUを搭載しているかつてのPC-98x1というハードウェア上で、仮にAT互換機用のOSをそのまま動くようにエミュレータを作成/用意して動かした場合、それは「完全仮想化」と言えるのか。私の感覚からは「それはちょっとちがうんじゃない?」と思ってしまうのです。
もちろん、最初に書いたように、エミュレータを導入してでもPCハードウェアを完全に仮想化することが必要な場面がある(そしてそうしなければ動かない物が存在する)という点では全く異論はありません。
$Id: about_xen.html,v 1.2 2008/07/12 10:22:13 oshima Exp $