[libvirt] [PATCH] Fix failing virGetHostname.

[Chris Lalancette]

On 05/24/2010 04:50 PM, Cole Robinson wrote:
> On 05/24/2010 04:17 PM, Chris Lalancette wrote:
>> On 05/21/2010 12:27 PM, Cole Robinson wrote:
>>> Hmm, why isn't one of the fallback options:
>>>
>>> if (conn)
>>>     hostname = parse_uri(conn.get_uri())
>>>     if hostname != "localhost":
>>> 	return hostname
>>>
>>> Seems like if MigratePrepare2 dconn is the remote connection, we are
>>> guaranteed to have a resolvable hostname in the URI (well, resolvable to
>>> the source connection at least).
>>
>> (sorry I was late in replying to this)
>>
>> The thing is, I don't think that is generally going to be useful.  At the
>> moment, all of the callers pass NULL as conn.  Even if we were to make
>> some of the callers pass a real conn, because of the way the remote driver
>> works it doesn't really map back to the IP address you care about.  That is,
>> at the place where you are running virsh (for instance), conn.uri() is actually
>> something useful.  But by the time you've remoted through the remote_driver and
>> made it to the remote libvirtd on the destination of the migration, you are
>> really doing a "local" connection from libvirtd to the qemu driver, so
>> conn.uri() basically contains "qemu:///system", which is not particularly
>> helpful.
>>
> 
> My bad, I figured dconn had the same URI on the dest host as it did on
> the source host. ACK to this patch then.
> 
> Maybe for the future we should consider always building a manual migrate
> URI in virsh.c (or maybe libvirt.c), using the destination connection
> URI hostname. This is what we do in virt-manager, since it's really it
> gives the closest guarantee for success.

Thanks for the review.  I've now pushed this patch, as it seems to resolve
most of the problems we are having with resolving localhost.

-- 
Chris Lalancette