Before, the definition of live_migration_downtime didn't explain
if any exception/timeout occurs if the migration exceeds the value.
This is just used as a reference for nova and if any problem happens
when the VM gets paused, there will be no abort or force-complete.
Closes-Bug: #1960345
Signed-off-by: Pedro Almeida <pedro.monteiroazevedodemouraalmeida@windriver.com>
Change-Id: I336481d1801a367b5628fedcd2aa5f5cf763355a
We currently have three cells v2 documents in-tree:
- A 'user/cellsv2-layout' document that details the structure or
architecture of a cells v2 deployment (which is to say, any modern
nova deployment)
- A 'user/cells' document, which is written from a pre-cells v2
viewpoint and details the changes that cells v2 *will* require and the
benefits it *would* bring. It also includes steps for upgrading from
pre-cells v2 (that is, pre-Pike) deployment or a deployment with cells
v1 (which we removed in Train and probably broke long before)
- An 'admin/cells' document, which doesn't contain much other than some
advice for handling down cells
Clearly there's a lot of cruft to be cleared out as well as some
centralization of information that's possible. As such, we combine all
of these documents into one document, 'admin/cells'. This is chosen over
'users/cells' since cells are not an end-user-facing feature. References
to cells v1 and details on upgrading from pre-cells v2 deployments are
mostly dropped, as are some duplicated installation/configuration steps.
Formatting is fixed and Sphinx-isms used to cross reference config
option where possible. Finally, redirects are added so that people can
continue to find the relevant resources. The result is (hopefully) a
one stop shop for all things cells v2-related that operators can use to
configure and understand their deployments.
Change-Id: If39db50fd8b109a5a13dec70f8030f3663555065
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Not as many of these as I thought there would be. Also, yes, the change
to 'nova.conf.compute' is a doc change :)
Change-Id: I27626984ce94544bd81d998c5fdf141875faec92
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Link to the "Secure live migration with QEMU-native TLS" document from
other relevant guides, and small blurbs of text where appropriate.
Blueprint: support-qemu-native-tls-for-live-migration
Change-Id: I9c6676897d27254e2e16bf7e36a74bf9f3da3832
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This change does a few things:
* Links live_migration_completion_timeout to the config
option guide.
* Links the force complete API reference to the feature support
matrix to see which drivers support the operation.
* Fixes the server status mentioned in the troubleshooting for
the force complete API reference (a live migrating server
status is MIGRATING, not ACTIVE). The same text is copied to the
abort live migration API reference troubleshooting for
consistency (and since using the server status is more natural than
the task_state).
* Links to the admin guide for troubleshooting live migration
timeouts.
Change-Id: I496d3f4b99e3d7e978c7ecb13ab3b67023fcb919
Closes-Bug: #1808579
Live migration is currently totally broken if a NUMA topology is
present. This affects everything that's been regrettably stuffed in with
NUMA topology including CPU pinning, hugepage support and emulator
thread support. Side effects can range from simple unexpected
performance hits (due to instances running on the same cores) to
complete failures (due to instance cores or huge pages being mapped to
CPUs/NUMA nodes that don't exist on the destination host).
Until such a time as we resolve these issues, we should alert users to
the fact that such issues exist. A workaround option is provided for
operators that _really_ need the broken behavior, but it's defaulted to
False to highlight the brokenness of this feature to unsuspecting
operators.
Change-Id: I217fba9138132b107e9d62895d699d238392e761
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-bug: #1289064
This patch implements live migration of instances across compute nodes.
Each compute node must be managing a cluster in the same vCenter and ESX
hosts must have vMotion enabled [1].
If the instance is located on a datastore shared between source
and destination cluster, then only the host is changed. Otherwise, we
select the most suitable datastore on the destination cluster and
migrate the instance there.
[1] https://kb.vmware.com/s/article/2054994
Co-Authored-By: gkotton@vmware.com
blueprint vmware-live-migration
Change-Id: I640013383e684497b2d99a9e1d6817d68c4d0a4b
Change I1a1143ddf8da5fb9706cf53dbfd6cbe84e606ae1 in Ocata
deprecated the libvirt.live_migration_progress_timeout
and disabled it by default. This change updates the config
option help to refer to the bug so people don't have to hunt
for it via git history, and also touches up the admin docs.
In the one doc, mention of the option is removed altogether
because it basically says, "here is a loaded gun, but don't
use it!". It's better to just not mention the option at all.
Change-Id: I33f3d508a2af6c94435f86ac740cf24b97dba76e
Related-Bug: #1644248
xenapi is going to support pool-based multi-hosts OpenStack
environments, this patch is used to remove dependency to the
old aggregate-based-pools and add support to xenapi pool.
Also include unit test changes.
Updated configuring migrations document:
https://docs.openstack.org/nova/latest/admin/configuring-
migrations.html#configuring-migrations-xenserver-shared-storage
Other related documents will be updated in another patch.
Implements: blueprint live-migration-in-xapi-pool
Change-Id: I2c492c46e85c1df96aa7fdc12cdee0b1c7ba775e
This patch is follow-up for
I48d7c77a6e0eaaf0efe66f848f45ae99007577e1.
The hyperlink style is fixed.
Add a note that it need be updated for os-xenapi latest version.
Add a reference to nova policies.
TrivialFix
Change-Id: I274fb6b7ea0bb2ea81faaa68d783edbaa8ed06c3
Import all docs from openstack-manuals.
Part of bp: doc-migration
Change-Id: I28bb8ce1f4a8653f176a554d2e95b4423c437972
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
keerthivasan86