Devices that report SR-IOV capabilities cannot be used without special
configuration - namely, the addition of "'device_type': 'type-PF'" or
"'device_type': 'type-VF'" to the '[pci] alias' configuration option.
Spell this out in the docs.
Change-Id: I4abbe30505a5e4ccba16027addd6d5f45066e31b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Closes-Bug: #1852727
The only ones remaining are some real crufty SVGs and references to
things that still exist because nova-network was once a thing.
Change-Id: I1aebf86c05c7b8c1562d0071d45de2fe53f4588b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Get excited, people. It's finally dying, for real. There is a lot more
doc work needed here, but this is a start. No need for a release note
modification since we've already said that nova-network has been
removed, so there's no point in saying that the service itself has been
removed since that's implicit.
Change-Id: I18d73212f9d98bc75974a024cf6fd872fdfb1ca4
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The majority if this doc was talking about ec2 concepts
which haven't been in nova for a looooong time so this
change just deletes the doc and moves the one useful
piece into another part of the admin guide and links to
the keystone docs.
Change-Id: I8d7c9c244767645a5d63716842eaf19ca6ab1a45
Yet another one of these. This time around, we make the following
changes:
- Put admin-focused stuff in '/admin', and user-focused docs in '/user'
- Merge the '/admin/quotas2' document into the '/admin/quotas' document
- Update references to novaclient to use openstackclient if possible and
include a TODO if not
- s/tenant/project/
Note that there is some duplication between the user and admin docs
here. That's necessary since, for example, showing a user's quotas is
also something an admin will want to do.
Change-Id: I733515cf0f939fe95203ff0b09df2709daee108c
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Not the first time we've done this [1]. Probably not the last.
[1] I5c99ff6b04ee97bac210a0d6762015225775c5ee
Change-Id: I9fc70df93af73b56ac9155d8d402b153d2af9f4e
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
These made things significantly less discoverable from the admin guide
and resulted in some duplication of links. Better to just flatten
things. Things are pretty much copy-pasted save for the removal of a
reference to the long-dead nova-objectstore service and the addition of
a TODO to provide overviews of other services.
Change-Id: Ibf2b6979318cf3f0a0519f66acbc279b2ce80968
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
It doesn't really make sense to describe the "higher level"
configuration steps necessary for PCI passthrough before describing
things like BIOS configuration. Simply switch the ordering.
Change-Id: I4ea1d9a332d6585ce2c0d5a531fa3c4ad9c89482
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Related-Bug: #1852727
While we do not have an automated fix for bug 1849479 this provides
a troubleshooting document for working around that issue where
allocations from a server that was evacuated from a down host need
to be cleaned up manually in order to delete the resource provider
and associated compute node/service.
In general this is also a useful guide for linking up the various
resources and terms in nova and how they are reflected in placement
with the relevant commands which is probably something we should
do more of in our docs.
Change-Id: I120e1ddd7946a371888bfc890b5979f2e19288cd
Related-Bug: #1829479
Add a section to the support matrix for image caching
(``has_imagecache`` virt driver capability).
Change-Id: I9147c5ea6b276b4fe18a981f4360844009bd3d95
Partial-Bug: #1847302
Blueprint image-precache-support added a conf section called
[image_cache], so it makes sense to move all the existing image
cache-related conf options into it.
Old:
[DEFAULT]image_cache_manager_interval
[DEFAULT]image_cache_subdirectory_name
[DEFAULT]remove_unused_base_images
[DEFAULT]remove_unused_original_minimum_age_seconds
[libvirt]remove_unused_resized_minimum_age_seconds
New:
[image_cache]manager_interval
[image_cache]subdirectory_name
[image_cache]remove_unused_base_images
[image_cache]remove_unused_original_minimum_age_seconds
[image_cache]remove_unused_resized_minimum_age_seconds
Change-Id: I3c49825ac0d70152b6c8ee4c8ca01546265f4b80
Partial-Bug: #1847302
If we're booting from an existing volume but the instance is not being
created in a requested availability zone, and cross_az_attach=False,
we'll fail with a 400 since by default the volume is in the 'nova'
AZ and the instance does not have an AZ set - because one wasn't requested
and because it's not in a host aggregate yet.
This refactors that AZ validation during server create in the API to
do it before calling _validate_bdm so we get the pre-existing volumes
early and if cross_az_attach=False, we validate the volume zone(s) against
the instance AZ. If the [DEFAULT]/default_schedule_zone (for instances) is
not set and the volume AZ does not match the
[DEFAULT]/default_availability_zone then we put the volume AZ in the request
spec as if the user requested that AZ when creating the server.
Since this is a change in how cross_az_attach is used and how the instance
default AZ works when using BDMs for pre-existing volumes, the docs are
updated and a release note is added.
Note that not all of the API code paths are unit tested because the
functional test coverage does most of the heavy lifting for coverage.
Given the amount of unit tests that are impacted by this change, it is
pretty obvious that (1) many unit tests are mocking at too low a level and
(2) functional tests are better for validating these flows.
Closes-Bug: #1694844
Change-Id: Ib31ba2cbff0ebb22503172d8801b6e0c3d2aa68a
This adds AggregateCacheNotification, related payload, and code in
conductor to emit this per-compute with progress information. This
also adds a "progress" phase to NotificationPhase, which allows for
start..progress..progress..end information for a single operation
(cache_images in this case).
Related to blueprint image-precache-support
Change-Id: I69ae26d4caf4b56ab2c4864455bfe9b5b736dbf3
These closely related features are the source of a disproportionate
number of bugs and a large amount of confusion among users. The spread
of information around multiple docs probably doesn't help matters.
Do what we've already done for the metadata service and remote consoles
and clean these docs up. There are a number of important changes:
- All documentation related to host aggregates and availability zones is
placed in one of three documents, '/user/availability-zones',
'/admin/aggregates' and '/admin/availability-zones'. (note that there
is no '/user/aggregates' document since this is not user-facing)
- References to these features are updated to point to the new location
- A glossary is added. Currently this only contains definitions for host
aggregates and availability zones
- nova CLI commands are replaced with their openstack CLI counterparts
- Some gaps in related documentation are closed
Change-Id: If847b0085dbfb4c813d4a8d14d99346f8252bc19
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Thank God. The majority of the removed images are so crufty, it's
actually funny. I don't want to update them and it's unlikely anyone
else does either. The rest are just moved to be with their comrades in
the '_static/images' directory.
Change-Id: I91b34c85379a68be5e6a09ce48b11c0d3343f12b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This relies on the recently added 'openstack server migrate confirm' and
'openstack server migrate revert' commands.
Change-Id: I58d0a62aeeb4bb23a7ed3a8e9fe5ddb7f2dd3877
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Depends-On: I0cb6304c794bffaec785add9f7b8cf53ab28cacd
We don't need to do a whole lot here. The key things to note are that
some host level configuration is now necessary, that the 'isolate' CPU
thread policy behaves slightly differently, and that you can request
'PCPU' inventory explicitly instead of using 'hw:cpu_policy=dedicated'
or the image metadata equivalent.
Part of blueprint cpu-resources
Change-Id: Ic1f98ea8a7f6bdc86f2d6b4734774fa380f8cc10
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The documentation for emulator threads leaves a lot to be desired, while
the hierarchy of the CPU thread pinning doesn't emphasise the dependency
of this feature on CPU pinning. Resolve both by tweaking or expanding
the wording of key paragraphs and modifying the header levels to nest
the CPU thread pinning and emulator thread pinning docs under the CPU
pinning docs.
Change-Id: Ife32a53b80b770e008dbe2091fbb88e6596d238b
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Rewrite the document, making the following changes:
- Remove use of bullet points in favour of more descriptive steps
- Cross-reference various configuration options
- Emphasise that ``[pci] alias`` must be set on both controller and
compute node
- Style nits, such as fixing the header style
Change-Id: I2ac7df7d235f0af25f5a99bc8f6abddbae2cb3af
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
As discussed on the following review:
https://review.opendev.org/674916
this adds a note indicating that the version of noVNC needs to be at
least v1.1.0 in order for the nova-novncproxy to work with ESX/ESXi
hypervisors.
Related-Bug: #1822676
Change-Id: Ia4ba37b6d6a1e4b5c75e38f4bcc2bea1d9ba9560
Added reference documentation and release note to explain how filtering
of hosts by isolate aggregates works.
Change-Id: I8d8086973039308f9041a36463a834b5275708e3
Implements: blueprint placement-req-filter-forbidden-aggregates
This is a follow-up to the previous SEV commit which enables booting
SEV guests (I659cb77f12a3), making some minor improvements based on
nits highlighted during review:
- Clarify in the hypervisor-kvm.rst documentation that the
num_memory_encrypted_guests option is optional, by rewording and
moving it to the list of optional steps.
- Make things a bit more concise and avoid duplication of information
between the above page and the documentation for the option
num_memory_encrypted_guests, instead relying on appropriate
hyperlinking between them.
- Clarify that virtio-blk can be used for boot disks in newer kernels.
- Hyperlink to a page explaining vhost-user
- Remove an unneeded mocking of a LOG object.
- A few other grammar / spelling tweaks.
blueprint: amd-sev-libvirt-support
Change-Id: I75b7ec3a45cac25f6ebf77c6ed013de86c6ac947
Track compute node inventory for the new MEM_ENCRYPTION_CONTEXT
resource class (added in os-resource-classes 0.4.0) which represents
the number of guests a compute node can host concurrently with memory
encrypted at the hardware level.
This serves as a "master switch" for enabling SEV functionality, since
all the code which takes advantage of the presence of this inventory
in order to boot SEV-enabled guests is already in place, but none of
it gets used until the inventory is non-zero.
A discrete inventory is required because on AMD SEV-capable hardware,
the memory controller has a fixed number of slots for holding
encryption keys, one per guest. Typical early hardware only has 15
slots, thereby limiting the number of SEV guests which can be run
concurrently to 15. nova needs to track how many slots are available
and used in order to avoid attempting to exceed that limit in the
hardware.
Work is in progress to allow QEMU and libvirt to expose the number of
slots available on SEV hardware; however until this is finished and
released, it will not be possible for nova to programatically detect
the correct value with which to populate the MEM_ENCRYPTION_CONTEXT
inventory. So as a stop-gap, populate the inventory using the value
manually provided by the cloud operator in a new configuration option
CONF.libvirt.num_memory_encrypted_guests.
Since this commit effectively enables SEV, also add all the relevant
documentation as planned in the AMD SEV spec[0]:
- Add operation.boot-encrypted-vm to the KVM hypervisor feature matrix.
- Update the KVM section of the Configuration Guide.
- Update the flavors section of the User Guide.
- Add a release note.
[0] http://specs.openstack.org/openstack/nova-specs/specs/train/approved/amd-sev-libvirt-support.html#documentation-impact
blueprint: amd-sev-libvirt-support
Change-Id: I659cb77f12a38a4d2fb118530ebb9de88d2ed30d
After three months since the quality warning change merged [1]
there has still been no progress in finding a maintainer for
the xenapi driver or someone to get the third party CI running
again - which has been off/broken for more than a release.
This change formally deprecates the driver, logging a warning
on startup along with providing a release note and warnings
in the docs and [xenserver] config group help.
Note that this does not mean the driver will absolutely be
removed in the Ussuri release, but it leaves the option open
to do so if the nova team decides that should happen.
This was discussed at the 2019-09-05 nova meeting [2] and
also at the Train PTG.
[1] I7f8eb7d5c5a9b1cb0a8d5e607d719b49a22675d3
[2] http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-09-05-14.01.log.html#l-227
Change-Id: Ie7e66ff64185d9fd4be2265e040e1afc45b95174
Zuul