Proxmox “TASK ERROR: timeout waiting for …”: localizar qué se agotó realmente

octubre 6, 2025 • febrero 3, 2026 • Lectura: 31 min • Views: 8

¿Te fue útil?

Hiciste clic en un botón en Proxmox. Iniciar VM. Detener contenedor. Instantánea. Backup. Migración. Y entonces: TASK ERROR: timeout waiting for …. La interfaz te da una frase sustantiva vaga y un reloj que acaba de agotarse. En producción recibes humanos enfadados y un reloj que no para.

La jugada clave es dejar de tratar el “timeout” como el problema. Un timeout en Proxmox es un síntoma: algún proceso estaba esperando un bloqueo específico, un estado del kernel, una operación de almacenamiento o un paso del sistema de archivos de clúster, y no terminó antes de que Proxmox se rindiera. Tu trabajo es identificar en qué estaba esperando realmente y luego arreglar el subsistema que se quedó detenido.

Qué son realmente los timeouts en Proxmox (y por qué la interfaz oculta la verdad)

Proxmox es un gestor. Orquesta muchas piezas en movimiento: servicios systemd, QEMU, LXC, ZFS, Ceph, dispositivos de bloque del kernel, almacenamiento en red y un sistema de archivos de configuración de clúster. Cuando haces clic en “Detener”, Proxmox no apaga una VM por arte de magia. Pide a QEMU con educación, espera que el invitado coopere, tal vez escala a un SIGKILL, luego espera a que se desvinculen los dispositivos de bloque, a que se desemparejen volúmenes y a que se liberen los bloqueos de configuración.

El mensaje “timeout waiting for …” suele emitirse desde una capa Perl de Proxmox (ayudantes de pvedaemon/pveproxy) que espera una transición de estado. Los timeouts varían según la operación, y a menudo protegen contra el peor día en operaciones: una tarea permanentemente atascada que sostiene un bloqueo y bloquea todo lo demás.

Esa es la filosofía. La realidad es desordenada: si el kernel está atrapado en espera de I/O, Proxmox “timeout waiting for…” algo perfectamente razonable, como un unmap de dispositivo, mientras que el problema real es un HBA muerto, una ruta multipath trabada o un OSD de Ceph inestable. Necesitas mapear la frase del registro de la tarea a la cadena de dependencias concreta.

Aquí está el modelo mental que realmente funciona:

Tarea de Proxmox (UPID) se ejecuta como un proceso.
Espera una condición: bloqueo, salida de PID, operación de volumen, actualización de archivo de clúster.
La condición depende de un subsistema: kernel, almacenamiento, red, clúster, S.O. invitado.
El timeout te dice qué condición no se cumplió. Los registros te dicen por qué.

Una verdad operativa: “timeout waiting for…” a menudo es Proxmox diciéndote cortésmente “algo está atascado en estado D y no puedo matarlo”. Si no has buscado el estado D todavía, todavía estás adivinando.

Broma #1 (corta y merecida): Cuando Proxmox dice “timeout waiting for lock”, básicamente es tu datacenter haciendo el baile de la puerta “después de ti”… para siempre.

Guion de diagnóstico rápido: primeras/segundas/terceras comprobaciones que localizan el cuello de botella

Si haces una sola cosa diferente después de leer esto: deja de perseguir la cadena de texto de la interfaz. Parte del UPID, identifica el proceso bloqueante y luego identifica el subsistema por aquello en lo que ese proceso está bloqueado.

Primero: ¿Está enfermo el propio nodo?

Comprueba carga, estado D, presión de memoria y bloqueos de I/O del kernel. Si el nodo está poco saludable, todas las tareas son sospechosas.
Si ves muchos procesos en estado D, trátalo como almacenamiento hasta que se demuestre lo contrario.

Segundo: ¿Es I/O de almacenamiento, plano de control de almacenamiento o bloqueo de clúster?

Plano de datos de almacenamiento: lecturas/escrituras lentas, unmap colgado, flushes detenidos, resets SCSI.
Plano de control de almacenamiento: monitores Ceph lentos, grupos de transacciones ZFS atascados, sesiones iSCSI intermitentes.
Bloqueo de clúster: contención de pmxcfs o una tarea muerta sosteniendo un archivo de bloqueo.

Tercero: ¿Es un invitado que se niega a cooperar?

Los timeouts de apagado de VM a menudo son solo un invitado ignorando ACPI.
Pero si el apagado se bloquea al separar dispositivos, sigue siendo almacenamiento/anfitrión.

Lista de verificación de triaje rápido (qué ejecutar inmediatamente)

Encuentra el UPID en la vista de tareas; compáralo con líneas de registro en /var/log/pve/tasks/.
Identifica el PID y el punto exacto de espera (bloqueo vs I/O vs salida de proceso).
Revisa dmesg por resets/timeout de almacenamiento en la misma ventana temporal.
Comprueba la salud de Ceph o ZFS (según el backend).
Verifica el quórum del clúster y la capacidad de respuesta de pmxcfs si la configuración/bloqueos están implicados.

Mapear “waiting for …” al subsistema real

Las cadenas “waiting for …” de Proxmox no son aleatorias. Normalmente corresponden a una de estas categorías:

1) Esperando un bloqueo (serialización de configuración y ciclo de vida)

Frases comunes: “timeout waiting for lock”, “can’t lock file”, “lock for VM …”, “lock for storage …”.

Qué se agotó realmente: una adquisición de bloqueo en Proxmox (a menudo bajo /var/lock/pve-manager/ o un bloqueo dentro de pmxcfs), o un bloqueo sostenido por otra tarea que nunca terminó.

Causas probables: una tarea previa colgada (a menudo por almacenamiento), o pmxcfs lento/no responde por problemas de clúster.

2) Esperando la salida de un proceso (ciclo de vida QEMU/LXC)

Frases comunes: “timeout waiting for VM to shutdown,” “timeout waiting for ‘qemu’ to stop,” “timeout waiting for CT to stop”.

Qué se agotó realmente: Proxmox envió una petición de apagado/parada y esperó a que QEMU/LXC saliera; no lo hizo. QEMU puede estar atascado en I/O del kernel, el invitado puede ignorar el apagado o QEMU está en pausa esperando almacenamiento.

3) Esperando operaciones de almacenamiento (crear/destruir/snapshot/clone/unmap)

Frases comunes: “timeout waiting for RBD unmap,” “timeout waiting for zfs destroy,” “timeout waiting for lvremove,” “timeout waiting for qm” (durante operaciones de disco), “timeout waiting for vzdump”.

Qué se agotó realmente: un comando de almacenamiento (rbd, zfs, lvm, iscsiadm, mount) no finalizó. Aquí es donde el kernel y el backend de almacenamiento se encuentran — y discuten.

4) Esperando actualizaciones del sistema de archivos de clúster (pmxcfs)

Frases comunes: “timeout waiting for pmxcfs,” “unable to read/write /etc/pve/…,” “cfs-lock ‘…’ timed out”.

Qué se agotó realmente: pmxcfs no pudo completar un bloqueo o una actualización con suficiente rapidez. Las causas raíz incluyen corosync/quórum inestables, CPU saturada o disco lleno impidiendo escrituras (sí, en serio).

5) Esperando red (migración y almacenamiento remoto)

Frases comunes: “migration aborted: timeout,” “waited too long for …,” “ssh connection timeout” (a veces oculto detrás de timeouts genéricos de tareas).

Qué se agotó realmente: TCP estancado, desajuste de MTU, pérdida de paquetes o el extremo remoto bloqueado por almacenamiento.

Diseccionar la tarea de Proxmox: del UPID al syscall que bloquea

Las tareas de Proxmox se registran con un UPID (Unique Process ID) que codifica nodo, PID, hora de inicio y tipo de tarea. Tu flujo de trabajo debe tratar al UPID como la clave primaria.

Aquí hay una forma práctica de cortar el ruido:

Encuentra el UPID en el registro de tareas de la GUI.
Abre el archivo de la tarea en el nodo para ver los pasos internos exactos y marcas temporales.
Encuentra el PID del worker y examina su estado (ejecutando, D-state, bloqueado).
Usa herramientas a nivel kernel (trazas de pila, estadísticas de I/O) para ver en qué está esperando.

Si solo lees el mensaje de alto nivel de Proxmox, te perderás la parte donde el kernel ha estado gritando “SCSI timeout” durante diez minutos en dmesg.

Una cita, porque sigue siendo la estrella polar para operaciones: “Hope is not a strategy.” — General Gordon R. Sullivan

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Estos no son comandos “bonitos de saber”. Son los que ejecutas mientras alguien espera una restauración, tu HA está inestable y necesitas decidir si reinicias un nodo o sigues un cable.

Tarea 1: Encuentra el archivo de registro UPID de la tarea y léelo como una línea temporal

cr0x@server:~$ ls -1t /var/log/pve/tasks/ | head
active
index
UPID:pve01:0000A1B2:019F3A2C:676D3B1C:vzdump:101:root@pam:
UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:

cr0x@server:~$ sed -n '1,120p' /var/log/pve/tasks/UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
starttime 1735163817
status: started
command: /usr/sbin/qm shutdown 104 --timeout 60
shutdown VM 104: initiated
shutdown VM 104: waiting for guest to shutdown...
shutdown VM 104: timeout waiting for shutdown
TASK ERROR: timeout waiting for shutdown

Significado: Ahora sabes el comando exacto y el parámetro de timeout implicado (qm shutdown --timeout 60).

Decisión: Si este es un invitado que no responde a ACPI, puedes escalar a qm stop. Si ocurre repetidamente y coincide con errores de almacenamiento, diagnostica el I/O del host primero.

Tarea 2: Correlaciona las marcas temporales de la tarea de Proxmox con los registros del journal

cr0x@server:~$ journalctl -u pvedaemon -S "2025-12-26 09:30:00" -U "2025-12-26 09:40:00" --no-pager | tail -n 40
Dec 26 09:33:22 pve01 pvedaemon[1412]: starting task UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
Dec 26 09:34:22 pve01 pvedaemon[1412]: task UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam: finished with exit code 255

Significado: Confirma qué demonio lo ejecutó y cuándo falló.

Decisión: Si pvedaemon se agota repetidamente en múltiples tareas, mira la salud del nodo y el almacenamiento en lugar de las VMs individuales.

Tarea 3: Identifica si el proceso worker está atascado (y en qué estado)

cr0x@server:~$ ps -eo pid,ppid,stat,wchan:24,cmd | egrep 'pvedaemon|pveworker|qmshutdown|vzdump' | head -n 20
1412     1 Ss   ep_poll                  /usr/bin/pvedaemon
9856  1412 S    do_wait                  pveworker UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
9874  9856 D    io_schedule              /usr/bin/qemu-system-x86_64 -id 104 -name vm104

Significado: QEMU está en estado D (D en STAT) y esperando en io_schedule. Eso no es “el invitado no quiere apagarse”. Es “el kernel del host está esperando I/O”.

Decisión: Deja de intentar matar QEMU. Investiga almacenamiento y registros del kernel. Un reinicio puede ser la única salida si el kernel no puede completar el I/O.

Tarea 4: Revisa dmesg por timeouts/reset de almacenamiento alrededor de la falla

cr0x@server:~$ dmesg -T | egrep -i 'timed out|reset|abort|blk_update_request|I/O error|nvme|scsi' | tail -n 30
[Thu Dec 26 09:33:51 2025] sd 2:0:0:1: rejecting I/O to offline device
[Thu Dec 26 09:33:51 2025] blk_update_request: I/O error, dev sdb, sector 9412896 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 09:33:52 2025] scsi host2: sas: task abort: SUCCESS scmd(0x00000000a1b2c3d4)
[Thu Dec 26 09:33:58 2025] sd 2:0:0:1: timing out command, waited 180s

Significado: Esta es la prueba definitiva de “qué se agotó realmente”: la capa de bloque del kernel no pudo completar el I/O. Proxmox solo estaba esperando.

Decisión: Trátalo como incidente de almacenamiento: revisa cableado/HBA/rutas, multipath, salud del array y considera evacuar VMs.

Tarea 5: Determina si pmxcfs (/etc/pve) está lento o bloqueado

cr0x@server:~$ timeout 3 ls -la /etc/pve/nodes/pve01/qemu-server/ | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 26 09:35 .
drwxr-xr-x 4 root www-data 0 Dec 26 09:20 ..
-rw-r----- 1 root www-data 0 Dec 26 09:35 104.conf

Significado: Si esto cuelga o expira, tu sistema de archivos de clúster está enfermo. Cuando ls en /etc/pve se cuelga, muchos errores “timeout waiting for lock” son ruido secundario.

Decisión: Revisa corosync/quórum, el proceso pmxcfs y la saturación de recursos del nodo antes de tocar operaciones de VM.

Tarea 6: Revisa quórum y estado de corosync (timeouts a nivel de clúster)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 09:36:01 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.98
Quorate:          Yes

Significado: Si Quorate: No o los nodos fluctúan, los bloqueos pmxcfs pueden trabarse o fallar.

Decisión: Estabiliza la red del clúster antes de fiarte de cualquier diagnóstico “timeout waiting for lock”.

Tarea 7: Identifica qué bloqueo está sostenido y por qué tarea

cr0x@server:~$ ls -la /var/lock/pve-manager/ | head
total 0
drwxr-xr-x 2 root root 120 Dec 26 09:36 .
drwxr-xr-x 9 root root 180 Dec 26 08:10 ..
-rw-r--r-- 1 root root   0 Dec 26 09:31 lock-104.conf
-rw-r--r-- 1 root root   0 Dec 26 09:33 vzdump-101.lock

cr0x@server:~$ fuser -v /var/lock/pve-manager/lock-104.conf
                     USER        PID ACCESS COMMAND
/var/lock/pve-manager/lock-104.conf:
                     root       9856 F.... pveworker

Significado: El bloqueo no es místico. Es un archivo, y un PID lo mantiene abierto.

Decisión: Investiga por qué ese PID está atascado. Matar al worker puede liberar el bloqueo, pero si está en estado D no lo matarás. Arregla el I/O subyacente o planea un reinicio del nodo.

Tarea 8: Inspecciona un PID atascado con trazas de pila del kernel (avanzado, decisivo)

cr0x@server:~$ cat /proc/9874/stack
[<0>] io_schedule+0x12/0x40
[<0>] bit_wait_io+0x11/0x60
[<0>] __wait_on_bit+0x6a/0x90
[<0>] out_of_line_wait_on_bit+0x8a/0xb0
[<0>] __filemap_fdatawait_range+0xd3/0x120
[<0>] filemap_write_and_wait_range+0x4a/0x90
[<0>] blkdev_fsync+0x2e/0x50
[<0>] vfs_fsync_range+0x4a/0xb0

Significado: QEMU está bloqueado esperando que complete un flush/fsync. Eso es almacenamiento. Posiblemente el dispositivo de respaldo está colgado, saturado o hay un proceso de fencing en curso.

Decisión: Deja de ajustar timeouts de apagado de invitados. Ve a arreglar la ruta de almacenamiento o el backend.

Tarea 9: Si usas ZFS, revisa la salud del pool y busca fuentes de latencia

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:10:12 with 0 errors on Thu Dec 26 03:10:21 2025
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda2    ONLINE       0     0     0
            sdb2    ONLINE       0     0     0

errors: No known data errors

cr0x@server:~$ zpool iostat -v rpool 1 5
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool       92.3G   380G     12    420   1.2M  48.9M
  mirror    92.3G   380G     12    420   1.2M  48.9M
    sda2        -      -      6    210   600K  24.4M
    sdb2        -      -      6    210   600K  24.5M

Significado: zpool status te dice si estás degradado/fallado; zpool iostat muestra si estás machacando el pool. No todos los cuelgues aparecen como DEGRADED—la latencia puede ser horrible aún en pools “ONLINE”.

Decisión: Si iostat muestra escrituras altas y tus tareas implican snapshots/destroys, considera contención (ventana de backups, replicación, scrub) y limita o reprograma.

Tarea 10: Si usas Ceph, revisa la salud del clúster y las slow ops

cr0x@server:~$ ceph -s
  cluster:
    id:     3c9f3a2c-1111-2222-3333-019f39f0abcd
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 87 sec, mon.pveceph01 has slow ops

  services:
    mon: 3 daemons, quorum pveceph01,pveceph02,pveceph03 (age 6h)
    mgr: pveceph01(active, since 6h)
    osd: 9 osds: 9 up (since 6h), 9 in (since 6h)

  data:
    pools:   2 pools, 256 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   14 TiB used, 18 TiB / 32 TiB avail
    pgs:     255 active+clean, 1 active+undersized+degraded

cr0x@server:~$ ceph health detail | head -n 40
HEALTH_WARN 12 slow ops, oldest one blocked for 87 sec, mon.pveceph01 has slow ops
SLOW_OPS 12 slow ops, oldest one blocked for 87 sec, osd.4 has slow ops
    slow ops on osd.4, oldest one blocked for 87 sec, committed, flags = none

Significado: Las slow ops son tu “qué se agotó realmente”. Proxmox espera una operación RBD; Ceph está atascado en completarla.

Decisión: Deja de reintentar tareas de Proxmox. Estabiliza Ceph: revisa latencia de OSD, presión de backfill/recovery, red y discos fallando.

Tarea 11: Si usas iSCSI/multipath, verifica sesiones y salud de rutas

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2001-05.com.example:storage.lun1 (non-flash)
tcp: [2] 10.10.20.51:3260,1 iqn.2001-05.com.example:storage.lun1 (non-flash)

cr0x@server:~$ multipath -ll | head -n 60
mpatha (3600a098038314b6d4a2b4b6f6f4b6d31) dm-3 EXAMPLE,Array
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 3:0:0:1 sdc 8:32 active ready running

Significado: Si faltan sesiones o las rutas muestran failed/faulty, tus timeouts son el host esperando una ruta muerta. Si ves queue_if_no_path, el I/O puede colgar “cortésmente” en lugar de fallar rápido.

Decisión: Arregla el enrutamiento antes de tocar Proxmox. Considera si las características de multipath son apropiadas para virtualización; colgarse para siempre rara vez es lo que quieres.

Tarea 12: Para NFS/CIFS, comprueba si los montajes están atascados (clásico “todo se cuelga”)

cr0x@server:~$ mount | egrep ' type nfs| type cifs'
10.10.30.10:/exports/vmstore on /mnt/pve/nfs-vmstore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.10.30.21)

cr0x@server:~$ timeout 3 stat /mnt/pve/nfs-vmstore
  File: /mnt/pve/nfs-vmstore
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 0,53	Inode: 2           Links: 15
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-12-26 09:36:10.000000000 +0000
Modify: 2025-12-26 09:33:01.000000000 +0000
Change: 2025-12-26 09:33:01.000000000 +0000
 Birth: -

Significado: Si stat se cuelga, NFS está trabado y tu “timeout waiting for …” es un efecto secundario. Con montajes hard, los procesos pueden quedarse en estado D para siempre esperando al servidor.

Decisión: Arregla el NAS/red primero. Considera opciones de montaje y monitorización para que un filer inestable no congele todo el nodo.

Tarea 13: Confirma si vzdump/backups son el propietario oculto del bloqueo

cr0x@server:~$ pvesh get /nodes/pve01/tasks --limit 5
┌──────────────────────────────────────────────────────────────────────────────┬───────────┬─────────┬────────────┬──────────┬────────────┐
│ upid                                                                         │ user      │ status  │ starttime  │ type     │ id         │
╞══════════════════════════════════════════════════════════════════════════════╪═══════════╪═════════╪════════════╪══════════╪════════════╡
│ UPID:pve01:0000A1B2:019F3A2C:676D3B1C:vzdump:101:root@pam:                   │ root@pam  │ running │ 1735163950 │ vzdump   │ 101        │
│ UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:               │ root@pam  │ error   │ 1735163817 │ qmshutdown│ 104        │
└──────────────────────────────────────────────────────────────────────────────┴───────────┴─────────┴────────────┴──────────┴────────────┘

Significado: Un backup en ejecución puede sostener bloqueos de snapshot o de configuración, o simplemente saturar el almacenamiento y hacer que otras tareas expiren.

Decisión: Si los backups se solapan con tareas operativas, programa mejor o acepta el riesgo. Elige una estrategia deliberadamente.

Tarea 14: Comprueba rápidamente la presión de I/O a nivel de nodo

cr0x@server:~$ iostat -x 1 3
Linux 6.2.16-20-pve (pve01) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11.20    0.00    6.10   42.30    0.00   40.40

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
dm-3             1.2   420.0     9.6  48960.0  85.3   1.9   98.7

Significado: %iowait es enorme; await y %util están altos. Tu nodo está esperando almacenamiento. Los timeouts de Proxmox son solo el mensajero.

Decisión: Limita la carga de trabajo, pausa trabajos pesados, investiga saturación o fallo del backend. Si es un array compartido, coordina con el equipo de almacenamiento (o conviértete en el equipo de almacenamiento).

Modos de fallo específicos de almacenamiento (ZFS, Ceph, iSCSI/NFS)

La mayoría de los incidentes “timeout waiting for …” en Proxmox son incidentes de almacenamiento con ropa de UI de gestión. La UI expira porque el almacenamiento es lento. O está desaparecido. O “más o menos ahí pero no responde”, lo cual es peor.

ZFS: cuando “ONLINE” aún duele

ZFS es estupendo en integridad de datos y bastante honesto sobre fallos. No está obligado a ser rápido cuando le pides operaciones de metadatos costosas mientras además machacas el pool con escrituras de VM.

Patrones de timeout que verás:

Operaciones de snapshot/destroy/clone atascadas por alta presión de TXG o flush lento del dispositivo.
Apagado/parada de VM atascada porque QEMU espera fsync/flush al dispositivo ZVOL de respaldo.
Trabajos de replicación que expiran porque enviar snapshots no puede seguir el ritmo o la red está congestionada.

Qué buscar:

Latencia a nivel de pool: iostat await y zpool iostat throughput.
Presión de ARC y memoria: ZFS consume memoria y tiene opiniones.
Tiempos de sincronización de grupos de transacciones: sincronizaciones largas hacen que todo lo que necesita un sync espere más.

Ceph RBD: el plano de control se convierte en latencia del plano de datos

El truco de Ceph es la fiabilidad distribuida. Su impuesto es que cuando el clúster está poco saludable, incluso operaciones “simples” pueden ralentizarse: mapping/unmapping RBD, snapshots, cambiar tamaño de imagen, flatten, etc.

Patrones de timeout:

“timeout waiting for RBD unmap” durante parada de VM, limpieza de migración o borrado de disco.
Tareas de backup que expiran porque las lecturas son lentas durante recovery/backfill.
Failover HA que parece roto porque las operaciones de almacenamiento están atascadas, no porque HA sea tonta.

Comprobaciones de realidad específicas de Ceph:

Slow ops más antiguas de un minuto no son “ruido normal” en un clúster de VM. Son síntoma de agotamiento de recursos, problemas de red o discos fallando.
Si Ceph está recovery/backfill intensivo, las tareas de Proxmox que esperan respuestas rápidas de almacenamiento expirarán. O ajustas recovery o programas operaciones disruptivas fuera de horas pico.

iSCSI y multipath: la alegría de “queue_if_no_path”

Los fallos iSCSI más dolorosos no son los ruidosos. Son los silenciosos: una ruta muere, multipath encola I/O y cada proceso que toca ese LUN entra en estado D. Proxmox no lo sabe. Espera que el comando termine. No lo hace.

Si ejecutas virtualización sobre iSCSI, necesitas decidir—explícitamente—si prefieres:

Fallar rápido: las tareas fallan, las VMs fallan o se pausan, pero el nodo es recuperable sin reinicio.
Colgarse para siempre: el plano de datos espera a que el almacenamiento responda, lo que puede congelar tu host.

No dejes que la política por defecto de multipath decida esto por ti. Los valores por defecto los hizo un comité, y los comités no reciben paginación.

NFS: los montajes “hard” también pueden congelar la gestión

Con NFS, una sorpresa común es que el almacenamiento no es solo donde viven los discos; también es donde están backups, plantillas y a veces almacenamiento ISO. Un montaje NFS trabado puede hacer que las tareas de backup se cuelguen, pero también puede bloquear operaciones que intentan listar o actualizar contenido en ese almacenamiento.

Cuando NFS falla, Proxmox puede expirar esperando un escaneo de almacenamiento, una escritura de backup o una operación de montaje. Mientras tanto, tus comandos en shell se cuelgan y tu plan de “reinicio simple” se convierte en un plan de fencing.

Sistema de archivos de clúster y bloqueos: pmxcfs, corosync y folclore sobre bloqueos obsoletos

La configuración de clúster de Proxmox vive en /etc/pve, respaldada por pmxcfs. Es conveniente y también la razón por la que un “problema de almacenamiento” puede manifestarse como “no se puede escribir la configuración” si el nodo está sobrecargado o el clúster es inestable.

Síntomas de pmxcfs que se hacen pasar por todo lo demás

Los comandos CLI cuelgan cuando acceden a /etc/pve (por ejemplo, qm config).
“timeout waiting for cfs-lock” al arrancar/detener VMs, especialmente en HA o migraciones.
La GUI se vuelve lenta porque pveproxy llama repetidamente al árbol de configuración del clúster.

Bloqueos: lo bueno, lo malo y lo colgado

Los bloqueos existen para evitar que dos operaciones pisen la misma configuración de VM o estado de disco. Son correctos. También son un problema cuando el poseedor está muerto.

Reglas que te salvan:

Nunca borres archivos de bloqueo a ciegas como primera medida. Si el bloqueo protege una operación de almacenamiento en vuelo, puedes crear un split-brain a nivel de VM (dos acciones en conflicto) incluso si el clúster en sí está bien.
Identifica el PID dueño del bloqueo. Si es un proceso normal atascado (no en D-state), podrías terminarlo limpiamente. Si está en D-state, deja de fingir que las señales funcionan.
Los timeouts de bloqueo suelen ser secundarios. Un unmap de almacenamiento colgado causa una tarea atascada; la tarea atascada sostiene el bloqueo; la siguiente tarea expira esperando el bloqueo.

Broma #2 (corta y demasiado cierta): No puedes kill -9 a un proceso en estado D. Esa es la forma de Linux de decir “por favor, espera”.

Tres microcasos de la realidad corporativa

Microcaso 1: El incidente causado por una suposición equivocada

Mantenían un pequeño clúster Proxmox para servicios internos: ticketing, runners CI, un par de bases de datos que “no eran críticas” (hasta que lo fueron). Una mañana, las paradas de VM empezaron a fallar con “TASK ERROR: timeout waiting for shutdown”. El on-call asumió que era problema del S.O. invitado: “otra vez actualizaciones de Windows”, murmuró alguien, confiadamente equivocado.

Aumentaron el timeout de apagado. Luego intentaron qm stop. Se colgó. Intentaron matar QEMU. No murió. Reiniciaron pvedaemon. Igual. Mientras tanto, más tareas se encolaban, todas expirando esperando bloqueos.

El punto de inflexión fue un simple ps mostrando múltiples procesos QEMU en estado D, todos esperando en io_schedule. Una rápida mirada a dmesg mostró una tormenta de timeouts SCSI en una ruta. Multipath estaba configurado para encolar I/O cuando las rutas desaparecían. Genial para algunas cargas. Catastrófico para un hipervisor cuando el controlador del array se reinició.

La solución no fue “más timeouts”. Fue restaurar una ruta sana (y después cambiar el comportamiento de multipath para que el host falle rápido lo suficiente como para recuperarse). La lección del postmortem fue directa: un timeout de apagado de VM rara vez trata sobre el apagado si el hipervisor está atascado en I/O. Empezaron a tratar “D-state + timeouts” como incidente de almacenamiento por defecto, lo que acortó y suavizó futuros incidentes.

Microcaso 2: La optimización que salió mal

Otra empresa quería backups más rápidos. Tenían una ventana nocturna de vzdump que se estaba comiendo las horas de oficina. Alguien propuso una “victoria fácil”: habilitar más paralelismo y apretar los backups basados en snapshot. El almacenamiento era “suficientemente rápido”, según picos de throughput en una diapositiva del vendedor.

Las primeras noches fueron bien. Los backups acababan antes. Luego el clúster tuvo un día con más carga de escritura diurna. Durante la ventana de backup solapada, los snapshots de VM y limpieza desencadenaron una ola de errores timeout waiting for …: commits de snapshot atascados, paradas de VM expirando, replicación retrasada. El equipo de operaciones persiguió bloqueos, mató tareas y en general luchó con síntomas.

La causa real fue latencia transaccional: los tiempos de sync de ZFS se dispararon bajo la concurrencia de snapshots más la I/O de VM. El pool siguió “ONLINE”, pero la latencia fue terrible. Los timeouts de Proxmox no mentían; eran impacientes. La optimización—más concurrencia—fue un amplificador de latencia.

La solución no fue dramática: redujeron la concurrencia de backups, movieron los trabajos más pesados a otra ventana y añadieron alertas simples de latencia I/O. El throughput siguió bien y el sistema dejó de expirar. La lección es clásica de SRE: optimizar la métrica que puedes enseñar (duración de backup) puede destruir silenciosamente la métrica que usan los usuarios (latencia de cola).

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

Un entorno regulado ejecutaba Proxmox con Ceph. Nada emocionante, por diseño. Su “práctica aburrida” era la correlación estricta: cada fallo de tarea debía vincularse a una señal de salud del backend con fecha y hora (detalle de salud de Ceph, registros del kernel, errores de red). Sin excepciones. Parecía burocrático hasta que dejó de serlo.

Una tarde, las migraciones empezaron a fallar con timeouts y algunas paradas de VM se colgaron. Los mensajes de la UI variaban—unos decían timeouts esperando almacenamiento, otros parecían timeouts de bloqueo. Los ingenieros estuvieron tentados a culpar a actualizaciones de Proxmox de la semana anterior. La práctica aburrida les obligó a extraer slow ops de Ceph y registros del kernel para la misma franja horaria.

Encontraron un patrón: las slow ops se disparaban cuando un puerto específico del switch top-of-rack hacía flap. Corosync seguía quórum, así que el clúster parecía “bien”, pero el tráfico Ceph veía pérdida intermitente y retransmisiones. Eso aumentó latencia, que aumentó timeouts, que aumentó la contención de bloqueos. Falla en cascada con cara educada.

Porque tenían el hábito de correlación, el incidente no se convirtió en una caza de brujas de una semana. Movieron el tráfico Ceph fuera del puerto con flaps, reemplazaron un transceiver y los timeouts se detuvieron. El postmortem fue aburrido. Eso es cumplido.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “timeout waiting for lock …” en muchas VMs

Causa raíz: Una tarea atascada mantiene un bloqueo; a menudo la tarea atascada está bloqueada en I/O de almacenamiento o pmxcfs.

Solución: Identifica el dueño del bloqueo con fuser, inspecciona su estado (¿D-state?), luego arregla almacenamiento/pmxcfs. No borres bloqueos como primera medida.

2) Síntoma: timeouts de apagado de VM, luego “qm stop” también se cuelga

Causa raíz: QEMU está bloqueado en el kernel (estado D), típicamente en flush/unmap de disco o ruta de almacenamiento muerta.

Solución: Revisa ps por estado D y dmesg por errores de bloque. Restaura salud del almacenamiento; reinicia el nodo si I/O del kernel está irremediablemente colgado.

3) Síntoma: trabajos vzdump expiran y dejan snapshots/bloqueos

Causa raíz: El almacenamiento destino de backup es lento/inaccesible (los problemas NFS son frecuentes), o el commit de snapshot es lento (slow ops Ceph / latencia ZFS).

Solución: Verifica la capacidad de respuesta del montaje con stat y revisa salud del backend. Reduce concurrencia, reprograma y asegura que el almacenamiento de backups se monitorice como producción (porque lo es).

4) Síntoma: “timeout waiting for RBD unmap” durante stop/delete

Causa raíz: slow ops Ceph, I/O cliente colgado o problemas de red entre nodo y Ceph.

Solución: Revisa ceph -s y ceph health detail. Si hay slow ops, trata Ceph primero. Considera pausar operaciones disruptivas temporalmente.

5) Síntoma: operaciones que tocan /etc/pve cuelgan o fallan

Causa raíz: pmxcfs está bloqueado por inestabilidad de corosync, inanición de CPU o un nodo trabado.

Solución: Revisa quórum (pvecm status), mira logs de corosync, comprueba presión de CPU/memoria y estabiliza la red del clúster.

6) Síntoma: migraciones expiran pero el almacenamiento parece OK

Causa raíz: congestión de red de migración/desajuste de MTU o latencia de almacenamiento en el nodo remoto.

Solución: Valida la salud de la red; ejecuta migraciones con menos carga; revisa I/O wait en origen y destino. La migración involucra dos nodos y una red, no es solo una casilla para marcar.

Listas de verificación / plan paso a paso

Paso a paso: localizar qué se agotó realmente

Obtén el UPID desde la vista de tareas de Proxmox.
Lee el archivo de tarea en /var/log/pve/tasks/ para identificar el comando subyacente exacto y la fase que se quedó.
Identifica el PID del worker que sostiene el bloqueo (si aplica) usando fuser sobre el archivo de bloqueo, o emparejando las líneas de comando del proceso.
Comprueba el estado del proceso con ps:
- Si D: deja de perder tiempo con señales; es I/O o bloqueo del kernel.
- Si S/R: puede estar esperando otro proceso, la red o un bloqueo.
Revisa los registros del kernel (dmesg -T) por timeouts/resets de almacenamiento en la misma ventana temporal.
Verifica la salud del backend:
- ZFS: zpool status, zpool iostat
- Ceph: ceph -s, ceph health detail
- iSCSI: iscsiadm -m session, multipath -ll
- NFS: stat en los puntos de montaje
Decide la acción de recuperación:
- Si el almacenamiento falla: evacua/migra donde sea posible; detén el churn; arregla el backend; considera reiniciar si el kernel está trabado.
- Si pmxcfs/quórum: estabiliza corosync y las comunicaciones del clúster primero.
- Si el invitado no se apaga pero el host está sano: usa stop/kill escalando con conciencia del riesgo sobre los datos.

Lista de verificación: “¿Debo reiniciar este nodo?”

¿Tienes procesos en D-state ligados a tareas críticas?
¿Los registros del kernel muestran timeouts I/O repetidos o eventos de dispositivo offline?
¿El backend de almacenamiento ya se recuperó pero el nodo sigue atascado?
¿Puedes migrar/evacuar VMs primero (almacenamiento compartido, HA o ventan
a planificada)?

Si respondiste sí a las dos primeras y no puedes despejar la condición, un reinicio controlado suele ser la opción menos mala. La peor opción es dejar que el nodo se pudra en un estado medio muerto mientras las tareas se amontonan y los bloqueos se acumulan.

Hechos y contexto: por qué existen estos timeouts

Hecho 1: El seguimiento de tareas de Proxmox usa UPIDs para que las operaciones asíncronas se registren y auditen independientemente de la sesión GUI.
Hecho 2: pmxcfs es un sistema de archivos de clúster basado en FUSE; esa conveniencia significa que las operaciones de archivo normales pueden bloquearse por la salud del clúster.
Hecho 3: El estado D de Linux (uninterruptible sleep) existe para proteger la integridad del kernel y el I/O; por eso algunas “señales” no matan.
Hecho 4: Las rutas de apagado de QEMU comúnmente implican semánticas de flush de almacenamiento; un “timeout de apagado” puede ser en realidad un timeout de flush de disco.
Hecho 5: Las “slow ops” de Ceph no son solo métricas de rendimiento; pueden bloquear directamente operaciones de cliente como unmap/snapshot/remove de RBD.
Hecho 6: El comportamiento “queue if no path” de multipath fue diseñado para preservar el orden de I/O durante outage de rutas, pero puede congelar un hipervisor cuando los outages son prolongados.
Hecho 7: Los montajes NFS “hard” reintentan para siempre por defecto; eso es genial para la corrección de datos y terrible para la gestión interactiva cuando el servidor se va.
Hecho 8: Los flujos de trabajo con muchas snapshots desplazan la carga de puro throughput a metadatos y latencia; los timeouts a menudo siguen la latencia de cola, no el ancho de banda medio.
Hecho 9: Los timeouts de bloqueo de clúster a menudo aparecen después de que el incidente real ya empezó; con frecuencia son fallos secundarios de paradas anteriores.

Preguntas frecuentes

1) ¿Qué significa “timeout waiting for lock” normalmente en Proxmox?

Significa que una tarea de Proxmox no pudo adquirir un bloqueo (configuración de VM, almacenamiento o configuración de clúster) dentro del tiempo permitido. La causa real suele ser una tarea previa que sostiene ese bloqueo—a menudo porque está atascada en I/O de almacenamiento o pmxcfs.

2) Si un apagado de VM expira, ¿debería simplemente aumentar el timeout?

Sólo si el host está sano y el invitado está simplemente lento para apagarse. Si QEMU está en estado D o el nodo tiene alta I/O wait, aumentar el timeout solo te hará esperar más por algo que no puede completarse.

3) ¿Cómo distingo si es problema del invitado o del host/almacenamiento?

Revisa el estado del proceso QEMU. Si está en estado D con io_schedule o bloqueado en fsync, es host/almacenamiento. Si está funcionando con normalidad y solo ignora el apagado ACPI, probablemente sea comportamiento del invitado.

4) ¿Por qué se acumulan bloqueos después de una tarea mala?

Porque Proxmox serializa muchas operaciones de ciclo de vida para evitar corrupción. Una operación atascada mantiene un bloqueo; las operaciones subsecuentes expiran esperando ese bloqueo. La acumulación de bloqueos es el humo, no el fuego.

5) ¿Cuál es el indicador más rápido de que Ceph es el problema?

ceph -s mostrando slow ops, PGs degradados o recovery/backfill bajo presión. Si hay slow ops, asume que las operaciones de almacenamiento de Proxmox expirarán hasta que Ceph se estabilice.

6) ¿Puedo borrar archivos de bloqueo en /var/lock/pve-manager de forma segura?

A veces, pero es último recurso. Primero identifica el PID propietario. Si el propietario es una tarea legítimamente en ejecución, borrar el bloqueo puede crear operaciones concurrentes en conflicto. Si el propietario ya no existe y has confirmado que no hay una operación de almacenamiento activa subyacente, eliminar bloqueos obsoletos puede ser aceptable—documenta lo que hiciste.

7) ¿Por qué el acceso a /etc/pve cuelga cuando el clúster tiene problemas?

Porque /etc/pve es pmxcfs (FUSE). Las operaciones de archivo pueden depender del mensajero del clúster y la coordinación de bloqueos. Si corosync es inestable o el nodo está sobrecargado, las lecturas/escrituras normales en ese árbol pueden bloquearse.

8) ¿Cuál es el orden correcto para solucionar: registros de Proxmox o registros del kernel?

Empieza con el registro de la tarea para identificar qué estaba haciendo Proxmox, luego revisa inmediatamente los registros del kernel por errores de I/O en la misma ventana temporal. Los registros del kernel suelen decirte por qué la operación se quedó atascada.

9) ¿Por qué los timeouts ocurren más durante backups que en cualquier otra cosa?

Los backups son intensivos en I/O, snapshots y metadata. Estresan tanto el throughput como la latencia cola del almacenamiento. Si tu almacenamiento está “bien” en operación normal, los backups aún pueden empujarlo a la zona lenta donde los loops de espera de Proxmox alcanzan sus umbrales de timeout.

Próximos pasos que deberías hacer esta semana

Si quieres menos timeouts sorpresivos y incidentes más cortos, haz estos pasos prácticos:

Entrena a tu equipo para empezar desde el UPID y leer /var/log/pve/tasks/. Haz que sea memoria muscular.
Añade monitorización de estado D y I/O wait en cada nodo. Si tu monitorización no alerta sobre picos de D-state, no está monitorizando; es scrapbook.
Establece la línea base de tu backend de almacenamiento durante backups y migraciones. Captura latencia iostat, slow ops Ceph, zpool iostat—lo que uses.
Decide tu política de fallo para multipath/NFS (fail-fast vs hang). Los valores por defecto no son una estrategia.
Ejecuta un game day: satura intencionadamente el almacenamiento de backups o simula un flap de ruta en una ventana controlada, y practica identificar “qué se agotó realmente” en menos de diez minutos.

Los timeouts de Proxmox parecen vagos porque son una capa de gestión esperando a capas inferiores. Una vez que rastreas consistentemente la espera hasta un proceso, luego a un syscall, luego al backend, el mensaje deja de ser misterioso. Se convierte en una migaja.