nova — Flavors kubevirt mapping

Flavor ↔ KubeVirt instancetype mapping — Nova — branch stable/2026.2

Nova branch stable/2026.2 @ 8df1922926dd — KubeVirt v1.9.1 @ c3d19093f9c7 (instancetype.kubevirt.io/v1beta1, the only version of that API in this release; sparse clone of staging/src/kubevirt.io/api) — analysed on 2026-10-28 References: nova/… = Nova repository; kubevirt:… = KubeVirt repository at the tag above.

This file says how OpenKeel can expose the Nova flavor API unchanged while running servers as KubeVirt VirtualMachines. It gives the mapping field by field and extra spec by extra spec. Every rule is also data (_rewrite/flavor-kubevirt-mapping_stable-2026.2.json) and code (_rewrite/flavor-to-kubevirt_stable-2026.2.py). The converter was run on 6 reference flavors (_rewrite/flavor-kubevirt-vectors_stable-2026.2.json).

1. Object model

KubeVirt has no disabled flag, no access-list API and no "list sizes visible to a project" query merging both kinds. OpenKeel keeps the flavor catalogue as its source of truth, for example in its own database or as an annotation on the instancetype, and reconciles the KubeVirt objects from it.

2. Base fields

3. Extra specs

Coverage: the 525 validators of Nova's registry (_rewrite/extra-spec-validators_stable-2026.2.json) all match a rule below (checked by script, validator_coverage in the mapping JSON). By fidelity:

The 458 "partial" rules are mostly the 378 traits and 45 capabilities: they become node labels, and that only works if an OpenKeel agent puts the same labels on the nodes.

Keys that are not in the registry (allowed by Nova outside its namespaces) are kept in the annotation and reported as unknown by the converter.

Notes on the important translations

• CPU pinning. hw:cpu_policy=dedicated maps exactly to dedicatedCPUPlacement, but KubeVirt needs the kubelet static CPU manager and Guaranteed QoS on the node. mixed has no equivalent. Nova also converts dedicated vCPUs into PCPU resources (nova/scheduler/utils.py:363-417); in KubeVirt, the kubelet CPU manager does that accounting.
• Realtime mask. Nova's mask excludes vCPUs (^0-1), KubeVirt's mask lists them in libvirt syntax (kubevirt:staging/src/kubevirt.io/api/core/v1/schema.go:393-398). The converter writes 0-<vcpus-1>,<nova mask>.
• Huge pages. A bare number is KiB in Nova (nova/virt/hardware.py:1572-1573). 1GB → 1Gi, 2048 → 2Mi. large has no "best available" equivalent: the converter picks 2Mi.
• NUMA. KubeVirt can only pass through the host layout of the pinned CPUs (kubevirt:staging/src/kubevirt.io/api/core/v1/schema.go:403-410). hw:numa_nodes, hw:numa_cpus.N and hw:numa_mem.N lose their exact layout.
• Memory encryption is the best fit: the four Nova models map to sev, sev + encryptedState, snp and tdx (kubevirt:staging/src/kubevirt.io/api/core/v1/schema.go:856-893). Nova's default model, when only hw:mem_encryption=true is set, is AMD SEV (nova/virt/hardware.py:1488-1489).
• Traits and aggregates. An instancetype has a nodeSelector (kubevirt:staging/src/kubevirt.io/api/instancetype/v1beta1/types.go:83) but no affinity. So:
  • required traits and plain aggregate values go there;
  • forbidden traits and aggregate operators (<in>, s>=…) must go into the VirtualMachine's affinity.
• Devices. PCI aliases and vGPUs need an OpenKeel configuration mapping each Nova [pci] alias and mdev type to a permittedHostDevices resource name.
• QoS. Disk and network QoS move to the StorageClass and the CNI. CPU shares follow the pod requests, which KubeVirt derives from vcpus / cpuAllocationRatio [inferred: KubeVirt cluster configuration, not part of the sparse clone].

4. Image properties that end in the preference

Most hw:<x> extra specs have an image twin hw_<x>, and Nova refuses conflicts (01 § 5). In KubeVirt, a single preference holds both:

• OpenKeel builds the preference from the flavor's extra specs, then the image properties;
• it refuses the boot, as Nova does, when the two disagree, applying Nova's rules: nova/virt/hardware.py:1361-1390 for strict equality, and nova/virt/hardware.py:1776-1823 for an image that cannot raise the flavor's CPU policy.

Image-only properties (not flavors) with a direct preference target [inferred: not part of this flavor scope, listed to complete the preference]:

requirements.cpu.guest and requirements.memory.guest (kubevirt:staging/src/kubevirt.io/api/instancetype/v1beta1/types.go:641-669) make KubeVirt refuse an instancetype that is too small for the preference. That matches Nova's FlavorMemoryTooSmall check against the image min_ram.

5. What OpenKeel puts in each VirtualMachine

The converter also returns a VM fragment:

• spec.instancetype / spec.preference → {kind, name};
• the root disk size (disk, or the image size when disk = 0);
• the ephemeral and swap emptyDisks;
• what has no place in an instancetype: watchdog, USB redirection, CPU limit from quota:cpu_quota, bandwidth annotations, NotIn affinity for forbidden traits.

The server API must keep showing the Nova flavor:

• from 2.47, server.flavor = {original_name, vcpus, ram, disk, ephemeral, swap, extra_specs} taken from the revision and the annotations, not from the current instancetype (nova/api/openstack/compute/views/servers.py:652-684);
• before 2.47, {id, links}.

6. Reference flavors (vectors)

_rewrite/flavor-kubevirt-vectors_stable-2026.2.json, produced by flavor-to-kubevirt_stable-2026.2.py --vectors:

7. Gaps and recommendations

1. No exact equivalent:
   • hw:cpu_policy=mixed;
   • an explicit NUMA layout;
   • hw:cpu_thread_policy per VM;
   • swap;
   • per-flavor disk and VIF QoS;
   • hw:locked_memory, hw:pmem, hw:pmu, hw:viommu_model, hw:usb_model, hw:boot_menu, hw:virtio_packed_ring, hw_rng rates, hw_video:ram_max_mb;
   • accel:device_profile (Cyborg). Announce them as compatibility gaps of OpenKeel. Keep the keys, so that the API round trip stays exact.
2. Validate like Nova ≥ 2.86 with the registry file: same types, enumerations, patterns and namespaces. Refuse what Nova refuses, and accept what Nova accepts even if KubeVirt ignores it.
3. Keep Placement semantics where KubeVirt has none. Quotas count vcpus, ram and disk of the flavor. They are not Kubernetes ResourceQuota requests, which are divided by the CPU allocation ratio.
4. Node labels for traits, aggregates and capabilities must be published by an OpenKeel node agent with a fixed prefix (openkeel.io/trait.<TRAIT>, openkeel.io/aggregate.<key>).
5. Names: keep the Nova name uniqueness check and the id → Kubernetes name encoding stable. The encoding is part of the contract between OpenKeel components.

8. Checklist for the OpenKeel flavor service

• [ ] Flavor API of 01, up to 2.104, with the same status codes (200 on create, 202 on delete, 200 on extra-spec delete) and messages of 02.
• [ ] Visibility rules (public + access list; admin is_public filter; disabled hidden).
• [ ] Extra-spec validation from the registry file (≥ 2.86 only).
• [ ] Reconciler: flavor → (Cluster)Instancetype / Preference per the rules; delete leaves VMs untouched.
• [ ] Server view of the flavor from the VM's revision.
• [ ] Resize: switch the instancetype, keep old for revert, refuse the cases of 01 § 7.
• [ ] Versioned notifications flavor.create/update/delete with FlavorPayload 1.4, if consumers rely on them.

Source: reverse-spec-nova/07-flavors-kubevirt-mapping_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.