Problem
VmHost, VmTemplate, and VmCustomTemplate all carry cpu_arch: CpuArch (x86_64 / arm64), but VmOsImage does not. Nothing prevents an x86_64 cloud image from being provisioned onto an arm64 host (or vice versa) — the image catalog is architecture-blind.
Proposal
- Migration:
ALTER TABLE vm_os_image ADD COLUMN cpu_arch SMALLINT UNSIGNED NOT NULL DEFAULT 1 (default = x86_64, correct for all existing images)
- Models: add
cpu_arch to VmOsImage (lnvps_db), ApiVmOsImage (user API), and the admin create/update/list models
- Provisioning: filter image selection by host/template arch compatibility so incompatible images cannot be deployed
- User API: expose
cpu_arch on GET /api/v1/image (open question: also filter the listing by requested/template arch?)
- Docs: update
API_DOCUMENTATION.md, ADMIN_API_ENDPOINTS.md, API_CHANGELOG.md
Notes
CpuArch enum already exists (Unknown = 0, X86_64 = 1, ARM64 = 2) with FromStr/Display (accepts amd64/aarch64 aliases)
- Most distros publish separate cloud images per arch (e.g. Debian
-amd64/-arm64, Ubuntu -amd64/-arm64), so the admin UI can eventually offer both variants of the same distro/version
Problem
VmHost,VmTemplate, andVmCustomTemplateall carrycpu_arch: CpuArch(x86_64 / arm64), butVmOsImagedoes not. Nothing prevents an x86_64 cloud image from being provisioned onto an arm64 host (or vice versa) — the image catalog is architecture-blind.Proposal
ALTER TABLE vm_os_image ADD COLUMN cpu_arch SMALLINT UNSIGNED NOT NULL DEFAULT 1(default = x86_64, correct for all existing images)cpu_archtoVmOsImage(lnvps_db),ApiVmOsImage(user API), and the admin create/update/list modelscpu_archonGET /api/v1/image(open question: also filter the listing by requested/template arch?)API_DOCUMENTATION.md,ADMIN_API_ENDPOINTS.md,API_CHANGELOG.mdNotes
CpuArchenum already exists (Unknown = 0,X86_64 = 1,ARM64 = 2) withFromStr/Display(acceptsamd64/aarch64aliases)-amd64/-arm64, Ubuntu-amd64/-arm64), so the admin UI can eventually offer both variants of the same distro/version