pvedaemon.service falló en Proxmox: por qué las tareas no se ejecutan y cómo solucionarlo

noviembre 25, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 14

¿Te fue útil?

Haces clic en Iniciar sobre una VM. La interfaz web finge enviar el trabajo. Luego no pasa nada: no hay registro de tarea, no hay un error utilizable, solo un silencio largo y la sensación creciente de que el hipervisor te está juzgando.
Si pvedaemon está caído, Proxmox puede verse “bastante bien” mientras lo único que realmente necesitas —las tareas— deja de existir en silencio.

Esta es una de esas fallas que consume horas porque no falla de forma estridente. Falla de forma educada. Aquí tienes cómo diagnosticarla rápido, arreglarla correctamente y evitar que vuelva como una reunión recurrente indeseada.

Qué hace pvedaemon (y por qué la interfaz miente cuando está muerto)

Proxmox no es un monolito. Es un puñado de demonios que cooperan y una interfaz web que en gran parte intermedia peticiones hacia ellos. Si recuerdas una cosa:
pvedaemon es el trabajador que ejecuta la mayoría de las tareas locales del nodo: arrancar/detener invitados, operaciones de instantáneas, copias de seguridad, acciones sobre almacenamiento y muchos trabajos de “hacer algo” que desencadenas desde la interfaz o la API.

Cuando pvedaemon está caído, la interfaz web (pveproxy) puede seguir sirviendo páginas perfectamente. La autenticación funciona. Los paneles de estado se renderizan. Incluso puedes pulsar botones.
Pero cuando el sistema intenta generar una tarea, no puede entregársela al trabajador. Por eso obtienes el comportamiento clásico: interfaz viva, tareas muertas.

En términos de fiabilidad: tu plano de control responde HTTP, pero tu ejecutor falta. Es como un restaurante que toma reservas mientras la cocina está en llamas.

Qué esperar cuando falla

Las entradas del registro de tareas no aparecen, o aparecen y luego fallan al instante con “connection refused”, “timeout” o “no such file”.
Las copias de seguridad no se ejecutan según el calendario, o arrancan y se quedan colgadas por locks.
Iniciar una VM desde la CLI (qm start) puede funcionar si evita ciertas rutas de la API, pero muchas operaciones seguirán dependiendo del ecosistema de demonios.
En entornos en clúster se suma diversión extra: las tareas pueden enviarse al nodo equivocado o fallar por el estado del clúster, aunque la interfaz parezca sana.

Una cita útil para operaciones—atribuida a Werner Vogels (CTO de Amazon): Build it, run it. Si ejecutas Proxmox en producción, también eres responsable de este modo de fallo.

Guía rápida de diagnóstico

No “toques al azar”. Ejecuta una secuencia ajustada que reduzca el dominio del fallo en minutos. El objetivo es responder tres preguntas:
¿pvedaemon está realmente caído? Si sí, ¿por qué? Y si se está reiniciando, ¿qué lo está matando?

Primero: confirma el estado del demonio y bucles de reinicio

Revisa systemctl status pvedaemon y journalctl -u pvedaemon.
Si ves “start request repeated too quickly” o códigos de salida, estás en el terreno de systemd. Arregla el error subyacente; no llames a reinicios en bucle.

Segundo: comprueba “no es pvedaemon, es todo lo de abajo”

Disco lleno en el filesystem raíz o en /var/log.
Módulo Perl roto / actualización de paquete fallida.
Problemas de hostname / DNS / estado del clúster que causan fallos en llamadas a la API.
Timeouts de almacenamiento (NFS/iSCSI/Ceph) que hacen que las tareas se bloqueen y pvedaemon parezca “colgado”.

Tercero: decide la postura de recuperación

Si es un crash limpio con un error claro en los logs: arregla y reinicia.
Si es un bloqueo por almacenamiento: deja de cavar; estabiliza el almacenamiento primero.
Si es una división del clúster: evita “reinicios aleatorios”. Reconcilia el quórum y la salud de corosync.

Broma #1 (corta y pertinente): Si pvedaemon está caído, tu UI de Proxmox se convierte en un generador de fondos de pantalla muy caro.

Datos y contexto interesantes (por qué esto falla de formas sorprendentes)

Un poco de contexto hace que el troubleshooting sea más rápido porque dejas de esperar que Proxmox se comporte como un único servicio.
Aquí tienes hechos concretos que importan cuando pvedaemon.service falla:

Las tareas de Proxmox se orquestan entre varios demonios—pveproxy para UI/API, pvedaemon para los trabajadores, y a menudo pvestatd para refrescar métricas.
La mayor parte de la lógica de gestión de Proxmox está implementada en Perl. Un módulo Perl faltante tras una actualización puede hacer que los demonios fallen en el arranque como una trampilla.
El rate limiting de reinicios de systemd marcará servicios como fallidos incluso si podrían recuperarse — systemd protege el nodo de bucles de fork-bomb.
Proxmox VE evolucionó desde la pila “PVE” alrededor de 2008 con foco en el empaquetado Debian. Eso significa que el estado de paquetes importa: paquetes medio instalados pueden dejar inutilizados servicios básicos.
Los logs de tareas se escriben bajo /var/log/pve/, y un filesystem raíz lleno puede romper la creación de tareas de formas que parecen “fallo aleatorio del demonio”.
La pertenencia al clúster afecta el enrutamiento de tareas. En un clúster, algunas tareas consultan configuración bajo /etc/pve, que es un filesystem distribuido respaldado por pmxcfs.
/etc/pve no es “solo un directorio”. Es un filesystem FUSE especial. Si pmxcfs tiene problemas, las configuraciones pueden parecer desaparecidas o atascadas, y los demonios pueden fallar al leerlas.
Los plugins de almacenamiento pueden bloquear tareas de gestión. Si un servidor NFS se queda colgado, un listado “simple” de backups puede bloquear hasta que los timeouts se acumulen.
Proxmox usa IDs de tarea (UPIDs) para rastrear trabajos. Si no puedes crear un UPID, generalmente tienes un problema de demonio/log/permisos—no un “problema de VM”.

Cómo se manifiestan las fallas: síntomas que apuntan a pvedaemon

No solucionas por conjeturas. Empareja los síntomas con los dominios de fallo probables.

Racimos de síntomas clásicos

La UI web carga, pero cada acción falla: iniciar VM, detener VM, snapshot, backup. Eso es fallo de pvedaemon o del worker de API, no necesariamente QEMU.
Las tareas aparecen como “en ejecución” para siempre: a menudo llamadas de almacenamiento atascadas, contención de locks, o un trabajador bloqueado en I/O.
“Connection refused” o errores tipo “501” en la API: puede ser pvedaemon caído, problemas con pveproxy, o permisos locales de sockets.
Tras una actualización, las tareas se detienen: incompatibilidad de paquetes, rotura de dependencias de módulos Perl, o servicios obsoletos no reiniciados correctamente.
En un clúster, solo un nodo está raro: fallo de servicio local. Si todos los nodos están raros: problema de clúster/quórum o almacenamiento compartido.

Tareas prácticas: comandos, salida esperada y la decisión que tomas

A continuación están las comprobaciones prácticas que realmente ejecuto. Cada una incluye: el comando, qué significa la salida y qué decisión tomar a continuación.
Úsalas como un playbook, no como un buffet.

Tarea 1: Comprobar si pvedaemon ha fallado, está muerto o en bucle de reinicio

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-12-22 09:14:02 UTC; 2min 11s ago
    Process: 2190 ExecStart=/usr/bin/pvedaemon start (code=exited, status=255/EXCEPTION)
   Main PID: 2190 (code=exited, status=255/EXCEPTION)

Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Failed with result 'exit-code'.

Significado: No está en ejecución y salió de inmediato. Normalmente es un error de arranque (configuración, dependencia faltante, permisos), no “alta carga”.

Decisión: Ve directo a los logs (journalctl) para encontrar el primer error real. No reinicies a ciegas.

Tarea 2: Leer el journal de pvedaemon, pero hazlo en serio

cr0x@server:~$ journalctl -u pvedaemon -b --no-pager -n 200
Dec 22 09:14:02 server pvedaemon[2190]: Starting pvedaemon
Dec 22 09:14:02 server pvedaemon[2190]: Can't locate PVE/API2/Tasks.pm in @INC (you may need to install the PVE::API2::Tasks module) (@INC contains: /usr/share/perl5 ...)
Dec 22 09:14:02 server pvedaemon[2190]: BEGIN failed--compilation aborted at /usr/bin/pvedaemon line 7.
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION

Significado: Problema de empaquetado/dependencia. Perl no encuentra un módulo de Proxmox. Esto suele ocurrir tras una actualización interrumpida o una instalación parcial.

Decisión: Deja de depurar “servicios” y arregla paquetes. Salta a la Tarea 8 (salud de paquetes).

Tarea 3: Comprobar si otros demonios PVE también están disgustados

cr0x@server:~$ systemctl --no-pager --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● pvedaemon.service     loaded failed failed PVE API Daemon
● pvestatd.service      loaded failed failed PVE Status Daemon

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

Significado: No es solo un demonio. Eso apunta a dependencias compartidas: pmxcfs, libs Perl, disco lleno, config roto o actualización fallida.

Decisión: Amplía el alcance: revisa pve-cluster/pmxcfs, disco y paquetes antes de perseguir un solo servicio.

Tarea 4: Confirmar que no es la UI la que te engaña

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:10 UTC; 25min ago
   Main PID: 1422 (pveproxy)
      Tasks: 4 (limit: 154606)
     Memory: 78.3M
        CPU: 6.321s
     CGroup: /system.slice/pveproxy.service
             ├─1422 pveproxy
             └─1427 "pveproxy worker"

Significado: El proxy UI/API está bien. Los usuarios pueden iniciar sesión. Insistirán en que “Proxmox está arriba”. Técnicamente tienen razón, y eso es lo peor de estar en lo cierto.

Decisión: Enfócate en pvedaemon y la cadena de back-end (pmxcfs, almacenamiento, paquetes).

Tarea 5: Comprobar pmxcfs y la salud del filesystem del clúster (`/etc/pve`)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:07 UTC; 26min ago
   Main PID: 1201 (pmxcfs)
      Tasks: 7 (limit: 154606)
     Memory: 26.9M
        CPU: 2.113s
     CGroup: /system.slice/pve-cluster.service
             └─1201 /usr/bin/pmxcfs -l

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Significado: Si pmxcfs no está montado o pve-cluster está caído, muchas configuraciones “desaparecen” y los demonios pueden fallar al leerlas.

Decisión: Si pve-cluster está fallido, arregla el filesystem del clúster primero; reiniciar pvedaemon será inútil.

Tarea 6: Comprobar el quórum y corosync (nodos en clúster)

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

Quorum information
------------------
Date:             Mon Dec 22 09:17:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          Yes

Significado: Si el quórum es No, el FS del clúster puede volverse de solo lectura o estar desactualizado y las operaciones de gestión pueden fallar o comportarse de forma extraña.

Decisión: Si no hay quórum, arregla la red/corosync primero. No “forces” a menos que aceptes riesgos de split-brain y sepas exactamente lo que haces.

Tarea 7: Comprobar espacio en disco y agotamiento de inodos (sí, en serio)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        94G   94G     0 100% /

cr0x@server:~$ df -ih /var/log
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        6.0M  6.0M     0  100% /

Significado: Discos llenos o sin inodos pueden impedir escrituras de logs, creación de logs de tarea, archivos temporales e incluso operaciones de sockets. Los demonios pueden fallar o negarse a arrancar.

Decisión: Libera espacio inmediatamente (rotar logs, eliminar copias antiguas en almacenamiento local, limpiar cache de paquetes). Hazlo antes de reiniciar nada.

Tarea 8: Validar la salud de dpkg/apt (la clase de fallo “módulo faltante”)

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 pve-manager               Proxmox Virtual Environment management tools

cr0x@server:~$ apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following additional packages will be installed:
  pve-cluster pve-container pve-ha-manager
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/5,842 kB of archives.
After this operation, 24.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pve-cluster (8.0.7) ...
Setting up pve-manager (8.2.2) ...

Significado: Paquetes medio configurados son evidencia clara. Si faltan módulos Perl, las tareas fallarán de forma espectacular y repetida.

Decisión: Deja el estado de paquetes limpio (dpkg --configure -a, apt-get -f install) antes de culpar a systemd.

Tarea 9: Intentar arrancar pvedaemon manualmente y observar errores inmediatos

cr0x@server:~$ systemctl restart pvedaemon
cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:20:41 UTC; 3s ago
   Main PID: 3122 (pvedaemon)
      Tasks: 4 (limit: 154606)
     Memory: 64.2M
        CPU: 424ms
     CGroup: /system.slice/pvedaemon.service
             ├─3122 pvedaemon
             └─3123 "pvedaemon worker"

Significado: El servicio arrancó y se mantuvo activo. Ese es el caso fácil.

Decisión: Inmediatamente prueba una tarea simple (Tarea 12) y luego busca el desencadenante original (disco lleno, paquete roto, etc.) para que no vuelva a ocurrir.

Tarea 10: Si sigue fallando, captura la razón exacta de salida

cr0x@server:~$ systemctl show -p ExecMainStatus -p ExecMainCode -p Result pvedaemon
ExecMainCode=1
ExecMainStatus=255
Result=exit-code

Significado: El código de salida 255 es común para “excepción en arranque” en runtimes de alto nivel. No dice suficiente.

Decisión: Necesitas la primera excepción en journalctl (Tarea 2) o una verificación de paquetes (Tarea 8).

Tarea 11: Comprobar si hay presión de memoria / kills por OOM

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 30
Dec 22 09:12:44 server kernel: Out of memory: Killed process 2877 (pvedaemon) total-vm:512004kB, anon-rss:221344kB, file-rss:1232kB, shmem-rss:0kB, UID:0 pgtables:624kB oom_score_adj:0
Dec 22 09:12:44 server kernel: oom_reaper: reaped process 2877 (pvedaemon), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Significado: El kernel lo mató. No systemd. No Proxmox. El kernel. Normalmente debido a sobrecompromiso de memoria, un invitado ballooning descontrolado o agotamiento de swap en el host.

Decisión: Arregla la presión de memoria: reduce el overcommit del host, añade swap (con cuidado), detén los invitados problemáticos y considera reservar memoria para el host. Reiniciar pvedaemon sin arreglar la memoria es entrar en bucle.

Tarea 12: Validar la ejecución de tareas de extremo a extremo

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 3
[
  {
    "endtime": 1734868815,
    "id": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "node": "server",
    "pid": 4675,
    "starttime": 1734868780,
    "status": "OK",
    "type": "vzdump",
    "upid": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "user": "root@pam"
  }
]

Significado: Las tareas se crean, rastrean y completan. Si tu UI sigue comportándose mal, probablemente tengas un problema de caché del proxy/UI, no del trabajador.

Decisión: Si esto funciona, pasa a validar almacenamiento específico y lo que originalmente falló (backups, migraciones, snapshots).

Tarea 13: Encontrar una tarea atascada e identificar qué trabajador la retiene

cr0x@server:~$ ls -1 /var/log/pve/tasks | tail -n 5
UPID:server:00000A1C:00006D32:6767F1C0:qmstart:103:root@pam:
UPID:server:00000A21:00006DA0:6767F1E2:vzsnapshot:101:root@pam:
UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:
UPID:server:00000B15:00008260:6767F248:qmstop:102:root@pam:
UPID:server:00000B19:00008288:6767F251:qmstart:104:root@pam:

cr0x@server:~$ tail -n 50 "/var/log/pve/tasks/UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:"
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
ERROR: storage 'backup-nfs' is not online
INFO: backup job failed

Significado: Esto no es “pvedaemon caído”. Es “la tarea se ejecutó y falló”. El log te indica qué subsistema arreglar.

Decisión: Deja de depurar demonios. Arregla la conectividad/estado del almacenamiento.

Tarea 14: Buscar locks que estanquen tareas (común con problemas de almacenamiento)

cr0x@server:~$ pvesh get /cluster/locks
[
  {
    "lock": "backup",
    "node": "server",
    "type": "storage",
    "id": "backup-nfs",
    "time": 1734868001
  }
]

Significado: Existe un lock. Los locks no son malos; son seguridad serializada. Pero pueden quedar huérfanos tras crashes o timeouts.

Decisión: Si el lock es antiguo y la tarea está muerta, confirma que no hay un proceso activo y luego elimínalo con seguridad (ver Tarea 15). No borres archivos de lock a ciegas.

Tarea 15: Verificar si una operación “atascada” sigue en ejecución antes de borrar nada

cr0x@server:~$ ps aux | egrep 'vzdump|qemu-img|pvesm|pvedaemon' | grep -v egrep
root      3122  0.0  0.2  52440 18944 ?        Ss   09:20   0:00 pvedaemon
root      4675  0.1  0.3 120332 26420 ?        Ss   09:24   0:02 vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Significado: El trabajo sigue en ejecución. Borrar locks ahora sería una excelente forma de crear backups solapados y snapshots inconsistentes.

Decisión: Si está colgado, depura por qué (normalmente I/O de almacenamiento). Solo mata el proceso si entiendes las consecuencias (limpieza de snapshots, archivos parciales).

Tarea 16: Confirmar el estado del almacenamiento como lo ve Proxmox (no como quisieras que fuera)

cr0x@server:~$ pvesm status
Name         Type     Status     Total     Used     Available  %
local        dir      active     93.00G   12.40G     75.85G   13%
backup-nfs   nfs      inactive       0B       0B         0B    0%

Significado: El almacenamiento está inactivo. Si las tareas dependen de él, fallarán o se colgarán.

Decisión: Depura el almacenamiento a nivel OS: mounts, red, credenciales. No culpes a pvedaemon por negarse a usar un almacenamiento offline.

Tarea 17: Verificar montajes NFS y su capacidad de respuesta (ejemplo)

cr0x@server:~$ grep backup-nfs /etc/pve/storage.cfg
nfs: backup-nfs
        server 10.20.30.40
        export /srv/nfs/pve-backup
        path /mnt/pve/backup-nfs
        content backup
        options vers=4.1,proto=tcp

cr0x@server:~$ mount | grep /mnt/pve/backup-nfs || echo "not mounted"
not mounted

cr0x@server:~$ timeout 5 bash -lc 'ls -la /mnt/pve/backup-nfs'
ls: cannot access '/mnt/pve/backup-nfs': No such file or directory

Significado: La ruta de almacenamiento no existe o no está montada. Proxmox la marca offline y las tareas fallan. Si la ruta existe pero ls se queda colgado, tienes otro problema: un montaje NFS atascado.

Decisión: Arregla la definición/ruta de mount, y si los mounts se cuelgan, usa umount -f o unmount lazy con cautela. No reinicies un nodo para arreglar un mount a menos que disfrutes del downtime.

Tarea 18: Comprobar problemas TLS/hostname (un asesino sutil de tareas)

cr0x@server:~$ hostname -f
server.example.internal
cr0x@server:~$ grep -E 'server|127.0.1.1' /etc/hosts
127.0.0.1 localhost
127.0.1.1 server.example.internal server

Significado: La resolución de nombres es coherente. Si no lo es —si hostname -f devuelve algo que no coincide con certificados o la configuración del clúster— puedes ver errores raros en la API y confusión en los demonios.

Decisión: Arregla hostname/DNS/hosts coherentemente en todo el clúster. No “añadas otra entrada en hosts” hasta que funcione. Así es como creas infraestructura embrujada.

Causas raíz que realmente ocurren en producción

1) Estado de paquetes roto tras una actualización (más común, menos glamuroso)

Las actualizaciones de Proxmox suelen ser suaves—hasta que no lo son. El modo de fallo no siempre es “la actualización falló”. A veces la actualización “casi funcionó” y te dejó módulos Perl faltantes, paquetes medio configurados o demonios ejecutando código antiguo contra librerías nuevas.

La pista: Can't locate ... in @INC, BEGIN failed o quejas de dpkg. Arréglalo completando la configuración de paquetes y asegurando repositorios correctos para tu versión de Proxmox/Debian.

2) Disco lleno o agotamiento de inodos (letal en silencio)

Proxmox escribe logs de tareas, estado y datos temporales. Si la raíz está llena, el síntoma suele ser “las tareas no arrancan” o “el servicio no se mantiene activo”.
A la gente le encanta tratar las alertas de disco lleno como opcionales hasta que se vuelven obligatorias.

Disparadores comunes: copias locales dejadas en el almacenamiento local, journals que se descontrolan, volcado de crash o acumulación de ISOs.

3) Problemas de pmxcfs o estado del clúster

En un clúster, /etc/pve es la despensa del cerebro. Si no está disponible, los demonios que dependen de leer configuraciones pueden fallar o comportarse mal.
Si se pierde el quórum, podrías ver lecturas desactualizadas o escrituras bloqueadas. No es fragilidad—es Proxmox negándose a mentir sobre el estado distribuido.

4) Timeouts de almacenamiento e I/O colgado (pvedaemon “activo pero inútil”)

Puedes tener pvedaemon en ejecución que es efectivamente inútil porque sus trabajadores están bloqueados en I/O. Esto es especialmente común con:

Montajes NFS que se cuelgan en lugar de fallar rápido
iSCSI multipath mal configurado
Problemas de salud en Ceph (operaciones lentas, requests bloqueados)
Flaps en rutas Fibre Channel que causan largos timeouts SCSI

El truco es distinguir: demonio se estrelló vs demonio bloqueado. Los logs y el estado de procesos te lo dicen.

5) Presión de memoria y kills por OOM

Cuando el kernel empieza a matar procesos, no elige el que prefieres. Si pvedaemon muere, las tareas se detienen. Pero el verdadero problema es la gobernanza de memoria del host: ballooning, política de swap y el hecho de que “arrancó” no equivale a “es estable”.

6) Permisos y rarezas de filesystem (los contenedores complican esto)

Los problemas de permisos aparecen cuando no se pueden escribir logs de tareas, cuando un directorio bajo /var/lib tiene propietario incorrecto o cuando alguien “endureció” el nodo y rompió supuestos.
Proxmox no es alérgico al hardening, pero espera lo básico: propietarios correctos, rutas escribibles y opciones de montaje sensatas.

Tres micro-historias corporativas (porque esto siempre le pasa a “alguien más”)

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana ejecutaba un clúster Proxmox de dos nodos para “alta disponibilidad”. No usaban HA-manager, solo clúster. Su suposición: “Dos nodos significa redundancia”.
El equipo de red hizo un cambio rutinario en un switch core. Un breve storm de broadcast después, corosync empezó a perder paquetes.

El Nodo A seguía sirviendo la UI web. La gente inició sesión e intentó reiniciar algunas VMs “atascadas”. Las tareas no se ejecutaban. Naturalmente, alguien concluyó: “pvedaemon está roto”.
Reiniciaron demonios. Reiniciaron el nodo entero. Nada mejoró, porque el nodo no tenía quórum y pmxcfs se negó a comportarse como un filesystem de un solo nodo.

La suposición equivocada no era sobre pvedaemon. Era sobre el quórum. Los clústeres de dos nodos son deuda operativa a menos que diseñes deliberadamente el comportamiento de quórum (witness, qdevice o un tercer nodo).

La solución no fue heroica: restaurar la conectividad de corosync, reestablecer quórum, confirmar la salud de /etc/pve y luego reiniciar servicios en orden limpio.
Después, añadieron un dispositivo de quórum. Aburrido. Efectivo. El único tipo de “redundancia” que importa a las 3 a.m.

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

Otro cliente quería backups más rápidos. Cambiaron vzdump para usar un target NFS con opciones de montaje agresivas y timeouts afinados, porque “los valores por defecto son lentos”.
Funcionó. Durante un tiempo. Las copias eran más rápidas cuando el NAS estaba sano.

Entonces el NAS tuvo un failover de controladora durante la ventana de backups. El export NFS no murió de forma limpia; quedó “medio vivo”. Las lecturas a veces funcionaban. Las llamadas de metadata colgaban.
Desde el punto de vista de Proxmox, las tareas arrancaron y luego se congelaron. Los trabajadores se acumularon. pvedaemon siguió en ejecución, pero cada cola de tareas útil se convirtió en un aparcamiento.

La “optimización” creó un sistema que fallaba colgando, no fallando rápido. Ese es el peor modo de fallo para un ejecutor de tareas porque come capacidad de trabajador sin dar errores útiles.

La solución a largo plazo fue dejar de tratar el almacenamiento como una caja negra mágica: añadieron monitorización de capacidad de respuesta NFS (no solo ping), cambiaron el comportamiento de montaje para favorecer fallos rápidos y escalonaron backups para reducir el radio de explosión.
Las copias quedaron un poco más lentas. Los incidentes se volvieron dramáticamente menos frecuentes. Esa es una compensación que la mayoría de adultos acepta.

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

Un entorno regulado ejecutaba clústeres Proxmox con una rutina de mantenimiento estricta: antes de actualizaciones comprobaban espacio libre en root, confirmaban la salud de dpkg y hacían copia de seguridad de /etc/pve (más una nota de versiones actuales).
A nadie le encantaba esa checklist. Era papeleo con comandos de shell.

Durante una ventana de actualización, un problema de mirror causó descargas parciales y dejó pve-manager medio configurado. pvedaemon no arrancó y las tareas se apagaron.
El ingeniero on-call no improvisó. Ejecutó el plan aburrido: confirmar estado de paquetes, arreglar dependencias, volver a ejecutar configuración y reiniciar demonios en orden limpio.

Porque tenían una base conocida buena (versiones, espacio y una copia de configuraciones), pudieron tomar decisiones con seguridad y rapidez. Sin conjeturas. Sin espirales de “quizá sea DNS”.
Los sistemas se recuperaron rápido y el postmortem fue corto, lo cual es un signo silencioso de felicidad profesional.

Broma #2 (corta y pertinente): Lo único más persistente que un lock huérfano es un ejecutivo preguntando si “probaste reiniciarlo”.

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

Esta sección es directa a propósito. Estos son los errores que convierten una reparación de 10 minutos en un incidente de medio día.

1) “Las tareas no se ejecutan, así que reinicio todo el nodo”

Síntoma: La UI funciona; las tareas nunca arrancan o fallan inmediatamente.
Causa raíz: pvedaemon se estrelló por paquetes faltantes o disco lleno; un reboot no arregla eso.
Solución: Revisa systemctl status pvedaemon, luego journalctl -u pvedaemon, y arregla paquetes/disco antes de reiniciar.

2) “Borré locks porque parecía atascado”

Síntoma: Backups/migraciones cuelgan; aparecen locks en los locks del clúster.
Causa raíz: El job aún está en ejecución pero bloqueado por almacenamiento; borrar el lock provoca operaciones solapadas.
Solución: Confirma procesos con ps y la capacidad de respuesta del almacenamiento. Solo borra locks cuando hayas probado que el worker está muerto.

3) “El almacenamiento está bien porque responde a ping”

Síntoma: pvedaemon en ejecución pero tareas colgadas, especialmente backups/snapshots.
Causa raíz: NFS/iSCSI/Ceph se atascan a nivel I/O; ping es irrelevante.
Solución: Prueba operaciones reales: ls en el mount, leer/escribir archivos pequeños, comprobar pvesm status, revisar logs del kernel para timeouts de I/O.

4) “Actualicé, terminó, así que los paquetes deben estar bien”

Síntoma: pvedaemon sale con errores de módulos Perl.
Causa raíz: Paquetes medio configurados o repos mismatched.
Solución: dpkg --audit, dpkg --configure -a, apt-get -f install, y luego reiniciar servicios.

5) “Es un nodo único, los servicios de clúster no importan”

Síntoma: Lecturas de config fallan, /etc/pve luce raro, tareas dan error al acceder a config.
Causa raíz: pmxcfs/pve-cluster caído incluso en una instalación “de un solo nodo”, porque Proxmox aún lo usa para gestión de config.
Solución: Restaura la salud de pve-cluster y confirma que /etc/pve está montado como fuse.pmxcfs.

6) “Arreglé el demonio, pero las tareas siguen sin ejecutarse”

Síntoma: pvedaemon activo; acciones desde la UI aún dan error o se cuelgan.
Causa raíz: Almacenamiento subyacente offline, lock obsoleto o enrutamiento de API/hostname inconsistente.
Solución: Revisa logs de tareas en /var/log/pve/tasks/, valida pvesm status y confirma consistencia de hostname/DNS.

Listas de verificación / plan paso a paso

Checklist A: Restauración rápida de ejecución de tareas (nodo único)

Comprueba espacio e inodos: df -h /, df -ih /. Libera espacio si hace falta.
Comprueba estado de servicio: systemctl status pvedaemon.
Revisa logs: journalctl -u pvedaemon -b -n 200. Encuentra el primer error real.
Si es empaquetado: ejecuta dpkg --audit, luego dpkg --configure -a y apt-get -f install.
Confirma pmxcfs: systemctl status pve-cluster y mount | grep /etc/pve.
Reinicia en orden sensato:
- systemctl restart pve-cluster (si hace falta)
- systemctl restart pvedaemon
- systemctl restart pveproxy (opcional, si la UI sigue rara)
Valida con pvesh get /nodes/$(hostname)/tasks --limit 3 y una operación real (arrancar/detener una VM de prueba).

Checklist B: Restauración segura para clúster (evita empeorar)

Comprueba el quórum primero: pvecm status.
Si no hay quórum: arregla la red de corosync primero. Evita reinicios aleatorios.
Confirma que /etc/pve está montado y coherente en el nodo que usas.
Revisa los logs de pvedaemon por errores de lectura de config o problemas de permisos.
Comprueba el estado del almacenamiento desde el nodo donde fallan las tareas: pvesm status.
Sólo después de lo anterior: reinicia pvedaemon en el nodo afectado y vuelve a probar tareas.

Checklist C: Prevenir recurrencias (la parte que la mayoría omite)

Pon alertas de espacio libre del filesystem raíz donde las vean humanos, y actúa sobre ellas.
Tras actualizaciones, verifica salud de demonios: systemctl is-active pvedaemon y ejecuta una tarea de prueba.
Haz que el almacenamiento “falle rápido” donde sea posible, y monitoriza la capacidad de respuesta del almacenamiento (no solo su alcance).
Documenta cómo maneja tu clúster el quórum (especialmente si son dos nodos).
Mantén un plan de rollback conocido para problemas de paquetes: caches de paquetes, mirrors locales o al menos un procedimiento de recuperación probado.

Preguntas frecuentes

1) ¿Qué se rompe exactamente cuando pvedaemon está caído?

La mayoría de las tareas locales del nodo: acciones del ciclo de vida de VM/LXC, backups, snapshots, muchas operaciones de almacenamiento y cualquier cosa que necesite un worker de tareas y seguimiento UPID.

2) ¿Por qué la interfaz web sigue cargando si pvedaemon falló?

Porque pveproxy sirve la UI y el front-end de la API. Puede responder incluso si falta el worker de back-end. La UI no es maliciosa; solo es optimista.

3) ¿Cómo distinguir entre “pvedaemon se estrelló” y “pvedaemon está colgado”?

Si systemd muestra failed o inactive, se estrelló o no arrancó. Si está active (running) pero las tareas cuelgan, revisa I/O de almacenamiento, locks y procesos de trabajadores.

4) Veo “Can’t locate … in @INC” en el journal. ¿Qué hago?

Arregla el estado de paquetes. Ejecuta dpkg --audit, luego dpkg --configure -a y apt-get -f install. Casi nunca se soluciona editando rutas Perl al azar.

5) ¿Puedo simplemente reinstalar pve-manager?

A veces sí, pero trátalo como un problema de salud de paquetes, no como un problema de un único paquete. Una reinstalación forzada sin resolver mismatch de repos o actualizaciones parciales puede empeorar la situación.

6) Las tareas están atascadas y veo locks. ¿Es seguro eliminarlos?

Solo después de confirmar que el proceso subyacente no está en ejecución y que el subsistema de almacenamiento está estable. Los locks están para prevenir corrupción; borrarlos a ciegas es jugarte los datos.

7) ¿De verdad los problemas de DNS/hostname pueden causar fallos de tareas?

Sí, especialmente en clústeres donde los nodos se referencian por nombre y validan certificados. La resolución inconsistente de nombres puede causar que llamadas API, migraciones y acciones de almacenamiento fallen de formas que parecen no relacionadas.

8) ¿Reiniciar pveproxy ayuda cuando las tareas no se ejecutan?

Rara vez. Si pvedaemon está muerto, reiniciar el proxy es teatro. Reinicia pvedaemon tras arreglar la causa, y solo reinicia pveproxy si la UI está cacheando errores o se comporta de forma extraña.

9) ¿Esto está relacionado específicamente con backups vzdump?

Los backups son un desencadenante común porque tocan mucho el almacenamiento y crean locks. Pero la falla de pvedaemon es más amplia: cualquier fallo del runner de tareas afectará muchas operaciones.

10) ¿Cuál es la prueba más rápida de “¿está arreglado?”

Lanza una tarea inocua y rápida y confirma que se completa. Por ejemplo, consulta tareas recientes con pvesh y ejecuta un stop/start en una VM no crítica.
Si las tareas generan UPIDs y se completan, la ruta del trabajador está de vuelta.

Conclusión: próximos pasos que perduran

Cuando pvedaemon.service falla, Proxmox no tanto “cae” como deja de trabajar. Por eso consume tiempo: los paneles siguen renderizando, los usuarios siguen clicando y nada sucede.

Haz esto a continuación, en este orden:

Confirma el modo de fallo: estrellado vs colgado (systemctl status, journalctl).
Arregla los sospechosos habituales: disco/inodos, estado de paquetes, pmxcfs/quórum, capacidad de respuesta del almacenamiento.
Reinicia con intención: reinicia los demonios correctos en el orden correcto y luego realiza una prueba de tarea de extremo a extremo.
Prevén recurrencias: alerta sobre uso del filesystem raíz, valida después de actualizaciones y monitoriza el almacenamiento como parte del stack de cómputo—porque lo es.