Re: [libvirt] Possibly deadlock with tunnelled migration
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 :|