2009年5月30日土曜日

Xenのインストールに苦労する

仮想化が注目されるようになって久しいが、ようやくXenに手をつけてみた。かなり流行に乗り遅れた感があるけれども、いろいろとはまったところもあるので、メモ代わりに記録を残す事にする。知っている人にとっては当たり前の内容だが、自分自身が後でまた同じ苦労をしそうなので、未来の自分に向けてはまった点を書いておこう。

はまった理由は、Linuxの知識の少なさに由来する部分も大きい。ずっとBSD系のOSを使ってきたので、Linux世界の暗黙の前提が分からない事も多く、Linux使いの同僚や知り合いにたくさん質問をするはめになってしまった。おかげで、多少なりともLinuxの使い方が上手になったかもしれない。

Xenは、Host OSとしてLinuxNetBSDをサポートしている。今回は、Xenと平行してLinuxのMobile IPv6スタック (NEPL) を利用する予定にしているので、ホストOSとしてLinuxを選択した。

今回使うDistributionはDebian。まわりのLinuxカーネル開発者の多くが使っているので、それに倣ってみた。
  • Debian testingリリース (2009年5月時点)
  • Xen 3.2.1
Debianは現時点での最新開発リリース (testing) を使ったけれども、実際はstableでもよいはずだ。NEPLが前提とするカーネル機能が、比較的新しいLinuxカーネル (2.6.23以降) にしか入っていないため、それに合うリリースを使う。stableリリースのカーネルも、十分条件を満たしているのだけれど、なんとなくtestingを使ってカーネル最前線を楽しんでみる。

Xenの最新バージョンは3.4 (2009年5月時点) だが、インストール作業などをざっくり省略したかったので、APTパッケージとして準備してある3.2.1を利用することにした。

最初の問題は、DebianやXenのインストールは問題なく完了しているにもかかわらず、実際にXenを使おうとするとうまく動作していないことだった。この、「何もしていないのに動かない」系の問題は、作業をしている本人が本当に何も分かっていない場合、特に始末が悪い。Googleで同じ問題を経験した人を探してみるものの、全くそういう報告が見当たらない。これは逆にめずらしい。つまり、普通の人なら、絶対にやらない間違いをやっているということになる。

調べてみると、どうやらGuest OSを接続するためのブリッジインターフェースの作成と、Host OSが実際のネットワークと接続する物理インターフェースの作成に失敗しているようだった。

Xenサービスが起動する際、Host OSのネットワークインターフェースは、だいたい以下の手順で操作される。
  1. Guest OSを収容するためのブリッジインターフェース (tdev) を作成する。
  2. Host OSが、Xenサービス開始前に利用していたインターフェース (通常はeth0) のネットワーク情報 (IPアドレス、経路情報など) を、1.で作成したtdevインターフェースに移動する。
  3. eth0インターフェースをpeth0に名称変更する。
  4. tdevインターフェースをeth0に名称変更する。
  5. peth0インターフェースをブリッジインターフェース (この時点ではeth0) のスレーブとして追加する。
この操作の結果、Host OS上にeth0というブリッジインターフェースが新規に作成され、もともとeth0という名前だったインターフェースはpeth0に名前を変えることになる。なぜこのような複雑な手順が必要かというと、Host OS上で動作するアプリケーション群から、インターフェース名の変更を隠蔽するためだろう。Xenサービス開始前と後では、eth0の構成状態が異なる (通常のインターフェースからブリッジインターフェースに変更されている) が、アプリケーションからみるとXenサービス開始前と同様、eth0のままアクセスできる。

問題なさそうだが、最初にXenを使おうとした時は、なぜかeth0peth0に同じネットワーク情報が重複して設定されるという状態に陥っていた。さんざん悩んだ挙句、問題はNetworkMmanagerと呼ばれるソフトウェアとの競合にあることが分かった。NetworkManagerは、ネットワークインターフェースの設定を半自動化するアプリケーションソフトウェアのようだ。ネットワークインターフェースのup/downに応じて、設定ファイルに記述された情報を元にアドレスを構成する。Xenの場合、前述したブリッジインターフェースの構成の途中で、インターフェースのup/downが発生する。このとき、すでにアドレスを取り除かれたeth0インターフェースが、peth0に名称変更される前にup/downが行われ、結果NewtorkManagerによって再び (不要に) アドレスが構成されていた。

当然、この問題はNetworkManagerがインストールされていなければ発生しない。どうやら原因は、Debianのインストールの際に、なにも考えずにDesktop環境を構成したことにあったようだ。NetworkManagerは、GUI統合環境のタスクバーから簡単にネットワークインターフェースを設定するために使われる事が多く、今回インストールしてしまっていたDesktop環境でも利用されていた。

あらためてDebianをCUIインターフェースのみの構成でインストールし直してみると、なんの問題もなくXenサービスが起動した。普通Xenなぞを使おうと思うような人は、Desktop環境をインストールすることもないだろうから、誰も問題に遭遇していないのだろう。

ともかく、これでようやく下準備ができた。問題はさらに続く。。。