Explore information related to libvirt

Libvirt error Unable to resolve address name or service not known

This article covers tips to fix 'Libvirt error: Unable to resolve address: name or service not known'. 

QEMU guest migration fails and this error message appears:

# 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

Note that the address used for migration data cannot be automatically determined from the address used for connecting to destination libvirtd (for example, from qemu+tcp://192.168.122.12/system). 

This is because to communicate with the destination libvirtd, the source libvirtd may need to use network infrastructure different from that which virsh (possibly running on a separate machine) requires.


To fix Libvirt error: Unable to resolve address: name or service not known:

The best solution is to configure DNS correctly so that all hosts involved in migration are able to resolve all host names.

If DNS cannot be configured to do this, a list of every host used for migration can be added manually to the /etc/hosts file on each of the hosts. 

However, it is difficult to keep such lists consistent in a dynamic environment.

i. If the host names cannot be made resolvable by any means, virsh migrate supports specifying the migration host:

# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12

Destination libvirtd will take the tcp://192.168.122.12 URI and append an automatically generated port number. 

ii. If this is not desirable (because of firewall configuration, for example), the port number can be specified in this command:

# virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12:12345

iii. Another option is to use tunnelled migration. Tunnelled migration does not create a separate connection for migration data, but instead tunnels the data through the connection used for communication with destination libvirtd (for example, qemu+tcp://192.168.122.12/system):

# virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled

Read More



Unable to allow access for disk path in libvirtd - Fix it Now

This article covers tips to fix the error Unable to allow access for disk path in libvirtd. By default, migration only transfers the in-memory state of a running guest (such as memory or CPU state). Although disk images are not transferred during migration, they need to remain accessible at the same path by both hosts.


To fix Unable to allow access for disk path in libvirtd error:

Set up and mount shared storage at the same location on both hosts. The simplest way to do this is to use NFS:

1. Set up an NFS server on a host serving as shared storage. The NFS server can be one of the hosts involved in the migration, as long as all hosts involved are accessing the shared storage through NFS.

# mkdir -p /exports/images
# cat >>/etc/exports <<EOF
/exports/images    192.168.122.0/24(rw,no_root_squash)
EOF


2. Mount the exported directory at a common location on all hosts running libvirt. For example, if the IP address of the NFS server is 192.168.122.1, mount the directory with the following commands:

# cat >>/etc/fstab <<EOF
192.168.122.1:/exports/images  /var/lib/libvirt/images  nfs  auto  0 0
EOF
# mount /var/lib/libvirt/images

Read More



Unable to add bridge port vnet0 No such device - Fix it now ?

This article covers how to resolve the error, Unable to add bridge port vnet0: No such device which happens when the bridge device specified in the guest's (or domain’s) <interface> definition does not exist.

Theerror messages reveal that the bridge device specified in the guest's (or domain's) <interface> definition does not exist.

To verify the bridge device listed in the error message does not exist, use the shell command ifconfig br0.

A message similar to this confirms the host has no bridge by that name:

br0: error fetching interface information: Device not found

If this is the case, continue to the solution.


To fix the error, Unable to add bridge port vnet0: No such device :

1. Edit the existing bridge or create a new bridge with virsh

Use virsh to either edit the settings of an existing bridge or network, or to add the bridge device to the host system configuration.

2. Edit the existing bridge settings using virsh

Use virsh edit name_of_guest to change the <interface> definition to use a bridge or network that already exists.

For example, change type='bridge' to type='network', and <source bridge='br0'/> to <source network='default'/>.

Read More



The URI Failed to Connect to the Hypervisor - Fix it now

This article covers methods to resolve hypervisor error. The error message is misleading about the actual cause. This error can be caused by a variety of factors, such as an incorrectly specified URI, or a connection that is not configured.


To fix THE URI FAILED TO CONNECT TO THE HYPERVISOR:

1. Incorrectly specified URI

When specifying qemu://system or qemu://session as a connection URI, virsh attempts to connect to host names system or session respectively. This is because virsh recognizes the text after the second forward slash as the host.

Use three forward slashes to connect to the local host. For example, specifying qemu:///system instructs virsh connect to the system instance of libvirtd on the local host.

When a host name is specified, the QEMU transport defaults to TLS. This results in certificates.


2. Connection is not configured

The URI is correct (for example, qemu[+tls]://server/system) but the certificates are not set up properly on your machine. For information on configuring TLS, see Setting up libvirt for TLS available from the libvirt website.

Read More



No guest machines present libvirtd - Fix it now

This article covers how to troubleshoot and fix No guest machines present libvirtd for our customers. 

The virsh program is the main interface for managing virsh guest domains. The program can be used to create, pause, and shutdown domains. 

It can also be used to list current domains. Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes).

The libvirt daemon is successfully started, but no guest virtual machines appear to be present.


There are various possible causes of this problem.

Performing these tests will help to determine the cause of this situation:

1. Verify KVM kernel modules

Verify that KVM kernel modules are inserted in the kernel:

$ lsmod | grep kvm

If you are using an AMD machine, verify the kvm_amd kernel modules are inserted in the kernel instead, using the similar command lsmod | grep kvm_amd in the root shell.

If the modules are not present, insert them using the modprobe <modulename> command.

Note: Although it is uncommon, KVM virtualization support may be compiled into the kernel. In this case, modules are not needed.

2. Verify virtualization extensions

Verify that virtualization extensions are supported and enabled on the host:

# egrep "(vmx|svm)" /proc/cpuinfo

Enable virtualization extensions in your hardware's firmware configuration within the BIOS setup.

3. Verify client URI configuration

Verify that the URI of the client is configured as desired:

# virsh uri


How to fix No guest machines present #libvirtd #error:

After performing these tests, use the following command to view a list of guest virtual machines:

# virsh list --all

Read More



libvirtd failed to start - Fix it Now

This article covers how to resolve the error 'libvirtd failed to start' which happens while manually trying to start libvirt daemon. 

To resolve this #libvirtd #error, Try journalctl -u libvirtd.service and see if the full log for the service has more information.

You can manually install "libxslt" to resolve the problem.

Also you can try re-installing the packages that libvirtd/KVM requires and did a full system update. 

After that, reboot the server, and libvirtd.service will be working fine.

Read More



Failed to initialize a valid firewall backend

This article will guide you on how to fix error ‘failed to initialize a valid firewall backend’ which is triggered in the process of creating Virtual Machines on KVM using Libvirt.

Read More