5aadff75c3
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 |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref/source | ||
| playbooks/legacy | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-py3.txt | ||
| tox.ini | ||
README.rst
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: