Provider guides
Proxmox VE: configuration and operations
Provision Proxmox VE QEMU virtual machines by cloning a template and applying the purchased configuration.
On this page
Provider workflow
Provision Proxmox VE QEMU virtual machines by cloning a template and applying the purchased configuration. The adapter checks node and storage capacity, stores a VM mapping and handles lifecycle operations with remote task checks. This is a VM adapter, not a claim of support for every Proxmox resource type.
Requirements
Agovena Core ^0.0.1. Enable Provisioning before this extension.
This extension is not marked production-ready. Validate its supported workflow in your own test environment before accepting customer orders.
Set up the package
Enable Provisioning and Proxmox and apply migrations. Set api_url, token_user, token_id, secret token_secret, node and storage on the server connection. Use a root URL such as https://pve.example.com:8006; the adapter appends /api2/json. Keep TLS verification enabled. The product requires template_vmid plus suitable CPU, memory, disk and network settings.
Provider-specific boundaries
The connection uses token_user, including its realm, plus token_id and token_secret to form a Proxmox API token credential. Do not put the credential in api_url. Paths, query strings, fragments and URL user information are rejected by the URL normalizer. A connection test checks version and node/storage capacity; it does not perform a paid provisioning cycle.
Product settings are template_vmid, cores, memory, disk, sockets, cpu_type, bridge and autostart. The declared defaults include one core, 1024 MiB memory, 20 GiB disk, one socket, CPU type host, bridge vmbr0 and autostart enabled. Treat these as starting configuration, not as proof the template, storage or bridge can satisfy it.
Test with a disposable template and sufficient reserved capacity. Verify the resulting VM belongs to the intended instance, has the expected configuration and reaches the intended running state. Test suspension and restoration separately from deletion. Provider task timeout, authorization failure and unknown VM state need different remedies. Do not disable TLS verification or remove resource checks to turn a failed health check green. 2
Configuration contract
| Field | Type | Required | Secret | Default |
|---|---|---|---|---|
api_url |
string |
Yes | No | Empty |
token_user |
string |
Yes | No | Empty |
token_id |
string |
Yes | No | Empty |
token_secret |
string |
Yes | Yes | Empty |
node |
string |
Yes | No | Empty |
storage |
string |
Yes | No | Empty |
verify_tls |
boolean |
No | No | true |
timeout |
string |
No | No | "30" |
These are the declared manifest fields. A field marked optional may still be required by an API operation, as described above. Store secret values only in protected settings, never in product descriptions, URLs or shared examples. 1
Operation and failure handling
Capacity checks compare the requested resources and existing reservations with node and storage data. Malformed responses and insufficient capacity fail rather than implying availability. Clone, start, stop and delete operations validate task IDs and poll task completion. An HTTP response alone is not proof that the VM is ready. After an interrupted operation, compare the VM mapping, remote configuration and task status before attempting another clone.