What a VM Template Is and Why Cloud-Init Matters
A template in Proxmox VE is a ready-made virtual machine blueprint that lets you quickly clone new VMs without reinstalling the operating system. Cloud-init is a standard for configuring cloud images at first boot: it sets the hostname, network, user, and SSH key before the system fully starts up.
Together, a template and cloud-init turn deploying a server into a one-minute operation: clone the template, pass in the network and key parameters, start the VM — it configures itself on first boot. This is especially useful when mass-creating virtual machines with the same base configuration.
How to Prepare a Cloud Image for the Template
A template uses not a regular ISO but a ready cloud image of the distribution in qcow2 format — it already contains the cloud-init agent and does not require manual installation through an installer.
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img
qm create 9000 --name ubuntu-24-04-template --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0The number 9000 is arbitrary: it is convenient to reserve the range 9000-9999 for template IDs so they are not confused with production VMs. It is worth giving the name a clear meaning right away, for example including the distribution version.
How to Turn a VM Into a Template in Proxmox VE
After creating the VM, the downloaded disk is imported into it and a separate cloud-init device is attached, which stores the first-boot parameters.
qm importdisk 9000 noble-server-cloudimg-amd64.img local-zfs
qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-9000-disk-0
qm set 9000 --ide2 local-zfs:cloudinit
qm set 9000 --boot c --bootdisk scsi0
qm set 9000 --serial0 socket --vga serial0
qm template 9000The last command, qm template 9000, turns a regular VM into a template: the disk switches to read-only mode, and the VM itself disappears from the list of machines that can be started — from now on it serves as the source for clones.
Cloud-Init Settings: User, SSH Key, Network
First-boot parameters are set on the VM card's Cloud-Init tab or through the CLI, before the VM is turned into a template.
| Parameter | Purpose |
|---|---|
| User | the account name that will be created on the system |
| SSH public key | the public key for passwordless login |
| IP Config | a static IP or DHCP for the network interface |
| DNS domain/servers | the search domain and DNS server addresses |
If the user and key are set at the template level, every clone gets the same starting data, while the specific IP address is more convenient to override after cloning — for that particular server.
Cloning a VM From a Template: Linked and Full Clones
A template can produce two types of clones: a linked clone and a full clone. A linked clone stores only the difference from the template's disk and is created almost instantly, but it depends on the source template and needs storage that supports this mode. A full clone copies the entire disk and no longer depends on the template after creation.
qm clone 9000 201 --name web-01 --fullMore about the difference between snapshots and clones, and when a linked clone is riskier than a full one, is covered in the article on VM snapshots and cloning.
Automating Mass Deployment via the API
It is convenient to script cloning and cloud-init setup when servers are deployed regularly: the IP, name, and key parameters can be passed in right after cloning with one command.
qm clone 9000 202 --name web-02 --full
qm set 202 --ipconfig0 ip=10.0.0.22/24,gw=10.0.0.1
qm set 202 --sshkeys ~/.ssh/deploy_key.pub
qm start 202The same result is achieved through the REST API without a node console — this is convenient for CI/CD and external orchestration systems. Details on calls and token-based authorization are covered in the article on the Proxmox VE REST API and automation.
Checklist Before Using a Template in Production
- The image is based on an official cloud distribution with cloud-init support.
- Template IDs are set apart in their own range and do not overlap with production VMs.
- The SSH key in the template points to an account that outsiders cannot access.
- The clone type is chosen deliberately: linked for speed, full for independence from the template.
- The cloning and network setup process is tested on a staging server before a mass rollout.
Once verified, the template can safely be used for repeatable deployment of servers with the same configuration, without manually installing the OS on every machine.
Frequently asked questions
Which clone type is better for a production server — linked or full?
A linked clone is created almost instantly and stores only the difference from the template's disk, but it depends on that template forever, which suits test and temporary machines. A full clone copies the whole disk and is no longer tied to the template once created, making it more reliable for servers meant to run independently long term.
What happens if you set a specific IP address right at the template level?
If you set a static IP in the template, every clone made from it will try to use the same address at startup, causing a network conflict. That is why network settings are better overridden after cloning, for each new server, while the template level only holds data shared by all clones, such as the user account and SSH key.
Will a regular installation ISO work instead of a cloud image for building a template?
It would not make sense: a plain installation ISO has no cloud-init agent and needs a full manual OS install through an installer. The whole point of the template approach is a ready cloud image that already knows how to configure itself on first boot, so that is what fast mass deployment relies on, not a classic installation disc.
Why are templates usually given a separate ID range instead of being numbered alongside production VMs?
A separate ID range removes confusion between templates and production servers: without it, you can easily start, change, or delete the template by mistake, thinking it is a regular virtual machine. When template numbers are set apart, an administrator sees what they are dealing with right away, and the risk of touching the clone source by accident drops noticeably.