Idempotence of ansbile modules

[TheBigOne]

Dear Community,

Is anyone here using Infrastructure as Code (IaC) to fully automate Proxmox infrastructure with Ansible—not just running occasional playbooks manually, but as a complete CI/CD automation stack?

I’m trying to understand the behavior of the proxmox_kvm module when cloning VMs from a template, specifically regarding idempotency. Out of the box, the module creates duplicate VMs with the same name on every run instead of ensuring the target state.

To work around this, I built a lookup module to check if a VM name already exists, preventing duplicates via a when condition. However, this feels like a workaround for something that should be handled natively.

A few specific points I’m struggling to wrap my head around:

• Lack of Idempotency: Running a clone task to ensure a VM exists should be idempotent. Instead, it creates a new VM with a new ID every time.
• Cloning vs. ID lookup: If I pass an existing VM ID to the clone task, Ansible uses that ID as the source to clone from, rather than treating it as the target.
• Non-unique VM names: Proxmox requires VM names to be valid DNS names, but allows duplicate names across a cluster. What is the design rationale behind this?
• Naming conventions: Using hyphens instead of underscores in object keys complicates YAML/JSON handling in Ansible workflows.
• In-flight modifications: It doesn't seem possible to alter settings (like expanding disk size) directly within the clone task.

Since I’m fairly new to Proxmox, I might be missing something fundamental. Idempotency is one of Ansible’s core conventions, so I’d love to hear how others tackle full automation with Proxmox.

EDIT: The documentation says: "With state=present if vmid not provided and VM with name exists in the cluster then no changes will be made." but this is wrong so I expect it is a bug?
community.proxmox 2.0.0
proxmoxxer 2.3.0

Thanks for your insights!

 

[Johannes S]

As far I know the ansible collection isn't maintained by the Proxmox developers but a community support. Did you try to ask at their issues tracker? https://github.com/ansible-collections/community.proxmox/issues

 

[TheBigOne]

Yes, I saw this during my research as well. I put something to an existing issue.
But in general it should not be possible to have duplicate names for the same type of resource in a cluster as long as its not just a label and if it is a label, why it should not be allowed to use underscores but hyphens.
I guess its because of cloud init to use it as hostname but even then, a duplicate is no fun.

But this may be just my own view on infrastructure.

 

[bbgeek17]

A VM name/label is not treated as a unique identifier in PVE, or, for example, in OpenStack. The VM ID is the actual identifier.

As an example, nothing in the PVE API uses the VM name or label as an addressable identifier. API operations use the VM ID.

This is an architectural choice that was made during the original product design, and it is unlikely to change at this point, given the hundreds of thousands, if not more, of PVE installations already in use.

Arguably, a uniquely generated Openstack-like ID is more flexible, but it is what it is now.

Cheers

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[TheBigOne]

So you say that proxmox will never evolve because there are already installations out there and switching to a uuid is impossible. I guess it will be the same for other features. It sounds strange, so we will discuss that with the proxmox support before we buy any licenses. Thanks for your insights.

 

[bbgeek17]

You should by all means discuss any concerns you have with PVE directly, either with Proxmox or a reseller during the pre-sales process.

There is nothing inherently impossible about changing software architecture. Whether a particular change represents a worthwhile investment, and how it could be implemented without breaking existing functionality and integrations, is a separate question.

If this is important to you - Proxmox GmbH also accepts code contributions, subject to their normal review process.

It is also worth keeping in mind that this is a volunteer community forum, and I am not associated with Proxmox GmbH. In particular, this thread concerns a third-party Ansible collection rather than the Proxmox API itself, so I would not expect the forum to necessarily provide an official position on how that integration should behave.

For questions about product direction, API semantics, or potential changes to the VMID model, Proxmox would be the appropriate source for an authoritative answer.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[bbgeek17]

A few comments about your observations:

Non-unique VM names: Proxmox requires VM names to be valid DNS names, but allows duplicate names across a cluster. What is the design rationale behind this?

There is absolutely no "valid DNS name" requirement for a VM name in the PVE, cluster or solo.

Naming conventions: Using hyphens instead of underscores in object keys complicates YAML/JSON handling in Ansible workflows.

This is Ansible creator's choice, not Proxmox's.

In-flight modifications: It doesn't seem possible to alter settings (like expanding disk size) directly within the clone task.

A clone creates an identical copy of a VM, resizing a disk is a completely separate operation. If some other Hypervisor/Orchestrator allows you do this, more than likely they are doing it in two steps, obfuscating it via a GUI or CLI switch.

• Cloning vs. ID lookup: If I pass an existing VM ID to the clone task, Ansible uses that ID as the source to clone from, rather than treating it as the target.

Proxmox API requires 3 parameters, in addition to a number of optional ones: https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/qemu/{vmid}/clone
If the Ansible module does not allow you to specify both clearly, that is an issue to raise with the creators

Lack of Idempotency: Running a clone task to ensure a VM exists should be idempotent. Instead, it creates a new VM with a new ID every time.

Name is an optional parameter that the API allows. If you want to base idempotency on the VM's name, that would require an additional lookup to check whether a VM with that name already exists before performing the clone. IMHO it is a rather specific requirement and does not seem to me to be widely acceptable as default use-case.
Again, going back to Openstack - nothing prevents you from having instances with duplicate names, but you will have issues with querying by name later. VMware is a bit more strict about it.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[fba]

There is an older thread about cloning with ansible: https://forum.proxmox.com/threads/problems-cloning-from-template-with-ansible.106527/
where it is also shown, that the targetid must be set to prevent Proxmox VE automatically assigning an available one.
You also should be aware of that filtering by name for the source vm uses the first match found, which might not be the intended source.