Hostname cloud-init

Collbrothers

New Member
Mar 6, 2026
5
0
1
Hi!

I've recently started playing around with cloud-init, and I've gotten so far as to having a complete template that has my ssh keys preconfigured & rsyslog to my central logging server. But I can't seem to find a way to change the host name of the VM created by cloning the template in the web UI.

My user data snippet (/var/lib/vz/snippets/debian-base.yaml):

YAML:
#cloud-config

timezone: Europe/Stockholm

locale: en_GB.UTF-8


users:

  - name: test

    groups: sudo

    shell: /bin/bash

    sudo: ALL=(ALL) NOPASSWD:ALL

... and more

When I dump the user data of the template however:
YAML:
#cloud-config
hostname: debian-template
manage_etc_hosts: true
fqdn: debian-template
user: test
chpasswd:
  expire: False
users:
  - default
package_upgrade: true

And then the config of the template:
Code:
agent: enabled=1
boot: c
bootdisk: scsi0
cicustom: user=local:snippets/debian-base.yaml
ciuser: test
cores: 2
cpu: host
ide2: local-lvm:vm-1000-cloudinit,media=cdrom
ipconfig0: ip=dhcp
memory: 2048
meta: creation-qemu=10.1.2,ctime=1772781924
name: debian-template
net0: virtio=BC:24:11:01:0C:B9,bridge=vmbr0
ostype: l26
scsi0: local-lvm:base-1000-disk-0,size=3G
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=c780d650-e16a-4c85-9b80-f603ebd14133
template: 1
vga: serial0
vmgenid: c9cd4d96-439d-4d93-ad61-d428ee5c96a1


This results in the hostname being "localhost". I would hope that there would be some sort of hostname field in the cloud-init page of the cloned VM?

Any help is appreciated :)
 
Additionally you can check /var/log/cloud-init.log on your VM to see if the cloud-init run even tried to set the hostname.

On my ubuntu machines, the log line looks like this:

Code:
cc_update_hostname.py[DEBUG]: Updating hostname to debian-template.example.org (debian-template)
 
Additionally you can check /var/log/cloud-init.log on your VM to see if the cloud-init run even tried to set the hostname.

On my ubuntu machines, the log line looks like this:

Code:
cc_update_hostname.py[DEBUG]: Updating hostname to debian-template.example.org (debian-template)
I did as gfngfn256 said, and verified by dumping the user data. It did not change the outcome however.

My cloud-init.log (grepped by hostname):
Code:
2026-03-06 10:03:01,248 - modules.py[DEBUG]: Running module set_hostname (<module 'cloudinit.config.cc_set_hostname' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_set_hostname.py'>) with frequency once-per-instance
2026-03-06 10:03:01,248 - handlers.py[DEBUG]: start: init-network/config-set_hostname: running config-set_hostname with frequency once-per-instance
2026-03-06 10:03:01,248 - util.py[DEBUG]: Writing to /var/lib/cloud/instances/999becead9e9de0d9d541573353b5c004da8b86e/sem/config_set_hostname - wb: [644] 24 bytes
2026-03-06 10:03:01,249 - helpers.py[DEBUG]: Running config-set_hostname using lock (<FileLock using file '/var/lib/cloud/instances/999becead9e9de0d9d541573353b5c004da8b86e/sem/config_set_hostname'>)
2026-03-06 10:03:01,250 - cc_set_hostname.py[DEBUG]: Hostname is localhost. Let other services handle this.
2026-03-06 10:03:01,250 - handlers.py[DEBUG]: finish: init-network/config-set_hostname: SUCCESS: config-set_hostname ran successfully and took 0.002 seconds
2026-03-06 10:03:01,250 - modules.py[DEBUG]: Running module update_hostname (<module 'cloudinit.config.cc_update_hostname' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_update_hostname.py'>) with frequency always
2026-03-06 10:03:01,250 - handlers.py[DEBUG]: start: init-network/config-update_hostname: running config-update_hostname with frequency always
2026-03-06 10:03:01,251 - helpers.py[DEBUG]: Running config-update_hostname using lock (<cloudinit.helpers.DummyLock object at 0x7effaa74d590>)
2026-03-06 10:03:01,251 - cc_update_hostname.py[DEBUG]: Hostname is localhost. Let other services handle this.
2026-03-06 10:03:01,251 - handlers.py[DEBUG]: finish: init-network/config-update_hostname: SUCCESS: config-update_hostname ran successfully and took 0.001 seconds
 
Hi @Collbrothers , welcome to the forum.
When I dump the user data of the template however:
The dump command _always_ shows only the output that refers to _internal_ cloudInit configuration in PVE. It does not read/interpret your snippets.
Once you use custom snippet the internal data is no longer used - the two files are not mashed together.

In our test we use custom metadata that is generated for each VM to set hostname to satisfy vendor provided CI images need for instance-id:
meta_data.cirros.proxmox
{
"instance-id": "INSTANCEID",
"local-hostname": "HOSTNAME"
}


Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox
 
Okay that's unfortunate. You mentioned that you generate custom metadata for each clone, is that some proprietary software you use? Right now my head goes to creating a script that takes hostname as an argument, clones template and changes the hostname field in the user data (and meta data) with the given argument...