KVMのよくある問題を解決する7つのトラブルシューティング術

以前、Xenを使った環境構築で遭遇しやすい典型的な問題を取り上げたトラブルシューティング記事を2本お届けしました。今回は同じテーマをKVMで扱います。

個人的には、KVMはPython由来の冗長なエラーメッセージや全体的な複雑さという点でXenよりはるかに洗練されていると感じています。それでも、作業を難しくする厄介なエラーに遭遇することはあります。このチュートリアルでは、そうしたエラーへの対処法、設定やセットアップ時の競合の特定方法、そしてその他の便利なテクニックを紹介します。それでは始めましょう。

ヒント1: ブリッジネットワークインターフェースが表示されない

自作したbr0というカスタムブリッジデバイスを使いたいとします。しかし、ゲストにこのインターフェースを使用させようとしても、Virtual Machine Managerのドロップダウンメニューに表示されないことがあります。下の画像は逆のケースですが、目的のデバイスが利用可能なアダプター一覧に現れない状況を想像してください。これは実際に起こり得ることで、筆者自身も目撃したことがあります。

解決策は非常にシンプルです。ドメインの設定ファイルを手動で編集しましょう。KVMはデフォルトで/etc/kvm/vmまたは/etc/libvirt/qemuのいずれかにファイルを保存するため、XMLファイルはそこにある可能性が高いです。該当ファイルを開き、<source bridge>以下のブリッジアダプター情報を手動で変更してください。ファイルを保存して仮想マシンを起動すれば完了です。

<interface type='bridge'>
    <source bridge='br0'/>
    <mac address='52:54:00:0d:e6:4a'/>
</interface>

ヒント2: biosdevnameによるネットワーク接続不能

biosdevnameは、BIOSが割り当てた名前をデバイスに付与するユーティリティです。命名の一貫性を保ち、特にネットワークデバイスのハードウェア管理ロジックを簡素化します。独自の機能を持つNICを多数搭載している場合、汎用的なethX名では識別が困難ですが、固有の文字列が付与されれば、1Gbpsと10Gbpsのアダプターなどを容易に区別できます。もちろん、これは主にエンタープライズシステム向けの機能であり、家庭環境ではほぼ縁のない悩みでしょう。

しかし、biosdevnameには副作用があります。KVMで作成した仮想マシンのゲストOS内で使用すると、仮想化されたデバイスに実機とは一致しない物理的な名前が割り当てられ、結果としてネットワークに接続できなくなることがあります。

回避策はいくつかあります。第一に、一部のバージョンは仮想環境内で起動されたことを検出し、何も変更せずに終了します。第二に、GRUBメニューでカーネル引数biosdevname=0を渡すと、ユーティリティの実行を無効化できます。

第三の選択肢は、ネットワークカードの命名に使われるudevルールを直接編集することです。以下は非常に初歩的な例で、単一NICのマシン向けです。複数枚挿しなら、コメント文にあるようにルールごとに個別の行を作成するなど、より動的なロジックが必要になります。

従来型の命名に戻すには、次のように手動で編集します。

vi /etc/udev/rules.d/70-persistent-net.rules

NAMEの値を"eth_biosname"から"ethX"など必要な名前に置き換えます。

# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth_biosname"

# PCI device ...
SUBSYSTEM=="net", ACTION=="add", ATTR(type)=="1",
KERNEL=="eth*", NAME="eth0"

仮想マシンで使用する仮想ハードウェアによってルールの内容は異なります。Realtek、e1000、virtioなどを選択した場合、それぞれ異なる文字列が生成されます。自分の環境に合った解決策を適用するよう注意してください。

ヒント3: 「ドメインが既に存在する」エラー

新しいドメインを定義しようとしたら既に存在するとエラーが出るのに、設定ファイルも宣言も見つけられない——そんな経験はありませんか?virsh listにも表示されず、virt-managerのどこにも現れない。さて、どうすればいいのでしょうか?

virsh define machine.xml
error: Failed to define domain from machine.xml
error: operation failed: domain 'machine' already exists
with uuid 883ab02f-1a67-7430-ef9a-2b59af52210e7

設定ファイルを見つけて削除し、libvirtdサービスを再起動する必要があります。

updatedb
locate machine.xml
rm <machine.xmlへのフルパス>
/etc/init.d/libvirtd restart

ヒント4: 内部エラー「cgroupが見つかりません」

この問題は、上記の例のようにlibvirtdの再起動後に現れることもあれば、まったく無関係なタイミングで発生することもあります。完全なエラーメッセージは次のようなものです。

virsh create machine.xml
error: Failed to create domain from machine.xml
error: internal error Unable to find cgroup for machine

Bugzillaレポートによればsystemd関連である可能性がありますが、systemdを使用していない真っ新なマシンでも発生することがあります。多くの場合、原因はcgroupsとlibvirtdの間の不恰好な競合状態です。libvirtdサービスがcgroupsより先に起動したり、cgroupsのいずれかが削除済みだったり、そもそも存在しなかったりすることで引き起こされます。

解決するには、libvirtdの設定ファイル/etc/libvirt/qemu.confを編集します。このファイル内のcgroups_controllersディレクティブを編集し、cgroupsを一切列挙しないようにすれば、libvirtdはcgroupsなしで動作できるようになります。

cgroups_controllers = [ ]

その後、再度libvirtdを再起動してください。あるいは、必要なcgroupsを手動で作成し、libvirtdプロセスを適切なサブシステムに割り当てる方法もあります。

ヒント5: 停止・再起動時に仮想マシンがVMMから消える

実はこれは非常にシンプルな問題かもしれません。仮想マシンをhaltまたはrebootすると、コンソールが閉じてしまうのです。設定自体は正しいのに、マシン管理のサイクルに介入しなければならず、大きな不便となります。

仮想マシンのXMLファイル内のon_reboot句を探し、アクションがdestroyではなくrestartに設定されていることを確認してください。これだけです。

<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>

ヒント6: 再起動アクションが効かない「サポートされていない関数」エラー

前のヒントと密接に関連しています。restartではなくrebootを指定すると、KVMが実行できない無効なコマンドだと分かります。その際、おそらく次のようなエラーを目にすることになるでしょう。

libvirtError: this function is not supported by the hypervisor: virDomainReboot

restartを使えば、すべて正常に動作します。

ヒント7: インストール後のブートローダーエラー

外部メディアからのインストール後の最初の再起動で、GRUBエラー(おそらく15番)が表示されることがあります。これは、CD/DVDイメージを仮想マシンに接続したまま、XMLファイルで第一ブートデバイスに指定している場合に起こりえます。一部のLinuxディストリビューションに影響するVirtualBoxのバグと似た問題です。例えば:

root (hd0,1)
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz

Error 15: File not found

Press any key to continue...

ISOイメージをアンマウントしてゲストを再起動すれば解決します。今度は正常に起動するはずです。なお、ハードディスクを第一ブートデバイスに設定していれば、この問題は発生しません。ディスク上に有効なパーティションテーブルが見つからない場合(インストール直後ならまさにその状態)、KVMは自動的にPXEやCD/DVDといった第二のソースへスキップするためです。

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

関連記事

以下のKVM関連記事も参考になるかもしれません。

KVMのストレージ・ネットワークガイド、およびブリッジネットワーキング

KVM + VirtualBoxの併用ハウツー

KVMクローン作成ガイド

まとめ

初めてのトラブルシューティングガイドとして6つのヒント、まずまずの出来だと思います。このチュートリアルでは、ブリッジネットワークの設定、biosdevnameへの対処、cgroupsとlibvirtdの問題、virt-managerが自動作成した重複ドメインの登録解除、そしてゲストOSの再起動に関する問題の解決方法を扱いました。

作業の大部分は、設定ファイルの編集とサービスの再起動で完結します。GUIに頼らないのは、コマンドラインに変換できる操作はすべてスクリプト化でき、より簡単で完全自動化された管理につながるからです。いかがでしたか?続編のアイデアがあれば、ぜひ教えてください。

それでは。