Problema

En entornos Proxmox que utilizan LXC containers sobre un LVM‑Thin pool, es frecuente migrar el disco de arranque a un SSD más rápido o con mayor capacidad. Tras una clonación del disco (por ejemplo con Clonezilla) el nodo arranca sin problemas, pero los containers aparecen “desaparecidos” o fallan al iniciar con errores como:

mount: /var/lib/lxc/.pve-staged-mounts/rootfs: wrong fs type, bad option, bad superblock on /dev/mapper/pve-vm--201--disk--0
pct start 201 --debug

En la interfaz de local‑lvm los volúmenes aparecen con el tamaño correcto pero con “0 GB” consumidos. El síntoma típico es que el LV sigue existiendo en la tabla de LVM, pero el thin pool no reconoce los datos o la metadata está corrupta. El resultado es que los containers no pueden montar su raíz y el hook lxc-pve-prestart-hook aborta.

Causa

Clonar un disco que contiene un thin pool no es equivalente a copiar un disco plano. El pool almacena su metadata en bloques que referencian los extents de los contenedores. Al clonar:

  1. Desalineación de UUID – El UUID del VG (pve) se replica, pero el kernel crea un nuevo device‑mapper node (/dev/dm‑X) con un número diferente. Los archivos de configuración de LXC (/etc/pve/lxc/ID.conf) siguen apuntando al antiguo nombre de dispositivo (/dev/mapper/pve-vm--201--disk--0), que ya no coincide con la nueva tabla de dispositivos.
  2. Metadata del thin pool dañada – Clonezilla copia sector a sector, pero el thin pool mantiene un bitmap de bloques libres. Si la copia se hace mientras el pool está activo, el bitmap puede quedar inconsistente, provocando que el pool informe “0 GB” consumidos y que los LVs no sean accesibles.
  3. Cambios de nombre de device‑mapper – Al crear el nuevo VG en el SSD, el kernel asigna nuevos nombres (dm‑6, dm‑7, …). Los scripts de arranque de Proxmox usan rutas estáticas, por lo que el mount falla porque el dispositivo indicado no existe o apunta a un LV vacío.
  4. Falta de actualización de fstab o lxc config – En algunos casos la configuración del contenedor contiene la ruta absoluta del LV. Tras la clonación, esa ruta ya no es válida.

Solución

La estrategia consiste en reconstruir la metadata del thin pool y alinear los nombres de los LVs con la nueva instalación. Los pasos pueden dividirse en tres fases:

1. Verificar integridad del VG y del thin pool

vgdisplay pve
lvdisplay -m pve
thin_check -v /dev/pve/data

Si thin_check reporta errores, procede a repararlos.

2. Reparar el thin pool

thin_repair -v /dev/pve/data

Este comando reescribe la metadata a partir de los extents existentes. En la mayoría de los casos, después de la reparación los LVs vuelven a mostrar su tamaño real y el consumo de espacio desaparece.

3. Actualizar referencias de los contenedores

  • Obtener el nuevo nombre del LV:
lvs -o lv_name,lv_path,lv_attr --noheadings | grep '^vm-.*-disk-0'
  • Editar la configuración del contenedor (/etc/pve/lxc/ID.conf) sustituyendo la línea rootfs: local-lvm:vm-201-disk-0 por la ruta correcta si el nombre cambió. En la mayoría de los setups, la referencia es simbólica y no necesita cambio, pero si el LV se renombró (por ejemplo vm-201-disk-0 → vm-201-disk-0-old), renómbralo:
lvrename pve vm-201-disk-0 vm-201-disk-0-old
lvrename pve vm-201-disk-0-old vm-201-disk-0
  • Forzar la relectura de la configuración:
pct reload 201

4. Reiniciar el contenedor

pct start 201

Si el contenedor arranca, el problema está resuelto. En caso contrario, revisa el log de journalctl -u pvedaemon para identificar si persiste algún hook que apunte a un dispositivo inexistente.

Cuándo aplicar esta solución

  • Síntomas: pct start falla con errores de montaje, el thin pool muestra “0 GB” consumidos, o los LVs aparecen como “missing” tras una migración de disco.
  • Entorno: Proxmox VE con LVM‑Thin como storage para LXC containers. La solución es válida tanto para clones realizados con Clonezilla como con dd o partclone.
  • No aplica: Si el problema es exclusivamente de hardware (SSD defectuoso) o si los contenedores usan almacenamiento ZFS o directory storage, la reparación del thin pool no será útil.

Código

# 1. Comprobar estado del VG y thin pool
vgdisplay pve
thin_check -v /dev/pve/data

# 2. Reparar metadata del thin pool (solo si thin_check reporta errores)
thin_repair -v /dev/pve/data

# 3. Listar LVs y confirmar nombres
lvs -o lv_name,lv_path,lv_attr --noheadings | grep 'disk-0'

# 4. Renombrar LV si es necesario
lvrename pve vm-201-disk-0 vm-201-disk-0-old
lvrename pve vm-201-disk-0-old vm-201-disk-0

# 5. Recargar configuración del contenedor
pct reload 201

# 6. Iniciar contenedor
pct start 201

Verificación

  1. Espacio consumido: lvs -o lv_name,lv_size,attr debe mostrar tamaños reales y el atributo V (thin volume) sin “0 GB”.
  2. Estado del contenedor: pct status 201 debe devolver running.
  3. Montaje correcto: mount | grep vm-201-disk-0 debe listar la raíz del contenedor bajo /var/lib/lxc/201/rootfs.
  4. Logs limpios: journalctl -u pvedaemon -b | grep -i "error" no debe contener referencias a lxc-pve-prestart-hook.

Notas adicionales

  • Evita clonar mientras el VG está activo. Apaga los containers y, si es posible, desmonta el thin pool (vgchange -an pve) antes de usar Clonezilla. Un clone “cold” garantiza que la metadata no cambie durante la copia.
  • Backup de la metadata: antes de cualquier migración, guarda una copia del metadata del thin pool con thin_dump. En caso de corrupción, puedes restaurar con thin_restore.
  • Uso de pve-zsync o vzdump para migrar LVs en lugar de clonar el disco completo. Estas herramientas manejan la re‑creación de los volúmenes en el destino y actualizan automáticamente las referencias en los archivos de configuración.
  • Documenta los UUID del VG y del thin pool. Si decides replicar el mismo UUID en el nuevo disco, asegúrate de que no haya conflictos con el nodo original (por ejemplo, al volver a conectar ambos discos).
  • Revisar hooks personalizados: si has añadido scripts en /usr/share/lxc/hooks/, verifica que no dependan de rutas estáticas que cambian tras la clonación.

Con estos pasos, la mayoría de los fallos de LXC tras clonar un nodo Proxmox a un SSD se resuelven rápidamente, y el entorno vuelve a estar listo para ejecutar contenedores sin perder datos.