A.19. 一般的なlibvirtエラーとトラブルシューティング
この付録では、一般的な libvirt 関連の問題とエラー、およびそれらに対処するための手順について説明します。
トラブルシューティングの詳細は、以下の表でエラーを特定し、
Solution
の対応するリンクを参照してください。
エラー | 問題の説明 | 解決方法 |
---|---|---|
libvirtd の起動に失敗しました。 | libvirt デーモンの起動に失敗しました。ただし、/var/log/messages にはこのエラーに関する情報はありません。 | 「libvirtd が起動しない」 |
Cannot read CA certificate | これは、URI がハイパーバイザーに接続できない場合に発生するいくつかのエラーのいずれかになります。 | 「URI のハイパーバイザー接続に失敗する」 |
その他の接続エラー | これは、URI がハイパーバイザーに接続できない場合に発生するその他のエラーです。 | 「URI のハイパーバイザー接続に失敗する」 |
ゲスト上の PXE ブート (または DHCP ) が失敗 | ゲスト仮想マシンは正常に起動しますが、DHCP、PXE プロトコルを使用した起動、またはその両方から IP アドレスを取得することはできません。これは、多くの場合、ブリッジの転送遅延時間が長く設定されている場合、または iptables パッケージとカーネルがチェックサムの難号化 (mangle) 規則をサポートしない場合に発生します。 | 「ゲスト上の PXE ブート (または DHCP ) が失敗」 |
ゲストは外部ネットワークにアクセスできるが、macvtap インターフェイスの使用時にはホストにアクセスできない |
ゲストは他のゲストと通信できますが、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 を表示して移行が失敗する」 |
libvirtd の開始時に存在するゲスト仮想マシンがない | libvirt デーモンは正常に起動しますが、virsh list --all の実行時にゲスト仮想マシンが存在しないように見えます。 | 「libvirtd の起動時に存在するゲスト仮想マシンがない」 |
一般的な XML エラー | libvirt は、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'
はありません。 - 調査
- 以下の行を有効にして、
/etc/libvirt/libvirtd.conf
のlibvirt のログを変更します。この行を有効にするには、テキストエディターで/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 Domain Identity, Authentication, and Policy Guide』 の Managing Certificates および Certificate Authorities の章を参照してください。
- 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. Cannot read CA certificate
- 現象
- コマンドの実行中に、以下のエラー (または同様のエラー) が表示される。
$ 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
- 接続 URI に
qemu://system
またはqemu://session
を指定すると、virsh は、ホスト名のsystem
またはsession
にそれぞれ接続しようとします。これは、virsh が、2 番目のスラッシュの後のテキストをホストとして認識するためです。前方スラッシュを 3 つ使用してローカルホストに接続します。たとえば、qemu:///system
を指定すると、virsh はローカルホストコンピューターの libvirtd のsystem
インスタンスに接続します。ホスト名が指定されていると、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
/etc/libvirt/libvirtd.conf
で設定を変更した後も、libvirt デーモンは 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. Authentication Failed
- 現象
- コマンドの実行中に、以下のエラー (または同様のエラー) が表示される。
$ 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. Permission Denied
- 現象
- root 以外のユーザーで virsh コマンドを実行すると、以下のエラー (または同様のもの) が表示されます。
$ 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 を無効にします。
- iptable パッケージおよびカーネルは、チェックサム難号化ルールをサポートしません。
- 調査
- このメッセージは、以下の 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
ファイルが正しく設定されている場合は、dhclient コマンドを root で使用することで、ゲストが 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 で分離されたネットワークを作成する
/tmp/isolated.xml
ファイルに以下の XML を追加して保存します。自分のネットワーク上で 192.168.254.0/24 がすでに使われている場合、別のネットワークを選びます。図A.3 分離されたネットワーク XML
... <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> ...
- 次のコマンドでネットワークを作成します。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'/>
行はオプションで追加できます)。図A.4 インターフェイスデバイス XML
... <interface type='network' trustGuestRxFilters='yes'> <source network='isolated'/> <model type='virtio'/> </interface>
- 各ゲストをシャットダウンし、再起動します。
これでゲストは 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 を使用することができます。注記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 ハイパーバイザーに接続されていることを示し、URI の設定エラーであることがわかります。本来は QEMU ハイパーバイザーへの接続として設定されているはずです。URI が QEMU に正常に接続している場合は、メッセージは以下のようになります。# virsh uri qemu:///system
他のハイパーバイザーが存在し、libvirt がこのハイパーバイザーとデフォルトで通信する場合に、この状況が発生します。
- 解決方法
- これらのテスト実行後に、以下のコマンドでゲスト仮想マシンのリストを表示します。
# virsh list --all
A.19.10. 一般的な XML エラー
libvirt では、XML ドキュメントを使用して構造化データを保存します。XML ドキュメントが API を介して libvirt に渡されると、さまざまな一般的なエラーが発生します。エラーのある XML タグ、不適切な値、欠落している要素など、一般的な XML エラーの一部を以下に示します。
A.19.10.1. ドメイン定義の編集
これは推奨されていませんが、ゲスト仮想マシン (またはドメインの XML ファイル) を手動で編集することが必要になる場合があります。ゲストの XML にアクセスして編集するには、次のコマンドを使用します。
# virsh edit name_of_guest.xml
このコマンドは、ゲスト仮想マシンの現在の定義を持つテキストエディターでファイルを開きます。編集を終了して変更を保存したら、libvirt により XML が再読み込みされ、解析されます。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 が作成したファイルでエラーが発生することはまれです。ただし、このエラーの原因の 1 つとして、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: 無効な要素名
- これは、特定の XML エラーを説明するlibxml2パーサーからのエラーメッセージです。
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'
に 2 番目の引用符が欠けています。属性値は、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
は、<clock>
にはドキュメントの 16 行目に一致しないタグが含まれていることを示しています。最後のヒントは、メッセージのコンテキスト部分のポインターで、2 番目の問題のあるタグを識別します。ペアになっていないタグは、/>
で閉じる必要があります。以下のスニペットはこのルールに従わず、上記のエラーメッセージが表示されます。<domain type='kvm'> ... <clock offset='utc'>
このエラーは、ファイル内で XML タグが一致しないために発生します。すべての XML タグに、一致する開始タグと終了タグが必要です。- 以下の例では、同様のエラーメッセージと、一致しない XML タグのバリエーションを示しています。終了タグ (
</name>
) がないため、このスニペットに<features>
の不一致エラーが含まれています。<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'
を使用します。