COMPUTE_NET_VIRTIO_PACKED allows us to report this trait and use it to
filter hosts that support packed virtqueue.
Nova spec: https://review.opendev.org/c/openstack/nova-specs/+/868377
Change-Id: I0752af7b67e999d53f007b3e83ec218bb6fd7da7
COMPUTE_SHARE_LOCAL_FS allows us to report this trait and use
it to filter hosts that support sharing local FS.
Implements: blueprint virtiofs-scaphandre
Change-Id: I7d3aee17b9afab5820735f5bdbb5fe69391dce45
These traits indicate the pass-through or emulated
mode of the guest physical address bits.
blueprint: libvirt-maxphysaddr-support
Signed-off-by: Nobuhiro MIKI <nmiki@yahoo-corp.jp>
Change-Id: Id3716ea9d8581b3c41604f35ed83fa41a3ce0554
Add trait to specify whether a driver supports regeneration
of config drives.
Change-Id: I1c63d1edde52e71c571258b87903afaaa26b1c8c
Signed-off-by: Jan Hartkopf <jhartkopf@inovex.de>
Add traits for vIOMMU traits corresponding to the allowed values of
"hw_iommu_model" image metadata property.
Blueprint: libvirt-viommu-device
Change-Id: Ic44429ad360475143b20071f85d534a958d110e0
This will be used by nova implementing PCI tracking in Placement along
with the existing OWNER_NOVA trait to indicate that an RP has
inventories of nova managed PCI device (or its children devices).
blueprint: pci-device-tracking-in-placement
Change-Id: Id0c87f3afc223f655a708d7d08df62216d832203
COMPUTE_STORAGE_VIRTIO_FS allows us to report this trait and use
it to filter hosts that support virtio filesystems.
COMPUTE_MEM_BACKING_FILE allows us to report this trait and use
it to filter hosts that supports file-backed memory.
These both traits are necessary to support sharing files with
virtiofs and so forth with manila shares.
Implements: blueprint libvirt-virtiofs-attach-manila-shares
Change-Id: I89419cf1649f48106d84cc84e688df7a065f470a
Implement new image meta property that allows for the selection of the
correct QEMU binary, cpu architecture, and machine type for a guest
architecture that is different than the host architecture; An x86_64
guest running on an AArch64 host, and vice versa.
Specifically the required OS traits have been added to ensure that the
hw_architecture and hw_emulation_architecture fields recieve the
correct allowed values.
exapnded hw_architecture os_traits to match all specified in nova object
fields.
Depends-On: https://review.opendev.org/c/openstack/nova-specs/+/824044
Implements: blueprint pick-guest-arch-based-on-host-arch-in-libvirt-driver
Closes-Bug: 1863728
Signed-off-by: Jonathan Race <jrace@augusta.edu>
Change-Id: I891cd43b2b97b3774ff923e3487a153a5ba237ef
Instances with VNIC_TYPE_SMARTNIC port need PCI devices tagged as
"remote_managed" in the PCI whitelist, however, not all compute drivers
may support the necessary functionality or have the necessary devices.
A new trait is added in order to allow a pre-filter based on it to be
implemented to avoid considering compute hosts that do not support
"remote_managed" ports.
Implements: blueprint integration-with-off-path-network-backends
Needed-By: I168d3ccc914f25a3d4255c9b319ee6b91a2f66e2
Change-Id: If5a4c81084ff9f9f8fecf9fa4cd62fc98e3efcd9
Task: 44048
Story: 2009706
The 'bochs' display device is a recommended[1] safe option for UEFI
guests.
This lets an admin set the trait either via the flavor extra-specs or
image metadata properties:
trait:COMPUTE_GRAPHICS_MODEL_BOCHS=required
This also allows The libvirt virt dirver report a standard trait
for bochs graphics model support and enables the image_metadata_prefilter
to automatically request the trait. This will enable vm that request
the bochs graphics model to be automaticaly scheduled to hosts that
can support it.
Implements: blueprint add-bochs-display-device
[1]: https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#tldr
Change-Id: Iba867f4632853f99373976e39c3494ea1c8b91a2
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
This allows us to report this trait and use it to filter out hosts that
support our requested 'hw_firmware_type'.
Change-Id: Ifc06d6f9b1d3217d09fa20aafc2988acb11c80f2
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
The new trait will be used to signal that compute hosts can honor the
new `socket` value of hw_pci_numa_affinity_policy. It will be helpful
in rolling upgrade scenarios, mixed hypervisor clouds, and just to
make scheduling faster.
Implements: blueprint pci-socket-affinity
Change-Id: Ia4d1871b719037174506fb784b77572e63303762
Introduce a trait, COMPUTE_SECURITY_UEFI_SECURE_BOOT, as discussed in
the Secure Boot spec[1]. (Yeah, it reads a little awkward, not sure if
we can avoid it, as I've included it as part of compute/security.py
file.)
This lets an admin set the trait either via the flavor extra-specs or
image metadata properties:
trait:COMPUTE_SECURITY_UEFI_SECURE_BOOT=required
to request to boot an instance in Secure Boot mode. Nova's libvirt
driver is responsible make sure the compute node has the necessary
capabilities (e.g. relevant libvirt, QEMU, OVMF, EDK2 et al versions).
If the host hypervisor is incapable, the instance creation will fail.
[1] https://opendev.org/openstack/nova-specs/src/branch/master/specs/wallaby/approved/allow-secure-boot-for-qemu-kvm-guests.rst#fnref8
blueprint: allow-secure-boot-for-qemu-kvm-guests
Change-Id: I333147dcd47c6d0b926338a5a0c545f5adc63961
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
When a Cyborg device profile name is present in the flavor, the
conductor will initiate creation and binding of accelerator requests,
and the compute manager must wait for the ARQ binding notifications.
In a deployment where the conductor is new, but one or more compute
managers are older than the needed version, this flow will break.
To prevent that: (a) the compute manager publishes this trait,
and (b) the scheduler factors this trait in the Placement query, so
that older compute nodes are not included in allocation candidates.
Change-Id: I6dc00248b54f3a8a5d5dae284d2182df5ba550ab
This change adds the COMPUTE_RESCUE_BFV trait for use when attempting to
rescue boot from volume instances.
Partial-Implements: blueprint virt-bfv-instance-rescue
Change-Id: Ida736058100b5a724da7156399b0c67a9854a806
This adds a compute capability trait to model the
nova ComputeDriver supports_migrate_to_same_host capability [1].
There is a latent bug in nova where configuring the
allow_resize_to_same_host option to True can potentially
lead the scheduler to pick the same host the server is on
to start a cold migration which is only supported by the
(in-tree) vCenter driver (since that driver manages a vCenter
cluster of ESXi hosts). This can lead to at best the cold migration
flow picking an alternate host and at worst failing the cold migration.
Either is not desirable if nova could make a better decision during
scheduling by asking placement for only compute nodes that support
this type of operation.
In absence of the trait, nova can workaround the issue with a
config option [2] such that when cold migrating the API can determine
if the current host that the instance is on should be ignored during
scheduling. With the trait, nova could deprecate and remove that workaround
by having the compute API determine if the host that the instance is on
is suitable for same-host cold migration by finding the provider using
the ComputeNode related to the instance (via host/node on the instance)
and if that provider has the COMPUTE_SAME_HOST_COLD_MIGRATE trait [3]. That
would still leave the nova scheduler to filter out allocation candidates
using the RequestSpec.ignore_hosts list as it does today but it's better
than using a global config option in the API which could be wrong for a
mixed hypervisor deployment.
[1] https://github.com/openstack/nova/blob/19.0.0/nova/virt/driver.py#L153
[2] https://review.opendev.org/676022/
[3] https://review.opendev.org/695220/
Change-Id: I29ef5c402e0d006518bfce14f616e58f85ce7c9d
Related-Bug: #1748697
We have at least one use case [1] for identifying resource providers
which represent compute nodes. There are a few ways we could do that
hackishly (e.g. [2], [3]) but the clean way is to have nova-compute mark
the provider with a trait, since nova-compute knows which one it is
anyway.
This commit adds a COMPUTE_NODE trait for this purpose.
[1] https://review.opendev.org/#/c/670112/7/nova/cmd/manage.py@2921
[2] Assume a provider with a certain resource class, like MEMORY_MB, is
always a compute node. This is not necessarily future-proof (maybe all
MEMORY_MB will someday reside on NUMA node providers; similar for other
resource classes) and isn't necessarily true in all cases today anyway
(ironic nodes don't have MEMORY_MB inventory) and there's also currently
no easy way to query for that (GET /resource_providers?MEMORY_MB:1 won't
return "full" providers, and you can't ask for :0).
[3] Assume a root provider without the MISC_SHARES_VIA_AGGREGATE trait
is a compute node. This assumes you're only using placement for nova-ish
things.
Change-Id: I036dd5cab15144447df5346814d5f0e8fd91135d
Adds a comment with a link to the spec for the recently-added
COMPUTE_MIGRATE_AUTO_CONVERGE and COMPUTE_MIGRATE_POST_COPY traits.
blueprint expose-auto-converge-post-copy
Change-Id: I89a67614cbd2da2840dc9f6a2fdf4f4633ca149f
This will be used by nova to signal when a compute node
resource provider is disabled so that a placement request
pre-filter in the nova scheduler can ask placement to filter
out compute node allocation candidates that are disabled,
similar to the post-placement ComputeFilter.
Part of nova blueprint pre-filter-disabled-computes
Change-Id: Ia8e4487bfb59f764a6817ec8650785ffa902eab5
This change extends the COMPUTE_GRAPHICS
module with 3 new traits for the GOP, NONE and
VIRTIO models.
Depends-On: https://review.opendev.org/#/c/647733/
Change-Id: I17945e8ad6ea5349f46c26e427a0f539ca5eba8b
Task: 30526
Story: 2005447
- This change introduces standard traits for the
well defined hw_disk_model, hw_cdrom_model, hw_video_model
and hw_vif_model image metadata properties.
- This spec defines all of the new traits in the compute
namespace as they represent the ability of a hypervisor to
emulate a specific virtual device model, not the presence
of the respective hardware device on the host.
Change-Id: I42237b196644bfa87701f978a1519941d447b450
Task: 30526
Story: 2005447
Adds a comment to the compute.image module proposed in [1] providing
context on where the values were derived from, and that they should be
kept in sync in the (perhaps unlikely) event that more image types are
added in the future.
[1] I2a76e6b1062b0112faec73cef4a369124e45aa98
Change-Id: I1f0d79e3e77d23d3a190bad594c504ef5503cc67
These are traits used to represent Glance image types that may be supported
by a service such as nova-compute. Glance defines these types rigidly in
their documentation:
https://docs.openstack.org/image-guide/image-formats.html#disk-formats
and thus they should be stable and standardized for use in placement
queries.
Change-Id: I2a76e6b1062b0112faec73cef4a369124e45aa98
This mirrors the compute driver "supports_trusted_certs"
capability added to nova in change:
Ie3130e104d7ca80289f1bd9f0fee9a7a198c263c
This is something validated during server creation
and if the user requests trusted image cert validation
but the driver does not support it, the create request
on that host fails. We eventually want to publish these
driver capabilities as traits so we can optimize scheduling
to avoid those types of capabilities-based build failures:
I15364d37fb7426f4eec00ca4eaf99bec50e964b6
Related to blueprint nova-validate-certificates
Change-Id: I0a67ce94b03b5707802935ddd36aedc622fe12fe
The virt driver API in nova has a capabilities dict that lists the
capabilities of the virt driver.
Based on the patch at https://review.openstack.org/#/c/538498/6, let's
try to standardize the relevant capabilities into a new
os_traits.compute module.
Change-Id: I77f2c4c696010dfe25d3282374dac702b08abaa6