Full Clone vs Linked Clone on Proxmox: Which Should You Use?

Right-click a Proxmox VM template, choose Clone, and you are quietly asked to make a decision that has real consequences down the road: Full Clone or Linked Clone? Plenty of people pick one at random, and most of the time it seems fine — until the day they try to delete a template and Proxmox refuses, or they migrate a VM to another node and half their storage vanishes. The two clone types trade off in exactly opposite directions. A full clone is heavy, independent, and free of strings. A linked clone is instant, tiny, and permanently tethered to the template it came from. Neither is a trap if you understand it; both are a trap if you do not. This guide explains precisely how each works on Proxmox, which storage backends support linked clones, the dependency that trips everyone up, and how to choose confidently every time that dialog appears.

Key Takeaways

• Full clone = independent copy — all disks are duplicated; the new VM shares nothing and can be moved, migrated, or deleted with no strings attached.
• Linked clone = shared base + deltas — only changes are stored; unchanged blocks are read from the template, so it deploys in seconds and uses minimal space.
• Linked clones depend on the template — you cannot delete a template that still has linked clones, and the dependency limits where the clone can move.
• Storage backend matters — linked clones require snapshot-capable storage (ZFS, LVM-thin, qcow2, Ceph RBD); raw disks on plain LVM or directory storage force a full clone.
• Match the clone to the lifecycle — linked clones for many short-lived, identical VMs; full clones for anything long-lived, portable, or that must outlive its template.

What Each Clone Type Actually Does

A full clone is the straightforward one. When Proxmox makes a full clone, it copies every block of the source VM's disks into brand-new disk images for the new VM. The result is a completely independent machine that has no ongoing relationship with the original. It occupies as much space as the source's used disk, and creating it takes as long as copying that data does. In exchange, it owes nothing to anyone: you can migrate it, move its disks between pools, back it up, and delete the original without the clone caring in the slightest.

A linked clone is cleverer and more constrained. Instead of copying the base disk, Proxmox creates the new VM with a disk that stores only the differences from the template. Every block the clone has not modified is read from the template's underlying disk; every block it writes goes into its own thin delta layer. This is why a linked clone appears almost instantly and initially consumes only kilobytes — it is not a copy, it is a copy-on-write overlay on top of the template. The catch is right there in the mechanism: the clone cannot function without the template's base disk underneath it. That single fact drives every one of the tradeoffs below. Templates themselves, and the workflow around them, are covered in Proxmox VM Templates: Clone and Deploy VMs in Seconds.

Storage: Which Backends Support Linked Clones

You do not always get to choose a linked clone — the storage backend decides whether it is even possible. Linked clones require storage that supports snapshots and copy-on-write, because that is the machinery a delta layer is built on. On Proxmox that means:

• ZFS — full support; the delta is a ZFS clone of a snapshot. Excellent for both clone types.
• LVM-thin — supported; thin provisioning provides the copy-on-write layer. This is the standard local option when you are not using ZFS, as detailed in LVM-Thin Pools on Proxmox for VM Snapshots Without ZFS.
• qcow2 on directory or NFS storage — supported; qcow2's backing-file feature is exactly a linked clone.
• Ceph RBD — supported; RBD layering provides the shared base.

What does not support linked clones is raw-format storage on plain LVM or plain directory storage. There is no snapshot layer to hang a delta on, so Proxmox greys out or refuses the linked-clone option and you must make a full clone. If you build on ZFS from the start — see Setting Up ZFS on Proxmox: Pools, Datasets, and Best Practices — both clone types are always available, which is one more reason ZFS is such a popular default.

The Dependency That Trips Everyone Up

Here is the single most common surprise, and it is worth stating bluntly: you cannot delete a template that still has linked clones. Because each linked clone reads its unchanged blocks from the template's base disk, removing the template would pull the floor out from under every clone depending on it. Proxmox protects you from this — it will block the deletion — but people still get caught out when they try to "clean up" an old template and cannot understand why it will not go away.

The dependency has two more practical consequences. First, migration: a linked clone is bound to the same storage as its base image, which restricts moving it between nodes unless that storage is shared (like Ceph) or you convert the clone first. Second, storage moves: you cannot simply move a linked clone's disk to a different pool the way you can with a full clone — the link would break. If you need that freedom later, the escape hatch is to convert a linked clone into a full clone, which materializes all the shared blocks into the clone's own disk and severs the dependency. Once converted, it behaves like any other full clone and can be moved with Proxmox VM Storage Migration: Move Disks Between Pools.

Cloning From the Command Line

The GUI's Clone dialog maps directly to the qm clone command, and seeing the flags makes the difference concrete. Assume template VM 9000 and a new VM 120.

# Linked clone (default when supported): instant, minimal space,
# tied to the template's base disk
qm clone 9000 120 --name web-linked

# Full clone: independent copy, add --full
qm clone 9000 120 --name web-full --full

# Full clone onto a specific target storage pool
qm clone 9000 120 --name web-full --full --storage local-zfs

The key flag is --full. Without it, qm clone produces a linked clone wherever the storage allows one (and silently falls back to a full clone on storage that cannot do linked clones). With --full, you always get an independent copy. To turn an existing linked clone into a full one after the fact, use the "Full Clone" action in the GUI or move its disk — both materialize the shared blocks. Note that you can only linked-clone from a VM that has been converted to a template; cloning a running, non-template VM always produces a full clone.

Performance and Space: The Real Tradeoff

The appeal of linked clones is density. Deploy fifty identical test VMs from one template as linked clones and you store the base image once plus fifty small delta layers — a fraction of the space fifty full clones would consume, created in seconds rather than minutes. For CI runners, throwaway lab machines, and any fleet of short-lived, near-identical VMs, that is a decisive advantage.

The cost is a modest, situational read penalty. Because unchanged blocks come from the shared base image, many linked clones reading the same base concentrate I/O on one underlying disk, and there is a small indirection cost to reading through the copy-on-write layer. On fast local NVMe with a well-tuned ARC this is usually imperceptible; on slower or heavily contended storage it can show up under load. Full clones have no such penalty because every block is local to the VM — which is part of why long-lived production VMs, where independence and predictable performance matter more than deploy speed, are usually full clones.

There is also a subtler space dynamic: over a linked clone's life, as it modifies more and more blocks, its delta grows and the space advantage shrinks. A linked clone that eventually rewrites most of its disk ends up nearly as large as a full clone would have been — without ever gaining the independence. That is the strongest argument for matching the clone type to the VM's expected lifespan rather than defaulting to whichever is faster to create.

When to Pick Each One

Use a linked clone when:

• You are spinning up many identical, short-lived VMs — test environments, CI runners, lab machines, or Proxmox Cloud-Init Templates: Automated VM Deployment fleets.
• Storage space and deploy speed matter more than portability.
• The template will stay in place and the clones will not need to migrate freely.

Use a full clone when:

• The VM is long-lived, production, or otherwise important.
• You need to migrate it between nodes, move its disk between pools, or back it up as a fully independent unit.
• You want to delete or replace the source template without disturbing the VM.
• Predictable, isolated disk performance matters under sustained load.

The mental shortcut: linked for disposable, full for durable. If you are not sure how long a VM will live, err toward a full clone — the space you save with a linked clone is rarely worth the dependency headaches on a machine that ends up sticking around.

Conclusion

Full clones and linked clones are not better or worse than each other — they are optimized for opposite lifecycles. A linked clone is the right tool when you want dozens of identical VMs to appear instantly and cost almost nothing, and you are happy to keep the template around forever. A full clone is the right tool when the VM needs to stand on its own — to migrate, to move storage, to outlive its template, and to deliver steady performance. The mistake to avoid is defaulting to linked clones for machines that turn out to be permanent, then fighting the template dependency later. Match the clone to the job: linked for disposable fleets, full for anything durable, and convert a linked clone to full the moment its role changes. To get the templates those clones spring from right in the first place, start with Proxmox VM Templates: Clone and Deploy VMs in Seconds.