On 03/24/2010 03:36 PM, Cole Robinson wrote: > On 03/24/2010 09:36 AM, Chris Lalancette wrote: >> On 03/23/2010 11:00 AM, Kenneth Nagin wrote: >>> Changing qemudDomainMigratePrepare2 call to virGetHostnameLocalhost >>> from: if ((hostname = virGetHostnameLocalhost(0)) == NULL) >>> to: if ((hostname = virGetHostnameLocalhost(1)) == NULL) >>> seems to fix the problem. >>> But maybe this is only masking a another problem. >> >> Yeah, you are masking another problem. The problem is that this portion >> of migration is running on the destination of the migration, and generating >> a string that the source of the migration will use to perform the migration. >> By passing the 1 flag to virGetHostnameLocalhost, you are allowing it to >> return "localhost" as the string. This means that when the source tries >> to migrate, it will actually try to migrate to "localhost", not the >> destination, and fail in complicated-to-debug ways. >> >> The actual problem you have is that the "hostname" command on your >> machine is returning a string that resolves to localhost, probably because of >> a misconfiguration in /etc/hosts. >> > > In this case, the destination is a host that the user already has a > valid remote libvirt URI for: maybe if 'hostname' doesn't work, we can > fallback to use the hostname portion of the remote URI? I can have a > static mapping in my local /etc/hosts for some remote machine without > 'hostname' output. Yeah, that's a pretty good idea. We still need to make sure that we don't eventually resolve to "localhost", but at least your suggestion would fix the situation you describe above. -- Chris Lalancette -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list