Proxmox TASK ERROR: де читати логи та швидко знаходити першопричину

Швидкий план діагностики (перші/другі/треті перевірки)

Коли задача Proxmox падає, ви не «починаєте читати логи». Ви запускаєте коротку, жорстку послідовність дій, яка звужує зону впливу за кілька хвилин. Секрет у тому, щоб перестати трактувати «TASK ERROR» як одну проблему. Це оболонка над підпроцесом, і цей підпроцес має свій дім.

Перша перевірка: дізнатися реальну команду задачі та контекст завершення

• Відкрийте задачу в GUI та скопіюйте UPID (унікальний ідентифікатор процесу). Він виглядає як довгий рядок, розділений двокрапками.
• На вузлі, де задача виконувалась, прочитайте журнал задач з диска (/var/log/pve/tasks/) і знайдіть фактичну невдалу команду та перший конкретний рядок з помилкою.
• Якщо лог обрізано або він розмитий, переходьте до systemd journal для демонa, який його виконав: зазвичай pvedaemon, іноді pveproxy, іноді pvescheduler.

Друга перевірка: визначте, яка підсистема володіє помилкою

Більшість збоїв завдань потрапляють в одну з п’яти груп:

1. Сховище: ZFS, LVM, Ceph, NFS, iSCSI, проблеми з правами, «нема місця», дивні монтування датасетів.
2. Кластер: флапи лінку corosync, відсутність кворуму, застарілий стан pmxcfs.
3. Гість: помилки командного рядка QEMU, відсутні диски, некоректний конфіг, проблеми LXC з AppArmor/cgroup.
4. Мережа: зламані бріджі, невідповідність MTU, фаєрвол, блокування сокетів міграції.
5. Хост: ядро, апаратне забезпечення, дрейф часу, OOM, завислий I/O, пошкодження файлової системи.

Якщо ви не можете визначити корзину за 3 хвилини, ви читаєте не той лог.

Третя перевірка: підтвердіть одним «командним джерелом правди» для кожної корзини

Запустіть одну команду, яка не зможе сфальсифікувати успіх:

• Правда для сховища: pvesm status, zpool status, ceph -s, df -h
• Правда для кластера: pvecm status, journalctl -u corosync
• Правда для гостя: qm start --debug або pct start --debug
• Правда для мережі: ss -tulpn + перевірки портів міграції + ip -d link
• Правда для хоста: dmesg -T, journalctl -p err..alert, smartctl

Як тільки ви отримали «правдивий вивід», припиняйте суперечки і приступайте до виправлення.

Чорна реальність: більшість інцидентів Proxmox з «TASK ERROR» — це не баги Proxmox. Це гігієна сховища або кластера, що проявилася в найгірший момент.

Як влаштовані завдання Proxmox (і чому UI вводить в оману пропуском деталей)

Proxmox VE — це набір демонів, які координують роботу:

• pvedaemon: виконує більшість задач на рівні вузла, що запускались через API/UI (запуск VM, створення контейнера, міграції, дії зі сховищем).
• pveproxy: фронтенд API/UI; обробляє автентифікацію та диспетчеризацію, але рідко є джерелом фактичної помилки.
• pvescheduler: запускає планові роботи, як-от бекапи.
• pvestatd: збирає статистику; корисний, коли в UI графіки некоректні, але не коли падає задача.
• pmxcfs: кластерна файлова система, змонтована в /etc/pve. Якщо вона у поганому стані, усе стає «дивним» по-особливому Proxmox-ним способом.

Задача в Proxmox — це по суті: «запустити команду, захопити stdout/stderr, зберегти, показати відфільтрований вигляд у UI». UI часто підсвічує останній рядок і ховає попередній рядок, який містить реальну помилку. Саме тому ви йдете в сирий лог задачі та журнал демона.

Також: помилка, яку ви бачите, може бути проваленням оболонки, а не базової операції. Наприклад: міграція падає з «connection timed out», але корінна причина — блокування сховища на вузлі призначення, бо цільова файлова система стала тільки для читання. Обгортка міграції каже правду, але не корисну правду.

Парафраз ідеї Вернера Фогельса: «You build it, you run it.» В Proxmox це означає: ви підключаєте сховище — ви його й виправляєте.

Жарт №1: Повідомлення помилки UI Proxmox як прогноз погоди, який каже тільки «була якась погода». Технічно вірно, з операційної точки зору — марно.

Місця зберігання логів, які мають значення (і ті, яким не варто довіряти)

Архів логів задач (починайте звідси)

Proxmox зберігає логи задач на вузлі в:

• /var/log/pve/tasks/ — канонічні логи задач, організовані по вузлах і датах
• /var/log/pve/tasks/index — індекс задач; зручно для grep

Найшвидший робочий процес: візьміть UPID з UI, потім grep-ніть його в /var/log/pve/tasks/ або відкрийте файл перегляду задач безпосередньо. Ви шукаєте:

• перший конкретний рядок з помилкою (не останній)
• точну команду виклику (qemu, vzdump, zfs, rbd, ssh, rsync)
• будь-які згадки «permission denied», «no space», «I/O error», «quorum», «timeout», «dataset not found»

Systemd journal (дорослі логи)

Логи задач хороші, але демони часто пишуть більше контексту в системний журнал. Ці юніти мають значення:

• pvedaemon — деталі виконання більшості задач
• pveproxy — проблеми з API/авторизацією, проблеми з квитками, websocket-відключення
• pvescheduler — тригери планових vzdump та реплікацій
• corosync — членство кластера, статус лінку, зміни кворуму
• pve-cluster (pmxcfs) — синхронізація кластерної файлової системи та конфігів
• ceph-* — якщо ви використовуєте Ceph, ви вже знаєте, про що мова

Логи ядра та сховища (де приховані трупи)

Коли залучено сховище, ядро зазвичай все розкаже:

• dmesg / journalctl -k — I/O помилки, ресети, завислі задачі, повідомлення ZFS
• /var/log/syslog (або журнал на новіших інсталяціях) — контекст на рівні сервісів
• ZFS: zpool status, zpool events (події — золото під час флапів)
• Ceph: ceph -s, логи OSD через systemd

Логи, яким не варто надто довіряти

• UI сам по собі. Це зведення, а не інструмент для пошуку первинної причини.
• /var/log/pveproxy/access.log як перша зупинка при помилках задач. Якщо автентифікація працює і задачі запускаються, pveproxy рідко винен.
• Випадкові grep-и по /var/log без ідентифікатора. Ви знайдете страшні слова і нічого не дізнаєтесь.

Практичні дії: команди, значення виводу та які рішення приймати

Мета тут — швидкість. Кожна дія нижче містить: команду(и), що означає її вивід, і рішення, яке потрібно прийняти. Виконуйте їх на вузлі, що виконав невдалу задачу, якщо не зазначено інше.

Задача 1: Визначити UPID і витягти сирий лог задачі

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:

Значення: У вас є недавні UPID задач. Краще скопіюйте відповідний з UI; grep індексу — запасний варіант.

Рішення: Використайте UPID, щоб знайти конкретний файл логу задачі і читайте його зверху вниз, а не знизу вгору.

Задача 2: Прочитати файл логу задачі для цього 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

Значення: Корисний рядок — Permission denied при відкритті zvol. Останній рядок — лише обгортка.

Рішення: Перейдіть до перевірки прав ZFS / доступу до пристрою / AppArmor / конфігурації сховища, а не «налаштувань бекапа».

Задача 3: Витяг контексту демона за той же часовий проміжок

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

Значення: Підтверджує невдалу підкоманду і що це відбувається під pvedaemon, а не під якоюсь містичною UI-оболонкою.

Рішення: Розслідуйте, чому qemu-img не може відкрити шлях до zvol.

Задача 4: Швидкий системний пошук помилок (не ускладнюйте)

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

Значення: Відмова AppArmor. Це не «випадковість»; це пряма причина помилки доступу.

Рішення: Виправити профіль AppArmor / від confinement контейнера / невідповідність після оновлення Proxmox.

Задача 5: Підтвердити стан сховища з точки зору 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%

Значення: За PVE сховище «active». Це не гарантує, що підлеглі пристрої ZFS доступні в умовах confinement, але це виключає «зовнішнє відключення сховища» як первинну причину.

Рішення: Залишайтеся сфокусованими на шляху доступу до пристрою та шарі безпеки, а не на NFS-монтуванні.

Задача 6: Перевірити стан ZFS і шукати I/O помилки

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

Значення: Немає очевидних проблем з пулом. Це ще не історія про несправний диск покищо.

Рішення: Не починайте заміну апаратури лише через провал бекапу. Продовжуйте шукати справжню відмову.

Задача 7: Подивитись події ZFS навколо часу відмови (корисно під час флапів)

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

Значення: Нічого катастрофічного. Події тихі, що підтримує версію «політика/права доступу» натомість «смерть сховища».

Рішення: Припиніть копатися в ZFS, поки не з’явиться підстава.

Задача 8: Перезапустити невдалу операцію гостя в режимі відлагодження

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

Значення: Це не лише проблема бекапа. Запуск VM падає з тієї ж причини. Це вагомий доказ регресу в політиці/доступі на хості.

Рішення: Трактувати як «VM не може доступитися до блочного пристрою». Ескалувати пріоритет.

Задача 9: Перевірити власника та права на ноду пристрою (так, це базово — перевірте)

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

Значення: Блочний пристрій у групі disk, режим 660. QEMU зазвичай працює як root у Proxmox, тому прості UNIX-права рідко блокують доступ.

Рішення: Якщо права виглядають адекватно, але доступ відмовляється — підозрюйте confinement (AppArmor), особливість простору імен монтувань або правило блокування на рівні ядра.

Задача 10: Перевірити стан AppArmor і останні відмови

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.

Значення: AppArmor активний. Якщо відмови згадують ваш шлях до пристрою або qemu-img, у вас є димовий сигнал.

Рішення: Виправте профіль або очікування шляху. У Proxmox це часто з’являється після часткових оновлень або кастомного хардінгу.

Задача 11: Помилки міграції — підтвердити зв’язність і сервіси, що слухають

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

Значення: Це підтверджує базові речі: API працює, SSH працює. Міграція використовує SSH для оркестрації і окремий канал для передачі пам’яті залежно від налаштувань.

Рішення: Якщо міграція таймаутиться, перевіряйте правила фаєрволу, маршрутизацію, MTU та будь-яку виділену мережу міграції. Якщо сервіси не слухають — виправляйте це перед змінами конфігів Proxmox.

Задача 12: Кластерні помилки задач — перевірити кворум і стан 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

Значення: Кворум в порядку. Якщо ви бачите Quorate: No, багато задач падатимуть, зависатимуть або відмовлятимуться виконуватись, бо /etc/pve перейде в режим тільки для читання.

Рішення: Якщо немає кворуму: припиніть «пошук проблем зі сховищем» і спочатку виправте зв’язок/кворум кластера. Proxmox залежить від здорового стану pmxcfs для коректних операцій.

Задача 13 (бонус, бо це знадобиться): Перевірити монтування 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)

Значення: rw — це бажано. Якщо воно зміниться на ro, ви побачите дивні відмови: редагування конфігів VM не працює, редагування сховищ не працює, задачі падають з вводячими в оману помилками.

Рішення: Якщо ro — сприймайте це як проблему кластера/кворуму, поки не доведено протилежне.

Задача 14 (бонус): Вловити «нема місця» так, як бачить це ядро

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

Значення: Кореневий розділ на 98% — це не «майбутня проблема». Це поточне джерело випадкових відмов задач (логи не пишуться, тимчасові файли не створюються, dpkg ламається).

Рішення: Якщо root заповнений: почистіть його зараз, потім перезапустіть задачу. Не «продовжуйте пробувати» і не чекайте, що саме вирішиться.

Це вже більше ніж 12 дій. Добре. Ваше завдання не запам’ятати їх усі; воно полягає в тому, щоб інтерналізувати відповідність: задача → демон → підсистема → команда правди.

Типові режими відмов за категоріями

Бекапи (vzdump), що падають «випадково»

Бекапи зачіпають майже все: логіку снапшотів гостя, сховище, стиснення, мережу (якщо віддалене) і прибирання по ретеншену. Якщо бекап падає, причина зазвичай не в «vzdump». Це:

• неможливість зробити снапшот (відсутній guest agent або провал фризу файлової системи)
• сховище не може створити тимчасові файли (права, немає місця, застарілий монтувальний стан)
• таймаути через повільні диски або перевантажене NFS/Ceph
• конкуренція за блокування: попередній бекап ще виконується або застарілий lock-файл

Куди дивитись спочатку: лог задачі для невдалої підкоманди (qemu-img, vma, zstd, tar) і потім логи ядра на предмет I/O зависань.

Міграції, що падають з таймаутами

Жива міграція — це вистава з трьома актами:

1. Оркестрація (SSH, pvedaemon на обох кінцях)
2. Передача стану (сторінки RAM, стан пристроїв)
3. Синхронізація сховища (залежно від спільного сховища чи локального + реплікації)

Помилки часто корелюють із невідповідністю MTU на виділеній мережі міграції, правилом фаєрволу, що блокує епемерні порти, або тим, що сховище на вузлі призначення не «дійсно готове», навіть якщо PVE каже, що воно active.

Помилки запуску VM, що виглядають як драматичні повідомлення QEMU

QEMU повідомлення докладні, але чесні. Коли ви бачите:

• Could not open ... Permission denied → політика/права або невідповідність шляху до блоку
• Device or resource busy → застарілий процес тримає пристрій, залишки qemu або обсяг ZFS ще використовується
• No such file or directory → шлях сховища невірний, датасет відсутній, сховище не змонтоване
• Invalid argument → часто невідповідність ядро/драйвер або зламана опція після оновлення

Кластерні задачі, що падають, бо кластер «ніби працює»

Кластери Proxmox можуть бути оманливо функціональними, але зламаними: вузли пінгуються, UI відкривається, але запис конфігів не працює або задачі зависають. Якщо помилений кворум, /etc/pve стає тільки для читання, щоб уникнути split-brain записів. Це добре спроектовано, але виглядає як саботаж опівночі.

Завдання зі сховищем, що падають, бо сховище «active», але незручне

«Active» у pvesm status означає, що Proxmox бачить визначення сховища і воно пройшло перевірку активації. Це не гарантує:

• що NFS стабільний (воно може бути змонтоване, але застаріле/зависле)
• що Ceph здоровий (він може відповідати, але бути degraded або блокувати I/O клієнтів)
• що ZFS має достатньо місця (воно може бути онлайн, але фактично повне через снапшоти)

Типові помилки: симптом → корінна причина → виправлення

Це відмови, які я бачу постійно, бо вони підступні, а не складні.

1) Симптом: «TASK ERROR: command ‘vzdump …’ failed» з кодом виходу 255

Корінна причина: Код 255 часто означає, що оболонка повідомляє про невдачу підкоманди. Справжня помилка була раніше: відмова в доступі, провал снапшоту або проблема віддаленого сховища.

Виправлення: Читайте лог задачі зверху і знайдіть перший рядок ERROR:. Потім перевірте journalctl -u pvedaemon за той же час.

2) Симптом: Міграція падає з «connection timed out» або «ssh exited with status 255»

Корінна причина: Не одна річ. Зазвичай фаєрвол/MTU/маршрутизація на шляху міграції або зламана довіра SSH між вузлами.

Виправлення: Переконайтеся, що sshd досяжний вузол-до-вузла, перевірте узгодженість MTU через ip link, і перевірте правила фаєрволу на обох кінцях. Якщо використовуєте виділену мережу міграції — тестуйте її безпосередньо.

3) Симптом: Запуск VM падає після оновлення, але вчора все працювало

Корінна причина: Часткові оновлення або невідповідність kernel/modules/userspace. Іноді профілі AppArmor змінюються і починають відмовляти шляхам, які раніше дозволені.

Виправлення: Переконайтеся, що вузол повністю оновлено і перезавантажено в очікуване ядро. Перевірте journalctl -p err..alert на предмет відмов AppArmor і помилок ядра.

4) Симптом: Задачі не можуть змінити конфіги VM; UI каже permission denied або «file is read-only»

Корінна причина: Кластер втратив кворум; pmxcfs тільки для читання.

Виправлення: Перевірте pvecm status. Виправте зв’язок corosync. Не «обходьте» проблему редагуванням файлів деінде; так виникає split-brain дрейф конфігів.

5) Симптом: Сховище «active», але бекапи/міграції зависають кілька хвилин і потім падають

Корінна причина: Застаріле NFS-монтування або заблокований I/O. Монтування є, але I/O застряг.

Виправлення: Перевірте логи ядра на NFS-таймаути, перевірте здоров’я NFS-сервера і розгляньте параметри монтування hard vs soft. Якщо хост застряг в стані D, можливо, доведеться відновити шлях сховища перед відновленням Proxmox.

6) Симптом: «no space left on device» хоча df показує вільне місце

Корінна причина: Вичерпані inode, квота ZFS dataset, ZFS pool майже повний із через copy-on-write штрафи, або досягнуто порогів fullness у Ceph.

Виправлення: Перевірте використання inode (df -i), квоти та роздування снапшотів ZFS (zfs list -o space), і пороги заповненості Ceph при потребі.

7) Симптом: «неможливо активувати сховище» після перезавантаження

Корінна причина: Мережева система з’являється після підняття мережі, або відсутня резолюція імен, або systemd ordering неправильно налаштовано.

Виправлення: Перевірте DNS, маршрути і подумайте про залежності systemd для монтувань. В NFS переконайтеся, що юніт монтування чекає network-online. Потім реактивуйте сховище і повторіть задачі.

8) Симптом: LXC не стартує з помилками cgroup або монтування

Корінна причина: Очікування kernel/cgroup v2 проти конфіг контейнера, AppArmor confinement або налаштування nesting.

Виправлення: Запустіть pct start <id> --debug, потім перевірте journalctl -u pvedaemon і логи ядра на повідомлення про cgroup. Виправляйте опції контейнера свідомо, а не методом тику.

Жарт №2: «Воно працювало вчора» — це не діагноз; це історія перед сном, яку система розповідає, перш ніж зіпсувати ваш ранок.

Три корпоративні міні-історії з польових боїв

Інцидент 1: Аутейдж через неправильне припущення (спільне сховище ≠ консистентне сховище)

Середня компанія мала двовузловий кластер Proxmox зі «спільним сховищем» на NFS. UI показував NFS datastore як активний на обох вузлах. Міграції були рутинними. Бекапи зелені. Усі спали спокійно.

Потім під час вікна обслуговування інженер мережі замінив комутатор, і один вузол повернувся з іншим конфігом VLAN-тагування. Вузол все ще міг дістатися до NFS-сервера періодично — достатньо, щоб монтування існувало — але великі I/O ставали зависати. В термінах Proxmox сховище було «active». Насправді це була пастка.

Жива міграція почалася в робочий час. Задача впала з таймаутом. На виклику вважали, що це «нестабільність міграції Proxmox», повторили двічі, потім спробували іншу VM. Тепер кілька VM зависли з утримуваними блокуваннями. UI наповнився записями TASK ERROR, що всі виглядали майже однаково.

Виправлення було нудним: перевірити I/O NFS безпосередньо читанням/записом на монтуванні, перевірити логи ядра на таймаути NFS і виправити VLAN-тагування. Урок запам’ятався: не вважайте «mounted» за «healthy», і не повторюйте міграції сліпо. Повторні спроби перетворюють одну невдачу в чергу невдач.

Інцидент 2: Оптимізація, що дала протилежний ефект (швидші бекапи, повільніший кластер)

Інша команда хотіла прискорити нічні бекапи. Вони перейшли з gzip на zstd, ввімкнули декілька паралельних бекапів і почувалися розумними. CPU мав запас. Сховище було «швидким». Що могло піти не так?

Пішло не так підвищення латентності I/O. Паралельні jobs vzdump створювали сплески читань із ZFS zvols одночасно з великими потоками запису стиснених даних на NFS-ціль. ZFS робив своє: намагався кешувати і copy-on-write. NFS додав мінливість. Результат — періодичні I/O-стали.

Задачі Proxmox почали падати з розмитими повідомленнями: таймаути, затримки комітів снапшотів, «unable to freeze filesystem», іноді timeouts команд монітора VM. Команда тиждень дивилася в логи Proxmox, переконана, що гіпервізор нестабільний. Логи ядра сказали правду: блоковані задачі чекають I/O і спайки латентності NFS.

Відкат був не драматичним. Вони зменшили паралелізм, призначили фіксовані вікна бекапів і — найголовніше — припинили писати бекапи по тій же мережі, що і інший чутливий трафік. Бекапи стали трохи повільнішими. Все інше — знову надійним. Оптимізація не-блокуючої частини системи — якраз шлях створити вузьке місце.

Інцидент 3: Нудна, але правильна практика, яка врятувала день (синхронізація часу + дисципліна логів)

Фінансово орієнтована компанія мала кластер Proxmox з Ceph. У них була сувора політика: кожен вузол повинен мати працюючий синхронізований час, і логи зберігалися з достатнім ретеншеном, щоб охопити вихідні. Ніхто не святкував це. Просто політика, підтримувана автоматизацією.

Одної п’ятниці вночі вузол почав кидати TASK ERROR під час реплікації і операцій Ceph. Повідомлення в UI були загальні. Але команда одразу зкореляла події, бо часові мітки узгоджувалися на всіх вузлах. Вони побачили, що відмови почалися одразу після конкретної мережевої зміни і що flaps corosync передували попередженням Ceph.

Оскільки логи зберігалися, а час був коректний, вони швидко простежили коренну причину: невірні налаштування jumbo frame спричиняли втрату пакетів на інтерфейсі, що дестабілізувало мережу кластера і викликало каскадні таймаути. Виправили узгодженість MTU, подивилися, як corosync стабілізується, і задачі перестали падати.

Нічого героїчного. Просто нудні основи: синхронізовані годинники, консистентний ретеншен логів і звичка перевіряти corosync перед тим, як звинувачувати Ceph або Proxmox. Ось як виглядає «операційна зрілість», коли вона не намагається вам щось продати.

Чеклісти / покроковий план

Чекліст A: Коли бачите «TASK ERROR» і маєте 10 хвилин

1. Скопіюйте UPID з деталей задачі.
2. Відкрийте сирий лог задачі в /var/log/pve/tasks/ і знайдіть перший реальний рядок ERROR:.
3. Витягніть журнал демона навколо тієї ж хвилини: journalctl -u pvedaemon (або pvescheduler для планових задач).
4. Розподіліть проблему по корзинах: сховище, кластер, гість, мережа, хост.
5. Запустіть одну команду правди для тієї корзини (pvesm status/zpool status/pvecm status/qm start --debug/dmesg -T).
6. Рішення: повторна спроба дозволена лише після усунення причини (місце, права, кворум, зв’язність). Ніколи не робіть повторну спробу як метод діагностики, якщо система не ідемпотентна і ви цього не знаєте.

Чекліст B: Помилки, пов’язані зі сховищем (бекапи, реплікація, приєднання дисків)

1. pvesm status — чи сховище active?
2. df -hT — чи root або цільовий монтувальний розділ повний?
3. Якщо ZFS: zpool status -x та zfs list -o space — стан пулу і роздування снапшотів.
4. Якщо Ceph: ceph -s — чи HEALTH_OK? Якщо ні, очікуйте дивні ефекти.
5. journalctl -k — є I/O помилки, ресети, завислі задачі?
6. Виправте вузьке місце, потім запустіть рівно одну задачу для валідації.

Чекліст C: Помилки, пов’язані з кластером (редагування конфігів, міграції, HA)

1. pvecm status — чи є кворум?
2. journalctl -u corosync — flaps лінку, таймаути токена?
3. mount | grep /etc/pve — чи pmxcfs rw?
4. Виправляйте мережу/лінки кластера першочергово. Не «примушуйте» операції на безкворумному кластері, якщо ви не приймаєте ризик split-brain.

Чекліст D: Помилки старту гостя

1. Запустіть старт гостя в режимі відлагодження (qm start --debug або pct start --debug).
2. Шукайте шляхи файлів і імена пристроїв у помилці. Це ваші якорі.
3. Переконайтеся, що підлягаючий об’єкт сховища існує (zvol, qcow2, rbd image, логічний том).
4. Перевірте шари безпеки на відмови (AppArmor) і логи ядра.
5. Лише після цього: розглядайте регрес конфігу (тип машини, CPU-флаги, опції пристроїв).

Цікавинки та історичний контекст (щоб логи стали зрозумілішими)

• UPID — система ідентифікації задач Proxmox: він кодує вузол, PID, час початку та тип задачі. Створений для розподіленого відстеження в кластерах.
• Proxmox опирається на модель сервісів Debian: багато «проблем Proxmox» насправді — проблеми systemd/journal/ядра під маскою Proxmox.
• /etc/pve — не звичайна файлова система: це pmxcfs, FUSE-базована кластерна файлова система. Коли кворум втрачається, вона може перейти в режим лише для читання, щоб запобігти split-brain.
• Поведінка кворуму corosync навмисно сувора: відмова від записів без кворуму — дизайн-рішення, яке віддає перевагу коректності над зручністю.
• Зміни copy-on-write у ZFS змінюють симптоми відмов: пули можуть бути «healthy», але неймовірно повільними або фактично непридатними, коли майже заповнені, бо кожен запис стає дорогим.
• Стан Ceph — це більше ніж «up»: кластер Ceph може відповідати на команди, але бути настільки degraded, що таймаутить клієнтські I/O під час відновлення.
• vzdump — це обгортка: інструмент бекапу організує снапшоти і пакування, але справжня робота відбувається в qemu, бекендах сховища і інструментах стиснення.
• Логи задач зберігаються локально: в мультивузловому кластері треба читати логи на вузлі, що виконав задачу, а не на вузлі, де ви клікнули в UI.
• Багато відмов — це проблема кореляції часу: без адекватного синхронізованого часу ви не зможете корелювати події corosync, помилки ядра і відмови задач. Логи стають художньою літературою.

Питання й відповіді

1) Де точно знайти лог для задачі, яка показує «TASK ERROR» в UI?

На вузлі, що її виконав: /var/log/pve/tasks/. Використайте UPID, щоб знайти точний файл (або grep по індексу в /var/log/pve/tasks/index).

2) Чому UI Proxmox показує так мало деталей для TASK ERROR?

Тому що UI рендерить зведення. Справжня помилка часто знаходиться раніше у виводі задачі або в журналі демона, що її виконував.

3) Який демон перевіряти в journalctl для більшості відмов задач?

Спочатку pvedaemon. Для планових задач, як бекапи, також перевіряйте pvescheduler. Для членства в кластері і кворуму — corosync і pve-cluster.

4) Моя задача впала на вузлі A, але я залогінений на вузлі B в UI. Це має значення?

Так. Логи задач локальні для вузла, що виконав задачу. Якщо ви читаєте логи на невірному вузлі, висновок буде «логів немає», і ви почнете здогадуватися.

5) Я часто бачу «exit code 255». Що це означає?

Зазвичай «команда завершилася з помилкою, і оболонка це повідомляє». Сам по собі код рідко є коренем проблеми. Знайдіть ранні рядки: permission, path, space, timeout, snapshot failure.

6) Як визначити, чи відмова пов’язана з кластером/кворумом?

pvecm status. Якщо Quorate: No, очікуйте дивні задачі і збої запису конфігів. Також перевірте, чи /etc/pve змонтовано в режимі тільки для читання.

7) Бекапи падають, але сховище «active». Що далі?

«Active» не означає «healthy». Перевірте логи ядра на таймаути сховища, підтвердьте вільне місце і доступність inode, і перевірте здоров’я бекенда сховища (ZFS/Ceph/NFS).

8) Який найшвидший спосіб дебагу VM, що не стартує?

Запустіть qm start <vmid> --debug на вузлі і прочитайте точний рядок помилки QEMU. Потім валідуйте згаданий шлях диска/пристрою і перевірте логи ядра/AppArmor.

9) Коли перезавантажувати вузол Proxmox під час інциденту TASK ERROR?

Коли ви підтвердили, що відмова викликана станом хоста, який безпечно не очиститься: завислий I/O, проблеми драйверів ядра або невідповідність kernel/userspace після оновлення. Перезавантаження як перша дія — шлях втратити судові дані.

10) Чи потрібна централізована система логування для розслідувань Proxmox?

Вона допомагає, але не є обов’язковою для пошуку кореня проблеми. Головне — правильний вибір вузла, читання логів за UPID і доступ до журналу з кореляцією по часу.

Наступні кроки, які ви можете зробити сьогодні

1. Практикуйте workflow з UPID: візьміть будь-яку завершену задачу, знайдіть її UPID і прослідкуйте від UI → /var/log/pve/tasks/ → journalctl. Зробіть це м’язовою пам’яттю.
2. Визначте ваші «команди правди» для кожної підсистеми і запишіть їх для вашого середовища (ZFS vs Ceph vs NFS змінює початкові питання).
3. Припиніть сліпі повторні спроби: введіть правило — максимум одна повторна спроба, і тільки після гіпотези та перевірки. Повтори створюють блокування, нагрузку і ще гірші логи.
4. Базовий моніторинг здоров’я кластера: перевірте статус кворуму, стабільність corosync і режим монтування pmxcfs в спокійний час, щоб відразу розпізнати аномальний вивід.
5. Слідкуйте за кореневим файловим простором: тримайте вільне місце на / і /var. Відмови задач через повний root диск — соромно, бо їх можна уникнути.

Якщо ви зробите ці п’ять речей, «TASK ERROR» перестане бути невизначеною образою і стане тим, чим він завжди був: вказівником на конкретну підсистему, яка поводиться неправильно. Інциденти ще будуть. Ви просто завершуватимете їх швидше і з меншими здогадками.