libvirt users - May 2014 - Is tunnelled "managed direct" live migration actually possible?

I have three servers set up as in this diagram:

  http://libvirt.org/migration.html#flowmanageddirect

My control application has separate libvirt connections to both the
source and destination nodes.  I want to migrate entirely over those
connections, not involving any third (peer-to-peer) connection between
nodes (a third connection isn't possible because of firewalls and SSH
keys).

Is this actually possible?  I've been playing with the API and reading
docs, and it seems like "direct managed" migration is simply not
possible :-(

  dom.migrate (dconn, libvirt.VIR_MIGRATE_LIVE|libvirt.VIR_MIGRATE_TUNNELLED)
  libvirt.libvirtError: Requested operation is not valid: cannot perform
tunnelled migration without using peer2peer flag

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

On Thu, May 08, 2014 at 10:29:37PM +0100, Richard W.M. Jones
wrote:
> I have three servers set up as in this diagram:
> 
>   http://libvirt.org/migration.html#flowmanageddirect
> 
> My control application has separate libvirt connections to both the
> source and destination nodes.  I want to migrate entirely over those
> connections, not involving any third (peer-to-peer) connection between
> nodes (a third connection isn't possible because of firewalls and SSH
> keys).
> 
> Is this actually possible?  I've been playing with the API and reading
> docs, and it seems like "direct managed" migration is simply not
> possible :-(
IIUC, you want the migration data stream to flow from source libvirtd
to client app, then from client app to dest libvirtd ?  If so, that is
not possible. For QEMU at least, either the libvirtd daemons need to
be able to talk to each other direct with data tunnelled between them,
or the QEMU processes need to be able to talk to each other directly
(with migration controlled from client);

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|