229fb3513a
The stats module uses the _find_pool() call to find a matching pool for a new device or a device that is being deallocated. If no existing pool matches with the dev then then a new pool is created for it. The pool matching logic was faulty as it did not remove all the metadata keys from the pool like rp_uuid. So if the dev did not have that key but the pool did then the dev did not match. On the other hand the PCI allocation logic (when PCI in Placement is enabled) assumed that devices from a single rp_uuid are always in a single pool. As this assumption was broken by the above bug the PCI allocation blindly tried to allocate resources for an rp_uuid from each matching pool causing overallocation. The main fix in this patch is to ignore the metadata tags in _find_pool(). But also two safety net are added to the allocation logic. The logic now asserts that the assumption is correct and if not (i.e. it found multiple pools with the same rp_uuid) then it bails out. It also does not ever blindly allocate the same rp_uuid request from multiple pools. Closes-Bug: #2098496 Change-Id: I9678230397fa1a3c735ee01ed756d5af3b4e1191
13 lines
608 B
YAML
13 lines
608 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixed the issue
|
|
`bug 2098496 <https://bugs.launchpad.net/nova/+bug/2098496>`__ where nova
|
|
assigned more PCI hostdevs to a VM than the flavor requested via the
|
|
pci_passthrough:alias extra_spec. This only affected systems where both
|
|
``[filter_scheduler]pci_in_placement`` and ``[pci]report_in_placement``
|
|
were set to True. This only affected systems where the PCI alias requested
|
|
type-VF devices and a single PF device on the compute node supported more
|
|
than one VFs and ``[pci]device_spec`` configuration allowed nova to use
|
|
multiple VFs from a single PF.
|