Go to file
Matthew Booth b626c0dc7b Avoid redundant initialize_connection on source post live migration
During live migration we update bdm.connection_info for attached volumes
in pre_live_migration to reflect the new connection on the destination
node. This means that after migration completes the BDM no longer has a
reference to the original connection_info to do the detach on the source
host. To address this, change I3dfb75eb added a second call to
initialize_connection on the source host to re-fetch the source host
connection_info before calling disconnect.

Unfortunately the cinder driver interface does not strictly require that
multiple calls to initialize_connection will return consistent results.
Although they normally do in practice, there is at least one cinder
driver (delliscsi) which doesn't. This results in a failure to
disconnect on the source host post migration.

This change avoids the issue entirely by fetching the BDMs prior to
modification on the destination node. As well as working round this
specific issue, it also avoids a redundant cinder call in all cases.

Note that this massively simplifies post_live_migration in the libvirt
driver. The complexity removed was concerned with reconstructing the
original connection_info. This required considering the cinder v2 and v3
use cases, and reconstructing the multipath_id which was written to
connection_info by the libvirt fibrechannel volume connector on
connection. These things are not necessary when we just use the original
data unmodified.

Other drivers affected are Xenapi and HyperV. Xenapi doesn't touch
volumes in post_live_migration, so is unaffected. HyperV did not
previously account for differences in connection_info between source and
destination, so was likely previously broken. This change should fix it.

Closes-Bug: #1754716
Closes-Bug: #1814245
Change-Id: I0390c9ff51f49b063f736ca6ef868a4fa782ede5
2019-02-13 13:33:02 +00:00
2018-10-18 17:55:36 -04:00
2019-02-06 14:38:56 -05:00
2018-12-08 04:56:56 +00:00
2018-08-10 20:04:19 +00:00
2018-11-28 03:38:41 +00:00
2014-05-07 12:14:26 -07:00
2017-11-24 16:51:12 -05:00
2012-02-08 19:30:39 -08:00
2018-01-12 17:05:11 +08:00
2010-05-27 23:05:26 -07:00
2017-09-07 15:42:31 +02:00
2018-03-24 20:27:11 +08:00
2017-03-02 11:50:48 +00:00
2019-02-06 19:41:15 +00:00

Team and repository tags

image

OpenStack Nova

OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.

Use the following resources to learn more.

API

To learn how to use Nova's API, consult the documentation available online at:

For more information on OpenStack APIs, SDKs and CLIs in general, refer to:

Operators

To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:

In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:

Developers

For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.

Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.

Further developer focused documentation is available at:

Other Information

During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at:

Description
OpenStack Compute (Nova)
Readme 1.6 GiB
Languages
Python 97.5%
Smarty 2.3%
Shell 0.2%