Problema

En entornos de Proxmox VE es frecuente clonar el nodo o migrar los volúmenes a un nuevo disco para renovar hardware o redistribuir capacidad. Después de la operación, varios usuarios descubren que sus LXC containers no arrancan. Los logs suelen mostrar errores al montar los volúmenes de Local‑LVM, como “mount: unknown filesystem type 'ext4'” o “Failed to activate logical volume”. El síntoma típico es:

pct start 101
lxc-start: failed to mount /dev/pve/vm-101-disk-0

Este patrón no está limitado a una versión concreta de Proxmox; ocurre siempre que la capa de almacenamiento (LVM) pierde la correspondencia entre los UUID de los volúmenes y la configuración guardada en /etc/pve/lxc/. El contenedor queda “atascado” porque el hipervisor no encuentra el dispositivo esperado.

Causa

1. UUIDs cambiados tras la clonación

Al clonar un disco con dd, Clonezilla o herramientas similares, los volúmenes LVM se recrean con nuevos UUID. Proxmox almacena la referencia al LV en la definición del contenedor (campo rootfs). Si el UUID no coincide, el intento de montaje falla.

2. Metadatos de VG (Volume Group) duplicados

Si la copia conserva el mismo nombre de VG (pve) en ambos nodos, el gestor de LVM puede confundirse al buscar el LV. En clústeres sin quorum, la colisión de nombres genera errores de “volume not found”.

3. Entradas obsoletas en /etc/fstab dentro del contenedor

Algunos contenedores incluyen montajes estáticos en /etc/fstab que apuntan a dispositivos específicos del host original. Tras la clonación, esos dispositivos ya no existen, provocando que el contenedor se quede en estado stopped.

4. Permisos y atributos de los dispositivos

Los dispositivos de bloque creados por LVM deben pertenecer al grupo lxc y tener los permisos correctos (660). La clonación a veces altera los atributos, impidiendo que el proceso lxc-start acceda al LV.

Solución

El objetivo es alinear la definición del contenedor con la realidad del storage después de la clonación. El proceso se puede dividir en tres pasos: identificar, corregir y validar.

Paso 1 – Identificar la discrepancia

  1. Listar los LVs que debería usar el contenedor:

    pct config <CTID> | grep rootfs

  2. Verificar que el LV exista:

    lvs -o lv_name,vg_name,lv_uuid,attr | grep <nombre_del_lv>

  3. Comparar el UUID del LV con el que aparece en la configuración. Si no coinciden, hay que actualizar la referencia.

Paso 2 – Corregir la configuración

Opción A: Reasignar el LV existente

Si el LV sigue presente pero con otro UUID, simplemente edita la definición:

pct set <CTID> -rootfs local-lvm:<VG>/<LV_NAME>,size=<tamaño>

Ejemplo:

pct set 101 -rootfs local-lvm:pve/vm-101-disk-0,size=8G

Opción B: Re‑crear el LV a partir de una copia de seguridad

Cuando el LV original se perdió o está corrupto, restaura desde la última backup:

vzdump --restore /ruta/backup/vzdump-lxc-101.tar.lzo 101

Opción C: Renombrar el VG para evitar colisiones

Si hay dos VGs con el mismo nombre, renómbralo en el nodo clonado:

vgrename pve pve_clone

Luego actualiza todas las referencias en /etc/pve/lxc/*.conf que apunten a pve/.

Opción D: Limpiar /etc/fstab del contenedor

Accede al rootfs del contenedor (montado temporalmente) y elimina líneas que referencien dispositivos inexistentes:

mount /dev/pve/vm-101-disk-0 /mnt
sed -i '/\/dev\/.*$/d' /mnt/etc/fstab
umount /mnt

Paso 3 – Ajustar permisos

Asegúrate de que el LV tenga los atributos correctos:

lvchange -ay /dev/pve/vm-101-disk-0
chown root:lxc /dev/pve/vm-101-disk-0
chmod 660 /dev/pve/vm-101-disk-0

Cuándo aplicar esta solución

  • Síntomas: pct start devuelve errores de montaje, lxc-start se detiene inmediatamente, o journalctl -u pve-container@<CTID>.service muestra “device not found”.
  • Entorno: Proxmox VE con almacenamiento Local‑LVM y contenedores LXC que fueron creados antes de la clonación del disco.
  • No aplica: Si los contenedores usan almacenamiento tipo ZFS, Ceph o Directory, ya que los problemas de UUID no aparecen allí. Tampoco es útil cuando el fallo proviene de una actualización de kernel que rompe la compatibilidad del módulo cgroup2.

Código

# 1. Ver configuración del contenedor
pct config 101 | grep rootfs

# 2. Listar LVs y comparar UUIDs
lvs -o lv_name,vg_name,lv_uuid,attr | grep vm-101-disk-0

# 3. Corregir referencia (ejemplo)
pct set 101 -rootfs local-lvm:pve/vm-101-disk-0,size=8G

# 4. Si el VG colisiona, renombrar
vgrename pve pve_clone

# 5. Ajustar permisos del LV
lvchange -ay /dev/pve/vm-101-disk-0
chown root:lxc /dev/pve/vm-101-disk-0
chmod 660 /dev/pve/vm-101-disk-0

Verificación

  1. Ejecuta pct start <CTID> y observa que el contenedor pasa a running sin errores.

  2. Revisa el log del contenedor:

    pct console <CTID>

    Debe aparecer el prompt del shell dentro del contenedor.

  3. Confirma que el LV está activo:

    lvs | grep vm-101-disk-0

    El estado Attr debe contener a (active).

  4. Si el contenedor monta volúmenes adicionales, verifica /etc/fstab dentro del contenedor para asegurarte de que no queden entradas rotas.

Notas adicionales

  • Siempre realiza una snapshot o backup antes de tocar LVs; vzdump es la herramienta recomendada en Proxmox.
  • Cuando clones discos, considera crear el nuevo disco con una VG diferente (pve2, storage2) para evitar colisiones de nombres.
  • En entornos con varios nodos, sincroniza los metadatos de LVM usando vgimportclone después de la clonación; este comando actualiza automáticamente los UUIDs y renombra los VGs según sea necesario.
  • Si el problema persiste después de los pasos anteriores, revisa la salida de dmesg para detectar errores de kernel relacionados con LVM o dispositivos de bloque.
  • Documenta cualquier cambio en los archivos de configuración de contenedores; una simple línea de rootfs equivocada puede volver a romper el arranque después de futuras migraciones.