A Proxmox clone snapshot web UI turns the two most nerve-wracking operations in a homelab — copying a guest and rolling one back — into buttons you can press without opening an SSH session. Stashboard V8.0 shipped this for LXC containers, and V8.2 extended the same panel to QEMU virtual machines, so a Proxmox clone snapshot web UI now covers both guest types from the same card. 🧬
This post is about the habit as much as the feature, because a Proxmox clone snapshot web UI is only worth having if you actually use it. Snapshot before you break it. Clone before you experiment. Those two reflexes are the difference between “I’ll fix it tonight” and “I’ll rebuild it this weekend.”
If you’re new to this series, start with managing Proxmox from a web dashboard, then creating an LXC from the web UI and the VM equivalent, creating and editing a Proxmox VM.
Why a Proxmox Clone Snapshot Web UI Beats the Shell
Nothing here is impossible with pct and qm. The problem is that the shell version of this workflow has no friction and no memory.
No friction means you skip it. When taking a snapshot costs a browser tab you already have open and two clicks, you actually do it — that is the entire argument for a Proxmox clone snapshot web UI. When it costs remembering the vmid, SSH-ing to the right node, and getting the argument order right, you tell yourself the upgrade will be fine.
No memory means nobody knows who did what. A Proxmox clone snapshot web UI that writes an audit row every time solves a problem you don’t notice until you’re staring at a guest that isn’t in the state you left it in.
The third reason is honesty about results. Proxmox returns a task UPID for these operations, not a result. A Proxmox clone snapshot web UI that fires the request and shows a green toast is lying to you — the task might still fail thirty seconds later. Stashboard polls the UPID to a terminal state, so what you see is what actually happened, not what was accepted.
Snapshot Before You Break It
This is the whole philosophy in one line. Before you touch anything that could plausibly go sideways, take a snapshot.
Concretely, in my homelab that means:
- Before a distro upgrade inside a container —
do-release-upgradehas opinions about your config files - Before adding a mount point or changing a device passthrough — the guest may simply refuse to start
- Before a big Docker Compose rewrite inside an LXC that hosts a stack
- Before touching anything in
/etcthat you don’t fully understand yet - Before installing a kernel module or a new driver in a VM
The Proxmox clone snapshot web UI makes each of those a two-click reflex instead of a decision. Snapshots are cheap on ZFS and LVM-thin. They are not backups — they live on the same storage and die with it — but as a five-second undo button they’re unbeatable. Pair them with a real backup target: my dedicated Proxmox Backup Server handles “the SSD is gone,” snapshots handle “I broke it myself.”
Inside the Snapshots Tab: List, Take, Roll Back, Delete
Each guest card gets a Snapshots tab. It lists what exists, newest first.
One detail worth knowing: Proxmox includes a synthetic entry called current in its snapshot list. It isn’t a snapshot — it’s a marker for the live state at the top of the tree. It’s filtered out, because listing it invites someone to try rolling back to it.
Four actions live in this part of the Proxmox clone snapshot web UI:
- Take snapshot — a name and an optional description. Write real descriptions. “before-jellyfin-upgrade” beats “snap3” at 11pm three weeks later.
- Roll back — this is the destructive one. ⚠️ A rollback discards everything that happened after the snapshot was taken. Every file written, every database row, every log line. It’s double-confirmed for exactly that reason.
- Delete — removes a snapshot and frees the space it was pinning.
Every one of those four operations returns a UPID that gets polled to completion. A rollback on a large guest is not instant, and the Proxmox clone snapshot web UI stays honest about that instead of pretending it finished.
VM Only: Saving Live RAM with vmstate
Here’s where LXC and QEMU genuinely diverge.
An LXC snapshot is a filesystem snapshot. That’s it. There is no memory to capture, because a container shares the host kernel and has no separate machine state.
A QEMU VM can do more. Proxmox can dump the guest’s RAM into the snapshot alongside the disk, so rolling back returns the VM to a running state — same processes, same open sockets, same half-typed command in a terminal. It’s a suspend-to-disk you can return to repeatedly.
In the Proxmox clone snapshot web UI that’s an “Include running memory state (RAM)” toggle, and it only appears for a VM that is currently running. Flip it on and the request carries vmstate=1. The LXC path never sends that parameter at all — there’s nothing for it to mean.
Two things to keep in mind. First, it costs disk: the snapshot grows by roughly the VM’s allocated memory. A 16 GB VM writes a 16 GB vmstate file. Second, it takes noticeably longer to create and to roll back, because that memory has to be written out and read back in.
This toggle is the one place where the Proxmox clone snapshot web UI behaves differently for VMs than for containers. Use it when the VM’s state is the interesting part — mid-debug, mid-migration, mid-anything you don’t want to redo. Skip it for a routine “before I upgrade packages” snapshot on a stopped or idle VM.
Cloning a Guest From the Proxmox Clone Snapshot Web UI
In the Proxmox clone snapshot web UI, the Clone button sits on the guest’s Lifecycle row, next to start/stop/restart. It opens a modal with:
- New VMID — pre-filled from Proxmox’s own
/cluster/nextid, so the default is already free. You can override it; if you pick something out of range or already taken, you get a clean 409 rather than a confusing Proxmox error. - Hostname (containers) or Name (VMs) — what the copy will be called.
- Target storage — optional. Leave it empty to inherit the source’s storage, or point the clone somewhere else. Handy if you’ve just added an LVM-thin pool and want new guests landing there.
- Full or linked clone — covered properly in the next section.
- Source snapshot — optional, and only offered when the source actually has snapshots. Clone from a known-good point in time instead of from now.
- Disk format — VM full clones only:
raw,qcow2, orvmdk.
Submit and the Proxmox clone snapshot web UI calls the .../clone endpoint, gets a UPID, and polls it. When the task reaches a successful terminal state the host is re-scanned, so the new guest’s card appears in the list immediately — no manual refresh, no wondering whether it worked.
Linked Clone vs Full Clone, Honestly
This is the one choice the Proxmox clone snapshot web UI can’t make for you, so let’s be blunt about the trade.
A full clone copies every block. It takes time proportional to the disk size and consumes that much storage. When it finishes, the copy is completely independent — you can delete the original, move the clone to different storage, back it up separately, and nothing ties the two together.
A linked clone copies almost nothing. It creates a guest that references the source’s disk and only stores blocks that differ. It’s near-instant and costs almost no space up front. That’s genuinely useful: spinning up five test containers from one golden template in seconds is a real superpower.
The catch is the chain. A linked clone depends on its parent forever. You cannot delete the source guest while a linked clone exists. You cannot freely move the clone to other storage. Snapshot behaviour on the parent gets more constrained. And linked clones require a storage backend that supports it — on plain directory storage the option may simply not be available. The Proxmox VE storage documentation lists which backends support what.
My rule: linked for throwaway test guests I’ll destroy this week, full for anything that will still exist next month. Fast and thin is great right up to the moment you want to retire the template and discover four guests are chained to it.
Why Proxmox Refuses to Clone a Running Guest
You’ll hit this early, so it’s worth understanding rather than fighting.
Proxmox will not clone a running guest from its live state. Copying a filesystem that’s actively being written produces a corrupt, torn copy — half-written database files, inconsistent journals. Proxmox refuses instead of handing you a broken guest.
There are exactly two valid paths, and the Proxmox clone snapshot web UI enforces both:
- Stop the guest, then clone. Clean and simple for anything you can afford a minute of downtime on.
- Clone from a snapshot. The snapshot is a frozen, consistent point in time, so the source can stay running while the clone is made from that frozen state.
Path two is the good one, and it’s another argument for the snapshot habit: a guest with recent snapshots is a guest you can clone without downtime.
Gating and Audit: Off by Default, Logged Forever
Cloning and rolling back are powerful enough that they don’t get enabled quietly.
Two switches, both off by default, both required:
Stashboard:AllowProxmoxClone— the master switch, under Settings → Clone/snapshot.- Per-host
AllowClone— an explicit opt-in on each Proxmox host.
If either is off, the request is rejected with a deterministic 403 before any call reaches Proxmox. Nothing is attempted, nothing is half-done, and the failure is instant instead of a timeout. Same defence-in-depth thinking as the LXC config editor: destructive capability is opt-in twice or not at all.
Everything that does get through the Proxmox clone snapshot web UI is recorded. Every clone, snapshot, rollback and delete writes a ProxmoxCloneAudits row, surfaced on a per-guest Audit tab. Who, what, when, against which guest. And when Proxmox itself rejects something, the host’s message is surfaced verbatim as a 502 — you get the real reason, not a sanitised “operation failed.”
Three things are deliberately out of scope: cross-node clone migration, scheduled snapshots, and nested snapshot trees. Those are Proxmox-console territory for now.
Give the Proxmox clone snapshot web UI a week of real use and the habit sticks. Snapshot before you break it, clone before you experiment, and stop treating “I’ll just be careful” as a rollback strategy. 🛟