Proxmox VE y la reutilización de VMID: por qué la VM 100 de hoy puede heredar las copias y los permisos de la de ayer

Las claves en 30 segundos

• Proxmox VE reutiliza los identificadores. Cuando se borra la VM 100, el asistente de creación vuelve a proponer el 100 a la siguiente máquina, porque /cluster/nextid devuelve el número libre más bajo del rango.
• El número es la clave de casi todo: discos (vm-100-disk-0), grupos de copia en Proxmox Backup Server (vm/100), permisos (/vms/100), tareas de copia, replicación y alta disponibilidad.
• Veeam pidió en julio una identidad permanente para cada VM en el bug 7846, con siete problemas documentados. Proxmox respondió el 7 de agosto que estudia terminar el parche de «next-id» que evita reutilizar números, pero será opcional y no tiene fecha.
• Una corrección al relato habitual: desde 2015 Proxmox borra las ACL de /vms/<id> al destruir la VM. Lo peligroso es otra cosa: quien reciba permisos sobre el nuevo 100 puede ver y restaurar las copias del 100 anterior, y en PBS la máquina nueva escribe en el mismo grupo y la retención se come las copias viejas.
• Hoy se arregla con método: un rango de next-id fuera del uso normal, un registro de números retirados, --purge al borrar, protección o namespace para las copias que hay que conservar y una comprobación antes de reutilizar un número.

---

Cualquiera que administre un clúster de Proxmox VE con cierta rotación de máquinas se ha encontrado alguna vez con esto: crea una VM, el asistente le propone el número 104 y no recuerda que el 104 era el servidor de facturación que se retiró en primavera. Lo normal es que no pase nada. Pero el número no es una etiqueta decorativa: es la clave con la que Proxmox, Proxmox Backup Server y cualquier herramienta externa asocian discos, copias y permisos a una máquina.

El asunto ha vuelto a la superficie por una petición abierta en el Bugzilla del proyecto, tal y como contó Administración de Sistemas. Hemos leído el hilo completo y, para separar lo que es riesgo real de lo que no, también el código fuente actual de Proxmox VE 9.2. Hay matices que cambian las conclusiones.

Qué es un VMID y dónde aparece

En Proxmox VE cada máquina virtual o contenedor recibe un número entero, el VMID, único dentro del clúster mientras la máquina existe. Por defecto, el asistente de la interfaz web propone el número libre más bajo entre 100 y 1.000.000. Ese número no es un campo más de la configuración: es el nombre de la máquina para todo el sistema.

La tabla ya deja ver el problema. Proxmox limpia lo que es suyo y vive en /etc/pve, pero las copias siguen ahí, y todo lo que está fuera del clúster sigue apuntando al número.

Lo que hemos comprobado en el código

El borrado de una VM lo hace la llamada DELETE /nodes/<nodo>/qemu/<vmid> (en la consola, qm destroy). En la versión actual del paquete qemu-server el orden es este:

1. Comprueba que la VM existe, que no tiene la protección activada y que está parada.
2. Si la VM está en alta disponibilidad o tiene tareas de replicación y no se ha pasado --purge, se niega a borrarla.
3. Destruye los discos referenciados en la configuración (y, con --destroy-unreferenced-disks 1, también los que llevan su número en cualquier almacenamiento activo).
4. Llama a remove_vm_access, que borra las ACL de /vms/<vmid> y saca la VM de su pool, y elimina su fichero de cortafuegos.
5. Solo con --purge, la quita de las tareas de replicación, de las tareas de copia y de la configuración de HA.
6. Al final borra la configuración. El propio código lo comenta: si lo hiciera antes, otro proceso podría reutilizar el número mientras se está borrando.

El paso 4 está ahí desde agosto de 2015. Es importante porque buena parte de la conversación, incluido el bug 7846 citando un comentario de 2022, da por hecho que el permiso concedido a un usuario sobre la VM 123 sobrevive al borrado y pasa a la siguiente VM 123. Con las ACL puestas directamente sobre /vms/123, eso no pasa en una instalación actual. Siguen sobreviviendo los permisos más amplios: los de un pool que se vuelve a usar, los de rutas superiores con propagación y los que se den en PBS sobre almacenes y namespaces.

Ahora bien, eso no cierra el problema, porque hay un permiso que se concede de nuevo de forma natural.

Las copias se resuelven por número

Para decidir si un usuario puede leer o restaurar una copia, Proxmox VE (la función check_volume_access de pve-storage) mira dos cosas: que tenga Datastore.AllocateSpace en el almacenamiento y que tenga VM.Backup sobre /vms/<vmid-de-la-copia>. El VMID de la copia sale de su nombre o de su grupo en PBS.

Es decir: si al cliente B se le da acceso completo a su nueva VM 100, que es lo normal, puede ver en el almacenamiento las copias de la VM 100 anterior, que era del cliente A, y restaurarlas. No hay ningún fallo en el control de permisos. Funciona como está diseñado, solo que la identidad que comprueba es un número que ha cambiado de dueño. Es lo que describe un comentario de 2024 en el bug 4369: las copias de la antigua VM 105 aparecen en la nueva VM 105, y su responsable no debería poder leerlas.

En PBS, la VM nueva sigue el grupo de la vieja

Proxmox Backup Server organiza las copias en grupos por tipo y número (vm/100), dentro de un almacén y, opcionalmente, de un namespace. Cada grupo tiene un propietario, que es el usuario o token con el que el clúster se conecta a PBS. Cuando llega una copia, PBS comprueba que quien la envía es el propietario del grupo y, si no lo es, la rechaza con backup owner check failed.

Pero un clúster usa casi siempre un único usuario o token para todas sus copias. Así que, cuando la nueva VM 100 hace su primera copia, el propietario coincide y PBS la añade como una instantánea más del grupo vm/100, al lado de las de la máquina anterior. A partir de ahí:

• La retención trabaja por grupo. Con keep-last=7, tras siete copias de la máquina nueva las de la antigua desaparecen en la siguiente poda, aunque se quisieran conservar dos meses más. Es justo el caso con el que se abrió el bug 4369 en noviembre de 2022.
• La lista de copias de la VM nueva mezcla dos máquinas. En la interfaz se ven todas juntas bajo el mismo número, y restaurar la equivocada es cuestión de un clic.
• La verificación y la sincronización a otro PBS tratan el grupo como una única cadena.

Los discos huérfanos también se reasignan

Hay un tercer efecto menos conocido. Un disco con el número de la VM que no figura en su configuración, porque quedó de un borrado incompleto o en un almacenamiento que estaba desactivado, se considera de esa VM. qm disk rescan --vmid 100 lo añadirá como disco unused a la nueva VM 100, que podrá montarlo. Y al revés: si se borra la VM nueva con destroy-unreferenced-disks, se llevará por delante discos de la anterior.

En replicación ZFS hacia destinos externos pasa algo parecido. El conjunto de datos rpool/data/vm-100-disk-0 de la máquina nueva choca con el de la vieja en el destino, y la salida que se suele proponer, forzar una sincronización completa, borra lo que quedaba allí de la anterior.

Por qué no sirven el vmgenid ni el UUID de SMBIOS

La respuesta clásica de Proxmox a los fabricantes de copias era usar otro identificador que ya está en la configuración. El bug 7846 explica por qué ninguno basta:

Hay un problema añadido: la API de Proxmox solo direcciona por VMID. No existe una llamada para preguntar «dame la máquina cuyo UUID es tal»; hay que recorrer las configuraciones. Al clonar, Proxmox sí genera un vmgenid y un UUID nuevos, pero eso no evita las copias manuales de configuración ni las migraciones de otros hipervisores.

Por eso integraciones que llevan un inventario propio lo tienen difícil. El proveedor de Proxmox para ManageIQ, por ejemplo, tiene abierta una incidencia que cita precisamente la falta de un identificador estable.

Los siete problemas del bug 7846

Pavel Tide, de Veeam, abrió la petición el 24 de julio de 2026 como mejora del backend de Proxmox VE 9, no como vulnerabilidad. Su objetivo declarado es reactivar los parches parados del bug 4369. Resumidos:

1. Identidad de las copias. Un producto de copia no sabe si el vm/100 de hoy es la misma máquina que el de ayer. Resultado: objetos duplicados, puntos de restauración que cruzan cadenas y restauraciones de la VM equivocada que acaban también en cinta y en las copias secundarias.
2. UUID duplicados en clones y migraciones desde Hyper-V, y ningún UUID en contenedores.
3. Integraciones de facturación, métricas y gestión que duplican entradas o asocian datos a la máquina que no es.
4. El grupo de PBS heredado, con la retención podando lo que había de la máquina anterior.
5. Copias de una VM borrada que no se pueden conservar durante su periodo de retención sin moverlas a mano antes de reutilizar el número.
6. Permisos y acceso a copias que pasan al siguiente dueño del número. Como hemos visto, las ACL directas ya se borran, pero el acceso a las copias no.
7. Colisiones de nombres de disco en destinos de replicación ZFS y en sincronizaciones propias.

En su resumen hay un dato que retrata el problema: la solución de llevar registro de los números usados se ha programado tres veces (en 2018, en mayo de 2024 y en noviembre de 2024) y ninguna se ha integrado.

Lo que propone Veeam y lo que contesta Proxmox

Andreas Neufert, también de Veeam, propuso el 3 de agosto un identificador nuevo, VMTRACKINGID, con estas reglas:

• Se genera al crear o registrar la máquina y nunca se reutiliza.
• Ninguna llamada de la API puede fijarlo ni cambiarlo, para que nadie restaure por error una máquina con el identificador de otra.
• Se conserva al restaurar sobre la misma máquina registrada (la copia sigue en su cadena, con una copia completa nueva).
• Cambia cuando se crea una máquina nueva, se restaura a otra VM o se sobrescribe una que ya no estaba registrada.

Neufert aclaraba que lo preferible sería que el propio VMID fuera siempre creciente y no se pudiera fijar desde la API. El identificador nuevo es su plan B, porque Proxmox le había dicho que cambiar el VMID rompe la compatibilidad.

La respuesta de Fiona Ebner, desarrolladora de Proxmox, llegó el 7 de agosto y tiene dos partes:

• Next-id: el equipo piensa «llevar a la meta» una de las series de parches que evitan reutilizar VMID dentro de un clúster. Pero será opcional y cada instalación tendrá que activarlo.
• VMTRACKINGID: son reacios a añadir otro UUID a la configuración. Como alternativa, plantea ampliar la propiedad meta, que hoy solo guarda la fecha de creación (ctime) y la versión de QEMU, con la fecha de clonado (bug 6156), la de restauración y su tipo (sobre la misma máquina o con número nuevo) y la de migración entre clústeres. De ahí se podría derivar una identidad combinando esas fechas con el VMID.

Ebner preguntaba si esa derivación cubriría lo que necesita Veeam. A 30 de octubre no hay respuesta pública en el hilo. Lo último es el comentario del 25 de agosto de un proveedor de servicios gestionados italiano, que pide las cinco medidas a la vez: no reutilizar números como política de clúster, VMID siempre crecientes, identidad independiente del número, aviso al restaurar si el número pudo pertenecer a otra máquina y bloqueo del número mientras queden copias en PBS.

El parche que lleva casi cuatro años esperando

El bug 4369 se abrió el 28 de noviembre de 2022 con un caso sencillo: borrar la VM 125, querer conservar sus copias dos meses y que la nueva VM 125 se las comiera. Está en estado PATCH AVAILABLE.

Los parches, propuestos en mayo de 2024 por Daniel Krambrock (Universidad de Marburgo) y retomados por Severen Redwood, hacen configurable la estrategia del asistente con tres opciones:

La cuarta versión se envió a pve-devel en diciembre de 2024. En mayo de 2026, Fabian Grünbichler confirmaba que los parches registran los números de máquinas eliminadas para no volver a proponerlos. Hemos comprobado que el código actual no los incluye: el next-id de datacenter.cfg sigue aceptando solo lower y upper, y /cluster/nextid busca el primer hueco libre.

Hay un matiz que conviene saber: incluso integrado, ese mecanismo actúa sobre la propuesta del asistente. Quien escriba el número a mano, o una herramienta de automatización que lo pase en la llamada a la API, puede seguir usando uno retirado salvo que el bloqueo llegue también al backend. Grünbichler lo advertía en 2022: quitar la sugerencia no protege contra alguien que puede crear máquinas y quiere abusar de ello.

Mientras tanto, los afectados siguen sumándose. El 15 de septiembre, una universidad estadounidense que ha llevado parte de su entorno de VMware a Proxmox contaba que, en un entorno compartido con varios equipos y refacturación, ya les habían aparecido máquinas nuevas con números viejos en el pool que no era. Su apaño es un pool «pendiente de borrar» donde aparcan las máquinas hasta que caducan sus copias.

Qué hacer hoy: un procedimiento en siete pasos

Ninguna de estas medidas sustituye a una identidad permanente, pero juntas reducen el riesgo a casi nada.

1. Saca el asistente del rango que usas

La opción next-id de datacenter.cfg limita el rango en el que el asistente busca huecos. Si tus máquinas usan números de cuatro cifras, pon la sugerencia en otro rango para que no pueda pisar los tuyos:

# Rango de sugerencia: de 100000 a 199999 (el límite superior es exclusivo)
pvesh set /cluster/options --next-id lower=100000,upper=200000

# Comprobar lo que proponerá ahora
pvesh get /cluster/nextid

Esto no impide reutilizar, pero evita el error más común, que es aceptar sin mirar lo que propone la interfaz.

2. Asigna rangos por cliente o por equipo

En un entorno compartido, la medida que de verdad funciona es que cada cliente tenga su rango de números y sus permisos solo cubran ese rango, normalmente a través de un pool por cliente. Así un número nunca pasa de un cliente a otro. Es lo que recomienda Proxmox desde 2022, y lo que resuelven las capas de gestión multicliente como MultiPortal.

3. Lleva un registro de números retirados

Una línea en el inventario, en la CMDB o en NetBox por cada número que se retira, con la fecha hasta la que hay copias. Si automatizas la creación con Terraform, Ansible o scripts, que el número salga de ese registro y nunca de /cluster/nextid.

4. Antes de reutilizar un número, mira si tiene copias

# ¿Quedan copias del 104 en el almacenamiento PBS "pbs-principal"?
pvesm list pbs-principal --content backup --vmid 104

# Y en todos los almacenamientos de copias del clúster
for s in $(pvesm status --content backup | awk 'NR>1 {print $1}'); do
  pvesm list "$s" --content backup --vmid 104
done

Si devuelve algo, ese número no está libre.

5. Borra con --purge y piensa antes en las copias

qm destroy 104 --purge 1 --destroy-unreferenced-disks 1
# Contenedores
pct destroy 104 --purge 1 --destroy-unreferenced-disks 1

--purge quita la máquina de las tareas de copia, de replicación y de HA; sin él, una tarea de copia que incluya el 104 de forma explícita lo copiará en cuanto exista otra máquina con ese número. En la interfaz web es la casilla Purge from job configurations del diálogo de borrado.

Antes de borrar, decide qué pasa con las copias:

• Protégelas si tienen que vivir su periodo de retención. Una instantánea protegida no la borra la poda (en la interfaz, el icono del escudo; en la consola, proxmox-backup-client snapshot protected update ... true).
• Muévelas a un namespace de archivo en PBS (por ejemplo, retiradas/2026) con una tarea de sincronización local. Ahí no las encontrará la máquina nueva, que escribe en el namespace del clúster.
• Expórtalas si la retención exige otro soporte.

La protección sola no basta. Evita que se borren, pero la máquina nueva seguirá escribiendo en el mismo grupo, y su dueño las verá.

6. Separa con namespaces lo que no debe mezclarse

Los namespaces de PBS separan almacenes por cluster, cliente o entorno con sus propios permisos, y evitan que dos clústeres con una VM 100 cada uno compartan grupo. No resuelven la reutilización dentro del mismo clúster, que escribe siempre en su namespace. En nuestro repaso a fondo de PBS explicamos cómo se combinan con la retención y la verificación.

7. Revisa lo que queda fuera de /etc/pve

Permisos en pools que se vuelven a usar, monitorización, facturación, reglas del cortafuegos perimetral, entradas DNS, documentación. Ninguna de esas cosas sabe que la VM ha cambiado de dueño.

A quién le importa más

En una empresa con un clúster y una veintena de máquinas que casi nunca se borran, esto es una curiosidad. Pesa de verdad en cuatro casos:

• Proveedores de servicios gestionados y entornos multicliente, donde un número puede haber pertenecido a dos empresas distintas y la confusión toca la separación de datos que exige cualquier contrato de encargo de tratamiento.
• Entornos con mucha rotación: laboratorios, CI, formación, escritorios virtuales, donde los números se reciclan cada semana.
• Quien use software de copia de terceros, como Veeam con Proxmox, que necesita saber qué máquina está protegiendo para no mezclar cadenas.
• Organizaciones con retenciones largas por normativa, que tienen que poder conservar la copia de una máquina que ya no existe sin que nadie la pise.

Cómo lo hacemos en Cloud Privado

En los entornos de Proxmox VE gestionado que operamos para nuestros clientes, cada cliente tiene su rango de números, sus pools y su namespace en Proxmox Backup Server, y el asistente propone números fuera del rango de producción. Los números retirados quedan anotados con la fecha de caducidad de sus copias, y el borrado de una máquina sigue un procedimiento con --purge, revisión de copias y limpieza de lo que queda fuera del clúster. Es trabajo poco vistoso, pero es lo que evita que una restauración devuelva la máquina de otro.

Si estás montando un entorno compartido sobre Proxmox, o vienes de VMware y nunca habías tenido que pensar en esto porque vSphere identifica cada máquina por un identificador interno que no se repite, cuéntanos cómo lo tienes organizado y revisamos contigo dónde puede cruzarse un número.

Preguntas frecuentes

¿Qué es un VMID en Proxmox VE?

Es el número entero que identifica a una máquina virtual o a un contenedor dentro de un clúster de Proxmox VE. Aparece en el nombre de su configuración, de sus discos y de sus grupos de copia en Proxmox Backup Server, y es la ruta sobre la que se dan los permisos.

¿Reutiliza Proxmox VE los VMID de las máquinas borradas?

Sí. Al borrar una máquina su número queda libre, y el asistente de creación propone el número libre más bajo del rango configurado, así que lo normal es que el siguiente número que proponga sea el de una máquina borrada.

¿Hereda la VM nueva los permisos de la anterior?

Las ACL dadas directamente sobre la ruta de la máquina se borran al destruirla desde 2015, y la máquina sale de su pool. Lo que se hereda es el acceso a las copias: quien tenga permiso de copia sobre el nuevo número puede ver y restaurar las copias del número anterior, y siguen valiendo los permisos dados sobre pools o rutas superiores.

¿Qué pasa con las copias en Proxmox Backup Server?

La máquina nueva escribe en el mismo grupo de copias que la anterior, porque el grupo se identifica por tipo y número y el clúster suele usar un único usuario para PBS. Las copias de ambas se mezclan y la política de retención acaba borrando las antiguas.

¿Se puede impedir que Proxmox reutilice VMID?

No de forma nativa a 30 de octubre de 2026. Hay parches que guardan la lista de números usados y Proxmox ha dicho que estudia integrarlos como opción, sin fecha. Hoy se puede cambiar el rango que propone el asistente con la opción next-id de datacenter.cfg y llevar un registro propio de números retirados.

¿Sirven los namespaces de PBS para evitarlo?

Separan copias de distintos clústeres o clientes, pero un clúster escribe siempre en su namespace, así que dos máquinas con el mismo número en el mismo clúster siguen compartiendo grupo. Sirven para archivar las copias de una máquina retirada fuera del alcance de la nueva.

Fuentes

• Administración de Sistemas, Proxmox VE: el riesgo de reutilizar los identificadores de las máquinas virtuales: artículo de partida.
• Proxmox Bugzilla, bug 7846: VMID reuse: issues, workarounds, why they fail (abierto el 24 de julio de 2026; respuesta de Proxmox del 7 de agosto).
• Proxmox Bugzilla, bug 4369: Reuse of Proxmox VM ID creates problem with PBS (abierto el 28 de noviembre de 2022, PATCH AVAILABLE).
• pve-devel, cuarta versión de los parches de estrategia de next-id (diciembre de 2024).
• Foro de Proxmox, Avoid reuse of VMID.
• ManageIQ, incidencia 8 del proveedor de Proxmox.
• Proxmox VE, documentación de datacenter.cfg (opción next-id).
• Proxmox Backup Server, documentación de almacenes, namespaces y grupos de copia.
• Código fuente de Proxmox (git.proxmox.com) consultado el 30 de octubre de 2026: qemu-server 9.2.14 (borrado de VM y rescan), pve-access-control (remove_vm_access), pve-storage (check_volume_access), pve-cluster (next-id) y proxmox-backup (comprobación de propietario del grupo).