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
l...@cs.umu.se
www.cloudresearch.se
www8.cs.umu.se/~luis
------------------------------------
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
