[openstack-dev] [nova] Enabling VM post-copy live migration

John Garbutt john at johngarbutt.com
Thu Mar 12 11:34:25 UTC 2015


On 12 March 2015 at 08:41, Luis Tomas <luis at cs.umu.se> wrote:
> Hi,
>
> As part of an European (FP7) project, named ORBIT
> (http://www.orbitproject.eu/), I'm working on including the possibility of
> live-migrating VMs in OpenStack in a post-copy mode.
> This way of live-migrating VMs basically moves the computation right away to
> the destination and then the VM starts working from there, while still
> copying the memory from the source to the new location of the VM. That way
> the memory pages are only copied as if the VM modifies them, they are
> already in the destination host. This basically ensures that migrations
> finish regardless of what the VM is doing, i.e., even extremely memory
> intensive VMs. Therefore removing the problem of having VMs hanging on in
> migrating state forever (as discussed in previous mails, e.g.,
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/055725.html).
>
> So far, I have included and tested this new functionality at the JUNO
> version, and the code modifications can be found in the github repository of
> the project (branch named "post-copy"):
>     - https://github.com/orbitfp7/nova/tree/post-copy --> mainly enabling
> the possibility of using the libvirt post-copy flag (libvirt driver.py).
> Note post-copy migration is not using "tunneling" as LibVirt patch for that
> is not yet ready.
>     - https://github.com/orbitfp7/python-novaclient/tree/post-copy -->
> adding the possibility of using the post-copy mode when triggering the
> migration: nova live-migration [--block-migrate] [--post-copy] VM_ID
>     - https://github.com/orbitfp7/horizon/tree/post-copy --> include a
> checkbox in the live-migration panel to perform the migration in post-copy
> mode. (like the one for enabling block-migration)
>
> To be able to live-migrate VMs in a post-copy way, I'm relying on some
> kernel+qemu+libvirt modifications, not yet merged upstream (but in their way
> to it), also available at the project github:
>     - Kernel: https://lkml.org/lkml/2015/3/5/576
>     - Qemu: https://github.com/orbitfp7/qemu/tree/wp3-postcopy
>     - LibVirt: https://github.com/orbitfp7/libvirt/tree/wp3-postcopy

Before merging the code in Nova, we usually like the dependent
features to be released by the respective projects.

Ideally we would like it to be easy to run that on some distro so
people could test/use the feature fairly easily.

> If this is a nice feature to have in future versions of OpenStack, I'm happy
> to adapt the code for the next release (the one after KILO). Any comments
> are really welcome.

It sounds like something that doesn't need an API call, as its a
deployer choice if they have support for this new live-migrate mode.
Is that true?

Although maybe it has a substantial runtime penalty as a page read
miss causes a fetch across the network, making it a user choice? Or do
you only start the fetch mode at the point you detect a failure to
"merge" using the regular live-migrate mode?

Thanks,
John



More information about the OpenStack-dev mailing list