Introduction

Setting up a VM from scratch every time gets old fast. Install the OS, apply updates, install your agents, tweak the network settings — and then you do it all again for the next one. Cloning skips most of that.

Proxmox VE can copy an existing VM in a couple of clicks, disks and configuration included. Once you've built one "golden" VM the way you like it, spinning up ten more takes minutes instead of an afternoon.

This guide covers both ways to clone in Proxmox VE 9.x: a quick clone of any existing VM, and the more deliberate template-based workflow that most people settle on once they're cloning regularly.

What You Will Learn

  • The difference between a full clone and a linked clone
  • How to clone a VM directly from the GUI
  • How to turn a VM into a reusable template
  • How to clone from the command line with qm clone
  • What breaks if you clone a running VM without preparing it first
  • How to fix the errors you're most likely to run into

What Is This Feature?

Cloning in Proxmox creates a new VM by copying an existing one's disks and configuration. There are two flavors, and picking the wrong one for your situation is the single most common mistake beginners make here.

A full clone copies every byte of the source VM's disks into brand new files. The result is completely independent — you can delete the original VM and the clone keeps working fine. It takes longer to create and uses just as much disk space as the source.

A linked clone doesn't copy the disk data at all. Instead it creates a new, tiny disk that only stores the differences from the original. This is fast and saves a lot of space, but the clone can't function without the original still existing — delete the source and every linked clone built from it breaks.

Linked clones require a template as their source, not just any regular VM. A template is a VM that's been converted into a locked, read-only base image specifically meant to be cloned from — it can no longer boot on its own.

Why Would You Use It?

The obvious reason is speed. Building a base Debian or Ubuntu VM with your usual packages, then cloning it for every new project, turns a fifteen-minute install into something that finishes before your coffee's ready.

Full clones make sense when you want total independence — testing something destructive on a copy of a production VM, for instance, where you don't want any shared dependency back to the original. Linked clones make sense when you're spinning up a lot of short-lived, similar VMs and don't want to burn disk space storing the same base OS forty times over.

Honestly, most homelab users start with full clones because they're simpler to reason about, then move to templates and linked clones once they notice their storage filling up with near-identical VMs.

A concrete example: say you run three small web app VMs, all Debian 12 with the same base packages. Build one properly, template it, and each new app becomes a two-minute linked clone plus whatever's specific to that app — instead of another twenty-minute OS install you'll inevitably configure slightly differently by accident.

Prerequisites

  • Proxmox VE 8.x or 9.x with at least one existing VM to clone
  • Enough free disk space — assume you'll need the full size of the source VM's disks for a full clone
  • For linked clones: storage that supports snapshots, such as ZFS, LVM-thin, or Ceph/RBD (plain LVM and iSCSI don't support linked clones)
  • VM.Clone permission on the source VM if you're not using the root account

Step-by-Step Tutorial

Step 1: Clone a VM directly (no template needed)

This is the fastest path if you just need one copy of an existing VM and don't care about disk space.

  1. Right-click the VM in the left-hand tree and choose Clone.
  2. Pick a target Node — you can clone across nodes in a cluster, not just within the same host.
  3. Give the clone a new Name and, if you want, a specific VM ID. Otherwise Proxmox picks the next free one.
  4. Set Mode to Full Clone.
  5. Click Clone and watch the task log — a full clone of a 32 GB disk on decent local SSD storage usually finishes in one to three minutes.

The clone comes with the same network configuration as the source, including the same MAC address behavior — Proxmox generates a new MAC for the clone automatically, so you won't get IP conflicts from that.

Step 2: Turn a VM into a template

Before converting a VM to a template, clean it up. This step gets skipped constantly and it's the reason people end up with fifteen VMs that all have the same SSH host key.

  1. Inside the guest, remove anything unique: SSH host keys (rm /etc/ssh/ssh_host_* on Debian/Ubuntu, then regenerate on first boot with cloud-init or a script), stored passwords, and machine-specific config.
  2. Shut the VM down completely — templates can't be created from a running VM.
  3. Right-click the VM in the GUI and select Convert to template.
  4. Confirm. The VM's icon changes, and it can no longer be started directly — only cloned from.

This step cannot be undone through the GUI. If you need the original VM back as a bootable machine, clone the template (full clone) and work from the copy instead.

Step 3: Clone from a template

  1. Right-click the template and choose Clone.
  2. Set the name and target node as before.
  3. Choose Mode: Full Clone for an independent copy, or Linked Clone to save space.
  4. Click Clone. Linked clones typically finish in a few seconds since there's no disk data to copy.

If Linked Clone is greyed out, your storage doesn't support it — check that you're using ZFS, LVM-thin, or Ceph, not plain LVM or a basic directory storage.

Step 4: Clone from the command line

Useful for scripting repeated deployments. The basic syntax:

qm clone 9000 105 --name web-server-03 --full true

Here 9000 is the source VM or template ID, and 105 is the new VM's ID. Drop --full true (or set it to false) if you want a linked clone instead — remember the source has to be a template for that to work.

Step 5: Add cloud-init so clones configure themselves (optional but worth it)

Cloud-init is a small program that runs on first boot and applies settings like hostname, IP address, and SSH keys that Proxmox passes in from outside the VM — no manual login required. Pair it with a template and every clone comes up with its own identity automatically, instead of copies of whatever was baked into the source.

  1. On the source VM, install cloud-init inside the guest (most cloud OS images already include it).
  2. In the Proxmox GUI, add a CloudInit Drive under the VM's Hardware tab.
  3. Convert the VM to a template as usual.
  4. When you clone it, open the new VM's Cloud-Init tab and set a hostname, IP configuration, and SSH key before first boot.

This is the difference between forty clones that all fight over the same hostname and forty clones that just work the moment they power on.

Commands Explained

  • qm clone <source-vmid> <new-vmid> — creates a new VM by cloning the source; both IDs are required positional arguments.
  • --name — sets a human-readable name for the new VM, shown in the GUI tree.
  • --full true — forces a full, independent copy of all disks. Omit or set to false for a linked clone from a template.
  • --storage — optionally sends the clone's disks to a different storage than the source used.
  • qm template <vmid> — the CLI equivalent of right-clicking a VM and choosing Convert to template.

Common Errors

"clone failed: unable to create VM ... - VM already exists" — the target VM ID you picked (or that Proxmox auto-assigned) is already in use. Pick a different ID or let Proxmox choose one for you by leaving the field blank.

"Linked clones are not supported for storage type 'lvm'" — you're trying to linked-clone onto plain LVM or iSCSI storage. Move the template's disk to ZFS, LVM-thin, or Ceph, or just use a full clone instead.

"clone failed: cfs-lock 'storage-...' error" — another operation (often another clone or a backup) is holding a lock on the storage. Wait for it to finish and retry.

Two VMs showing the same IP address after cloning — this isn't a Proxmox bug, it's leftover static network config inside the guest. Cloud-init or a fresh DHCP lease fixes this; a manually configured static IP inside the guest OS will not change on its own.

Troubleshooting

If a clone gets stuck at a specific percentage in the task log for a long time, check disk I/O on the source and target storage before assuming Proxmox has hung — a full clone between two spinning disks is genuinely slow, and 20 minutes for a 200 GB VM isn't unusual.

If Convert to template is greyed out, make sure the VM is fully stopped, not just paused or suspended. A running or suspended VM can't be templated.

If a linked clone's disk shows as unexpectedly large, double check you didn't accidentally full-clone instead — the Mode dropdown resets to Full Clone by default in some Proxmox versions, so it's worth glancing at it every time.

Best Practices

  • Keep one clean, minimal template per OS you use regularly, and rebuild it every few months to pick up security updates rather than patching a years-old template forever.
  • Strip SSH host keys and machine-id before templating, or use cloud-init so each clone regenerates its own identity on first boot.
  • Use linked clones for throwaway test environments, and full clones for anything you plan to keep running long-term or migrate to another node later.
  • Name clones consistently — something like app-prod-01, app-prod-02 — so a list of forty VMs doesn't turn into a guessing game six months from now.

Frequently Asked Questions

Can I clone a running VM?

Yes, Proxmox handles this fine for both full and linked clones, though a full clone of a busy VM under heavy disk I/O will take longer and may briefly affect that VM's performance.

What happens if I delete a template that has linked clones?

Proxmox will refuse to delete it. You'd need to full-clone (promote) every linked clone first, or delete the clones themselves.

Do clones keep the same MAC address as the source?

No, Proxmox generates a new MAC address for the cloned network interface automatically, so you won't get network conflicts from that alone.

Can I convert a template back into a regular, bootable VM?

Not directly through the GUI. Clone it (full clone) and use the resulting copy as your working VM instead.

Is a linked clone slower to run than a full clone?

Marginally, since disk reads for unchanged data pass through to the base template. In practice most people never notice the difference for typical workloads.

Do I need to shut down the source VM before cloning it?

No — only for converting it to a template. A regular clone (full or linked) can run against a live VM, though Proxmox does briefly pause disk I/O to keep the copy consistent.

Can I clone a VM to a completely different node in my cluster?

Yes, as long as the target node has access to compatible storage. Pick the destination node in the Clone dialog's Target node field — it doesn't have to match the source.

Conclusion

Cloning turns "build a VM" into "copy a VM," which is a much better way to spend your afternoon. Start simple with a direct full clone the first time, then build a proper template once you notice you're repeating the same base setup over and over.

The cleanup step before templating is the part worth doing right — a template full of leftover SSH keys and static IPs causes more headaches down the line than it saves you now.