The reuse of virtual machine identifiers in Proxmox Virtual Environment (Proxmox VE) has reignited debate among system administrators and backup software vendors. An open request in the project’s Bugzilla tracker calls for every virtual machine to have a permanent identity, independent of its numerical identifier, or VMID. The issue goes beyond organisation: it can affect backups, permissions, external integrations and data separation between customers. Proxmox is considering alternatives, but the proposal has yet to result in a confirmed official solution.
Proxmox VE VMIDs: the key points in 20 seconds
- Proxmox VE can reassign the identifier of a virtual machine after it has been deleted.
- Bug 7846 outlines seven issues involving backups, permissions and integrations.
- Veeam is involved in the request to introduce a permanent identity for each machine.
- An earlier proposal, opened in 2022, already suggested preventing VMID reuse.
- Until an integrated solution becomes available, administrators need to manage identifiers and retained backups manually.
The debate is particularly relevant to infrastructure running large numbers of virtual machines, multiple clusters or services for different customers. In these environments, a number that identified a production server yesterday may be assigned to a different machine later, while backup systems and management tools still hold references to the original one.
The latest request, listed as bug 7846 in Proxmox Bugzilla, is titled VMID reuse: issues, workarounds, why they fail. According to the information provided in the report, Pavel Tide opened it on 24 July 2026, with contributions from Andreas Neufert. Both are associated with product management at Veeam. The request is classified as an enhancement to the Proxmox VE 9 backend, rather than a confirmed security vulnerability.
Why a VMID can end up identifying two different machines
In Proxmox VE, each virtual machine or container receives a numerical identifier called a VMID. This number is used across different parts of the infrastructure, including disk names, permission paths, references in external tools and backup groups in Proxmox Backup Server (PBS).
For example, a machine with VMID 100 may use volumes named vm-100-disk-0 and a backup group identified as vm/100. If that machine is deleted and the number 100 is assigned again, the new machine can share numerical references with resources left behind by the previous one.
A VMID helps locate objects within Proxmox, but it does not, by itself, guarantee that the same machine is being identified over time. This distinction becomes particularly important when external systems use the identifier as a permanent reference.
Request 7846 lists seven problems associated with this reuse.
The first concerns backup identity. An external tool may find a group named vm/100, but the number alone cannot establish whether it belongs to the original machine or to another one created later. The VM Generation ID does not resolve every requirement raised in the report. It can change after certain operations, does not behave like an immutable identity and, according to the request, has limitations when queried through the API.
The second issue involves duplicate hardware identifiers. The UUID exposed through SMBIOS can be repeated in certain cloning scenarios or migrations from Hyper-V. LXC containers also lack the same identification mechanism, so SMBIOS UUIDs cannot provide a common solution for every workload type.
The third problem affects external integrations. Management, billing and automation platforms need to distinguish between a deleted machine and another one that later receives the same identifier. Without that distinction, duplicate records or incorrect associations can appear. The request also cites difficulties affecting the Proxmox provider used by ManageIQ.
The remaining four issues concern backup retention, permissions, replication and identifier allocation.
In PBS, a new machine can end up using the same backup group as a previous one. This can interfere with retention policies and the preservation of older backups if the situation is not managed correctly. The request also notes that permissions associated with a VMID may survive the machine’s deletion and affect the next machine assigned that number. In a shared environment, this could result in unintended access to another machine’s resources or backups.
Finally, VMID reuse can cause collisions in ZFS volume names when resources are replicated to external destinations. The /cluster/nextid API, which suggests the next available identifier, does not maintain a global record of every number previously used by external tools.
Proxmox considers a permanent identifier and optional sequential allocation
The request does more than describe the problems. It proposes several measures: allowing administrators to disable VMID reuse, assigning identifiers that always increase, introducing a permanent identity independent of the number, and validating identifiers during restores.
It also calls for a VMID to remain unavailable while associated backups still exist in Proxmox Backup Server. This would mean that a virtual machine’s lifecycle no longer depended solely on whether its configuration had been removed from the cluster.
Andreas Neufert proposes an additional identifier called VMTRACKINGID. According to the proposal, it would be generated when a machine is created or registered, could never be reused or modified through the API, and would change only when a restore resulted in a new virtual machine.
The advantage of this approach would be to separate two functions that can currently be confused. The VMID would continue to serve operational purposes within Proxmox, while the additional UUID would allow external systems to identify a machine persistently.
Neufert considers it preferable for VMIDs themselves to increase sequentially. The additional identifier would be an alternative if changing the existing VMID behaviour could create compatibility problems for current installations.
Proxmox developer Fiona Ebner responded on 7 August 2026. According to the discussion described in the request, the team is considering integrating a series of patches known as next-id, which would prevent identifiers from being reused within a cluster. The feature would be optional and would have to be explicitly enabled.
The team has also expressed reservations about adding another identifier to each machine’s configuration file. As an alternative, Ebner suggested investigating whether some of the required information could be derived from existing metadata, expanded with details about cloning, restoring and remote migration.
The outstanding question is whether that mechanism would meet the needs of backup vendors and other external tools. The request, as described, contains no definitive public answer to that question and no confirmed release date for the changes.
A proposal dating back to 2022, and interim measures for administrators
The debate has a history. Proxmox Bugzilla bug 4369, titled Reuse of Proxmox VM ID creates problem with PBS, was opened in November 2022 and is listed as PATCH AVAILABLE, according to the information provided.
The associated patches propose different ways to select the next VMID: choosing the lowest available number, selecting the highest existing identifier plus one, or skipping numbers included in a list of previously used identifiers. The fourth version of the proposal was sent to the pve-devel development mailing list in December 2024.
The existence of an available patch does not mean that the feature has been integrated into a stable version of Proxmox VE. Based on the information in the requests, no release date or version incorporating the solution can be confirmed.
In the meantime, administrators can reduce the risks through internal procedures. The first measure is to maintain an inventory of retired VMIDs and avoid automatically accepting the number suggested by the interface when creating a new machine. An asset management register, a configuration management database or a tool such as NetBox can help control identifier allocation.
Before deleting a machine, administrators should decide what will happen to its backups. Depending on retention requirements, these may need to be preserved, moved or exported. It is also advisable to review permissions associated with the identifier after deletion and verify that the machine has been removed from backup, replication and high-availability tasks where appropriate.
PBS namespaces can help separate backups by customer or cluster, but they do not, by themselves, eliminate the risk of VMID reuse within the same cluster. These measures therefore reduce the likelihood of errors without replacing a permanent identity that every integration can query.
The issue is particularly important for managed service providers (MSPs). In a multi-customer infrastructure, the same VMID may have belonged to different organisations at different times. If backups of the previous machine still exist, an incorrect association could affect data separation and retention policies.
Request 7846 specifically raises this concern from the perspective of a managed service provider. It also refers to the problem described in bug 4369, where a university reportedly encountered new virtual machines with previously used identifiers and incorrect resource-pool assignments.
For Proxmox, the challenge is to introduce more reliable identity management without breaking existing workflows and integrations that depend on VMIDs. For administrators, the immediate task is to treat an identifier as a resource that must be managed throughout a machine’s lifecycle, rather than as a number that stops mattering once the delete button is clicked.
Frequently asked questions
What is a VMID in Proxmox VE?
A VMID is the numerical identifier assigned to a virtual machine or container in Proxmox VE. It is used in internal references and can appear in disk names, permissions and backup groups.
What are the risks of reusing a VMID?
A new machine may receive the identifier of a deleted one, causing confusion in backups, integrations or permissions that remain associated with the previous machine’s number.
Does Proxmox VE already support preventing VMID reuse?
The cited requests describe proposals and patches for changing identifier allocation. Based on the available information, it cannot be confirmed that the feature has been integrated into a stable release or that a release date has been announced.
What can administrators do in the meantime?
They can maintain an inventory of retired identifiers, review permissions after deleting machines, decide how to preserve backups and check backup and replication tasks. PBS namespaces help separate environments, but they do not, by themselves, solve VMID reuse within a single cluster.
Sources: