be553fb155
In swap_volume method of nova/virt/libvirt/driver.py, before BDM was got by using the instance's UUID and 'serial' of new connection_info as the volume ID, and driver BDM was updated by using the BDM. ('serial' has the volume ID information.) But in _init_volume_connection method in ComputeManager class, 'serial' is passed from old connection_info to new connection_info. It works fine in the case that cinder initiates swapping volumes because the ID of the attached volume isn't changed after swapping volumes. But in the case that nova initiates swapping volumes, the ID of the attached volume is changed. So in the case that nova initiated swapping volumes, after swap volume function was performed once, BDM was got by wrong old volume id (serial) when swap volume function was performed for the second time. So if 'serial' of new connection_info is None, it is set to new volume ID. And if cinder 'migrate_volume_completion' API returns old volume ID (the case that cinder initiates swapping volumes), the 'serial' of new connection_info is set to old volume ID. If cinder 'migrate_volume_completion' API returns new volume ID (the case that nova initiated swapping volumes), the 'serial' is left as it is (new volume ID). Change-Id: I86b8fbb09b0f1ed4c667683de3827cd9b63bca7f Closes-Bug: #1490236 |
||
---|---|---|
api-guide/source | ||
api-ref/source | ||
contrib | ||
devstack | ||
doc | ||
etc/nova | ||
nova | ||
plugins/xenserver | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.testr.conf | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
MAINTAINERS | ||
README.rst | ||
babel.cfg | ||
bandit.yaml | ||
bindep.txt | ||
requirements.txt | ||
run_tests.sh | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tests-py3.txt | ||
tox.ini |
README.rst
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 and OpenStack Ironic.
OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.
API
To learn how to use Nova's API, consult the documentation available online at:
http://developer.openstack.org/api-guide/compute/ http://developer.openstack.org/api-ref/compute/
For more information on OpenStack APIs, SDKs and CLIs, please see:
http://www.openstack.org/appdev/ http://developer.openstack.org/
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
For information about the different compute (hypervisor) drivers supported by Nova, please read:
http://docs.openstack.org/developer/nova/feature_classification.html
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: