Proxmox “VM disk vanished”: almacenamiento vs configuración, y cómo diagnosticarlo

El único modelo mental que necesitas: punteros de configuración vs objetos de almacenamiento

Cuando Proxmox dice que falta un disco de VM, estás tratando con dos capas que pueden desincronizarse:

• Capa de configuración: la configuración de la VM en /etc/pve/qemu-server/<vmid>.conf (y las definiciones de almacenamiento en /etc/pve/storage.cfg). Este es el “sistema de punteros”: qué nombre de disco, qué ID de almacenamiento, qué ID de volumen.
• Capa de almacenamiento: objetos reales en el backend de almacenamiento (ZFS zvol, LVM LV, archivo QCOW2, imagen RBD de Ceph, LUN iSCSI, NFS file). Esta es la “física”.

La mayoría de los incidentes “disco desaparecido” son uno de estos:

1. El objeto existe, el puntero está equivocado (desajuste de configuración). Este es el caso feliz: arregla la configuración, importa el volumen, refresca el almacenamiento y reinicia la VM.
2. El puntero es correcto, el objeto es inaccesible (almacenamiento caído, pool no importado, ruta de red muerta, permisos). Aún suele ser recuperable sin pérdida de datos, pero debes dejar de adivinar y empezar a probar.
3. El objeto desapareció (volumen eliminado, snapshot revertido, almacenamiento reemplazado, pool equivocado). Esto se convierte en una historia de restauración desde backup o recuperación profunda del almacenamiento.

Así que tu trabajo no es “hacer que Proxmox deje de quejarse”. Tu trabajo es responder, con evidencia:

• ¿Qué ID de volumen cree Proxmox que usa la VM?
• ¿Ese volumen existe en el backend?
• Si no, ¿existe un volumen similar en otra parte?
• ¿Se cambió storage.cfg, cambió el ID de almacenamiento o se movió el backend?

Una cita que ha envejecido bien en operaciones: Parafraseando — Gene Kim: la fiabilidad proviene de diseñar bucles de retroalimentación que detecten errores temprano, no de heroicidades después del hecho. El punto aquí: adquiere el hábito de verificar configuración y almacenamiento por separado.

Primer chiste corto: Tu disco de VM no “desapareció”; solo se fue a vivir a una granja en el campo con todos los demás LUNs perdidos.

Guion de diagnóstico rápido (primero/segundo/tercero)

Este es el guion que usas cuando la gente espera. Está sesgado hacia la velocidad y la evidencia.

Primero: demuestra lo que Proxmox cree que debería existir

1. Localiza la configuración de la VM, lee las líneas de disco (virtio/scsi/sata/ide). Extrae los IDs de volumen.
2. Comprueba si el ID de almacenamiento referenciado está definido y actualmente “activo”.
3. Intenta una búsqueda de volumen a nivel Proxmox (pvesm list / pvesm status).

Segundo: demuestra si el objeto del backend existe

1. ZFS: lista zvols/datasets, confirma que el pool esté importado y saludable.
2. LVM-thin: lista LVs, asegúrate de que el VG esté presente y el thinpool activo.
3. Almacenamiento por directorio: comprueba rutas y permisos, confirma que el punto de montaje es real (no un mountpoint vacío).
4. Ceph: lista imágenes RBD, verifica salud del cluster y autenticación del keyring.

Tercero: decide la ruta de recuperación más segura

• Si el disco existe pero el puntero está mal: modifica la configuración de la VM o reimporta el volumen al almacenamiento con el ID correcto.
• Si el almacenamiento está caído: repara el almacenamiento primero; no edites la configuración de la VM para “eludir” el almacenamiento faltante o causarás errores de configuración en dos sentidos.
• Si el disco se eliminó: deja de hurgar; pivota hacia backups, objetivos de replicación, snapshots o recuperación a nivel de sistema de archivos. Cada “intento” extra es una oportunidad para sobrescribir evidencia.

Consejo de velocidad: no reinicies el nodo ni “simplemente reinicies la VM” hasta que sepas si tratas con un montaje obsoleto, un pool faltante o un volumen realmente eliminado. Los reinicios pueden ocultar evidencia transitoria en logs y también activar reparaciones automáticas que cambien la situación.

Datos y contexto interesantes (por qué esto sigue ocurriendo)

• /etc/pve es un sistema de archivos de clúster: Proxmox almacena la configuración en pmxcfs, un sistema distribuido tipo base de datos. Si las comunicaciones del clúster están malsanas, las lecturas de configuración pueden ser extrañamente consistentes pero erróneas entre nodos.
• Los IDs de almacenamiento son nombres, no magia: “local-lvm” es solo una etiqueta en storage.cfg. Renombrar o recrear un almacenamiento con un backend distinto puede invalidar silenciosamente las referencias de disco de las VMs.
• Los zvols ZFS son dispositivos de bloque: en Proxmox, un disco respaldado por zvol no es un archivo. “Buscar en el directorio” no lo encontrará; debes consultar ZFS.
• LVM-thin puede engañarte bajo presión: los thinpools pueden pasar a solo lectura o negarse a activarse cuando la metadata está llena. Eso puede parecer “LV faltante”, pero en realidad es “el LV no se activa”.
• Los puntos de montaje pueden fallar en abierto: si un montaje NFS cae y un servicio recrea el directorio de montaje local, puedes acabar escribiendo imágenes de VM en el disco local del nodo. Después, el “disco desaparecido” ocurre cuando NFS se vuelve a montar y oculta los archivos locales.
• “Healthy” en Ceph está acotado: un clúster puede estar globalmente saludable, pero tu cliente puede faltar de keyring o tener caps que impidan listar/leer una imagen RBD.
• Los IDs de volumen de Proxmox tienen estructura: típicamente lucen como local-lvm:vm-101-disk-0 o tank:vm-101-disk-0. Si ves una ruta cruda en la config, alguien probablemente evitó la abstracción de almacenamiento.
• La deriva de configuración de VM es común en migraciones: especialmente al pasar de discos basados en archivos (qcow2) a volúmenes de bloque (ZFS/LVM/Ceph), o al importar desde otras plataformas.
• Los snapshots no te protegen de errores de punteros: los snapshots protegen datos; no protegen a un humano de adjuntar el disco equivocado al VMID equivocado.

Qué significa realmente “disk vanished” en Proxmox

No existe una cadena de error canónica. Verás variaciones según el backend:

• Interfaz web de Proxmox: “unable to find volume” o “volume does not exist”.
• qm start: errores que hacen referencia a un ID de volumen (por ejemplo, storage 'local-lvm' does not exist o no such logical volume).
• qemu-system: no puede abrir un dispositivo de bloque, permiso denegado, archivo faltante.

Traduce el síntoma a una pregunta:

• Si el error menciona ID de almacenamiento (p. ej., local-lvm, tank, ceph-ssd): probablemente storage.cfg o un problema de activación del almacenamiento.
• Si menciona un nombre de volumen (vm-101-disk-0): probablemente objeto del backend faltante, pool equivocado, VG equivocado, o el disco fue movido/renombrado.
• Si menciona una ruta (p. ej., /mnt/pve/nfs/images/101/vm-101-disk-0.qcow2): probablemente un problema de montaje/permisos/ruta.

La forma más rápida de dejar de dar vueltas es tratar la config de la VM como un contrato. O es válida y el almacenamiento está roto, o el almacenamiento está bien y el contrato está mal.

Tareas prácticas: comandos, salidas y decisiones (12+)

Todo lo siguiente está escrito para la shell de un host Proxmox. Ejecuta como root (o con privilegios apropiados). Cada tarea incluye: el comando, qué significa típicamente la salida y la decisión que tomas.

Tarea 1: Identificar las referencias exactas de disco en la configuración de la VM

cr0x@server:~$ vmid=101; sed -n '1,200p' /etc/pve/qemu-server/${vmid}.conf
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0
onboot: 1
ostype: l26
scsihw: virtio-scsi-pci

Significado: ahora tienes dos backends distintos: local-lvm y tank. No asumas que ambos están rotos; diagnostica por disco.

Decisión: copia los IDs de volumen a algún lado. Tus siguientes pasos son validar cada ID de almacenamiento y cada objeto de volumen.

Tarea 2: Comprobar el estado del almacenamiento en Proxmox (activo, habilitado, tipos de contenido)

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      98420640        21053440        72278144   21.39%
local-lvm        lvmthin  active      402653184       187904000       214749184   46.67%
tank             zfspool  active      1099511627776   603979776000   495531851776   54.93%

Significado: los storages están “active”. Si tu VM aún no puede arrancar, probablemente tratemos con volúmenes faltantes, permisos o casos de activación, no con una definición de almacenamiento deshabilitada.

Decisión: si un almacenamiento muestra inactive o falta, arregla eso antes de tocar la config de la VM.

Tarea 3: Validar que la configuración de almacenamiento existe y no ha derivado

cr0x@server:~$ grep -nE '^(dir|lvmthin|zfspool|rbd|lvm|nfs|iscsi):|^content|^path|^pool|^vgname|^monhost|^nodes' /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup
lvmthin: local-lvm
        thinpool data
        vgname pve
        content images,rootdir
zfspool: tank
        pool tank
        content images,rootdir

Significado: los IDs de almacenamiento coinciden con lo que la config de la VM referencia. Si la VM referencia un ID que no aparece aquí, Proxmox tratará los volúmenes como inexistentes.

Decisión: si el ID de almacenamiento está equivocado en la config de la VM, arregla la config (con cuidado) en lugar de “crear un almacenamiento con ese nombre” apuntando a otro lado.

Tarea 4: Pedir a Proxmox que liste el volumen referenciado (independiente del backend)

cr0x@server:~$ pvesm list local-lvm --vmid 101
Volid                          Format  Type              Size VMID
local-lvm:vm-101-disk-0         raw     images     85899345920 101

Significado: Proxmox puede ver el objeto de disco vía su plugin de almacenamiento. Eso sugiere fuertemente que el disco existe y es descubrible.

Decisión: si el disco lista aquí pero la VM no arranca, busca permisos/bloqueos, mapeos de dispositivo obsoletos o errores en QEMU, no “disco faltante”.

Tarea 5: Intentar listar un volumen que Proxmox afirma que falta

cr0x@server:~$ pvesm path tank:vm-101-disk-1
pvesm: volume 'tank:vm-101-disk-1' does not exist

Significado: a nivel de abstracción de Proxmox, ese ID de volumen no está presente en la vista del plugin de almacenamiento.

Decisión: pivota a comprobaciones del backend (lista de ZFS). No edites aún la config de la VM; el disco podría existir con un nombre ligeramente distinto o en otro pool.

Tarea 6: Backend ZFS: confirmar que el pool esté importado y saludable

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: la salud del pool no es tu bloqueo inmediato.

Decisión: continúa: lista datasets/zvols; buscamos un desajuste de nombres o un volumen movido.

Tarea 7: Backend ZFS: buscar el zvol faltante

cr0x@server:~$ zfs list -t volume -o name,volsize,used,refer,origin | grep -E 'vm-101|101-disk|disk-1' || true
tank/vm-101-disk-0   80G   12G  12G  -
tank/vm-102-disk-1  200G   68G  68G  -

Significado: el esperado tank/vm-101-disk-1 no está. Pero ves algo sospechoso: tank/vm-102-disk-1 existe y tiene exactamente el tamaño que esperabas para el segundo disco de la VM 101.

Decisión: investiga si los discos fueron adjuntados al VMID equivocado o renombrados. Aquí es donde “config vs almacenamiento” se vuelve un ejercicio forense.

Tarea 8: Cruzar qué configuración de VM referencia el volumen sospechoso

cr0x@server:~$ grep -R --line-number "tank:vm-102-disk-1" /etc/pve/qemu-server/*.conf
/etc/pve/qemu-server/102.conf:6:scsi1: tank:vm-102-disk-1,size=200G

Significado: la VM 102 lo referencia, así que probablemente esté legítimamente adjunto allí. Pero “probablemente” no es un plan.

Decisión: si el disco de la VM 101 falta y la VM 102 tiene un disco extra que “parece” ser el correcto, verifica mediante identificadores dentro del guest (UUIDs de sistema de archivos, datos de la aplicación) antes de volver a adjuntar nada.

Tarea 9: Backend LVM-thin: confirmar que VG y thinpool existen

cr0x@server:~$ vgs; lvs -a -o vg_name,lv_name,lv_attr,lv_size,pool_lv,data_percent,metadata_percent
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1  12   0 wz--n- 372.51g  1.00g
  VG   LV                Attr       LSize   Pool      Data%  Meta%
  pve  data              twi-aotz-- 350.00g           62.15  11.02
  pve  vm-101-disk-0      Vwi-aotz--  80.00g data     15.63

Significado: vm-101-disk-0 existe en LVM-thin y está activo. La utilización de datos/metadata no es alarmante aquí. Si la metadata está al 99% y la activación de LV falla, a menudo verás dispositivos faltantes como síntoma.

Decisión: si el thinpool data no está activo o la metadata está llena, arregla la salud del thinpool antes de intentar “recrear” volúmenes.

Tarea 10: Almacenamiento por directorio: detectar la trampa del “punto de montaje vacío”

cr0x@server:~$ mount | grep -E '/mnt/pve|nfs|cifs' || true
server-nfs:/export/pve-images on /mnt/pve/nfs-images type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

cr0x@server:~$ ls -lah /mnt/pve/nfs-images/images/101/ | head
total 80G
drwxr-xr-x 2 root root 4.0K Dec 26 01:50 .
drwxr-xr-x 3 root root 4.0K Dec 26 01:50 ..
-rw-r----- 1 root root 80G Dec 26 01:49 vm-101-disk-0.qcow2

Significado: el montaje existe y el directorio esperado contiene el disco. Si la salida de mount está vacía pero el directorio sigue existiendo, podrías estar viendo contenidos del disco local, no tu export NFS.

Decisión: si falta el montaje, detén la VM inmediatamente si está escribiendo en el lugar equivocado. Vuelve a montar y reconcilia qué copia es la autorizada.

Tarea 11: Comprobar bloqueos que hacen que un disco parezca “inutilizable”

cr0x@server:~$ qm status 101
status: stopped

cr0x@server:~$ qm config 101 | grep -E '^lock:|^scsi|^virtio|^sata|^ide'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G

Significado: no se muestra línea de lock. Si ves lock: backup o lock: migrate, Proxmox puede bloquear operaciones y los usuarios lo interpretan como “disco faltante”. No está faltando; está protegido.

Decisión: elimina locks solo después de confirmar que no hay realmente un backup/migración en curso. Quitar un lock real a mitad de operación es la forma de ganarte tu próximo outage.

Tarea 12: Arrancar la VM para capturar el mensaje real de error (no te fíes de resúmenes en la interfaz)

cr0x@server:~$ qm start 101
kvm: -drive file=/dev/zvol/tank/vm-101-disk-1,if=none,id=drive-scsi1,format=raw,cache=none,aio=io_uring: Could not open '/dev/zvol/tank/vm-101-disk-1': No such file or directory
start failed: QEMU exited with code 1

Significado: QEMU intenta abrir una ruta de zvol y no existe. Esto confirma que no es un “problema de interfaz”. El objeto del backend falta o fue renombrado.

Decisión: encuentra el nombre real del zvol (Tarea 7) o restaúralo; no inventes un disco en blanco con el mismo nombre a menos que disfrutes de la pérdida irreversible de datos.

Tarea 13: Buscar en logs eventos de borrado/renombrado y errores de almacenamiento

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pvesm -u pveproxy --since "24 hours ago" | tail -n 40
Dec 26 01:41:12 server pvedaemon[2210]: update VM 101: moved disk scsi1 to tank
Dec 26 01:41:15 server pvedaemon[2210]:  end task UPID:server:000008A2:0000F1A3:676C3B6B:qmmove:101:root@pam: OK
Dec 26 02:10:33 server pvedaemon[2210]:  start task UPID:server:00000B11:00012A3D:676C4BE9:qmstart:101:root@pam:
Dec 26 02:10:34 server pvedaemon[2210]: command 'qmstart 101' failed: exit code 1

Significado: tienes una pista: alguien movió el disco recientemente. “Move disk to tank” tuvo éxito, pero ahora el zvol falta. Eso sugiere una eliminación posterior, un rollback o un cambio de pool.

Decisión: correlaciona con el historial de ZFS, eventos de rollback del almacenamiento o acciones de operadores alrededor de 01:41–02:10.

Tarea 14: Historial de ZFS (si está habilitado) para captar destroy/rename

cr0x@server:~$ zpool history tank | tail -n 20
2025-12-26.01:41:13 zfs create -V 214748364800 tank/vm-101-disk-1
2025-12-26.01:41:14 zfs set volblocksize=16K tank/vm-101-disk-1
2025-12-26.01:58:02 zfs destroy tank/vm-101-disk-1

Significado: se creó y luego se destruyó. Esto ya no es “misteriosamente desaparecido”. Es “eliminado”, que es muy diferente.

Decisión: deja de intentar arrancar la VM; procede a restaurar desde snapshot/backup o a opciones de recuperación ZFS (según tu política).

Tarea 15: Backend Ceph RBD: verificar presencia de imagen y permisos

cr0x@server:~$ ceph -s
  cluster:
    id:     7d2a2f1c-1a11-4f2b-bc1a-0c3f0c0d0d0d
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   2 pools, 128 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 20 TiB / 33 TiB avail

cr0x@server:~$ rbd -p rbd ls | grep -E 'vm-101-disk-0|vm-101-disk-1' || true
vm-101-disk-0

Significado: el cluster está healthy, pero solo una imagen existe. Si Proxmox espera una segunda, no arrancará. Esto también puede pasar si usas el nombre de pool equivocado o faltan namespaces en RBD.

Decisión: valida storage.cfg para el pool/namespace correcto; verifica qué nodo tiene el keyring y las caps adecuadas.

Tarea 16: Confirmar que Proxmox resuelve la ruta del disco (sanidad del plugin de almacenamiento)

cr0x@server:~$ pvesm path local-lvm:vm-101-disk-0
/dev/pve/vm-101-disk-0

Significado: Proxmox puede resolver el ID de volumen a una ruta de dispositivo bloque real. Si QEMU aún falla, el error probablemente sea permisos, nodos de dispositivo obsoletos o mapeo en el kernel.

Decisión: comprueba si el nodo de dispositivo existe y es accesible, y si la activación de LVM es consistente.

Tarea 17: Verificar que el nodo de dispositivo bloque exista y tenga permisos sensatos

cr0x@server:~$ ls -lah /dev/pve/vm-101-disk-0
lrwxrwxrwx 1 root root 7 Dec 26 00:02 /dev/pve/vm-101-disk-0 -> ../dm-12

cr0x@server:~$ ls -lah /dev/dm-12
brw-rw---- 1 root disk 253, 12 Dec 26 00:02 /dev/dm-12

Significado: el dispositivo existe. Si faltara, verías “No such file” y te centrarías en la activación de LVM y en udev.

Decisión: si faltan nodos de dispositivo, ejecuta pasos de activación de LVM e investiga por qué no aparecieron (VG no encontrado, multipath, sesión iSCSI caída).

Tarea 18: Encontrar mapeos obsoletos para rutas de dispositivos ZFS zvol

cr0x@server:~$ ls -lah /dev/zvol/tank/ | head
total 0
drwxr-xr-x 2 root root  80 Dec 26 01:41 .
drwxr-xr-x 4 root root  80 Dec 26 01:41 ..
lrwxrwxrwx 1 root root  13 Dec 26 01:41 vm-101-disk-0 -> ../../../zd0

Significado: el zvol faltante realmente no está presente; de lo contrario verías un symlink para él. Esto se alinea con el error de QEMU de la Tarea 12.

Decisión: no “toques” la config de la VM. Tu solución es: restaurar el zvol (desde snapshot/backup) o volver a adjuntar el zvol correcto si fue renombrado.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: Incidente causado por una suposición errónea

Una empresa SaaS de tamaño medio corría un clúster Proxmox donde “local-lvm” existía en cada nodo, pero no de forma idéntica. En papel, era “el mismo nombre de VG en todas partes”, que es de esas afirmaciones que suenan verdad hasta que preguntas qué significa.

Una VM se migró del Nodo A al Nodo B tras una alarma de hardware. Proxmox actualizó la configuración de la VM y la VM arrancó. Una semana después, el disco “desapareció” tras un reboot. Se desató el pánico. El equipo de almacenamiento culpó a Proxmox. El administrador de Proxmox culpó al almacenamiento. Dueto clásico.

La suposición equivocada: “Si el ID de almacenamiento es el mismo, el contenido del almacenamiento es el mismo.” En el Nodo B, “local-lvm” apuntaba a un VG distinto que en el Nodo A debido a una reconstrucción anterior. Funcionó brevemente porque la VM había estado corriendo y los dispositivos de bloque permanecieron mapeados hasta el reinicio. Al reiniciar, la activación del LV no encontró el volumen esperado.

La solución no fue heroica: estandarizaron nombres de VG e IDs de almacenamiento, y dejaron de usar una etiqueta compartida para almacenamiento no compartido. La causa raíz fue una colisión de nombres. La lección: un ID de almacenamiento en Proxmox no es una promesa de semántica compartida. Es una cadena en un archivo de configuración.

Microhistoria 2: La optimización que salió mal

Un equipo de plataforma interno de una empresa introdujo un trabajo programado que podaba agresivamente “volúmenes ZFS antiguos” que coincidían con un patrón usado para VMs de prueba temporales. Era una solución ordenada. También era incorrecta.

Una VM de producción se había movido recientemente de LVM-thin a ZFS. Durante el movimiento, un humano renombró un disco para ajustar convenciones internas—desafortunadamente, esas convenciones se solapaban con el patrón “temporal”. La VM funcionó dos días, hasta que el job de poda hizo lo que se le ordenó y destruyó el zvol.

El incidente se presentó como “disco desaparecido”. Proxmox no mentía; el disco había sido eliminado. La primera reacción del equipo fue recrear un zvol vacío con el mismo nombre para que la VM arrancara. Eso habría sido una forma rápida de asegurarse de que nunca funcionaran las forenses o la recuperación. Alguien los detuvo.

Restauraron desde backups y luego arreglaron la política: los jobs de eliminación ahora comprueban referencias en /etc/pve/qemu-server antes de destruir nada. Además, los nombres de disco dejaron de ser texto libre. “Optimización” es otra palabra para “introducir un nuevo modo de fallo”, a menos que añadas salvaguardas.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una organización financiera ejecutaba Proxmox con Ceph RBD para discos de VM y tenía una regla estricta: cada ticket de cambio de almacenamiento incluía un “paso de prueba” equivalente a una captura de pantalla—salidas de pvesm status, qm config y un listado del backend (rbd ls o zfs list) antes y después.

Era burocrático. La gente puso los ojos en blanco. Pero también significó que siempre había un pequeño rastro de verdad objetiva. Un día, un nodo se reinició tras actualizaciones de kernel y varias VMs se negaron a arrancar con “unable to find volume”. El on-call sacó el último ticket de cambio y comparó las salidas antes/después. Las configs de VM referenciaban ceph-ssd, pero storage.cfg ahora listaba ceph_ssd debido a un renombrado bienintencionado para ajustar un estándar de nombres.

Los discos nunca se movieron. Ceph estaba bien. Solo cambió la etiqueta del ID de almacenamiento, rompiendo todas las referencias. Revirtieron el nombre del ID de almacenamiento, recargaron y todo volvió a funcionar.

Nada elegante. No hubo recuperación de datos. No hubo adivinanzas. Solo evidencia disciplinada de cambios que hizo obvio el fallo. Las prácticas aburridas no ganan premios. Ganan disponibilidad.

Errores comunes: síntoma → causa raíz → arreglo

1) “Volume does not exist” justo después de renombrar un almacenamiento

Síntoma: las configs de VM referencian old-storage:vm-XXX-disk-Y; pvesm status no muestra old-storage.

Causa raíz: se cambió el ID de almacenamiento en /etc/pve/storage.cfg pero las configs de VM no se actualizaron.

Arreglo: revierte el nombre del ID de almacenamiento o actualiza las configs de VM al nuevo ID (solo si el backend es verdaderamente el mismo). Luego verifica con pvesm list y qm start.

2) Archivos QCOW2 faltantes tras un fallo de NFS

Síntoma: archivos “desaparecen” de /mnt/pve/nfs-*; el directorio existe pero está vacío; luego reaparecen.

Causa raíz: el montaje cayó; el host escribió en el directorio local; el remount ocultó los archivos locales.

Arreglo: vuelve a montar correctamente y reconcilia duplicados. Confirma con mount y compara IDs de inode/dispositivo. Prevén usando unidades de systemd con dependencias fuertes y monitorizando stale file handle.

3) Pool ZFS importado en un nodo pero no en otro (confusión de clúster)

Síntoma: la VM arranca en el Nodo A pero no en el Nodo B; Nodo B indica ruta de zvol faltante.

Causa raíz: pool ZFS local no importado en Nodo B; la config de Proxmox asume compartido pero no lo es.

Arreglo: importa el pool en el nodo correcto o deja de tratarlo como almacenamiento compartido. Usa el tipo de almacenamiento correcto y restricción de nodos en storage.cfg.

4) LVM-thin “LV faltante” durante agotamiento de metadata de thinpool

Síntoma: el LV parece faltar, la VM no arranca; metadata del thinpool cerca del 100%.

Causa raíz: el thinpool no puede asignar metadata; la activación del LV falla; pueden no aparecer nodos de dispositivo.

Arreglo: extiende el LV de metadata, reduce snapshots, ejecuta reparación del thinpool según corresponda. Luego reactiva VGs y reintenta.

5) “Permission denied” parece disco faltante

Síntoma: QEMU no puede abrir archivo/dispositivo; la interfaz reporta disco inaccesible.

Causa raíz: propietario/modo incorrecto en almacenamiento por directorio, AppArmor/SELinux, o ACLs rotas en NFS.

Arreglo: corrige permisos, asegura que Proxmox esté configurado para el tipo de almacenamiento y vuelve a probar con pvesm path y ls -l.

6) Disco existe pero con otro nombre (renombrado humano)

Síntoma: la config de VM referencia vm-101-disk-1 pero el backend tiene vm-101-data u otro nombre de disco de VMID diferente.

Causa raíz: renombre manual en el backend o durante migración/restore.

Arreglo: verifica el volumen correcto por tamaño, tiempo de creación, linaje de snapshots e identificadores dentro del guest; luego actualiza la config de la VM al ID real del volumen.

7) Backups restaurados al ID de almacenamiento equivocado

Síntoma: el trabajo de restore “vence”, pero la VM no arranca porque referencia un disco en un almacenamiento que no lo contiene.

Causa raíz: el almacenamiento objetivo difiere del original; la config no se reescribió como se esperaba.

Arreglo: restaura con mapeo explícito de almacenamiento y luego confirma con qm config y pvesm list.

8) Ceph parece bien, pero imagen RBD “falta” para Proxmox

Síntoma: ceph -s está OK; Proxmox no puede listar imágenes o no puede abrir una.

Causa raíz: pool/namespace equivocado en storage.cfg, keyring faltante en ese nodo o caps insuficientes.

Arreglo: valida storage.cfg, confirma que el keyring existe en el nodo, prueba rbd -p POOL ls como root y bajo el mismo entorno que usa Proxmox.

Segundo chiste corto: El almacenamiento es como el cotilleo—una vez que un mal nombre sale (ID de almacenamiento equivocado), todos lo repiten hasta que corriges la fuente.

Listas de verificación / plan paso a paso

Paso a paso: cuando una VM no arranca por un disco faltante

1. Congela la escena. Si la VM está caída, mantenla caída hasta saber si tratas con eliminación vs mapeo. Si está en ejecución pero reporta disco faltante al reiniciar, no reinicies otra vez.
2. Extrae referencias de disco. Lee /etc/pve/qemu-server/<vmid>.conf. Registra cada línea de disco y ID de volumen.
3. Verifica que los IDs de almacenamiento existan y estén activos. pvesm status. Si está inactive, arregla el almacenamiento primero (montaje, import pool, red).
4. Listado a nivel Proxmox. pvesm list <storage> --vmid <vmid>. Si lista el volumen, tu “disco faltante” probablemente no esté faltando.
5. Listado a nivel backend. ZFS: zfs list -t volume. LVM: lvs. Directorio: find el archivo. Ceph: rbd ls.
6. Si hay desajuste: busca coincidencias próximas. Grep en configs de VM por nombres similares; comprueba attachments a VMID erróneos.
7. Revisa logs. journalctl para tareas de move/delete; historial de ZFS o logs de Ceph cuando sea posible.
8. Elige modo de recuperación.
   • Puntero equivocado: actualiza config de VM o re-importa volumen.
   • Almacenamiento inaccesible: restaura acceso al almacenamiento.
   • Volumen eliminado: restaura desde backup/snapshot; considera recuperación ZFS si la política lo permite.
9. Valida antes de arrancar. Asegúrate de que pvesm path <volid> funcione para cada disco en la config.
10. Arranca una vez y observa la salida. qm start desde CLI; captura el error completo si falla.
11. Limpieza post-incidente. Documenta qué capa falló (config o almacenamiento) y añade un monitor/salvaguarda.

Lista: qué NO debes hacer bajo presión

• No crees un disco vacío nuevo con el mismo nombre “para que arranque”. Así borras la evidencia y garantizas pérdida de datos.
• No renombres IDs de almacenamiento a la ligera. Si debes hacerlo, planifica una actualización masiva de configs de VM y valida con un ensayo.
• No supongas que almacenamiento “activo” significa “correcto”. Un montaje NFS puede estar activo pero apuntando al export equivocado.
• No trates almacenamiento local como compartido. Si el pool/VG existe solo en un nodo, restríngelo a ese nodo.
• No quites locks a ciegas. Los locks suelen ser lo único que te impide empeorar la situación.

Lista: prevención que realmente funciona

• Estandariza IDs de almacenamiento y hazlos cumplir mediante revisión. Los nombres son una dependencia.
• Monitoriza la presencia de montajes y la “corrección del montaje” (ID de dispositivo, no solo existencia del directorio).
• Alerta en fallos de importación de pools ZFS y en uso de metadata de thinpool LVM.
• Ejecuta una auditoría nocturna: para cada volid de disco de VM, verifica que exista en el backend y sea resolvible vía pvesm path.
• Requiere evidencia de cambio (salidas antes/después) para operaciones de almacenamiento: mover, renombrar, borrar, cambiar pools.

Preguntas frecuentes

1) ¿Cómo sé si es problema de configuración o de almacenamiento?

Si pvesm list no puede ver el volumen y el listado del backend tampoco lo ve, es realidad del almacenamiento/objeto. Si el backend lo muestra pero Proxmox no lo resuelve, es un desajuste de configuración/definición de almacenamiento.

2) La config de VM referencia local-lvm, pero pvesm status lo muestra inactive. ¿Qué es más rápido?

Arregla la activación del almacenamiento primero: confirma que el VG exista y sea visible. Editar la config de la VM para apuntar a otro sitio suele ser un parche corto que se convierte en corrupción a largo plazo.

3) ¿Puedo editar directamente /etc/pve/qemu-server/<vmid>.conf?

Sí, pero hazlo como un adulto: haz una copia, cambia una cosa y valida con qm config y pvesm path. Recuerda además que /etc/pve está gestionado por el clúster.

4) Veo un zvol como tank/vm-101-disk-1, pero Proxmox dice que no existe.

Normalmente es un desajuste en storage.cfg (nombre de pool incorrecto), restricción por nodo, o el volumen está en un pool/dataset distinto al que Proxmox espera. Confirma que la definición de almacenamiento apunte al mismo pool y que el nodo tenga acceso.

5) El archivo del disco existe en NFS, pero Proxmox no puede abrirlo.

Revisa opciones de montaje y permisos/propietario. También verifica que no estés mirando un directorio local porque el montaje falló. La salida de mount es el árbitro.

6) ¿Qué significa si una VM arranca en un nodo pero no después de migrar?

Suele significar que el almacenamiento no es realmente compartido o no está definido idénticamente en cada nodo. La migración de Proxmox puede mover la configuración, pero no puede conjurar un VG local en otra máquina.

7) ¿Cuál es la forma más segura de recuperar si el volumen fue eliminado?

Detente, confirma la eliminación (historial de backend/logs), luego restaura desde backup o snapshot. Si tienes snapshots/replicación ZFS, restaura el dataset/zvol y vuelve a adjuntarlo por ID de volumen.

8) ¿Por qué Proxmox a veces muestra el disco en la interfaz pero el arranque aún falla?

Porque listar metadata es más fácil que abrir el dispositivo. Puedes “ver” un ID de volumen, pero QEMU aún puede fallar por permisos, nodos de dispositivo obsoletos, problemas de activación o estados de solo lectura en el backend.

9) ¿Cómo prevengo que un renombrado de almacenamiento rompa VMs?

No renombres IDs de almacenamiento en sitio a menos que planees una actualización coordinada. Si debes hacerlo, actualiza las configs de VM en una ventana de cambio controlada y verifica con pvesm path para cada disco.

10) ¿Existe un comando único que encuentre referencias de disco rotas?

No uno perfecto, pero puedes automatizarlo: iterar VMIDs, parsear líneas de disco y ejecutar pvesm path, y marcar fallos. La ausencia de esa auditoría es por lo que este incidente sigue ocurriendo.

Conclusión: próximos pasos para evitar que se repita

Diagnosticar “VM disk vanished” es mayormente disciplina para no mezclar capas. La configuración de Proxmox es un conjunto de punteros. El almacenamiento son los objetos. Tu trabajo es encontrar el desajuste con pruebas, no con intuiciones.

Próximos pasos que deberías tomar de verdad:

• Implementar una auditoría diaria: para cada volid de disco de VM, verificar que pvesm path lo resuelva y que el objeto backend exista.
• Endurecer montajes e importación de pools: trata la “corrección del montaje” y “pool importado” como SLOs monitorizados, no como suposiciones.
• Control de cambios para IDs de almacenamiento: las ediciones de storage.cfg deben revisarse como código. Los nombres son dependencias.
• Escribe tus reglas de recuperación: “nunca recrear un nombre de disco faltante”, “verificar existencia del backend antes de editar la config”, y “logs primero, reinicio al final”.

El mejor resultado no es una recuperación ingeniosa. Es un incidente aburrido que nunca vuelve a pasar porque hiciste mecánicamente difícil perder la pista de dónde están los discos.