Open Stack

On 26/11/15 15:55, 少合冯 wrote:
> Hi all,
> We want to support xbzrle compress for live migration.
>
> Now there are 3 options,
> 1. add the enable flag in nova.conf.
>     such asa dedicated 'live_migration_compression=on|off" parameter 
> in nova.conf.
>     And nova simply enable it.
>     seems not good.
> 2.  add a parameters in live migration API.
>
> A new array compress will be added as optional, the json-schema as below::
>
>   {
>     'type': 'object',
>     'properties': {
>       'os-migrateLive': {
>         'type': 'object',
>         'properties': {
>           'block_migration': parameter_types.boolean,
>           'disk_over_commit': parameter_types.boolean,
>           'compress': {
>             'type': 'array',
>             'items': ["xbzrle"],
>           },
>           'host': host
>         },
>         'additionalProperties': False,
>       },
>     },
>     'required': ['os-migrateLive'],
>     'additionalProperties': False,
>   }
>
>
> 3. dynamically choose when to activate xbzrle compress for live migration.
>    This is the best.
>  xbzrle really wants to be used if the network is not able to keep up 
> with the dirtying rate of the guest RAM.
>    But how do I check the coming migration fit this situation？
>
>
> REF:
> https://review.openstack.org/#/c/248465/
>
>
> BR
> Shaohe Feng

Feels to me that this is too implementation dependent to be exposed in 
API.  I've seen elsewhere
discussion about removing the block migrate and disk over commit 
parameters, the idea being it
would figure out the type of migration for itself and over commit is not 
needed anymore.

Seems to me the prevailing view is that we should get live migration to 
figure out the best setting for
itself where possible.  There was discussion of being able have a 
default policy setting that will allow
the operator to define balance between speed of migration and impact on 
the instance.  This could be
a global default for the cloud with overriding defaults per aggregate, 
image, tenant and instance as
well as the ability to vary the setting during the migration operation.

Seems to me that items like compression should be set in configuration 
files based on what works best
given the cloud operator's environment?

-- 
Paul Carlton
Software Engineer
Cloud Services
Hewlett Packard
BUK03:T242
Longdown Avenue
Stoke Gifford
Bristol BS34 8QZ

Mobile:    +44 (0)7768 994283
Email:    mailto:paul.carlton2 at hpe.com
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England.
The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151126/b41e44a1/attachment.html>