[openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options
pawel.koniszewski at intel.com
Tue Aug 2 14:36:32 UTC 2016
In Mitaka development cycle 'live_migration_flag' and 'block_migration_flag' have been marked as deprecated for removal. I'm working on a patch  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  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.
More information about the OpenStack-dev