Provisioning System

Provisioning purpose

The provisioning system is responsible for turning a customer order, admin action, or billing event into a real virtual machine on Proxmox. VMNexor handles the control-plane logic so billing systems do not need direct Proxmox awareness.

Provisioning flow

Request → Validate plan → Validate template → Select node → Assign storage/IP → Clone template → Configure guest → Start service → Sync state

Plan validation

• Confirms the requested package exists
• Confirms CPU, memory, and disk values are allowed
• Confirms the selected template is allowed for the plan
• Confirms reinstall rules where the request is a reinstall
• Prevents billing adapters from bypassing VMNexor policy

Node and storage selection

• Checks that a usable node exists
• Confirms the target storage is available
• Ensures the selected template can be cloned
• Avoids provisioning to unavailable or unsuitable infrastructure where possible

IP assignment

IP assignment should match the real network design on the target node. Bridged networks and routed /32 networks require different guest configuration, so each plan and template combination should be tested before public use.

Linux provisioning

• Applies network configuration
• Sets DNS where required
• Handles OS-family-specific networking behaviour
• Supports routed configuration where the template and node are prepared for it
• Validates that the service can boot and be accessed

Windows provisioning

• Uses Windows-compatible template behaviour
• Relies on QEMU Guest Agent where guest-aware actions are required
• Supports Cloudbase-Init workflows where configured
• Allows password handling to match the template design
• Keeps Windows desktop and Windows Server account behaviour separate where needed

Reinstall provisioning

A reinstall is a destructive reprovisioning action. VMNexor should validate the allowed templates, apply the service reinstall policy, replace the operating system, and preserve only the service-level state that should survive the reinstall.

Billing-triggered provisioning

Billing providers such as WHMCS should send lifecycle requests to VMNexor. VMNexor then applies its own validation and infrastructure logic before touching Proxmox. This keeps the billing layer replaceable.

Failure handling

• Check the VMNexor service state
• Check Proxmox task output
• Confirm the template still exists
• Confirm storage has capacity
• Confirm an IP was available
• Confirm guest configuration completed
• Retry only after identifying the failure point

Safe testing flow

• Create one disposable plan
• Use one known-good Linux template
• Provision a disposable VM
• Test boot, network, DNS, console, and power controls
• Repeat with Windows if Windows is supported
• Only then enable billing automation