B.13. Migration Fails with Error: unable to resolve address
B.13. Migration Fails with Error: unable to resolve address Symptom QEMU guest migration fails and this error message appears: For example, if the destination host name is "newyork", the error message will appear as: However, this error looks strange as we did not use "newyork" host name anywhere. Investigation 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. In this case, the destination host ( 192.168.122.12 ) has its name set to 'newyork' . For some reason, libvirtd running on that host is unable to resolve the name to an IP address that could be sent back and still be useful. For this reason, it returned the 'newyork' host name hoping the source libvirtd would be more successful with resolving the name. This can happen if DNS is not properly configured or /etc/hosts has the host name associated with local loopback address ( 127.0.0.1 ). 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. Solution 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. If the host names cannot be made resolvable by any means, virsh migrate supports specifying the migration host: Destination libvirtd will take the tcp://192.168.122.12 URI and append an automatically generated port number. If this is not desirable (because of firewall configuration, for example), the port number can be specified in this command: 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 error: Unable to resolve address name_of_host service '49155': Name or service not known virsh migrate qemu qemu+tcp://192.168.122.12/system error: Unable to resolve address 'newyork' service '49155': Name or service not known virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12 virsh migrate qemu qemu+tcp://192.168.122.12/system tcp://192.168.122.12:12345 virsh migrate qemu qemu+tcp://192.168.122.12/system --p2p --tunnelled