Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

この付録では、一般的な libvirt- 関連の問題およびエラーと、その対応手順について説明します。
以下の表でエラーを確認し、解決策 の下にある対応するリンクに従ってトラブルシューティング情報を確認してください。

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

Error 問題の概要 ソリューション
libvirtd failed to start libvirt デーモンの起動に失敗しました。ただし、/var/log/messages には、このエラーに関する情報はありません。 「libvirtd が起動しない」
Cannot read CA certificate これは、URI がハイパーバイザーへの接続に失敗した場合に発生するいくつかのエラーの 1 つです。 「URI のハイパーバイザー接続に失敗する」
その他の接続エラー これらは、URI がハイパーバイザーへの接続に失敗した場合に発生する他のエラーです。 「URI のハイパーバイザー接続に失敗する」
ゲストでの PXE ブート（または DHCP）が失敗しました ゲスト仮想マシンは正常に起動するが、DHCP から IP アドレスを取得できず、PXE プロトコルを使用してブートしたり、またはその両方を使用して起動することはできません。これは、ブリッジに設定された転送遅延時間が長くなるか、iptables パッケージとカーネルがチェックサム難号化ルールをサポートしない場合がよくあります。 「ゲスト上の 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 構文および設定の一般的なエラーの詳細を説明します。 「Common 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 接続モードで実行される際に、欠落している cacert.pem ファイルが TLS 認証局として使用されることを示しています。これは、--listen パラメーターが渡されることを意味します。
ソリューション
libvirt デーモンを以下のいずれかの方法で設定します。

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 つ使用してローカルホストに接続します。たとえば、指定すると、virsh がローカルホストの libvirtd の qemu:///system インスタンスに接続するように指示します。system
ホスト名が指定されていると、QEMU トランスポートがデフォルトで TLS に設定されます。これは証明書になります。
接続が未設定
URI は適切ですが (例: qemu[+tls]://server/system)、証明書がマシンで適切に設定されていません。TLS の設定に関する詳細は、アップストリームの libvirt web サイト を参照してください。

A.19.2.2. 'host:16509' でサーバーに接続できません： Connection refused

現象
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 認証が設定されていない可能性があります。
ソリューション
  1. /etc/libvirt/libvirtd.conf ファイルを編集し、auth_tcp パラメーターの値を sasl に設定します。確認するには、以下を実行します。 
    # cat /etc/libvirt/libvirtd.conf | grep auth_tcp
auth_tcp = "sasl"
  2. /etc/sasl2/libvirt.conf ファイルを編集し、以下の行をファイルに追加します。 
    mech_list: digest-md5
sasldb_path: /etc/libvirt/passwd.db
  3. cyrus-sasl-md5 パッケージがインストールされていることを確認します。 
    # yum install cyrus-sasl-md5
  4. libvirtd サービスを再起動します。 
    # systemctl restart libvirtd
  5. 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
ソリューション
  1. /etc/libvirt/libvirt.conf ファイルを編集し、以下の行をファイルに追加します。 
    #unix_sock_group = "libvirt"
#unix_sock_ro_perms = "0777"
#unix_sock_rw_perms = "0770"
  2. 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 インターフェースは役に立ちます。このようなインターフェースのモードをブリッジに設定すると、従来のホストブリッジデバイスの使用に伴う設定の問題（または NetworkManager の非互換性）なしに、非常に簡単な方法でゲストを物理ネットワークに直接接続することができます。
ただし、ゲスト仮想マシンが macvtap などの type='direct' ネットワークインターフェースを使用するように設定されている場合、ネットワーク上の他のゲストや他の外部ホストと通信できなくても、ゲストは独自のホストと通信できません。
この状況は、実際にエラーではなく、macvtap の定義済みの動作です。ホストの物理イーサネットが macvtap ブリッジに割り当てられている方法が原因で、物理インターフェースに転送されるゲストからそのブリッジへのトラフィックは、ホストの IP スタックに送り返されることはありません。さらに、物理インターフェースに送信されたホストの IP スタックからのトラフィックも macvtap ブリッジに送り返されず、ゲストに転送することができません。
ソリューション
libvirt を使って、分離されたネットワークと、このネットワークに接続する各ゲスト仮想マシンの 2 つ目のインターフェースを作成します。これでホストとゲストはこの分離されたネットワーク上で直接通信でき、NetworkManager との互換性も維持できます。

手順A.8 libvirtで分離されたネットワークの作成

  1. 以下の XML を /tmp/isolated.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>
...
  2. virsh net-define /tmp/isolated.xmlコマンドを使用してネットワークを作成します。
  3. virsh net-autostart isolated コマンドを使用して、ネットワークが autostart に設定します。
  4. virsh net-start isolated コマンドを使用してネットワークを起動します。
  5. virsh edit name_of_guest を使用して、ネットワーク接続に macvtap を使用する各ゲストの設定を編集し、以下のような <devices <> > セクションに新しいインターフェースを追加します（ <model type='virtio'/> 行は任意です）。

    図A.4 インターフェースデバイス XML

    
...
<interface type='network' trustGuestRxFilters='yes'>
  <source network='isolated'/>
  <model type='virtio'/>
</interface>
  6. 各ゲストをシャットダウンし、再起動します。
これでゲストは 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> 定義で指定されたブリッジデバイスが存在しないことを示しています。
エラーメッセージで表示されたブリッジデバイスが存在しないことを確認するには、shell コマンド 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 共有ストレージのセットアップ

  1. ホスト上に共有ストレージとして機能する NFS サーバーをセットアップします。関連するすべてのホストが NFS 経由で共有ストレージにアクセスしている限り、NFS サーバーには移行関連のいずれかのホストを使用できます。 
    # mkdir -p /exports/images
# cat >>/etc/exports <<EOF
/exports/images    192.168.122.0/24(rw,no_root_squash)
EOF
  2. 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. Common XML エラー

libvirt ツールは XML ドキュメントを使用して構造化データを保存します。XML ドキュメントで、API 経由で libvirt に渡されると、さまざまな典型的なエラーが発生します。いくつかの一般的な XML エラー： エラーのある XML タグ、不適切な値、および要素がありません。以下に詳しく記載します。

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

推奨されていませんが、ゲスト仮想マシンの XML ファイル（またはドメインの 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 要素によって追加される 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. ドキュメントにある stray <
現象
以下のエラーが発生する。 
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 つの条件が含まれています。
最後のコロン、クロックライン 16 およびドメインに続くメッセージは 、<clock> がドキュメントの 16 行目に一致しないタグが含まれていることを表しています。最後のヒントは、メッセージのコンテキスト部分のポインターで、2 番目のバックオフタグを識別します。
切断されたタグは、/> で閉じられている必要があります。以下のスニペットはこのルールに従いておらず、上記のエラーメッセージを生成しました。 
<domain type='kvm'>
  ...
    <clock offset='utc'>
このエラーは、ファイル内の XML タグの不一致が原因で発生します。すべての XML タグには、一致する start および end タグが必要です。
一致しない他の 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 エラーがハイライトされています。この場合、単語タイプ内の余分な空白があり、ポインターがあります。 
<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 の変更が行われているものもあります。
ソリューション
edit または define コマンドに渡する前に XML 入力を検証します。libvirt 開発者は、libvirt で使用される XML ドキュメントで許容可能なコンストラクトの大半を定義する libvirt とバンドルされた XML スキーマのセットを維持します。
以下のコマンドを使用して、libvirt XML ファイルを検証します。 
# virt-xml-validate libvirt.xml
このコマンドにパスすると、libvirt は、特定のハイパーバイザーでのみ有効なオプションを検出できない場合には、libvirt が XML からのすべてのコンストラクトを認識する可能性が高くなります。たとえば、libvirt が生成した XML が、virsh dump コマンドで生成した 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' を使用します。