Problema

En entornos de alta disponibilidad donde varios nodos Proxmox comparten un mismo pool de bloques (FC, iSCSI o multipath iSCSI), la gestión de discos virtuales suele quedar atrapada entre dos extremos: usar LVM‑thin para ahorrar espacio pero perder predictibilidad de consumo, o usar discos totalmente preasignados (thick) que garantizan espacio pero desperdician recursos. Cambiar de un modo a otro después de que la VM está en producción es doloroso: snapshots pueden romperse, los movimientos de almacenamiento fallan y la coherencia del clúster se ve amenazada. El patrón recurrente es la necesidad de un plugin o método que permita:

  • Seleccionar explícitamente thin o thick por VM.
  • Convertir discos entre ambos modos sin perder datos.
  • Mantener snapshots, rollback y migraciones en vivo sin pasos manuales extensos.
  • Operar sobre un VG LVM ya existente que ya está expuesto por el SAN.

Causa

Los fallos habituales provienen de tres áreas:

  1. Falta de separación de metadatos – Cuando se usa un solo LV para thin y thick, el plugin de almacenamiento no puede distinguir qué discos pertenecen a qué modo, lo que lleva a operaciones de snapshot que intentan mezclar cadenas de dependencias incompatibles.
  2. Bloqueo de recursos del clúster – Proxmox confía en su API de almacenamiento para garantizar quorum y locking. Si el plugin no verifica la propiedad del LV antes de mutar, dos nodos pueden intentar crear o eliminar el mismo LV simultáneamente, provocando corrupción.
  3. Gestión de fallos incompleta – En caso de pérdida de conectividad SAN, QEMU y el device‑mapper siguen enviando I/O. Si el plugin intenta “reparar” automáticamente los metadatos faltantes, puede crear LVs huérfanos o sobrescribir datos de respaldo.

Estos problemas se agravan cuando se intenta migrar una VM thin a thick (o viceversa) usando la herramienta de “Storage Move” de Proxmox sin un mecanismo que convierta los datos de forma segura.

Solución

Una solución reutilizable se basa en tres pilares:

1. Definir dos IDs de almacenamiento en Proxmox que apunten al mismo VG

  • sharedlvm-thin → usa lvmthin como backend y crea un pool LVM‑thin por VM.
  • sharedlvm-thick → usa lvm normal, pero con una capa de “generation” que materializa snapshots como LV independientes.

Ambos IDs comparten el mismo vgname (por ejemplo, sharedvg). La distinción se hace a nivel de tipo de backend, no de VG.

2. Plugin o script de conversión que:

  • Para thin → thick: crea un LV lineal del mismo tamaño, copia los bloques con dd o lvconvert --type linear, luego crea snapshots como LVs independientes y elimina el pool thin.
  • Para thick → thin: crea un nuevo thin pool (si no existe), clona el LV lineal dentro del pool usando lvconvert --type thin, y elimina el LV lineal original.

El proceso debe envolver:

  • Lock de clúster mediante pvesh o la API de Proxmox (/nodes/{node}/cluster/lock).
  • Verificación de quorum antes de iniciar la copia.
  • Rollback automático si la copia falla (mantener ambos LVs hasta que la operación concluya).

3. Integrar la lógica en los hooks de Proxmox

Proxmox permite definir hookscript en la definición del storage. Un hook que capture los eventos pre-move, post-move, pre-snapshot y post-snapshot puede:

  • Detectar el tipo de storage (thin o thick).
  • Ejecutar la conversión correspondiente.
  • Actualizar los metadatos del VM (qm config) para apuntar al nuevo LV.

Paso a paso de instalación (Linux)

  1. Instalar el paquete del plugin (por ejemplo, proxmox-sharedlvmthin).
  2. Añadir los dos storages en la GUI o vía CLI.
  3. Habilitar los hook scripts en /etc/pve/storage.cfg.

Código esencial

# 1. Instalar plugin desde GitHub (versión RC5.4 TG12)
apt-get update && apt-get install -y git
git clone https://github.com/delltech1/proxmox-sharedlvmthin.git /usr/local/src/proxmox-sharedlvmthin
cd /usr/local/src/proxmox-sharedlvmthin
dpkg-buildpackage -us -uc
dpkg -i ../proxmox-sharedlvmthin_*.deb

# 2. Crear storage IDs (ejemplo con pvesh)
pvesh create /storage -storage sharedlvm-thin -type lvmthin -vgname sharedvg -content images,rootdir
pvesh create /storage -storage sharedlvm-thick -type lvm -vgname sharedvg -content images,rootdir

# 3. Hook script para conversión (guardado en /etc/pve/local/hooks/convert.sh)
cat > /etc/pve/local/hooks/convert.sh <<'EOF'
#!/bin/bash
set -e
VMID=$1
ACTION=$2
STORAGE=$3

if [[ "$ACTION" == "pre-move" && "$STORAGE" == "sharedlvm-thin" ]]; then
    # thin → thick conversion
    LV=$(qm config $VMID | grep '^virtio0' | cut -d':' -f2 | tr -d ',')
    THICK_LV="${LV}_thick"
    lvcreate -L $(lvs --noheadings -o LV_SIZE $LV) -n $THICK_LV sharedvg
    dd if=/dev/sharedvg/$LV of=/dev/sharedvg/$THICK_LV bs=64K conv=noerror,sync
    qm set $VMID -virtio0 sharedlvm-thick:$THICK_LV
    lvremove -f $LV
fi
EOF
chmod +x /etc/pve/local/hooks/convert.sh

# 4. Asociar hook al storage
pvesh set /storage/sharedlvm-thin -hookscript /etc/pve/local/hooks/convert.sh

4. Buenas prácticas de bloqueo y recuperación

  • Usa pvecm lock antes de iniciar cualquier movimiento que implique cambios en LVs.
  • Configura multipath -ll y verifica que todos los paths estén active ready.
  • Mantén una copia de seguridad de los metadatos del VG (vgcfgbackup) antes de cualquier conversión masiva.

Cuándo aplicar esta solución

Escenarios válidos

  • Clústeres Proxmox con SAN compartido donde se desea mezclar VMs thin y thick.
  • Necesidad de migrar VMs entre nodos sin detenerlas, manteniendo snapshots.
  • Entornos donde el consumo de espacio es crítico pero se requiere garantía de reserva para ciertas VMs (bases de datos, aplicaciones críticas).

Señales típicas

  • Crecimiento inesperado de uso de LVM‑thin que amenaza el espacio del pool.
  • Necesidad de snapshots consistentes para VMs que ya usan discos thick.
  • Fallos de “Storage Move” que reportan “insufficient space” aunque haya espacio libre en el pool.

Exclusiones

  • Configuraciones sin un VG compartido (solo discos locales) no se benefician.
  • Entornos donde el SAN no soporta multipath o no ofrece quorum; la solución depende de la disponibilidad del pool.
  • Cuando la política de la empresa prohíbe scripts de hook personalizados por motivos de auditoría.

Verificación

  1. Comprobar tipo de storage 
    pvesh get /nodes/<node>/storage/sharedlvm-thin/status
pvesh get /nodes/<node>/storage/sharedlvm-thick/status
  2. Crear VM con thin y validar que el LV está bajo un pool thin: 
    lvs -a -o lv_name,lv_attr,vg_name | grep <vmid>
  3. Ejecutar Storage Move de la VM a sharedlvm-thick. Verificar que el hook crea el LV thick y actualiza la configuración.
  4. Revisar snapshots después de rollback: los snapshots deben aparecer como LVs independientes (lvdisplay).
  5. Simular pérdida de path (desconectar un HBA) y observar que QEMU sigue funcionando y que el plugin no intenta reparar automáticamente.

Si todos los pasos concluyen sin errores en los logs de journalctl -u pvedaemon y pveproxy, la solución está operativa.

Notas adicionales

  • La conversión thin → thick implica una copia de bloques completa; planifícala fuera de horas pico para evitar saturación de I/O.
  • Los snapshots thick consumen espacio lineal; monitoriza el uso del VG con vgs y establece alertas en tu sistema de monitoring.
  • En clústers de tres nodos, el plugin no sustituye la lógica de quorum del SAN; siempre verifica que la capa de hardware (FC, iSCSI) tenga su propio mecanismo de failover.
  • Si el plugin se actualiza, revisa los cambios en los hooks; una incompatibilidad de versión puede romper la lógica de conversión.
  • Para entornos de pruebas, crea un VG “dummy” con lvcreate --size 10G --name dummyvg y valida el flujo antes de tocar el SAN productivo.