Open Stack

Hi all,

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 
available at
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 
triggered.

- 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 
network traffic.

Any input/review of the updated patch set is really welcome.

Thanks,
Luis


On 04/05/2016 05:17 PM, Luis Tomas wrote:
> Hi,
>
> 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?
>
> Thanks!
>
> Best regards,
> Luis
>


-- 
-----------------------------------
Dr. Luis Tomás
Postdoctoral Researcher
Department of Computing Science
Umeå University
luis at cs.umu.se
www.cloudresearch.se
www8.cs.umu.se/~luis
------------------------------------

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