Hi, Taking into account everything above I'd prefer to see live_migration_tunnelled(that corresponds to VIR_MIGRATE_TUNNELLED) 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.
Thanks, Timofey On Tue, Aug 2, 2016 at 5:36 PM, Koniszewski, Pawel < pawel.koniszew...@intel.com> wrote: > 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. > > 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. > > 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: > > * True - means that live migrations will be tunneled through libvirt. > * False - no tunneling, native hypervisor transport. > * None - nova will choose default based on, e.g., the availability of > native encryption support in the hypervisor. (Default value) > > 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. > > Thoughts? > > [1] https://review.openstack.org/#/c/334860/ > [2] > https://github.com/openstack/nova/blob/be59c19c969acf6b25b0711f0ebfb26aaed0a171/nova/conf/libvirt.py#L107 > > Kind Regards, > Pawel Koniszewski > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
