You've got a VM running the way you want it. Now you need three more just like it for testing, or you want a safety net before you mess with its config, or you just want a golden image you can stamp out new servers from. Proxmox VE gives you three different tools for this — clones, snapshots, and templates — and they get mixed up constantly because on the surface they all sound like "make a copy of my VM."
They're not interchangeable. Each one solves a different problem, and picking the wrong one wastes disk space at best and costs you your VM at worst. This guide walks through what each feature actually does under the hood, when a real admin would reach for it, and how to use all three without stepping on a rake.
What You Will Learn
- What a snapshot, a clone, and a template each actually do to your VM's disk and config
- Why full clones and linked clones behave completely differently depending on your storage type
- How to take, roll back, and delete snapshots from both the GUI and the command line
- How to convert a VM into a template and clone from it
- The mistakes that trip up almost everyone the first time — grayed-out buttons, storage errors, and snapshots that quietly eat your free space
What Is This Feature?
A snapshot is a point-in-time save state of a VM's disk (and optionally its RAM) that you can roll back to later. It lives on the same storage as the VM itself and depends on that VM's disk existing — delete the VM, and the snapshot goes with it. Think of it as an undo button, not a copy.
A clone is a brand new VM created from an existing one. Proxmox VE gives you two flavors. A full clone copies every byte of the source disk into a new, completely independent disk image. A linked clone instead creates a new disk that only stores the differences from the original — the original's data is referenced, not duplicated, which makes the clone tiny and fast to create.
A template is a VM that's been marked read-only and locked from booting normally. On its own a template doesn't do much — its entire purpose is to act as the base image that clones (especially linked clones) get created from. You build it once, get it exactly right, then stamp out copies whenever you need them.
Here's the part that actually matters day to day: linked clones can only be made from a template. If you try to make a linked clone from a regular running VM, Proxmox won't let you — you'll only get the full clone option. That single rule is why templates and clones are joined at the hip even though they're separate features.
Why Would You Use It?
Snapshots exist for the "oh no, undo that" moment. You're about to run a risky apt upgrade, change a network config, or test a kernel module — take a snapshot first, and if it goes sideways you're back to normal in under a minute. They are not a backup strategy. A snapshot lives on the same disk as the VM, so if that disk dies, your snapshot dies with it.
Full clones exist for when you want a genuinely independent VM. Say you're standing up a second WordPress site that started life as a copy of your first one — you want it fully separate, with its own disk, so you can delete the original later without breaking the copy. Full clones cost you the same disk space as the original, and they take longer to create because Proxmox has to physically copy the data.
Linked clones exist for speed and disk efficiency when you're spinning up short-lived or disposable VMs — think CI test runners, a "let me try this in a clean Ubuntu box" sandbox, or a classroom lab where twenty students each get their own VM from the same base image. Because only the differences get written, a linked clone can be ready in a couple of seconds and use a fraction of the disk space of a full copy.
Templates exist to make linked clones possible and to give you a known-good starting point. Once you've built a template — OS installed, updates applied, QEMU Guest Agent running, SSH keys dropped in — every VM cloned from it starts from that exact same clean state, every time.
Prerequisites
Before you start, you'll want:
- A working Proxmox VE 8.x or 9.x install with at least one existing VM
- Comfortable access to the Proxmox web UI (this guide covers both GUI and CLI steps)
- Storage that actually supports snapshots — not every storage type does, and we'll cover which ones in a table below
- Enough free disk space for at least one full clone, since it duplicates the entire source disk
- SSH or shell access to the Proxmox host if you want to follow along with the
qmcommands instead of clicking through the GUI
One thing worth checking up front: what storage is your VM's disk actually on? Run pvesm status on the host and note the storage type next to your VM's disk. It'll matter for every section below.
Storage Type and What It Supports
| Storage Type | Snapshots | Linked Clones |
|---|---|---|
| ZFS (local) | Yes | Yes |
| LVM-thin | Yes | Yes |
| Ceph RBD | Yes | Yes |
| Directory (qcow2 disks) | Yes | Yes |
| Directory (raw disks) | No | No |
| Plain LVM (not thin) | No | No |
| NFS/CIFS (qcow2 disks) | Yes | Yes |
If your VM's disk is raw on plain LVM or a directory that isn't using qcow2, the snapshot button in the GUI will just be grayed out. That's not a bug — it's the storage backend telling you it can't do it.
Step-by-Step Tutorial
1. Taking a Snapshot
In the GUI, click your VM, go to the Snapshots tab, and click Take Snapshot. Give it a name (no spaces — Proxmox will reject those) and an optional description. If the VM is running and you want to capture RAM state too, check Include RAM. That lets you roll back to a VM that's mid-boot or mid-process, but it also means the snapshot needs disk space equal to the VM's assigned memory, so a VM with 8 GB of RAM eats roughly 8 GB extra just for that one snapshot.
From the CLI, the equivalent is:
qm snapshot 105 before-upgrade --description "Before running apt full-upgrade"Here, 105 is the VMID and before-upgrade is the snapshot name.
2. Rolling Back
Go to the Snapshots tab, select the snapshot, and click Rollback. Proxmox will warn you that current changes will be lost — read that warning, because it means it. Anything you changed after the snapshot was taken is gone, with no redo.
qm rollback 105 before-upgradeYour other snapshots (if you have more than one) stay intact in the list — rolling back doesn't delete them, it just resets the VM's disk and config to match the one you picked.
3. Deleting Old Snapshots
Snapshots aren't meant to live forever. Each one holds onto the disk blocks that changed after it was taken, so a pile of old snapshots slowly eats your free space even if you never look at them again.
qm delsnapshot 105 before-upgradeDeleting a snapshot can take a while on a busy VM, since Proxmox has to merge that snapshot's data back into the disk chain.
4. Converting a VM Into a Template
Build the VM you want as your base image first — install the OS, run updates, install the QEMU Guest Agent, and clean up anything specific to that one install (like SSH host keys or machine IDs, if you care about that level of cleanliness). Shut the VM down completely; you can't template a running VM.
Right-click the VM in the tree and choose Convert to Template. There's no undo dialog here that lets you pick options — it's a one-way action. The VM disappears from the regular VM list and shows up with a template icon instead. You can no longer boot it directly.
qm template 90005. Cloning From a Template (or a Regular VM)
Right-click the source (template or VM) and choose Clone. You'll get a dialog asking for a target VMID, a name, and a clone mode. If your source is a template and the storage supports it, you'll see both Full Clone and Linked Clone as options. If the source is a regular VM, only Full Clone is available.
qm clone 9000 210 --name test-box --full 0That creates VMID 210 as a linked clone named "test-box" from template 9000. Drop the --full 0 (or set it to 1) for a full, independent copy instead.
Commands Explained
| Command | What It Does |
|---|---|
qm snapshot <vmid> <name> | Creates a snapshot of the given VM's current disk state (and RAM, if requested) |
qm listsnapshot <vmid> | Lists every snapshot that exists for a VM, in order |
qm rollback <vmid> <name> | Resets the VM's disk and config back to a specific snapshot |
qm delsnapshot <vmid> <name> | Removes a snapshot and merges its data back into the disk chain |
qm template <vmid> | Converts a stopped VM into a read-only template |
qm clone <vmid> <newid> --full <0/1> | Creates a new VM from a source VM or template; --full 1 forces a full clone |
pvesm status | Shows every configured storage and its type, useful for checking snapshot support before you start |
Common Errors
clone failed: unable to create link clone, target storage does not support it — you tried a linked clone on a storage type from the "No" column in the table above. Either switch the target storage or just do a full clone instead.
TASK ERROR: no such snapshot — usually a typo in the snapshot name, or you're running the command against the wrong VMID. qm listsnapshot <vmid> will show you the exact names to use.
can't lock file - got timeout during a clone or snapshot — another task is already running against that VM, or a stale lock got left behind from an interrupted operation. Wait for any running task to finish before retrying.
200 Volume ... does not support the 'snapshot' feature — same root cause as the linked-clone error above, but shown when you try to take a snapshot directly on unsupported storage.
Cloning fails partway through with a "no space left on device" style error — full clones need the entire source disk's worth of free space on the target storage. Check pvesm status for available space before kicking off a full clone of a large disk.
Troubleshooting
If the Snapshots tab shows no "Take Snapshot" button at all, or it's grayed out, the fastest check is the VM's disk storage. Click the VM, go to Hardware, note which storage the disk lives on, then check that storage's type against the support table earlier in this guide. Nine times out of ten that's the whole answer.
If a linked clone option isn't showing up even though your storage supports it, double check that you're cloning from an actual template and not a regular VM. Proxmox only offers the linked option when the source has been converted with Convert to Template first.
If you deleted a template and it complained that clones still depend on it, that's storage-dependent behavior. On ZFS, qcow2, and Ceph, the template's base disk stays in use as long as any linked clone references it — you can't remove it until every linked clone made from it is either deleted or converted to a full clone. LVM-thin behaves differently: because of how its block reference counting works, linked clones there keep running fine even after the template is deleted.
If a snapshot rollback seems to hang, give it time before assuming it's broken — rolling back a snapshot that included RAM state on a VM with a lot of memory can take a noticeably longer time than a disk-only snapshot, since Proxmox has to restore that memory image too.
Best Practices
Keep snapshots short-lived. They're for "let me try this and undo it if it breaks," not for long-term protection — that's what actual backups (via vzdump or Proxmox Backup Server) are for. A VM with snapshots from six months ago is just quietly wasting disk space.
Build one clean template per OS and update it periodically rather than letting it drift. If your Ubuntu template is still running whatever was current a year ago, every clone from it inherits that same stale baseline and needs updates immediately after boot.
Name snapshots and clones with something you'll actually recognize later — "before-network-change" beats "snap1" every time you're scrolling through the list at 2 a.m. trying to remember which one is safe to roll back to.
If you're cloning a VM that has a running database or anything with open file handles, install the QEMU Guest Agent first and make sure it's active. It lets Proxmox freeze the filesystem for a consistent snapshot instead of grabbing a disk image mid-write.
Honestly, most homelab users overthink the full-versus-linked decision. If disk space isn't tight, full clones are simpler to reason about and don't leave you dependent on a template you might forget exists. Save linked clones for situations where you're spinning up and tearing down VMs often enough that the speed and space savings actually matter.
Frequently Asked Questions
Can I convert a clone back into a template?
Yes. A clone is just a regular VM once it's created, so you can shut it down and run Convert to Template on it exactly like any other VM.
What happens to a linked clone if I delete the template it came from?
Depends on the storage. On LVM-thin, the clone keeps working fine. On ZFS, qcow2, and Ceph, Proxmox blocks the deletion until every linked clone from that template is gone or converted to a full clone.
Can I take a snapshot of a running VM?
Yes, and most people do it that way. You don't need to shut the VM down first, though including RAM in the snapshot does briefly pause the VM while it captures memory state.
Do LXC containers support snapshots and clones the same way?
Mostly yes — containers have their own Snapshots tab and clone dialog that work almost identically, with the same storage-type restrictions applying.
Is a snapshot the same thing as a backup?
No. A snapshot lives on the same disk as the VM, so losing that disk means losing the snapshot too. Treat snapshots as a short-term undo button, not a substitute for real backups stored somewhere else.
Do I need a paid Proxmox subscription to use any of this?
No — snapshots, clones, and templates are all part of the free, no-subscription version of Proxmox VE.
Conclusion
Once you see the actual mechanics, the choice stops being confusing. Need an undo button before you do something risky? Snapshot. Need a completely independent copy of a VM you can hand off or delete the original from later? Full clone. Need to spin up disposable VMs fast from a known-good base? Build a template and make linked clones from it. Pick based on what you actually need afterward — independence, speed, or the ability to undo — and the right tool is usually obvious.