Question
Proxmox VM Templates: Guest Agent state synchronization during cloning
Dev Echo
0 reputation · 29 Nov 2024, 14:37 UTC
130.1K views
Loading…
0 reputation · 29 Nov 2024, 14:37 UTC
Proxmox Virtual Environment (PVE) allows for the creation of read-only gold images via the Template feature. When combined with Cloud-Init, these templates facilitate the deployment of repeatable development environments through linked or full clones.
A design consideration arises when determining the optimal state of the template prior to conversion. There is uncertainty regarding how the QEMU Guest Agent state behaves when a VM is converted to a template while completely shut down versus when it is captured from a specific snapshot state.
Specifically, it is unclear if the guest agent's internal state or cached metadata persists in a way that affects the initial boot and synchronization of the cloned instance.
32775 reputation · 29 Nov 2024, 19:22 UTC
Cloning a template made from a snapshot or from a shut‑down VM does not change how the QEMU Guest Agent behaves inside the clone. The agent itself has no persistent internal state that Proxmox copies; it starts fresh on boot and reports whatever the guest OS currently sees.
proxmoxagent: 1) indicating the agent should be used; the agent binary lives inside the guest.network-get-interfaces reply, reflecting the guest’s current network view.What actually carries over is the guest’s identity: /etc/machine-id, hostname, SSH host keys, and any cached DHCP lease. When a clone boots with those values unchanged, the agent reports an IP/hostname that duplicates the source or another clone, which looks like stale agent data but is an identity‑collision issue.
sudo truncate -s 0 /etc/machine-id
sudo rm -f /etc/ssh/ssh_host_*
sudo cloud-init clean --logs # if cloud-init is installed
sudo poweroff
qm template <vmid>).systemctl status qemu-guest-agent
cat /etc/machine-id # must differ from the source
hostname # should match the clone’s intended name
From the Proxmox host confirm the agent reports the clone’s own address:
qm agent <vmid> network-get-interfaces
Use comments to ask for clarification. Post a solution as an answer.
32,775 reputation · 30 Nov 2024, 00:10 UTC
To build on the previous point regarding identity collisions, it is important to distinguish between the QEMU Guest Agent (QGA) and the guest OS boot sequence. While the QGA itself doesn't maintain a conflicting persistent state, capturing a template from a running snapshot rather than a shut-down VM can interfere with Cloud-Init.
Cloud-Init typically triggers its initialization stages (like local and network) during the initial boot process. If a template is captured from a snapshot of a running system, the cloned instance may resume from a saved RAM state, potentially bypassing the specific boot-time triggers required to process new Proxmox Cloud-Init configurations.
For production gold images, converting a completely shut-down VM to a template is the recommended practice. This ensures a clean boot sequence where /var/log/cloud-init.log confirms that the metadata service is polled and applied correctly before the QGA begins reporting the new network state to the Proxmox host.