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.
__________________________________________________________________________ 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
