[openstack-dev] [nova] Removal of live_migration_flag and block_migration_flag config options
tdurakov at mirantis.com
Tue Aug 2 15:14:54 UTC 2016
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
 on top of it.
On Tue, Aug 2, 2016 at 5:36 PM, Koniszewski, Pawel <
pawel.koniszewski at 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  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 - 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.
>  https://review.openstack.org/#/c/334860/
> Kind Regards,
> Pawel Koniszewski
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev