Open Stack

The following summarizes status of the main topics relating to live migration after the Newton design summit. Please feel free to correct any inaccuracies or add additional information.

Paul

-------------------------------------------------------------

Libvirt storage pools

The storage pools work has been selected as one of the project review priorities for Newton.
(see https://etherpad.openstack.org/p/newton-nova-summit-priorities )

Continuation of the libvirt storage pools work was discussed in the live migration session. The proposal has grown to include a refactor of the existing libvirt driver instance storage code. Justification for this is based on three factors:

1.       The code needs to be refactored to use storage pools

2.       The code is complicated and uses inspection, poor practice

3.       During the investigation Matt Booth discovered two CVEs in the code - suggesting further work is justified

So the proposal is now to follow three stages:

1.       Refactor the instance storage code

2.       Adapt to use storage pools for the instance storage

3.       Use storage pools to drive resize/migration

Matt has code already starting the refactor and will continue with help from Paul Carlton + Paul Murray. We will look for additional contributors to help as we plan out the patches.

https://review.openstack.org/#/c/302117 : Persist libvirt instance storage metadata
https://review.openstack.org/#/c/310505 : Use libvirt storage pools
https://review.openstack.org/#/c/310538 : Migrate libvirt volumes

Post copy

The spec to add post copy migration support in the libvirt driver was discussed in the live migration session. Post copy guarantees completion of a migration in linear time without needing to pause the VM. This can be used as an alternative to pausing in live-migration-force-complete. Pause or complete could also be invoked automatically under some circumstances. The issue slowing these specs is how to decide which method to use given they provide a different user experience but we don't want to expose virt specific features in the API. Two additional specs listed below suggest possible generic ways to address the issue.

There was no conclusions reached in the session so the debate will continue on the specs. The first below is the main spec for the feature.

https://review.openstack.org/#/c/301509 : Adds post-copy live migration support to Nova
https://review.openstack.org/#/c/305425 : Define instance availability profiles
https://review.openstack.org/#/c/306561 : Automatic Live Migration Completion

Live Migration orchestrated via conductor

The proposal to move orchestration of live migration to conductor was discussed in the working session on Friday, presented by Andrew Laski on behalf of Timofey Durakov. This one threw up a lot of debate both for and against the general idea, but not supporting the patches that have been submitted along with the spec so far. The general feeling was that we need to attack this, but need to take some simple first cleanup steps first to get a better idea of the problem. Dan Smith proposed moving the stateless pre-migration steps to a sequence of calls from conductor (as opposed to the going back and forth between computes) as the first step.

https://review.openstack.org/#/c/292271 : Remove compute-compute communication in live-migration

Cold and Live Migration Scheduling

When this patch merges all migrations will use the request spec for scheduling: https://review.openstack.org/#/c/284974
Work is still ongoing for check destinations (allowing the scheduler to check a destination chosen by the admin). When that is complete migrations will have three ways to be placed:

1.       Destination chosen by scheduler

2.       Destination chosen by admin but checked by scheduler

3.       Destination forced by admin

https://review.openstack.org/#/c/296408 Re-Proposes to check destination on migrations

PCI + NUMA claims

Moshe and Jay are making great progress refactoring Nicola's patches to fix PCI and NUMA handling in migrations. The patch series should be completed soon.

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