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
Team and repository tags
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: