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 spec proposes to add ability to allow users to use
``Aggregate``'s ``metadata`` to override the global config options
for weights to achieve more fine-grained control over resource
weights.
blueprint: per-aggregate-scheduling-weight
Change-Id: I6e15c6507d037ffe263a460441858ed454b02504
This resolves the TODO from Ocata change:
I8871b628f0ab892830ceeede68db16948cb293c8
By adding a min=0.0 value to the soft affinity
weight multiplier configuration options.
It also removes the deprecated [DEFAULT] group
alias from Ocata change:
I3f48e52815e80c99612bcd10cb53331a8c995fc3
Change-Id: I79e191010adbc0ec0ed02c9d589106debbf90ea8
Add a document about using the "native TLS" encryption feature of QEMU
and libvirt to secure live migration data transports — including disks
that are on non-shared storage ("block migration"). This ties into the
newly introduced Nova configuration attribute,
``[libvirt]/live_migration_with_native_tls``, to that end.
Blueprint: support-qemu-native-tls-for-live-migration
Change-Id: Ic1af52bc3608f8f586244dd26dad1f47604e3278
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
Fix broken links in doc/source/user/cells.rst.
In addition, fix a format of a console code block
in doc/source/admin/pci-passthrough.rst.
Change-Id: I66a2adb3ff75da6e267536f25c2eda5925f2fa87
Closes-Bug: #1808906
A recent thread in the mailing list [1] reminded me that we
don't have any documentation for the service user token feature
added back in ocata under blueprint use-service-tokens.
This change adds a troubleshooting entry for when using service
user tokens would be useful, and links to it from two known
trouble spots: live migration timeouts and creating images.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2018-December/001130.html
Change-Id: I1dda889038ffe67d53ceb35049aa1f2a9da39ae8
Closes-Bug: #1809165
- Move deprecated services to the end of the document
- Update incorrect information regarding nova-consoleauth
- Move configuration options that were specified for the wrong service
- Don't give the impression that the serial console is libvirt-only
Change-Id: Ie0fd987a1e5c130b8e31c84910814d5d051f2b31
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
Config option ``libvirt.live_migration_progress_timeout`` was
deprecated in Ocata, and can now be removed.
This patch remove live_migration_progress_timeout and also remove
the migration progress timeout related logic.
Change-Id: Ife89a705892ad96de6d5f8e68b6e4b99063a7512
blueprint: live-migration-force-after-timeout
This patch remove the auto trigger post-copy, and add a new libvirt
configuration 'live_migration_completion_action'.
This option determines what actions will be taken against a VM after
``live_migration_completion_timeout`` expires. This option is set to
'abort' action by default, that means the live migrate operation will
be aborted after completion timeout expires. If option is set to
'force_complete', that means will either pause the VM or trigger
post_copy depending on if post copy is enabled and available.
Note that the progress based post-copy triggering from the libvirt
driver will be removed in next patch [1].
[1] Ife89a705892ad96de6d5f8e68b6e4b99063a7512
Change-Id: I0d286d12e588b431df3d94cf2e65d636bcdea2f8
blueprint: live-migration-force-after-timeout
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 adds a new section to the admin scheduler configuration
docs devoted to allocation ratios to call out the differences
between the override config options and the initial ratio
options, and how they interplay with the resource provider
inventory allocation ratio override that can be performed
via the placement REST API directly.
This moves the note about bug 1804125 into the new section
and also links to the docs from the initial allocation ratio
config option help text.
Part of blueprint initial-allocation-ratios
Related-Bug: #1804125
Change-Id: I7d8e822cd40dccaf5244e2cd95fa1af43fa9ed87
This borrows from the release note in change
I01f20f275bbd5451ace5c1e6f41ab38d488dae4e to document the
regression, introduced in Ocata, where allocation ratio settings
in the aggregate core/ram/disk filters are not honored because
of placement being used by the FilterScheduler.
While there is related work going on around this in
blueprint initial-allocation-ratios and
blueprint placement-aggregate-allocation-ratios, it is still
a limitation in the current code base and needs to be called
out in the docs.
Change-Id: Ifaf596a8572637f843f47daf5adce394b0365676
Related-Bug: #1804125
The installation of the nova-consoleauth service was erroneously
removed from the docs prematurely. The nova-consoleauth service
is still being used in Rocky, with the removal being possible in
Stein.
This should have been fixed as part of change
Ibbdc7c50c312da2acc59dfe64de95a519f87f123 but was missed.
This is also related to the release note update in Rocky
under change Ie637b4871df8b870193b5bc07eece15c03860c06.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Closes-Bug: #1793255
Related-Bug: #1798188
Change-Id: Ied268da9e70bd2807c2dfe7a479181fbec52979d
This changes does two things to the admin scheduler configuration
docs:
1. Notes the limitation from bug 1802111 for the older
AggregateMultiTenancyIsolation filter and mentions that
starting in Rocky, using tenant isolation with placement
is better.
2. Notes that when isolating tenants via placement, the metadata
key "filter_tenant_id" can be suffixed to overcome the limitation
in bug 1802111.
Change-Id: I792c5df01b7cbc46c8363e261bc7422b09180e56
Closes-Bug: #1802111
In the Configuration Guide's section on KVM:
* expand on the implications of selecting a CPU mode and model
for live migration,
* explain the cpu_model_extra_flags option,
* discuss how to enable nested guests, and the implications and
limitations of doing so,
* bump the heading level of "Guest agent support".
Closes-Bug: 1791678
Change-Id: I671acd16c7e5eca01b0bd633caf8e58287d0a913
The CachingScheduler has been deprecated since Pike [1].
It does not use the placement service and as more of nova
relies on placement for managing resource allocations,
maintaining compabitility for the CachingScheduler is
exorbitant.
The release note in this change goes into much more detail
about why the FilterScheduler + Placement should be a
sufficient replacement for the original justification
for the CachingScheduler along with details on how to migrate
from the CachingScheduler to the FilterScheduler.
Since the [scheduler]/driver configuration option does allow
loading out-of-tree drivers and the scheduler driver interface
does have the USES_ALLOCATION_CANDIDATES variable, it is
possible that there are drivers being used which are also not
using the placement service. The release note also explains this
but warns against it. However, as a result some existing
functional tests, which were using the CachingScheduler, are
updated to still test scheduling without allocations being
created in the placement service.
Over time we will likely remove the USES_ALLOCATION_CANDIDATES
variable in the scheduler driver interface along with the
compatibility code associated with it, but that is left for
a later change.
[1] Ia7ff98ff28b7265058845e46b277317a2bfc96d2
Change-Id: I1832da2190be5ef2b04953938860a56a43e8cddf
This is a relic that has long since been replaced by the noVNC proxy
service. Start preparing for its removal.
Change-Id: Icb225dec3ad291b751e475bd3703ce0eb30b44db
I did know this was a thing but only barely. As with RDP, the
documentation is very minimal but it should contain enough pointers for
anyone playing with this stuff.
Change-Id: I0b62d42eae7c325566ee065dcdc0f73b7223d471
I didn't even know this was a thing. Call it out...and promptly link to
the Cloudbase documentation, which I don't want to reproduce here for
reasons of expediency.
Change-Id: I4416bf5c5c4e906bcfdeec5a7ae41f747029a292
The link between the various consoles was never well understood (by me,
at least). Clarify this by restructuring the document to highlight the
few differences between these services.
Change-Id: I08991796aaced2abc824f608108c0c786181eb65
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
The scheduler_default_filters option is deprecated in favor of
the [scheduler]/enabled_filters option. This change updates
the docs to use the enabled_filters option over the deprecated
scheduler_default_filters option.
Change-Id: I6cc78056179e01752e48e51a4e3552d52d66074b
Closes-Bug: #1794306
Add a note to the documentation,the GPU vendor's VGPU
driver software needs to be installed and configured.
Change-Id: I8618a312818f6f26d358b40e723fecf74c0d2eb7
Zuul