Xenのよくある問題を解決する5つの実践的トラブルシューティング術

運が悪い日には、仮想化の体験も一気に台無しになりがちです。Xenを使い始めたばかりの方なら、Xenのエラーメッセージが極めて冗長で、Python開発者でない限りほとんど役に立たないことを痛感するはずです。冗長なトレースバックと内部関数呼び出しへの不可解な参照のせいで、本来ならシンプルに解決できる問題から注意をそらされてしまうことさえあります。

筆者は仮想化やPythonの専門家ではありませんが(実は専門家なのですが、謙遜しておくのが得策です。1) エラーが許容される 2) 失敗しても済む 3) 人は謙虚さや弱者を好むからです)、解決には数分しかかからないのに、初心者には永遠に感じられるような典型的な問題にいくつも遭遇してきました。というわけで、Xenを快適に使いこなすためのお手伝いをさせてください。

ヒント1: ディスプレイ設定

作業を始める前に、まずディスプレイが正しく構成されていることを確認しましょう。BASHでもTCSHでも、DISPLAY変数をexportまたはsetenvで適切なデバイスに設定します。これが最初の一歩です。

export DISPLAY=hostname:port

ヒント2: 「No module named ○○」エラー

「no module named xen.xm」「no module named gtk」など、この種のエラーメッセージが大量に表示されることがあります。一見無関係に見えるメッセージでも、多くの場合、根本的な原因は同じです。

xmのトレースバックの例を見てみましょう。/usr/sbin/xm something を実行して失敗する様子です。

Linux #xm list

Traceback (most recent call last):

  File "/usr/sbin/xm", line 8, in <module>

    from xen.xm import main

ImportError: No module named xen.xm

考えられる原因は2つあります。1) モジュールが本当に存在しない、2) 別の場所に問題がある。まず最初のケースから見ていきましょう。

Pythonモジュールが欠落している場合

モジュールが本当に欠落している可能性があります。ホストマシンに関連パッケージがインストールされているかを確認すれば検証できます。たとえばgtkパッケージが疑われる場合は、インストールデータベースに対してgtkやpython-gtkパッケージを問い合わせてみてください。

また、失敗するコマンドをstrace付きで実行し、ユーティリティが必要としているファイルやディレクトリの欠落を調べる方法もあります。これにより問題の詳細な情報が得られるはずです。Xenのインストール自体が不完全である可能性も十分にあります。

別の箇所に問題がある場合

ここでいう「別の問題」とは、Pythonの環境設定を指します。パッケージはマシンにインストール済みなのに、何らかの理由でPythonがそれらを認識できないケースです。この問題を回避するには、PYTHONPATH変数を手動で設定し、site-packagesディレクトリを明示的に指定します。

export PYTHONPATH=/path-to-python-version/site-packages

あわせてPATH変数も確認し、意図したバージョンのPythonが使われているかチェックしましょう。コマンドはフルパスで実行するのが常におすすめです。これが次のヒントにつながります。

ヒント3: 明示的なコマンド実行

意外に思われるかもしれませんが、Xenユーティリティの多くはラッパースクリプトにすぎません。その内部にはPythonコードが隠れています。たとえばVirtual Machine Manager(VMM)もPython製です。まず、ユーティリティがどこにあるのかを特定しましょう。

which <xenユーティリティ>

次に、そのファイルの中身を確認します。

cat <xenユーティリティへのパス>

そして、ラッパーを経由せずにコマンドを直接実行できます。ラッパーコマンドは相対的な名前を持っているため、どのPythonバージョンを使っていてもツールが動くという利点がありますが、その反面、問題発生時には根本原因が覆い隠されてしまうのです。

本当にアプリケーション側の問題なのか、それとも環境設定の問題なのかを見分けるには、Python本体へのフルパスを指定してコマンドを実行します。たとえばvirt-managerの代わりに次のように実行します。

/usr/bin/python "/usr/share/virt-manager ..."

さらに、python2.4やpython2.7など、特定のバージョンを明示的に使ってみるのも有効です。

ヒント4: スクリプトの書き換え

熟練ユーザーでない限りおすすめはしませんが、ラッパースクリプトを編集して、特定のパスやPythonインストール先を直接指定することも可能です。冒頭の問題に戻りましょう。xm create <VM名> を実行すると、xen.xmモジュールのエラーが発生しました。

まず、xmコマンドの正体を確認します。which xm を実行すると /usr/sbin/xm に格納されていることがわかります。このファイルをテキストエディタで開いてみると、確かにPythonスクリプトです。

#!/usr/bin/env python

#  -*- mode: python; -*-

import sys

 

# add fallback path for non-native python path installs if needed

sys.path.append('/usr/lib/python')

sys.path.append('/usr/lib64/python')

from xen.xm import main

 

main.main(sys.argv)

Xenの一部のバージョンでは、1行目が #!/usr/bin/env python となっています。これを特定のPythonバージョンに書き換えてみるとよいでしょう。たとえばPython 2.4やPython 2.6などです。いずれかのバージョンが誤設定されていたり、環境に存在しなかったりする可能性があります。

#!/usr/bin/env python <--- 削除

#!/usr/bin/python2.6  <--- 使用

書き換えた結果、期待どおりすべてが正常に動作するかもしれません。たとえば、Xenカーネルも導入済みの筆者のopenSUSE 11.4マシンではうまくいきました。

同様に、新しいバージョンのXenで単に /usr/bin/python と記述されている場合も、同じ変更を試すことで、自分の環境固有の問題かどうかを切り分けられます。

変更を加える前に必ず元のファイルをバックアップしてください。また、新たな複合的な問題を生まないよう、一度に複数の変更を加えるのは避けましょう。

ヒント5: サービスの確認

初歩的に聞こえますが、libvirtサービスが起動していなければ、仮想化まわりで大きなつまずきになります。dom0ドメインに接続できなくなるなどの支障が出ます。サービスが稼働中であること、そしてシステム起動時に自動的に有効化されるよう設定されていることを必ず確認してください。

ひとまず、今回はここまでにしておきましょう。

参考資料

Virtuatopiaには非常に価値のあるリソースが揃っています。

Red Hat Documentationの「Common Xen Problems」も参考になるでしょう。

まとめ

この記事は決して美しい文章ではないかもしれませんが、そもそもPythonのトレースバックメッセージも美しいものではありません。過剰な冗長性のせいで、正しい環境変数の設定やPythonバージョンの変更といった単純な解決策が見えにくくなっているのです。このガイドが、皆さんの貴重な時間とフラストレーションを大幅に節約できれば幸いです。

読むべきコンテンツはまだまだたくさんあります。ぜひ仮想化セクションへ足を運び、片っ端からクリックしてみてください。入門記事、Xen Cloud PlatformやXenServerの解説、お試し用ライブCDなどをご用意しています。今後もXenに関する情報をお届けする予定です。別のオープンソースソリューションに興味があれば、KVMの記事もありますので、ぜひご覧ください。

他にもシンプルで普遍的なテクニックをご存じの方は、遠慮なくメールでお知らせください。

それでは、また。