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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list