[openstack-dev] [nova] post-copy live migration
luis at cs.umu.se
Wed May 4 07:56:09 UTC 2016
Based on Live Migration IRC meeting discussions, I've uploaded an
updated patch set for the "add post-copy live migration support to Nova"
specs (https://review.openstack.org/#/c/301509/). Based on that
discussions, the proposed way of including the post-copy live migration
capability is the next:
- To enable the use of post-copy, a new config option will be made
nova.conf, `live_migration_postcopy`, similarly
to`live_migration_tunnelled`one. If `True`, the
libvirt postcopy flag `VIR_MIGRATE_POSTCOPY` will be used, if supported,
making the migration ready to be switched to post-copy mode.
- To trigger the switch to post-copy mode, an automatic mechanism will
be implemented based on the number
of memory iterations done by the ongoing migration. When the number of
iterations is greater than a defined threshold, the switch will be
- Similarly to the `live_migration_bandwidth` parameter, the number of
memory iterations before the switch to postcopy will be defined in
another configuration parameter named
`live_migration_postcopy_max_iterations`, allowing a more or less
aggressive switch to post-copy. For instance, it could be set to a small
number (even 0) for evacuation purposes, minimizing the amount of
Any input/review of the updated patch set is really welcome.
On 04/05/2016 05:17 PM, Luis Tomas wrote:
> We are working on the possibility of including post-copy live
> migration into Nova (https://review.openstack.org/#/c/301509/)
> At libvirt level, post-copy live migration works as follow:
> - Start live migration with a post-copy enabler flag
> (VIR_MIGRATE_POSTCOPY). Note this does not mean the migration is
> performed in post-copy mode, just that you can switch it to post-copy
> at any given time.
> - Change the migration from pre-copy to post-copy mode.
> However, we are not sure what's the most convenient way of providing
> this functionality at Nova level.
> The current specs, propose to include an optional flag at the live
> migration API to include the VIR_MIGRATE_POSTCOPY flag when starting
> the live migration. Then we propose a second API to actually switch
> the migration from pre-copy to post-copy mode similarly to how it is
> done in LibVirt. This is also similar to how the new "force-migrate"
> option works to ensure migrations completion. In fact, this method
> could be an extension of the force-migrate, by switching to postcopy
> if the migration was started with the VIR_MIGRATE_POSTCOPY libvirt
> flag, or pause it otherwise.
> The cons of this approach are that we expose a too specific mechanism
> through the API. To alleviate this, we could remove the "switch" API,
> and automatize the switch based on data transferred, available
> bandwidth or other related metrics. However we will still need the
> extension to the live-migration API to include the proper libvirt
> postcopy flag.
> The other solution is to start all the migrations with the
> VIR_MIGRATE_POSTCOPY mode, and therefore no new APIs would be needed.
> The system could automatically detect the migration is taking too long
> (or is dirting memory faster than the sending rate), and automatically
> switch to post-copy.
> The cons of this is that including the VIR_MIGRATE_POSTCOPY flag has
> an overhead, and it will not be desirable to included for all
> migrations, specially is they can be nicely migrated with pre-copy
> mode. In addition, if the migration fails after the switching, the VM
> will be lost. Therefore, admins may want to ensure that post-copy is
> not used for some specific VMs.
> I would like to know your opinion in this? What option would be
> preferred? Is there a different option we are missing?
> Best regards,
Dr. Luis Tomás
Department of Computing Science
luis at cs.umu.se
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev