[openstack-dev] [Nova][Neutron][Live-Migration] Cross l2 agent migration and solving Nova-Neutron live migration bugs

Carl Baldwin carl at ecbaldwin.net
Wed Jun 29 21:20:03 UTC 2016


On Tue, Jun 28, 2016 at 9:42 AM, Andreas Scheuring
<scheuran at linux.vnet.ibm.com> wrote:
> I'm currently working on solving Nova-Neutron issues during Live
> Migration. This mail is intended to raise awareness cross project and
> get things kicked off.

Thanks for sending this.

> The issues
> ==========
>
> #1 When portbinding fails, instance is migrated but stuck in error state
> #2 Macvtap agent live Migration when source and target use different
> physical_interface_mapping [3]. Either the migration fails (good case)
> or it would place the instance on a wrong network (worst case)
> #3 (more a feature):  Migration cross l2 agent not possible (e.g.
> migrate from lb host to ovs host, or from ovs-hybrid to new ovsfirewall
> host)

Since all of these issues are experienced when using live migration, a
Nova feature, I was interested in finding out how Nova prioritizes
getting a fix and then trying to align Neutron's priority to that
priority.  It would seem artificial to me to drive priority from
Neutron.  That's why I mentioned it.  Since Nova is hitting a freeze
for non-priority work tomorrow, I don't think anything can be done for
Newton.  However, there is a lot of time to tee up this conversation
for Ocata if we get on it.

> The proposal
> ============
> All those problems could be solved with the same approach . The proposal
> is, to bind a port to the source AND to the target port during
> migration.
>
> * Neutron would need to allow multiple bindings for a compute port and
> externalize that via API.
>   - Neutron Spec [1]
>   - Bug [4]  is a prereq to the spec.
>
> * Nova would need to use those new APIs to check in pre_live_migration,
> if the binding for target host is valid and to modify the instance
> definition (e.g. domain.xml) during migration.
>   - Nova Spec [2]
>
> This would solve the issues in the following way:
> #1 would abort the migration before it started, so instance is still
> usable
> #2 Migration is possible with all configurations
> #3 would allow such a migration
>
> Coordination
> ============
> Some coordination between Nova & Neutron is required. Along todays Nova
> Live Migration Meeting [5] this will happen on the Nova midcycle. I put
> an item on the agenda [6].

I'll be there.

> Would be great that anybody that is interested in this bugfix/feature
> could comment on the specs [1] or [2] to get as much feedback as
> possible before the nova midcycle in July!
>
> Thank you!

>
> [1] Neutron spec: https://review.openstack.org/#/c/309416
> [2] Nova spec: https://review.openstack.org/301090
> [3] macvtap bug: https://bugs.launchpad.net/neutron/+bug/1550400
> [4] https://bugs.launchpad.net/neutron/+bug/1367391
> [5]
> http://eavesdrop.openstack.org/meetings/nova_live_migration/2016/nova_live_migration.2016-06-28-14.00.log.html
>
> [6] https://etherpad.openstack.org/p/nova-newton-midcycle



More information about the OpenStack-dev mailing list