8:05 p.m.
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
2:04 a.m.
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 :|
8:01 a.m.
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
5491
days inactive
5491
days old
2 comments
2 participants
participants (2)
-
Cole Robinson -
Daniel P. Berrange