Are you facing 'Libvirt error: Unable to resolve address: name or service not known' ?
This guide is for you.
During migration, libvirtd running on the destination host creates a URI from an address and port where it expects to receive migration data and sends it back to libvirtd running on the source host.
Sometimes, QEMU quest users end up with this error while migrating. This error message usually occurs when the source server cannot resolve to the destination IP causing the failure of migration.
Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to handle QEMU guests.
This error message appears when QEMU guest migration fails:
# 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
For example, if the destination hostname is Arizona, the error message appears as:
# virsh migrate qemu qemu+tcp://192.168.122.12/system
error: Unable to resolve address 'Sydney' service '49155': Name or service not known
However, this error looks strange as we did not use the Sydney host name anywhere.
This can happen if DNS is not properly configured or /etc/hosts has the hostname associated with the local loopback address (127.0.0.1).
1. To fix this error we need to configure DNS correctly so that all hosts involved in migration are able to resolve all hostnames.
2. If we cannot configure DNS, we will have to add the list of every host used for migration manually to the /etc/hosts file on each of the hosts. However, it is difficult to keep such lists consistent in a dynamic environment.
3. Even after doing the above, If the hostnames cannot be made resolvable we can use virsh commands that support migration 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. If this is not desirable, 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
4. Another option is to use tunneled migration.
Tunneled migration does not create a separate connection for migration data, but instead tunnels the data through the connection used for communication with destination libvirtd:
# virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled
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