Support VDS (Virtual Dedicated Servers): dedicated CPU/RAM templates with no overcommit

[v0l]

Goal

Offer VDS products alongside the existing VPS line: VMs with dedicated, non-oversubscribed CPU cores and RAM (host CPU passthrough, optionally pinned cores), sold at a premium. Everything below is based on a deep dive of the current code.

Where the codebase stands today

Area	Current state	Relevance
VmTemplate (lnvps_db/src/model.rs)	Has cpu, memory, cpu_mfg/arch/features, cpu_limit (fractional cap), IOPS/net caps, cost_plan_id, region_id	Natural place for a dedicated class flag; cpu_limit is the opposite lever (throttling shared VMs)
VmHost	load_cpu / load_memory / load_disk are host-wide overcommit factors	Dedicated VMs must bypass these; a host cannot express "N cores reserved"
Capacity engine (lnvps_api_common/src/capacity.rs)	available_cpu() = cpu * load_cpu - consumed, summed over all VMs uniformly	No way to account shared and dedicated consumption differently on one host
Proxmox client (lnvps_api/src/host/proxmox.rs)	VMs created with cpu: "kvm64" (from QemuConfig.cpu), supports cpulimit	No cputype=host, no affinity (PVE 7.3+ core pinning), no numa, no cpuunits, no hugepages
Libvirt client (lnvps_api/src/host/libvirt.rs)	Plain <vcpu>/<memory> XML	No <cputune>/<vcpupin>, no host-passthrough CPU mode, no <numatune>
Provisioner / placement	Picks host by region + arch/mfg/features + capacity	Needs host-class awareness
Pricing	Per-template via cost_plan_id; custom pricing per region	Dedicated templates can simply carry their own (pricier) cost plans — little work needed

Design

1. Data model (migration)

• vm_template.dedicated BOOLEAN NOT NULL DEFAULT 0 (or a template_class enum if more classes are expected later).
• vm_host.host_class SMALLINT NOT NULL DEFAULT 0 — 0 = Shared, 1 = Dedicated. Phase 1 keeps the classes exclusive per host: dedicated templates only place on dedicated hosts, whose load_cpu/load_memory are forced to 1.0.
• (Phase 3, only if mixing classes on one host) vm_core_assignment (vm_id, host_id, core_idx) table recording pinned cores, so the allocator can hand out disjoint core sets and reclaim them on delete.

2. Capacity engine

Phase 1 (host-class separation) keeps capacity.rs almost unchanged:

• list_available_vm_templates / placement filter hosts by host.host_class == template.class.
• Dedicated hosts run with load factors 1.0, so the existing arithmetic already yields no-overcommit accounting.
• Guard: reject load_cpu/load_memory != 1.0 on dedicated hosts in admin API validation (or clamp).

Mixing shared + dedicated on one host is much harder (shared VMs still steal cycles unless every dedicated VM is pinned and shared VMs are confined to the complementary core set via affinity/cgroup cpusets). Defer.

3. Proxmox host client

For VMs from dedicated templates:

• cpu: host (CPU passthrough) instead of the configured kvm64 — expose as QemuConfig.dedicated_cpu or derive from the template flag.
• cpuunits: 10000 so dedicated VMs win scheduling against any co-located workload.
• Optional core pinning via the PVE affinity: <core-list> config key (PVE >= 7.3), driven by the core allocator (phase 5).
• Optional: numa: 1 + hugepages for large-memory templates.
• Note: cputype=host breaks live-migration between heterogeneous hosts — acceptable for VDS (document it), and cpu_mfg/cpu_features matching already exists to keep templates on homogeneous hardware.

4. Libvirt host client (parity, later)

• <cpu mode="host-passthrough"/>, <cputune><vcpupin vcpu="N" cpuset="M"/></cputune>, <numatune> as needed.

5. API surface

• User API: dedicated: bool on template/VM responses so the frontend can badge VDS plans; capacity-aware template listing already flows through list_available_vm_templates.
• Admin API: CRUD for the template flag + host class; validation as above.
• ApiVmTemplate, admin models, and E2E fixtures updated.

6. Explicitly out of scope (follow-ups)

• Mixed shared/dedicated hosts with core-set partitioning (needs vm_core_assignment + confining shared VMs to the complement).
• Converting an existing shared VM to VDS in place (would be a migration/upgrade flow like Transfer VM #178/VM addons #187).
• Dedicated disk spindles/NVMe namespaces — current VmHostDisk + IOPS caps are considered sufficient.

Suggested phasing (one PR each)

1. DB + admin API: migration, dedicated template flag, host_class, validation. (S)
2. Capacity/placement: class-aware host filtering + template availability. (S)
3. Proxmox: cpu: host + cpuunits for dedicated VMs, config plumbed through FullVmInfo. (M)
4. User API exposure + E2E test covering provision-on-dedicated-host. (S)
5. Core pinning allocator (affinity) — optional hardening. (M)
6. Libvirt parity. (M)

Acceptance criteria (phases 1-4)

• A template flagged dedicated only ever places on a Dedicated-class host, with 1:1 CPU/RAM accounting (no overcommit).
• Proxmox VMs from dedicated templates run with host CPU passthrough and elevated cpuunits.
• Shared templates never place on dedicated hosts and vice versa.
• Template/VM API responses expose the dedicated flag.

[v0l]

Revised design: weighted cpuunits instead of host-class separation

Rather than segregating the fleet into Shared/Dedicated hosts, encode the overcommit ratio directly into each VM's CPU scheduling weight:

cpuunits = vcpus * 100 / load_cpu   # shared  (e.g. 300% overcommit, 1 vCPU -> ~33)
cpuunits = vcpus * 100              # dedicated (VDS)

Why scale by vCPU count: Proxmox cpuunits (cgroup v2 cpu.weight, default 100, range 1-10000) is a per-VM weight covering all of the VM's vCPU threads — without the vcpus factor, a 1-core and an 8-core VM would receive equal host shares under contention.

Why this works: under CFS, host CPU divides proportionally to weight. If every VM's weight equals its effective reserved cores × 100 (dedicated at 1:1, shared at 1/load_cpu), and capacity accounting reserves in the same units, then total weight <= host cores × 100 and a dedicated VM is guaranteed its full cores whenever it wants them — while shared VMs proportionally squeeze into the remainder. No pinning, no fleet segregation, and mixed hosts work from day one.

Bonus: this also fixes an existing fairness gap — today all shared VMs get the default weight regardless of size, so a 1-core VM contends equally with an 8-core VM.

Changes vs. the original plan

1. Drop vm_host.host_class (phase 1) — no fleet segregation needed. Keep vm_template.dedicated flag.
2. Capacity engine: replace host-wide load_cpu division with per-VM weighted consumption: consumed = sum(dedicated_cores) + sum(shared_cores / load_cpu) compared against host.cpu. Same for placement checks. (This replaces the "load factors forced to 1.0" trick.)
3. Proxmox client: emit cpuunits on create/update for all VMs (shared and dedicated) using the formula above; dedicated templates additionally get cpu: host passthrough.
4. Existing fleet: a one-time reconcile pass (or apply-on-next-configure) to patch cpuunits onto already-running VMs so the weights actually hold.
5. Core pinning (affinity) demoted to an optional later hardening step — weights already provide the throughput guarantee; pinning only adds cache/NUMA locality.

Caveats (documented, accepted)

• This is a scheduling-throughput guarantee, not isolation: no cache/NUMA/SMT partitioning. Fine for VDS positioning; pinning can be layered on later.
• Memory cannot be weighted. Dedicated RAM must be accounted 1:1 in the capacity engine; on mixed hosts, RAM overcommit (load_memory > 1.0) applies only to the shared portion, and hosts intended for VDS-heavy use should run load_memory = 1.0 to avoid OOM pressure reaching dedicated VMs.
• cgroup v1 hosts use a different default (1024) — derive the base from the host's cgroup version or just require cgroup v2 (PVE 7+ default).