Ocho almacenamientos compartidos en Proxmox, y solo dos sin letra pequeña

El 30 de octubre, Lightbits anunció que Proxmox la ha nombrado Solution Provider y publicó un plugin de almacenamiento para Proxmox VE. En la nota, Tim Marx, COO de Proxmox, lo resume así: «Proxmox VE supports a wide range of storage technologies, so organizations can build their infrastructure the way it best suits them». Es verdad y es amable. La tabla de la documentación oficial dice lo mismo con menos cortesía: hay ocho tipos de almacenamiento compartido y, en la columna de snapshots, solo tres llegan sin una nota al pie. Cuando abres esas notas, quedan dos.

Esto importa sobre todo si vienes de VMware con una cabina pagada y amortizada. La pregunta que llega a nuestra mesa casi siempre es la misma: «¿me vale mi SAN con Proxmox?». La respuesta corta es sí. La respuesta útil es que te vale con una lista concreta de renuncias, y que la lista no está en ninguna nota de prensa: está en las notas al pie de la tabla.

Las ocho filas, y lo que esconde cada nota

La tabla de tipos de almacenamiento de la documentación de Proxmox VE marca nueve filas con «yes» en la columna de compartido. Una es Proxmox Backup Server, que ni siquiera puntúa en la columna de snapshots: pone «n/a». Quedan ocho, y esta es la lectura con las notas ya abiertas:

Las tres filas limpias de la tabla principal son CephFS, Ceph/RBD y ZFS over iSCSI. CephFS se cae sola en cuanto miras su ficha: no acepta imágenes de disco, y su propia tabla añade un aviso que la general no muestra, «While no known bugs exist, snapshots are not yet guaranteed to be stable, as they lack sufficient testing». Quedan dos. Y de esos dos, uno te pide una cabina capaz de ZFS y una clave SSH sin contraseña guardada en /etc/pve/priv/zfs/ para que Proxmox cree los ZVOL por ti. No es un defecto, es su diseño; pero es una frase que conviene leer antes de firmar la arquitectura, no después.

La nota 2: el snapshot que para la máquina

Si tu almacenamiento compartido es un NAS por NFS, los snapshots existen pero los hace qcow2, no el almacenamiento. Y la documentación es explícita sobre el precio: «Creating and deleting internal qcow2 snapshots will block a running VM and is not an efficient operation», con un añadido que rara vez se cita: «The performance is particularly bad with network storages like NFS» y, en discos de cientos de gigas o de teras, «these operations may take several minutes, or in extreme cases, even hours». Si tu caso está afectado, la documentación recomienda crear y borrar los snapshots con la VM apagada, contando con una tarea larga. Esa misma nota deja abierta la otra puerta, y conviene decirlo: las cadenas de volúmenes también valen en almacenamiento de fichero. Pero ahí siguen en vista previa, y de eso va el apartado siguiente.

Traducido a la vida real: el botón de «snapshot antes de actualizar» que todo el mundo da por gratis puede ser una parada de servicio en la máquina más grande que tengas, que suele ser justo la que menos te puedes permitir parar. No es una queja contra NFS, que funciona de maravilla para otras cosas. Es que ese botón no cuesta lo mismo en cada fila de la tabla.

La nota 4: el interruptor que solo vale para los discos de mañana

Aquí está la buena noticia de Proxmox VE 9, y es de verdad buena. Se llama snapshot-as-volume-chain y es una bandera del backend LVM. Con ella, el snapshot no lo hace LVM (cuyas instantáneas nativas, dice la documentación, «interfere with all write operations within the entire volume group while the snapshot is active») sino el propio Proxmox, encadenando volúmenes: el estado actual se queda con el nombre del snapshot y se arranca un volumen nuevo que apunta al anterior y solo guarda las diferencias. Usa qcow2 únicamente para encadenar, no para sus instantáneas internas. Y lo relevante: «Snapshots as volume chains provide vendor-agnostic support for snapshots on any storage system that supports block storage. This includes iSCSI and Fibre Channel-attached SANs». Es decir, tu cabina.

Ahora las tres frases que vienen con ella, todas en la misma página:

• Sigue siendo vista previa. «Snapshots as volume chains are currently a technology preview in Proxmox VE», dice el recuadro. No es una advertencia decorativa: en la hoja de ruta de Proxmox, sacarla de vista previa en LVM-thick, directorio, NFS y CIFS sigue en la lista de objetivos, junto con poder borrar en caliente el snapshot más alto de la cadena.
• No alcanza a lo que ya tienes. «Enabling or disabling this flag only affects newly created virtual disk volumes». Esta es la frase del post. Si migras doscientas máquinas a la cabina y activas la bandera después, esas doscientas siguen sin cadena. El orden de la migración decide quién tiene snapshots.
• Tu contabilidad de espacio miente, salvo que la cabina ayude. Los volúmenes de snapshot son LVM gruesos, y «Each snapshot will appear to use the full volume size on the PVE side, but the actual space usage on the underlying storage will be smaller» solo si la cabina soporta aprovisionamiento fino y discard. Si no, el consumo aparente es el real.

La otra vía: código de otro dentro de PVE::Storage::Custom

Volvamos a la noticia del 30 de octubre, porque ilustra una vía que cada vez se usa más: el plugin de terceros. El de Lightbits conecta Proxmox a su almacenamiento por NVMe/TCP, está publicado con licencia Apache 2.0 en GitHub, su repositorio se creó el 1 de junio de 2026 y acumulaba quince estrellas el día que escribimos esto. Técnicamente promete lo que uno quiere: volúmenes compartidos, snapshot y rollback en el propio almacenamiento, migración en vivo sin copiar discos y HA. La nota de prensa lo llama plugin «nativo».

Y luego está lo que el propio proyecto dice de sí mismo en su README, que es mucho más informativo que la nota: es un «open-source, community-driven project» mantenido «on a best-effort basis», y la relación con el producto comercial la deja por escrito sin rodeos: «not part of the Lightbits LightOS commercial product» y «not covered by Lightbits LightOS support agreements or SLAs unless a separate written agreement explicitly states otherwise». Esto no es una pega: es honestidad del fabricante, y se agradece. Pero cambia la pregunta. Ya no es «¿rinde?», que seguramente sí. Es «¿quién arregla esto un martes a las tres de la mañana, y bajo qué contrato?».

Hay un detalle técnico que lo hace concreto, y está en la guía de problemas del propio plugin. Proxmox versiona la interfaz de sus plugins de almacenamiento, y cuando una actualización sube ese número, el plugin de terceros empieza a soltar en cada orden el mensaje «Plugin "PVE::Storage::Custom::LightbitsPlugin" is implementing an older storage API, an upgrade is recommended». El proyecto declara compatibilidad con libpve-storage-perl hasta 9.1.13 y API de almacenamiento 16. Dicho de otro modo: cuando actualices Proxmox, hay una pieza más en el camino crítico de tus discos que tiene que ir al ritmo del hipervisor y que no mantiene ni Proxmox ni tú. A nosotros eso no nos frena, lo inventariamos; lo que no se puede es descubrirlo el día de la actualización.

Lo que montamos nosotros, y cuándo decimos que no

Operamos Proxmox VE con almacenamiento Ceph en producción, repartido en varios centros de datos, y la fila limpia de la tabla coincide con lo que vemos: Ceph/RBD te da compartido, snapshots y clones sin asteriscos, y te quita la cabina del camino crítico. Esa es la parte que vendemos y es verdad.

Y aquí va la parte que no vendemos: Ceph no es la respuesta por defecto. Pide nodos, pide red dedicada y pide alguien que lo entienda el día que se pone en HEALTH_WARN. Ya escribimos, sin adornos, por qué un Ceph de tres nodos no se cura solo, aguanta: con tres nodos no hay sitio donde recolocar las copias cuando cae uno. Si tu realidad son tres máquinas, una red compartida y nadie de guardia, lo honesto es la cabina que ya tienes, con la bandera de cadenas activada antes de mover el primer disco, y una lista escrita de lo que renuncias. Lo decidimos caso por caso porque no somos revendedores de nada: esa decisión es exactamente el trabajo de consultoría.

Esto encaja además con lo que contábamos hace unas horas sobre qué ruta de salida de VMware pasaba de verdad por el VDDK: la ruta de salida de VMware casi nunca se rompe por donde se dice en los foros, sino por una pieza concreta que nadie miró a tiempo. En las migraciones, la pieza suele ser el almacenamiento, y el momento en que se decide no es cuando falla, sino cuando se crea el primer volumen.

Cuatro comprobaciones, hoy, en tu clúster

Ninguna lleva más de cinco minutos y las cuatro se contestan mirando la máquina, no leyendo:

# 1. ¿Qué tipos de almacenamiento tienes de verdad?
pvesm status

# 2. ¿Está la bandera de cadenas en tu storage LVM?
grep -A8 '^lvm:' /etc/pve/storage.cfg

# 3. ¿Tus discos YA creados la aprovechan? (lectura nuestra: raw = no)
qemu-img info /dev/<vg>/vm-<vmid>-disk-0

# 4. Si usas un plugin de terceros, ¿va al día?
#    (los dos números: el que exige PVE y el que declara el plugin)
perl -MPVE::Storage -e 'print PVE::Storage::APIVER(), " ",
  PVE::Storage::Custom::TuPlugin->api(), "\n"'

La tercera es la que suele doler. Si tus volúmenes existentes salen en raw y la bandera está puesta, el interruptor se activó tarde: la documentación dice que solo afecta a los volúmenes nuevos. Nuestra lectura, y la marcamos como lectura nuestra, es que mover el disco a otro almacenamiento y traerlo de vuelta lo recrea bajo la bandera actual; compruébalo en una máquina de pruebas antes de tocar producción, porque ahí nos la jugamos todos. Y añade una quinta comprobación que no cabe en una línea de consola: haz un snapshot de la VM más grande que tengas, en el almacenamiento real, y cronométralo. Ese número, y no la tabla, es tu ventana de mantenimiento.

La frase del COO de Proxmox es cierta: hay para elegir. Lo que no hay es una fila sin coste. Elegir almacenamiento compartido no va de rendimiento, porque casi todos rinden; va de decidir qué parte de la pila vas a poder reparar tú, cuál va a reparar un contrato y cuál no va a reparar nadie a las tres de la mañana.

Fuentes. La tabla de tipos de almacenamiento, sus notas 2, 3 y 4, las fichas por backend (iSCSI, CephFS, LVM, ZFS over iSCSI) y todas las frases sobre snapshot-as-volume-chain salen del capítulo de almacenamiento de la documentación oficial de Proxmox VE, consultado el 2 de noviembre de 2026. Los objetivos pendientes (sacar las cadenas de vista previa, el borrado en caliente del snapshot más alto y la mejora de multipath para FC e iSCSI) están en la hoja de ruta de Proxmox VE, que también fecha Proxmox VE 9.2 el 21 de mayo de 2026. El anuncio de Lightbits como Solution Provider, la cita de Tim Marx y la licencia Apache 2.0 proceden de la nota de prensa publicada el 30 de octubre de 2026. Las frases sobre el modelo de soporte del plugin, el mensaje de deriva de API y la tabla de compatibilidad (PVE 9.x, libpve-storage-perl hasta 9.1.13, API 16) son del README del repositorio pve-lightbits; la fecha de creación del repositorio y el recuento de estrellas, de la API pública de GitHub el 2 de noviembre de 2026. Las citas técnicas se reproducen en su inglés original para que se puedan buscar literalmente. La lectura comparada entre la tabla general y las fichas por backend es nuestra, igual que la hipótesis sobre recrear el volumen, y van marcadas como tales en el texto. No tenemos relación comercial con Lightbits ni con ningún fabricante de cabinas. La fotografía de la imagen social es «3PAR SAN in the server room», de Alexis Lê-Quôc, CC BY-SA 2.0, vía Wikimedia Commons.