A.19. 一般的な libvirt エラーおよびトラブルシューティング

この付録では、libvirt 関連の一般的な問題とエラーおよびそれらの対処法について説明します。

以下の表でエラーを特定し、Solution (解決法) の対応するリンク先で詳細なトラブルシューティング情報を参照してください。

表A.1 一般的な libvirt エラー

エラー	問題の概要	解決法
`libvirtd failed to start`	libvirt デーモンがスタートに失敗するが、`/var/log/messages` にはこのエラーに関する情報がない。	「libvirtd が起動しない」
`Cannot read CA certificate`	URI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。	「URI のハイパーバイザー接続に失敗する」
Other connectivity errors	URI がハイパーバイザー接続に失敗する際に発生するその他のエラーです。	「URI のハイパーバイザー接続に失敗する」
PXE boot (or DHCP) on guest failed	ゲスト仮想マシンは正常にスタートするが、DHCP から IP アドレスを取得できない、または PXE を使用したブートができない、もしくはその両方。この原因は多くの場合、ブリッジでの転送遅延時間が長く設定されているか、iptables パッケージとカーネルがチェックサム難号化ルールをサポートしないためです。	「ゲスト上の PXE ブート (または DHCP ) が失敗」
Guest can reach outside network, but cannot reach host when using macvtap interface	ゲストは他のゲストと通信できるが、macvtap (または `type='direct'`) ネットワークインターフェース使用の設定後にはホストに接続できない。この状況は、実際にはエラーではなく macvtap の定義済み動作です。	「ゲストは外部ネットワークにアクセスできるが、macvtap インターフェースの使用時にはホストにアクセスできない」
`Could not add rule to fixup DHCP response checksums on network 'default'`	この警告メッセージはほとんどの場合、いずれの影響もありませんが、間違って問題の証拠と見なされることが多くあります。	「Could not add rule to fixup DHCP response checksums on network 'default'」
`Unable to add bridge br0 port vnet0: No such device`	このエラーメッセージと、同様の `Failed to add tap interface to bridge 'br0': No such device` というメッセージは、ゲストの (またはドメインの) `<interface>` 定義で指定されたブリッジデバイスが存在しないことを示しています。	「Unable to add bridge br0 port vnet0: No such device」
`Unable to resolve address name_of_host service '49155': Name or service not known`	QEMU ゲストマイグレーションが失敗し、このエラーメッセージが知らないホスト名とともに表示される。	「移行時にエラーが発生: `error: unable to resolve address`」
`Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory`	libvirt がディスクイメージにアクセスできないため、ゲスト仮想マシンを移行できない。	「移行時にエラーが発生: `Unable to allow access for disk path: No such file or directory`」
No guest virtual machines are present when libvirtd is started	libvirt デーモンは正常にスタートしたが、`virsh list --all` を実行してもゲスト仮想マシンが見当たらない	「libvirtd の開始時に存在するゲスト仮想マシンがない」
Common XML errors	libvirt は XML ドキュメントを使用して構造化データを保存します。XML ドキュメントのエラーのいくつかは、XML ドキュメントが API で libvirt に渡される際に発生します。このエントリーでは、ゲスト XML 定義の編集に関する指示と、XML 構文および設定における一般的なエラーの詳細を提供します。	「一般的な XML エラー」

A.19.1. libvirtd が起動しない

現象

libvirt デーモンが自動的に起動しない。libvirt デーモンを手作業で起動することもできない。

# systemctl start libvirtd.service
* Caching service dependencies ...                                                                                             [ ok ]
* Starting libvirtd ...
/usr/sbin/libvirtd: error: Unable to initialize network sockets. Check /var/log/messages or run without --daemon for more info.
* start-stop-daemon: failed to start `/usr/sbin/libvirtd'                                                                      [ !! ]
* ERROR: libvirtd failed to start

さらに、/var/log/messages にはこのエラーに関する 'more info' がない。

調査

以下の行を有効にして、libvirt's のロギングを /etc/libvirt/libvirtd.conf で変更します。行の設定を有効にするには、テキストエディターで /etc/libvirt/libvirtd.conf ファイルを開き、以下の行の始めにあるハッシュ記号 (#) を削除して変更を保存します。

log_outputs="3:syslog:libvirtd"

注記

この行は、libvirtが過剰なログメッセージを作成しないように、デフォルトではコメントアウトされています。問題の診断後には、/etc/libvirt/libvirtd.conf ファイルでこの行を再度コメントすることが推奨されます。

libvirt を再起動して、問題が解決されたかを判断します。

libvirtd がまだ正常に開始されない場合には、以下と同様のエラーが表示されます。

# systemctl restart libvirtd
Job for libvirtd.service failed because the control process exited with error code. See "systemctl status libvirtd.service" and "journalctl -xe" for details.

Sep 19 16:06:02 jsrh libvirtd[30708]: 2017-09-19 14:06:02.097+0000: 30708: info : libvirt version: 3.7.0, package: 1.el7 (Unknown, 2017-09-06-09:01:55, js
Sep 19 16:06:02 jsrh libvirtd[30708]: 2017-09-19 14:06:02.097+0000: 30708: info : hostname: jsrh
Sep 19 16:06:02 jsrh libvirtd[30708]: 2017-09-19 14:06:02.097+0000: 30708: error : daemonSetupNetworking:502 : unsupported configuration: No server certif
Sep 19 16:06:02 jsrh systemd[1]: libvirtd.service: main process exited, code=exited, status=6/NOTCONFIGURED
Sep 19 16:06:02 jsrh systemd[1]: Failed to start Virtualization daemon.

-- Subject: Unit libvirtd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit libvirtd.service has failed.
--
-- The result is failed.

libvirtd の manページには、libvirt が Listen for TCP/IP connections モードで実行されているときに、存在しない cacert.pem ファイルが TLS の認証局として使用されることが記載されています。これは、--listen パラメーターが渡されることを意味します。

解決法

libvirt デーモンを以下のいずれかの方法で設定します。

CA 証明書をインストールする。
注記
CA 証明書およびシステム認証の設定に関する詳細は、『『Red Hat Enterprise Linux 7 ドメイン ID、認証、およびポリシーガイド』』の証明書と認証局の管理に関する章を参照してください。
TLS は使用せずに TCP を使用してください。/etc/libvirt/libvirtd.conf で、listen_tls = 0 および listen_tcp = 1 を設定します。デフォルトの値は listen_tls = 1 および listen_tcp = 0 です。
--listen パラメーターを渡さないでください。/etc/sysconfig/libvirtd.conf で LIBVIRTD_ARGS 変数を変更してください。

A.19.2. URI のハイパーバイザー接続に失敗する

サーバーへの接続時にいくつかの異なるエラーが発生する (例: virsh の実行時) 。

A.19.2.1. CA 証明書を読み込めない

現象

コマンドの実行中に、以下のエラー (または同様のエラー) が表示される。

$ virsh -c qemu://$hostname/system_list
error: failed to connect to the hypervisor
error: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory

調査

このエラーメッセージは、実際の原因に関して誤解を招くものです。このエラーは、誤って指定された URI や未設定の接続など様々な要素によって起こり得ます。

解決法

誤って指定された URI: qemu://system または qemu://session を接続 URI として指定すると、virsh がそれぞれホスト名の system または session に接続しようとします。これは、virsh が 2 つ目の前方スラッシュの後にあるテキストをホストとして認識するためです。
前方スラッシュを 3 つ使用してローカルホストに接続します。たとえば、qemu:///system を指定すると、ローカルホストの libvirtd の system インスタンスに接続するよう virsh を指示します。
ホスト名が指定されている場合、QEMU トランスポートのデフォルトは TLS になります。これは証明書になります。
接続が未設定: URI は適切ですが (例: qemu[+tls]://server/system)、証明書がマシンで適切に設定されていません。TLS の設定に関する情報は、アップストリームの libvirt の Web サイトを参照してください。

A.19.2.2. 「host:16509」でサーバーに接続できず、接続が拒否される。

現象

libvirtd 接続で TCP ポートをリッスンしている間に、接続が失敗する。

# virsh -c qemu+tcp://host/system
error: failed to connect to the hypervisor
error: unable to connect to server at 'host:16509': Connection refused

libvirt デーモンは、/etc/libvirt/libvirtd.conf で設定を変更した後も TCP ポートでリッスンしていません。

# grep listen_ /etc/libvirt/libvirtd.conf
listen_tls = 1
listen_tcp = 1
listen_addr = "0.0.0.0"

しかし、libvirt の TCP ポートは設定変更後も開いたままです。

# netstat -lntp | grep libvirtd
#

調査

libvirt デーモンは --listen オプションなしで開始されました。以下のコマンドを実行してこれを確認します。

# ps aux | grep libvirtd
root     10749  0.1  0.2 558276 18280 ?        Ssl  23:21   0:00 /usr/sbin/libvirtd

出力には --listen オプションは含まれません。

解決法

--listen オプションを使用してデーモンを起動します。

これを行うには、/etc/sysconfig/libvirtd ファイルを編集し、以下の行をコメント解除します。

# LIBVIRTD_ARGS="--listen"

次に、以下のコマンドで libvirtd サービスを再起動します。

# /bin/systemctl restart libvirtd.service

A.19.2.3. 認証失敗

現象

コマンドの実行中に、以下のエラー (または同様のエラー) が表示される。

$ virsh -c qemu://$hostname/system_list
error: failed to connect to the hypervisor
error: authentication failed: authentication failed

調査

正しい認証情報を使用しても認証が失敗する場合は、SASL 認証が設定されていない可能性があります。

解決法

/etc/libvirt/libvirtd.conf ファイルを編集し、auth_tcp パラメーターの値を sasl に設定します。検証するには、次のコマンドを実行します。
```
# cat /etc/libvirt/libvirtd.conf | grep auth_tcp
auth_tcp = "sasl"
```
/etc/sasl2/libvirt.conf ファイルを編集し、次の行をファイルに追加します。
```
mech_list: digest-md5
sasldb_path: /etc/libvirt/passwd.db
```
cyrus-sasl-md5 パッケージがインストールされていることを確認します。
```
# yum install cyrus-sasl-md5
```
libvirtd サービスを再開します。
```
# systemctl restart libvirtd
```
libvirt SASL のユーザー名とパスワードを設定します。
```
# saslpasswd2 -a libvirt 1
```

A.19.2.4. パーミッション拒否

現象

virsh コマンドを非 root ユーザーとして実行中に、以下のエラー (または同様のエラー) が表示されます。

$ virsh -c qemu://$hostname/system_list
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
error: failed to connect to the hypervisor

解決法

/etc/libvirt/libvirt.conf ファイルを編集し、以下の行をファイルに追加します。
```
#unix_sock_group = "libvirt"
#unix_sock_ro_perms = "0777"
#unix_sock_rw_perms = "0770"
```
libvirtd サービスを再開します。
```
# systemctl restart libvirtd
```

A.19.3. ゲスト上の PXE ブート (または DHCP ) が失敗

現象

ゲスト仮想マシンは正常に起動するが、DHCP から IP アドレスを取得できないか、PXE プロトコルを使用してブートを実行できない、またはその両方。このエラーには、ブリッジの転送遅延時間が長く設定されている場合と iptables パッケージとカーネルがチェックサムの難号化 (mangle) 規則をサポートしない場合という 2 つの一般的な原因があります。

ブリッジの転送遅延時間が長い

調査

これは、このエラーの最も一般的な原因になります。ゲストのネットワークインターフェースが STP (Spanning Tree Protocol) 対応のブリッジデバイスに接続しており、かつ長時間の転送遅延時間が設定されていると、ゲストがブリッジに接続してからその転送遅延時間が経過してからでなければゲスト仮想マシンからブリッジにネットワークパケットを転送しません。この遅延により、インターフェースからのトラフィックの監視、背後での MAC アドレスの決定、ネットワークトポロジー内の転送ループ防止がブリッジ時間で可能になります。

転送遅延がゲストの PXE や DHCP クライアントのタイムアウトよりも長い場合、クライアントの操作は失敗し、ゲストは (PXE の場合) 起動に失敗するか、または (DHCP の場合) IP アドレスの取得に失敗します。

解決法

これが原因の場合は、ブリッジにおける転送遅延を 0 に変更するか、ブリッジの STP を無効にするか、またはこの両方を実行します。

注記

この解決法は、ブリッジが複数のネットワーク接続に使用されておらず、複数のエンドポイントを単一のネットワーク接続のみに使用されている場合にのみ適用されます (libvirt で使用される最も一般的なブリッジのユースケース)。

ゲストに libvirt が管理する仮想ネットワークに接続するインターフェースがある場合、そのネットワークの定義を編集し、再起動します。たとえば、以下のコマンドでデフォルトのネットワークを編集します。

# virsh net-edit default

<bridge> 要素に以下の属性を追加します。

<name_of_bridge='virbr0' delay='0' stp='on'/>

注記

delay='0' および stp='on' は仮想ネットワークのデフォルト設定なので、このステップは設定がデフォルトから変更されている場合にのみ必要となります。

ゲストインターフェースが、libvirt の外部で設定されたホストブリッジに接続されている場合、遅延設定を変更します。

/etc/sysconfig/network-scripts/ifcfg-name_of_bridge ファイルにある以下の行を追加または編集し、0 秒の遅延で STP を有効にします。

STP=on DELAY=0

設定ファイルの変更後にブリッジデバイスを再起動します。

/usr/sbin/ifdown name_of_bridge
/usr/sbin/ifup name_of_bridge

注記

name_of_bridge がネットワークのルートブリッジでない場合、そのブリッジの遅延は最終的にルートブリッジに設定された遅延時間に再設定されます。この発生を防ぐには、name_of_bridge の STP を無効にします。

iptables パッケージとカーネルがチェックサム難号化ルールをサポートしない場合

調査

このメッセージは、以下の 4 つの条件すべてが該当する場合にのみ問題となります。

ゲストが virtio ネットワークデバイスを使用している。
その場合、設定ファイルに model type='virtio' が含まれています。
ホストに vhost-net モジュールがロードされている。
ls /dev/vhost-net を実行して空の結果が返されなければ、このモジュールはロードされています。
ホスト上で直接実行中の DHCP サーバーからホストが IP アドレスを取得しようとしている。
ホストの iptables のバージョンが 1.4.10 よりも古い。
iptables 1.4.10 は libxt_CHECKSUM 拡張を追加する最初のバージョンでした。libvirtd のログに以下のメッセージが記録されている場合は、これよりも古いバージョンになります。
```
warning: Could not add rule to fixup DHCP response checksums on network default
warning: May need to update iptables package and kernel to support CHECKSUM rule.
```
重要
この一覧の最初の 3 つの条件すべてが該当していなければ上記の警告メッセージは問題を示すものではなく、無視することができます。

これらの条件が当てはまる場合、ホストからゲストへ送信される UDP パケットには未算出のチェックサムがあります。これにより、ホストの UDP パケットがゲストのネットワークスタックには無効のように表示されます。

解決法

この問題を解決するには、上記の 4 つの条件のいずれかを無効にします。最善の解決法は、可能であればホストの iptables およびカーネルを iptables-1.4.10 もしくはそれ以降に更新することです。これ以外では、このゲストの vhost-net ドライバーを無効にするのが最も的確な修正方法になります。これには、以下のコマンドでゲスト設定を編集します。

virsh edit name_of_guest

<driver> の行を変更するか、<interface> セクションに追加します。

<interface type='network'>
  <model type='virtio'/>
  <driver name='qemu'/>
  ...
</interface>

変更を保存し、ゲストをシャットダウンしてから再起動します。

それでもこの問題が解決しない場合、firewalld とデフォルトの libvirt ネットワークとの競合が原因である場合があります。

これを修正するには、service firewalld stop コマンドで firewalld を停止した後に、service libvirtd restart コマンドで libvirt を再起動します。

注記

さらに、/etc/sysconfig/network-scripts/ifcfg-network_name ファイルが正しく設定されている場合は、ゲストの root で dhclient コマンドを実行すれば、ゲストが IP アドレスを確実に取得できます。

A.19.4. ゲストは外部ネットワークにアクセスできるが、macvtap インターフェースの使用時にはホストにアクセスできない

現象

ゲストは他のゲストと通信できるが、macvtap (または type='direct') ネットワークインターフェースを使用するように設定された後にはホストマシンに接続できない。

調査

Virtual Ethernet Port Aggregator (VEPA) や VN-Link 対応スイッチに接続していない場合でも、macvtap インターフェースは役に立ちます。インターフェースのモードを bridge に設定すると、非常に簡単な方法でゲストを物理ネットワークに直接接続することができます。この場合、従来のホストブリッジデバイスの使用に伴う設定の問題 (または NetworkManager の非互換性) がありません。

しかし、ゲスト仮想マシンが macvtap などの type='direct' ネットワークインターフェースを使用するように設定されていると、ネットワーク上で他のゲストや他の外部ホストと通信する機能がありながら、ゲストは自分のホストと通信できなくなります。

この状況は、実際にはエラーではなく macvtap の定義済みの動作です。ホストの物理イーサネットが macvtap ブリッジに割り当てられている方法が原因で、物理インターフェースに転送されるゲストからそのブリッジへのトラフィックは、ホストの IP スタックに送り返されることはありません。さらに、物理インターフェースに送信されたホストの IP スタックからのトラフィックも macvtap ブリッジに送り返されず、ゲストに転送することができません。

解決法

libvirt を使って、分離されたネットワークと、このネットワークに接続する各ゲスト仮想マシンの 2 つ目のインターフェースを作成します。これでホストとゲストはこの分離されたネットワーク上で直接通信でき、NetworkManagerとの互換性も維持できます。

手順A.8 libvirt で分離されたネットワークを作成します。

以下の XML を /tmp/isolated.xml ファイルに追加して保存します。自分のネットワーク上で 192.168.254.0/24 が既に使われている場合、別のネットワークを選びます。
```
...
<network>
  <name>isolated</name>
  <ip address='192.168.254.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.254.2' end='192.168.254.254'/>
    </dhcp>
  </ip>
</network>
...
```
図A.3 隔離されたネットワーク
virsh net-define /tmp/isolated.xml コマンドを使用して、ネットワークを作成します。
virsh net-autostart isolated コマンドを使用して、ネットワークが自動起動するように設定します。
virsh net-start isolated コマンドを使用して、ネットワークを起動します。
virsh edit name_of_guest を使用して、ネットワークの接続に macvtap を使用する各ゲストの設定を編集し、以下のように <devices> セクションに新しい <interface> を追加します (<model type='virtio'/> の行は任意です)。
```
...
<interface type='network' trustGuestRxFilters='yes'>
  <source network='isolated'/>
  <model type='virtio'/>
</interface>
```
図A.4 インターフェースデバイス XML
各ゲストをシャットダウンし、再起動します。

これでゲストは 192.168.254.1 のアドレスにあるホストにアクセスでき、ホストは各ゲストが DHCP から取得した IP アドレスでゲストにアクセスできます (または、ゲストに手動で IP アドレスを設定することもできます) 。この新たなネットワークはこのホストとゲスト専用に分離されているので、ゲストからの他の通信はすべて macvtap インターフェースを使用することになります。詳細は「ネットワークインターフェース」を参照してください。

A.19.5. Could not add rule to fixup DHCP response checksums on network 'default'

現象

以下のメッセージが表示されます。

Could not add rule to fixup DHCP response checksums on network 'default'

調査

このメッセージはエラーに見えますが、ほとんどの場合問題ありません。

解決法

ゲスト仮想マシンが DHCP から IP アドレスを取得できないという問題が発生していない限り、このメッセージは無視してかまいません。

このような場合の詳細は「ゲスト上の PXE ブート (または DHCP ) が失敗」を参照してください。

A.19.6. Unable to add bridge br0 port vnet0: No such device

現象

以下のエラーメッセージが表示されます。

Unable to add bridge name_of_bridge port vnet0: No such device

たとえば、ブリッジの名前が br0 の場合、エラーメッセージは以下のようになります。

Unable to add bridge br0 port vnet0: No such device

libvirt のバージョンが 0.9.6 以下の場合、以下と同じエラーが表示されます。

Failed to add tap interface to bridge name_of_bridge: No such device

たとえば、ブリッジの名前が br0 の場合、エラーは次のようになります。

Failed to add tap interface to bridge 'br0': No such device

調査

いずれのエラーメッセージも、ゲストの (またはドメインの) <interface> 定義で指定されたブリッジデバイスが存在しないことを示しています。

エラーメッセージで表示されたブリッジデバイスが存在しないことを確認するには、シェルコマンドip addr show br0 を使います。

以下のようなメッセージが表示されると、その名前のブリッジが存在しないことが確認できます。

br0: error fetching interface information: Device not found

存在しない場合は、解決法に進みます。

ただし、メッセージが以下のようであれば、問題は別に存在します。

br0        Link encap:Ethernet  HWaddr 00:00:5A:11:70:48
           inet addr:10.22.1.5  Bcast:10.255.255.255  Mask:255.0.0.0
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:249841 errors:0 dropped:0 overruns:0 frame:0
           TX packets:281948 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
	   RX bytes:106327234 (101.4 MiB)  TX bytes:21182634 (20.2 MiB)

解決法

virsh で既存のブリッジを編集または新規ブリッジを作成

virsh を使って既存のブリッジもしくはネットワークの設定を編集するか、ブリッジデバイスをホストシステム設定に追加します。

virsh を使った既存ブリッジ設定の編集

virsh edit name_of_guest を使用して、既存のブリッジまたはネットワークを使用するように <interface> 定義を変更します。

たとえば、type='bridge' を type='network' に変更し、<source bridge='br0'/> を <source network='default'/> に変更します。

virsh を使用したホストブリッジの作成

libvirt のバージョン 0.9.8 以上では、virsh iface-bridge コマンドでブリッジデバイスを作成できます。以下のコマンドは、ブリッジの一部として設定される物理ネットワーク eth0 が接続されたブリッジデバイス br0 を作成します。

virsh iface-bridge eth0 br0

任意手順: 必要な場合は、以下のコマンドを使用して、ブリッジを削除し、元の eth0 設定を復元します。

virsh iface-unbridge br0

ホストブリッジを手動で作成

以前のバージョンの libvirt では、手作業でブリッジデバイスをホストで作成することが可能です。手順については「libvirt を使用したブリッジネットワーク」を参照してください。

A.19.7. 移行時にエラーが発生: `error: unable to resolve address`

現象

QEMU ゲストの移行が失敗し、以下のエラーメッセージが表示される。

# virsh migrate qemu qemu+tcp://192.168.122.12/system
  error: Unable to resolve address name_of_host service '49155': Name or service not known

たとえば、移行先のホスト名が newyork の場合、エラーメッセージは以下のようになります。

# virsh migrate qemu qemu+tcp://192.168.122.12/system
error: Unable to resolve address 'newyork' service '49155': Name or service not known

しかし、ホスト名 newyork はどこにも使用していないため、このエラーには違和感があります。

調査

移行時に、移行先ホスト上で稼働している libvirtd は移行データの受信が予想されるアドレスおよびポートから URI を作成し、これを移行元ホスト上で稼働している libvirtd に送信します。

上記の例では、移行先ホスト (192.168.122.12) は名前を 'newyork' に設定していました。何らかの理由で、そのホスト上で実行中の libvirtd は IP アドレスに対して名前を解決できず、送信されるべきものが有効なままとなっています。このため、移行元の libvirtd が名前を解決することを期待して、ホスト名 'newyork' が返されました。DNS が適切に設定されていなかったり、/etc/hosts にローカルループバックアドレス (127.0.0.1) に関連するホスト名があったりすると、このようなことが発生します。

移行データに使用されるアドレスは、移行先 libvirtd への接続に使用されるアドレス (例: qemu+tcp://192.168.122.12/system) から自動的に決定されることはありません。これは、移行先 libvirtd と通信するために、移行元の libvirtd は (別のマシンで実行中かもしれない) virsh が必要とするネットワークインフラストラクチャーとは別のものを使用する必要がある場合があるためです。

解決法

最善の解決法として、DNS を正しく設定し、移行に関連するすべてのホストがすべてのホスト名を解決できるようにすることができます。

DNS をこのように設定できない場合は、各ホスト上の /etc/hosts ファイルに移行に使用するすべてのホストのリストを手動で追加することができます。しかし、ダイナミックな環境ではそのようなリストの一貫性の維持は困難です。

どの方法でもホスト名を解決可能にできない場合、virsh migrate は移行ホストの特定をサポートします。

# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12

移行先の libvirtd は tcp://192.168.122.12 URI を取得し、自動生成されたポート番号を追加します。この番号が望ましくない場合は (たとえば、ファイアウォール設定との関連により適切でない場合)、ポート番号は以下のコマンドで指定できます。

# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12:12345

別のオプションとして、トンネル化した移行を使用することもできます。トンネル化した移行では移行データ用に別の接続を作成しませんが、その代わりに移行先 libvirtd との通信で使用される接続でデータをトンネルします (例: qemu+tcp://192.168.122.12/system)。

# virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled

A.19.8. 移行時にエラーが発生: `Unable to allow access for disk path: No such file or directory`

現象

libvirt がディスクイメージにアクセスできないため、ゲスト仮想マシン (またはドメイン) を移行できない。

# virsh migrate qemu qemu+tcp://name_of_host/system
error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory

たとえば、移行先のホスト名が newyork の場合、エラーメッセージは以下のようになります。

# virsh migrate qemu qemu+tcp://newyork/system
error: Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directory

調査

デフォルトでは、移行で移動するのは実行中のゲストのメモリー内の状態のみです (メモリ−または CPU 状態など)。移行中にはディスクイメージは移動しませんが、両方のホストから同じパスでアクセスできる状態である必要があります。

解決法

両方のホストの同じ位置に共有ストレージをセットアップし、マウントします。最も簡単な方法として、NFS を使用することができます。

手順A.9 共有ストレージのセットアップ

ホスト上に共有ストレージとして機能する NFS サーバーをセットアップします。関連するすべてのホストが NFS で共有ストレージにアクセスしている限り、NFS サーバーには移行関連のいずれかのホストを使用できます。
```
# mkdir -p /exports/images
# cat >>/etc/exports <<EOF
/exports/images    192.168.122.0/24(rw,no_root_squash)
EOF
```
libvirt を実行しているすべてのホスト上の共通の場所にエクスポートされたディレクトリーをマウントします。たとえば、NFS サーバーの IP アドレスが 192.168.122.1 の場合は、以下のコマンドでディレクトリーをマウントします。
```
# cat >>/etc/fstab <<EOF
192.168.122.1:/exports/images  /var/lib/libvirt/images  nfs  auto  0 0
EOF
# mount /var/lib/libvirt/images
```

注記

NFS を使ってホストからローカルディレクトリーをエクスポートし、別のホストの同じパスにマウントすることはできません。ディスクイメージの保存に使われるディレクトリーは、両方のホストで共有ストレージからマウントされる必要があります。これが正確に設定されていない場合、ゲスト仮想マシンは移行時にそのディスクイメージへのアクセスを失う可能性があります。これは、ゲストを移行先に正常に移行した後に、移行元ホストの libvirt デーモンがディスクイメージ上の所有者、権限および SELinux ラベルを変更する可能性があるからです。

libvirt は、ディスクイメージが共有ストレージの場所からマウントされたことを検出すると、これらの変更を実施しません。

A.19.9. libvirtd の開始時に存在するゲスト仮想マシンがない

現象

libvirt デーモンは正常に起動したが、ゲスト仮想マシンが見当たらない。

# virsh list --all
 Id    Name                           State
----------------------------------------------------

調査

この問題の原因としていくつもの原因が考えられます。以下のテストを実施して原因を特定します。

KVM カーネルモジュールの確認

KVM カーネルモジュールがカーネルに挿入されていることを確認する。

# lsmod | grep kvm
kvm_intel             121346  0
kvm                   328927  1 kvm_intel

AMD マシンを使用している場合は、root シェルで同様の lsmod | grep kvm_amd コマンドを使用して、カーネルに kvm_amd カーネルモジュールが挿入されていないか確認します。

モジュールが存在しない場合は、modprobe <modulename> コマンドを使用して挿入します。

注記

一般的ではありませんが、KVM 仮想化サポートがカーネルにコンパイルされている場合もあります。その場合は、モジュールは必要ありません。

仮想化拡張機能の確認

仮想化拡張機能がホスト上でサポートされ、有効にされていることを確認します。

# egrep "(vmx|svm)" /proc/cpuinfo
flags		: fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save
flags		: fpu vme de pse tsc ... svm ... skinit wdt npt lbrv svm_lock nrip_save

BIOS 設定内のファームウェア設定で仮想化拡張機能を有効にします。詳細は、お使いのハードウェアの資料を参照してください。

クライアント URI 設定の確認

クライアントの URI が適切に設定されていることを確認します。

# virsh uri
vbox:///system

たとえば、このメッセージは URI が QEMUではなく VirtualBox ハイパーバイザーに接続されていることを示し、本来は QEMU ハイパーバイザーに接続するように設定されているはずの URI の設定エラーを示しています。URI が QEMU に正常に接続している場合は、メッセージは以下のようになります。

# virsh uri
qemu:///system

他のハイパーバイザーが存在し、libvirt がこのハイパーバイザーとデフォルトで通信する場合に、この状況が発生します。

解決法

これらのテスト実行後に、以下のコマンドでゲスト仮想マシンの一覧を表示します。

# virsh list --all

A.19.10. 一般的な XML エラー

libvirt ツールは XML ドキュメントを使用して構造化データを保存します。XML ドキュメントの様々なエラーは、XML ドキュメントが API で libvirt に渡される際に発生します。一般的な XML エラー (誤りのある XML タグや不適切な値、要素の欠如を含む) のいくつかを以下で詳述します。

A.19.10.1. ドメイン定義の編集

これは推奨されませんが、ゲスト仮想マシン (またはドメイン) の XML ファイルを手動で編集することも時には必要になります。編集目的でゲストの XML にアクセスするには、以下のコマンドを使用します。

# virsh edit name_of_guest.xml

このコマンドで、ゲスト仮想マシンの現在の定義によるファイルがテキストエディターで開かれます。編集して変更を保存した後、XML はリロードされ、libvirt で解析されます。XML が正しければ、以下のメッセージが表示されます。

# virsh edit name_of_guest.xml

Domain name_of_guest.xml XML configuration edited.

重要

virsh で edit コマンドを使用して、XML ドキュメントを編集する際は、エディターを終了する前にすべての変更を保存します。

XML ファイルの保存後に、xmllint コマンドで XML が整形式かどうかを確認します。または、virt-xml-validate コマンドで使用法の問題をチェックします。

# xmllint --noout config.xml

# virt-xml-validate config.xml

エラーが表示されない場合、XML 記述子は整形式で libvirt スキーマに合致しています。スキーマはすべての制約を捕捉しませんが、レポートされたエラーを修正することでトラブルシューティングが促進されます。

libvirt によって格納される XML ドキュメント: これらのドキュメントには、ゲストの状態や設定の定義が含まれています。ドキュメントは自動生成され、手動での編集は推奨されません。ドキュメントにあるエラーには、破損したドキュメントのファイル名が含まれています。このファイル名は、URI によって定義されたホストマシン上でのみ有効で、コマンドが実行されたマシンを参照する場合があります。
libvirtが作成したファイルのエラーはまれにしか発生しません。エラーの原因となりえるのは libvirt のダウングレードです。新しいバージョンの libvirtは、古いバージョンが生成した XML を常に読み込めるのに対して、古いバージョンの libvirt は、新しいバージョンで追加された XML 要素によって混乱する可能性があります。

A.19.10.2. XML 構文エラー

構文エラーは、XML パーサーがキャッチします。エラーメッセージには、問題特定のための情報が含まれています。

以下の例では、XML パーサーからのエラーメッセージは、3 行で構成されています。最初の行はエラーメッセージを表示し、残りの 2 行にはエラーが含まれる XML コードのコンテキストと場所が表示されます。3 行目は、上の行のどこにエラーがあるかおおよその位置を示します。

error: (name_of_guest.xml):6: StartTag: invalid element name
<vcpu>2</vcpu><
-----------------^

このメッセージに含まれている情報

(name_of_guest.xml): これは、エラーを含むドキュメントのファイル名です。括弧内のファイル名は、メモリーから解析された XML ドキュメントを表現する象徴的な名前で、ディスク上のファイルに直接対応するものではありません。括弧内に含まれていないファイル名は、接続先に配置されているローカルファイルです。
6: これは、XML ファイル内でのエラーを含む行番号です。
StartTag: invalid element name: これは libxml2 パーサーからのエラーメッセージで、特定の XML エラーを記述するものです。

A.19.10.2.1. ドキュメントの余分な `<`

現象

以下のエラーが発生する。

error: (name_of_guest.xml):6: StartTag: invalid element name
<vcpu>2</vcpu><
-----------------^

調査

このエラーメッセージは、ゲストの XML ファイルの 6 行目にある < 記号の後に、パーサーが新たな要素名を予測していることを示しています。

テキストエディターの行数表示が有効になっていることを確認します。XML ファイルを開いて、6 行目のテキストをみつけます。

<domain type='kvm'>
   <name>name_of_guest</name>
<memory>524288</memory>
<vcpu>2</vcpu><

ゲストの XML ファイルのこの抜粋には、余分な < が含まれています。

解決法

余分な < を削除するか、新たな要素名を適切に追加します。

A.19.10.2.2. 未終了の属性

現象

以下のエラーが発生する。

error: (name_of_guest.xml):2: Unescaped '<' not allowed in attributes values
<name>name_of_guest</name>
--^

調査

ゲストの XML ファイルのこの抜粋には、未終了要素の属性値が含まれています。

<domain type='kvm>
<name>name_of_guest</name>

このケースでは、'kvm' を閉じる引用符が足りません。XML の開始および終了タグと同様に、属性値は引用符またはアポストロフィで開いたり閉じたりする必要があります。

解決法

すべての属性値の文字列を引用符またはアポストロフィーで適切に開始および終了します。

A.19.10.2.3. 開始および終了タグの不一致

現象

以下のエラーが発生する。

error: (name_of_guest.xml):61: Opening and ending tag mismatch: clock line 16 and domain
</domain>
---------^

調査

上記のエラーメッセージには、問題となっているタグを特定する 3 つのヒントがあります。

最後のコロンの後のメッセージである clock line 16 and domain は、ドキュメントの 16 行目の <clock>にタグの不一致があることを示しています。最後のヒントはメッセージのコンテキスト部分にあるポインターで、これは問題となっている 2 つ目のタグを特定しています。

ペアになっていないタグは /> で閉じる必要があります。以下の抜粋はこのルールを守っていないので、上記のエラーメッセージが表示されました。

<domain type='kvm'>
  ...
    <clock offset='utc'>

このエラーはファイル内の XML タグのミスマッチが原因で発生します。すべての XML タグは、開始および終了タグでマッチする必要があります。

その他の XML タグ不一致の例

以下の例では同様のエラーメッセージが生成され、XML タグのミスマッチの例が示されています。

このスニペットには<features> の不一致によるエラーが含まれています。これは、終了タグである </name> が存在しないことが原因です。

<domain type='kvm'>
 ...
 <features>
   <acpi/>
   <pae/>
 ...
 </domain>

以下のスニペットには、終了タグ </name> のみが存在し、その開始タグがありません。

<domain type='kvm'>
  </name>
  ...
</domain>

解決法

すべての XML タグが正しく開始し、終了していることを確認します。

A.19.10.2.4. よくあるタグのエラー

現象

以下のエラーメッセージが表示されます。

error: (name_of_guest.xml):1: Specification mandate value for attribute ty
<domain ty pe='kvm'>
-----------^

調査

XML エラーは、簡単な誤字脱字で発生します。このエラーメッセージは、XML エラー (このケースでは type という単語の中に余分な空白) をポインターで示しています。

<domain ty pe='kvm'>

以下の XML 例は、特別文字が足りなかったり余分な文字があったりするエラーが理由で正確に解析されません。

<domain type 'kvm'>

<dom#ain type='kvm'>

解決法

問題のあるタグを特定するには、ファイルのコンテキストのエラーメッセージを読んで、ポインターでエラーを見つけます。XML を修正し、変更を保存します。

A.19.10.3. 論理および設定エラー

適切にフォーマットされた XML ドキュメントで構文が正しくても、libvirt が解析できないエラーを含んでいる場合があります。これらのエラーの多くは、以下で説明する 2 つのケースに当てはまります。

A.19.10.3.1. 部分的な消滅

現象

ドメインの編集または定義後に、変更箇所が表示されず、その効果も見られない。define コマンドや edit コマンドは機能するが、XML を再度ダンプすると変更が消えてしまう。

調査

このエラーは、構築または構文が正しくないため libvirt が解析できない場合に発生することが予想されます。libvirt は一般的に、理解できる構築のみを探して他のものはすべて無視するため、libvirt が入力を解析した後に XML 変更が消滅する場合があります。

解決法

XML の入力を検証してから edit または define コマンドに渡します。libvirt の開発者は、libvirt が使用する XML ドキュメントで許可されるほとんどの構築を定義する、libvirt にバンドルされた XML スキーマを維持します。

次のコマンドを使用して libvirt XML ファイルを検証します。

# virt-xml-validate libvirt.xml

このコマンドが渡されると、libvirt が XML からのすべてのコンストラクトを理解します。ただし、特定のハイパーバイザーにのみ有効なオプションをスキーマが検出できない場合は例外です。たとえば、virsh dump コマンドの結果として libvirt によって生成された XML は、エラーなしで検証されます。

A.19.10.3.2. ドライブデバイスの種類の誤り

現象

CD-ROM 仮想ドライブ用のソースイメージの定義を追加したにもかかわらず、見当たらない。

# virsh dumpxml domain
<domain type='kvm'>
  ...
  <disk type='block' device='cdrom'>
    <driver name='qemu' type='raw'/>
    <target dev='hdc' bus='ide'/>
    <readonly/>
  </disk>
  ...
</domain>

解決法

以下のように、見つからない <source> パラメーターを追加して XML を訂正します。

<disk type='block' device='cdrom'>
  <driver name='qemu' type='raw'/>
  <source file='/path/to/image.iso'/>
  <target dev='hdc' bus='ide'/>
  <readonly/>
</disk>

type='block' ディスクデバイスはソースが物理デバイスであることを予想します。イメージファイルのディスクを使用するには、type='file' を代わりに使用します。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。

A.19. 一般的な libvirt エラーおよびトラブルシューティング

A.19.1. libvirtd が起動しない

A.19.2. URI のハイパーバイザー接続に失敗する

A.19.2.1. CA 証明書を読み込めない

A.19.2.2. 「host:16509」でサーバーに接続できず、接続が拒否される。

A.19.2.3. 認証失敗

A.19.2.4. パーミッション拒否

A.19.3. ゲスト上の PXE ブート (または DHCP ) が失敗

A.19.4. ゲストは外部ネットワークにアクセスできるが、macvtap インターフェースの使用時にはホストにアクセスできない

A.19.5. Could not add rule to fixup DHCP response checksums on network 'default'

A.19.6. Unable to add bridge br0 port vnet0: No such device

A.19.7. 移行時にエラーが発生: error: unable to resolve address

A.19.8. 移行時にエラーが発生: Unable to allow access for disk path: No such file or directory

A.19.9. libvirtd の開始時に存在するゲスト仮想マシンがない

A.19.10. 一般的な XML エラー

A.19.10.1. ドメイン定義の編集

A.19.10.2. XML 構文エラー

A.19.10.2.1. ドキュメントの余分な <

A.19.10.2.2. 未終了の属性

A.19.10.2.3. 開始および終了タグの不一致

A.19.10.2.4. よくあるタグのエラー

A.19.10.3. 論理および設定エラー

A.19.10.3.1. 部分的な消滅

A.19.10.3.2. ドライブデバイスの種類の誤り

A.19.7. 移行時にエラーが発生: `error: unable to resolve address`

A.19.8. 移行時にエラーが発生: `Unable to allow access for disk path: No such file or directory`

A.19.10.2.1. ドキュメントの余分な `<`