[libvirt] Possibly deadlock with tunnelled migration
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. 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. Thanks, Cole
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 :|
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
participants (2)
-
Cole Robinson -
Daniel P. Berrange