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

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

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

エラー問題の概要解決法
libvirtd failed to startlibvirt デーモンがスタートに失敗するが、/var/log/messages にはこのエラーに関する情報がない。libvirtd がスタート失敗」
Cannot read CA certificateURI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。「URI がハイパーバイザー接続に失敗する」
Failed to connect socket ... : Permission deniedURI がハイパーバイザー接続に失敗する際に発生するエラーの 1 つです。「URI がハイパーバイザー接続に失敗する」
Other connectivity errorsURI がハイパーバイザー接続に失敗する際に発生するその他のエラーです。「URI がハイパーバイザー接続に失敗する」
Internal error guest CPU is not compatible with host CPUホストとゲストのプロセッサーが異なるため、ゲスト仮想マシンがスタートできない。「ゲスト仮想マシンがスタートできずエラーが発生: internal error guest CPU is not compatible with host CPU
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 パッケージとカーネルがチェックサム難号化ルールをサポートしないためです。「ゲスト上の 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 のスタート時にゲスト仮想マシンがない」
Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisorlibvirtd が接続のために TCP ポートをリッスンしている間に、ハイパーバイザーへの接続が失敗する。「unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisor」
Common XML errorslibvirt は XML ドキュメントを使用して構造化データを保存します。XML ドキュメントのエラーのいくつかは、XML ドキュメントが API で libvirt に渡される際に発生します。このエントリーでは、ゲスト XML 定義の編集に関する指示と、XML 構文および設定における一般的なエラーの詳細を提供します。「一般的な XML エラー」

A.18.1. libvirtd がスタート失敗

現象
libvirt デーモンが自動的にスタートしない。手動での libvirt デーモンのスタートも失敗
# /etc/init.d/libvirtd start
* 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.conflibvirt のロギングを変更します。行の設定を有効にするには、テキストエディターで /etc/libvirt/libvirtd.conf ファイルを開き、以下の行の先頭からハッシュ (または #) 記号を削除して、変更を保存します。
log_outputs="3:syslog:libvirtd"

注記

この行は、libvirt が過剰なログメッセージを作成しないように、デフォルトではコメントアウトされています。問題の診断後には、/etc/libvirt/libvirtd.conf ファイルでこの行を再度コメントすることが推奨されます。
libvirt を再起動し、問題が解決されたか確認します。
libvirtd がまだ正常にスタートしない場合、/var/log/messages ファイルに以下と同様のエラーが表示されます。
Feb  6 17:22:09 bart libvirtd: 17576: info : libvirt version: 0.9.9
Feb  6 17:22:09 bart libvirtd: 17576: error : virNetTLSContextCheckCertFile:92: Cannot read CA certificate '/etc/pki/CA/cacert.pem': No such file or directory
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17573]: start-stop-daemon: failed to start `/usr/sbin/libvirtd'
Feb  6 17:22:09 bart /etc/init.d/libvirtd[17565]: ERROR: libvirtd failed to start
libvirtd man ページには、libvirtListen for TCP/IP connections モードで実行された際に、見つからない cacert.pem ファイルが TLS 認証として使用されたことが示されています。つまり、--listen パラメーターがパスされています。
解決法
libvirt デーモンを以下のいずれかの方法で設定します。
  • CA 証明書をインストールする。

    注記

    CA 証明書およびシステム認証の設定に関する詳細は、Red Hat Enterprise Linux 7 Domain Identity, Authentication, and Policy Guide の認証の設定の章を参照してください。
  • TLS を使わずにベア TCP を使用する。/etc/libvirt/libvirtd.conflisten_tls = 0listen_tcp = 1 に設定する。デフォルト値は、listen_tls = 1listen_tcp = 0
  • --listen パラメーターをパスしない。/etc/sysconfig/libvirtd.confLIBVIRTD_ARGS 変数を変更する。

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

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

A.18.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 を指定すると、 ローカルホスト上で libvirtdsystem インスタンスに接続するようvirsh に指示します。
ホスト名が指定されていると、QEMU トランスポートがデフォルトで TLS を選択します。これで証明書が作成されます。
接続が未設定
URI は正しいが (例えば、qemu[+tls]://server/system) マシン上で証明書が正しく設定されていない。TLS の設定に関する詳細は、libvirt ウェブサイトの Setting up libvirt for TLS を参照してください。

A.18.2.2. Failed to connect socket ... : Permission denied

現象
virsh コマンド実行中に、以下のエラー (または同様のエラー) が表示される。
$ virsh -c qemu:///system_list
error: failed to connect to the hypervisor
error: authentication failed: polkit: polkit\56retains_authorization_after_challenge=1
Authorization requires authentication but no agent is available

A.18.2.3. 他の接続エラー

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.18.3. ゲスト仮想マシンがスタートできずエラーが発生: internal error guest CPU is not compatible with host CPU

現象
Intel Core i7 プロセッサー (virt-managerNehalem と呼ぶ。また、以前の Core 2 Duo の場合は Penryn と呼ぶ) 上で動作する KVM ゲスト (またはドメイン) は、virt-manager を使用して作成されます。インストール後に、ゲストのプロセッサーはホストの CPU に適合するように変更されます。するとゲストはスタートできず、以下のエラーメッセージを表示します。
2012-02-06 17:49:15.985+0000: 20757: error : qemuBuildCpuArgStr:3565 : internal error guest CPU is not compatible with host CPU
また、virt-managerCopy host CPU configuration をクリックすると、NehalemPenryn ではなく、Pentium III が表示されます。
調査
/usr/share/libvirt/cpu_map.xml ファイルは、各 CPU モデルを定義するフラグをリスト表示します。Nehalem および Penryn の定義には、以下が含まれます。
<feature name='nx'/>
その結果、 CPU を Nehalem または Penryn と特定するには、NX (または No eXecute) フラグを提示する必要があります。しかし、/proc/cpuinfo にはこのフラグが欠けています。
解決法
ほとんどすべての新規 BIOSes では、No eXecute ビットの有効化や無効化が可能です。しかし、無効となっている場合、このフラグをレポートしない CPU もあり、そのため libvirt は別の CPU を検出します。この機能を有効にすると、libvirt が正しい CPU にレポートするように指示します。この問題の詳細な指示に関しては、ご自分のハードウェアの資料を参照してください。

A.18.4. ゲストがスタートに失敗しエラーが発生: 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. libvirtQEMU または 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 を実行して破損した管理保存イメージを削除することで修正できます。新しいバージョンの libvirt は、最初の段階で破損を回避するステップを取り、virsh start --force-boot name_of_guest を追加して管理保存イメージも迂回します。

A.18.5. 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.18.6. ゲスト仮想マシンの起動がストールしエラーが発生: 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 が生成した bus= がゲストの XMLにあることに注意。
<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.18.7. Virtual network default has not been started

現象
通常、libvirt パッケージの一部として default 名で仮想ネットワークの設定がインストールされており、libvirtd のスタート時に自動スタートするように設定されています。
default ネットワーク (またはローカルで作成されたネットワーク) がスタートできない場合、接続にそのネットワークを使うように接続されている仮想マシンもスタートに失敗し、以下のエラーメッセージが表示されます。
Virtual network default has not been started
調査
libvirt 仮想ネットワークのスタート失敗でよくある理由の一つは、そのネットワーク上でクライアントからのDHCP および DNS リクエストに応えるために必要な dnsmasq インスタンスがスタートに失敗したためです。
これが理由であることを確かめるには、root shell から virsh net-start default を実行し、default 仮想ネットワークをスタートします。
この方法で仮想ネットワークが正常にスタートしない場合、/var/log/libvirt/libvirtd.log を開いて完全なエラーログメッセージを表示します。
以下と同様のメッセージが表示される場合、問題は libvirt のブリッジ上ですでにリッスンしているシステムワイドの dnsmasq インスタンスである可能性が高いと言えます。このインスタンスは、libvirt の dnsmasq イスタンスがリッスンすることを妨げています。エラーメッセージで最も注目すべき点は、dnsmasqexit 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 サービスを再起動します。
次に、default ネットワークを virsh net-start default コマンドでスタートします。
仮想マシンを起動します。

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

現象
ゲスト仮想マシンは正常にスタートするが、DHCP から IP アドレスを取得できない、または PXE を使用したブートができない、もしくはその両方。このエラーには 2 つの一般的な原因があります。ブリッジでの転送遅延時間が長く設定されている場合と、iptables パッケージとカーネルがチェックサム難号化ルールをサポートしない場合です。
ブリッジの転送遅延時間が長い
調査
このエラーにおける最も一般的な原因です。ゲストのネットワークインターフェースが 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 パッケージとカーネルがチェックサム難号化ルールをサポートしない場合
調査
このメッセージは、以下の 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.18.9. ゲストは外部ネットワークにアクセスできるが、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 を使用する各ゲストの設定を編集し、以下と同様の新たな <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.18.10. 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.18.11. 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.18.12. ゲストがスタートできずエラーが発生: 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 で直接サポートされていない別の機能を活用することも必要です。例えば、 openvswitchlibvirt では libvirt-0.9.11 までサポートされていなかったので、libvirt の古いバージョンでは <interface type='ethernet'> がゲストを openvswitch ブリッジに接続する唯一の方法でした。
しかし、ホストシステムに他の変更を加えることなく <interface type='ethernet'> インターフェースを設定すると、ゲスト仮想マシンは正常にスタートしなくなります。
この失敗の原因は、この種類のインターフェースでは、QEMU に呼び出されるスクリプトはタップデバイスを操作する必要があるからです。しかし、type='ethernet' が設定されていると、QEMU をロックダウンする目的で、libvirt と SELinux はこれを妨げるためのチェックをいくつか確立しています。 (通常、libvirt はタップデバイス作成および操作のすべてを実行し、タップデバイスのオープンファイル記述子を QEMU にパスします。)
解決法
ホストシステムがジェネリックイーサネットインターフェースと互換性を持つように再設定します。

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

  1. /etc/selinux/configSELINUX=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 shell から 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 SELinix ユーザーおよび管理者のガイド を参照してください。

A.18.13. 移行に失敗しエラーが発生 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
移行先 libvirtdtcp://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.18.14. 移行に失敗しエラーが発生: 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.18.15. libvirtd のスタート時にゲスト仮想マシンがない

現象
libvirt デーモンは正常にスタートしたが、ゲスト仮想マシンが見当たらない
# virsh list --all
 Id    Name                           State
----------------------------------------------------
#
調査
この問題の原因は、いくつも考えられます。以下のテストを実施して原因を特定します。
KVM カーネルモジュールの確認
KVM カーネルモジュールがカーネルに挿入されていることを確認する。
# lsmod | grep kvm
kvm_intel             121346  0
kvm                   328927  1 kvm_intel
AMD マシンを使用している場合は、root shell で同様の 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.18.16. 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.18.17. 一般的な XML エラー

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

A.18.17.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.

重要

virshedit コマンドを使用して、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.18.17.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.18.17.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.18.17.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.18.17.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.18.17.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.18.17.3. 論理および設定エラー

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