Every VM this driver created was left on Proxmox's API default kvm64 (no AES-NI, no AVX); MongoDB 5.0+ will not start on it (NetOrk/netork#494).
create_vm_from_cloud_init always passes cpu=: x86-64-v2-AES by default (the PVE GUI default), or the requested cpu_type.
get_vm_cpu_types() lists x86-64-v2-AES, x86-64-v3 and host. The named models carry the flags Proxmox's own definitions add; available compares them with the node's /nodes/{node}/status cpuinfo flags. host lists the node's flags, so it offers no AVX on a CPU without it.
A requested model is validated before a VMID is allocated; an unknown or unrunnable one raises ValueError instead of failing at VM start after the disk import.
Tests use real flag sets from a Celeron J3455 (no AVX) and an i7-7700. Needs NAPALM/napalm-device-types feat/vm-cpu-type for the type only (imported under TYPE_CHECKING).
Every VM this driver created was left on Proxmox's API default `kvm64` (no AES-NI, no AVX); MongoDB 5.0+ will not start on it (https://git.netork.io/NetOrk/netork/issues/494).
- `create_vm_from_cloud_init` always passes `cpu=`: `x86-64-v2-AES` by default (the PVE GUI default), or the requested `cpu_type`.
- `get_vm_cpu_types()` lists `x86-64-v2-AES`, `x86-64-v3` and `host`. The named models carry the flags Proxmox's own definitions add; `available` compares them with the node's `/nodes/{node}/status` cpuinfo flags. `host` lists the node's flags, so it offers no AVX on a CPU without it.
- A requested model is validated **before** a VMID is allocated; an unknown or unrunnable one raises `ValueError` instead of failing at VM start after the disk import.
Tests use real flag sets from a Celeron J3455 (no AVX) and an i7-7700. Needs NAPALM/napalm-device-types `feat/vm-cpu-type` for the type only (imported under `TYPE_CHECKING`).
A VM created without a cpu argument gets Proxmox's API default, kvm64: no
AES-NI and no AVX. MongoDB 5.0 and later exit with "Illegal instruction" on
it, which is how a Graylog provisioned through netOrk failed (netork#494).
Every VM built by hand in the same cluster uses host or x86-64-v2-AES; only
the ones this driver created were left on kvm64.
create_vm_from_cloud_init now always passes cpu=, defaulting to x86-64-v2-AES
as the Proxmox GUI does since PVE 8, and takes cpu_type for a different one.
get_vm_cpu_types() lists x86-64-v2-AES (default), x86-64-v3 and host. The
named models carry the cpuinfo flags they add over qemu64, following
Proxmox's own definitions (CPUConfig.pm), and are available when the node's
CPU has all of them, read from /nodes/{node}/status. host lists the node's
own flags, so on a CPU without AVX it does not pretend to offer any.
A model asked for by name is checked against the node before a VMID is
allocated: one the CPU cannot run would only fail at VM start, after the disk
import, leaving a half-built VM behind. The default is not checked, so a
plain create costs no extra API call. VMCpuTypeDict is imported for type
checking only, so this works with an older napalm_device_types.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Every VM this driver created was left on Proxmox's API default
kvm64(no AES-NI, no AVX); MongoDB 5.0+ will not start on it (NetOrk/netork#494).create_vm_from_cloud_initalways passescpu=:x86-64-v2-AESby default (the PVE GUI default), or the requestedcpu_type.get_vm_cpu_types()listsx86-64-v2-AES,x86-64-v3andhost. The named models carry the flags Proxmox's own definitions add;availablecompares them with the node's/nodes/{node}/statuscpuinfo flags.hostlists the node's flags, so it offers no AVX on a CPU without it.ValueErrorinstead of failing at VM start after the disk import.Tests use real flag sets from a Celeron J3455 (no AVX) and an i7-7700. Needs NAPALM/napalm-device-types
feat/vm-cpu-typefor the type only (imported underTYPE_CHECKING).A VM created without a cpu argument gets Proxmox's API default, kvm64: no AES-NI and no AVX. MongoDB 5.0 and later exit with "Illegal instruction" on it, which is how a Graylog provisioned through netOrk failed (netork#494). Every VM built by hand in the same cluster uses host or x86-64-v2-AES; only the ones this driver created were left on kvm64. create_vm_from_cloud_init now always passes cpu=, defaulting to x86-64-v2-AES as the Proxmox GUI does since PVE 8, and takes cpu_type for a different one. get_vm_cpu_types() lists x86-64-v2-AES (default), x86-64-v3 and host. The named models carry the cpuinfo flags they add over qemu64, following Proxmox's own definitions (CPUConfig.pm), and are available when the node's CPU has all of them, read from /nodes/{node}/status. host lists the node's own flags, so on a CPU without AVX it does not pretend to offer any. A model asked for by name is checked against the node before a VMID is allocated: one the CPU cannot run would only fail at VM start, after the disk import, leaving a half-built VM behind. The default is not checked, so a plain create costs no extra API call. VMCpuTypeDict is imported for type checking only, so this works with an older napalm_device_types.