[libvirt] Possibly deadlock with tunnelled migration

[Daniel P. Berrange]

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.

> 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.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|