The 'force' parameter of os-brick's disconnect_volume() method allows
callers to ignore flushing errors and ensure that devices are being
removed from the host.
We should use force=True when we are going to delete an instance to
avoid leaving leftover devices connected to the compute host which
could then potentially be reused to map to volumes to an instance that
should not have access to those volumes.
We can use force=True even when disconnecting a volume that will not be
deleted on termination because os-brick will always attempt to flush
and disconnect gracefully before forcefully removing devices.
Closes-Bug: #2004555
Change-Id: I3629b84d3255a8fe9d8a7cea8c6131d7c40899e8
Also did a bit of cleanup in the text message to tell *when* we need to bump
the min service version.
Given 2023.1 is our first SLURP release, we need to clarify the level of
support we now have for rolling upgrades.
Next cycle, we should update the min version to be Zed.
Change-Id: I2dd906f34118da02783bb7755e0d6c2a2b88eb5d
The deprecated `--live` option of the `server migrate` command
was removed I37ef09eca0db9286544a4b0bb33f845311baa9b2
Update docs with new arguments.
Change-Id: Id7a9a7509ca5e7811b6d3ce060390ea23c93d4ce
This adds some admin guide documentation about the stable compute_id
file. It covers upgrade, greenfield generation, and greenfield
pre-provisioning by deployment tools.
Related to blueprint stable-compute-uuid
Change-Id: I078b3f9e1919f2008628dc7b889e8696f1f6159a
This patch adds the following SPICE-related options to the 'spice'
configuration group of a Nova configuration:
- image_compression
- jpeg_compression
- zlib_compression
- playback_compression
- streaming_mode
These configuration options can be used to enable and set the SPICE
compression settings for libvirt (QEMU/KVM) provisioned instances.
Each configuration option is optional and can be set explictly to
configure the associated SPICE compression setting for libvirt. If all
configuration options are not set, then none of the SPICE compression
settings will be configured for libvirt, which corresponds to the
behavior before this change. In this case, the built-in defaults from
the libvirt backend (e.g. QEMU) are used.
Note that those options are only taken into account if SPICE support is
enabled (and the VNC support is disabled).
Implements: blueprint nova-support-spice-compression-algorithm
Change-Id: Ia7efeb1b1a04504721e1a5bdd1b5fa7a87cdb810
A new configuration option [filter_scheduler]pci_in_placement is added
that allows enabling the scheduler logic for PCI device handling in
Placement for flavor based PCI requests.
blueprint: pci-device-tracking-in-placement
Change-Id: I5ddf6d3cdc7e05cc4914b9b1e762fa02a5c7c550
While collecting information because of a question I received
about soft delete and shadow tables I realized that the documentation
contains bits and pieces here and there, but I couldn't find more.
This change summarizes what I found from docs and asking around.
I hope you find it useful.
Change-Id: I5ff90224cc27c57dc463604559d25298ed7b3f98
The [pci]alias configuration option now accepts two new optional fields:
* resource_class: that can be used to request PCI device by placement
RC name.
* traits: a comma separated list of placement trait names that can be
used to filter placement PCI resource provider by traits.
These fields has the matching counterpart in [pci]device_spec
implemented already.
These fields are matched by the Placement GET allocation_candidates
query therefore these fields are ignored when PCI device pools are
matched against IntancePCIRequest by nova.
Note that InstancePCIRequest object spec field is defined as a list of
dicts. But in reality nova creates the request always with a single
dict. So we restricted the placement logic to handle a single spec.
blueprint: pci-device-tracking-in-placement
Change-Id: I5c8f05c3c5d7597175e60b29e4ab2f22e6496ecd
This change updates the cpu and ram initial
allocation ratios to 4.0 and 1.0 to reflect
the typical values that are suitable for non web
hosting workloads.
Change-Id: I283eb270a4e47da15cf01d098b4f3952f7b5b570
implements: bp/nova-change-default-overcommit-values
This fixes the doc comments for the already merged (or being merged)
patches in the series.
blueprint: pci-device-tracking-in-placement
Change-Id: Ia99138d603722a66c9a6ac61b035384d86ccca75
This patch introduces the [pci]report_in_placement config option that is
False by default but if set to True will enable reporting of the PCI
passthrough inventories to Placement.
blueprint: pci-device-tracking-in-placement
Change-Id: I49a3dbf4c5708d2d92dedd29a9dc3ef25b6cd66c
PCI devices which are allocated to instances can be removed from the
[pci]device_spec configuration or can be removed from the hypervisor
directly. The existing PciTracker code handle this cases by keeping the
PciDevice in the nova DB exists and allocated and issue a warning in the
logs during the compute service startup that nova is in an inconsistent
state. Similar behavior is now added to the PCI placement tracking code
so the PCI inventories and allocations in placement is kept in such
situation.
There is one case where we cannot simply accept the PCI device
reconfiguration by keeping the existing allocations and applying the new
config. It is when a PF that is configured and allocated is removed and
VFs from this PF is now configured in the [pci]device_spec. And vice
versa when VFs are removed and its parent PF is configured. In this case
keeping the existing inventory and allocations and adding the new inventory
to placement would result in placement model where a single PCI device
would provide both PF and VF inventories. This dependent device
configuration is not supported as it could lead to double consumption.
In such situation the compute service will refuse to start.
blueprint: pci-device-tracking-in-placement
Change-Id: Id130893de650cc2d38953cea7cf9f53af71ced93
During resize an instance with existing PCI allocation can be changed to
consume less, more, or different PCI devices. So the heal allocation
logic needs to handle the case when an existing instance is changed to
consume different PCI devices.
This patch adds support to change existing PCI allocations in placement
during resize.
There is one limitation of the healing logic. It assumes that there is
no in-progress migration when nova is upgraded. If there is an in
progress migration, then the PCI usage will not be healed in the
migration allocation. The placement view will be consistent after such
migration is completed or reverted.
blueprint: pci-device-tracking-in-placement
Change-Id: Icc968c567f9967d7449d6c6c1f57783098e63f55
We agreed not to support 'devname' based [pci]device_spec configuration
in the new PCI Placement tracking code. So this patch adds a check to
reject those.
blueprint: pci-device-tracking-in-placement
Change-Id: Ifa0dd34506ebc25cfe5bafd6952b72b0008fc741
The first version of the PCI tracking in placement feature will not
handle Neutron based SRIOV devices. So those are now ignored during
placement inventory reporting.
blueprint: pci-device-tracking-in-placement
Change-Id: Ie24969d60c84379673c5450863f4cf58cf09207c
If two VFs from the same PF are configured by two separate
[pci]device_spec entries then it is possible to define contradicting
resource classes or traits. This patch detects and rejects such
configuration.
blueprint: pci-device-tracking-in-placement
Change-Id: I623ab24940169991a400eba854c9619a11662a91
The PCI tracking in placement does not support the configuration where
both a PF and its children VFs are configured for nova usage. This patch
adds logic to detect and reject such configuration. To be able to kill
the service if started with such config special exception handling is
added for the update_available_resource code path, similarly how a
failed reshape is handled.
blueprint: pci-device-tracking-in-placement
Change-Id: I708724465d2afaa37a65c231c64da88fc8b458eb
Each [pci]device_spec entry can specify the two new resource_class and
traits tags.
If the resource_class is specified then it will be used as the RC in the
placement inventory of the PCI devices matching the spec. If not
specified then the RC is defaulted CUSTOM_PCI_<vendor_id>_<product_id>.
The traits tag is a comma separated list of trait names. Nova will
report these traits to RP representing the matching PCI devices.
blueprint: pci-device-tracking-in-placement
Change-Id: I71b7a2fb8b03a3679733a98958b2f6d447ed5004
A new PCI resource handler is added to the update_available_resources
code path update the ProviderTree with PCI device RPs, inventories and
traits.
It is a bit different than the other Placement inventory reporter. It
does not run in the virt driver level as PCI is tracked in a generic way
in the PCI tracker in the resource tracker. So the virt specific
information is already parsed and abstracted by the resource tracker.
Another difference is that to support rolling upgrade the PCI handler
code needs to be prepared for situations where the scheduler does not
create PCI allocations even after some of the compute already started
reporting inventories and started healing PCI allocations. So the code
is not prepared to do a single, one shot, reshape at startup, but
instead to do a continuous healing of the allocations. We can remove
this continuous healing after the PCI prefilter will be made mandatory
in a future release.
The whole PCI placement reporting behavior is disabled by default while
it is incomplete. When it is functionally complete a new
[pci]report_in_placement config option will be added to allow enabling
the feature. This config is intentionally not added by this patch as we
don't want to allow enabling this logic yet.
blueprint: pci-device-tracking-in-placement
Change-Id: If975c3ec09ffa95f647eb4419874aa8417a59721
This change adds a new hw:locked_memory extra spec and hw_locked_memory
image property to contol preventing guest memory from swapping.
This change adds docs and extend the flavor
validators for the new extra spec.
Also add new image property.
Blueprint: libvirt-viommu-device
Change-Id: Id3779594f0078a5045031aded2ed68ee4301abbd
This change append vnic-type vdpa to the list
of passthough vnic types and removes the api blocks
This should enable the existing suspend and live migrate
code to properly manage vdpa interfaces enabling
"hot plug" live migrations similar to direct sr-iov.
Implements: blueprint vdpa-suspend-detach-and-live-migrate
Change-Id: I878a9609ce0d84f7e3c2fef99e369b34d627a0df
This change extends the guest xml parsing such that
the source device path can be extreacted from interface
elements of type vdpa.
This is required to identify the interface to remove when
detaching a vdpa port from a domain.
This change fixes a latent bug in the libvirt fixutre
related to the domain xml generation for vdpa interfaces.
Change-Id: I5f41170e7038f4b872066de4b1ad509113034960
