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=vmbr0
The 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 9000
The 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 --full
More 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 202
The 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.