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.