Open Stack

Hi!

I have a question about live migration in a p2p scenario. We have a
deployment where the compute nodes have several interfaces. The
hostname is associate with one of them, that is used for nova to do all
the communication, and also the live migration.

The thing is that we want to use the fast interface to do the live
migration. According to the documentation this is easy:

* Configure libvirtd to listen in the fast interface in every compute
node

* Configure in nova.conf live_migration_uri to point to the correct URI
where libvirtd is listening

* Done!

Doing this makes the live-migration works ... but in the slow
interface!

Digging into libvirt driver for nova, looks like that the problem is
that in a p2p there are two connections. One to libvirtd level, and
another in the qemu/kvm level. The first one is the one configured with
the live_migration_uri parameter, but the second one is not configured
anywhere in nova.

The second connection is were the bulk of data is happening, according
to `iftop`. Digging a bit more, I discover that I can force the
interface where qemu will listen (parameter -incoming in qemu), but we
need to pass the correct URI from the nova side.

I consider this a bug, and I created this bug report:

https://bugs.launchpad.net/nova/+bug/1614063

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.

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/

that is used in the libvirt API migrateToURI[23] to specify the URI for
QEMU.

This worked. I backported it to Mitaka and Liberty and works as
expected (checked with and w/out the patch with iftop several times)

The thing is that this patch and solution can not be discussed further
because the bug related was marked as invalid, but the issue is still
there.

I checked and rechecked the comments in the bug report to make sure
that I am not missing something. But I am unable to!

So, if the patch and the bug are not valid, how can I do a p2p live
migration when both connections (the libvirtd one, used as a first
parameter in migrateToURI[23], and miguri parameter in the same API)
are pointing to the same interface?


-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham
Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany