nova/releasenotes/notes/live_migration_wait_for_vif_plug-c9dcb034067890d8.yaml
Matt Riedemann 5aadff75c3 Wait for network-vif-plugged before starting live migration
This adds a new config option which is read on the destination host
during pre_live_migration and the value is returned back to the
source host, which can be used to determine, from the source host,
if it should wait for a "network-vif-plugged" event due to VIFs
being plugged on the destination host. This helps us to
avoid the guest transfer at all if vif plugging failed on the dest
host, which we just wouldn't find out until post live migration
and then we have to rollback.

The option is disabled by default for backward compatibility and
also because certain networking backends, like OpenDaylight, are
known to not send network-vif-plugged events unless the port host
binding information changes, which for live migration doesn't happen
until after the guest is transferred to the destination host.

We could arguably avoid the changes to the live migrate data
versioned object and just assume the same networking backend is
used within each cell, but this does allow the deployer to have
the flexibility of live migrating between different network
backends (eventually anyway). The ability to live migrate between
different VIF types is being worked on as part of blueprint
neutron-new-port-binding-api.

Related to blueprint neutron-new-port-binding-api

Change-Id: I0f3ab6604d8b79bdb75cf67571e359cfecc039d8
2018-06-19 18:21:29 -04:00

21 lines
1.1 KiB
YAML

---
other:
- |
A new configuration option, ``[compute]/live_migration_wait_for_vif_plug``,
has been added which can be used to configure compute services to wait
for network interface plugging to complete on the destination host before
starting the guest transfer on the source host during live migration.
Note that this option is read on the destination host of a live migration.
If you set this option the same on all of your compute hosts, which you
should do if you use the same networking backend universally, you do not
have to worry about this.
This is disabled by default for backward compatibilty and because the
compute service cannot reliably determine which types of virtual
interfaces (``port.binding:vif_type``) will send ``network-vif-plugged``
events without an accompanying port ``binding:host_id`` change.
Open vSwitch and linuxbridge should be OK, but OpenDaylight is at least
one known backend that will not currently work in this case, see bug
https://launchpad.net/bugs/1755890 for more details.