Open Stack

On Thu, Aug 25, 2016 at 12:01:40PM +0200, Alberto Planas Dominguez wrote:
> On Wed, 2016-08-24 at 11:18 -0400, Daniel P. Berrange wrote:
> > On Wed, Aug 24, 2016 at 05:07:50PM +0200, Alberto Planas Dominguez
> > wrote:
> 
> Daniel, thanks for the fast reply!!
> 
> > > 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.
> 
> The code in libvirt is very clear: if uri_in is NULL will ask to the
> hostname to the other side. I checked the code in 1.2.18:
> 
> https://github.com/libvirt/libvirt/blob/v1.2.18-maint/src/qemu/qemu_mig
> ration.c#L3601
> 
> https://github.com/libvirt/libvirt/blob/v1.2.18-maint/src/qemu/qemu_mig
> ration.c#L3615
> 
> The same logic is in master:
> 
> https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_migration.
> c#L4013
> 
> But we can go back to 0.9.12:
> 
> https://github.com/libvirt/libvirt/blob/v0.9.12-maint/src/qemu/qemu_mig
> ration.c#L1472
> 
> Nova set migration_uri parameter to None, that this means that uri_in
> is NULL.
> 
> How can I affect the the QEMU part? The code path AAIU is: if we do not
> set miguri (migrateToURI2) or migrate_uri (migrateToURI3), is a
> uri_in=NULL.
> 
> I am not familiar with libvirt code, please, help me to find how I can
> affect this uri_in parameter to have a value different from the
> hostname of the other node, without setting the correct value in
> migrateToURI[23] in the Nova side.

I think where the confusion is coming is that libvirt will work in two
different ways with P2P migration. If the TUNNELLED flag is set, then the
migration data will go over the Libvirtd <-> libvirtd connection, which is
influenced by the live_migration_inbound_addr parameter. If the TUNNELED
flag is not set the data is QEMU <-> QEMU directly, and that needs the
extra URI set.

What we need todo is fix the Nova code so that when the TUNNELLED flag
is *not* set, we also provide the extra URI, using the hostname/ip addr
listed in live_migration_inbound_addr, falling back to the compute hostname
if live_migration_inbound_addr is not set.


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