Xenとは何か

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

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

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ではない特定のドメインに与えてることができます。

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では、当然既存のバイナリしか提供されていないOSをDomain-U上で動作させることはできません。そこで、Xen 3.0ではXenの仕組みの上に、ハードウェアエミュレータを組み合わせることで、Xen仮想マシン用OSではないPCハードウェア用OSをそのまま動作させる方法を付け加えました。これを一般的に完全仮想化(Full-Virtualization)と呼びます。

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毎に別々に用意する必要があります。