[libvirt] Possibly deadlock with tunnelled migration

[Cole Robinson]

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