<div dir="ltr">Hi, <div><br></div><div>Taking into account everything above I'd prefer to see live_migration_tunnelled(that corresponds to <span style="font-size:12.8px">VIR_MIGRATE_TUNNELLED</span>) defaulted to False. We just need to make a release note for this change, and on the host startup do LOG.warning to notify the operator that there are no tunnels for live-migration. For me, it will be enough. Then just put [1] on top of it.</div><div><br></div><div>Thanks, </div><div>Timofey</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 5:36 PM, Koniszewski, Pawel <span dir="ltr"><<a href="mailto:pawel.koniszewski@intel.com" target="_blank">pawel.koniszewski@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In Mitaka development cycle 'live_migration_flag' and 'block_migration_flag' have been marked as deprecated for removal. I'm working on a patch [1] to remove both of them and want to ask what we should do with live_migration_tunnelled logic.<br>
<br>
The default configuration of both flags contain VIR_MIGRATE_TUNNELLED option. It is there to avoid the need to configure the network to allow direct communication between hypervisors. However, tradeoff is that it slows down all migrations by up to 80% due to increased number of memory copies and single-threaded encryption mechanism in Libvirt. By 80% here I mean that transfer between source and destination node is around 2Gb/s on a 10Gb network. I believe that this is a configuration issue and people deploying OpenStack are not aware that live migrations with this flag will not work. I'm not sure that this is something we wanted to achieve. AFAIK most operators are turning it OFF in order to make live migration usable.<br>
<br>
Going to a new flag that is there to keep possibility to turn tunneling on - Live_migration_tunnelled [2] which is a tri-state boolean - None, False, True:<br>
<br>
* True - means that live migrations will be tunneled through libvirt.<br>
* False - no tunneling, native hypervisor transport.<br>
* None - nova will choose default based on, e.g., the availability of native encryption support in the hypervisor. (Default value)<br>
<br>
Right now we don't have any logic implemented for None value which is a default value. So the question here is should I implement logic so that if live_migration_tunnelled=None it will still use VIR_MIGRATE_TUNNELLED if native encryption is not available? Given the impact of this flag I'm not sure that we really want to keep it there. Another option is to change default value of live_migration_tunnelled to be True. In both cases we will again end up with slower LM and people complaining that LM does not work at all in OpenStack.<br>
<br>
Thoughts?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/334860/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/334860/</a><br>
[2] <a href="https://github.com/openstack/nova/blob/be59c19c969acf6b25b0711f0ebfb26aaed0a171/nova/conf/libvirt.py#L107" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/be59c19c969acf6b25b0711f0ebfb26aaed0a171/nova/conf/libvirt.py#L107</a><br>
<br>
Kind Regards,<br>
Pawel Koniszewski<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>