XenによるFedoraの仮想化
本記事は、2007年8月に出版されたAndrew Hudson、Paul Hudson著『Fedora 7 Unleashed』（SAMS Publishing）からの抜粋である。
仮想化と疑似仮想化
仮想マシン（VM）は割り当てられたRAM上で、外部の世界に対して完全に自己充足的に動作する。仮想化システムの一つであるVMwareなどは、この仮想世界を完全なものにすべくBIOSさえも仮想化している。したがって、一般に、VM同士が情報を交換するには、たとえ同じコンピューター上にある場合でも、異なるコンピューター上にある場合と同じようにTCP/IPネットワークを利用する必要がある。実際、VM上にインストールされたオペレーティング・システム（OS）から見える環境はハードウェアに直接インストールされた場合とまったく同じため、OSはVM上にあることすら認識できない。
しかし、この方式による仮想化には動作速度が著しく低下するという欠点がある。VMはハードウェアに頻繁にアクセスする必要があるが（ファイルを保存したりディスプレイに表示したりするため）、当然のことながら、ハードウェアに直接アクセスすることはできない。直接アクセスすれば、ほかのVMと干渉する可能性があるからだ。そこで、ハードウェアに対するリクエストはホストOSに対して処理を依頼する形に変換する必要がある。同様に、VMであることがわかるようなCPU命令については、ホストOSがVMによる実行を捕捉して、VMであることを悟らせないよう命令の結果を偽装しなければならない（バイナリー・パッチと呼ばれている技法）。こうした条件により、動作速度が低下するのだ。
この問題を解決するために考案されたのが、仮想化ならぬ疑似仮想化である。Xenはこの方式を採用している。Linuxはオープンソースであるため、ソース・コードを変更することができる。これを利用して、LinuxがVMであることを認識し、仮想Linuxがハードウェアにアクセする場合はXenに許可を求めるように改造する。バイナリー・パッチをなどの仮想化技法を使わないというこの違いが、大きな効果を生む。通常のVMはハードウェアの能力の50%ほどでしか動作しないが、Xen VMは最大95%で動作できるのだ。
Xenの弱点はソースコードにパッチを当てる必要があること。したがって、ソースコードが公開されていないオペレーティング・システムには適用することができない。VMwareはLinux上でWindows XPをそのまま動かすことができるが、Xenでは不可能だ。ご存じのように、Xenでも、Linux上でWindowsをそのままの形でフルスピードで動かせる。しかし、これはIntelやAMDがハードウェアによる仮想化機能を持つ新しいチップを出したからであり、この技術がなければ、Xenは、LinuxやNetBSD、FreeBSDなど、ソース・コードの変更が可能なオープンソース・ディストリビューションにしか適用することはできない。
Xenの仕組み
Xenの実態は、VMのリソースを管理することを唯一の目的とするごく小さなオペレーティング・システムだ。Xen OSの上に従来ホストOSと呼ばれてきたものが載り、これがマシンの主たるOSとなる。VMwareとは異なり、このホストOS（Xenではドメイン0またはdom0と呼ばれている）はVMだ。ただし、応答性を改善するために特権が与えられている。
ドメイン0 VMはXenを制御する場であり、ほかのVMを起動する場でもある。ここから起動されたVMは非特権ドメインまたはdomUと呼ばれている。起動するVMの数に制限はなく、マシンに搭載されているRAMの大きさで実質的な制約を受けるだけだ。domU OSはXen VM上にあることを完全に把握しているため、VMに割り当てるRAMの大きさを稼働中に変更することができる。ただし、最初に割り当てたRAMの大きさを超えることはできない。
Fedora LinuxのRAMに関する最小システム要件は256MBだ。したがって、Fedora上でFedoraを動かすには、少なくとも512MBのRAMが必要になる。Xen自体が使用するRAMはごくわずかなので、計算上は、768MBのRAMがあれば2つのOSをフルスピードで併走させることができることになる。
なお、旧版のFedoraではSELinuxを無効にしないとXenは動作しなかったが、今、その必要はない。
Xenのインストール
まず、現行のOSを仮想ゲストOSに変更する。難しそうに聞こえるが、実際にはきわめて簡単だ。すでに述べたように、ドメイン0は、ハードウェアに直接アクセスできるなど、特権を持っているからだ。したがって、マシンを再フォーマットする必要はない。dom0は直接ディスクを読み、グラフィックス・カードやサウンド・カードを使う。
まず、メニューからApplications→Add/Remove Softwareと進む。ウィンドウが開くので、その中のListビューを選び、kernel-xenとvncとxenの3つのパッケージを選択する。kernel-xenパッケージには、Xen上で非特権的に動くよう構成されたLinuxカーネルと、ハードウェアに直接アクセスできるdom0用のLinuxカーネルが含まれている。vncパッケージはVMの管理を容易にし、xenパッケージにはVMを作成し管理するために必要となるツール群が含まれている。依存性はほかにもあるが、Fedoraが自動的に解決してくれるので、このままでパッケージをインストールする。
新しいカーネルが2つインストールされたため、それをブートできるようFedoraはGRUBブート構成を変更する。元からあった非Xenカーネルはデフォルトとなる。そこで、デフォルトを変えるため、rootになり、適当なテキスト・エディターを使って/boot/grub/grub.confを開き、そこにあるdefault=2という行をdefault=0に変更する。ここで、数字はgrub.confでのXenハイパーバイザー・カーネルの位置を表し、マシンごとに変わる。GRUBは、1ではなく0から番号を付けることに注意。したがって、リスト上の最初のOSは第0番になる。ここで、ゲスト・カーネルをデフォルトにはできないことに注意しよう。ハイパーバイザー（dom0）上に作られることを前提としたdomUのゲスト・カーネルは、ブートしないのだ。
変更したらファイルを保存して再起動する。新しいハイパーバイザー・カーネルが起動されるが、その様子に変わったところは何もないはずだ。最初に「Xen」がちらっと表示されるが、それ以外に気付く点はないだろう。しかし、起動後ターミナルを開き「uname -r」を実行してみてほしい。Xenハイパーバイザー・カーネルが動作していることがわかるはずだ。
この時点で、Xenカーネル上にはVMが動作している。今操作しているのはそのVMだ。しかし、この状態ではXenカーネルと交信することもできなければ、システム上にVMを作るなどの操作をすることもできない。それには、dom0とその下にあるXenカーネル間を橋渡しするXenデーモンが必要だ。
まず、「ps aux | grep xend」を実行して、xendが動作しているかどうかを確認する。動いていなければデーモンを起動する。「su -」コマンドでrootになり、「service xend start」を実行すればよい。デーモンが起動したら、「xm list」コマンドを実行してみよう。そのとき稼働しているVMとそれに割り当てられているRAMの大きさが一覧表示される。その中に、今いるシステムDomain-0があるはずだ。
ゲスト・オペレーティング・システムの設定
このリストで、ドメイン0が使っているRAMの大きさを確認してみよう。ドメイン0は、おそらく、システム上のRAMをすべて使っているだろう。もしそうなら、新しいゲストOSを作る余地はない。その場合は、使用するメモリーを減らして空きを作る必要がある。コマンド「xm mem-set Domain-0 256」を実行する。これで、ドメイン0が使うRAMは256MBに減少する。これはFedoraインストールに必要なメモリーの下限であるから、動きが若干遅くなると予想される。RAMが512MB以上あるなら、もう少し大きめにメモリーを割り当てた方がよい。
Fedora上にdomU VMを作る場合は、rootでxenguest-install.pyというスクリプトを実行する。その際、次の項目を設定する。
- VMの名前。FCUnleashedなど、わかりやすい名前にする。これは、ほかのVMと区別できるようにするため。
- 割り当てるRAMの大きさ。256MB以上で、なるべく多く。
- ファイルを保存する場所。Xenはループバック・ファイルシステムを使っているため、VMのファイルはすべてドメイン0の1つのファイルの中に格納される。/home/paul/vms/fcu.imgなどとする。
- 仮想ディスクの大きさ。基本的なインストールでは4GB程度で十分だ。
- インストールの位置（ここからFedoraをインストールする）。オンライン・リソースhttp://download.fedora.redhat.com/pub/fedora/linux/core/6/i386を設定する。
ここで、しばらく待つ。接続速度によるが、必要なファイルをダウンロードするには時間がかかるのだ。
必要なファイルがダウンロードされると通常のFedoraインストーラー（Anaconda）が起動し、インストール・モードを尋ねてくる。テキスト・モードとVNCのいずれかだ。ここではStart VNCを選ぶ。これでインストールはグラフィカルになるが、Xenのゲストはハードウェアに直接アクセスすることができないので、グラフィックスを表示しようにもその場所がないはずだ。実は、VNCでは、Xen VMのグラフィックスをウィンドウ内にあるdom0のディスプレイに表示させることができる。つまり、ここを通して複数のVMを同時に扱うことができるのだ。Start VNCを選択するとパスワードが要求されるので設定し、OKをクリックすると、VNCアドレスが表示される。このアドレスは10.0.0.1:1などといった形式をしている。ここで、:1はVNCディスプレイの番号を表す。ディスプレイに接続するときに、このアドレスが必要になる。
dom0に戻り、初めにインストールしておいたVNC Viewerを起動する。まず、メニューからApplications→Accessories→VNC Viewerと進む。先ほどのアドレス（上の例で言えば:1の部分まで）を入力し、Connectをクリックする。パスワードを要求されるので先ほど設定したものを入力する。これでVNCが起動し、Fedoraインストーラーが表示されるはずだ。画面の解像度によるが、Fedoraインストーラーが画面からはみ出している場合はスクロールバーを使う。
ここから先のインストーラーの動きは通常と同じ。ただし、先ほど作った仮想ディスクを使うため、ディスクの余裕は乏しい。ハード・ディスクは/dev/xvdaなどとなるが、気にする必要はない。
稼働中の構成
ゲストOSが起動したら、dom0からxmコマンドを使ってみよう。マシンに割り当てるメモリーの大きさを変更するコマンド「xm mem-set」はすでに経験済みだ。domU VMは仮想化されていることを認識しているので、使用するメモリーの大きさを変更することができる。同じ理由で、VMに対してシャットダウンを求めることもできる。コマンドは「xm shutdown yourvm 」。これを使えば、domU VMはLinuxの正当なシャットダウン手順を経て正常終了する。直ちにシャットダウンさせたいときに使うコマンドは「xm destroy yourvm 」。これを使う場合は、VMが安全な状態にあることを確かめておく必要がある。たとえば、テキスト・ファイルをオープンしていてまだ保存していなければ、ファイルは失われる。
xmコマンドはVMを停止させるだけでなく、スナップショットを保存することもできる。コマンドは「xm save yourvm yourvm.state。このコマンドはyourvm VM（yourvmはVMの名前）のRAMをファイルに保存しVMを停止させる。コマンド「xm restore yourvm.state」を実行すると、保存した状態が復元される。構成ファイルからVMを作る場合は、コマンド「xm create -c yourconfig を使う。構成ファイルは/etc/xenに置き、VMに付ける一意的な名前を設定しておく必要がある。
VMのコンソールに接続するコマンドは「xm console yourvm 」。Ctrl-]（Controlキーと右角括弧)を押せば、接続は切断される。コンソールを切り離したあとも、VMは動作を続け、シャットダウンはしない。再度「xm connect」コマンドを実行すれば、再びコンソールが接続される。
ヒント /etc/xenにある構成ファイルはテキスト形式のため、編集は容易だ。たとえば、vcpusの設定値を変えるだけで、VMから見えるCPUの数を変更することができる。これは仮想CPUであって、実際のCPUではない点に注意。したがって、実際にはCPUが1基しかなくても8を設定すれば、ゲストOSにはCPUが8基あるように見える。これを利用してデスクトップでクラスターをテストすることができるので非常に便利だ。
仮想化に関連するFedoraコマンドとXenコマンド
Fedora上のXenを扱う際に有用なコマンドを以下にまとめた。
-
virt-manager— Red Hatの新しいグラフィカルXen管理システム。 -
vncviewer— Xen VMのグラフィカル出力に接続するコマンド。 -
xend— Xenデーモンを起動したり停止させたりするコマンド。したがって、serviceコマンドを使わなくても起動・停止はできる。 -
xenguest-install.py— 構成ファイルの作成に便利なスクリプト。 -
xm— 稼働しているVMの状態を操作するコマンド。
