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:[email protected]
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".

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to