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
This change adds functional test for operations on servers with VDPA
devices that are expected to work but currently blocked due to lack
of testing or qemu bugs.
cold-migrate, resize, evacuate,and shelve are enabled
and tested by this patch
Closes-Bug: #1970467
Change-Id: I6e220cf3231670d156632e075fcf7701df744773
A later patch in the pci-device-tracking-in-placement work
will extend the existing [pci]passthrough_whitelist config syntax.
So we take the opportunity here to deprecate the old non inclusive
passthrough_whitelist name and introduce a better one.
All the usage of CONF.pci.passthrough_whitelist is now changed over to
the new device_spec config. Also the in tree documentation is updated
accordinly.
However the nova code still has a bunch of references to the
"whitelist" terminology. That will be handled in subsequent patches.
blueprint: pci-device-tracking-in-placement
Change-Id: I843032e113642416114f169069eebf6a56ed78dd
The PowerVM driver was deprecated in November 2021 as part of change
Icdef0a03c3c6f56b08ec9685c6958d6917bc88cb. As noted there, all
indications suggest that this driver is no longer maintained and may be
abandonware. It's been some time and there's still no activity here so
it's time to abandon this for real.
This isn't as tied into the codebase as the old XenAPI driver was, so
removal is mostly a case of deleting large swathes of code. Lovely.
Change-Id: Ibf4f36136f2c65adad64f75d665c00cf2de4b400
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Custom filters are still supported. Custom schedulers / scheduler
drivers are what is not. This patch fixes the wording.
Change-Id: Icf9576b75bd006ba65484b9232e85d8b748458f1
Previously, the libvirt driver defaulted to 1024 * (# of CPUs) for the
value of domain/cputune/shares in the libvirt XML. This value is then
passed directly by libvirt to the cgroups API. Cgroups v2 imposes a
maximum value of 10000 that can be passed in. This makes Nova
unable to launch instances with more than 9 CPUs on hosts that run
cgroups v2, like Ubuntu Jammy or RHEL 9.
Fix this by just removing the default entirely. Because there is no
longer a guarantee that domain/cputune will contain at least a shares
element, we can stop always generating the former, and only generate
it if it will actually contain something.
We can also make operators's lives easier by leveraging the fact that
we update the XML during live migration, so this patch also adds a
method to remove the shares value from the live migration XML if one
was not set as the quota:cpu_shares flavor extra spec.
For operators that *have* set this extra spec to something greater
than 10000, their flavors will have to get updates, and their
instances resized.
Partial-bug: 1978489
Change-Id: I49d757f5f261b3562ada27e6cf57284f615ca395
Because in the above description:
To install nova-compute, run:
PS C:\> cd c:\nova
PS C:\> python setup.py install
The file is downloaded to c:\nova. After executing `python setup.py
install` in this directory, the etc directory is generated under
`c:\nova`. Correct the path.
Closes-Bug: #1964548
Change-Id: Ibf0c1b56f235fffae65afbbcee30056bae965afe
This a follow up for change Ic8783053778cf4614742186e94059d5675121db1
and corrects the 'image_property set --property' arg format in the
hw_machine_type doc. Newline formats in the nova-manage CLI doc is
cleaned up to be consistent throughout and unnecessary () is removed
from the ImagePropertyCommands class.
Related to blueprint libvirt-device-bus-model-update
Change-Id: I5b67e9ae5125f6dad68cae7ac0601ac5b02e74b3
host arch in libvirt driver support
This is split 2 of 3 for the architecture emulation feature.
This implements emulated multi-architecture support through qemu
within OpenStack Nova.
Additional config variable check to pull host architecture into
hw_architecture field for emulation checks to be made.
Adds a custom function that simply performs a check for
hw_emulation_architecture field being set, allowing for core code to
function as normal while enabling a simple check to enable emulated
architectures to follow the same path as all multi-arch support
already established for physical nodes but instead levaraging qemu
which allows for the overall emulation.
Added check for domain xml unit test to strip arch from the os tag,
as it is not required uefi checks, and only leveraged for emulation
checks.
Added additional test cases test_driver validating emulation
functionality with checking hw_emulation_architecture against the
os_arch/hw_architecture field. Added required os-traits and settings
for scheduler request_filter.
Added RISCV64 to architecture enum for better support in driver.
Implements: blueprint pick-guest-arch-based-on-host-arch-in-libvirt-driver
Closes-Bug: 1863728
Change-Id: Ia070a29186c6123cf51e1b17373c2dc69676ae7c
Signed-off-by: Jonathan Race <jrace@augusta.edu>
This adds an image property show and image property set command to
nova-manage to allow users to update image properties stored for an
instance in system metadata without having to rebuild the instance.
This is intended to ease migration to new machine types, as updating
the machine type could potentially invalidate the existing image
properties of an instance.
Co-Authored-By: melanie witt <melwittt@gmail.com>
Blueprint: libvirt-device-bus-model-update
Change-Id: Ic8783053778cf4614742186e94059d5675121db1
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
While most of the SR-IOV related documentation resides in the Neutron
repository which is going to have a separate section on the topic of
supporting remote-managed ports and off-path networking backends, there
are still some things specific to Nova which are worth documenting in
Nova docs.
https://docs.openstack.org/neutron/latest/admin/config-sriov.html
Implements: blueprint integration-with-off-path-network-backends
Change-Id: I3c5fe8ec0539e10d07b1b4888e9833bc7ede1d04
This was eventually added in Yoga, not Xena.
Change-Id: I8afe755732c95d023b7c4bd99964507f54d324f1
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This was actually three documents in one:
- An admin doc detailing how to configure and use notifications
- A contributor doc describing how to extend the versioned notifications
- A reference doc listing available versioned notifications
Split the doc up to reflect this
Change-Id: I880f1c77387efcc3c1e147323b224e10156e0a52
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Mostly copy-paste from the spec, but at least this is in-tree and
updatable.
Change-Id: I4cad2111065fbc1840d44fc9f4bf6ac585e18db6
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Cells mean NUMA cells below in text.
By default, first instance's cell are placed to the host's cell with
id 0, so it will be exhausted first. Than host's cell with id 1 will
be used and exhausted. It will lead to error placing instance with
number of cells in NUMA topology equal to host's cells number if
some instances with one cell topology are placed on cell with id 0
before. Fix will perform several sorts to put less used cells at
the beginning of host_cells list based on PCI devices, memory and
cpu usage when packing_host_numa_cells_allocation_strategy is set
to False (so called 'spread strategy'), or will try to place all
VM's cell to the same host's cell untill it will be completely
exhausted and only after will start to use next available host's
cell (so called 'pack strategy'), when the configuration option
packing_host_numa_cells_allocation_strategy is set to True.
Partial-Bug: #1940668
Change-Id: I03c4db3c36a780aac19841b750ff59acd3572ec6
Based on review feedback on [1] and [2].
[1] If39db50fd8b109a5a13dec70f8030f3663555065
[2] I518bb5d586b159b4796fb6139351ba423bc19639
Change-Id: I44920f20213462a3abe743ccd38b356d6490a7b4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Zuul