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

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

表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 ネットワーク (またはローカルで作成された別のネットワーク) を開始できないと、そのネットワークを接続に使用するように設定されたすべての仮想マシンも起動に失敗する。
「Virtual network default has not been started」
PXE boot (or DHCP) on guest failedゲスト仮想マシンは正常に起動するが、DHCP から IP アドレスを取得できない、PXE プロトコルを使用してブートできない、またはその両方。この原因は多くの場合、ブリッジの転送遅延時間が長く設定されているか、または iptables パッケージとカーネルがチェックサムの難号化 (mangle) 規則をサポートしないためです。「ゲスト上の 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.20.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 にはこのエラーの 詳細情報 がない。
調査
以下の行を有効にし、/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 ドメイン 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.20.2. URI のハイパーバイザー接続に失敗する

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

A.20.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.20.2.2. 他の接続エラー

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

A.20.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. libvirt は QEMU または QEMU エラーモニターソケットに接続しようとした際に終了した
エラーの詳細を確認するために、ゲストログを検証します。 
# 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 を実行して破損した管理保存 (managedsave) イメージを削除することで修正できます。新しいバージョンの libvirt は最初の段階で破損を回避する手順を実行し、virsh start --force-boot name_of_guest を追加して管理保存 (managedsave) イメージを無視します。

A.20.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.9 ゲストの 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.20.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.10 ディスクのバスの種類の訂正

  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.20.6. Virtual network default has not been started

現象
通常、libvirt パッケージの一部として default という名前の仮想ネットワークの設定がインストールされており、libvirtd の起動時に自動起動ように設定されています。
default ネットワーク (または他のローカルで作成されたネットワーク) が起動しない場合、接続にそのネットワークを使うように設定されている仮想マシンも起動に失敗し、以下のエラーメッセージが表示されます。 
Virtual network default has not been started
調査
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.20.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 ファイルで以下の行を追加または編集して、STP を on にし、遅延を 0 秒にします。 
STP=on DELAY=0
設定ファイルの変更後にブリッジデバイスを再起動します。 
/usr/sbin/ifdown name_of_bridge
/usr/sbin/ifup name_of_bridge

注記

name_of_bridge がネットワークの root ブリッジでない場合、そのブリッジの遅延時間は最終的には root ブリッジ に設定されている遅延時間にリセットされます。この場合の唯一の解決法は、name_of_bridge で STP を完全に無効にすることです。
iptables パッケージとカーネルがチェックサムの難号化 (mangle) 規則をサポートしない
調査
このメッセージは、以下の 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
<interface> セクションの <driver> 行を変更するか、またはこれを追加します。 
<interface type='network'>
  <model type='virtio'/>
  <driver name='qemu'/>
  ...
</interface>
変更を保存し、ゲストをシャットダウンしてから再起動します。
この問題が解決されない場合、firewalld とデフォルトの libvirt ネットワーク間に競合がある可能性があることが原因として考えられます。
これを修正するには、service firewalld stop コマンドで firewalld を停止し、service libvirtd restart コマンドで libvirt を再起動します。

A.20.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.11 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 分離されたネットワーク XML

  2. コマンド virsh net-define /tmp/isolated.xml を使ってネットワークを作成します。
  3. virsh net-autostart isolated コマンドを使ってネットワークの自動起動を設定します。
  4. virsh net-start isolated コマンドを使ってネットワークを起動します。
  5. virsh edit name_of_guest を使って、ネットワーク接続に macvtap を使用する各ゲストの設定を編集し、以下と同様の新たな <interface> を <devices> セクションに追加します。(<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.20.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.20.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 showbr0 を使います。
以下のようなメッセージが表示されると、その名前のブリッジが存在しないことが確認できます。 
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.20.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 は libvirt では libvirt-0.9.11 までサポートされていなかったので、libvirt の古いバージョンでは <interface type='ethernet'> がゲストを openvswitch ブリッジに接続する唯一の方法でした。
しかし、ホストシステムに他の変更を加えることなく <interface type='ethernet'> インターフェースを設定すると、ゲスト仮想マシンは正常に起動しなくなります。
この失敗の原因は、この種類のインターフェースでは、QEMU に呼び出されるスクリプトはタップデバイスを操作する必要があることによります。しかし、type='ethernet' が設定されていると、QEMU をロックダウンする目的で、libvirt と SELinux はこれを妨ぐためのチェックをいくつか実施します(通常、libvirt はタップデバイス作成および操作のすべてを実行し、タップデバイスのオープンファイル記述子を QEMU に渡します)。
解決法
ホストシステムが汎用イーサネットインターフェースと互換性を持つように再設定します。

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

  1. /etc/selinux/config で SELINUX=permissive を設定し、SELinux to 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.20.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.20.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.13 共有ストレージのセットアップ

  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.20.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.20.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
/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.20.16. 一般的な XML エラー

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

A.20.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.20.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.20.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.20.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.20.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 タグの不一致の例が示されています。
この抜粋には、終了タグ (</name>) がないために <features> の不一致エラーが含まれています。 
<domain type='kvm'>
 ...
 <features>
   <acpi/>
   <pae/>
 ...
 </domain>
以下の例では、</name> の終了タグのみがあり、対応する開始タグがありません。 
<domain type='kvm'>
  </name>
  ...
</domain>
解決法
すべての XML タグが正しく開始し、終了していることを確認します。
A.20.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.20.16.3. 論理および設定エラー

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