feat: a new VM's CPU model can be chosen, from a list the hypervisor offers #3

2026-10-04T10:03:09Z

christianmanivong commented

2026-10-04 10:03:09 +00:00

create_vm_from_cloud_init gets cpu_type, and there is a new optional get_vm_cpu_types() returning VMCpuTypeDict entries (name, description, cpuinfo features, available on this node, default).

Why: Proxmox gives a VM created without a CPU model kvm64, which has no AVX, so MongoDB 5.0+ (and netOrk's graylog role) cannot run there (NetOrk/netork#494). Which model is right depends on the cluster, so the caller chooses from what the hypervisor lists.

Optional capability: VMware has no per-VM CPU model, does not implement the listing and must reject a non-None cpu_type.
Declarations stay under TYPE_CHECKING, so hasattr remains a truthful probe; the test reads the signature from the source.

Used by NAPALM/napalm-proxmox and NAPALM/napalm-vmware branches feat/vm-cpu-type, and by netOrk's provisioning dialog.

`create_vm_from_cloud_init` gets `cpu_type`, and there is a new optional `get_vm_cpu_types()` returning `VMCpuTypeDict` entries (name, description, cpuinfo `features`, `available` on this node, `default`). Why: Proxmox gives a VM created without a CPU model `kvm64`, which has no AVX, so MongoDB 5.0+ (and netOrk's graylog role) cannot run there (https://git.netork.io/NetOrk/netork/issues/494). Which model is right depends on the cluster, so the caller chooses from what the hypervisor lists. - Optional capability: VMware has no per-VM CPU model, does not implement the listing and must reject a non-None `cpu_type`. - Declarations stay under `TYPE_CHECKING`, so `hasattr` remains a truthful probe; the test reads the signature from the source. Used by NAPALM/napalm-proxmox and NAPALM/napalm-vmware branches `feat/vm-cpu-type`, and by netOrk's provisioning dialog.

christianmanivong added 1 commit 2026-10-04 10:03:09 +00:00

feat: a new VM's CPU model can be chosen, from a list the hypervisor offers b5c40019af

create_vm_from_cloud_init takes cpu_type. Proxmox gives a VM created without
one the kvm64 model, which has no AVX, so MongoDB 5.0 and later do not start
there, and netOrk's graylog role failed on every VM it provisioned
(netork#494). Which model is right depends on the cluster: host cannot
live-migrate between different CPUs, x86-64-v3 does not start on a CPU older
than Haswell. So the caller chooses.

get_vm_cpu_types() is the new, optional listing behind that choice. Each
VMCpuTypeDict names the model, says what it is for, lists the /proc/cpuinfo
flags the guest gets (so a caller can ask "does this give AVX?" without
knowing model names), whether the node at hand can run it, and which one is
the default. A hypervisor whose VMs have no per-VM CPU model (VMware sets CPU
compatibility per cluster) does not implement it and must reject any
cpu_type other than None.

Both declarations sit under TYPE_CHECKING like the rest of the contract, so
hasattr stays a truthful capability probe; the tests read the signature from
the source.

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin feat/vm-cpu-type:feat/vm-cpu-type

git checkout feat/vm-cpu-type

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: NAPALM/napalm-device-types#3