Open Stack

On Wed, Aug 24, 2016 at 05:07:50PM +0200, Alberto Planas Dominguez wrote:
> Unfortunately was closed as invalid, and the solution provided is
> completely unrelated. The solution suggested is based on
> `live_migration_inbound_addr`, that is related with the libvirtd URI,
> not the qmeu one. I tested several times and yes, this solution is not
> related with the problem.

The "live_migration_inbound_addr" configuration parameters was intended
to affect both libvirt & QEMU traffic. If that is not working correctly,
then we should be fixing that, nto adding yet another parameter.

> 
> I worked in a patch for mater here:
> 
> https://review.openstack.org/#/c/356558/
> 
> This patch worked as expected. This create a second URI, based on the
> hostname given in live_migration_uri parameter, to build a second one
> that will be used by qemu/kvm for the second connection.
> 
> So, for example if:
> 
> live_migration_uri=qemu+tcp://fast.%s/system
> 
> this patch will create a second uri:
> 
> migrate_uri=tcp://fast.%s/

While you can do that hack, the fact that is works is simply luck - it
certainly was not designed with this kind of usage in mind. We would
in fact like to remove the live_migration_uri config parameter entirely
and having the libvirt driver automatically use the correct URI. As such
adding further URI config parmaeters is not a direction we want to go
in.

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 :|