Bug 1312204 - libvirtd (libvirt) 1.2.17 breaks the behavior of using IP for migration
Summary: libvirtd (libvirt) 1.2.17 breaks the behavior of using IP for migration
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-26 05:40 UTC by Frank Zhang
Modified: 2016-06-20 13:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-20 13:38:06 UTC


Attachments (Terms of Use)

Description Frank Zhang 2016-02-26 05:40:05 UTC
Description of problem:

For some reason, libvirt requires DNS name of hosts when doing VM migration. For situations that hostnames cannot be DNS resolved, the documentation(http://wiki.libvirt.org/page/Migration_fails_with_%22Unable_to_resolve_address%22_error) gives out two options that directly use IPs for migration. However, for libvirtd (libvirt) 1.2.17 coming out with RedHat/CentOS7.2, all those options are broken. The errors are like:

Tunnelled:

[root@localhost ~]# virsh migrate --live --p2p --undefinesource --tunnelled 480861e1907245d2b632c86c4beea075 qemu+tcp://192.168.200.145/system
error: internal error: Attempt to migrate guest to the same host localhost.localdomain

TCP URI:

[root@localhost ~]# virsh migrate --live --p2p --undefinesource  480861e1907245d2b632c86c4beea075 qemu+tcp://192.168.200.145/system tcp://192.168.200.145
error: internal error: Attempt to migrate guest to the same host localhost.localdomain
 

Version-Release number of selected component (if applicable):

CentOS 7.2
libvirtd 1.2.17

How reproducible:

migrate a VM using commands like:

 virsh migrate --live --p2p --undefinesource --tunnelled 480861e1907245d2b632c86c4beea075 qemu+tcp://192.168.200.145/system

or 

virsh migrate --live --p2p --undefinesource --tunnelled 480861e1907245d2b632c86c4beea075 qemu+tcp://192.168.200.145/system

Steps to Reproduce:
1.
2.
3.

Actual results:

Migration failure


Expected results:

Migration success

Additional info:

Comment 1 zhe peng 2016-02-29 02:48:52 UTC
Hi,
Seems your migration hosts not config /etc/hosts file.
Try to edit /etc/hosts on both hosts, like below:
ip1 host1
ip2 host2
Maybe this can solved your issue.

Comment 2 Cole Robinson 2016-04-10 23:45:23 UTC
What is the source host's IP address? What URI are you using for the source host?

Comment 3 Frank Zhang 2016-04-11 01:57:16 UTC
The source IP is 192.168.200.146 which is in the same subnet with the destination host. The migration URI is qemu+tcp://192.168.200.145/system.

I have confirmed the problem is because the two hosts have the same hostname: localhost.localdomain that is quite common as people usually don't configure any hostname for machines. I don't see any need that libvirt looks up the hostnames for both hosts, as the IP address is good enough for data transferring during the migration.

Comment 4 Cole Robinson 2016-06-20 13:38:06 UTC
(In reply to Frank Zhang from comment #3)
> The source IP is 192.168.200.146 which is in the same subnet with the
> destination host. The migration URI is qemu+tcp://192.168.200.145/system.
> 
> I have confirmed the problem is because the two hosts have the same
> hostname: localhost.localdomain that is quite common as people usually don't
> configure any hostname for machines. I don't see any need that libvirt looks
> up the hostnames for both hosts, as the IP address is good enough for data
> transferring during the migration.

Your host could have multiple IP addresses. The host name checking is annoying but if we get it wrong and migrate to the same host, libvirt deadlocks, so we have to be overly strict. I don't think there's anything that will change in libvirt here, you just have to set up proper hostnames to get working migration. Closing as DEFERRED but please reopen if I've missed something


Note You need to log in before you can comment on or make changes to this bug.