Proxmox VE has become one of the most popular destinations for organizations rethinking their hypervisor strategy. Until recently, the trade-off was automation: RAS couldn’t provision or power-manage Proxmox VMs natively. With the Custom Provider Framework (CPF) introduced in Parallels RAS 21.2, and an official Proxmox sample connector from Parallels, that gap is closed.
This guide walks through a production-minded RAS on Proxmox deployment.
What the Proxmox provider does
The Proxmox connector is a script that RAS calls through the CPF’s standardized JSON protocol. It translates RAS requests into Proxmox VE API calls for:
- Onboarding the Proxmox cluster as a provider
- Enumerating VMs and reading guest information
- Power operations
- Template promotion and versioning
- Cloning new session hosts from templates
Parallels publishes the Proxmox sample, a basic skeleton and a test kit in its RAS-PowerShell GitHub repository.
Reference architecture
- Hypervisor: Proxmox VE cluster (three or more nodes for HA)
- Storage: shared storage such as Ceph or an external SAN/NAS, so clones can run on any node
- RAS infrastructure: Connection Brokers, Secure Gateways and RAS Reporting, on Proxmox or separate hosts
- Session hosts: Windows Server RDSH or Windows VDI, cloned by RAS from a Proxmox template
- Profiles: FSLogix containers on an SMB share
- Access: RAS Secure Gateways with HALB or an external load balancer
Step 1: Prepare Proxmox
- Create a dedicated resource pool for RAS-managed VMs
- Create an API token for the connector, scoped to that pool with only the privileges it needs
- Confirm network bridges or VLANs give session hosts access to Active Directory and the RAS infrastructure
- Use shared storage for templates and clones where possible
Technical steps
Run these on any cluster node. The names are examples.
# Resource pool for RAS-managed VMs
pveum pool add ras-pool --comment "Parallels RAS session hosts"
# Service account and a role with only what the connector needs
pveum user add ras-svc@pve --comment "Parallels RAS connector"
pveum role add RASProvider --privs "VM.Audit VM.Allocate VM.Clone VM.PowerMgmt VM.Config.CPU VM.Config.Memory VM.Config.Disk VM.Config.Network VM.Config.Options Datastore.Audit Datastore.AllocateSpace"
# Grant the role on the pool and on the storage that holds clones
pveum acl modify /pool/ras-pool --users ras-svc@pve --roles RASProvider
pveum acl modify /storage/<storage-id> --users ras-svc@pve --roles RASProvider
# API token with privilege separation off, so it inherits the user's rights
pveum user token add ras-svc@pve ras-connector --privsep 0
- Copy the token secret when it is shown. Proxmox displays it once.
- Add the template VM and the storage to the pool, or the connector will not see them.
- Confirm the RAS server that runs the connector can reach the Proxmox API on TCP 8006 on every node.
- If the cluster uses a self-signed certificate, either install a trusted one or import the Proxmox CA on the RAS server.
Step 2: Build the Windows golden image
- Install Windows Server or Windows client with VirtIO drivers for disk and network
- Install the QEMU guest agent, so Proxmox (and therefore RAS) can read guest details such as IP address and shut the VM down cleanly
- Install the RAS agent, FSLogix and your applications
- Apply your optimizations, then Sysprep and shut down
- Convert the VM to a template in Proxmox
Technical steps
- Create the VM with a VirtIO SCSI controller, a VirtIO network adapter and the QEMU agent option enabled. Attach the Windows ISO and the virtio-win driver ISO.
- During Windows setup, choose “Load driver” and point it at the virtio-win ISO so the installer can see the disk.
- After first boot, run the virtio-win guest tools installer from the ISO. It installs the remaining drivers and the QEMU guest agent.
- Check the agent from the Proxmox node before going further:
qm set <vmid> --agent enabled=1
qm agent <vmid> ping
qm agent <vmid> network-get-interfaces
- Install the RAS agent for the role (RD Session Host or Guest Agent), FSLogix and your applications, then patch Windows fully.
- Generalize and shut down from inside Windows:
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
- Convert the powered-off VM to a template:
qm template <vmid>
Keep a non-templated copy of the image VM. A Proxmox template cannot be started, so you need the copy to patch and re-promote later.
Step 3: Choose linked or full clones
Linked clone
- Pros: very fast provisioning, low storage use
- Cons: depends on the template’s base disk; storage must support it
Full clone
- Pros: fully independent VM, simpler lifecycle
- Cons: slower to create, uses more storage
For pooled, non-persistent RDSH hosts, linked clones usually give the best provisioning speed. For persistent VDI, full clones are simpler to manage.
Technical steps
- Check your storage type first. Linked clones need storage with snapshot or clone support, such as Ceph RBD, ZFS, LVM-thin, or qcow2 disks on NFS or directory storage. Plain LVM does not support them.
- Test both clone types by hand before RAS does it, so storage problems show up early:
# Linked clone (the default when cloning a template)
qm clone <template-vmid> <new-vmid> --name ras-test-01 --pool ras-pool
# Full clone
qm clone <template-vmid> <new-vmid> --name ras-test-02 --pool ras-pool --full 1
- Remember that a template with linked clones cannot be deleted until every clone based on it is gone. Plan template versions around that.
Step 4: Configure and test the connector
Download the Proxmox sample from the Parallels repository and configure it with your Proxmox API endpoint, token, node or pool and storage settings. Before connecting it to RAS, run the test kit against a lab pool to check each operation: enumerate, power on and off, promote a template and clone.
Technical steps
- Confirm the token works before you touch the connector:
curl -H "Authorization: PVEAPIToken=ras-svc@pve!ras-connector=<secret>" https://<proxmox-host>:8006/api2/json/version
- Clone the Parallels RAS-PowerShell repository and copy the Proxmox sample into your own repository, so your changes are tracked from the first edit.
- Set the endpoint, token ID, pool, node and storage values as the sample’s README describes. Keep the token secret out of the script and out of version control.
- Run the test kit operation by operation against the lab pool, in this order: enumerate, power on, power off, promote a template, clone.
- Check each result in the Proxmox task log as well as the test kit output, so you know the API call did what the script reported.
Step 5: Add the provider in RAS
Register the custom provider in the RAS console, select the Proxmox template, and create a template in RAS. Build a host pool with your autoscaling rules, then let RAS clone and domain-join session hosts and add them to load balancing.
Technical steps
- Add the custom provider in the RAS console’s Providers section, pointing it at your connector script, and confirm the provider status shows as verified.
- Create the RAS template from the Proxmox template VM. Set the naming pattern, maximum host count, and how many hosts to keep ready.
- In the template’s preparation settings, supply the domain, target OU and a join account with rights limited to that OU.
- Create the host pool, assign the template, and set autoscaling limits: minimum hosts, maximum hosts and the load threshold that triggers a new clone.
- Let RAS create two hosts first. Check that each one clones, gets an IP address through the guest agent, joins the domain and shows the RAS agent as OK before you raise the limits.
Step 6: Operate and update
- Update the golden image, promote a new template version, and roll it out through RAS
- Use Drain Mode for host maintenance
- Keep the connector in version control and retest after Proxmox or RAS upgrades
Technical steps
- Patch the non-templated image VM, Sysprep it, convert it to a new template and promote it as a new version in RAS.
- Roll the new version out to a small pool first, then recreate the remaining hosts in a maintenance window.
- Put hosts into Drain Mode before recreating them so active sessions finish on their own.
- After any Proxmox or RAS upgrade, rerun the test kit in the lab before you upgrade production. Proxmox has changed privilege names between major releases, so recheck the connector role too.
- Rotate the API token on a schedule and update the connector configuration at the same time.
Support model
The CPF uses a shared-responsibility model. Parallels supports RAS and the framework itself; the connector script and the platform automation it performs are the responsibility of whoever deploys it. Treat the sample as a starting point, test it thoroughly in a lab, and document your configuration.
Why Proxmox and RAS work well together
- Lower hypervisor cost for organizations leaving VMware
- Full RAS automation for templates, cloning and autoscaling
- Open, API-driven platform that fits infrastructure-as-code practices
- A consistent RAS experience for users, whatever runs underneath
How XenTegra helps
XenTegra designs and deploys Parallels RAS across Hyper-V, VMware, Nutanix, Azure, AWS and now Proxmox. We can plan your hypervisor move, build the Proxmox provider configuration and run the migration of your existing RAS workloads.
Moving RAS to Proxmox? Book a Proxmox migration assessment with XenTegra Canada.
