Appendix B. Common libvirt Errors and Troubleshooting

This appendix documents common libvirt-related problems and errors along with instructions for dealing with them.
Locate the error on the table below and follow the corresponding link under Solution for detailed troubleshooting information.

Table B.1. Common libvirt errors

ErrorDescription of problemSolution
libvirtd Failed to StartThe libvirt daemon failed to start. However, there is no information about this error in /var/log/messages.Section B.1, “libvirtd failed to start”
Cannot read CA certificateThis is one of several errors that occur when the URI fails to connect to the hypervisor.Section B.2, “The URI Failed to Connect to the Hypervisor”
Failed to connect socket ... : Permission deniedThis is one of several errors that occur when the URI fails to connect to the hypervisor.Section B.2, “The URI Failed to Connect to the Hypervisor”
Other connectivity errorsThese are other errors that occur when the URI fails to connect to the hypervisor.Section B.2, “The URI Failed to Connect to the Hypervisor”
Internal error guest CPU is not compatible with host CPUThe guest virtual machine cannot be started because the host and guest processors are different.Section B.3, “The guest virtual machine cannot be started: 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 refusedThe guest virtual machine (or domain) starting fails and returns this error or similar.Section B.4, “Guest starting fails with error: monitor socket did not show up
Internal error cannot find character device (null)This error can occur when attempting to connect a guest's console. It reports that there is no serial console configured for the guest virtual machine.Section B.5, “Internal error cannot find character device (null)
No boot deviceAfter building a guest virtual machine from an existing disk image, the guest booting stalls. However, the guest can start successfully using the QEMU command directly.Section B.6, “Guest virtual machine booting stalls with error: No boot device
The virtual network "default" has not been started
If the default network (or other locally-created network) is unable to start, any virtual machine configured to use that network for its connectivity will also fail to start.
Section B.7, “Virtual network default has not been started”
PXE boot (or DHCP) on guest failedA guest virtual machine starts successfully, but is unable to acquire an IP address from DHCP, boot using the PXE protocol, or both. This is often a result of a long forward delay time set for the bridge, or when the iptables package and kernel do not support checksum mangling rules.Section B.8, “PXE Boot (or DHCP) on Guest Failed”
Guest can reach outside network, but cannot reach host when using macvtap interface
A guest can communicate with other guests, but cannot connect to the host machine after being configured to use a macvtap (or type='direct') network interface.
This is actually not an error — it is the defined behavior of macvtap.
Section B.9, “Guest Can Reach Outside Network, but Cannot Reach Host when Using macvtap Interface”
Could not add rule to fixup DHCP response checksums on network 'default'This warning message is almost always harmless, but is often mistakenly seen as evidence of a problem.Section B.10, “Could not add rule to fixup DHCP response checksums on network 'default'
Unable to add bridge br0 port vnet0: No such device This error message or the similar Failed to add tap interface to bridge 'br0': No such device reveal that the bridge device specified in the guest's (or domain's) <interface> definition does not exist.Section B.11, “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 The guest virtual machine does not start after configuring a type='ethernet' (or 'generic ethernet') interface in the host system. This error or similar appears either in libvirtd.log, /var/log/libvirt/qemu/name_of_guest.log, or in both.Section B.12, “Guest is Unable to Start with Error: warning: could not open /dev/net/tun
Unable to resolve address name_of_host service '49155': Name or service not knownQEMU guest migration fails and this error message appears with an unfamiliar host name.Section B.13, “Migration Fails with Error: unable to resolve address
Unable to allow access for disk path /var/lib/libvirt/images/qemu.img: No such file or directoryA guest virtual machine cannot be migrated because libvirt cannot access the disk image(s).Section B.14, “Migration Fails with Unable to allow access for disk path: No such file or directory
No guest virtual machines are present when libvirtd is startedThe libvirt daemon is successfully started, but no guest virtual machines appear to be present when running virsh list --all.Section B.15, “No Guest Virtual Machines are Present when libvirtd is Started”
Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisorWhile libvirtd should listen on TCP ports for connections, the connection to the hypervisor fails.Section B.16, “Unable to connect to server at 'host:16509': Connection refused ... error: failed to connect to the hypervisor”
Common XML errorslibvirt uses XML documents to store structured data. Several common errors occur with XML documents when they are passed to libvirt through the API. This entry provides instructions for editing guest XML definitions, and details common errors in XML syntax and configuration.Section B.17, “Common XML Errors”

B.1. libvirtd failed to start

Symptom
The libvirt daemon does not start automatically. Starting the libvirt daemon manually fails as well:
# /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
Moreover, there is not 'more info' about this error in /var/log/messages.
Investigation
Change libvirt's logging in /etc/libvirt/libvirtd.conf by uncommenting the line below. To uncomment the line, open the /etc/libvirt/libvirtd.conf file in a text editor, remove the hash (or #) symbol from the beginning of the following line, and save the change:
log_outputs="3:syslog:libvirtd"

Note

This line is commented out by default to prevent libvirt from producing excessive log messages. After diagnosing the problem, it is recommended to comment this line again in the /etc/libvirt/libvirtd.conf file.
Restart libvirt to determine if this has solved the problem.
If libvirtd still does not start successfully, an error similar to the following will be shown in the /var/log/messages file:
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
The libvirtd man page shows that the missing cacert.pem file is used as TLS authority when libvirt is run in Listen for TCP/IP connections mode. This means the --listen parameter is being passed.
Solution
Configure the libvirt daemon's settings with one of the following methods:
  • Install a CA certificate.

    Note

    For more information on CA certificates and configuring system authentication, refer to the Configuring Authentication chapter in the Red Hat Enterprise Linux 6 Deployment Guide.
  • Do not use TLS; use bare TCP instead. In /etc/libvirt/libvirtd.conf set listen_tls = 0 and listen_tcp = 1. The default values are listen_tls = 1 and listen_tcp = 0.
  • Do not pass the --listen parameter. In /etc/sysconfig/libvirtd.conf change the LIBVIRTD_ARGS variable.