Every time you spin up a new virtual machine from scratch, you burn ten or fifteen minutes on the same boring steps. Boot the installer, click through the same menus, wait for updates, install the same guest agent, set the same time zone. Do that a dozen times a year and you've lost a couple of hours to work that taught you nothing new.
A VM template fixes this. You build the VM once, lock it, and then clone it whenever you need a fresh machine. What used to take fifteen minutes takes about fifteen seconds.
This guide covers the plain, no-frills version of templating: install a VM the normal way, convert it, and clone it. If you've seen our Cloud-Init guide, you already know there's a more advanced, fully automated version of this workflow built around cloud images. This one is simpler and doesn't require downloading anything special — it's the version most people should learn first.
What You Will Learn
- What a Proxmox VE template actually is, and how it's different from a regular VM
- How to prepare a VM before turning it into a template
- How to convert a VM to a template, from both the GUI and the shell
- The difference between a full clone and a linked clone, and which one to pick
- Common mistakes that leave you with two identical VMs fighting over the same IP address
- How to keep templates updated without breaking existing clones
What Is This Feature?
A template is a VM that's been flagged as read-only. Proxmox VE won't let you start it, and you can't edit its disks directly. What you can do is clone it, as many times as you want, into brand-new VMs that boot and run like any other.
Under the hood, nothing exotic is happening. Proxmox is really just marking the VM's configuration and disks as a template and changing the icon in the UI so you can't accidentally boot it. The disk image itself becomes the base that clones are built from.
This matters because of how cloning works afterward. A full clone copies every byte of the template's disk into a new, completely independent disk. A linked clone instead creates a new disk that only stores the differences from the template — much faster to create, much smaller on disk, but permanently dependent on the template still existing.
| Full Clone | Linked Clone |
|---|---|
| Copies the entire disk — takes longer, uses full disk space | Only stores changes — nearly instant, uses a fraction of the space |
| Independent of the template afterward | Breaks if the template is deleted |
| Works on any storage type | Only works on storage that supports snapshots (ZFS, LVM-thin, Ceph, or qcow2 on directory/NFS storage) |
| Good for production VMs | Good for disposable test VMs and lab environments |
Why Would You Use It?
The obvious reason is speed. But the bigger win, honestly, is consistency. When you clone from a known-good template, you're not re-answering "did I remember to install the guest agent this time?" or "which time zone did I pick last time?" every single VM starts from the exact same, tested baseline.
Homelab users get a lot out of this. Say you're testing something that might trash the OS — a Docker Compose stack, a script you're not sure about, a security tool you're poking at for a course. Clone a throwaway VM, wreck it, delete it, clone another one. No reinstalling anything.
It's also useful if you're running a small classroom or lab environment where several people need identical starting VMs. Build one, template it, clone it per student. Nobody ends up with a machine that's subtly different because of a missed step during manual setup.
Prerequisites
You'll need:
- A working Proxmox VE install (this applies to both the 8.x and 9.x release lines — the template and clone workflow hasn't changed between them)
- Root or an account with the PVEVMAdmin and PVETemplateUser permissions on the relevant resource pool
- One VM already installed with its guest OS, updated, and working the way you want future clones to work
- Enough free space on your target storage for at least one full clone, even if you mostly plan to use linked clones later
- Comfort with the Proxmox web GUI; the shell commands here are optional but useful if you're scripting this
You don't need cloud-init, a cloud image, or any extra packages for this method. That's the whole point.
Step-by-Step Tutorial
Step 1: Clean Up the Source VM
Before you lock a VM in as a template, strip out anything that shouldn't be copied into every future clone. This step gets skipped constantly, and it's the reason people end up with weird SSH warnings or duplicate machine identities later.
For a Linux VM, log in and run:
sudo apt update && sudo apt upgrade -y
sudo rm -f /etc/ssh/ssh_host_*
sudo truncate -s0 /etc/machine-id
history -c
sudo shutdown nowRemoving the SSH host keys forces each clone to generate its own on first boot — without this, every clone shares the same host key, and your SSH client will throw a "host key changed" warning the moment you connect to a second one. Clearing /etc/machine-id does something similar for systemd, which uses that file to identify the machine on the network and for logging.
For a Windows VM, run Sysprep before shutting down:
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdownSysprep strips the machine's security identifier (SID) and resets Windows' first-boot experience, so each clone gets its own identity instead of quietly colliding with every other machine cloned from the same template.
Step 2: Make Sure the VM Is Fully Shut Down
Templates can't be created from a running VM. Check the VM's status in the GUI — it should say stopped, not paused or running. If you used Sysprep, Windows will power itself off as its last step, so just wait for that to finish.
Step 3: Convert the VM to a Template
In the Proxmox web interface, right-click the VM in the left-hand tree and choose Convert to Template. There's no confirmation dialog with a big warning — it just does it — so double-check you picked the right VM first.
From the shell, the equivalent is:
qm template 9000Replace 9000 with your VM's ID. Once this finishes, the VM's icon changes and the Start button disappears. That's expected — templates aren't meant to boot.
This step is one-way. There's no "convert back to VM" button and no CLI equivalent. If you need to make changes to the template's OS later, you clone it, edit the clone, and template that clone instead. More on that in Best Practices below.
Step 4: Clone the Template
Right-click the new template and select Clone. You'll get a small dialog with a few fields worth understanding:
- Target node — which host in your cluster the clone will live on (irrelevant on a single-node setup)
- Mode — Full Clone or Linked Clone
- VM ID — Proxmox suggests the next free ID; feel free to override it
- Name — give it something meaningful, not "Clone of template-1"
If Linked Clone is greyed out, your target storage doesn't support snapshots. This is the single most common surprise here — plain LVM storage (not LVM-thin) can't do linked clones at all, so Full Clone is your only option until you switch to ZFS, LVM-thin, Ceph, or qcow2-on-directory storage.
From the shell:
# Full clone
qm clone 9000 201 --name web-server-01 --full
# Linked clone (storage must support snapshots)
qm clone 9000 202 --name test-vm-01Step 5: Boot the Clone and Fix What Doesn't Auto-Update
Start the new VM and log in. Since you skipped cloud-init, nothing about networking or hostname changes automatically — the clone comes up with the exact hostname and, if you set one, the exact static IP the template had. That's fine for a single clone, but boot two clones from the same template on the same network and you'll get an IP conflict almost immediately.
Fix the hostname:
sudo hostnamectl set-hostname web-server-01And update the network config to a new address if you're not using DHCP. On Debian-based guests that's usually /etc/network/interfaces; on anything using Netplan, it's a YAML file under /etc/netplan/.
If you find yourself doing this every single time, that's the sign you've outgrown plain templates and it's worth reading our Cloud-Init guide — it handles hostname and IP assignment automatically at boot, no manual editing required.
Commands Explained
| Command | What it does |
|---|---|
qm template <vmid> | Converts the specified VM into a read-only template. Irreversible. |
qm clone <vmid> <newid> --name <name> | Creates a linked clone if the storage supports it, otherwise fails with an error telling you to add --full. |
qm clone <vmid> <newid> --name <name> --full | Forces a full, independent copy of the disk regardless of storage type. |
qm list | Lists all VMs and templates on the node, including their current status. |
qm config <vmid> | Prints the full configuration of a VM or template — useful for double-checking what you're about to clone. |
Common Errors
"Convert to Template" is greyed out. The VM is still running or paused. Shut it down completely and the option becomes available again.
Linked Clone option is disabled in the clone dialog. Your target storage doesn't support snapshots. Plain (non-thin) LVM is the usual culprit. Either pick Full Clone or move the template to ZFS, LVM-thin, or a directory/NFS storage using qcow2.
Clone fails with "not enough space". Full clones need the entire disk size available on the destination storage, not just the used portion. A 32 GB thin-provisioned disk that's only 6 GB full still needs 32 GB free if you're doing a full clone to raw or non-thin storage.
Two clones end up with the same IP address. Not a Proxmox bug — this is exactly what happens when you clone a template that had a static IP baked in and skip Step 5. Change the hostname and IP on each clone before putting it on the network.
Troubleshooting
If a clone seems to hang at 0% for a long time, that's usually normal for a full clone of a large disk on slow storage. A 32 GB disk on local SSD storage typically finishes in under a minute; the same clone over NFS or against spinning disks can take several minutes. Give it time before assuming it's stuck — check the task log (the small icon at the bottom of the screen, or Datacenter → Tasks) to confirm progress is actually moving.
If a Windows clone boots into a boot loop or throws activation errors, go back and confirm you actually ran Sysprep before templating. Skipping it is the most common cause of Windows clones behaving strangely — duplicate SIDs can cause everything from domain-join failures to random Windows Update issues down the line.
If SSH suddenly refuses to connect to a clone with a "REMOTE HOST IDENTIFICATION HAS CHANGED" warning, that means the template still had its original SSH host keys when you templated it. There's no fix after the fact except removing the offending key from ~/.ssh/known_hosts on your client and starting over with a properly cleaned template.
If a clone loses its guest agent status (shown as a question mark next to the IP in the Summary tab), give it a minute after boot — the agent takes a moment to start. If it never shows up, check that qemu-guest-agent is actually installed and enabled inside the guest, not just ticked on in the VM's Options tab.
Best Practices
Reserve a VMID range for templates so they're easy to spot in a long VM list — a lot of people use 9000 and up. It's a small thing, but it saves you from accidentally cloning the wrong machine at 11pm.
Templates go stale. An Ubuntu 22.04 template built in January is missing six months of security patches by July. Since you can't edit a template directly, the usual pattern is: full-clone the template, boot it, run updates, shut it down, then convert that clone into your new template (and retire the old one, or keep it around versioned as ubuntu-22.04-template-2026-01 if you want a rollback option).
Use tags on your templates in the GUI (the small labels under the VM name) so anyone else managing the cluster — including future you — knows at a glance what's a base image versus a live workload.
If you're running a cluster, keep templates on shared storage. A template that only exists on one node's local disk can't be cloned from any other node, which defeats a lot of the point in a multi-node setup.
Don't template a VM with cloud-init already configured for a specific host unless you mean to — check the Cloud-Init tab is either blank or set to sensible defaults, otherwise every clone inherits whatever was last configured there.
Frequently Asked Questions
Can I convert a template back into a regular VM?
No. It's a one-way operation. If you need to change the template's OS or software, clone it, make your changes on the clone, and template that clone instead.
Do templates take up extra disk space compared to a normal VM?
No more than the VM already used. A template is just the same disk marked read-only. Space adds up on the clone side — full clones duplicate the whole disk, linked clones only grow as they diverge from the template.
Can I delete a template after I've cloned from it?
Only if every clone made from it is a full clone. Linked clones store just the differences and need the original template's disk to stay put — delete it, and every linked clone breaks.
Do I need a paid subscription to use templates and cloning?
No. Templating and cloning are core Proxmox VE features and work exactly the same on the free, no-subscription repository as they do with a paid subscription.
Can I template an LXC container the same way?
Yes — the container equivalent is pct template <ctid>, and cloning uses pct clone. The concepts are identical, just for containers instead of full VMs.
What's actually different between this and a cloud-init template?
This method clones an exact copy of whatever you installed by hand, hostname and network settings included. A cloud-init template is built from a cloud image instead and re-generates hostname, network config, and SSH keys automatically on every clone's first boot — more setup up front, less manual cleanup afterward.
Conclusion
Once you've got a template built, spinning up a new VM stops being a fifteen-minute chore and turns into something you do without thinking twice. Build it once, clean it up properly, convert it, and let cloning do the rest.
If you're cloning the same kind of VM often enough that manually fixing the hostname and IP every time gets old, that's your cue to move on to cloud-init templates next. But for a one-off lab VM or your first attempt at this workflow, plain templates are the right place to start.