Proxmox « TASK ERROR: timeout waiting for … » : identifier ce qui a réellement expiré

octobre 6, 2025 • février 3, 2026 • Lecture : 33 min • Views: 9

Cet article vous a aidé ?

Vous avez cliqué sur un bouton dans Proxmox. Démarrer une VM. Arrêter un conteneur. Snapshot. Sauvegarde. Migration. Et puis : TASK ERROR: timeout waiting for …. L’interface affiche une expression nominale vague et une horloge qui vient de s’écouler. En production, elle vous donne des utilisateurs énervés et une horloge qui ne s’arrête jamais.

Le mouvement clé est d’arrêter de considérer le « timeout » comme le problème. Un timeout Proxmox est un symptôme : un processus attendait un verrou spécifique, un état du noyau, une opération de stockage ou une étape du système de fichiers de cluster, et cela ne s’est pas terminé avant que Proxmox abandonne. Votre travail consiste à identifier ce à quoi il attendait réellement, puis à réparer le sous-système qui s’est bloqué.

Ce que sont réellement les timeouts Proxmox (et pourquoi l’UI cache la vérité)

Proxmox est un orchestrateur. Il coordonne beaucoup d’éléments : services systemd, QEMU, LXC, ZFS, Ceph, périphériques blocs du noyau, stockage réseau et un système de fichiers de configuration de cluster. Quand vous cliquez sur « Stop », Proxmox n’arrête pas une VM par magie. Il demande poliment à QEMU, attend que le système invité coopère, escalade peut-être en envoyant un SIGKILL, puis attend le détachement des périphériques blocs, le démappage des volumes et la libération des verrous de configuration.

Le message « timeout waiting for … » est généralement émis par une couche Perl de Proxmox (aides pvedaemon/pveproxy) attendant une transition d’état. Les timeouts varient selon l’opération, et ils gardent souvent contre le pire scénario : une tâche bloquée de façon permanente qui détient un verrou et bloque tout le reste.

Voilà la philosophie. La réalité est désordonnée : si le noyau est bloqué en attente d’I/O, Proxmox va « timeout waiting for … » quelque chose de parfaitement raisonnable, comme un démappage de périphérique, alors que le vrai problème est un HBA mort, un chemin multipath bloqué ou un OSD Ceph instable. Il faut relier la phrase du journal de tâche à la chaîne de dépendance concrète.

Voici le modèle mental qui fonctionne réellement :

Tâche Proxmox (UPID) s’exécute comme un processus.
Elle attend une condition : verrou, sortie d’un PID, opération de volume, mise à jour d’un fichier de configuration de cluster.
La condition dépend d’un sous-système : noyau, stockage, réseau, cluster, OS invité.
Le timeout vous indique quelle condition n’a pas été satisfaite. Les logs vous disent pourquoi.

Une vérité opérationnelle : « timeout waiting for … » signifie souvent que Proxmox dit poliment « quelque chose est bloqué en D-state et je ne peux pas le tuer ». Si vous n’avez pas encore cherché le D-state, vous êtes encore en train de deviner.

Blague #1 (courte et méritée) : Quand Proxmox dit « timeout waiting for lock », c’est essentiellement votre datacenter qui fait la danse de la porte « après vous »… pour toujours.

Méthode de diagnostic rapide : contrôles premier/second/troisième qui trouvent le goulot

Si vous ne faites qu’une chose différemment après avoir lu ceci : arrêtez de courir après la chaîne de l’UI. Commencez par le UPID, identifiez le processus bloquant, puis identifiez le sous-système par rapport auquel ce processus est bloqué.

Premier : Le nœud lui-même est-il malade ?

Vérifiez la charge, le D-state, la pression mémoire et les blocages d’I/O du noyau. Si le nœud est malsain, toutes les tâches sont suspectes.
Si vous voyez de nombreux processus en D-state, traitez cela comme un incident de stockage jusqu’à preuve du contraire.

Second : Est-ce l’I/O de stockage, le plan de contrôle du stockage ou un verrou de cluster ?

Plan de données du stockage : lectures/écritures lentes, démappage bloqué, flushs en attente, resets SCSI.
Plan de contrôle du stockage : monitors Ceph lents, groupes de transactions ZFS bloqués, sessions iSCSI instables.
Verrou de cluster : contention sur pmxcfs ou une tâche morte détenant un fichier lock.

Troisième : Est-ce un invité qui refuse de coopérer ?

Les timeouts d’arrêt de VM sont souvent juste un invité ignorant l’ACPI.
Mais si l’arrêt bloque sur le détachement d’un périphérique, c’est toujours du stockage/hôte.

Checklist de triage rapide (à exécuter immédiatement)

Trouvez le UPID dans la vue des tâches ; mettez-le en correspondance avec les lignes de log dans /var/log/pve/tasks/.
Identifiez le PID et le point d’attente exact (verrou vs I/O vs sortie de processus).
Vérifiez dmesg pour les resets/timeouts de stockage pendant la même fenêtre temporelle.
Vérifiez la santé de Ceph ou de ZFS (selon le backend).
Vérifiez le quorum du cluster et la réactivité de pmxcfs si la configuration/les verrous sont impliqués.

Cartographier « waiting for … » vers le sous-système réel

Les chaînes « waiting for … » de Proxmox ne sont pas aléatoires. Elles correspondent généralement à l’une de ces catégories :

1) Waiting for a lock (sérialisation de configuration et cycle de vie)

Phrases communes : « timeout waiting for lock », « can’t lock file », « lock for VM … », « lock for storage … ».

Ce qui a réellement expiré : une acquisition de verrou dans Proxmox (souvent sous /var/lock/pve-manager/ ou un verrou à l’intérieur de pmxcfs), ou un verrou détenu par une autre tâche qui ne s’est jamais terminée.

Causes probables : une tâche précédente bloquée (souvent due au stockage), ou pmxcfs lent/inaccessible à cause de problèmes de cluster.

2) Waiting for process exit (cycle de vie QEMU/LXC)

Phrases communes : « timeout waiting for VM to shutdown », « timeout waiting for ‘qemu’ to stop », « timeout waiting for CT to stop ».

Ce qui a réellement expiré : Proxmox a envoyé une demande d’arrêt/stop et a attendu que QEMU/LXC se termine ; ce n’est pas arrivé. QEMU peut être bloqué en I/O noyau, l’invité peut ignorer l’arrêt, ou QEMU est en pause en attendant le stockage.

3) Waiting for storage operations (create/destroy/snapshot/clone/unmap)

Phrases communes : « timeout waiting for RBD unmap », « timeout waiting for zfs destroy », « timeout waiting for lvremove », « timeout waiting for qm » (pendant des opérations disque), « timeout waiting for vzdump ».

Ce qui a réellement expiré : une commande de stockage (rbd, zfs, lvm, iscsiadm, mount) n’a pas abouti. C’est l’endroit où le noyau et le backend de stockage se rencontrent — et se disputent.

4) Waiting for cluster filesystem updates (pmxcfs)

Phrases communes : « timeout waiting for pmxcfs », « unable to read/write /etc/pve/… », « cfs-lock ‘…’ timed out ».

Ce qui a réellement expiré : pmxcfs n’a pas pu compléter un verrou ou une mise à jour assez rapidement. Les causes racines incluent corosync/quorum, CPU saturé, ou un disque plein empêchant les écritures (oui, vraiment).

5) Waiting for networking (migration and remote storage)

Phrases communes : « migration aborted: timeout », « waited too long for … », « ssh connection timeout » (parfois caché derrière des timeouts génériques de tâches).

Ce qui a réellement expiré : TCP bloqué, mauvaise MTU, perte de paquets, ou le côté distant bloqué sur du stockage.

Disséquer la tâche Proxmox : du UPID à l’appel système bloquant

Les tâches Proxmox sont journalisées avec un UPID (Unique Process ID) qui encode le nœud, le PID, l’heure de démarrage et le type de tâche. Votre flux de travail doit traiter le UPID comme la clé primaire.

Voici une manière pratique de couper à travers le bruit :

Trouvez le UPID dans le journal de tâches de l’interface.
Ouvrez le fichier de tâche sur le nœud pour voir les étapes internes exactes et les horodatages.
Trouvez le PID du worker et inspectez son état (running, D-state, blocked).
Utilisez des outils au niveau du noyau (backtraces, statistiques I/O) pour voir ce sur quoi il attend.

Si vous ne lisez que le message de haut niveau de Proxmox, vous manquerez la partie où le noyau hurle « SCSI timeout » depuis dix minutes dans dmesg.

Une citation, parce que c’est toujours un phare pour les opérations : « Hope is not a strategy. » — General Gordon R. Sullivan

Tâches pratiques : commandes, what the output means, and the decision you make

Ce ne sont pas des commandes « agréables à connaître ». Ce sont celles que vous exécutez pendant que quelqu’un attend une restauration, votre HA vacille et vous devez décider s’il faut redémarrer un nœud ou vérifier un câble.

Task 1: Find the task’s UPID log file and read it like a timeline

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

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

Signification : Vous connaissez maintenant la commande exacte et le paramètre de timeout impliqué (qm shutdown --timeout 60).

Décision : Si l’invité ne répond pas à l’ACPI, vous pouvez escalader vers qm stop. Si cela se répète et coïncide avec des erreurs de stockage, diagnostiquez d’abord l’I/O hôte.

Task 2: Correlate Proxmox task timestamps with journal logs

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

Signification : Confirme quel démon l’a exécutée et quand il a échoué.

Décision : Si pvedaemon timeoute de façon répétée sur plusieurs tâches, regardez la santé du nœud et du stockage plutôt que des VMs individuelles.

Task 3: Identify whether the worker process is stuck (and in what state)

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

Signification : QEMU est en D-state (D dans STAT) et attend dans io_schedule. Ce n’est pas « l’invité ne veut pas s’arrêter ». C’est « le noyau hôte attend de l’I/O ».

Décision : Arrêtez d’essayer de tuer QEMU. Enquêtez sur le stockage et les logs du noyau. Un redémarrage peut être la seule issue si le noyau ne peut pas compléter l’I/O.

Task 4: Check dmesg for storage timeouts/reset storms around the failure

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

Signification : C’est la preuve irréfutable de « ce qui a réellement expiré » : la couche bloc du noyau n’a pas pu compléter l’I/O. Proxmox attendait juste.

Décision : Traitez comme un incident de stockage : vérifiez câblage/HBA/chemins, multipath, santé du RAID/array, et envisagez d’évacuer les VMs.

Task 5: Determine if pmxcfs (/etc/pve) is slow or blocked

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

Signification : Si ceci se bloque ou expire, votre système de fichiers de cluster est malade. Quand ls sur /etc/pve se bloque, beaucoup d’erreurs « timeout waiting for lock » en aval ne sont que du bruit.

Décision : Vérifiez corosync/quorum, le processus pmxcfs et la saturation des ressources du nœud avant de toucher aux opérations VM.

Task 6: Check quorum and corosync status (cluster-level timeouts)

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

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

Signification : Si Quorate: No ou si des nœuds fluctuent, les verrous pmxcfs peuvent se bloquer ou échouer.

Décision : Stabilisez le réseau du cluster avant de vous fier aux diagnostics « timeout waiting for lock ».

Task 7: Identify which lock is held and by what task

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

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

Signification : Le verrou n’est pas mystique. C’est un fichier, et un PID le tient ouvert.

Décision : Cherchez pourquoi ce PID est bloqué. Tuer le worker peut libérer le verrou, mais s’il est en D-state, vous ne le tuerez pas. Réparez l’I/O sous-jacent ou planifiez un redémarrage du nœud.

Task 8: Inspect a stuck PID with kernel stack traces (advanced, decisive)

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

Signification : QEMU est bloqué en attente que flush/fsync se termine. C’est du stockage. Possiblement le périphérique de backing est bloqué, saturé, ou un fencing est en cours.

Décision : Arrêtez d’ajuster les timeouts d’arrêt des invités. Allez réparer le chemin de stockage ou le backend.

Task 9: If using ZFS, check pool health and spot latency sources

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

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

errors: No known data errors

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

Signification : zpool status vous indique si vous êtes dégradé/échec ; zpool iostat montre si vous soumettez fortement le pool. Toutes les latences ne se manifestent pas par un état DEGRADED — la latence peut être terrible même sur des pools « ONLINE ».

Décision : Si iostat montre beaucoup d’écritures et que vos tâches impliquent snapshots/destroys, considérez la contention (fenêtre de sauvegarde, réplication, scrub) et limitez ou replanifiez.

Task 10: If using Ceph, check cluster health and slow ops

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

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

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

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

Signification : Les slow ops sont votre « ce qui a réellement expiré ». Proxmox attend une opération RBD ; Ceph est bloqué pour la terminer.

Décision : Arrêtez de relancer les tâches Proxmox. Stabilisez Ceph : vérifiez la latence OSD, la pression de backfill/recovery, le réseau et les disques défaillants.

Task 11: If using iSCSI/multipath, verify sessions and path health

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

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

Signification : Si des sessions manquent ou si des chemins affichent failed/faulty, vos timeouts sont l’hôte attendant sur un chemin mort. Si vous voyez queue_if_no_path, l’I/O peut se bloquer « poliment » plutôt que d’échouer rapidement.

Décision : Réparez le routage des chemins avant de toucher Proxmox. Réfléchissez à si vos options multipath conviennent à la virtualisation ; se bloquer indéfiniment est rarement souhaitable.

Task 12: For NFS/CIFS storage, find out if mounts are stuck (classic “everything hangs”)

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

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

Signification : Si stat se bloque, NFS est bloqué et votre « timeout waiting for … » est un effet en aval. Avec des montages hard, les processus peuvent rester en D-state pour toujours en attendant le serveur.

Décision : Réparez d’abord le NAS/réseau. Pensez aux options de montage et à la surveillance pour qu’un serveur de fichiers instable ne fige pas tout votre nœud.

Task 13: Confirm whether vzdump/backups are the hidden lock-holder

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

Signification : Une sauvegarde en cours peut détenir des verrous de snapshot ou de configuration, ou tout simplement saturer le stockage et faire expirer d’autres tâches.

Décision : Si des sauvegardes chevauchent des opérations critiques, programmez mieux ou acceptez le risque. Choisissez délibérément.

Task 14: Check node-level I/O pressure quickly

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

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

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

Signification : %iowait est énorme ; await et %util sont élevés. Votre nœud attend le stockage. Les timeouts Proxmox ne sont que le messager.

Décision : Limitez la charge, mettez en pause les jobs lourds, enquêtez sur la saturation ou la défaillance du backend. Si c’est un array partagé, coordonnez-vous avec l’équipe stockage (ou devenez l’équipe stockage).

Modes de défaillance spécifiques au stockage (ZFS, Ceph, iSCSI/NFS)

La plupart des incidents « timeout waiting for … » dans Proxmox sont des incidents de stockage déguisés en UI de gestion. L’UI timeoute parce que le stockage est lent. Ou absent. Ou « à moitié là mais ne répond pas », ce qui est pire.

ZFS : quand « ONLINE » fait encore mal

ZFS est excellent pour l’intégrité des données et honnête sur les défaillances. Il n’a pas l’obligation d’être rapide quand vous lui demandez des opérations coûteuses en métadonnées pendant que vous écrasez le pool avec des écritures VM.

Patrons de timeout que vous verrez :

Opérations snapshot/destroy/clone qui se bloquent à cause d’une forte pression TXG ou d’un flush de périphérique lent.
Arrêts/stop de VM qui se bloquent parce que QEMU attend fsync/flush vers le ZVOL de backing.
Jobs de réplication qui expirent parce que l’envoi de snapshots ne suit pas ou le réseau est congestionné.

À regarder :

Latence au niveau du pool : iostat await et débit zpool iostat.
Pression ARC et mémoire : ZFS consomme de la mémoire avec des opinions.
Temps de sync des groupes de transactions : des syncs longs signifient que tout ce qui a besoin d’un sync attend plus longtemps.

Ceph RBD : la santé du plan de contrôle devient latence du plan de données

Le truc de Ceph est la fiabilité distribuée. Son impôt est que quand le cluster est malsain, même des opérations « simples » peuvent ralentir : mapping/démappage RBD, snapshots, resize d’image, flatten, etc.

Patrons de timeout :

« timeout waiting for RBD unmap » pendant l’arrêt de VM, le nettoyage de migration ou la suppression d’un disque.
Les tâches de sauvegarde expirent car les lectures sont lentes durant recovery/backfill.
Le basculement HA semble cassé parce que les opérations de stockage sont bloquées, pas parce que HA est stupide.

Vérifications spécifiques Ceph :

Les slow ops plus anciennes qu’une minute ne sont pas du « bruit normal » ; elles indiquent famine de ressources, problème réseau ou disques défaillants.
Si Ceph est en recovery/backfill intensif, les tâches Proxmox qui attendent des réponses rapides de stockage vont timeout. Ajustez la recovery ou planifiez les opérations disruptives hors des pics.

iSCSI et multipath : la joie de « queue_if_no_path »

Les pires échecs iSCSI ne sont pas les plus bruyants. Ce sont les blocages silencieux : un chemin meurt, multipath met en file l’I/O, et tous les processus accédant à ce LUN entrent en D-state. Proxmox ne sait pas. Il attend qu’une commande se termine. Elle ne se termine jamais.

Si vous virtualisez sur iSCSI, vous devez décider — explicitement — si vous préférez :

Fail fast : les tâches échouent, les VMs plantent ou se figent, mais le nœud est récupérable sans redémarrage.
Bloquer indéfiniment : le plan de données attend que le stockage revienne, ce qui peut figer votre hyperviseur.

Ne laissez pas la politique multipath par défaut décider pour vous. Les valeurs par défaut sont décidées par des comités, et les comités ne reçoivent pas d’alertes au pager.

NFS : les montages « hard » peuvent geler aussi la gestion

Avec NFS, une surprise courante est que le stockage n’est pas seulement là où résident les disques ; c’est aussi là où résident les sauvegardes, les templates et parfois les ISO. Un montage NFS bloqué peut fairehanguer les jobs de sauvegarde, mais aussi bloquer les opérations qui essaient de lister ou de mettre à jour le contenu de ce stockage.

Quand NFS flanche, Proxmox peut timeout en attendant un scan de stockage, une écriture de sauvegarde ou une opération de montage. Pendant ce temps, vos commandes shell se bloquent, et votre plan de redémarrage simple devient un plan de fencing.

Système de fichiers de cluster et verrous : pmxcfs, corosync, et folklore sur les verrous persistants

La configuration de cluster de Proxmox vit dans /etc/pve, soutenue par pmxcfs. C’est pratique et c’est aussi la raison pour laquelle un « problème de stockage » peut se manifester comme un « impossible d’écrire la config » si le nœud est surchargé ou si le cluster est instable.

Symptômes pmxcfs qui se déguisent en tout le reste

Les commandes CLI se bloquent quand elles accèdent à /etc/pve (par ex. qm config).
« timeout waiting for cfs-lock » lors des démarrages/arrêts de VM, surtout autour de HA ou des migrations.
L’interface devient lente car pveproxy appelle et modifie la config du cluster en boucle.

Les verrous : le bon, le mauvais et le bloqué

Les verrous existent pour empêcher deux opérations d’écraser la même config VM ou l’état disque. Ils sont corrects. Ils sont aussi pénibles quand le détenteur est mort.

Règles qui vous sauvent :

Ne supprimez jamais les fichiers de verrou aveuglément comme première mesure. Si le verrou protège une opération de stockage en cours, vous pouvez créer un split-brain au niveau VM (deux actions conflictuelles) même si le cluster est sain.
Identifiez le PID propriétaire du verrou. S’il s’agit d’un processus bloqué normal (pas en D-state), vous pouvez le terminer proprement. S’il est en D-state, n’espérez pas que les signaux fonctionnent.
Les timeouts de verrou sont souvent secondaires. Un démappage de stockage bloqué provoque une tâche coincée ; la tâche coincée détient le verrou ; la tâche suivante timeoute en attendant le verrou.

Blague #2 (courte et trop vraie) : Vous ne pouvez pas kill -9 un processus en D-state. C’est la façon de Linux de dire « veuillez patienter ».

Trois micro-récits issus du monde de l’entreprise

Micro-récit 1 : L’incident provoqué par une mauvaise hypothèse

Ils faisaient tourner un petit cluster Proxmox pour des services internes : ticketing, runners CI, quelques bases de données « pas critiques » (jusqu’au jour où elles le furent). Un matin, des arrêts de VM ont commencé à échouer avec « TASK ERROR: timeout waiting for shutdown ». L’on-call a supposé que c’était un problème d’OS invité : « Windows updates encore », quelqu’un marmonna, confiant et erroné.

Ils ont augmenté le timeout d’arrêt. Puis ils ont essayé qm stop. Ça a bloqué. Ils ont tenté de tuer QEMU. Il n’est pas mort. Ils ont redémarré pvedaemon. Même chose. Entre-temps, d’autres tâches se sont mises en file et ont toutes expiré en attendant des verrous.

Le tournant a été un simple ps montrant plusieurs processus QEMU en D-state, tous en attente dans io_schedule. Un rapide coup d’œil à dmesg a montré une tempête de timeouts SCSI sur un chemin. Multipath était configuré pour mettre en file l’I/O quand des chemins disparaissent. Parfait pour certains workloads. Catastrophique pour un hyperviseur quand le contrôleur de l’array a redémarré.

La correction n’était pas « plus de timeout ». La correction était de restaurer un chemin sain (et plus tard de changer le comportement multipath pour que l’hôte échoue plus vite afin de récupérer). Le postmortem était direct : un timeout d’arrêt de VM concerne rarement l’arrêt si l’hyperviseur est bloqué sur l’I/O. Ils ont commencé à traiter « D-state + timeouts » comme un incident de stockage par défaut, ce qui a rendu les incidents suivants plus courts et moins théâtraux.

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

Une autre entreprise voulait des sauvegardes plus rapides. Ils avaient une fenêtre nocturne de vzdump qui débordait sur les heures de travail. Quelqu’un a proposé un « gain facile » : activer plus de parallélisme et pousser les sauvegardes snapshot davantage. Le stockage était « largement suffisant », selon des pics de débit sur une slide du vendeur.

Les premières nuits étaient bonnes. Les sauvegardes finissaient plus tôt. Puis le cluster a eu une journée avec une charge d’écriture plus élevée. Pendant le chevauchement de la fenêtre de sauvegarde, les commits de snapshot et les nettoyages ont déclenché une vague d’erreurs timeout waiting for … : commits de snapshot qui se bloquent, arrêts de VM qui expirent, réplication en retard. L’équipe d’ops a chassé des verrous, tué des tâches et combattu des symptômes.

La cause réelle était la latence transactionnelle : les temps de sync ZFS ont explosé sous la concurrence de snapshots et d’écritures VM. Le pool est resté « ONLINE », mais la latence est devenue horrible. Les timeouts Proxmox n’avaient pas menti ; ils étaient juste impatients. L’optimisation — plus de parallélisme — a amplifié la latence.

La correction n’a pas été spectaculaire : ils ont réduit la concurrence des sauvegardes, déplacé les jobs les plus lourds dans une fenêtre séparée et ajouté des alertes simples sur la latence I/O. Le débit est resté correct et le système a cessé de timeout. La leçon est classique SRE : optimiser pour une métrique que vous pouvez exhiber (durée de sauvegarde) peut détruire silencieusement une métrique que les utilisateurs ressentent (latence de queue).

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

Un environnement réglementé faisait tourner Proxmox avec Ceph. Rien d’excitant, par conception. Leur pratique « ennuyeuse » était la corrélation stricte : chaque échec de tâche devait être lié à un signal de santé backend horodaté (détail santé Ceph, logs noyau, erreurs réseau). Pas d’exceptions. Ça paraissait bureaucratique jusqu’au jour où ce ne l’était plus.

Un après-midi, des migrations ont commencé à échouer avec des timeouts, et quelques arrêts de VM ont bloqué. Les messages UI variaient — certains parlaient de timeouts de stockage, d’autres semblaient être des timeouts de verrous. Les ingénieurs étaient tentés d’attribuer ça aux mises à jour Proxmox de la semaine précédente. La pratique ennuyeuse les a forcés à extraire les slow ops Ceph et les logs noyau pour la même tranche horaire.

Ils ont trouvé un motif : les slow ops augmentaient chaque fois qu’un port de switch top-of-rack clignotait. Corosync restait quoré, donc le cluster semblait « correct », mais le trafic Ceph subissait des pertes intermittentes et des retransmissions. Cela augmentait la latence, ce qui augmentait les timeouts, ce qui augmentait la contention des verrous. Une cascade d’échecs avec une face polie.

Parce qu’ils avaient l’habitude de la corrélation, l’incident n’est pas devenu une chasse aux sorcières d’une semaine. Ils ont déplacé le trafic Ceph hors du port défectueux, remplacé un transceiver, et les timeouts ont cessé. Le postmortem était ennuyeux. C’est un compliment.

Erreurs fréquentes : symptôme → cause racine → fix

1) Symptôme : « timeout waiting for lock … » sur de nombreuses VMs

Cause racine : Une tâche bloquée détient un verrou ; souvent la tâche bloquée est bloquée sur I/O stockage ou pmxcfs.

Correctif : Identifiez le propriétaire du verrou avec fuser, inspectez son état (D-state ?), puis réparez le stockage/pmxcfs. Ne supprimez pas les verrous en premier.

2) Symptôme : timeouts d’arrêt de VM, puis « qm stop » aussi bloque

Cause racine : QEMU est bloqué dans le noyau (D-state), typiquement sur flush/unmap disque ou chemin de stockage mort.

Correctif : Vérifiez ps pour D-state et dmesg pour les erreurs bloc. Restaurez la santé du stockage ; redémarrez le nœud si l’I/O noyau est irrécupérablement bloqué.

3) Symptôme : jobs vzdump expirent et laissent snapshots/verrous

Cause racine : Le stockage cible de sauvegarde est lent/inaccessible (les problèmes NFS sont fréquents), ou le commit de snapshot est lent (Ceph slow ops / latence ZFS).

Correctif : Vérifiez la réactivité des montages avec stat et la santé du backend. Réduisez la concurrence, replanifiez et surveillez le stockage de sauvegarde comme le stockage de production (parce que c’en est).

4) Symptôme : « timeout waiting for RBD unmap » pendant stop/delete

Cause racine : slow ops Ceph, I/O client bloqué, ou problèmes réseau entre le nœud et Ceph.

Correctif : Vérifiez ceph -s et ceph health detail. Si des slow ops existent, traitez Ceph en priorité. Envisagez de suspendre temporairement les opérations disruptives.

5) Symptôme : opérations touchant /etc/pve se bloquent ou échouent

Cause racine : pmxcfs est bloqué à cause d’une instabilité corosync, d’une famine CPU, ou d’un nœud bloqué.

Correctif : Vérifiez le quorum (pvecm status), examinez les logs corosync, contrôlez la pression CPU/mémoire et stabilisez le réseau du cluster.

6) Symptôme : migrations time out mais le stockage semble OK

Cause racine : congestion réseau de migration/MTU mismatch ou latence du stockage côté distant.

Correctif : Validez la santé du réseau ; lancez les migrations pendant des périodes de moindre charge ; vérifiez l’I/O wait sur source et destination. La migration implique deux nœuds et un réseau, pas une checkbox.

Listes de contrôle / plan étape par étape

Étape par étape : identifier ce qui a réellement expiré

Récupérez le UPID depuis la vue des tâches Proxmox.
Lisez le fichier de tâche dans /var/log/pve/tasks/ pour identifier la commande sous-jacente exacte et la phase qui a stagné.
Identifiez le PID worker qui détient le verrou (si applicable) avec fuser sur le fichier de verrou, ou en faisant correspondre les lignes de commande des processus.
Vérifiez l’état du processus avec ps :
- Si D : ne perdez pas de temps avec les signaux ; c’est un blocage I/O ou noyau.
- Si S/R : il peut attendre un autre processus, le réseau ou un verrou.
Vérifiez les logs du noyau (dmesg -T) pour les timeouts/resets de stockage dans la même fenêtre temporelle.
Vérifiez la santé du backend :
- ZFS : zpool status, zpool iostat
- Ceph : ceph -s, ceph health detail
- iSCSI : iscsiadm -m session, multipath -ll
- NFS : stat sur les points de montage
Décidez l’action de récupération :
- Si le stockage échoue : évacuez/migrez si possible ; arrêtez le churn ; réparez le backend ; envisagez un redémarrage si le noyau est bloqué.
- Si pmxcfs/quorum : stabilisez corosync et les communications du cluster d’abord.
- Si l’invité refuse de s’arrêter mais que l’hôte est sain : utilisez stop/kill avec conscience du risque de corruption des données.

Checklist : « Dois-je redémarrer ce nœud ? »

Y a-t-il des processus en D-state liés à des tâches critiques ?
Les logs du noyau montrent-ils des timeouts d’I/O répétés ou des événements de périphérique hors ligne ?
Le backend de stockage est-il déjà rétabli mais le nœud reste bloqué ?
Pouvez-vous migrer/évacuer les VMs d’abord (stockage partagé, HA, ou fenêtre de maintenance) ?

Si vous avez répondu oui aux deux premières questions et que vous ne pouvez pas dégager la condition, un redémarrage contrôlé est souvent la moins pire des options. La pire option est de laisser le nœud pourrir dans un état semi-mort pendant que les tâches s’accumulent et que les verrous s’additionnent.

Faits et contexte : pourquoi ces timeouts existent

Fait 1 : Le suivi des tâches Proxmox utilise des UPID pour que les opérations asynchrones soient journalisées et auditables indépendamment de la session GUI.
Fait 2 : pmxcfs est un système de fichiers cluster FUSE ; cette commodité signifie que les opérations normales peuvent se bloquer selon la santé du cluster.
Fait 3 : Le D-state Linux (sleep non interruptible) existe pour protéger l’intégrité du noyau et de l’I/O ; c’est pourquoi certains « kill » ne tuent pas.
Fait 4 : Les chemins d’arrêt QEMU impliquent souvent des sémantiques de flush de stockage ; un « timeout d’arrêt » peut être un timeout de flush disque déguisé.
Fait 5 : Les « slow ops » Ceph ne sont pas que des métriques de performance ; elles peuvent bloquer directement des opérations clientes comme RBD unmap/snapshot/remove.
Fait 6 : Le comportement « queue if no path » de multipath a été conçu pour préserver l’ordre des I/O lors d’une perte de chemin, mais il peut figer un hyperviseur si la panne dure.
Fait 7 : Les montages NFS « hard » retentent indéfiniment par défaut ; c’est bien pour la cohérence des données et terrible pour la gestion interactive quand le serveur disparait.
Fait 8 : Les workflows riches en snapshots déplacent la charge du débit pur vers les métadonnées et la latence ; les timeouts suivent souvent la latence terminale, pas la bande passante moyenne.
Fait 9 : Les timeouts de verrous de cluster apparaissent souvent après le début du véritable incident ; ils sont fréquemment des échecs secondaires issus de blocages antérieurs.

FAQ

1) Que signifie généralement « timeout waiting for lock » dans Proxmox ?

Cela signifie qu’une tâche Proxmox n’a pas pu acquérir un verrou (config VM, stockage ou config de cluster) dans le délai autorisé. La cause réelle est typiquement une tâche antérieure qui détient ce verrou — souvent parce qu’elle est bloquée sur I/O stockage ou pmxcfs.

2) Si l’arrêt d’une VM timeoute, dois-je simplement augmenter le timeout ?

Seulement si l’hôte est sain et que l’invité est simplement lent à s’arrêter. Si QEMU est en D-state ou si le nœud subit un fort iowait, augmenter le timeout ne fait que vous faire attendre plus longtemps pour une opération qui ne peut pas se terminer.

3) Comment savoir si c’est un problème invité ou un problème hôte/stockage ?

Vérifiez l’état du processus QEMU. S’il est en D-state avec io_schedule ou bloqué sur fsync, c’est l’hôte/stockage. S’il tourne normalement et que seule la fermeture ACPI est ignorée, c’est probablement un comportement invité.

4) Pourquoi les verrous s’accumulent-ils après une tâche défaillante ?

Parce que Proxmox sérialise beaucoup d’opérations de cycle de vie pour éviter la corruption. Une opération bloquée détient un verrou ; les opérations suivantes timeouteront en attendant. L’accumulation de verrous est la fumée, pas le feu.

5) Quel est l’indicateur le plus rapide que Ceph est le problème ?

ceph -s affichant des slow ops, des PGs dégradés ou un recovery/backfill sous pression. Si des slow ops existent, supposez que les opérations de stockage Proxmox vont timeout tant que Ceph n’est pas stabilisé.

6) Puis-je supprimer en toute sécurité les fichiers de verrou dans /var/lock/pve-manager ?

Parfois, mais en dernier recours. Identifiez d’abord le PID propriétaire. Si le propriétaire est une tâche légitime en cours, supprimer le verrou peut créer des opérations concurrentes conflictuelles. Si le propriétaire a disparu et que vous avez confirmé qu’aucune opération de stockage sous-jacente n’est active, la suppression de verrous obsolètes peut être acceptable — documentez ce que vous faites.

7) Pourquoi l’accès à /etc/pve se bloque quand le cluster a des problèmes ?

Parce que /etc/pve est pmxcfs (FUSE). Les opérations de fichiers peuvent dépendre du messaging du cluster et de la coordination des verrous. Si corosync est instable ou si le nœud est saturé, les lectures/écritures normales dans cet arbre peuvent se bloquer.

8) Quel est le bon ordre pour dépanner : logs Proxmox ou logs noyau ?

Commencez par le journal de la tâche pour identifier ce que Proxmox faisait, puis vérifiez immédiatement les logs noyau pour les erreurs I/O dans la même fenêtre. Les logs noyau vous disent généralement pourquoi l’opération a stagné.

9) Pourquoi les timeouts surviennent-ils plus souvent pendant les sauvegardes ?

Les sauvegardes sollicitent fortement l’I/O, les snapshots et les métadonnées. Elles mettent à l’épreuve à la fois le débit et la latence terminale du stockage. Si votre stockage est « correct » en opération normale, les sauvegardes peuvent le pousser dans une zone lente où les boucles d’attente de Proxmox atteignent leurs seuils de timeout.

Prochaines étapes à réaliser cette semaine

Si vous voulez moins de timeouts surprise et des incidents plus courts, faites ces actions pratiques :

Formez votre équipe à partir du UPID et à lire /var/log/pve/tasks/. Faites-en un réflexe.
Ajoutez une surveillance des D-state et de l’iowait sur chaque nœud. Si votre monitoring ne peut pas alerter sur les pics de D-state, ce n’est pas de la surveillance ; c’est du scrapbook.
Établissez une ligne de base de votre backend de stockage pendant les sauvegardes et les migrations. Capturez la latence iostat, les slow ops Ceph, zpool iostat — selon votre stack.
Décidez d’une politique de tolérance de panne pour multipath/NFS (fail-fast vs hang). Les valeurs par défaut ne sont pas une stratégie.
Organisez un game day : saturer volontairement le stockage de sauvegarde ou simuler une perte de chemin pendant une fenêtre contrôlée, et entraînez-vous à identifier « ce qui a réellement expiré » en moins de dix minutes.

Les timeouts Proxmox semblent vagues parce que c’est une couche de gestion qui attend des couches inférieures. Une fois que vous tracez systématiquement l’attente jusqu’à un processus, puis à un appel système, puis au backend, le message d’erreur cesse d’être mystérieux. Il devient une piste.