Proxmox TASK ERROR : où lire les journaux et trouver rapidement la cause racine

Playbook de diagnostic rapide (vérifications 1re/2e/3e)

Quand une tâche Proxmox échoue, vous ne « commencez pas à lire les journaux ». Vous exécutez une courte séquence brutale qui réduit le rayon d’action en quelques minutes. L’astuce est d’arrêter de traiter « TASK ERROR » comme un unique problème. C’est un conteneur pour un sous-processus, et ce sous-processus a un domicile.

Première vérification : récupérez la commande réelle de la tâche et son contexte de sortie

• Ouvrez la tâche dans l’interface et copiez le UPID. Il ressemble à une longue chaîne séparée par des deux-points.
• Sur le nœud où elle s’est exécutée, lisez le journal de la tâche sur disque (/var/log/pve/tasks/) et cherchez la commande défaillante réelle et la première ligne d’erreur concrète.
• Si le journal est tronqué ou vague, passez au journal systemd pour le démon qui l’a exécutée : généralement pvedaemon, parfois pveproxy, parfois pvescheduler.

Deuxième vérification : décidez quel sous-système est responsable

La plupart des échecs de tâches relèvent d’un des cinq domaines :

1. Stockage : ZFS, LVM, Ceph, NFS, iSCSI, problèmes de permissions, « plus d’espace », mount de dataset étrange.
2. Cluster : basculements de lien corosync, absence de quorum, état pmxcfs obsolète.
3. Invité : erreurs de ligne de commande QEMU, disques manquants, configuration invalide, problèmes AppArmor/cgroup pour LXC.
4. Réseau : bridges cassés, mismatch MTU, pare-feu, sockets de migration bloqués.
5. Hôte : noyau, matériel, dérive temporelle, OOM, I/O bloqué, corruption de système de fichiers.

Si vous ne pouvez pas identifier le domaine en 3 minutes, vous lisez le mauvais journal.

Troisième vérification : confirmez avec une commande « vérité » par domaine

Exécutez une commande qui ne peut pas feindre le succès :

• Vérité stockage : pvesm status, zpool status, ceph -s, df -h
• Vérité cluster : pvecm status, journalctl -u corosync
• Vérité invité : qm start --debug ou pct start --debug
• Vérité réseau : ss -tulpn + vérification ports de migration + ip -d link
• Vérité hôte : dmesg -T, journalctl -p err..alert, smartctl

Une fois que vous avez une « sortie vérité », vous arrêtez de débattre et commencez à réparer.

Réalité sèche : la plupart des incidents « TASK ERROR » sur Proxmox ne sont pas des « bugs Proxmox ». Ce sont des problèmes d’hygiène de stockage ou de cluster qui remontent au pire moment.

Comment les tâches Proxmox sont câblées (et pourquoi l’UI omet la vérité)

Proxmox VE est un ensemble de démons qui coordonnent le travail :

• pvedaemon : exécute la plupart des tâches au niveau du nœud demandées via l’API/l’interface (démarrer VM, créer conteneur, migrations, actions de stockage).
• pveproxy : frontend API/UI ; il gère l’auth et la distribution, mais il est rarement la source de l’échec réel.
• pvescheduler : lance les jobs planifiés comme les sauvegardes.
• pvestatd : collecte les statistiques ; utile quand le graphe UI est erroné, pas quand une tâche échoue.
• pmxcfs : le système de fichiers de cluster monté sur /etc/pve. S’il est mal en point, tout devient « bizarre » d’une manière propre à Proxmox.

Une tâche dans Proxmox est essentiellement : « exécuter une commande, capturer stdout/stderr, stocker le tout, afficher une vue filtrée dans l’UI ». L’interface met souvent en avant la dernière ligne et cache la ligne antérieure qui contient l’erreur réelle. C’est pourquoi vous devez aller lire le journal brut de la tâche et le journal du démon.

Aussi : l’erreur que vous voyez peut être l’échec du wrapper, pas de l’opération sous-jacente. Exemple : une migration échoue avec « connection timed out », mais la cause racine est un verrouillage de stockage sur le nœud de destination parce que le système de fichiers cible est monté en lecture seule. Le wrapper de migration dit la vérité, mais pas la vérité utile.

Idée paraphrasée de Werner Vogels : « You build it, you run it. » En langage Proxmox : vous attachez le stockage, vous dépannez le stockage.

Blague n°1 : Le message d’erreur de l’UI Proxmox ressemble à une météo qui se contente de dire « il y a eu du temps ». Techniquement correct, opérationnellement inutile.

Emplacements des journaux importants (et ceux à ignorer)

L’archive des journaux de tâches (commencez ici)

Proxmox stocke les journaux de tâches sur le nœud sous :

• /var/log/pve/tasks/ — journaux canoniques des tâches, organisés par nœud et date
• /var/log/pve/tasks/index — index des tâches ; pratique pour grep

Flux de travail le plus rapide : récupérez l’UPID depuis l’UI, puis greppez-le dans /var/log/pve/tasks/ ou utilisez directement le fichier du visualiseur de tâches. Vous cherchez :

• la première ligne d’erreur concrète (pas la dernière)
• la commande exacte invoquée (qemu, vzdump, zfs, rbd, ssh, rsync)
• toute mention de « permission denied », « no space », « I/O error », « quorum », « timeout », « dataset not found »

Journal systemd (les journaux adultes)

Les journaux de tâches sont utiles, mais les démons consignent souvent plus de contexte dans le journal systemd. Ces unités comptent :

• pvedaemon — la plupart des détails d’exécution des tâches
• pveproxy — problèmes API/auth, tickets, déconnexions websocket
• pvescheduler — déclencheurs vzdump et réplication planifiés
• corosync — adhésion au cluster, état des liens, changements de quorum
• pve-cluster (pmxcfs) — synchronisation du système de fichiers de cluster et configs
• ceph-* — si vous utilisez Ceph, vous savez déjà où cela mène

Journaux noyau et stockage (là où se cachent les corps)

Quand le stockage est impliqué, le noyau finit par le dire :

• dmesg / journalctl -k — erreurs I/O, resets, tâches bloquées, messages ZFS
• /var/log/syslog (ou le journal sur les installations récentes) — contexte au niveau service
• ZFS : zpool status, zpool events (les events sont de l’or lors de flaps)
• Ceph : ceph -s, journaux OSD via systemd

Journaux auxquels il faut cesser de trop faire confiance

• L’UI seule. C’est un résumé, pas un outil de cause racine.
• /var/log/pveproxy/access.log comme premier arrêt pour les erreurs de tâche. Si l’auth fonctionne et que les tâches se lancent, pveproxy est rarement en cause.
• Greps aléatoires dans /var/log sans identifiant. Vous trouverez des mots effrayants et n’apprendrez rien.

Tâches pratiques : commandes, signification des sorties et décision à prendre

L’objectif ici est la rapidité. Chaque tâche ci-dessous inclut : commande(s), ce que signifie la sortie, et la décision que vous en retirez. Exécutez-les sur le nœud qui a exécuté la tâche défaillante sauf indication contraire.

Task 1 : identifier l’UPID et extraire le journal brut de la tâche

cr0x@server:~$ grep -R "UPID:" -n /var/log/pve/tasks/index | tail -n 3
/var/log/pve/tasks/index:98122:UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam:
/var/log/pve/tasks/index:98123:UPID:pve1:0000A1B7:01F4C3D8:676D2C91:qmstart:104:root@pam:
/var/log/pve/tasks/index:98124:UPID:pve1:0000A1C0:01F4C3E0:676D2C9A:vmmigrate:104:root@pam:

Signification : Vous avez des UPID récents. Copiez celui pertinent depuis l’UI idéalement ; le grep de l’index est un plan de secours.

Décision : Utilisez l’UPID pour localiser le fichier de journal de la tâche et lisez-le du haut vers le bas, pas l’inverse.

Task 2 : lire le fichier journal de la tâche pour cet UPID

cr0x@server:~$ UPID="UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam:"; grep -R "$UPID" -n /var/log/pve/tasks/ | head
/var/log/pve/tasks/9/98122:UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam:

cr0x@server:~$ sed -n '1,160p' /var/log/pve/tasks/9/98122
UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam:
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
INFO: Running hook script 'backup-hook.pl'.
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive '/mnt/pve/backup-nfs/dump/vzdump-qemu-101-2025_12_26-02_00_01.vma.zst'
ERROR: qemu-img: Could not open '/dev/zvol/rpool/data/vm-101-disk-0': Permission denied
INFO: aborting backup job
TASK ERROR: command 'vzdump 101 --storage backup-nfs --mode snapshot --compress zstd' failed: exit code 255

Signification : La ligne utile est Permission denied lors de l’ouverture d’un zvol. La dernière ligne n’est que le wrapper.

Décision : Orientez-vous vers les permissions ZFS / l’accès au périphérique / AppArmor / la configuration du stockage, pas « paramètres de sauvegarde ».

Task 3 : récupérer le contexte côté démon pour la même fenêtre temporelle

cr0x@server:~$ journalctl -u pvedaemon --since "2025-12-26 01:55" --until "2025-12-26 02:05" | tail -n 30
Dec 26 02:00:01 pve1 pvedaemon[1123]: starting task UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam:
Dec 26 02:00:02 pve1 pvedaemon[1123]:  starting task vzdump 101
Dec 26 02:00:05 pve1 pvedaemon[1123]: command 'qemu-img info /dev/zvol/rpool/data/vm-101-disk-0' failed: Permission denied
Dec 26 02:00:05 pve1 pvedaemon[1123]: end task UPID:pve1:0000A1B2:01F4C3D2:676D2C8B:vzdump:101:root@pam: TASK ERROR: exit code 255

Signification : Confirme la sous-commande défaillante et que cela se produit sous pvedaemon, pas une couche UI mystérieuse.

Décision : Cherchez pourquoi qemu-img ne peut pas ouvrir le chemin du zvol.

Task 4 : balayage rapide des erreurs système (ne pas sur-analyser)

cr0x@server:~$ journalctl -p err..alert --since "1 hour ago" | tail -n 25
Dec 26 02:00:05 pve1 kernel: audit: type=1400 apparmor="DENIED" operation="open" profile="lxc-container-default-cgns" name="/dev/zvol/rpool/data/vm-101-disk-0" pid=22871 comm="qemu-img" requested_mask="r" denied_mask="r"
Dec 26 02:00:05 pve1 pvedaemon[1123]: command 'qemu-img info /dev/zvol/rpool/data/vm-101-disk-0' failed: Permission denied

Signification : Refus AppArmor. Ce n’est pas « aléatoire » ; c’est une raison directe pour l’erreur de permission.

Décision : Corriger le profil AppArmor / la confinement du conteneur / le décalage après mise à jour qui provoque le refus.

Task 5 : confirmer l’état du stockage du point de vue de Proxmox

cr0x@server:~$ pvesm status
Name        Type     Status           Total            Used       Available        %
local       dir      active        98317312        21938176        71340544    22.31%
local-zfs   zfspool  active       402653184       312475648        90177536    77.60%
backup-nfs  nfs      active      1048576000       612368384       436207616    58.40%

Signification : Le stockage est « active » selon PVE. Cela ne garantit pas que les périphériques ZFS sont accessibles sous confinement, mais écarte « stockage hors-ligne » comme cause principale.

Décision : Concentrez-vous sur le chemin d’accès au périphérique et la couche de sécurité, pas sur une défaillance NFS.

Task 6 : valider la santé ZFS et chercher des erreurs I/O

cr0x@server:~$ zpool status -x
all pools are healthy

Signification : Pas de faute évidente au niveau pool. Ce n’est pas encore une histoire de disque défaillant.

Décision : Ne commencez pas à remplacer du matériel parce qu’une sauvegarde a échoué. Continuez à chercher le refus réel.

Task 7 : regarder les événements ZFS autour du moment de l’échec (utile en cas de flaps)

cr0x@server:~$ zpool events -v | tail -n 12
Dec 26 01:58:44.120782 sysevent.fs.zfs.config_sync
Dec 26 01:58:44.120790 sysevent.fs.zfs.history_event
    history_event: zfs create rpool/data/vm-104-disk-0
Dec 26 02:00:03.908111 sysevent.fs.zfs.vdev_check
    pool: rpool

Signification : Rien d’alarmant. Les événements sont calmes, ce qui favorise « politique/permission » plutôt que « stockage en train de mourir ».

Décision : Arrêtez de creuser ZFS tant que vous n’avez pas de raison.

Task 8 : relancer l’opération invitée défaillante en mode debug

cr0x@server:~$ qm start 101 --debug
start VM 101: UPID:pve1:0000A1D0:01F4C410:676D2D12:qmstart:101:root@pam:
QEMU command line: /usr/bin/kvm -id 101 -name vm101 -no-shutdown ...
kvm: -drive file=/dev/zvol/rpool/data/vm-101-disk-0,if=none,id=drive-scsi0,format=raw: Could not open '/dev/zvol/rpool/data/vm-101-disk-0': Permission denied
TASK ERROR: start failed: QEMU exited with code 1

Signification : Pas un problème limité à la sauvegarde. Le démarrage de la VM échoue pour la même raison. Forte indication d’une régression d’accès ou de politique au niveau hôte.

Décision : Considérez que « la VM ne peut pas accéder à son périphérique bloc ». Priorisez l’escalade.

Task 9 : confirmer la propriété et permissions du nœud périphérique (oui, c’est basique — faites-le)

cr0x@server:~$ ls -l /dev/zvol/rpool/data/vm-101-disk-0
lrwxrwxrwx 1 root root 13 Dec 26 01:12 /dev/zvol/rpool/data/vm-101-disk-0 -> ../../zd0

cr0x@server:~$ ls -l /dev/zd0
brw-rw---- 1 root disk 230, 0 Dec 26 01:12 /dev/zd0

Signification : Le périphérique bloc appartient au groupe disk, mode 660. QEMU fonctionne typiquement en root sur Proxmox, donc les permissions UNIX simples ne sont généralement pas le blocage.

Décision : Si les perms semblent correctes mais l’accès échoue, suspectez le confinement (AppArmor), une anomalie de namespace de montage, ou une règle au niveau noyau.

Task 10 : vérifier l’état d’AppArmor et les refus récents

cr0x@server:~$ aa-status | sed -n '1,60p'
apparmor module is loaded.
60 profiles are loaded.
58 profiles are in enforce mode.
   /usr/bin/lxc-start
   /usr/bin/pve-container
   lxc-container-default-cgns
2 profiles are in complain mode.
0 processes are unconfined but have a profile defined.

Signification : AppArmor est actif. Si des refus mentionnent votre chemin de périphérique ou qemu-img, vous tenez votre preuve fumante.

Décision : Corrigez le profil ou les attentes de chemin. Sur Proxmox, cela apparaît souvent après des mises à jour partielles ou un durcissement personnalisé.

Task 11 : échecs de migration — confirmer connectivité et services à l’écoute

cr0x@server:~$ ss -tulpn | egrep '(:8006|:3128|:5900|:60000|:22)\b'
tcp   LISTEN 0      4096           0.0.0.0:8006       0.0.0.0:*    users:(("pveproxy",pid=1044,fd=6))
tcp   LISTEN 0      4096           0.0.0.0:22         0.0.0.0:*    users:(("sshd",pid=881,fd=3))

Signification : Confirme les bases : l’API est up, SSH est up. La migration utilise SSH pour l’orchestration et un canal séparé pour le transfert mémoire selon les paramètres.

Décision : Si la migration échoue par timeout, vérifiez pare-feu, routage, MTU, et tout réseau dédié à la migration. Si des services n’écoutent pas, réparez-les avant de toucher aux configs Proxmox.

Task 12 : erreurs de tâches de cluster — vérifier quorum et santé corosync

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prodcluster
Config Version:   19
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 02:03:11 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Total votes:      3
Quorum:           2
Flags:            Quorate

Signification : Le quorum est OK. Si vous voyez Quorate: No, beaucoup de tâches vont échouer, se bloquer ou refuser de s’exécuter parce que /etc/pve devient lecture-seule.

Décision : Si pas de quorum : cessez les « dépannages stockage » et réparez d’abord le lien/quorum du cluster. Proxmox dépend d’un état pmxcfs sain pour des opérations cohérentes.

Task 13 (bonus, parce que vous en aurez besoin) : vérifier le montage et l’état de pmxcfs

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

Signification : rw est ce que vous voulez. Si cela bascule en ro, vous verrez des échecs bizarres : éditions de config VM échouent, éditions de stockage échouent, tâches échouent avec des erreurs trompeuses.

Décision : Si c’est ro, considérez-le comme un problème de cluster/quorum jusqu’à preuve du contraire.

Task 14 (bonus) : détecter le « plus d’espace » comme le voit le noyau

cr0x@server:~$ df -hT | egrep '(/$|/var|/mnt/pve|/rpool|/dev/sd)'
Filesystem                 Type  Size  Used Avail Use% Mounted on
/dev/mapper/pve-root       ext4   96G   89G  2.1G  98% /
backup-nfs:/export/backup  nfs4  1000G  584G  417G  59% /mnt/pve/backup-nfs

Signification : Le système racine à 98% n’est pas un « problème futur ». C’est une source actuelle de défaillances aléatoires de tâches (les logs ne peuvent pas s’écrire, les fichiers temporaires échouent, dpkg casse).

Décision : Si la racine est pleine : nettoyez maintenant, puis relancez la tâche. Ne « réessayez » pas en espérant que ça se résolve.

C’est déjà plus que 12 tâches. Bien. Votre travail n’est pas de les mémoriser ; c’est d’intérioriser la cartographie : tâche → démon → sous-système → commande vérité.

Modes d’échec courants par catégorie

Sauvegardes (vzdump) qui échouent « aléatoirement »

Les sauvegardes touchent presque tout : logique de snapshot invité, stockage, compression, réseau (si distant) et nettoyage de rétention. Quand une sauvegarde échoue, la cause n’est généralement pas « vzdump est cassé ». C’est :

• snapshot impossible (agent invité manquant ou gel du filesystem qui échoue)
• le stockage ne peut pas créer de fichiers temporaires (permissions, plus d’espace, mount obsolète)
• timeouts dus à des disques lents ou NFS/Ceph surchargés
• contention de verrou : sauvegarde précédente encore en cours, ou fichier lock obsolète

Où regarder en premier : le journal de la tâche pour la sous-commande qui échoue (qemu-img, vma, zstd, tar) puis les journaux noyau pour les blocages I/O.

Migrations qui échouent avec des timeouts

La migration live est une pièce en trois actes :

1. Orchestration (SSH, pvedaemon sur les deux côtés)
2. Transfert d’état (pages RAM, état des périphériques)
3. Synchronisation du stockage (dépend du stockage partagé vs local + réplication)

Les échecs sont souvent corrélés à un mismatch MTU sur un réseau de migration dédié, des règles pare-feu bloquant des ports éphémères, ou le stockage sur la destination qui n’est pas « réellement prêt » même si PVE dit qu’il est actif.

Erreurs de démarrage VM qui ressemblent à du théâtre QEMU

Les erreurs QEMU sont verbeuses mais honnêtes. Quand vous voyez :

• Could not open ... Permission denied → politique/permissions ou mismatch de chemin bloc
• Device or resource busy → processus stale tenant un périphérique, qemu restant, ou volume ZFS toujours utilisé
• No such file or directory → chemin de stockage incorrect, dataset manquant, stockage non monté
• Invalid argument → souvent mismatch noyau/driver ou option cassée après une mise à jour

Tâches de cluster échouant alors que le cluster est « à moitié opérationnel »

Les clusters Proxmox peuvent sembler fonctionnels tout en étant cassés : les nœuds pingent, l’UI se charge, mais les écritures de configuration échouent ou les tâches se bloquent. Si le quorum est perdu, /etc/pve devient lecture-seule pour éviter le split-brain. C’est un bon choix d’ingénierie, mais ça ressemble à un sabotage à 2h du matin.

Tâches stockage échouant parce que le stockage est « actif » mais inutilisable

« Active » dans pvesm status signifie que Proxmox voit la définition du stockage et qu’il a passé son contrôle d’activation. Cela ne garantit pas :

• que NFS est stable (il peut être monté mais en état stale/hang)
• que Ceph est sain (il peut répondre mais être dégradé au point de bloquer I/O client)
• que ZFS a assez d’espace (il peut être en ligne mais pratiquement plein à cause des snapshots)

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

Ce sont les échecs que je vois régulièrement parce qu’ils sont sournois, pas parce qu’ils sont difficiles.

1) Symptom : « TASK ERROR: command ‘vzdump …’ failed » avec code de sortie 255

Cause racine : Le code 255 est souvent le wrapper rapportant l’échec d’une sous-commande. L’erreur réelle est plus haut : permission denied, échec de snapshot, ou problème de stockage distant.

Correction : Lisez le journal de la tâche depuis le début et trouvez la première ligne ERROR:. Puis vérifiez journalctl -u pvedaemon pour la même fenêtre temporelle.

2) Symptom : Migration échoue avec « connection timed out » ou « ssh exited with status 255 »

Cause racine : Pas une seule chose. Généralement pare-feu/MTU/routage sur le chemin de migration, ou confiance SSH rompue entre les nœuds.

Correction : Confirmez que sshd est accessible nœud-à-nœud, vérifiez la cohérence MTU via ip link, et contrôlez les règles pare-feu des deux côtés. Si vous utilisez un réseau de migration dédié, testez-le directement.

3) Symptom : Le démarrage VM échoue après une mise à jour, alors que ça marchait hier

Cause racine : Mises à jour partielles ou noyau/modules/userspace incompatibles. Parfois les profils AppArmor changent et commencent à refuser des chemins qui étaient autorisés.

Correction : Assurez-vous que le nœud est entièrement mis à jour et redémarré sur le noyau attendu. Vérifiez journalctl -p err..alert pour des refus AppArmor et erreurs noyau.

4) Symptom : Les tâches n’arrivent pas à modifier les configs VM ; l’UI indique permission denied ou « file is read-only »

Cause racine : Cluster a perdu le quorum ; pmxcfs est en lecture-seule.

Correction : Vérifiez pvecm status. Réparez la connectivité corosync. Ne « contournez » pas en éditant des fichiers ailleurs ; c’est ainsi qu’on crée une dérive de configuration split-brain.

5) Symptom : Le stockage est « active », mais sauvegardes/migrations se bloquent des minutes puis échouent

Cause racine : Mount NFS obsolète ou I/O bloqué. Le mount existe, mais l’I/O est bloqué.

Correction : Vérifiez les journaux noyau pour timeouts NFS, validez la santé du serveur NFS, et considérez les options mount hard vs soft. Si l’hôte est coincé sur des tâches en état D, vous devrez réparer le chemin de stockage avant que Proxmox ne puisse récupérer.

6) Symptom : « no space left on device » même si df montre de l’espace libre

Cause racine : Inodes épuisés, quota dataset ZFS, pool ZFS presque plein avec pénalités copy-on-write, ou seuil de remplissage Ceph atteint.

Correction : Vérifiez l’usage des inodes (df -i), quotas et bloat de snapshots ZFS (zfs list -o space), et les seuils de remplissage Ceph si applicable.

7) Symptom : « unable to activate storage » après un reboot

Cause racine : Le stockage réseau monte avant que le réseau soit prêt, ou la résolution de noms n’est pas disponible, ou l’ordre systemd est incorrect.

Correction : Validez DNS, routes, et envisagez des dépendances systemd de montage. Sur NFS, assurez-vous que l’unité de montage attend network-online. Puis réactivez le stockage et ré-exécutez les tâches.

8) Symptom : LXC ne démarre pas avec erreurs cgroup ou mount

Cause racine : Attentes kernel/cgroup v2 vs configuration container, confinement AppArmor, ou options de nesting.

Correction : Lancez pct start <id> --debug, puis vérifiez journalctl -u pvedaemon et les journaux noyau pour des messages cgroup. Corrigez les flags de fonctionnalités du conteneur délibérément, pas par essais/erreurs aléatoires.

Blague n°2 : « Ça marchait hier » n’est pas un diagnostic ; c’est une histoire qu’on se raconte avant que le système ne ruine votre matinée.

Trois mini-récits issus du terrain

Incident 1 : La panne causée par une mauvaise hypothèse (stockage partagé ≠ stockage cohérent)

Une entreprise de taille moyenne faisait tourner un cluster Proxmox deux nœuds avec « stockage partagé » sur NFS. L’UI montrait le datastore NFS comme actif sur les deux nœuds. Les migrations étaient routinières. Les sauvegardes étaient vertes. Tout le monde dormait.

Puis une fenêtre de maintenance est arrivée : un ingénieur réseau a remplacé un switch, et un nœud est revenu avec une configuration d’étiquetage VLAN différente. Le nœud pouvait toujours atteindre le serveur NFS de manière intermittente — assez pour que le mount existe — mais les I/O importants se bloquaient. En termes Proxmox, le stockage était « actif ». En réalité, c’était un piège.

La migration live a commencé en heures ouvrées. La tâche a échoué par timeout. L’astreignant a supposé une « instabilité de migration Proxmox », a réessayé deux fois, puis a tenté une autre VM. Maintenant plusieurs VMs étaient en attente avec des verrous maintenus. L’UI s’est remplie d’entrées TASK ERROR qui se ressemblaient toutes.

La réparation était ennuyeuse : vérifier la santé I/O NFS par des tests lecture/écriture directs sur le mount, consulter les journaux noyau pour timeouts NFS, et corriger l’étiquetage VLAN. La leçon : ne considérez pas « monté » comme « sain », et ne relancez pas aveuglément des migrations. Les relances transforment un échec en file d’échecs.

Incident 2 : L’optimisation qui a eu l’effet inverse (sauvegardes plus rapides, cluster plus lent)

Une autre équipe voulait accélérer les sauvegardes nocturnes. Ils sont passés de gzip à zstd, activé plusieurs jobs de sauvegarde en parallèle, et se sentaient malin. Le CPU avait de la marge. Le stockage était « rapide ». Que pourrait-il mal tourner ?

Ce qui a mal tourné, c’est l’ordonnancement I/O et la latence. Les jobs vzdump parallèles ont créé des rafales de lectures depuis des zvols ZFS tout en écrivant simultanément de gros flux compressés vers une cible NFS. ZFS a fait ce que ZFS fait : tenter d’aider avec le cache et copy-on-write. NFS a ajouté de la variabilité. Le résultat : des blocages I/O occasionnels.

Les tâches Proxmox ont commencé à échouer avec des messages vagues : timeouts, retards de commit de snapshot, « unable to freeze filesystem », timeouts occasionnels du moniteur VM. L’équipe a passé une semaine à scruter les logs Proxmox, convaincue que l’hyperviseur était instable. Les journaux noyau ont raconté la vraie histoire : tâches bloquées en attente d’I/O et pics de latence NFS.

Le rollback n’a pas été spectaculaire. Ils ont réduit la concurrence, planifié les fenêtres de sauvegarde, et — surtout — arrêté d’écrire les sauvegardes sur le même chemin réseau que le trafic sensible à la latence. Les sauvegardes sont devenues un peu plus lentes. Tout le reste est redevenu fiable. Optimiser un non-goulot crée un goulot.

Incident 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (synchronisation temporelle + discipline des logs)

Une société liée à la finance exploitait un cluster Proxmox avec Ceph. Ils avaient une règle stricte : chaque nœud doit avoir la synchronisation temporelle fonctionnelle, et les logs sont conservés avec une rétention suffisante pour couvrir les week-ends. Personne ne célébrait ça. C’était juste une politique, appliquée par automatisation.

Un vendredi soir, un nœud a commencé à produire des TASK ERROR pendant des réplications et opérations Ceph. Les erreurs UI étaient génériques. Mais l’équipe a immédiatement corrélé les événements parce que les horodatages étaient alignés proprement sur tous les nœuds. Ils ont vu que les échecs ont commencé juste après un changement réseau spécifique et que des flaps corosync précédaient les avertissements Ceph.

Parce que les logs étaient conservés et que l’heure était correcte, ils ont rapidement tracé la cause : un MTU jumbo mal configuré provoquait une perte de paquets sur une interface, ce qui déstabilisait le réseau du cluster et déclenchait des timeouts en cascade. Ils ont corrigé la cohérence MTU, observé la stabilisation de corosync, et les tâches ont cessé d’échouer.

Rien d’héroïque. Juste des fondamentaux ennuyeux : horloges synchronisées, rétention cohérente, et l’habitude de vérifier corosync avant d’accuser Ceph ou Proxmox. Voilà à quoi ressemble la « maturité opérationnelle » quand elle n’essaie pas de vous vendre quelque chose.

Listes de contrôle / plan pas à pas

Checklist A : Quand vous voyez « TASK ERROR » et que vous avez 10 minutes

1. Copiez l’UPID depuis les détails de la tâche.
2. Ouvrez le journal brut sous /var/log/pve/tasks/ et trouvez la première vraie ligne ERROR:.
3. Récupérez le contexte du journal du démon autour de la même minute : journalctl -u pvedaemon (ou pvescheduler pour les jobs planifiés).
4. Classez le problème : stockage, cluster, invité, réseau, hôte.
5. Exécutez une commande vérité pour ce domaine (pvesm status/zpool status/pvecm status/qm start --debug/dmesg -T).
6. Décidez : le réessai n’est autorisé qu’après avoir éliminé la cause (espace, permission, quorum, connectivité). Ne réessayez jamais en diagnostic sauf si le système est idempotent et que vous le savez.

Checklist B : Échecs centrés stockage (sauvegardes, réplication, attach de disque)

1. pvesm status — le stockage est-il actif ?
2. df -hT — la racine ou la cible est-elle pleine ?
3. Si ZFS : zpool status -x et zfs list -o space — santé du pool et bloat de snapshots.
4. Si Ceph : ceph -s — le cluster est-il HEALTH_OK ? Sinon, attendez-vous à des anomalies.
5. journalctl -k — des erreurs I/O, resets, tâches bloquées ?
6. Corrigez le goulot, puis relancez exactement une tâche pour valider.

Checklist C : Échecs centrés cluster (edits config, migrations, actions HA)

1. pvecm status — quorum ou non ?
2. journalctl -u corosync — flaps de lien, timeouts de token ?
3. mount | grep /etc/pve — pmxcfs est-il rw ?
4. Réparez d’abord le réseau/liens du cluster. Ne forcez pas d’opérations sur un cluster non quoré tant que vous n’acceptez pas le risque de split-brain.

Checklist D : Échecs de démarrage invité

1. Exécutez le démarrage invité en debug (qm start --debug ou pct start --debug).
2. Cherchez les chemins de fichiers et noms de périphériques dans l’erreur. Ce sont vos points d’ancrage.
3. Vérifiez que l’objet de stockage sous-jacent existe (zvol, qcow2, image rbd, volume logique).
4. Vérifiez les refus de la couche de sécurité (AppArmor) et les journaux noyau.
5. Ce n’est qu’après cela : envisagez une régression de configuration (machine type, flags CPU, options de périphérique).

Faits intéressants et contexte historique (pour mieux comprendre les journaux)

• UPID est le système d’identité des tâches Proxmox : il encode le nœud, le PID, l’heure de démarrage et le type de tâche. Conçu pour le suivi distribué dans les clusters.
• Proxmox s’appuie sur le modèle de services Debian : beaucoup de « problèmes Proxmox » sont en réalité des problèmes systemd/journal/noyau déguisés en Proxmox.
• /etc/pve n’est pas un système de fichiers normal : c’est pmxcfs, un système de fichiers de cluster basé sur FUSE. Lorsque le quorum est perdu, il peut passer en lecture-seule pour éviter le split-brain.
• Le comportement de quorum de Corosync est volontairement strict : refuser les écritures sans quorum est un choix de conception qui privilégie la cohérence sur la commodité.
• Les changements copy-on-write de ZFS modifient les symptômes d’échec : les pools peuvent être « healthy » mais extrêmement lents ou quasi-inutilisables quand ils sont presque pleins, car chaque écriture devient coûteuse.
• La santé Ceph est plus que « up » : un cluster Ceph peut répondre aux commandes tout en étant suffisamment dégradé pour provoquer des timeouts I/O client pendant la récupération.
• vzdump est un wrapper : l’outil de sauvegarde orchestre le snapshot et le packaging, mais le vrai travail est effectué par qemu, les backends de stockage et les outils de compression.
• Les journaux de tâches sont stockés localement : dans un cluster multi-nœuds, vous devez lire les journaux sur le nœud qui a exécuté la tâche, pas sur le nœud où vous avez cliqué l’UI.
• Beaucoup d’échecs sont des problèmes de corrélation temporelle : sans synchronisation temporelle correcte, vous ne pouvez pas corréler corosync, erreurs noyau et échecs de tâches. Les « logs » deviennent de la fiction.

FAQ

1) Où trouver exactement le journal d’une tâche qui affiche « TASK ERROR » dans l’UI ?

Sur le nœud qui l’a exécutée : /var/log/pve/tasks/. Utilisez l’UPID pour localiser le fichier exact (ou greppez l’index à /var/log/pve/tasks/index).

2) Pourquoi l’UI Proxmox affiche-t-elle si peu de détails pour TASK ERROR ?

Parce qu’elle rend un résumé. L’erreur réelle se trouve souvent plus haut dans la sortie de la tâche ou est consignés par le démon exécutant dans le journal.

3) Quel démon dois-je vérifier dans journalctl pour la plupart des échecs de tâches ?

pvedaemon en priorité. Pour les tâches planifiées comme les sauvegardes, vérifiez aussi pvescheduler. Pour les problèmes d’adhésion au cluster et de quorum, regardez corosync et pve-cluster.

4) Ma tâche échoue sur le nœud A, mais je suis connecté sur le nœud B dans l’UI. Est-ce important ?

Oui. Les journaux de tâches sont locaux au nœud qui a exécuté la tâche. Si vous lisez les journaux sur le mauvais nœud, vous en conclurez qu’« il n’y a pas de journaux », et vous commencerez à deviner.

5) Je vois souvent « exit code 255 ». Que signifie-t-il ?

Généralement « la commande a échoué et le wrapper le rapporte ». Rarement la cause racine en soi. Trouvez la ligne antérieure : permission, chemin, espace, timeout, échec de snapshot.

6) Comment savoir si un échec est lié au cluster/quorum ?

pvecm status. Si Quorate: No, attendez-vous à des comportements étranges et à des échecs d’écriture de config. Vérifiez aussi si /etc/pve est monté lecture-seule.

7) Les sauvegardes échouent mais le stockage est « active ». Et maintenant ?

« Active » n’est pas « sain ». Vérifiez les journaux noyau pour des timeouts de stockage, confirmez l’espace libre et les inodes, et validez la santé du backend de stockage (ZFS/Ceph/NFS).

8) Quel est le moyen le plus rapide de déboguer une VM qui ne démarre pas ?

Exécutez qm start <vmid> --debug sur le nœud et lisez la ligne d’erreur QEMU exacte. Puis validez le chemin/disque référencé et vérifiez les journaux noyau/AppArmor.

9) Quand dois-je redémarrer un nœud Proxmox pendant un incident TASK ERROR ?

Quand vous avez confirmé que l’échec est causé par un état hôte qui ne se résoudra pas de manière sûre : I/O bloqué, problèmes de driver noyau, ou mismatch noyau/userspace après mise à jour. Redémarrer en premier réponse fait perdre des données forensiques.

10) Ai-je besoin de centraliser les logs pour dépanner Proxmox ?

Cela aide, mais ce n’est pas obligatoire pour trouver la cause racine. Ce dont vous avez besoin : sélectionner le bon nœud, lire les journaux basés sur UPID, et accéder au journal avec corrélation temporelle.

Étapes suivantes que vous pouvez faire aujourd’hui

1. Exercez-vous au workflow UPID : prenez n’importe quelle tâche terminée, trouvez son UPID, et suivez-la UI → /var/log/pve/tasks/ → journalctl. Faites-en une habitude musculaire.
2. Définissez vos « commandes vérité » par sous-système et notez-les pour votre environnement (ZFS vs Ceph vs NFS change les premières questions).
3. Arrêtez de réessayer aveuglément : instaurez une règle—un seul réessai max, seulement après une hypothèse et une vérification. Les réessais créent des verrous, de la charge, et des logs pires.
4. Établissez une baseline de santé du cluster : vérifiez le quorum, la stabilité corosync, et le mode de montage pmxcfs pendant les heures calmes pour reconnaître instantanément une sortie anormale.
5. Surveillez votre système racine : gardez de l’espace libre sur / et /var. Les échecs de tâches causés par une racine pleine sont embarrassants car évitables.

Si vous faites ces cinq choses, « TASK ERROR » cesse d’être une insulte vague et redevient ce qu’il a toujours été : un pointeur vers un sous-système spécifique qui dysfonctionne. Vous aurez toujours des incidents. Vous les résoudrez juste plus vite et avec moins d’hypothèses.