Bug 1312204

Summary: libvirtd (libvirt) 1.2.17 breaks the behavior of using IP for migration
Product: [Community] Virtualization Tools Reporter: Frank Zhang <xing5820>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED DEFERRED QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: crobinso, dyuan, rbalakri, xing5820, zpeng
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-20 13:38:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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