On 11/11/2009 03:04 AM, Daniel P. Berrange wrote: > On Tue, Nov 10, 2009 at 09:05:46PM -0500, Cole Robinson wrote: >> Hi Chris (and list), >> >> Playing with TUNNELLED migration, I'm hitting an issue. Take this example: >> >> VM URI = qemu+ssh://phys1/system >> destconn = qemu:///system >> >> invoking virDomainMigrate with a VM from the former URI, and destconn as the >> latter, we will deadlock. The qemu driver would be reopening it's local >> qemu:///system, and eventually lock up. We should probably add some sanity >> checking for the URI we plan to open. > > It shouldn't be deadlocking on the virConnectOpen() call itself, so the > way to deal with this is to call virConnectGetHostname() on both conn > objects, and if they match, then abort the migration attempt. > Right, the deadlock comes later, when we actually call into the connection object. >> Aside from that, anyone have recommendations on the best way to handle the >> above situation? I'm currently improving the migration support in >> virt-manager, and if the TUNNELLED API requires opening a URI, it makes the >> remote-to-local migration case a bit annoying, because we would have to >> require the user to provide a remote accessible URI for the local system. > > Again I think virConnectGetHostname() is helpful here - if you don't want > to prompt the user, then you'll need to canonicalize the local URI by adding > in the default hostname associated with it. Of course this relies on the > user having configured the local libvirtd to listen on TCP or TLS sockets. > Right, the latter piece is the issue. I figure I'll just duplicate whatever auth the source connection URI is using (ssh, tcp, etc.) and try to build a remote URI for localhost. - Cole -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list