Almacenamiento en Proxmox VE: buenas prácticas y equivalencias con vSphere para migrar desde VMware

Cuando alguien llega a Proxmox VE desde años de vSphere, lo primero que le descoloca no es la interfaz, ni la línea de comandos, ni siquiera la gestión del clúster. Es el almacenamiento. En VMware el modelo mental es sencillo y homogéneo: creas un datastore —normalmente VMFS sobre una LUN, o un recurso NFS— y ahí viven tus VMs. Punto. En Proxmox hay media docena larga de tecnologías de almacenamiento distintas conviviendo, cada una con sus reglas sobre snapshots, aprovisionamiento fino, alta disponibilidad y formato de disco. Elegir mal al principio se paga caro: migrar terabytes de un backend a otro cuando ya estás en producción no es divertido.

Este artículo es la guía que me habría gustado tener cuando empecé a mover cargas de ESXi a Proxmox. Vamos a repasar cada tipo de almacenamiento con sus ventajas e inconvenientes reales, con los comandos que de verdad se usan, y con una tabla de equivalencias frente a vSphere para que quien venga del mundo VMware sepa exactamente qué es cada cosa. Si estás valorando el salto, quizá te interese antes echar un ojo a las mejores alternativas a VMware en 2026 y a cómo instalar Proxmox VE en un mini PC.

El modelo mental: cómo piensa Proxmox el almacenamiento

La primera diferencia conceptual importante: en vSphere el datastore es una abstracción que oculta la tecnología subyacente. Da igual si por debajo hay VMFS, vSAN o NFS; para el hipervisor un datastore es un sitio donde caben ficheros VMDK. En Proxmox, en cambio, el tipo de backend es explícito y determina qué puedes y qué no puedes hacer. Un almacenamiento LVM no soporta snapshots; uno LVM-thin sí. Un ZFS te da compresión y checksums; un directory con qcow2 te da snapshots pero peor rendimiento bajo carga. No hay una capa que lo homogeneíce: eliges la herramienta consciente de sus límites.

La segunda diferencia es el concepto de content types. Cada almacenamiento en Proxmox declara qué tipos de contenido admite: imágenes de disco de VM (images), discos de contenedores LXC (rootdir), plantillas de contenedor (vztmpl), ISOs (iso), copias de seguridad (backup) y snippets. Un mismo NFS puede servir para ISOs y backups pero no necesariamente para discos de VM con buen rendimiento. Esto no existe en vSphere, donde un datastore lo aguanta todo.

Puedes ver de un vistazo qué almacenamientos tienes configurados, su tipo, uso y content types con:

pvesm status
# Name             Type     Status      Total        Used   Available    %
# local            dir      active   98559220     6829448    86695000    6.93%
# local-lvm        lvmthin  active  1638400000   204800000  1433600000  12.50%
# ceph-vm          rbd      active  8796093022   879609302  7916483720  10.00%
# nas-backups      nfs      active  4831838208  1932735283  2899102925  40.00%

Y la definición real de todos ellos vive en un único fichero de texto, versionable y fácil de auditar —algo que se agradece viniendo del vCenter:

cat /etc/pve/storage.cfg

Almacenamiento local basado en bloques: LVM y LVM-thin

LVM (Logical Volume Manager) es el caballo de batalla del almacenamiento local en bloques de Proxmox. Cada disco de VM es un volumen lógico (LV) dentro de un grupo de volúmenes (VG). Aquí hay que distinguir dos sabores que la gente confunde constantemente.

LVM «grueso» (thick) reserva todo el espacio del disco en el momento de crearlo. Es rápido y predecible, pero no soporta snapshots de VM desde la interfaz de Proxmox (los snapshots de LVM tradicionales existen a bajo nivel, pero Proxmox no los usa para VMs) y no hay aprovisionamiento fino. Es el equivalente conceptual a un disco thick provisioned eager zeroed de VMware, pero sin la comodidad de los snapshots.

LVM-thin es harina de otro costal y, para la mayoría de instalaciones de un solo nodo, la opción por defecto y la más sensata. Usa un thin pool: el espacio se asigna bajo demanda (aprovisionamiento fino real) y, lo más importante, soporta snapshots de forma nativa y eficiente. Es lo que Proxmox configura como local-lvm durante la instalación estándar.

Crear un thin pool y registrarlo en Proxmox se hace así:

# Crear el volumen físico y el grupo de volúmenes sobre un disco dedicado
pvcreate /dev/sdb
vgcreate vg_vms /dev/sdb

# Crear el thin pool ocupando todo el VG
lvcreate --type thin-pool -l 100%FREE -n thinpool vg_vms

# Registrar el thin pool como almacenamiento en Proxmox
pvesm add lvmthin local-nvme --vgname vg_vms --thinpool thinpool --content images,rootdir

Ventajas de LVM-thin: excelente rendimiento (acceso a bloque directo, sin capa de fichero por medio), snapshots rápidos, aprovisionamiento fino, madurez a prueba de bombas. Inconvenientes: es estrictamente local —no se comparte entre nodos—, no tiene checksums de datos ni protección contra corrupción silenciosa (bit rot), y si sobreaprovisionas y llenas el pool real, las VMs se paran en seco. Vigila siempre el uso real del pool, no el aparente.

ZFS: el favorito para nodo único y para quien viene de storage serio

Si LVM-thin es lo pragmático, ZFS es lo que elige quien quiere lo mejor del almacenamiento local y no le importa dedicarle RAM. Proxmox integra ZFS de forma nativa y, para mí, es la opción por defecto en cualquier nodo con discos decentes y memoria de sobra.

Lo que ZFS aporta sobre LVM-thin es sustancial: checksums de extremo a extremo (detecta y, con redundancia, corrige la corrupción silenciosa), compresión transparente (LZ4 es prácticamente gratis en CPU y suele ganar espacio y hasta rendimiento), snapshots instantáneos y baratos, clones, y —clave para clústeres sin cabina compartida— replicación asíncrona entre nodos, que habilita migraciones y una forma de HA sin necesidad de storage compartido.

Un pool en espejo con las buenas prácticas típicas se monta así:

# Pool en espejo (equivalente a un RAID1) con dos NVMe
zpool create -o ashift=12 rpool-data mirror /dev/nvme0n1 /dev/nvme1n1

# Compresión LZ4 (casi siempre recomendable) y desactivar atime
zfs set compression=lz4 rpool-data
zfs set atime=off rpool-data

# Registrar el pool como almacenamiento de Proxmox
pvesm add zfspool zfs-local --pool rpool-data --content images,rootdir --sparse 1

Para producción con más discos, RAIDZ2 (doble paridad, tolera dos fallos) es el punto dulce de capacidad y seguridad, mientras que los espejos ofrecen mejor rendimiento de IOPS y reconstrucciones más rápidas:

# RAIDZ2 con seis discos: capacidad de 4, tolerancia a 2 fallos simultáneos
zpool create -o ashift=12 tank raidz2 sda sdb sdc sdd sde sdf

# Estado de salud del pool y de la reconstrucción
zpool status -v tank

# Ver cuánto está ahorrando la compresión de verdad
zfs get compressratio tank

Ventajas de ZFS: integridad de datos real, compresión, snapshots y clones baratísimos, replicación entre nodos, gestión unificada. Inconvenientes: es voraz de RAM —la regla clásica es contar con memoria para la caché ARC, y por defecto ZFS puede reclamar hasta la mitad de la RAM del host—; conviene ponerle un límite explícito si compartes el hierro con VMs hambrientas; y no perdona los discos SMR ni los controladores RAID hardware (ZFS quiere ver los discos en crudo, HBA en modo IT). El límite de ARC se fija así:

# Limitar la ARC de ZFS a 8 GB (en bytes) de forma persistente
echo "options zfs zfs_arc_max=8589934592" > /etc/modprobe.d/zfs.conf
update-initramfs -u

Almacenamiento compartido en red: NFS y CIFS/SMB

Aquí el terreno es familiar para cualquiera que venga de VMware, porque NFS funciona en Proxmox exactamente igual de bien que en vSphere. Montas un export de tu NAS o cabina y lo usas como almacenamiento compartido entre todos los nodos del clúster. Es la vía más rápida y sencilla de tener storage compartido, que es el requisito para migraciones en vivo cómodas y para HA.

# Añadir un export NFS como almacenamiento compartido del clúster
pvesm add nfs nas-vms \
  --server 192.168.10.20 \
  --export /volume1/proxmox \
  --content images,iso,backup,vztmpl \
  --options vers=4.2

Un matiz importante frente a VMware: sobre NFS, Proxmox almacena los discos como ficheros qcow2 por defecto, y es qcow2 —no NFS— quien aporta los snapshots y el aprovisionamiento fino. Esto es distinto del VMDK sobre NFS de vSphere, pero el resultado práctico es equivalente. CIFS/SMB existe y funciona, pero salvo que estés atado a un NAS que solo hable SMB, para discos de VM prefiere siempre NFS: menos sobrecarga y mejor comportamiento con la escritura síncrona.

Ventajas de NFS: compartido entre nodos, trivial de configurar, ideal para ISOs, plantillas y backups, y perfectamente válido para VMs si el NAS y la red acompañan. Inconvenientes: el rendimiento y la latencia dependen por completo de tu red y de tu cabina —10 GbE o mejor si vas en serio—, y tienes un punto único de fallo en el propio NAS salvo que lo montes en alta disponibilidad.

iSCSI y LVM sobre iSCSI: la cabina de bloques de toda la vida

Si vienes de una SAN Fibre Channel o iSCSI sirviendo LUNs a tu clúster ESXi, este es tu camino de migración más directo. Proxmox puede conectarse a targets iSCSI, pero con una advertencia que sorprende a los recién llegados: usar el iSCSI «pelado» directamente para discos de VM es mala idea, porque no puedes poner varias VMs en la misma LUN de forma segura. El patrón correcto es montar un LVM encima del target iSCSI compartido: la LUN entera se convierte en un VG del que Proxmox reparte volúmenes lógicos, uno por disco de VM, y ese LVM sí es compartible entre todos los nodos.

# 1) Registrar el target iSCSI (sin usarlo directamente para VMs)
pvesm add iscsi san-target \
  --portal 192.168.20.5 \
  --target iqn.2010-06.com.example:storage.lun0 \
  --content none

# 2) Crear un LVM compartido sobre esa LUN
pvesm add lvm san-lvm \
  --vgname vg_san \
  --base san-target:0.0.0.scsi-360014...  \
  --shared 1 \
  --content images

Ventajas: reaprovechas tu inversión en cabina, storage compartido de bloque con buen rendimiento, ruta de migración natural desde VMware. Inconvenientes: el LVM sobre LUN compartida no soporta snapshots de VM (el gran «pero» frente a VMFS, que sí los hace), y la gestión de multipath hay que montarla a mano con multipath-tools. Si los snapshots te son innegociables y quieres bloque compartido, la respuesta ya no es iSCSI+LVM, es Ceph.

Ceph: hiperconvergencia y el equivalente real a vSAN

Llegamos a la joya de la corona para clústeres serios. Ceph es un almacenamiento definido por software, distribuido y con replicación, que Proxmox integra de forma nativa (paquete pveceph). Conviertes los discos locales de tres o más nodos en un pool de almacenamiento único, replicado y tolerante a fallos, sin ninguna cabina externa. Si en VMware montabas vSAN, Ceph es tu equivalente conceptual directo: hiperconvergencia, storage compartido «gratis» a partir de los discos de los propios hosts, y HA de verdad.

El despliegue mínimo, sobre un clúster ya formado y con una red dedicada para Ceph (esto último no es opcional, es obligatorio para que rinda), sería:

# Instalar Ceph en cada nodo del clúster
pveceph install --repository no-subscription

# Inicializar el clúster Ceph indicando la red dedicada de almacenamiento
pveceph init --network 10.10.10.0/24

# Crear un monitor en el nodo (repetir en al menos 3 nodos)
pveceph mon create

# Convertir cada disco libre en un OSD (una unidad de almacenamiento Ceph)
pveceph osd create /dev/nvme1n1

# Crear un pool con 3 réplicas (mínimo 2 para seguir escribiendo)
pveceph pool create vm-pool --size 3 --min_size 2

La regla de oro de Ceph: tres nodos es el mínimo absoluto, cinco es donde empieza a estar cómodo, la red de almacenamiento va separada y a 10/25 GbE, y con size 3 tu capacidad útil es un tercio del bruto (el precio de la resiliencia). Comprobar la salud del clúster es tu nuevo pan de cada día:

ceph -s
ceph osd df tree

Ventajas de Ceph: storage compartido, replicado, con snapshots, escalado horizontal y autorreparación, sin cabina externa ni licencias. Es lo que hace posible un HA real en Proxmox de forma comparable a vSAN. Inconvenientes: complejidad operativa notable —Ceph es un mundo en sí mismo—, exige red dedicada rápida y hardware homogéneo, y penaliza mucho si escatimas en nodos o en red. No lo montes para dos servidores «a ver qué tal»: para eso, ZFS con replicación te da el 80% del resultado con el 20% del dolor.

Tabla comparativa de los backends de Proxmox

Resumiendo lo anterior en lo que de verdad importa a la hora de decidir:

Buenas prácticas según tu escenario

Nodo único (homelab, servidor pequeño): ZFS si tienes RAM de sobra y valoras la integridad de datos; LVM-thin si quieres lo simple, rápido y probado. En ambos casos, discos por SSD/NVMe para las VMs y, si puedes, un segundo pool o disco para las copias. No metas los backups en el mismo pool que las VMs: el día que el pool muera, te llevas por delante datos y respaldos a la vez.

Clúster pequeño (2-3 nodos) sin cabina: ZFS en cada nodo más replicación programada. No es HA instantánea como Ceph, pero te permite migrar VMs y recuperarte de la caída de un nodo con una pérdida de datos acotada al intervalo de replicación. Es la opción con mejor relación resultado/complejidad para la mayoría de PYMEs.

# Programar replicación de la VM 100 al nodo pve2 cada 15 minutos
pvesr create-local-job 100-0 pve2 --schedule "*/15"

# Ver el estado de las réplicas
pvesr status

Clúster serio (3+ nodos) con HA real: Ceph, sin dudarlo, con su red de almacenamiento dedicada a 10/25 GbE y, a ser posible, discos empresariales con protección ante pérdida de energía (PLP). Aquí es donde Proxmox planta cara a un vSphere+vSAN de tú a tú.

Vienes de una SAN de VMware: iSCSI+LVM como puente para no tirar la cabina, asumiendo que pierdes los snapshots a nivel de disco, y planifica la migración a Ceph a medio plazo si quieres recuperarlos.

Equivalencias vSphere → Proxmox para migradores de VMware

Esta es la tabla que todo ex-administrador de vSphere agradece tener a mano. No son equivalencias perfectas —las filosofías difieren— pero sí funcionalmente cercanas:

La operación estrella del día a día, mover un disco de una VM de un almacenamiento a otro sin apagarla (el equivalente al Storage vMotion), se hace así:

# Mover el disco scsi0 de la VM 100 al almacenamiento Ceph, formato raw,
# y borrar el original al terminar
qm disk move 100 scsi0 ceph-vm --format raw --delete

# Migrar la VM 100 completa al nodo pve2 en vivo
qm migrate 100 pve2 --online

Copias de seguridad: Proxmox Backup Server, el arma secreta

Un apartado que merece mención propia porque es, sinceramente, uno de los puntos donde Proxmox supera con holgura a la experiencia estándar de VMware sin licencias caras. Proxmox Backup Server (PBS) hace backups incrementales a nivel de bloque con deduplicación y compresión, verificación de integridad y restauración granular (puedes montar un backup y sacar un solo fichero). Se integra con Proxmox VE de forma nativa como un almacenamiento más de tipo pbs.

# Registrar un Proxmox Backup Server como almacenamiento
pvesm add pbs pbs-principal \
  --server 192.168.10.30 \
  --datastore backups \
  --username backup@pbs \
  --content backup

# Lanzar un backup manual de la VM 100 con modo snapshot y compresión zstd
vzdump 100 --storage pbs-principal --mode snapshot --compress zstd

La combinación de snapshots del backend para recuperación rápida ante un error, más PBS con retención y verificación para el respaldo serio, cubre la estrategia de backup completa sin desembolsar en soluciones de terceros. Si el post te ha servido, quizá quieras rematar la instalación con la guía de hardening de Proxmox.

Errores comunes al migrar desde VMware

• Poner un controlador RAID hardware delante de ZFS. ZFS quiere los discos en crudo. Un RAID hardware le esconde los errores que ZFS está diseñado para detectar. HBA en modo IT o nada.
• Usar iSCSI directamente para discos de VM. Siempre LVM por encima de la LUN compartida. El iSCSI pelado no reparte una LUN entre varias VMs de forma segura.
• Esperar snapshots donde el backend no los da. Si eliges LVM thick o iSCSI+LVM, olvídate de los snapshots de disco. Es la diferencia más dolorosa frente a VMFS.
• Montar Ceph con red compartida. Ceph sin su red dedicada rápida es una fuente inagotable de latencias y de discusiones. La red de almacenamiento va aparte.
• Sobreaprovisionar LVM-thin y no vigilar el pool real. Cuando el thin pool físico se llena, las VMs no ralentizan: se detienen. Monitoriza el uso real, no el aparente.
• Meter backups y VMs en el mismo pool. El respaldo tiene que sobrevivir a la muerte del almacenamiento primario. Sepáralos siempre.

Conclusión: elige consciente y no mires atrás

La riqueza de opciones de almacenamiento de Proxmox es a la vez su mayor fortaleza y la principal fuente de tropiezos para quien llega de la comodidad homogénea de vSphere. Pero la decisión, bien mirada, no es tan difícil: LVM-thin o ZFS para nodo único, ZFS con replicación para clústeres pequeños, y Ceph para HA real. NFS para lo compartido sencillo, iSCSI+LVM como puente desde tu SAN de VMware, y Proxmox Backup Server rematando la estrategia de respaldo.

Lo importante es elegir con conocimiento de causa, entendiendo qué snapshots, qué aprovisionamiento fino y qué tolerancia a fallos te da cada backend, porque cambiar de opinión en producción cuesta tiempo y disgustos. Si tienes claro el escenario, el resto es aplicar los comandos de arriba y disfrutar de una plataforma que, sin licencias, hace casi todo lo que hacía tu vSphere —y algunas cosas, como PBS, incluso mejor.