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

この付録では、libvirt 関連の一般的な問題とエラーおよびそれらの対処法について説明します。
以下の表でエラーを特定し、Solution (解決法) の対応するリンク先で詳細なトラブルシューティング情報を参照してください。

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

エラー問題の概要解決法
libvirtd failed to startlibvirt デーモンがスタートに失敗するが、/var/log/messages にはこのエラーに関する情報がない。「libvirtd が起動しない」
Cannot read CA certificateURI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。「URI のハイパーバイザー接続に失敗する」
Other connectivity errorsURI がハイパーバイザー接続に失敗する際に発生するその他のエラーです。「URI のハイパーバイザー接続に失敗する」
Failed to create domain from vm.xml error: monitor socket did not show up.: Connection refusedゲスト仮想マシン (またはドメイン) がスタートに失敗し、このエラーまたは同様のエラーを返す。「ゲストの起動に失敗しエラーが発生: monitor socket did not show up」
Internal error cannot find character device (null)このエラーは、ゲストのコンソールに接続しようとする際に発生します。ゲスト仮想マシン用に設定されたシリアルコンソールがない、とレポートされます。「internal error cannot find character device (null)」
No boot device既存のディスクイメージからゲスト仮想マシンを構築した後、ゲストの起動がストールするが、QEMU コマンドを直接使うとゲストは正常にスタートできる。「ゲスト仮想マシンの起動が停止してエラーが発生: No boot device」
The virtual network "default" has not been started
default ネットワーク (またはローカル作成された別のネットワーク) がスタートできないと、そのネットワークを接続に使用するように設定されたすべての仮想マシンもスタートに失敗する。
「仮想ネットワーク default が開始されない」
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」
Warning: could not open /dev/net/tun: no virtual network emulation qemu-kvm: -netdev tap,script=/etc/my-qemu-ifup,id=hostnet0: Device 'tap' could not be initializedホストシステムの type='ethernet' (別名、ジェネリックイーサネット) インターフェースの設定後にゲスト仮想マシンがスタートしない。このエラーまたは同様のエラーが libvirtd.log または /var/log/libvirt/qemu/name_of_guest.log のどちらか、または両方に表示される。「ゲストを起動できずエラーが発生: warning: could not open /dev/net/tun」
Unable to resolve address name_of_host service '49155': Name or service not knownQEMU ゲストマイグレーションが失敗し、このエラーメッセージが知らないホスト名とともに表示される。「移行時にエラーが発生: error: unable to resolve address」
Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directorylibvirt がディスクイメージにアクセスできないため、ゲスト仮想マシンを移行できない。「移行時にエラーが発生: Unable to allow access for disk path: No such file or directory」
No guest virtual machines are present when libvirtd is startedlibvirt デーモンは正常にスタートしたが、virsh list --all を実行してもゲスト仮想マシンが見当たらない「libvirtd の開始時に存在するゲスト仮想マシンがない」
Common XML errorslibvirt は 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 Linux ドメイン 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. 他の接続エラー

server:port でサーバーに接続できず、接続が拒否される。
デーモンがサーバー上で動作していないか、listen_tcp または listen_tls 設定オプションを使用していて、リッスンしないように設定されている。
End of file while reading data: nc: using stream socket: Input/output error
ssh トランスポートが指定されている場合、デーモンはサーバー上で動作していない可能性があります。デーモンがサーバー上で実行しているかどうかを確認して、このエラーを解消します。

A.19.3. ゲストの起動に失敗しエラーが発生: monitor socket did not show up

現象
ゲスト仮想マシン (またはドメイン) がスタートに失敗し、以下のエラーメッセージが表示される。 
# virsh -c qemu:///system create name_of_guest.xml error: Failed to create domain from name_of_guest.xml error: monitor socket did not show up.: Connection refused
調査
このエラーメッセージは以下の点を示しています。
  1. libvirt は動作している。
  2. QEMU プロセスが起動しなかった。
  3. QEMU または QEMU エージェント監視ソケットへの接続時に libvirt が終了する。
エラーの詳細を理解するために、ゲストログを検証します。 
# cat /var/log/libvirt/qemu/name_of_guest.log
LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-kvm -S -M pc -enable-kvm -m 768 -smp 1,sockets=1,cores=1,threads=1 -name name_of_guest -uuid ebfaadbe-e908-ba92-fdb8-3fa2db557a42 -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/name_of_guest.monitor,server,nowait -mon chardev=monitor,mode=readline -no-reboot -boot c -kernel /var/lib/libvirt/boot/vmlinuz -initrd /var/lib/libvirt/boot/initrd.img -append method=http://www.example.com/pub/product/release/version/x86_64/os/ -drive file=/var/lib/libvirt/images/name_of_guest.img,if=none,id=drive-ide0-0-0,boot=on -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -device virtio-net-pci,vlan=0,id=net0,mac=52:40:00:f4:f1:0a,bus=pci.0,addr=0x4 -net tap,fd=42,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -vnc 127.0.0.1:0 -k en-gb -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,
addr=0x3
char device redirected to /dev/pts/1
qemu: could not load kernel '/var/lib/libvirt/boot/vmlinuz':
Permission denied
解決法
ゲストログには、エラーの修正に必要な詳細が含まれています。
ゲストが libvirt の 0.9.5 よりも前のバージョンを実行中にホスト物理マシンがシャットダウンした場合、libvirt ゲストの init スクリプトはゲストの管理保存を実行しようとします。管理保存が不完全な場合 (たとえば、管理保存イメージがディスクにフラッシュされる前に電源が遮断される場合など)、保存イメージは破損し、QEMU はロードしません。古いバージョンの libvirt は破損を認識せず、問題は永続化します。この場合、ゲストログには、引数の 1 つとして -incoming の使用を試みたことが表示されます。これは、libvirt が保存状態のファイル内での移行により QEMU の起動を試みていることを意味します。
この問題を修正するには、virsh managedsave-remove name_of_guest を実行して、破損した管理された保存イメージを削除します。新しいバージョンの libvirt は手順を踏んで破損が発生しないようにし、virsh start --force-boot name_of_guest を追加して管理された保存イメージを迂回します。

A.19.4. internal error cannot find character device (null)

現象
ゲスト仮想マシンのコンソールに接続を試みる際にこのエラーメッセージが表示されます。 
# virsh console test2
Connected to domain test2
Escape character is ^]
error: internal error cannot find character device (null)
調査
このエラーメッセージは、ゲスト仮想マシン用にシリアルコンソールが設定されていないことを示しています。
解決法
ゲストの XML ファイル内でシリアルコンソールを設定します。

手順A.8 ゲストの XML ファイルでのシリアルコンソールの設定

  1. virsh edit を使用して、以下の XML をゲスト仮想マシンの XML に追加します。 
    <serial type='pty'>
  <target port='0'/>
</serial>
<console type='pty'>
  <target type='serial' port='0'/>
</console>
  2. ゲストのカーネルコマンドラインでコンソールを設定します。
    これを行うには、ゲスト仮想マシンにログインして /boot/grub2/grub.cfg ファイルを直接編集するか、または virt-edit コマンドラインツールを使用します。ゲストのカーネルコマンドラインに以下を追加します。 
    console=ttyS0,115200
  3. 以下のコマンドを実行します。 
    # virsh start vm && virsh console vm

A.19.5. ゲスト仮想マシンの起動が停止してエラーが発生: No boot device

現象
既存のディスクイメージからゲスト仮想マシンを作成した後、ゲストの起動が停止し、エラーメッセージ No boot device が表示される。ただし、QEMU コマンドを直接使うとゲスト仮想マシンは正常に起動する。
調査
既存ディスクイメージをインポートするコマンドでディスクのバスの種類が指定されていない。 
# virt-install \
--connect qemu:///system \
--ram 2048 -n rhel_64 \
--os-type=linux --os-variant=rhel5 \
--disk  path=/root/RHEL-Server-5.8-64-virtio.qcow2,device=disk,format=qcow2 \
--vcpus=2 --graphics spice --noautoconsole --import
ただし、QEMU を直接使用してゲスト仮想マシンを起動するために使用されるコマンドラインでは、バスの種類に virtio を使用することが示されます。 
# ps -ef | grep qemu
/usr/libexec/qemu-kvm -monitor stdio -drive file=/root/RHEL-Server-5.8-32-virtio.qcow2,index=0,if=virtio,media=disk,cache=none,format=qcow2 -net nic,vlan=0,model=rtl8139,macaddr=00:30:91:aa:04:74 -net tap,vlan=0,script=/etc/qemu-ifup,downscript=no -m 2048 -smp 2,cores=1,threads=1,sockets=2 -cpu qemu64,+sse2 -soundhw ac97 -rtc-td-hack -M rhel5.6.0 -usbdevice tablet -vnc :10 -boot c -no-kvm-pit-reinjection
インポートされたゲストのために libvirt によって生成されたゲストの XML にある bus= に注目してください。 
<domain type='qemu'>
 <name>rhel_64</name>
 <uuid>6cd34d52-59e3-5a42-29e4-1d173759f3e7</uuid>
 <memory>2097152</memory>
 <currentMemory>2097152</currentMemory>
 <vcpu>2</vcpu>
 <os>
   <type arch='x86_64' machine='rhel5.4.0'>hvm</type>
   <boot dev='hd'/>
 </os>
 <features>
   <acpi/>
   <apic/>
   <pae/>
 </features>
 <clock offset='utc'>
   <timer name='pit' tickpolicy='delay'/>
 </clock>
 <on_poweroff>destroy</on_poweroff>
 <on_reboot>restart</on_reboot>
 <on_crash>restart</on_crash>
 <devices>
   <emulator>/usr/libexec/qemu-kvm</emulator>
   <disk type='file' device='disk'>
     <driver name='qemu' type='qcow2' cache='none'/>
     <source file='/root/RHEL-Server-5.8-64-virtio.qcow2'/>
     <emphasis role="bold"><target dev='hda' bus='ide'/></emphasis>
     <address type='drive' controller='0' bus='0' unit='0'/>
   </disk>
   <controller type='ide' index='0'/>
   <interface type='bridge'>
     <mac address='54:52:00:08:3e:8c'/>
     <source bridge='br0'/>
   </interface>
   <serial type='pty'>
     <target port='0'/>
   </serial>
   <console type='pty'>
     <target port='0'/>
   </console>
   <input type='mouse' bus='ps2'/>
   <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
   <video>
     <model type='cirrus' vram='9216' heads='1'/>
   </video>
 </devices>
 </domain>
ディスクのバスの種類は ide に設定されており、これは libvirt によって設定されるデフォルト値です。これは間違ったバスの種類で、インポートされたゲストが正常に起動できない原因となっています。
解決法

手順A.9 ディスクのバスの種類の訂正

  1. インポートされたゲスト仮想マシンの定義を解除し、以下のように bus=virtio を使って再度インポートします。 
    # virsh destroy rhel_64
# virsh undefine rhel_64
# virt-install \
--connect qemu:///system \
--ram 1024 -n rhel_64 -r 2048 \
--os-type=linux --os-variant=rhel5  \
--disk path=/root/RHEL-Server-5.8-64-virtio.qcow2,device=disk,bus=virtio,format=qcow2 \
--vcpus=2 --graphics spice --noautoconsole --import
  2. virsh edit を使ってインポートされてゲストの XML を編集し、ディスクのバスの種類を訂正します。

A.19.6. 仮想ネットワーク default が開始されない

現象
通常は、default という名前の仮想ネットサークの設定は libvirt パッケージの一部としてインストールされ、libvirtd の起動時に自動起動に設定されます。
default ネットワーク (または他のローカルで作成されたネットワーク) が起動しない場合、接続にそのネットワークを使うように設定されている仮想マシンも起動に失敗し、以下のエラーメッセージが表示されます。 
仮想ネットワーク default が開始されない
調査
libvirt 仮想ネットワークの起動が失敗する最も一般的な理由の 1 つは、そのネットワーク上でクライアントからのDHCP および DNS 要求に対応するために必要な dnsmasq インスタンスの起動しなかったことです。
これが原因であるかどうかを判断するには、root シェルから virsh net-start default を実行して default 仮想ネットワークを起動します。
この方法で仮想ネットワークが正常に起動しない場合は、/var/log/libvirt/libvirtd.log を開いてエラーログメッセージ全体を確認します。
以下と同様のメッセージが表示される場合、問題は libvirt のブリッジ上ですでにリッスンしているシステム全体の dnsmasq インスタンスに関係する可能性が高くなり、これにより libvirt 独自の dnsmasq インスタンスがリッスンできなくなります。エラーメッセージで留意すべき最も重要な部分は、dnsmasq と exit status 2 になります。 
Could not start virtual network default: internal error
Child process (/usr/sbin/dnsmasq --strict-order --bind-interfaces
--pid-file=/var/run/libvirt/network/default.pid --conf-file=
--except-interface lo --listen-address 192.168.122.1
--dhcp-range 192.168.122.2,192.168.122.254
--dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
--dhcp-lease-max=253 --dhcp-no-override) status unexpected: exit status 2
解決法
物理ネットワークで DHCP の応答にマシンが dnsmasq を使用していない場合は、dnsmasq を完全に無効にします。
物理ネットワークで DHCP の応答に dnsmasq の実行が必要な場合は、/etc/dnsmasq.conf ファイルを編集します。最初の行のコメントと、それに続く 2 つの行いずれかのコメントマークを追加または削除します。3 つの行すべてでコメントマークを追加または削除しないでください。 
bind-interfaces
interface=name_of_physical_interface
listen-address=chosen_IP_address
この変更を加えてファイルを保存した後、システム全体の dnsmasq サービスを再起動します。
次に、virsh net-start default コマンドを使用して default ネットワークを起動します。
仮想マシンを起動します。

A.19.7. ゲスト上の 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 を再起動します。

A.19.8. ゲストは外部ネットワークにアクセスできるが、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.10 libvirt で分離されたネットワークを作成します。

  1. 以下の 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 隔離されたネットワーク

  2. virsh net-define /tmp/isolated.xml コマンドを使用して、ネットワークを作成します。
  3. virsh net-autostart isolated コマンドを使用して、ネットワークが自動起動するように設定します。
  4. virsh net-start isolated コマンドを使用して、ネットワークを起動します。
  5. 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

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

A.19.9. 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.10. 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.11. ゲストを起動できずエラーが発生: warning: could not open /dev/net/tun

現象
ゲスト仮想マシンは、ホストシステムで type='ethernet' (汎用イーサネットとも呼ばれる) インターフェースを設定した後は起動しません。エラーは、以下と似たメッセージで libvirtd.log または /var/log/libvirt/qemu/name_of_guest.log のいずれかか、両方に記録されます。 
warning: could not open /dev/net/tun: no virtual network emulation qemu-kvm: -netdev tap,script=/etc/my-qemu-ifup,id=hostnet0: Device 'tap' could not be initialized
調査
汎用イーサネットインターフェースタイプ (<interface type='ethernet'>) の使用は推奨されません。これは、QEMU とそのゲストの潜在的なセキュリティーの欠陥に対してホストの保護レベルを下げる必要があるためです。しかし、このインターフェースタイプを利用して、libvirt では直接サポートされていない一部のファシリティーを使用しなければならないことがあります。たとえば、openvswitch はバージョン 0.9.11 まで libvirt ではサポートされませんでした。そのため、それよりも古い libvirt バージョンでは <interface type='ethernet'> を使用してゲストを openvswitch ブリッジに接続するのが唯一の方法でした。
しかし、ホストシステムに他の変更を加えることなく <interface type='ethernet'> インターフェースを設定すると、ゲスト仮想マシンは正常に起動しなくなります。
この失敗の原因は、この種類のインターフェースでは、QEMU に呼び出されるスクリプトはタップデバイスを操作する必要があることによります。しかし、type='ethernet' が設定されていると、QEMU をロックダウンする目的で、libvirt と SELinux はこれを妨ぐためのチェックを複数実行します (通常、libvirt はタップデバイス作成および操作のすべてを実行し、タップデバイスのオープンファイル記述子を QEMU に渡します)。
解決法
ホストシステムが汎用イーサネットインターフェースと互換性を持つように再設定します。

手順A.11 ホストシステムがジェネリックイーサネットインターフェースを使用するように再設定

  1. /etc/selinux/config に SELINUX=permissive を設定して SELinux を permissive に設定します。 
    # This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted
  2. root のシェルからコマンド setenforce permissive を実行します。
  3. /etc/libvirt/qemu.conf に以下の行を追加または編集します。 
    clear_emulator_capabilities = 0
    user = "root"
    group = "root"
    cgroup_device_acl = [
        "/dev/null", "/dev/full", "/dev/zero",
        "/dev/random", "/dev/urandom",
        "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
	"/dev/rtc", "/dev/hpet", "/dev/net/tun",
  4. libvirtd を再起動します。

重要

これらの各ステップは QEMU ゲストドメインに対するホストのセキュリティー保護を大幅に低下させるので、この設定は <interface type='ethernet'> 以外に方法がない場合にのみ使用してください。

注記

SELinux の詳細については、『『Red Hat Enterprise Linux 7 SELinux ユーザーおよび管理者のガイド』』を参照してください。

A.19.12. 移行時にエラーが発生: 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.13. 移行時にエラーが発生: 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.12 共有ストレージのセットアップ

  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.14. 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.15. unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisor

現象
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.16. 一般的な XML エラー

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

A.19.16.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.16.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.16.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.16.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.16.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.16.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.16.3. 論理および設定エラー

適切にフォーマットされた XML ドキュメントで構文が正しくても、libvirt が解析できないエラーを含んでいる場合があります。これらのエラーの多くは、以下で説明する 2 つのケースに当てはまります。
A.19.16.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.16.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' を代わりに使用します。