Desktop pools
A desktop pool is a desired-state description of a group of desktops: one template, a capacity range, a naming pattern, and a set of connection and session policies. Planeon continuously clones, customizes, and retires VMs so the pool's actual desktops match what the pool describes — you edit the pool, and the platform converges to it rather than you creating or deleting individual VMs by hand. If you haven't created a pool yet, start with the quickstart.
Pool settings
Open Pools and select Create Pool (or Edit on an existing pool) to see the full settings form. The fields that shape a pool:
| Field | What it controls |
|---|---|
| Pool Name | The pool's display name, unique within its cluster. |
| Pool Type | Persistent — a user keeps the same VM across sessions. Non-Persistent — a fresh VM is handed out and the previous one recycled. Ephemeral — same recycling behavior as Non-Persistent. |
| Template | The registered template the pool clones from. |
| Cluster | The Proxmox VE cluster the pool's VMs live on. |
| Storage | The storage target new clones are placed on. |
| Node Selector | Where clones are placed: Any node (first online node), Specific node (only that node, or placement fails), or Preferred node (that node if online, otherwise any online node). |
| Min Size / Max Size / Warm Pool | The capacity range — see Self-healing and reconciliation below. |
| VM Naming Prefix | The prefix used for each clone's VM name and guest hostname, for example win11-std becomes win11-std-1, win11-std-2, and so on. |
| VMID Range | An optional reserved VMID range for the pool; leave it empty to auto-assign the lowest free VMID. |
| Status | Active — eligible for reconciliation and new session assignment. Maintenance — reconciliation and new session assignment are both paused; existing desktops stay visible and usable. Disabled — reconciliation and new session assignment are both paused (no new provisioning or resize activity). Only an Active pool hands out desktops: a session request against a disabled or maintenance pool is rejected, and a ready VM in such a pool is never claimed. Existing live sessions are unaffected. To stop a specific user from requesting desktops regardless of pool status, remove their entitlements (the Entitlements panel). |
The pool editor also has dedicated sections for Connection methods, RDP options, Browser access (Guacamole), and Session timeouts — see Sessions for what each of those means for your users. A pool can additionally be configured to join its Windows clones to Active Directory and to run guest customization commands after clone; those are advanced, optional settings in the same editor.
VM lifecycle states
Open a pool and select View VMs to see its managed VMs. Each row has two
independent state columns, Lifecycle and Assignment, shown as the raw
state values below (they're the same values you saw move through
planned → cloning → cloned → customizing → ready in the quickstart).
Lifecycle — where the VM is in its build/teardown pipeline:
| State | Meaning |
|---|---|
planned | Planeon has decided to create this VM; the clone job hasn't started yet. |
cloning | The clone job is running: allocating a VMID and cloning from the template. |
cloned | The clone finished; the VM exists in Proxmox VE and is being configured. |
customizing | Waiting for the guest agent, waiting out first-boot setup, setting the hostname, and running the health check. |
ready | The VM passed its health check, counts as warm capacity, and can be handed to a user. |
assigned | Bound to a user's session. |
draining | Being taken out of service. |
deleting | A delete or recreate action is removing the VM from Proxmox VE. |
deleted | The VM record is retired; its VMID has been released for reuse. |
failed | A step in the clone pipeline failed. See Failure handling. |
Assignment — whether a session currently holds the VM:
| State | Meaning |
|---|---|
unassigned | Not bound to a user; eligible to be claimed by the next session request once ready. |
assigned | Bound to a live session. |
reserved | Held back from new assignments (for example, after a Drain action) without being deleted or removed from the pool. |
Self-healing and reconciliation
An Active pool is checked continuously against its capacity settings. The target size is:
required = clamp(Min Size, assigned VMs + Warm Pool, Max Size)
If the pool has fewer VMs than that, Planeon clones more; if it has more
unassigned VMs than Max Size, Planeon retires the extras. Assigned VMs are
never removed by this process. VMs already planned or in progress count
toward the target too, so a slow clone in flight doesn't cause a second,
duplicate clone on the next check.
A failed VM also counts toward the target, because it still physically
occupies its VMID slot: if the platform cloned a replacement for every
failed VM automatically, a systemic problem — a template whose RDP service
never starts, for example — would spawn an unbounded cascade of new failed
VMs every cycle instead of surfacing one clear problem. Recovering a failed
VM is instead a deliberate action you take: Recreate re-clones the same
identity, or Delete removes it and frees its slot for a fresh warm VM.
See Managed VM actions below.
Maintenance and Disabled pools are skipped by this process entirely — useful while you're deliberately working on a pool's settings or template.
Resizing a pool
Editing Min Size, Max Size, or Warm Pool and saving the pool changes its target immediately. The next reconciliation pass converges toward the new target — cloning more VMs if you raised it, or retiring unassigned VMs if you lowered it. Assigned VMs are never touched by a resize; shrinking a pool only ever removes VMs nobody is using.
Deleting a pool
Selecting Delete on a pool removes only the pool's own record from Planeon. It does not power off, delete, or otherwise touch the VMs the pool had cloned — those VMs remain in Proxmox VE, no longer managed by any pool. If you want them gone too, delete them individually from the pool's VM list before deleting the pool — the pool's VM list disappears together with the pool — or find them afterwards on the Virtual Machines page.
Managed VM actions
From a pool's VM list, each managed VM has an actions menu: Start, Stop, Shutdown (graceful), Reboot (graceful), Reset (hard), Drain, Recreate, Delete, and Job history (a per-VM history of the background jobs that targeted it). Every action — including the non-destructive ones — requires an explicit confirmation before it runs, so a stray click can't stop, reset, or delete a VM someone is using.
Recreate and Delete on a VM that's currently assigned require an
extra confirmation ("This VM is currently assigned to a user. I understand
this will disrupt them.") before they proceed, since both actions disrupt
whoever is using that desktop.
Failure handling
A VM whose clone pipeline failed shows failed in its Lifecycle column,
and the job that failed appears on the Jobs page with a Failed
status and a Kind such as Clone VM. From there you can:
- Select Requeue to reset a failed job back to queued with a fresh attempt budget and let it run again. Only jobs in Failed status can be requeued.
- Or act on the VM directly with Recreate (re-clone the same identity) or Delete (release its slot so a fresh warm VM is planned instead) — see Managed VM actions above.
Either path is a deliberate choice you make; a failed VM is never silently retried or replaced on its own, for the reasons in Self-healing and reconciliation above.