Tareas atascadas en Proxmox: Cómo limpiar trabajos y procesos colgados de forma segura

enero 2, 2026 • febrero 3, 2026 • Lectura: 29 min • Views: 8

¿Te fue útil?

Algunos días, Proxmox es un hipervisor calmado y sensato. Otros días parece una casa encantada: backups que nunca terminan, “TASK ERROR: interrupted by signal”, un LXC que se niega a detenerse y un cargador “ejecutando…” en la GUI que dura más que tu café.

La parte difícil no es “cómo lo mato”. La parte difícil es saber qué estás realmente matando, en qué está esperando el sistema (¿almacenamiento? ¿quorum del clúster? ¿un estado D del kernel?) y cómo desenredarlo sin convertir un bloqueo temporal en un evento de corrupción.

Qué significa realmente “atascado” en Proxmox (y por qué la GUI miente)

En Proxmox, la mayoría de las operaciones que pulsas en la interfaz se convierten en una tarea en segundo plano manejada por un pequeño elenco de demonios: pvedaemon, pveproxy, pvescheduler y compañía. Esas tareas pueden generar otros procesos: vzdump para backups, qm para acciones de VM QEMU, pct para acciones LXC, utilidades zfs, comandos rbd o simplemente rsync.

“Atascado” suele significar una de estas condiciones:

Un proceso en espacio de usuario está esperando por un bloqueo, un socket de red o un proceso hijo que no responde.
Un proceso está bloqueado en espacio de kernel (estado D), típicamente esperando E/S de disco o red. Este es el desagradable: puedes enviar señales todo el día y no morirá hasta que la llamada del kernel regrese.
Se mantiene un “lock” de Proxmox (como el bloqueo de configuración de VM o el lock de vzdump). A veces es válido. A veces está obsoleto, lo que significa que el trabajo murió pero el lock no se limpió.
El sistema de archivos del clúster (pmxcfs) está descontento. Si el nodo no puede confirmar cambios de configuración de forma fiable, las tareas que tocan la config de VM o definiciones de almacenamiento pueden estancarse de formas extrañas.
El almacenamiento es el cuello de botella, y la tarea es el mensajero. Un scrub de ZFS, un pool saturado, un montaje NFS atascado, un clúster Ceph degradado—todo eso puede congelar acciones “simples” como detener/iniciar, snapshot o backup.

El estado de la UI de Proxmox no es autoritativo. Es una vista de los logs de tareas y del estado del clúster, que puede retrasarse o fallar en actualizarse cuando la plomería subyacente está congestionada. No “hagas clic con más fuerza”. Observa como un adulto.

Guion de diagnóstico rápido (primera/segunda/tercera comprobación)

Si estás en un incidente, no tienes tiempo para admirar la sutileza de los estados de proceso de Linux. Necesitas un embudo rápido para encontrar el cuello de botella.

Primero: confirma si esto es almacenamiento, clúster o un proceso único

¿El host está limitado por I/O? Alto iowait, tareas bloqueadas en dmesg, latencia del pool ZFS, operaciones lentas en Ceph o un montaje atascado de NFS gritan “almacenamiento”.
¿El nodo está en quorum y pmxcfs es escribible? Si las comunicaciones del clúster están rotas, las tareas que cambian la configuración pueden “colgarse” mientras reintentan o esperan.
¿Es solo una acción de VM/contenedor? Entonces probablemente tengas un problema por invitado: QEMU atascado, QMP sin respuesta, desmontaje de passthrough de dispositivo, retención de snapshot de backup o un archivo de bloqueo.

Segundo: localiza el proceso exacto y su motivo de espera

Obtén el UPID de la UI/log de tareas o con pvesh.
Encuentra el PID e inspecciona el estado: ps, top, pstree, cat /proc/PID/stack, wchan.

Tercero: elige la intervención de menor riesgo

Si es un lock de Proxmox obsoleto: elimina el lock después de verificar que ningún proceso activo lo posee.
Si es un bloqueo en espacio de usuario: detén/termina procesos hijos en orden, luego el proceso padre.
Si es espera por E/S en estado D: no juegues a la ruleta rusa con kill -9. Arregla primero la ruta de E/S y luego limpia.
Si es clúster/pmxcfs: restaura el quorum o opera temporalmente en modo local con disciplina (y conocimiento del riesgo).

Hechos interesantes y contexto histórico (por qué sigue ocurriendo)

El “estado D” en Linux ha sido una trampa clásica para operaciones durante décadas: un proceso atascado en sueño no interrumpible ignora señales hasta que la operación del kernel finaliza. Por eso “kill -9” a veces parece que no funciona.
Las tareas de Proxmox usan UPIDs (Unique Process IDs) que codifican nodo, PID, tiempo de inicio y tipo. No es solo un ID; es un rastro de migas de pan.
pmxcfs es un sistema de archivos de clúster basado en FUSE que vive en RAM y sincroniza la configuración vía corosync. Si se atasca, las lecturas/escrituras de config pueden volverse extrañas pese a que el disco subyacente esté bien.
Los backups basados en snapshots cambiaron los modos de fallo: los flujos modernos de backup en Proxmox dependen de hooks del agente invitado QEMU, creación de snapshots y flushes de almacenamiento. Las fallas suelen ser “bugs de coordinación”, no solo discos lentos.
ZFS prioriza intencionadamente la consistencia sobre la capacidad de respuesta. Bajo ciertos caminos de error, ZFS esperará en lugar de adivinar. Es una característica hasta que te encuentras mirando un backup congelado a las 02:00.
Los montajes NFS “hard” pueden colgar indefinidamente por diseño (siguen reintentando). Eso es genial para la corrección y terrible para la finalización de tareas cuando el NAS tiene un problema.
Los “slow ops” de Ceph suelen ser problemas de red disfrazados. El síntoma de almacenamiento aparece primero; la causa raíz puede ser un puerto de switch que hace flap.
Los bloqueos de stop/reboot de QEMU suelen ser sobre desmontaje de dispositivos: un flush virtio-blk atascado, una sesión iSCSI muerta o un dispositivo PCI passthrough que no se resetea limpiamente.

Reglas de seguridad: qué hacer antes de tocar nada

Cuando las tareas se atascan, la gente se vuelve agresiva. Así conviertes “un backup atascado” en “un disco de VM corrupto y una reunión incómoda”. Aquí está la disciplina básica.

Regla 1: No elimines locks hasta probar que están obsoletos

Un lock de Proxmox suele estar presente porque algo está mutando activamente el estado de la VM. Si lo quitas mientras el trabajo todavía se está ejecutando, puedes superponer operaciones que deberían haberse serializado.

Regla 2: Prefiere detener el proceso hijo, no el demonio padre

Matar pvedaemon porque un backup está atascado es como reiniciar un router porque una sola pestaña del navegador no carga. Técnicamente hace algo; rara vez es la mejor primera medida.

Regla 3: Si el proceso está en estado D, deja de intentar “matarlo”

Arregla lo que está esperando: almacenamiento, ruta de red o problema del driver del kernel. Entonces el proceso se desenrollará. O no, y estarás mirando una ventana para reiniciar el nodo.

Regla 4: Captura evidencia antes de intervenir

Como mínimo: log de la tarea, journalctl alrededor del tiempo de la falla y estado del proceso. Si luego necesitas explicar lo ocurrido, “maté algunas cosas y desapareció” no es un informe de incidente.

Broma #1: “Kill -9” no es una estrategia de troubleshooting; es una admisión de derrota con puntuación.

Tareas prácticas (comandos + qué significa la salida + la decisión que tomas)

Estos son los movimientos que realmente uso en producción. Cada tarea incluye un comando realista, un ejemplo de la salida que verás, qué significa y la decisión que conduce.

Tarea 1: Listar tareas en ejecución de Proxmox e identificar el UPID

cr0x@server:~$ pvesh get /nodes/pve1/tasks --running 1
┌──────────────────────────────────────────────────────────────────────────────────────┬───────────────┬────────┬─────────────┬──────────┬────────┐
│ upid                                                                                 │ type          │ status │ starttime   │ user     │ id     │
╞══════════════════════════════════════════════════════════════════════════════════════╪═══════════════╪════════╪═════════════╪══════════╪════════╡
│ UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:                            │ vzdump        │ running│ 1735019546  │ root@pam │ 101    │
│ UPID:pve1:00013210:03F4C2C8:676D2C4B:qmstop:205:root@pam:                            │ qmstop        │ running│ 1735019595  │ root@pam │ 205    │
└──────────────────────────────────────────────────────────────────────────────────────┴───────────────┴────────┴─────────────┴──────────┴────────┘

Qué significa: Tienes dos tareas en ejecución. Una es un backup para VM 101. Otra es una acción de stop para VM 205.

Decisión: Elige un UPID para investigar. No mates servicios a lo loco hasta saber qué trabajo está atascado y por qué.

Tarea 2: Obtener el log de la tarea atascada

cr0x@server:~$ pvesh get /nodes/pve1/tasks/UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:/log
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
INFO: VM Name: app01
INFO: include disk 'scsi0' 'local-zfs:vm-101-disk-0' 200G
INFO: creating vzdump archive '/mnt/pve/backup-nfs/dump/vzdump-qemu-101-2025_12_26-01_12_26.vma.zst'
INFO: started backup task 'UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:'
INFO: status: 0% (loading)
INFO: backup is sparse: 58% (data 42%)

Qué significa: El trabajo arrancó bien y ahora está atascado al inicio (“loading”), a menudo indicio de que está esperando E/S de almacenamiento o un snapshot/flush.

Decisión: Comprueba la salud del sistema y del almacenamiento antes de matar nada.

Tarea 3: Identificar el PID detrás de un UPID

cr0x@server:~$ ps -eo pid,etimes,stat,cmd | egrep 'vzdump|pvedaemon|UPID' | head
  7714   1289 Ssl  pvedaemon worker UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
  7760   1281 S    /usr/bin/perl /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd

Qué significa: El worker es PID 7714; generó el proceso real de trabajo (vzdump) PID 7760.

Decisión: Investiga el PID 7760. Matar el worker sin limpiar hijos puede dejar artefactos a medio terminar.

Tarea 4: Comprobar si el proceso está en estado D (sueño no interrumpible)

cr0x@server:~$ ps -o pid,stat,wchan,cmd -p 7760
  PID STAT WCHAN  CMD
 7760 D    nfs_wait_on_request /usr/bin/perl /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd

Qué significa: El proceso está en estado D y esperando en nfs_wait_on_request. Las señales no ayudarán hasta que la llamada NFS retorne.

Decisión: Deja de tratar esto como “un problema de tarea Proxmox”. Es un problema de NFS. Ve a revisar el montaje, la ruta de red y el NAS.

Tarea 5: Inspeccionar montajes atascados (el asesino silencioso de tareas)

cr0x@server:~$ mount | grep '/mnt/pve/backup-nfs'
10.10.20.50:/export/pve-backups on /mnt/pve/backup-nfs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.11,local_lock=none)

Qué significa: Es un montaje hard de NFS (normal para corrección). Si el servidor está lento o inalcanzable, los procesos cliente pueden colgar indefinidamente.

Decisión: Si el servidor NFS está caído, o bien lo restauras o planificas un unmount/reboot controlado. No esperes que Proxmox se “desatasque” solo.

Tarea 6: Confirmar dolor de I/O a nivel sistema (iowait y procesos bloqueados)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  8      0 512344  89312 845992    0    0   112   984  921 1650  6  4 30 60  0
 1  7      0 508120  89316 846200    0    0    96   812  880 1543  5  3 27 65  0
 0  9      0 509004  89320 846380    0    0    72   900  915 1602  4  3 25 68  0

Qué significa: Alto wa (iowait) y muchos procesos bloqueados (b) indican un estancamiento de E/S. Esto concuerda con un proceso en estado D esperando en NFS.

Decisión: Cambia el foco de troubleshooting a almacenamiento/red. Matar tareas no arreglará la espera.

Tarea 7: Identificar qué mantiene un lock de Proxmox en una VM

cr0x@server:~$ qm config 205 | grep -E '^lock:'
lock: stop

Qué significa: La VM 205 está bloqueada por una operación de stop. Puede ser legítimo (se está ejecutando un stop) o estar obsoleto (un stop falló y dejó el lock).

Decisión: Verifica si hay una tarea de stop activa para esta VM antes de limpiar el lock.

Tarea 8: Comprobar si hay tarea qmstop activa y estado del proceso QEMU

cr0x@server:~$ ps -eo pid,stat,cmd | grep -E 'qemu-system|qm stop 205' | grep -v grep
 8122 Sl   /usr/bin/kvm -id 205 -name vm205 -m 16384 -smp 8 -machine q35 ...

Qué significa: QEMU está en ejecución. La tarea de stop puede estar atascada en la comunicación QMP, o QEMU puede estar atascado en el desmontaje de I/O.

Decisión: Consulta el estado del monitor QEMU y revisa si el almacenamiento está bloqueado.

Tarea 9: Consultar el estado de QEMU vía qm monitor (verificación rápida)

cr0x@server:~$ qm monitor 205 --cmd 'info status'
VM status: running

Qué significa: QEMU responde al monitor. Eso es bueno: probablemente no está en coma de E/S a nivel kernel.

Decisión: Intenta un apagado gracioso primero (qm shutdown) e inspecciona el agente invitado si está configurado. Evita qm stop salvo que sea necesario.

Tarea 10: Revisar logs relacionados con la tarea en el journal de systemd

cr0x@server:~$ journalctl -u pvedaemon -u pvescheduler -u pveproxy --since "30 min ago" | tail -n 40
Dec 26 01:12:26 pve1 pvedaemon[1650]: starting task UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
Dec 26 01:12:31 pve1 pvedaemon[7714]: vzdump: backup job failed to make progress (waiting for storage)
Dec 26 01:13:15 pve1 pvedaemon[1650]: starting task UPID:pve1:00013210:03F4C2C8:676D2C4B:qmstop:205:root@pam:
Dec 26 01:14:16 pve1 pvedaemon[8120]: qmstop: VM 205 qmp command failed - timeout

Qué significa: Los demonios te están diciendo exactamente qué duele: backup esperando almacenamiento; QMP timeout para stop.

Decisión: Para el timeout de stop, revisa si QEMU está bloqueado por E/S. Para el backup, atiende NFS/servidor primero.

Tarea 11: Buscar advertencias del kernel de “hung task”

cr0x@server:~$ dmesg -T | tail -n 30
[Thu Dec 26 01:15:02 2025] INFO: task vzdump:7760 blocked for more than 120 seconds.
[Thu Dec 26 01:15:02 2025]       Tainted: P           O      6.5.11-8-pve #1
[Thu Dec 26 01:15:02 2025] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Thu Dec 26 01:15:02 2025] task:vzdump          state:D stack:0     pid:7760  ppid:7714 flags:0x00004006
[Thu Dec 26 01:15:02 2025] Call Trace:
[Thu Dec 26 01:15:02 2025]  nfs_wait_on_request+0x2f/0x90 [nfs]

Qué significa: El kernel lo confirma: la tarea está bloqueada en NFS. Esto no es un bug de Proxmox; es la ruta de almacenamiento.

Decisión: Arregla la conectividad/performance de NFS; si debes recuperar inmediatamente, planifica un reinicio controlado del nodo tras asegurar la seguridad de los invitados.

Tarea 12: Confirmar salud del pool ZFS y detectar stalls evidentes

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 00:21:11 with 0 errors on Thu Dec 26 00:40:15 2025
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_AAA      ONLINE       0     0     1
            ata-SAMSUNG_SSD_BBB      ONLINE       0     0     0

errors: No known data errors

Qué significa: El pool está en línea, pero tienes un error de checksum en un dispositivo. No necesariamente causa el bloqueo actual, pero es una luz amarilla encendida.

Decisión: Si tus tareas están atascadas en E/S ZFS local, investiga la latencia (zpool iostat) y el hardware. Incluso errores “menores” pueden correlacionarse con stalls bajo carga.

Tarea 13: Comprobar latencia y throughput de ZFS (encontrar el punto de estrangulamiento)

cr0x@server:~$ zpool iostat -v 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        620G  1.19T    210    980   12.5M  88.3M
  mirror-0                   620G  1.19T    210    980   12.5M  88.3M
    ata-SAMSUNG_SSD_AAA         -      -    105    495   6.25M  44.1M
    ata-SAMSUNG_SSD_BBB         -      -    105    485   6.30M  44.2M
--------------------------  -----  -----  -----  -----  -----  -----

Qué significa: El throughput es decente; si las tareas todavía se atascan, el problema puede estar en otro lugar (NFS, Ceph o una ruta de dispositivo específica) en lugar de una saturación ZFS local.

Decisión: No culpes a ZFS por reflejo. Usa evidencia: si zpool iostat está calmado pero NFS wchan muestra esperas, sigue la pista NFS.

Tarea 14: Inspeccionar la salud de Ceph si tu almacenamiento es RBD/CephFS

cr0x@server:~$ ceph -s
  cluster:
    id:     8b7a3c8d-4f20-4f0a-8ce8-8c1b0f20d1b2
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 76 sec, osd.3 has slow requests

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: mgr1(active), standbys: mgr2
    osd: 6 osds: 6 up (6 total), 6 in (6 total)

  data:
    pools:   3 pools, 256 pgs
    objects: 18.2k objects, 71 GiB
    usage:   224 GiB used, 2.1 TiB / 2.3 TiB avail
    pgs:     254 active+clean, 2 active+degraded

Qué significa: Las slow ops pueden hacer que las tareas de Proxmox se atasquen (snapshot, backup, stop). Aunque sea solo un “WARN”, tu latencia ya te está mintiendo.

Decisión: Trata las slow ops como un incidente de performance. Investiga latencia de OSD, red y backfill/recovery. No mates tareas a lo loco; se volverán a atascar.

Tarea 15: Comprobar pmxcfs y estado de quorum (atascos “locales” inducidos por el clúster)

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

Quorum information
------------------
Date:             Thu Dec 26 01:18:07 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.342
Quorate:          Yes

Qué significa: El quorum está bien. Eso elimina toda una clase de rarezas.

Decisión: Si el quorum fuera No, evita escrituras de configuración y ten cuidado con acciones de VM que requieran actualizar el estado del clúster.

Tarea 16: Encontrar y limpiar un lock obsoleto de forma segura (solo tras verificar)

cr0x@server:~$ qm unlock 205
unlocking VM 205

Qué significa: Se elimina el lock de la configuración de la VM. Esto no mata ningún proceso QEMU en ejecución; solo elimina la guardia de serialización de Proxmox.

Decisión: Haz esto solo después de confirmar que no hay ninguna operación activa legítima aún en ejecución para esa VM. Si QEMU sigue en medio de un stop y desbloqueas, puedes empezar a superponer operaciones y crear fallas posteriores.

Tarea 17: Cancelar una tarea en ejecución (mejor esfuerzo, depende del estado de espera)

cr0x@server:~$ pvesh create /nodes/pve1/tasks/UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:/cancel
OK

Qué significa: Proxmox registró una solicitud de cancelación. Si el proceso está en espacio de usuario, puede detenerse. Si está bloqueado en estado D, no lo hará.

Decisión: Usa cancel primero por cortesía; luego atiende la causa raíz. No asumas que OK significa “desapareció”.

Tarea 18: Matar limpiamente un proceso helper colgado en espacio de usuario (y solo el helper)

cr0x@server:~$ pstree -ap 7714 | head -n 20
pvedaemon,7714 worker UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
  └─perl,7760 /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd
     └─tar,7788 --sparse -cf - .

Qué significa: El worker vzdump generó un proceso tar (o similar) que realiza el trabajo de archivar. A veces el helper se atasca mientras el padre está bien.

Decisión: Si el helper está atascado en espacio de usuario (no en estado D), puedes intentar terminarlo primero para permitir que el padre falle limpiamente y libere locks.

cr0x@server:~$ kill -TERM 7788
cr0x@server:~$ sleep 3
cr0x@server:~$ ps -p 7788
  PID TTY          TIME CMD

Qué significa: No hay salida después del encabezado implica que salió.

Decisión: Revisa el log del proceso padre. Si se está desenrollando y limpiando, ya terminaste. Si sigue bloqueado (especialmente en estado D), detente y céntrate en el almacenamiento.

Ángulo de almacenamiento: ZFS, Ceph, NFS, iSCSI y el arte de esperar

La mayoría de las “tareas Proxmox atascadas” son incidentes de almacenamiento con disfraz de UI. La UI es el mensajero. No la dispares a menos que estés seguro de que lo merece.

ZFS para VMs: stalls en snapshot y send/receive

Con ZFS, los puntos comunes de bloqueo son:

Creación de snapshot cuando el pool está bajo estrés (rara vez se cuelga totalmente, pero puede volverse muy lento).
ZFS send (replicación) esperando lecturas de disco, o limitado por escrituras en el destino.
Contención del pool: backups, scrubs, resilvers y escrituras aleatorias intensas en los mismos vdevs.

El truco es diferenciar “lento pero progresando” de “parado”. ZFS a menudo sigue moviéndose, solo que dolorosamente. Si tu iostat muestra throughput y ops que avanzan, no está atascado; está infraaprovisionado.

Backups en NFS: la semántica “hard” provoca bloqueos en estado D

Si tu destino de backup es NFS, estás tomando prestada la pila de almacenamiento de otro y esperando que no estornude. Cuando lo hace, el cliente Linux puede bloquearse en llamadas NFS del kernel. Eso bloquea vzdump, lo que bloquea al worker de Proxmox, lo que bloquea locks y trabajos siguientes. Por eso verás un “backup atascado” que también impide operaciones de VM.

Si tu montaje NFS es hard (típico), no puedes “matar al proceso” para salir de él. Debes restaurar el servidor NFS o programar un reinicio del nodo para limpiar hilos del kernel atascados. Reiniciar no es vergonzoso; a veces es el corte limpio necesario.

Almacenamiento Ceph: las slow ops se convierten en acciones de ciclo de vida atascadas

Ceph suele ser honesto. Si está poco saludable, te lo dice. Pero las acciones de Proxmox pueden seguir pareciendo “atascadas” porque esperan operaciones RBD ralentizadas por recovery, backfill o latencia de red.

Patrón común: un stop de VM se atasca porque el flush de disco del invitado no completa a tiempo. O una tarea de snapshot espera operaciones de metadatos RBD. Si ves slow ops, deja de preguntar “por qué Proxmox está atascado” y pregunta “por qué Ceph está lento”.

iSCSI: sesiones que medio-mueren y se llevan tus procesos de rehén

iSCSI puede ser perfectamente aburrido en producción, que es lo mejor que puedes decir de un almacenamiento. Cuando falla, puede fallar lentamente: una ruta hace flap, multipath reintenta, los timeouts se acumulan y procesos bloquean en sueño no interrumpible. Las tareas que tocan esos LUNs se colgarán.

Si ves esperas en estado D en blk_mq_get_tag o similar, estás en territorio de capa de bloque. Arregla la ruta (red, target, multipath) antes de intentar matar trabajos de Proxmox.

Una cita que deberías interiorizar

“La esperanza no es una estrategia.” — General Gordon R. Sullivan

En términos de operaciones: si tu “arreglo” depende de que el almacenamiento vuelva por su cuenta, no es un arreglo. Es una oración con número de ticket.

Ángulo de clúster: pmxcfs, corosync, quorum y por qué las tareas “locales” se atascan

La pila de clúster de Proxmox es un multiplicador de productividad. También es fuente de modos de fallo sorprendentes cuando el clúster está degradado.

pmxcfs: el sistema de archivos de configuración que puede hacerte dudar de la realidad

/etc/pve no es un directorio normal. Es un sistema de archivos de clúster (FUSE) respaldado por RAM y sincronizado. Eso significa:

Si pmxcfs no puede confirmar cambios, las tareas que escriben configs de VM pueden bloquearse o fallar de formas extrañas.
Si el nodo está aislado sin quorum, Proxmox puede intencionalmente impedir ciertas escrituras para evitar split-brain en la configuración.

Pérdida de quorum: el modo “todo funciona pero nada puede cambiar”

Perder el quorum no necesariamente detiene tus VMs en ejecución. Impide cambios coordinados. La gente interpreta eso como “Proxmox está atascado”. No está atascado; se niega a hacer cambios inseguros.

Si estás en un nodo aislado y lo fuerzas a comportarse como si estuviera solo, tal vez puedas hacer trabajo. También puedes acabar con configs de VM conflictivas cuando el clúster sane. Elige ese intercambio intencionalmente, no emocionalmente.

Broma #2: Corosync sin quorum es como una reunión sin actas: todos recuerdan una verdad diferente, y todas están equivocadas.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

El equipo tenía un clúster Proxmox con NFS para backups. Una noche, los jobs de backup empezaron a acumularse. La UI mostraba “running” durante horas. Un ingeniero senior asumió, con razón, que el proceso de backup simplemente era lento porque el job semanal procesa más datos.

Así que esperaron. Luego esperaron más. Las operaciones de stop de VM también empezaron a colgar. La suposición se convirtió en “Proxmox está sobrecargado”. Reiniciaron pvedaemon y pveproxy para “limpiar tareas”. La UI se refrescó y pareció mejor durante unos diez minutos—hasta que dejó de serlo.

El problema real: la ruta de red hacia el servidor NFS tenía un problema. El montaje era hard, por lo que los procesos quedaron bloqueados en estado D. Reiniciar demonios no hizo nada excepto eliminar migas de pan fáciles en los logs y confundir la rotación on-call.

La recuperación fue contundente: restaurar la ruta NFS, esperar a que el kernel desenrolle las llamadas bloqueadas, luego cancelar los jobs y limpiar los archivos parciales. También aprendieron una regla: cuando ves estado D con un wchan de NFS, tu “backup atascado” es un incidente de NFS. Escala acorde.

Mini-historia 2: La optimización que salió mal

Una compañía quiso backups más rápidos. Cambiaron la compresión de vzdump a una más pesada y aumentaron la concurrencia para que más VMs se pudieran respaldar en paralelo. Los gráficos de CPU parecían “bien” en hora laboral normal, así que la optimización pasó.

Llegó la noche de backups. El pool ZFS sufrió alta amplificación de escrituras bajo snapshotting concurrente y compresión, el destino NFS se volvió el siguiente cuello de botella y la latencia subió. Algunos huéspedes se volvieron lentos. Unos cuantos qm shutdown empezaron a hacer timeout porque los comandos QMP esperaban flushes de I/O.

El equipo respondió matando tareas colgadas, lo cual liberó locks pero no redujo la presión subyacente. Ahora tenían artefactos de backup parciales y reintentos acumulándose. Se convirtió en una estampida auto-infligida.

La solución fue casi aburrida: reducir la concurrencia, elegir la compresión que encaje con la balanza CPU/almacenamiento, escalonar jobs pesados y vigilar iowait y latencia de almacenamiento, no solo uso de CPU. La lección: “backups más rápidos” es un problema de sistemas, no un solo ajuste. Si optimizas un componente, otro felizmente arderá.

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

Otra organización tenía una regla: cada nodo tiene una pequeña lista “break-glass” en un runbook—cómo identificar tareas por UPID, cómo encontrar PIDs y qué logs capturar antes de intervenir. A nadie le encantaba. Parecía papeleo para máquinas.

Durante una ventana de mantenimiento, una ruta iSCSI hizo flap. Un puñado de VMs estuvo bien. Dos VMs tuvieron operaciones de stop que colgaron y un job de replicación se congeló. El on-call siguió la lista: capturar logs de tareas, confirmar estados de proceso, revisar mensajes del kernel, verificar multipath y solo entonces decidir un reinicio controlado de servicios afectados.

Notaron el detalle crítico temprano: los procesos colgados estaban en estado D en la capa de bloque, así que matarlos no funcionaría. En su lugar, restauraron la ruta iSCSI, confirmaron que la E/S reanudó y luego reintentaron los stops limpiamente. Sin corrupción, sin reinicios panicosos, sin misterio.

La “práctica aburrida” fue la diferencia. Bajo estrés, no asciendes al nivel de la ocasión—caes al nivel de tus hábitos operativos. Su hábito fue evidencia primero, acción después.

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

Esta sección es deliberadamente específica. El consejo genérico es barato; el downtime no lo es.

1) Síntoma: “TASK OK” nunca aparece; la UI muestra “running” para siempre

Causa raíz: El proceso worker está bloqueado en E/S del kernel (estado D), o la UI no puede actualizarse debido a pmxcfs/problemas de clúster.
Solución: Encuentra el PID, comprueba ps STAT y wchan, consulta dmesg. Si está en D-state, arregla almacenamiento/red. Si no, usa cancel de tarea y termina procesos hijos limpiamente.

2) Síntoma: “cannot lock file /var/lock/qemu-server/205.conf”

Causa raíz: Un lock válido sostenido por un job activo, o un lock obsoleto tras un crash.
Solución: Confirma que no hay tarea en ejecución para esa VM; inspecciona qm config por lock; luego qm unlock 205. Si la acción de VM sigue, resuélvela primero.

3) Síntoma: vzdump atascado en “0% (loading)”

Causa raíz: Espera en flush/snapshot de almacenamiento o destino de backup muerto (NFS/SMB).
Solución: Revisa estado del proceso; verifica salud del montaje; revisa la ruta de red; para problemas de montajes NFS hard, restaura el servidor o planifica reinicio controlado.

4) Síntoma: qm stop se cuelga; QMP hace timeout

Causa raíz: QEMU bloqueado en flush de disco o desmontaje de dispositivo; agente invitado ausente; latencia de almacenamiento alta.
Solución: Prueba qm shutdown primero; verifica qm monitor; inspecciona salud de almacenamiento y mensajes del kernel. Si QEMU está en D-state, arregla la ruta de E/S. Solo forza stop cuando aceptes el posible impacto en el sistema de archivos del invitado.

5) Síntoma: LXC stop se cuelga

Causa raíz: Procesos del contenedor atascados en NFS dentro del contenedor, o freezer de cgroup del kernel esperando.
Solución: Identifica el PID init del contenedor, inspecciona estados de proceso, revisa montajes usados por el contenedor. Arregla la ruta de almacenamiento; luego reintenta stop. Evita matar a la fuerza a menos que entiendas el riesgo para las cargas del contenedor.

6) Síntoma: tareas fallan aleatoriamente tras un tropiezo del clúster

Causa raíz: Pérdida de quorum o pmxcfs no saludable; escrituras de config bloqueadas.
Solución: Comprueba pvecm status, restaura quorum, confirma que /etc/pve responde. Evita cambios de config mientras no hay quorum a menos que hayas aceptado deliberadamente el riesgo de split-brain (normalmente no).

7) Síntoma: jobs de replicación atascados; zfs send no progresa

Causa raíz: Destino lento o inalcanzable, cuello de botella de red, snapshots retenidos o contención en pool origen.
Solución: Revisa el estado del proceso zfs send; comprueba la red; valida la salud del dataset destino; reduce carga concurrente (scrubs/resilver) durante ventanas de replicación.

Listas de verificación / planes paso a paso

Checklist A: Desenrollar de forma segura un backup vzdump atascado

Obtén el UPID de tareas en ejecución (pvesh get /nodes/NODE/tasks --running 1).
Extrae el log de la tarea y anota la última línea de progreso.
Encuentra los PIDs (worker + vzdump + helpers) con ps y pstree.
Comprueba estado con ps -o stat,wchan.
Si está en D-state en NFS/capa de bloque: arregla la ruta de almacenamiento primero. No pierdas tiempo con señales.
Si es un bloqueo en espacio de usuario: intenta pvesh .../cancel, luego kill -TERM a procesos helper y después al padre si es necesario.
Verifica la limpieza del lock en la VM y que no haya nuevas tareas bloqueadas detrás.
Revisa archivos de archivo parciales en el almacén de backups y elimina solo tras confirmar que están incompletos y no referenciados por un proceso aún en ejecución.
Ejecuta un único job de backup con concurrencia reducida para validar la ruta antes de reanudar el calendario.

Checklist B: Tratar de forma segura una tarea de “stop” colgada para una VM

Confirma que la VM sigue en ejecución: ps para PID de QEMU y qm status VMID.
Prueba qm shutdown (gracioso). Si el agente invitado está instalado y funciona, mejor.
Comprueba la capacidad de respuesta de QMP: qm monitor VMID --cmd 'info status'.
Si QEMU responde pero el stop cuelga: investiga latencia de almacenamiento y logs de desmontaje de dispositivos; considera ampliar el timeout.
Si QEMU está en D-state: arregla la ruta de almacenamiento. Para fallos graves, programa reinicio del nodo; no confíes en kills forzados.
Sólo como último recurso: qm stop VMID (forzar). Documenta el riesgo y realiza comprobaciones de sistema de archivos del invitado tras el hecho según proceda.
Tras la recuperación: elimina lock obsoleto de Proxmox (qm unlock VMID) si es necesario, pero solo después de verificar que no queda ninguna tarea de stop activa.

Checklist C: Cuando sospechas problemas de clúster/pmxcfs

Comprueba quorum: pvecm status.
Revisa la salud de corosync en logs: journalctl -u corosync --since "30 min ago".
Prueba la capacidad de respuesta de /etc/pve (lecturas simples como ls no deberían colgar).
No realices operaciones que cambien la configuración si no hay quorum a menos que hayas aceptado explícitamente el riesgo de split-brain.
Restaura la red entre nodos, arregla problemas de sincronización de tiempo y luego verifica que vuelve el quorum.
Una vez estable el clúster, vuelve a revisar las tareas en ejecución; muchas tareas “atascadas” se vuelven simplemente “fallidas” y se pueden reintentar limpiamente.

Preguntas frecuentes

1) ¿Puedo reiniciar pvedaemon para limpiar tareas atascadas?

Puedes, pero raramente es la primera medida correcta. Si un worker está bloqueado en estado D debido a almacenamiento, reiniciar demonios no lo desbloqueará. Solo perderás continuidad en los logs y confundirás el seguimiento de tareas.

2) ¿Cuál es la forma más segura de detener un backup colgado?

Pide cancel vía el endpoint de tarea, luego termina los procesos hijos con suavidad (TERM) si están en espacio de usuario. Si están en estado D, arregla primero el almacenamiento; de lo contrario crearás un desorden sin lograr “detener” realmente.

3) ¿Cómo sé si un lock está obsoleto?

Correlaciónalo con tareas en ejecución y procesos reales. Si la VM tiene lock: seteado pero no hay tarea en ejecución correspondiente ni árbol de procesos relevante, probablemente esté obsoleto. Entonces qm unlock es apropiado.

4) ¿Por qué a veces “kill -9” no funciona?

Porque el proceso está atascado en sueño no interrumpible (estado D) dentro del kernel, usualmente esperando E/S. La señal se pone en cola pero no se atiende hasta que la llamada del kernel retorna.

5) ¿Es seguro eliminar archivos parciales de backup del almacén?

Generalmente, sí—después de confirmar que ningún proceso sigue escribiéndolos y que has decidido que el archivo está incompleto. Borrar un archivo que sigue abierto por un proceso puede empeorar el troubleshooting y no te libera necesariamente del bloqueo subyacente.

6) Mi VM no se detiene y QMP hace timeout. ¿Está corrupta la VM?

No necesariamente. A menudo significa que QEMU no puede completar un flush de I/O o una operación de dispositivo, por lo que no puede responder. El riesgo de corrupción aumenta si terminas forzosamente sin resolver la E/S.

7) ¿Puedo ignorar Ceph HEALTH_WARN por ahora?

No. “WARN” a menudo significa “la latencia ya es suficientemente mala como para bloquear operaciones de nivel superior”. Las slow ops son la canaria; las tareas atascadas de Proxmox son el derrumbe de la mina.

8) ¿Cuándo es correcto reiniciar un nodo?

Cuando procesos críticos están atascados en D-state debido a una ruta de E/S que no se puede restaurar rápidamente, o cuando hilos del kernel están wedged e impiden una recuperación limpia. Reiniciar es un reinicio controlado, no un fallo moral.

9) ¿Por qué fallan tareas “locales” cuando el clúster tiene problemas de quorum?

Porque “local” a menudo todavía toca la configuración sincronizada del clúster en /etc/pve. Si pmxcfs está afectado o las escrituras están bloqueadas por la política de quorum, las tareas pueden estancarse o negarse a continuar.

10) ¿Cómo evito que vuelvan a ocurrir tareas atascadas?

Diseña para latencia de I/O predecible: dimensiona almacenamiento, limita concurrencia de backups, separa tráfico de backups, monitoriza hung tasks del kernel y trata las advertencias de almacenamiento como incidentes, no como trivia.

Conclusión: pasos siguientes para prevenir repeticiones

Las tareas atascadas en Proxmox rara vez son misteriosas. Normalmente son una de tres cosas: stalls de almacenamiento, locks obsoletos o problemas de coordinación del clúster. La diferencia entre una recuperación limpia y una desordenada es si identificas en qué categoría estás antes de empezar a matar procesos.

Haz esto a continuación:

Adopta el embudo de diagnóstico rápido: almacenamiento vs clúster vs proceso por invitado.
Enseña a tu equipo a reconocer estado D y deja de perder tiempo con señales cuando el kernel espera E/S.
Pon límites sensatos en la concurrencia de backups y programa operaciones pesadas (scrub, replicación, backups masivos) como si realmente te importara la latencia.
Cuando limpies locks, hazlo como un cirujano: verifica y luego corta. No improvises.