Proxmox : Tâches bloquées — Nettoyer les jobs et processus coincés en toute sécurité

janvier 2, 2026 • février 3, 2026 • Lecture : 31 min • Views: 11

Cet article vous a aidé ?

Certains jours, Proxmox est un hyperviseur calme et sensé. D’autres jours, c’est une maison hantée : des sauvegardes qui ne se terminent jamais, « TASK ERROR: interrupted by signal », un LXC qui refuse de s’arrêter, et un indicateur « running… » dans l’interface qui survit à votre café.

La difficulté n’est pas « comment je le tue ». La difficulté est de savoir ce que vous tuez réellement, sur quoi le système attend (stockage ? quorum du cluster ? un D-state noyau ?), et comment démêler la situation sans transformer un blocage temporaire en corruption.

Ce que « bloqué » signifie vraiment dans Proxmox (et pourquoi l’interface trompe)

Dans Proxmox, la plupart des opérations cliquées dans l’UI deviennent des tâches en arrière-plan gérées par un petit ensemble de démons : pvedaemon, pveproxy, pvescheduler, et leurs alliés. Ces tâches peuvent engendrer d’autres processus : vzdump pour les sauvegardes, qm pour les actions de VM QEMU, pct pour les actions LXC, les utilitaires zfs, les commandes rbd, ou juste rsync.

« Bloqué » signifie généralement l’une de ces situations :

Un processus en espace utilisateur attend sur un verrou, une socket réseau, ou un processus enfant qui ne renvoie rien.
Un processus est bloqué en espace noyau (état D), typiquement en attente d’E/S disque ou réseau. C’est le cas le plus pénible : vous pouvez envoyer des signaux toute la journée et il ne mourra pas tant que l’appel noyau n’est pas terminé.
Un « verrou » Proxmox est détenu (par exemple verrou de config VM ou verrou vzdump). Parfois il est légitime. Parfois il est obsolète : le job est mort mais le verrou n’a pas été nettoyé.
Le système de fichiers du cluster (pmxcfs) est mal en point. Si le nœud ne peut pas engager de façon fiable des changements de configuration, les tâches touchant la config VM ou les définitions de stockage peuvent se bloquer de façon étrange.
Le stockage est le goulot, et la tâche n’en est que le messager. Scrub ZFS, pool saturé, montage NFS grippé, cluster Ceph dégradé — tout cela peut figer des actions « simples » comme stop/start, snapshot ou sauvegarde.

L’état affiché par l’UI Proxmox n’est pas forcément autoritatif. C’est une vue sur les logs de tâches et l’état du cluster, qui peut prendre du retard ou ne pas se mettre à jour quand la plomberie sous-jacente est congestionnée. Ne « cliquez pas plus fort ». Observez comme un adulte.

Playbook de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Si vous êtes en pleine interruption de service, vous n’avez pas le temps d’admirer la subtilité des états de processus Linux. Vous avez besoin d’un entonnoir rapide pour trouver le goulot.

Première étape : confirmer s’il s’agit du stockage, du cluster ou d’un seul processus

L’hôte est-il I/O-bound ? Un iowait élevé, des tâches bloquées dans dmesg, latence du pool ZFS, slow ops Ceph, ou un montage wedgé NFS crient « stockage ».
Le nœud est-il en quorum et pmxcfs est-il réinscriptible ? Si les communications du cluster sont cassées, les tâches modifiant la configuration peuvent « bloquer » en retentant ou en attendant.
Est-ce seulement une action d’une VM/conteneur ? Alors vous avez probablement un souci par invité : QEMU bloqué, QMP qui ne répond pas, un teardown de device en passthrough, une snapshot de sauvegarde qui retient, ou un fichier de verrou.

Deuxième étape : localiser le processus exact et sa raison d’attente

Obtenez l’UPID de la tâche depuis l’UI/log de tâche ou pvesh.
Trouvez le PID et inspectez l’état : ps, top, pstree, cat /proc/PID/stack, wchan.

Troisième étape : choisir l’intervention la moins risquée

Si c’est un verrou Proxmox obsolète : supprimez le verrou après avoir vérifié qu’aucun processus actif ne le possède.
Si c’est un blocage en espace utilisateur : arrêtez/tuez les processus enfants dans l’ordre, puis le parent de la tâche.
Si c’est un D-state en attente d’E/S : ne jouez pas au marteau avec kill -9. Réparez d’abord le chemin d’E/S, puis nettoyez.
Si c’est cluster/pmxcfs : restaurez le quorum ou opérez temporairement en local avec discipline (et conscience du risque).

Faits intéressants et contexte historique (pourquoi ça recommence)

L’état « D » de Linux est un piège classique des opérations depuis des décennies : un processus bloqué en sommeil non interruptible ignore les signaux jusqu’au retour de l’appel noyau. C’est pourquoi « kill -9 » semble parfois cassé.
Les tâches Proxmox utilisent des UPID (Unique Process IDs) qui encodent le nœud, le PID, l’heure de début et le type. Ce n’est pas qu’un identifiant ; c’est une piste.
pmxcfs est un système de fichiers de cluster basé sur FUSE qui vit en RAM et synchronise la config via corosync. S’il est bloqué, les lectures/écritures de config peuvent devenir étranges malgré le disque sous-jacent en bon état.
Les sauvegardes basées sur snapshot ont changé les modes de défaillance : les flux de sauvegarde modernes s’appuient sur des hooks guest agent QEMU, la création de snapshot et les flushs de stockage. Les échecs sont souvent des « bugs de coordination », pas seulement des disques lents.
ZFS priorise intentionnellement la cohérence plutôt que la réactivité. Dans certains chemins d’erreur, ZFS attend au lieu de deviner. C’est une fonctionnalité jusqu’à ce que vous regardiez une sauvegarde figée à 02:00.
Les montages NFS « hard » peuvent bloquer indéfiniment par conception (ils continuent de réessayer). C’est excellent pour la justesse et terrible pour l’achèvement des tâches quand le NAS a un souci.
Les « slow ops » de Ceph sont souvent de faux-nez pour des problèmes réseau. Le symptôme stockage apparaît en premier ; la cause racine peut être un port de switch qui flappe.
Les blocages stop/reboot QEMU concernent fréquemment le teardown de device : un flush virtio-blk coincé, une session iSCSI morte, ou un device PCI passthrough qui ne se réinitialise pas proprement.

Règles de sécurité : que faire avant de toucher quoi que ce soit

Quand les tâches se bloquent, les gens deviennent agressifs. C’est comme ça que vous transformez « une sauvegarde bloquée » en « un disque VM corrompu et une réunion gênante ». Voici la discipline de base.

Règle 1 : Ne supprimez pas les verrous avant de prouver qu’ils sont obsolètes

Un verrou Proxmox est souvent présent parce que quelque chose mutile l’état de la VM. Si vous l’enlevez alors que le job tourne encore, vous pouvez chevaucher des opérations qui devaient être sérialisées.

Règle 2 : Préférez arrêter le processus enfant, pas le démon parent

Tuer pvedaemon parce qu’une sauvegarde est bloquée, c’est comme redémarrer un routeur parce qu’un onglet de navigateur ne charge pas. Techniquement, ça fait quelque chose ; rarement le meilleur premier choix.

Règle 3 : Si le processus est en D-state, arrêtez d’essayer de le « tuer »

Réparez ce sur quoi il attend : stockage, chemin réseau, ou pilote noyau. Ensuite le processus se déroulera. Ou pas, et vous serez face à une fenêtre de redémarrage du nœud.

Règle 4 : Capturez des preuves avant d’intervenir

Au minimum : log de la tâche, journalctl autour du moment de l’échec, et l’état des processus. Si vous devez ensuite expliquer ce qui s’est passé, « j’ai tué des processus et ça a disparu » n’est pas un rapport d’incident.

Blague n°1 : « Kill -9 » n’est pas une stratégie de dépannage ; c’est un aveu de défaite avec de la ponctuation.

Tâches pratiques (commandes + ce que signifient les sorties + la décision que vous prenez)

Voici les actions que j’utilise réellement en production. Chaque tâche inclut une commande réaliste, un exemple de sortie, ce que ça signifie, et la décision qu’elle provoque.

Tâche 1 : Lister les tâches Proxmox en cours et identifier l’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    │
└──────────────────────────────────────────────────────────────────────────────────────┴───────────────┴────────┴─────────────┴──────────┴────────┘

Ce que ça signifie : Vous avez deux tâches en cours. L’une est une sauvegarde de la VM 101. L’autre est une action d’arrêt pour la VM 205.

Décision : Choisissez un UPID à enquêter. Ne tuez pas les services au hasard avant de savoir quelle tâche est bloquée et pourquoi.

Tâche 2 : Récupérer le log de la tâche bloquée

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%)

Ce que ça signifie : Le job a démarré correctement et est maintenant bloqué tôt (« loading »), indice fréquent qu’il attend une I/O de stockage ou une snapshot/flush.

Décision : Vérifiez d’abord l’état système et stockage avant de tuer quoi que ce soit.

Tâche 3 : Identifier le PID derrière 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

Ce que ça signifie : Le worker est PID 7714 ; il a engendré le vrai processus de travail (vzdump) PID 7760.

Décision : Enquêter sur le PID 7760. Tuer le worker sans nettoyer les enfants peut laisser des artefacts à moitié terminés.

Tâche 4 : Vérifier si le processus est en D-state (sommeil non interruptible)

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

Ce que ça signifie : Le processus est en état D et attend dans nfs_wait_on_request. Les signaux n’aideront pas tant que l’appel NFS ne retourne pas.

Décision : Cessez de traiter cela comme un « problème de tâche Proxmox ». C’est un problème NFS. Allez vérifier le montage, le chemin réseau et le NAS.

Tâche 5 : Inspecter les montages bloqués (le tueur silencieux)

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)

Ce que ça signifie : C’est un montage NFS hard (normal pour la cohérence). Si le serveur est lent ou injoignable, les processus clients peuvent se bloquer indéfiniment.

Décision : Si le serveur NFS est tombé, restaurez-le ou planifiez un démontage contrôlé / redémarrage. N’attendez pas que Proxmox se « débloque » tout seul.

Tâche 6 : Confirmer une douleur I/O globale (iowait et tâches bloquées)

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

Ce que ça signifie : Un wa (iowait) élevé et beaucoup de processus bloqués (b) indiquent un blocage I/O. Cela correspond à un processus en D-state attendant sur NFS.

Décision : Orientez le dépannage vers le stockage/réseau. Tuer les tâches ne résoudra pas l’attente.

Tâche 7 : Identifier ce qui détient un verrou Proxmox sur une VM

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

Ce que ça signifie : La VM 205 est verrouillée pour une opération stop. Cela peut être légitime (un stop est en cours) ou obsolète (un stop a échoué et a laissé le verrou).

Décision : Vérifiez s’il existe une tâche stop active pour cette VM avant de supprimer le verrou.

Tâche 8 : Vérifier la présence d’une tâche qmstop active et l’état du processus 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 ...

Ce que ça signifie : QEMU tourne. La tâche stop peut être bloquée dans la communication QMP, ou QEMU peut être coincé sur le teardown d’E/S.

Décision : Interrogez le moniteur QEMU et vérifiez si le stockage est wedgé.

Tâche 9 : Interroger l’état QEMU via qm monitor (vérification rapide)

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

Ce que ça signifie : QEMU répond suffisamment pour répondre aux commandes du moniteur. C’est bon : il n’est probablement pas en coma d’E/S au niveau noyau.

Décision : Tentez un arrêt gracieux d’abord (qm shutdown) et inspectez le guest agent si configuré. Évitez qm stop sauf si nécessaire.

Tâche 10 : Vérifier les logs de tâches via le journal 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

Ce que ça signifie : Les démons vous disent exactement ce qui fait mal : sauvegarde en attente de stockage ; timeout QMP pour le stop.

Décision : Pour le timeout de stop, vérifiez si QEMU est bloqué sur une E/S. Pour la sauvegarde, adressez d’abord le NFS/serveur.

Tâche 11 : Rechercher des avertissements noyau « 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]

Ce que ça signifie : Le noyau le confirme : la tâche est bloquée dans NFS. Ce n’est pas un bug Proxmox ; c’est le chemin de stockage.

Décision : Réparez la reachabilité/performance NFS ; si vous devez récupérer immédiatement, planifiez un redémarrage contrôlé du nœud après avoir assuré la sécurité des invités.

Tâche 12 : Confirmer l’état du pool ZFS et repérer les blocages évidents

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

Ce que ça signifie : Le pool est en ligne, mais vous avez une erreur de checksum sur un périphérique. Cela ne cause pas nécessairement le blocage actuel, mais c’est un voyant jaune à surveiller.

Décision : Si vos tâches sont bloquées sur des E/S ZFS locales, investiguez la latence (zpool iostat) et le matériel. Même des erreurs « mineures » peuvent se corréler avec des blocages sous charge.

Tâche 13 : Vérifier la latence et le débit ZFS (trouver le point d’étranglement)

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
--------------------------  -----  -----  -----  -----  -----  -----

Ce que ça signifie : Le débit est correct ; si les tâches restent bloquées, le problème peut se situer ailleurs (NFS, Ceph ou un chemin de device spécifique) plutôt qu’une saturation ZFS locale.

Décision : Ne blâmez pas ZFS par réflexe. Utilisez des preuves : si zpool iostat est calme mais que NFS wchan montre des attentes, suivez le fil NFS.

Tâche 14 : Inspecter la santé Ceph si votre stockage est 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

Ce que ça signifie : Les slow ops peuvent absolument faire bloquer des tâches Proxmox (snapshot, sauvegarde, stop). Même si c’est seulement « WARN », votre latence est déjà en train de mentir.

Décision : Traitez les slow ops comme un incident de performance. Investiguer la latence OSD, le réseau, et les opérations de backfill/recovery. Ne vous contentez pas de tuer les tâches ; elles se bloqueront à nouveau.

Tâche 15 : Vérifier pmxcfs et l’état du quorum (blocages « locaux » induits par le cluster)

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

Ce que ça signifie : Le quorum est bon. Cela élimine toute une classe d’étrangetés.

Décision : Si le quorum était No, évitez les écritures de config et soyez prudent avec les actions VM qui nécessitent des mises à jour d’état de cluster.

Tâche 16 : Trouver et supprimer un verrou obsolète en toute sécurité (seulement après vérification)

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

Ce que ça signifie : Le verrou est supprimé de la config VM. Cela ne tue aucun processus QEMU en cours ; cela retire seulement la garde de sérialisation de Proxmox.

Décision : Ne faites cela qu’après avoir confirmé qu’aucune opération légitime n’est encore en cours pour cette VM. Si QEMU est encore en plein stop et que vous déverrouillez, vous pouvez chevaucher des opérations et créer des échecs en chaîne.

Tâche 17 : Annuler une tâche en cours (meilleur effort, dépend de l’état d’attente)

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

Ce que ça signifie : Proxmox a enregistré une requête d’annulation. Si le processus est en espace utilisateur, il peut s’arrêter. S’il est bloqué en D-state, il ne le fera pas.

Décision : Utilisez d’abord cancel par politesse ; puis traitez la cause racine. Ne supposez pas que OK signifie « c’est parti ».

Tâche 18 : Tuer proprement un processus helper utilisateur bloqué (et seulement le 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 - .

Ce que ça signifie : Le worker vzdump a engendré un processus tar (ou similaire) qui fait l’archive. Parfois le helper bloque alors que le parent est correct.

Décision : Si le helper est bloqué en espace utilisateur (pas en D-state), vous pouvez tenter de le terminer en premier pour laisser le parent échouer proprement et libérer les verrous.

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

Ce que ça signifie : L’absence de sortie après l’en-tête implique qu’il est sorti.

Décision : Vérifiez à nouveau le log du parent. S’il se déroule et nettoie, vous avez terminé. S’il est toujours bloqué (surtout en D-state), arrêtez et concentrez-vous sur le stockage.

Angle stockage : ZFS, Ceph, NFS, iSCSI et l’art d’attendre

La plupart des « tâches Proxmox bloquées » sont des incidents de stockage déguisés en UI. L’UI est le messager. Ne le tirez pas tant que vous n’êtes pas sûr qu’il le mérite.

VMs sur ZFS : points de blocage snapshot et send/receive

Avec ZFS, les points de blocage fréquents sont :

Création de snapshot quand le pool est sous tension (rarement complètement bloquant, mais peut devenir lent).
ZFS send (réplication) en attente de lectures disque, ou bridée par les écritures côté destination.
Contention de pool : sauvegardes, scrubs, resilvers et écritures aléatoires lourdes sur les mêmes vdevs.

L’astuce est de différencier « lent mais progressant » de « complètement figé ». ZFS continue souvent d’avancer, mais péniblement. Si votre iostat montre un débit et des opérations qui progressent, ce n’est pas bloqué ; c’est sous-dimensionné.

Sauvegardes sur NFS : la sémantique « hard » provoque des D-state

Si votre cible de sauvegarde est NFS, vous empruntez la pile de stockage de quelqu’un d’autre en espérant qu’elle ne tousse pas. Quand ça arrive, le client Linux peut bloquer dans des appels noyau NFS. Cela bloque vzdump, ce qui bloque le worker Proxmox, ce qui retient des verrous et bloque des jobs suivants. C’est pourquoi vous verrez une « sauvegarde bloquée » qui empêche aussi des opérations VM.

Si votre montage NFS est hard (typique), vous ne pouvez pas « tuer le processus » pour le sortir. Vous devez restaurer le serveur NFS ou planifier un redémarrage du nœud pour nettoyer les threads noyau bloqués. Redémarrer n’est pas honteux ; parfois c’est la coupure propre nécessaire.

Stockage Ceph : les slow ops se transforment en actions lifecycle bloquées

Ceph est généralement honnête. S’il est unhealthy, il vous le dira. Mais les actions Proxmox peuvent toujours sembler « bloquées » car elles attendent des opérations RBD ralenties par le recovery, le backfill ou la latence réseau.

Patron courant : un arrêt de VM bloque parce que le flush du disque invité n’aboutit pas à temps. Ou une tâche snapshot attend des opérations metadata RBD. Si vous voyez des slow ops, arrêtez de demander « pourquoi Proxmox est bloqué » et demandez « pourquoi Ceph est lent ».

iSCSI : sessions qui meurent à moitié et prennent vos processus en otage

iSCSI peut être parfaitement ennuyeux en production, ce qui est le plus joli compliment qu’on puisse lui faire. Quand il échoue, il peut échouer lentement : un chemin flappe, multipath tente, les timeouts s’empilent, les processus se bloquent en sommeil non interruptible. Les tâches qui touchent ces LUNs vont se figer.

Si vous voyez des attentes D-state dans blk_mq_get_tag ou similaire, vous êtes côté couche bloc. Réparez le chemin (réseau, cible, multipath) avant d’essayer de tuer des jobs Proxmox.

Une citation que vous devriez vraiment intégrer

« Hope is not a strategy. » — General Gordon R. Sullivan

En termes d’ops : si votre « fix » dépend du retour spontané du stockage, ce n’est pas un fix. C’est une prière avec un numéro de ticket.

Angle cluster : pmxcfs, corosync, quorum et pourquoi les tâches « locales » bloquent

La pile de cluster de Proxmox est un multiplicateur de productivité. C’est aussi une source de modes de défaillance surprenants quand le cluster est dégradé.

pmxcfs : le système de fichiers de config qui peut vous faire douter de la réalité

/etc/pve n’est pas un répertoire normal. C’est un système de fichiers de cluster (FUSE) en RAM et synchronisé. Cela signifie :

Si pmxcfs ne peut pas engager de changements, les tâches qui écrivent les configs VM peuvent se bloquer ou échouer de façon étrange.
Si le nœud est isolé sans quorum, Proxmox peut volontairement empêcher certaines écritures pour éviter un split-brain de configuration.

Perte de quorum : le mode « tout tourne mais rien ne peut changer »

Perdre le quorum n’arrête pas nécessairement vos VMs en cours. Ça empêche les changements coordonnés. Les gens interprètent cela comme « Proxmox est bloqué ». Ce n’est pas bloqué ; il refuse de faire des changements non sûrs.

Si vous êtes sur un nœud isolé et que vous forcez son comportement en mode « seul », vous pourriez avancer. Vous pourriez aussi finir avec des configs VM conflictuelles quand le cluster reviendra. Choisissez ce compromis intentionnellement, pas émotionnellement.

Blague n°2 : Corosync sans quorum, c’est comme une réunion sans procès-verbal — chacun se souvient d’une vérité différente, et elles sont toutes fausses.

Trois mini-récits d’entreprise venus du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

L’équipe avait un cluster Proxmox avec NFS pour les sauvegardes. Une nuit, les jobs de sauvegarde ont commencé à s’empiler. L’UI affichait « running » pendant des heures. Un ingénieur senior a supposé, à raison, que le processus de sauvegarde était juste lent parce que le job hebdomadaire touchait plus de données.

Ils ont donc attendu. Puis attendu plus longtemps. Les opérations d’arrêt VM ont aussi commencé à bloquer. L’hypothèse est devenue « Proxmox est surchargé ». Ils ont redémarré pvedaemon et pveproxy pour « nettoyer les tâches ». L’UI s’est rafraîchie, et ça a semblé mieux pendant dix minutes — jusqu’à ce que ce ne soit plus le cas.

Le vrai problème : le serveur NFS avait un souci de chemin réseau. Le montage était hard, donc les processus étaient bloqués en D-state. Redémarrer les démons n’a rien fait à part enlever des traces faciles dans les logs et embrouiller la rotation d’astreinte.

La récupération a été brutale : restaurer le chemin NFS, attendre que le noyau déroule les appels bloqués, puis annuler les jobs et nettoyer les archives partielles. Ils ont aussi retenu une règle : quand vous voyez D-state avec un wchan NFS, votre « sauvegarde bloquée » est un incident NFS. Escaladez en conséquence.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une entreprise voulait des sauvegardes plus rapides. Ils ont changé la compression de vzdump pour un réglage plus lourd et augmenté la concurrence pour que plus de VMs soient sauvegardées en parallèle. Les graphes CPU semblaient « corrects » en heures normales, donc le changement a été validé. C’était une optimisation, après tout.

La nuit de sauvegarde est arrivée. Le pool ZFS a subi une amplification d’écriture élevée sous snapshots concurrents et compression, la cible NFS de sauvegarde est devenue le goulot suivant, et la latence a grimpé. Quelques invités sont devenus lents. Des « qm shutdown » ont commencé à expirer parce que les commandes QMP attendaient des flushs I/O.

L’équipe a répondu en tuant les tâches bloquées, ce qui a libéré des verrous mais n’a pas réduit la pression sous-jacente. Maintenant ils avaient des artefacts de sauvegarde partiels et des retries qui s’accumulaient. Ça s’est transformé en un thundering herd auto-infligé.

La correction fut presque ennuyeuse : réduire la concurrence, choisir une compression adaptée à l’équilibre CPU/stockage, échelonner les jobs lourds, et surveiller iowait et la latence stockage, pas seulement l’utilisation CPU. La leçon : « sauvegardes plus rapides » est un problème système, pas un seul réglage. Si vous optimisez un composant, un autre prendra feu.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une autre organisation avait une règle : chaque nœud dispose d’une petite checklist « break-glass » dans un runbook — comment identifier des tâches par UPID, comment trouver les PIDs, et quels logs capturer avant d’intervenir. Personne ne l’aimait. Ça ressemblait à de la paperasse pour machines.

Pendant une fenêtre de maintenance, un chemin iSCSI a flappé. Quelques VMs allaient bien. Deux VMs avaient des opérations stop qui ont bloqué, et un job de réplication a gelé. L’astreinte a suivi la checklist : capturer les logs de tâche, confirmer l’état des processus, vérifier les messages noyau, valider multipath, et seulement alors décider d’un redémarrage contrôlé des services affectés.

Ils ont remarqué le détail critique tôt : les processus bloqués étaient en D-state côté couche bloc, donc les tuer n’aurait pas fonctionné. Au lieu de cela, ils ont restauré le chemin iSCSI, confirmé la reprise des I/O, puis relancé proprement les actions stop. Aucune corruption, pas de redémarrages paniqués, pas de mystère.

La « pratique ennuyeuse » a fait la différence. Sous stress, vous ne vous élevez pas au niveau ; vous retombez au niveau de vos habitudes opérationnelles. Leur habitude était : preuve d’abord, action ensuite.

Erreurs communes : symptôme → cause racine → correctif

Cette section est délibérément spécifique. Les conseils génériques coûtent peu ; le downtime, lui, coûte cher.

1) Symptom : « TASK OK » n’apparaît jamais ; l’UI affiche « running » indéfiniment

Cause racine : Le processus worker est bloqué en I/O noyau (D-state), ou l’UI ne peut pas se mettre à jour à cause de pmxcfs/problème de cluster.
Fix : Trouvez le PID, vérifiez ps STAT et wchan, consultez dmesg. Si D-state, réparez stockage/réseau. Sinon, utilisez cancel de tâche et terminez proprement les processus enfants.

2) Symptom : « cannot lock file /var/lock/qemu-server/205.conf »

Cause racine : Un verrou valide détenu par un job actif, ou un verrou obsolète après un crash.
Fix : Confirmez qu’aucune tâche n’exécute cette VM ; inspectez qm config pour le lock ; puis qm unlock 205. Si l’action VM est toujours en cours, résolvez-la d’abord.

3) Symptom : vzdump bloqué à « 0% (loading) »

Cause racine : En attente de flush/snapshot de stockage ou cible de sauvegarde morte (NFS/SMB).
Fix : Vérifiez l’état du processus ; vérifiez la santé du montage ; vérifiez le chemin réseau ; pour des problèmes de montage NFS hard, restaurez le serveur ou planifiez un redémarrage contrôlé.

4) Symptom : qm stop bloque ; timeouts QMP

Cause racine : QEMU bloqué sur flush disque ou teardown de device ; guest agent absent ; latence stockage élevée.
Fix : Essayez qm shutdown d’abord ; vérifiez qm monitor ; inspectez la santé du stockage et les messages noyau. Si QEMU est en D-state, réparez le chemin I/O. Force stop uniquement si vous acceptez l’impact possible sur le filesystem invité.

5) Symptom : LXC stop bloque

Cause racine : Processus du conteneur bloqués sur NFS à l’intérieur du conteneur, ou freezer cgroup noyau en attente.
Fix : Identifiez le PID init du conteneur, inspectez les états de processus, vérifiez les montages utilisés par le conteneur. Réparez le chemin de stockage ; puis réessayez stop. Évitez de forcer le kill à moins de comprendre le risque pour les workloads.

6) Symptom : les tâches échouent aléatoirement après un hic de cluster

Cause racine : Perte de quorum ou pmxcfs non sain ; écritures de config bloquées.
Fix : Vérifiez pvecm status, restaurez le quorum, confirmez que /etc/pve est réactif. Évitez de faire des changements de config quand vous êtes non-quorate, sauf si vous avez explicitement accepté le risque de split-brain (généralement vous ne le faites pas).

7) Symptom : jobs de réplication bloqués ; zfs send n’avance pas

Cause racine : Destination lente ou injoignable, goulot réseau, snapshots qui retiennent, ou contention du pool source.
Fix : Vérifiez l’état du processus zfs send ; vérifiez le réseau ; validez la santé du dataset de destination ; réduisez la charge concurrente (scrubs/resilver) pendant les fenêtres de réplication.

Checklists / plans pas à pas

Checklist A : Dérouler en sécurité une sauvegarde vzdump bloquée

Récupérez l’UPID depuis les tâches en cours (pvesh get /nodes/NODE/tasks --running 1).
Récupérez le log de la tâche et notez la dernière ligne de progression.
Trouvez les PIDs (worker + vzdump + helpers) avec ps et pstree.
Vérifiez l’état avec ps -o stat,wchan.
Si D-state sur NFS/couche bloc : réparez le chemin stockage d’abord. Ne perdez pas de temps avec des signaux.
Si blocage en espace utilisateur : essayez pvesh .../cancel, puis kill -TERM des helpers, puis le parent si nécessaire.
Vérifiez le nettoyage des verrous sur la VM et qu’aucune autre tâche n’est bloquée derrière.
Vérifiez les fichiers d’archive partiels sur le backup store et supprimez-les seulement après avoir confirmé qu’ils sont incomplets et non référencés par un processus encore en écriture.
Lancez un job de sauvegarde unique avec une concurrence réduite pour valider le chemin avant de reprendre le planning.

Checklist B : Gérer en sécurité une tâche « stop » bloquée pour une VM

Confirmez que la VM tourne réellement : ps pour le PID QEMU et qm status VMID.
Tentez qm shutdown (gracieux). Si le guest agent est présent et fonctionnel, c’est encore mieux.
Vérifiez la réactivité QMP : qm monitor VMID --cmd 'info status'.
Si QEMU répond mais que le stop bloque : investiguez la latence stockage et les logs de teardown de device ; envisagez un timeout plus long.
Si QEMU est en D-state : réparez le chemin stockage. Pour des pannes sévères, planifiez un redémarrage du nœud ; ne faites pas confiance aux kills forcés.
Dernier recours uniquement : qm stop VMID (force). Documentez le risque et suivez avec des vérifications de filesystem invité si nécessaire.
Après récupération : nettoyez le verrou Proxmox (qm unlock VMID) si besoin, mais seulement après avoir vérifié qu’aucune tâche stop active ne subsiste.

Checklist C : Quand vous suspectez un souci de cluster/pmxcfs

Vérifiez le quorum : pvecm status.
Consultez la santé de corosync dans les logs : journalctl -u corosync --since "30 min ago".
Testez la réactivité de /etc/pve (des lectures simples comme ls ne devraient pas bloquer).
N’effectuez pas d’opérations changeant la config si vous êtes non-quorate, sauf si vous avez explicitement accepté le risque de split-brain.
Restaurez le réseau entre nœuds, corrigez les problèmes de synchronisation temporelle, puis vérifiez le retour du quorum.
Une fois le cluster stable, revérifiez les tâches en cours ; beaucoup de « bloquées » deviennent soudainement des « échouées » et peuvent être relancées proprement.

FAQ

1) Puis-je simplement redémarrer pvedaemon pour nettoyer les tâches bloquées ?

Vous pouvez, mais ce n’est rarement le bon premier geste. Si un worker est bloqué en D-state à cause du stockage, redémarrer les démons ne le débloquera pas. Vous perdrez juste la continuité des logs et vous embrouillerez le suivi des tâches.

2) Quelle est la manière la plus sûre d’arrêter une sauvegarde bloquée ?

Demandez l’annulation via l’endpoint de tâche, puis terminez les processus enfants doucement (TERM) s’ils sont en espace utilisateur. S’ils sont en D-state, réparez d’abord le stockage ; sinon vous créerez un bazar sans réellement « arrêter ».

3) Comment savoir si un verrou est obsolète ?

Corrélez-le avec les tâches en cours et les processus réels. Si la VM a lock: défini mais qu’il n’y a aucune tâche correspondante en cours et aucun arbre de processus pertinent, il est probablement obsolète. Alors qm unlock est approprié.

4) Pourquoi « kill -9 » ne fonctionne-t-il pas parfois ?

Parce que le processus est coincé en sommeil non interruptible (D-state) dans le noyau, généralement en attente d’E/S. Le signal est mis en file mais n’est pas traité jusqu’au retour de l’appel noyau.

5) Est-il sûr de supprimer des fichiers de sauvegarde partiels sur le backup store ?

Généralement oui — après avoir confirmé qu’aucun processus n’écrit encore dedans et que vous avez décidé que l’archive est incomplète. Supprimer un fichier encore ouvert par un processus peut empirer le dépannage et ne vous libère pas forcément du blocage sous-jacent.

6) Ma VM ne veut pas s’arrêter et QMP expire. La VM est-elle corrompue ?

Pas nécessairement. Cela signifie souvent que QEMU ne peut pas terminer un flush I/O ou une opération device, donc il ne peut pas répondre. Le risque de corruption augmente si vous terminez brutalement sans résoudre l’I/O.

7) Ceph HEALTH_WARN veut-il dire que je peux l’ignorer pour l’instant ?

Non. « WARN » signifie souvent « la latence est déjà suffisamment mauvaise pour bloquer des opérations de plus haut niveau ». Les slow ops sont le canari ; les tâches Proxmox bloquées sont l’effondrement.

8) Quand un redémarrage de nœud est-il la bonne réponse ?

Quand des processus critiques sont bloqués en D-state à cause d’un chemin I/O qui ne peut être restauré rapidement, ou quand des threads noyau sont wedgés et empêchent une récupération propre. Le reboot est un reset contrôlé, pas un aveu d’échec moral.

9) Pourquoi des tâches « locales » échouent-elles quand le cluster a des problèmes de quorum ?

Parce que « local » touche souvent des configs synchronisées par le cluster dans /etc/pve. Si pmxcfs est mal en point ou si les écritures sont bloquées à cause du quorum, les tâches peuvent se figer ou refuser d’avancer.

10) Comment empêcher la récurrence des tâches bloquées ?

Concevez pour une latence I/O prévisible : dimensionnez le stockage, limitez la concurrence des backups, séparez le trafic de sauvegarde, surveillez les hung tasks noyau, et traitez les warnings de stockage comme des incidents, pas de la trivia.

Conclusion : étapes suivantes pour éviter les récidives

Les tâches Proxmox bloquées ne sont généralement pas mystérieuses. Elles sont habituellement l’une de trois choses : blocages de stockage, verrous obsolètes, ou problèmes de coordination de cluster. La différence entre une récupération propre et une pagaille, c’est d’identifier à quelle catégorie vous avez affaire avant de commencer à tuer des processus.

Faites ceci ensuite :

Adoptez l’entonnoir de diagnostic rapide : stockage vs cluster vs processus par invité.
Apprenez à votre équipe à reconnaître l’état D et à cesser de perdre du temps sur des signaux quand le noyau attend des E/S.
Imposez des limites sensées sur la concurrence des sauvegardes et planifiez les opérations lourdes (scrub, réplication, grosses sauvegardes) comme si la latence comptait réellement.
Quand vous nettoyez des verrous, faites-le comme un chirurgien : vérifiez, puis coupez. Ne faites pas du freestyle.