Proxmox Server Solutions anunció el 05/11/2026 desde Viena que Everpure, el nombre que usa Pure Storage desde este año, se incorpora a su red de socios como Proxmox Solution Provider oficial y que Proxmox VE pasa a estar soportado en toda la familia de cabinas all-flash FlashArray. Según la nota, las cabinas actúan como almacenamiento compartido centralizado para clústeres Proxmox VE por iSCSI, Fibre Channel, NVMe/TCP o NFS, tanto para máquinas virtuales como para contenedores.
Las claves de Proxmox VE con Everpure FlashArray en 20 segundos
- Everpure (antes Pure Storage) es ya socio oficial de Proxmox desde el 05/11/2026.
- Protocolos: iSCSI, Fibre Channel, NVMe/TCP y NFS.
- En bloque, la integración se apoya en LVM compartido y multipath, sin plugin específico en las guías publicadas.
- Los snapshots sobre LVM compartido siguen como vista previa tecnológica en Proxmox.
La nota de prensa se queda en la alianza y en dos declaraciones; para un administrador de sistemas lo útil está en la documentación que Everpure ha publicado en su portal de soporte. Allí hay guías de conexión para cada protocolo, recomendaciones de red y multipath, procedimientos para Proxmox Backup Server (PBS) y varias rutas de migración desde VMware. Lo que esas guías describen es un montaje con herramientas estándar de Linux y de Proxmox VE: iniciador iSCSI, multipath-tools, nvme-cli y LVM marcado como compartido. No aparece ningún plugin de almacenamiento específico de FlashArray para Proxmox, así que la gestión de volúmenes en la cabina sigue haciéndose desde la propia FlashArray.
Everpure es la marca con la que Pure Storage opera desde 2026; según Computer Weekly, la compañía empezó a cotizar con ese nombre en la Bolsa de Nueva York el 05/03/2026 y la propia empresa presentó el cambio como una ampliación hacia la gestión de datos. Las cabinas mantienen el nombre FlashArray, como recoge la nota de Proxmox.
Cómo se monta cada protocolo según las guías de Everpure
El esquema de la cabina es el mismo para iSCSI y NVMe/TCP: un host por cada nodo de Proxmox con personalidad «none», un grupo de hosts que reúne a todos los nodos del clúster y un volumen asignado a ese grupo. En iSCSI cada host se identifica con su IQN, que se lee en /etc/iscsi/initiatorname.iscsi; en NVMe/TCP, con el NQN de host que se guarda en /etc/nvme/hostnqn. La guía de iSCSI pide además un clúster de al menos tres nodos.
| Protocolo | Almacenamiento en Proxmox VE | Gestión de rutas | Versión citada |
|---|---|---|---|
| iSCSI | LVM compartido sobre dispositivo multipath | dm-multipath (multipath-tools) | 8.x o posterior (guía de buenas prácticas) |
| Fibre Channel | LVM compartido | dm-multipath, con zonificación en la fábrica FC | No indicada en el índice |
| NVMe/TCP | LVM thick compartido | Multipath nativo de NVMe | 9.x o posterior |
| NFS | Recurso NFS compartido | Opción nconnect (varias conexiones TCP) | No indicada en el índice |
En iSCSI, la guía de conexión crea una interfaz iSCSI por cada tarjeta de red, lanza el descubrimiento sendtargets contra cada portal y abre sesión por cada combinación de interfaz y portal; con dos interfaces y dos portales salen cuatro rutas. Después instala multipath-tools en todos los nodos, escribe un /etc/multipath.conf con find_multipaths off, una lista negra para todos los dispositivos y una excepción para el fabricante «PURE», y comprueba el resultado con multipath -ll. El volumen físico y el grupo de volúmenes se crean en un único nodo; luego se añade el almacenamiento LVM en Datacenter > Storage con la casilla «Shared» marcada. Si otro nodo muestra el almacenamiento como «unknown», la guía indica ejecutar vgscan y vgchange -ay.
La guía de NVMe/TCP exige Proxmox VE 9.x o posterior y es la más detallada. Activa el multipath nativo del kernel, fija la política de E/S en queue-depth mediante una regla de udev, conecta cada interfaz a cada portal en el puerto 4420 y deja las conexiones persistentes con /etc/nvme/discovery.conf y el servicio nvmf-autoconnect. Estas son dos de las líneas que publica, la segunda reescrita en una sola línea:
options nvme_core multipath=Y
pvesm add lvm nvme-datastore --vgname nvme-vg --content images,rootdir --shared 1La misma guía pone tres condiciones de red: no agregar (bonding) las interfaces de almacenamiento, mantenerlas en la misma subred que los portales sin rutas manuales y, si se usa MTU 9000, que las tramas jumbo estén activas de extremo a extremo. Quien venga de pruebas previas con este protocolo puede repasar la comparativa de rendimiento de Proxmox y ESXi con NVMe/TCP que se publicó aquí en 2025.
Snapshots, thin provisioning y alta disponibilidad: lo que hay y lo que no
La nota de Proxmox afirma que la alta disponibilidad (HA) y la migración en vivo integradas en Proxmox VE funcionan con FlashArray y que las máquinas virtuales se mueven entre nodos sin copiar sus discos. Encaja con el diseño: todos los nodos ven el mismo grupo de volúmenes LVM, de modo que al migrar solo se traslada el estado de la máquina. La guía de iSCSI propone como prueba apagar un host y comprobar que las máquinas arrancan en otro nodo.
Los snapshots son el punto delicado. Ni la nota ni las guías de conexión de Everpure los mencionan. Proxmox VE 9.0, publicado el 05/08/2025, añadió snapshots en almacenamiento LVM thick compartido mediante cadenas de volúmenes, en las que cada volumen derivado guarda solo los cambios respecto a su padre. En el foro oficial, el equipo de Proxmox explicaba en octubre de 2026 que la función sigue marcada como vista previa tecnológica y citaba dos problemas abiertos: un límite de tamaño de disco de unos 16 TiB y fallos en la exportación e importación sin conexión para migraciones remotas. Quien necesite snapshots en producción tendrá que contar con esa etiqueta o resolverlos en la propia cabina.
Sobre el aprovisionamiento ligero (thin provisioning) la nota no dice nada. La guía de NVMe/TCP indica que LVM thick es el único método de almacenamiento que cubre, así que en Proxmox los discos ocupan su tamaño completo dentro del grupo de volúmenes; cualquier ahorro de espacio quedaría en el lado de la cabina, algo que la documentación revisada no detalla para este caso. Everpure sí publica guías aparte para ampliar un volumen de FlashArray y su almacenamiento LVM, para ActiveCluster con Proxmox y para usar FlashArray como destino de PBS por bloque, NFS o S3.
Qué comprobar antes de llevarlo a producción
La guía de buenas prácticas de multipath para iSCSI recomienda path_selector "service-time 0", agrupación group_by_prio con prioridad ALUA (Asymmetric Logical Unit Access), fast_io_fail_tmo 10, dev_loss_tmo 60 y no_path_retry 0, y desaconseja queue_if_no_path porque puede dejar procesos colgados. Con esos valores calcula unos 20 segundos de caída total de rutas antes de devolver errores de E/S, y avisa de que sus medidas salen de una sola plataforma y conviene repetirlas. El mismo texto usa polling_interval 5 en el ejemplo y 10 en el cálculo de tolerancia, y la guía de NVMe/TCP tiene una línea de ejemplo con el puerto 8009 donde el resto usa 4420. Son detalles menores, pero conviene revisarlos antes de copiar configuración. Con multipath -t se ve la configuración efectiva que resulta al final.
Tampoco está claro el reparto del soporte. La nota habla de soporte oficial en toda la familia FlashArray, pero no precisa versiones mínimas de Purity, condiciones, precio ni qué parte atiende cada incidencia; el perfil de socio en la web de Proxmox solo enlaza a sus servicios de soporte generales. Antes de migrar, lo prudente es validar en laboratorio la versión exacta de Proxmox VE y de Purity, el comportamiento ante la caída de una controladora y la recuperación tras un reinicio de nodo, que la guía de iSCSI señala como causa habitual del estado «unknown».
Para quien venga de vSphere, Everpure documenta migraciones desde volúmenes vVols y mediante un datastore NFS en la cabina, que se pueden contrastar con la guía de migración de VMware a Proxmox de este medio y con la guía en castellano de Proxmox VE 9.2. Una SAN externa no es la única forma de dar almacenamiento compartido a Proxmox: cloudprivado.com describe en su página de cloud privado Proxmox VE gestionado un diseño con Ceph distribuido sobre los propios nodos de cómputo, sin SAN externa, y en otra sección detalla su almacenamiento en red NAS/SAN por NFS e iSCSI.
Preguntas frecuentes
¿Qué protocolos admite Proxmox VE con Everpure FlashArray?
Según la nota de Proxmox, iSCSI, Fibre Channel, NVMe/TCP y NFS. Everpure publica una guía de conexión para cada uno.
¿Hace falta instalar un plugin en Proxmox VE?
Las guías revisadas no usan ningún plugin específico. Trabajan con LVM compartido sobre iSCSI, Fibre Channel o NVMe/TCP, o con un recurso NFS, y herramientas estándar como multipath-tools y nvme-cli.
¿Funcionan los snapshots de Proxmox sobre FlashArray por iSCSI o Fibre Channel?
Proxmox VE 9 permite snapshots en LVM thick compartido mediante cadenas de volúmenes, pero en octubre de 2026 seguían como vista previa tecnológica, con un límite de unos 16 TiB por disco. Las guías de Everpure no tratan este punto.
¿Qué versión de Proxmox VE se necesita?
La guía de NVMe/TCP exige Proxmox VE 9.x o posterior y la de buenas prácticas de iSCSI recomienda 8.x o posterior. La nota de prensa no fija versiones ni de Proxmox VE ni de Purity.
Fuentes:
- Proxmox: Proxmox expands enterprise storage options with Everpure FlashArray (05/11/2026)
- Proxmox: perfil de socio de Everpure
- Everpure: documentación de Proxmox
- Everpure: Connecting Proxmox to FlashArray using iSCSI
- Everpure: Connecting Proxmox to FlashArray using NVMe-TCP
- Everpure: iSCSI Multipath Configuration
- Proxmox: Proxmox Virtual Environment 9.0 (05/08/2025)
- Foro de Proxmox: Proxmox VE 9 LVM snapshot feature still tech preview?
- Computer Weekly: Pure Storage rebrands to Everpure
