Xen トラブルシューティング実践ガイド：VNC接続、ネットワーク、起動エラーの解決法

以前の記事では、Xen を環境でテストする際に発生しがちな一般的な問題をいくつか取り上げました。最初の回では、ディスプレイの問題、Python のバージョンやモジュールの不具合、ラッパースクリプトの変更や明示的なコマンドの実行、サービスのトラブルシューティングなどに焦点を当てました。

今回はさらに踏み込んで、遭遇する可能性のある（あるいはすでに経験したかもしれない）さまざまな問題について、原因の理解、修正方法、回避策を解説していきます。正直に言うと、一部の解決策はやや場当たり的なものかもしれません。鵜呑みにはせず、あくまで参考としていただければと思いますが、全体的には十分機能すると確信しています。この記事を読めば、あなたの Xen 体験がより「禅」の境地に近づくことを願っています。

ヒント1：ハイパーバイザーホストへの VNC 接続が拒否される・切断される

仮想マシンマネージャー（virt-manager）を起動すると、VNC を使って仮想マシンの内容を表示できるようになります。これにより、該当ドメインのコンソール画面が表示されます。しかし時折、コンソールが真っ白になり、接続拒否や切断のエラーが表示されることがあります。さて、どうすればよいのでしょうか？

筆者の経験によると、これはゲスト OS を再起動またはシャットダウンした際に必ず発生します。再度電源を入れた後は、非常に面倒ですが、コンソールを開き直して内容を確認する必要があります。virt-viewer を使用している場合も同様です。

virt-viewer <domain>

ドメインを再起動、リセット、または電源オフすると、接続が失われます。現時点での簡単な解決策は、virt-manager または virt-viewer 経由でコンソールウィンドウを開き直すことです。

あるいは、以下のコマンドで接続を確立することもできます。

virsh vncdisplay <domain>
vncviewer <virshコマンドが返したホスト名:ポート>

ヒント2：ゲスト稼働中に vif が消え、ネットワークが使えなくなる

仮想マシンの稼働中に、通常 vifX.X というラベルが付いた仮想ネットワークインターフェースが ifconfig の一覧から消え、ゲストが使い物にならなくなることがあります。

この問題は、仮想マシン内のネットワークインターフェースの MAC アドレスがすべてゼロになる形でも現れることがあります。また、ホスト側（dom0）では、/var/log/messages に次のようなエントリが記録される場合があります。

kernel: [ 109.743854] br0: port 2(vif1.0) entering learning state
kernel: [ 109.811880] br0: port 3(tap1.0) entering learning state
kernel: [ 117.369189] br0: port 3(tap1.0) entering disabled state
kernel: [ 117.398076] device tap1.0 left promiscuous mode
kernel: [ 117.398083] br0: port 3(tap1.0) entering disabled state
kernel: [ 117.815006] br0: port 2(vif1.0) entering disabled state
kernel: [ 117.850075] br0: port 2(vif1.0) entering disabled state

では、このような問題をどう修正すればよいのでしょうか？　いくつかの選択肢があります。

第一の選択肢はカーネルのアップグレードです。謎めいた話に聞こえるかもしれませんが、実際には Xen ネットワーキングスタック内の競合状態（レースコンディション）を修正することで解決するケースです。

第二の選択肢は、/etc/xen/xend-config.sxp にある Xen 設定ファイルのネットワーク設定を調整することです。このファイルには、ブリッジや仮想ネットワークインターフェースのセットアップ方法を含む、あらゆるディレクティブが含まれています。多くの人は、Xen のネットワーキングには多少バグがあり、独自のスクリプトを手動で設定すべきだと主張しています。

具体的には、次のディレクティブを変更します。

(network-script network-bridge) を (network-script ) に変更

さらに、ブリッジを手動で設定する必要があります。テスト中は brctl コマンドと ifconfig コマンドを使用し、変更が確実であると自信を持てたら、それらをネットワークスクリプトに恒久的に反映させましょう。RedHat 系や SUSE 系のシステムでは、ifcfg-br<番号> を作成し、/etc/sysconfig/network 配下にある既存の NIC 用ネットワークスクリプトを変更します。Debian 系のシステムでは、/etc/network/interfaces 設定ファイルを編集します。もちろん、バックアップは必須です。

手動によるブリッジ設定の例を以下に示します。

brctl addbr br0
brctl setfd br0 0
ifconfig br0 10.0.0.128 up netmask 255.255.255.0
brctl addif br0 eth0
route add -net default gw 10.0.0.254 br0
ifconfig eth0 0.0.0.0 up

次に、netloop の数を増減させる方法です。netloop とは、作成可能な仮想デバイスのペア数を指します。上限に達した場合は、この数値を増やすとよいでしょう。これを行うには、/etc/modprobe.d 配下に netloop というファイルを作成し、以下の内容を記述します。

options netloop nloopbacks=<大きめの数値、例：16 や 32>

あるいは、/etc/modprobe.conf にこのオプションを追加するだけでも構いません。

このトピックに関する参考資料：

• Xen networking（Xen ネットワーキング）
• Xen ネットワークブリッジの解説とトラブルシューティングノート
• Xen 環境下での SLES ネットワーキング、トラブルシューティングと推奨事項
• 手間のかからない Xen ネットワーキング
• Linux ネットワーキングは最悪。XEN ネットワーキングも最悪。
• Xen の追加仮想ネットワークブリッジの作成

この問題の発生時にカーネルクラッシュに遭遇した場合は、以下の2つのリンクも役立つかもしれません。ただし、かなりマニアックな内容なのでご注意ください。

• Kernel BUG at mm/vmalloc.c:2165
• [PATCH] mm: sync vmalloc address space page tables in alloc_vm_area()

実際には、netloop の数をゼロに減らすことで問題が解決する場合もあります。

ヒント3：レガシー HTTP アクセスを有効にする

libvirt の登場により、dom0 への接続とローカル・リモート両方からの管理において、HTTP は不要になりました。しかし、OpenXenManager のように HTTP/HTTPS を使って接続するツールを使用する予定がある方にとっては、このオプションが有用な場合があります。Web から Xen にアクセスできるようにするには、xend-config.sxp 設定ファイル内のいくつかのディレクティブを編集する必要があります。

(xend-http-server yes)
(xend-port 8000)
(xend-address '')

xend-http-server を no から yes に変更し、正しいポートを指定します。xend-address は、Xend がリッスンするネットワークインターフェースの IP アドレスを指定します。デフォルトの空の引用符のままにしておくと、利用可能なすべてのインターフェースでリッスンします。次に、設定ファイルを再読み込みします。

/etc/init.d/xend reload

その後、Web アクセスをテストできます。

ヒント4：ERROR: unable to connect to 'localhost:8000': Connection refused

上記のヒントの派生として、virt-manager を使って dom0 に接続しようとした際に、「Connection refused」という厄介なエラーが表示されることがあります。Python は冗長な出力で悪名高いため、醜いエラー表示に備えておきましょう。

この問題を解決するには、HTTP アクセスを有効にする必要があるかもしれません。あるいは、そもそもなぜこの現象が起こるのか自問してみる必要があります。最も可能性の高い理由は、Xen サービスのいずれかが動作しておらず、virt-manager がレガシーアクセスへフォールバックせざるを得なくなっていることです。HTTP プロトコルを使いたくない場合は、システム起動時に libvirtd と xend を含む関連するすべての Xen サービスが確実に立ち上がるようにしてください。

ヒント5：domU の起動エラー

xm create <domain> や xm start <domain> でドメインを起動しようとすると、イライラしたり混乱したりするようなエラーメッセージに遭遇することがあります。ここでは、その一部を分解して、問題の所在を理解していきましょう。

#xm start test1
Error: Domain unable to be unpaused: an integer is required
Usage: xm start <DomainName>

GUI 版でも同様のエラーが表示されます。

これは通常、存在しない、またはサポートされていないハードウェアコンポーネント（ネットワークカードやサウンドカードなど）を指定していることを意味します。ドメイン設定ファイル（通常 /etc/xen/vm 配下に保存されています）を見直して、誤りがないか確認してください。/var/log/messages や Xen のエラーログ /var/log/xen/xend.log も参照するとよいでしょう。

次に、別のエラーです。

#xm create test1
Using config file "./test1".
Error: (2, 'Invalid kernel', "elf_xen_note_check: ERROR: Not a Xen-ELF image: No ELF notes or '__xen_guest' section found.\n")

これは、準仮想化（paravirtualized）ゲストを、ドメイン設定ファイル内の HVM カーネル設定で起動しようとした場合に発生することがあります。比較的簡単にデバッグ・解決できます。

#xm create test1
Using config file "./test1".
Error: Device 768 (vbd) could not be connected.
File /tmp/disk.raw is loopback-mounted through /dev/loop1,
which is mounted in a guest domain,
and so cannot be mounted now.

このエラーは、他の仮想マシンがすでに使用中のハードディスクファイルを再利用しようとした場合に表示されることがあります。あるいは、中身を調査するためにどこかでループバックデバイスとしてマウントしていた可能性もあります。

vbd エラーといえば、もうひとつ例を挙げましょう。

#xm create test1
Using config file "./test1".
Error: Device 5632 (vbd) could not be connected. Device not found.

xend.log に表示される同種メッセージのバリエーションは以下の通りです。

DEBUG (DevController:139) Waiting for devices vscsi.
DEBUG (DevController:139) Waiting for devices vbd.
DEBUG (DevController:144) Waiting for 768.
WARNING (XendDomain:1076) Failed to setup devices for <domain id=None name=test1 memory=4294967296 state=halted>: Device 768 (vbd) could not be connected. Device not found.

原因としては、ハードディスクファイルの指定ミス、あるいは何らかのデバイスの誤用（おそらくスペルミス）が考えられます。これは冒頭で挙げた最初のエラーと類似しています。

ここで疑問が生じるのは、「vbd がどんな種類のデバイスなのか、どうやって知ればよいのか？」という点でしょう。最も簡単な回避策として、起動済みの任意の Xen domU 上で確認できます。すべてのデバイスは /sys/devices/xen/ 配下にあります。例えば：

#cat /sys/devices/xen/vbd-768/block/hda/hda1/dev
3:1

この例では、vbd-768 がメジャー番号 3 のブロックデバイスであることがわかります。つまり、hda1 は 3:1 に対応しており、論理的に整合しています。この命名規則については後ほど詳しく説明します。

特定の仮想マシンの一覧全体は以下のようになります。

#ll
total 0
drwxr-xr-x 2 root root    0 Dec 18 12:07 power
-rw-r--r-- 1 root root 4096 Dec 18 12:07 uevent
drwxr-xr-x 4 root root    0 Dec 18 12:05 vbd-5632
drwxr-xr-x 4 root root    0 Dec 18 12:05 vbd-768
drwxr-xr-x 3 root root    0 Dec 18 12:05 vfb-0
drwxr-xr-x 4 root root    0 Dec 18 12:05 vif-0

より複雑な方法としては、番号を16進数に変換し、下位2桁をマイナー番号、残りの上位ビットをメジャー番号として扱い、devices.txt のリスト（オンラインまたは /usr/src/linux/Documentation 配下）を参照して正確なデバイスタイプを特定します。例えば、10進数の 768 は16進数で x0300 となり、メジャー番号 3、マイナー番号 0 を意味します。これは最初（ゼロ番目）の IDE デバイス、つまり hda に相当します。同様に、5632 は x1600 となり、メジャー・マイナーの組み合わせ 16,00 を意味し、ブロックデバイスの場合は CD-ROM に対応します。なかなか興味深い仕組みですね。この古い Xen メーリングリストのスレッドも参考になるかもしれません。

ヒント6：高度な設定

最後に、軽めのトピックです。ゲストの起動時に、いくつかの高度な設定を調整したい場合があるでしょう。例えば、PAE や OpenGL に関心があるかもしれません。仮想マシンウィザードで適切なオプションにチェックを入れるか、コマンドラインや仮想マシン定義ファイルに精通しているなら、そこに直接必要な文字列を追加しても構いません。

最後に、リストには載っていない追加のヒントとして、GRUB2 を使ったマルチブート環境の構築があります。これは目新しいものではなく、導入記事で触れた内容なので、そちらをご覧ください。

今日はここまでとしましょう。

まとめ

筆者に言わせれば、Python で書かれたツールはどれも、管理者を困らせ、苛立たせるためだけに、極限まで冗長なエラー出力をするよう設計されているように思えます。Xen も例外ではなく、直面している問題についてかなり大量の、しかも洗練されていないメッセージを出力します。少なくとも、決して簡単な話ではありません。

それでも、このチュートリアルが皆さんの役に立てば幸いです。正直に認めますが、ここにはかなりの誤差の余地があります。これらの提案を試してみても、惨敗して怒りと失望を感じるかもしれません。それは、状況によって本当に何百もの異なるシナリオが存在し、それぞれがわずかに異なるからです。それでも、いくつかのヒントは役立つはずです。VNC 切断への対処法、ネットワーク問題の調査方法、各種エラーや設定問題への対応など。それでは、またお会いしましょう。

それでは、良い Xen ライフを！