Завислі завдання Proxmox: як безпечно очистити завислі роботи та процеси

January 2, 2026 • February 3, 2026 • Читання: 7 хв • Views: 14

Було корисно?

Деколи Proxmox поводиться як спокійний, розумний гіпервізор. Інші дні — ніби будинок з привидами: бекапи, що ніколи не завершуються, «TASK ERROR: interrupted by signal», LXC, який відмовляється зупинятися, і індикатор у GUI «running…», що переживе вашу каву.

Складність не в тому, «як його вбити». Складність — знати що саме ви насправді вбиваєте, на що чекає система (сховище? кворум кластера? ядровий D-state?) і як розвернути ситуацію так, щоб тимчасове зависання не перетворилося на корупцію даних.

Що насправді означає «зависло» в Proxmox (і чому GUI бреше)

У Proxmox більшість операцій, які ви запускаєте в UI, перетворюються на фонові завдання, що ними керують кілька демонів: pvedaemon, pveproxy, pvescheduler та інші. Ці завдання можуть порождати додаткові процеси: vzdump для бекапів, qm для дій з QEMU VM, pct для LXC, утиліти zfs, команди rbd або просто rsync.

«Зависло» зазвичай означає одну з цих ситуацій:

Користувацький процес чекає на блокування, мережевий сокет або дочірній процес, який не повертається.
Процес заблокований у просторі ядра (D-state), зазвичай чекаючи дискового або мережевого вводу/виводу. Це найнеприємніше: можна надсилати сигнали цілий день, але він не помре, поки ядро не завершить виклик.
Тримаються «локи» Proxmox (наприклад, лок на конфіг VM або lock для vzdump). Іноді це коректно. Іноді лок застарів — робота померла, але лок не прибрали.
Файлова система кластера (pmxcfs) працює некоректно. Якщо вузол не може надійно зафіксувати зміни конфігу, завдання, що торкаються конфігів VM або визначень сховища, можуть зависнути дивним чином.
Сховище — вузьке місце, а завдання лише передає повідомлення. ZFS scrub, насичений пул, завислий NFS-монтаж, деградований Ceph — усе це може заморозити «просту» дію, як зупинка/запуск, snapshot або бекап.

Статус у Proxmox UI не є авторитетним. Це погляд у журнали завдань та стан кластера, який може запізнюватися або не оновлюватися, коли підлегла система завантажена. Не «клацайте сильніше». Спостерігайте як доросла людина.

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

Якщо у вас аварія, нема часу милуватися тонкощами станів процесів у Linux. Потрібен швидкий фільтр, щоб знайти вузьке місце.

Перше: підтвердіть, чи це сховище, кластер чи одиночний процес

Чи вузол забитий ввід/виводом? Високий iowait, заблоковані задачі в dmesg, затримки пулу ZFS, повільні операції Ceph або завислий монтаж кричать «сховище».
Чи вузол у кворумі і чи pmxcfs записуваний? Якщо комунікація кластера порушена, завдання, що змінюють конфіг, можуть «зависнути», намагаючись повторити або чекати.
Чи це лише одна дія для VM/контейнера? Тоді скоріше за все проблема на гостьовому рівні: завислий QEMU, QMP не відповідає, teardown пристрою не відбувається, snapshot бекапу утримує ресурс або файл лок.

Друге: знайдіть точний процес і причину очікування

Отримайте UPID завдання з UI/журналу завдань або через pvesh.
Знайдіть PID і проінспектуйте стан: ps, top, pstree, cat /proc/PID/stack, wchan.

Третє: оберіть найменш ризикове втручання

Якщо це застарілий лок Proxmox: видаліть лок після перевірки, що жоден активний процес ним не володіє.
Якщо це зависання в userspace: зупиніть/вбийте дочірні процеси послідовно, потім батьківський таск.
Якщо це D-state очікування I/O: не грайте в whack-a-mole з kill -9. Виправте шлях I/O, потім очищуйте.
Якщо це cluster/pmxcfs: відновіть кворум або тимчасово працюйте локально з дисципліною (і усвідомленням ризику).

Цікаві факти та історичний контекст (чому це повторюється)

Linux «D-state» — класична пастка для операторів десятиліттями: процес у нерозривному сні ігнорує сигнали до завершення виклику ядра. Ось чому «kill -9» іноді виглядає безпорадним.
Завдання Proxmox використовують UPID (унікальні ідентифікатори процесів), що кодують вузол, PID, час запуску й тип. Це не просто ID; це крихти шляху.
pmxcfs — це кластерна файлова система на FUSE, що живе в оперативній пам’яті й синхронізує конфіг через corosync. Якщо вона зависла, читання/записи конфігів можуть поводитися дивно, попри те, що диск ОК.
Резервні копії на основі snapshot змінили режими відмов: сучасні потоки бекапів Proxmox залежать від QEMU guest agent, створення snapshot і флашів сховища. Збої часто бувають «координаційними», а не лише повільними дисками.
ZFS навмисне віддає пріоритет консистентності над чуйністю. В певних шляхах помилок ZFS чекатиме, а не вгадуватиме. Це функція, доки ви не сидите біля замерзлого бекапу о 02:00.
NFS з «hard» монтуванням може зависати безкінечно за задумом (він постійно повторює запити). Це добре для коректності і жахливо для завершення завдань, коли NAS має проблеми.
«Повільні операції» Ceph часто маскують мережеві проблеми. Симптом сховища з’являється першим; корінь проблеми може бути в підкиданні порту комутатора.
Зависання stop/reboot у QEMU часто пов’язані з teardown пристроїв: застряглий virtio-blk flush, мертва сесія iSCSI або PCI passthrough-пристрій, що не скидається коректно.

Правила безпеки: що робити перед тим, як щось чіпати

Коли завдання зависають, люди стають агресивними. Саме так «завислий бекап» перетворюється на «корумпований диск VM і незручну нараду». Ось базова дисципліна.

Правило 1: Не видаляйте локи, поки не доведете, що вони застаріли

Лок Proxmox часто існує тому, що щось активно змінює стан VM. Якщо ви його видалите, поки завдання ще працює, можете накласти операції, що мали виконуватись послідовно.

Правило 2: Віддавайте перевагу зупинці дочірнього процесу, а не демонів

Вбивати pvedaemon через один завислий бекап — це як перезавантажити маршрутизатор через те, що одна вкладка браузера не завантажується. Формально це щось робить; але рідко це перший правильний крок.

Правило 3: Якщо процес у D-state — припиніть намагання «вбити» його

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

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

Щонайменше: журнал завдання, journalctl навколо часу збоїв і стан процесу. Якщо пізніше доведеться пояснювати, що сталося, «я вбив щось і воно зникло» — це не інцидентний звіт.

Жарт №1: «Kill -9» — це не стратегія усунення несправностей; це зізнання у поразці з пунктуацією.

Практичні завдання (команди + що означає вивід + рішення)

Це ходи, які я реально використовую в production. Кожне завдання містить реальну команду, приклад виводу, що ви побачите, що це означає і яке рішення це підказує.

Завдання 1: Перелік запущених завдань Proxmox і визначення UPID

cr0x@server:~$ pvesh get /nodes/pve1/tasks --running 1
┌──────────────────────────────────────────────────────────────────────────────────────┬───────────────┬────────┬─────────────┬──────────┬────────┐
│ upid                                                                                 │ type          │ status │ starttime   │ user     │ id     │
╞══════════════════════════════════════════════════════════════════════════════════════╪═══════════════╪════════╪═════════════╪══════════╪════════╡
│ UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:                            │ vzdump        │ running│ 1735019546  │ root@pam │ 101    │
│ UPID:pve1:00013210:03F4C2C8:676D2C4B:qmstop:205:root@pam:                            │ qmstop        │ running│ 1735019595  │ root@pam │ 205    │
└──────────────────────────────────────────────────────────────────────────────────────┴───────────────┴────────┴─────────────┴──────────┴────────┘

Що це означає: У вас два запущені завдання. Одне — бекап VM 101. Друге — операція stop для VM 205.

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

Завдання 2: Витягніть журнал завдання для завислого job

cr0x@server:~$ pvesh get /nodes/pve1/tasks/UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:/log
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
INFO: VM Name: app01
INFO: include disk 'scsi0' 'local-zfs:vm-101-disk-0' 200G
INFO: creating vzdump archive '/mnt/pve/backup-nfs/dump/vzdump-qemu-101-2025_12_26-01_12_26.vma.zst'
INFO: started backup task 'UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:'
INFO: status: 0% (loading)
INFO: backup is sparse: 58% (data 42%)

Що це означає: Завдання стартувало нормально та зараз зависло на ранній стадії («loading»), часто натяк на очікування на I/O сховища або snapshot/flush.

Рішення: Спочатку перевірте стан системи та сховища, перш ніж щось вбивати.

Завдання 3: Визначте PID за UPID

cr0x@server:~$ ps -eo pid,etimes,stat,cmd | egrep 'vzdump|pvedaemon|UPID' | head
  7714   1289 Ssl  pvedaemon worker UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
  7760   1281 S    /usr/bin/perl /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd

Що це означає: Worker має PID 7714; він породив реальний робочий процес (vzdump) PID 7760.

Рішення: Досліджуйте PID 7760. Вбивство worker без очищення дітей може залишити напівзакінчені артефакти.

Завдання 4: Перевірте, чи процес у D-state (нерозривний сон)

cr0x@server:~$ ps -o pid,stat,wchan,cmd -p 7760
  PID STAT WCHAN  CMD
 7760 D    nfs_wait_on_request /usr/bin/perl /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd

Що це означає: Процес у стані D і чекає в nfs_wait_on_request. Сигнали не допоможуть, поки NFS-виклик не повернеться.

Рішення: Припиніть розглядати це як «проблему завдання Proxmox». Це проблема NFS. Перевірте монтаж, мережевий шлях та NAS.

Завдання 5: Перевірте завислі монтування (мовчазний вбивця завдань)

cr0x@server:~$ mount | grep '/mnt/pve/backup-nfs'
10.10.20.50:/export/pve-backups on /mnt/pve/backup-nfs type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.10.20.11,local_lock=none)

Що це означає: Це hard-монтаж NFS (нормально для коректності). Якщо сервер повільний або недоступний, клієнтські процеси можуть зависати безкінечно.

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

Завдання 6: Підтвердіть системний I/O біль (iowait і заблоковані процеси)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  8      0 512344  89312 845992    0    0   112   984  921 1650  6  4 30 60  0
 1  7      0 508120  89316 846200    0    0    96   812  880 1543  5  3 27 65  0
 0  9      0 509004  89320 846380    0    0    72   900  915 1602  4  3 25 68  0

Що це означає: Високий wa (iowait) і багато заблокованих процесів (b) вказують на I/O-столяння. Це узгоджується з процесом у D-state, який чекає на NFS.

Рішення: Перемістіть усі зусилля на діагностику сховища/мережі. Вбивство задач цього не вирішить.

Завдання 7: Визначте, хто тримає лок Proxmox на VM

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

Що це означає: VM 205 має лок на операцію stop. Це може бути коректно (stop у процесі) або застарілим (stop завершився з помилкою і лишив лок).

Рішення: Перевірте, чи дійсно є активне завдання stop для цієї VM, перед очищенням локу.

Завдання 8: Перевірте активне завдання qmstop і стан QEMU процесу

cr0x@server:~$ ps -eo pid,stat,cmd | grep -E 'qemu-system|qm stop 205' | grep -v grep
 8122 Sl   /usr/bin/kvm -id 205 -name vm205 -m 16384 -smp 8 -machine q35 ...

Що це означає: QEMU працює. Завдання stop може зависнути у QMP-зв’язку або QEMU застряг на teardown I/O.

Рішення: Запитайте статус монітора QEMU і перевірте, чи сховище не зависло.

Завдання 9: Запитайте статус QEMU через qm monitor (швидка перевірка)

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

Що це означає: QEMU відповідає на моніторні команди. Це добре: ймовірно, він не в ядерній I/O комі.

Рішення: Спробуйте коректне завершення роботи (qm shutdown) і перевірте guest agent, якщо налаштовано. Уникайте qm stop, якщо це не необхідно.

Завдання 10: Перевірте журнали systemd, пов’язані з завданням

cr0x@server:~$ journalctl -u pvedaemon -u pvescheduler -u pveproxy --since "30 min ago" | tail -n 40
Dec 26 01:12:26 pve1 pvedaemon[1650]: starting task UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
Dec 26 01:12:31 pve1 pvedaemon[7714]: vzdump: backup job failed to make progress (waiting for storage)
Dec 26 01:13:15 pve1 pvedaemon[1650]: starting task UPID:pve1:00013210:03F4C2C8:676D2C4B:qmstop:205:root@pam:
Dec 26 01:14:16 pve1 pvedaemon[8120]: qmstop: VM 205 qmp command failed - timeout

Що це означає: Демони прямо говорять, де болить: бекап чекає сховище; QMP таймаут при stop.

Рішення: Для таймауту stop перевірте, чи QEMU не заблокований на I/O. Для бекапу вирішіть проблему NFS/серверу першочергово.

Завдання 11: Шукайте ядрові попередження про «hung task»

cr0x@server:~$ dmesg -T | tail -n 30
[Thu Dec 26 01:15:02 2025] INFO: task vzdump:7760 blocked for more than 120 seconds.
[Thu Dec 26 01:15:02 2025]       Tainted: P           O      6.5.11-8-pve #1
[Thu Dec 26 01:15:02 2025] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[Thu Dec 26 01:15:02 2025] task:vzdump          state:D stack:0     pid:7760  ppid:7714 flags:0x00004006
[Thu Dec 26 01:15:02 2025] Call Trace:
[Thu Dec 26 01:15:02 2025]  nfs_wait_on_request+0x2f/0x90 [nfs]

Що це означає: Ядро підтверджує: завдання заблоковано в NFS. Це не баг Proxmox; це шлях сховища.

Рішення: Виправте доступність/продуктивність NFS; якщо треба термінове відновлення, плануйте контрольований перезавантаження вузла після гарантії безпеки гостьових машин.

Завдання 12: Перевірте стан пулу ZFS і явні затримки

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
  scan: scrub repaired 0B in 00:21:11 with 0 errors on Thu Dec 26 00:40:15 2025
config:

        NAME                         STATE     READ WRITE CKSUM
        rpool                        ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-SAMSUNG_SSD_AAA      ONLINE       0     0     1
            ata-SAMSUNG_SSD_BBB      ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул онлайн, але один пристрій має помилку контрольної суми. Не обов’язково викликає поточне зависання, але це жовтий прапорець.

Рішення: Якщо завдання зависли на локальному ZFS I/O, перевірте затримки (zpool iostat) і обладнання. Навіть «дрібні» помилки можуть корелювати зі стійкими затримками під навантаженням.

Завдання 13: Перевірте латентність і пропускну здатність ZFS (знайдіть горло пляшки)

cr0x@server:~$ zpool iostat -v 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        620G  1.19T    210    980   12.5M  88.3M
  mirror-0                   620G  1.19T    210    980   12.5M  88.3M
    ata-SAMSUNG_SSD_AAA         -      -    105    495   6.25M  44.1M
    ata-SAMSUNG_SSD_BBB         -      -    105    485   6.30M  44.2M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Пропускна здатність пристойна; якщо завдання все одно зависають, проблема може бути в іншому місці (NFS, Ceph або певний путь пристрою), а не в локальному насиченні ZFS.

Рішення: Не звинувачуйте ZFS за рефлексом. Керуйтеся доказами: якщо zpool iostat спокійний, але wchan показує NFS-чекання — слідуйте за NFS.

Завдання 14: Перевірте здоров’я Ceph, якщо ваше сховище — RBD/CephFS

cr0x@server:~$ ceph -s
  cluster:
    id:     8b7a3c8d-4f20-4f0a-8ce8-8c1b0f20d1b2
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 76 sec, osd.3 has slow requests

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: mgr1(active), standbys: mgr2
    osd: 6 osds: 6 up (6 total), 6 in (6 total)

  data:
    pools:   3 pools, 256 pgs
    objects: 18.2k objects, 71 GiB
    usage:   224 GiB used, 2.1 TiB / 2.3 TiB avail
    pgs:     254 active+clean, 2 active+degraded

Що це означає: Повільні операції цілком можуть спричиняти зависання дій Proxmox (snapshot, бекап, stop). Навіть якщо це лише WARN — ваша латентність уже бреше вам.

Рішення: Ставтеся до slow ops як до інциденту продуктивності. Досліджуйте затримки OSD, мережу та процеси backfill/recovery. Не вбивайте задачі просто так — вони знову зависнуть.

Завдання 15: Перевірте pmxcfs і стан кворуму (кластерні причини «локального» зависання)

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

Quorum information
------------------
Date:             Thu Dec 26 01:18:07 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.342
Quorate:          Yes

Що це означає: Кворум в порядку. Це виключає цілу кладу дивних проблем.

Рішення: Якби кворум був No, уникайте записів конфігів і будьте обережні з діями, що потребують стану кластера.

Завдання 16: Знайдіть і безпечно очистіть застарілий лок (тільки після перевірки)

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

Що це означає: Лок видалено з конфігу VM. Це не вбиває жодного запущеного процесу QEMU; лише прибирає захисний механізм серіалізації Proxmox.

Рішення: Виконуйте це лише після підтвердження, що жодна легітимна операція для цієї VM не триває. Якщо QEMU ще завершує stop і ви знімаєте лок, можете створити накладні операції і додаткові помилки.

Завдання 17: Скасувати запущене завдання (best-effort, залежить від стану очікування)

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

Що це означає: Proxmox записав запит на скасування. Якщо процес у userspace, він може зупинитися. Якщо в D-state — не зупиниться.

Рішення: Спочатку використайте cancel з ввічливості; потім вирішіть корінну причину. Не думайте, що OK означає «воно зникло».

Завдання 18: Коректно вбити завислий допоміжний userspace-процес (лише допоміжний)

cr0x@server:~$ pstree -ap 7714 | head -n 20
pvedaemon,7714 worker UPID:pve1:00012A3B:03F4C2B5:676D2C1A:vzdump:101:root@pam:
  └─perl,7760 /usr/bin/vzdump 101 --mode snapshot --storage backup-nfs --compress zstd
     └─tar,7788 --sparse -cf - .

Що це означає: Worker vzdump породив процес tar (або подібний) для архівації. Іноді допоміжний процес застрягає, а батько — ні.

Рішення: Якщо допоміжний процес завис у userspace (не в D-state), можна спробувати завершити його, щоб батько коректно завершився і прибрав локи.

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

Що це означає: Відсутність рядків після заголовка означає, що процес вийшов.

Рішення: Перевірте журнал батьківського завдання. Якщо воно відмотується і прибирає ресурси — все добре. Якщо воно все ще блокується (особливо в D-state) — зупиніться і зосередьтесь на сховищі.

Погляд зі сторони сховища: ZFS, Ceph, NFS, iSCSI і мистецтво чекання

Більшість «завислих завдань Proxmox» — це інциденти зі сховищем в маскарадній формі. UI — це лише кур’єр. Не стріляйте в нього, якщо не впевнені.

ZFS-backed VM: затримки при snapshot і send/receive

У ZFS типовими точками зависання є:

Створення snapshot коли пул під навантаженням (рідко повністю зависає, але може дуже сповільнитись).
ZFS send (реплікація), що чекає на читання диска або загальмований запис на приймальному боці.
Контенція пулу: бекапи, scrubs, resilver та інтенсивні випадкові записи на тих же vdev.

Трюк — відрізнити «повільно, але рухається» від «зупинився». ZFS часто йде повільно, але прагне рухатися. Якщо iostat показує трафік і операції змінюються — це не зависання, а недостатність ресурсів.

NFS-backed backups: семантика «hard» монтувань спричинює D-state

Якщо ціль бекапу — NFS, ви позичаєте стек зберігання в когось іншого й сподіваєтеся, що той не чхне. Коли чхає — клієнт Linux може заблокуватися в ядерних NFS-викликах. Це блокує vzdump, який блокує worker Proxmox, що блокує локи і наступні роботи. Ось чому ви бачите «завислий бекап», який також заважає операціям з VM.

Якщо ваш монтаж NFS — hard (типово), ви не можете «вбити процес» з цього стану. Треба або відновити сервер NFS, або запланувати перезавантаження вузла, щоб очистити залежлі ядерні потоки. Перезавантаження — не соромно; іноді це єдиний чистий варіант.

Ceph-backed сховище: повільні операції перетворюються на завислі дії життєвого циклу

Ceph переважно чесний. Якщо він нездоровий — скаже вам. Але дії Proxmox все одно можуть виглядати «завислими», бо вони чекають на RBD-операції, які уповільнені через відновлення, backfill або мережеву латентність.

Типова картина: stop VM зависає, бо flush гостьового диска не проходить вчасно. Або операція snapshot чекає на RBD-метадані. Якщо бачите slow ops — перестаньте питати «чому Proxmox завис», і почніть питати «чому Ceph повільний».

iSCSI: сесії, що напіввмирають і беруть процеси в заручники

iSCSI може бути ідеально нудним у продакшені — найліпша характеристика для сховища. Коли воно ламається, це може бути повільно: шлях флапає, multipath намагається, таймаути накопичуються, процеси блокуються в нерозривному сні. Завдання, що торкаються цих LUN, зависнуть.

Якщо бачите D-state очікування в blk_mq_get_tag або подібному — ви в шарі блоків. Виправте шлях (мережа, target, multipath) перш ніж намагатися вбити задачі Proxmox.

Одна цитата, яку варто запам’ятати

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

В термінах операцій: якщо ваш «фікс» покладається на те, що сховище саме повернеться — це не фікс. Це молитва з номером тікета.

Погляд зі сторони кластера: pmxcfs, corosync, кворум і чому «локальні» завдання зависають

Кластерний стек Proxmox — це множник продуктивності. Він також джерело несподіваних режимів відмов, коли кластер деградує.

pmxcfs: файлова система конфігів, що може змусити сумніватися в реальності

/etc/pve — це не звичайний каталог. Це кластерна файлова система (FUSE), що зберігається в RAM і синхронізується. Це означає:

Якщо pmxcfs не може зафіксувати зміни, завдання, що пишуть конфіги VM, можуть блокуватись або падати дивним чином.
Якщо вузол ізольований без кворуму, Proxmox може свідомо забороняти певні записи, щоб уникнути split-brain.

Втратa кворуму: режим «усе працює, але нічого змінити не можна»

Втратa кворуму не обов’язково зупиняє ваші запущені VM. Воно зупиняє координовані зміни. Люди тлумачать це як «Proxmox завис». Він не завис; він відмовляється робити небезпечні зміни.

Якщо ви на одному ізольованому вузлі і примусово зробите його «сам на сам», ви можете виконати роботу. Ви також ризикуєте отримати конфліктні конфіги при відновленні кластера. Обирайте цей компроміс свідомо, а не емоційно.

Жарт №2: Corosync без кворуму — як нарада без протоколу: кожен пам’ятає іншу версію правди, і всі вони невірні.

Три корпоративні історії з практики

Міні-історія 1: Інцидент через неправильне припущення

Команда мала Proxmox-кластер із NFS для бекапів. Однієї ночі бекап-завдання почали накопичуватися. UI показував «running» годинами. Старший інженер припустив, цілком логічно, що бекап просто повільний, бо тижневий job обробляє більше даних.

Вони чекали. Потім чекали довше. Операції stop VM почали теж зависати. Припущення перетворилось на «Proxmox перевантажений». Вони перезапустили pvedaemon і pveproxy, щоб «очистити задачі». UI освіжився і було краще хвилин десять — поки знову ні.

Реальна проблема: у NFS сервера були проблеми шляху в мережі. Монтаж був hard, тому процеси заблоковані в D-state. Перезапуск демонів нічого не дав, окрім того, що стер сліди в логах і заплутав on-call.

Відновлення було грубим: відновили шлях до NFS, чекали, поки ядро розблокує виклики, потім скасували jobs і прибрали часткові архіви. Вони також ввели правило: коли бачите D-state з NFS wchan — ваш «завислий бекап» це інцидент NFS. Ескалюйте відповідно.

Міні-історія 2: Оптимізація, що обернулася проти

Компанія хотіла швидші бекапи. Змінили стиснення vzdump на важче і збільшили паралелізм, щоб більше VM бекапилося одночасно. CPU-графіки виглядали «нормально» в робочі години, тож зміна пройшла.

Настала ніч бекапів. Пул ZFS відчув високу write amplification через одночасне snapshotting і стиснення, NFS-ціль став наступним вузьким місцем, латентність зросла. Декілька гостей стали повільними. Декілька qm shutdown таймаутилися, бо QMP чекав на I/O flush.

Команда почала вбивати завислі задачі — це звільнило локи, але не прибрало тиск на підлягаюче сховище. Залишилися часткові артефакти бекапів і повтори, що створили ефект thundering herd.

Виправлення було майже банальним: знизити паралелізм, обрати стиснення, яке відповідає балансу CPU/сховище, рознести важкі роботи в часі і дивитися на iowait і затримки сховища, а не лише на CPU. Урок: «швидші бекапи» — системна задача, а не один регулятор. Оптимізуєте один компонент — інший згорить.

Міні-історія 3: Сумна, але правильна практика, що врятувала ситуацію

Інша організація мала правило: кожен вузол має маленький «break-glass» чекліст у рукописному runbook — як ідентифікувати завдання по UPID, як знайти PID-и і які логи захопити перед втручанням. Ніхто не любив це. Здавалося паперовою тяганиною для машин.

Під час вікна обслуговування flapping iSCSI-шлях. Декілька VM були в порядку. Дві VM мали завислі операції stop, а робота реплікації замерзла. On-call слідував чеклісту: захопив журнали завдань, підтвердив стани процесів, перевірив ядро, перевірив multipath і тільки тоді вирішив про контрольований рестарт сервісів.

Вони помітили критичну деталь рано: завислі процеси були в D-state в шарі блоків, тож їх вбивати марно. Замість цього вони відновили iSCSI-путь, підтвердили, що I/O відновився, й тільки потім повторили stop дії коректно. Ніякої корупції, ніяких панічних перезавантажень, ніяких загадок.

«Нудна практика» і була різницею. У стресі ви не піднімаєтеся до рівня обставин — ви падаєте до рівня своїх операційних звичок. Їх звичка — спочатку докази, потім дія.

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

Цей розділ навмисно конкретний. Узагальнені поради дешеві; простої відповіді на простій випадок немає.

1) Симптом: «TASK OK» ніколи не з’являється; UI показує «running» вічно

Корінна причина: Worker процес заблокований в ядерному I/O (D-state), або UI не може оновлюватися через pmxcfs/проблеми кластера.
Виправлення: Знайдіть PID, перевірте ps STAT і wchan, перегляньте dmesg. Якщо D-state — виправляйте сховище/мережу. Якщо ні — використайте cancel і коректно заверште дочірні процеси.

2) Симптом: «cannot lock file /var/lock/qemu-server/205.conf»

Корінна причина: Дійсний лок, утримуваний активною роботою, або застарілий лок після краху.
Виправлення: Переконайтеся, що немає робочого завдання для цієї VM; перевірте qm config на предмет локу; потім qm unlock 205. Якщо дія VM ще триває — вирішіть її спочатку.

3) Симптом: vzdump завис на «0% (loading)»

Корінна причина: Очікування на flush/snapshot сховища або недоступний цільовий монтаж (NFS/SMB).
Виправлення: Перевірте стан процесу; перевірте здоров’я монтування; перевірте мережевий шлях; для проблем з NFS hard mount — відновіть сервер або плануйте контрольоване перезавантаження.

4) Симптом: qm stop зависає; QMP таймаути

Корінна причина: QEMU заблокований на disk flush або teardown пристрою; відсутній guest agent; висока латентність сховища.
Виправлення: Спробуйте qm shutdown спочатку; перевірте qm monitor; проінспектуйте здоров’я сховища і повідомлення ядра. Якщо QEMU у D-state — виправте шлях I/O. Примусовий stop лише коли ви приймаєте ризик для файлової системи гостя.

5) Симптом: LXC stop зависає

Корінна причина: Процеси контейнера застрягли на NFS всередині контейнера, або блокування cgroup freezer чекає.
Виправлення: Знайдіть PID init контейнера, перевірте стани процесів, перевірте монтування контейнера. Виправте шлях сховища; потім повторіть stop. Уникайте форсованого вбивства, якщо не розумієте ризики для робочих навантажень контейнера.

6) Симптом: завдання випадково падають після кластерного збою

Корінна причина: Втрата кворуму або pmxcfs не здоровий; записи конфігу заблоковані.
Виправлення: Перевірте pvecm status, відновіть кворум, переконайтеся, що /etc/pve відповідає. Уникайте змін конфігу при відсутності кворуму, якщо у вас немає свідомого плану split-brain (зазвичай — ні).

7) Симптом: реплікаційні jobs зависли; zfs send не просувається

Корінна причина: Приймальна сторона повільна або недоступна, мережеве вузьке місце, snapshot утримування або контенція джерельного пулу.
Виправлення: Перевірте стан процесу zfs send; проведіть мережеву діагностику; валідуйте стан приймального dataset; зменшіть конкурентне навантаження (scrub/resilver) під час вікна реплікації.

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

Чекліст A: Безпечно розгорнути завислий бекап vzdump

Отримайте UPID із запущених завдань (pvesh get /nodes/NODE/tasks --running 1).
Витягніть журнал завдання і зафіксуйте останній рядок прогресу.
Знайдіть PID-и (worker + vzdump + допоміжні) за допомогою ps і pstree.
Перевірте стани з ps -o stat,wchan.
Якщо D-state в NFS/блоках: спочатку виправляйте шлях сховища. Не витрачайте час на сигнали.
Якщо зависання в userspace: спробуйте pvesh .../cancel, потім kill -TERM допоміжних процесів, потім батьківський якщо потрібно.
Переконайтеся, що локс на VM очищено та що ніякі нові завдання не стоять у черзі за ним.
Перевірте часткові архіви на цільовому сховищі та видаліть їх лише після підтвердження, що вони неповні і більше не використовуються процесом.
Запустіть один бекап з пониженою паралельністю, щоб валідувати шлях, перш ніж відновити графік.

Чекліст B: Безпечно працювати із завислим stop-завданням для VM

Підтвердіть, що VM дійсно ще працює: ps для PID QEMU і qm status VMID.
Спробуйте qm shutdown (коректно). Якщо guest agent встановлено і працює — ще краще.
Перевірте QMP-реактивність: qm monitor VMID --cmd 'info status'.
Якщо QEMU відповідає, але stop завис: дослідіть латентність сховища і логи teardown пристроїв; розгляньте довший таймаут.
Якщо QEMU в D-state: виправте шлях сховища. Для жорстких відмов — плануйте перезавантаження вузла; не довіряйте примусовим вбивствам.
Лише в крайньому випадку: qm stop VMID (force). Документуйте ризик і перевірте файлову систему гостя після відновлення.
Після відновлення: очистіть застарілий лок (qm unlock VMID), але тільки після перевірки, що жодне активне stop-завдання не лишається.

Чекліст C: Коли підозрюєте проблеми з cluster/pmxcfs

Перевірте кворум: pvecm status.
Перегляньте логи corosync: journalctl -u corosync --since "30 min ago".
Перевірте реактивність /etc/pve (просте читання, як ls, не повинно зависати).
Не проводьте операцій, що змінюють конфіг, якщо немає кворуму, якщо ви не прийняли ризик split-brain.
Відновіть мережу між вузлами, виправте синхронізацію часу, потім перевірте кворум ще раз.
Коли кластер стабільний, перевірте запущені завдання; багато «завислих» задач перетворяться на «failed» і їх можна буде безпечно перезапустити.

Часті питання

1) Чи можна просто перезапустити pvedaemon, щоб очистити завислі задачі?

Можна, але це рідко правильний перший крок. Якщо worker заблокований в D-state через сховище, перезапуск демонів його не розблокує. Ви лише втратите безперервність у логах і заплутаєте відстеження завдань.

2) Який найбезпечніший спосіб зупинити завислий бекап?

Запросіть cancel через endpoint завдання, потім коректно завершіть дочірні процеси (TERM), якщо вони в userspace. Якщо вони в D-state — спочатку виправте сховище; інакше ви створите безлад без фактичної зупинки.

3) Як зрозуміти, що лок застарів?

Зіставте лок із запущеними завданнями та реальними процесами. Якщо VM має lock:, але нема відповідного запущеного завдання і відсутнє дерево процесів — ймовірно лок застарів. Тоді qm unlock буде доречним.

4) Чому іноді «kill -9» не працює?

Тому що процес застряг у нерозривному сні (D-state) в ядрі, зазвичай чекаючи I/O. Сигнал ставиться в чергу, але не буде опрацьований, поки ядро не поверне виклик.

5) Чи безпечно видаляти часткові файли бекапів зі сховища?

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

6) Моя VM не зупиняється і QMP таймаутить. Чи пошкоджена VM?

Не обов’язково. Часто це означає, що QEMU не може завершити flush I/O або операцію з пристроєм, тому не відповідає. Ризик корупції зростає, якщо ви примусово припините роботу, не вирішивши проблему I/O.

7) Чи можна ігнорувати Ceph HEALTH_WARN?

Ні. «WARN» часто означає, що латентність вже достатньо погана, щоб блокувати верхньорівневі операції. Повільні операції — це канарка в шахті; завислі завдання Proxmox — вже обвал.

8) Коли перезавантаження вузла — правильна відповідь?

Коли критичні процеси застрягли в D-state через шлях I/O, який не можна швидко відновити, або коли ядерні потоки зависли і перешкоджають чистому відновленню. Перезавантаження — контрольований скидання, а не моральна поразка.

9) Чому «локальні» задачі падають, коли кластер має проблеми з кворумом?

Тому що «локальна» дія часто все одно торкається синхронізованого кластера конфігу в /etc/pve. Якщо pmxcfs нездоровий або записи заблоковані через кворум, завдання можуть зависати чи відмовитись виконуватись.

10) Як запобігти повторенню завислих задач?

Проектуйте під передбачувану латентність I/O: розмір сховища, обмеження паралелізму бекапів, розділення трафіку бекапу, моніторинг hung tasks ядра і ставлення до попереджень сховища як до інцидентів, а не до дрібниць.

Висновок: наступні кроки, що запобігають повторенню

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

Зробіть ось що далі:

Впровадьте швидкий фільтр діагностики: сховище vs кластер vs процес на гостя.
Навчіть команду розпізнавати D-state і припиняти марні спроби зі сигналами, коли ядро чекає на I/O.
Встановіть розумні обмеження паралелізму бекапів і плануйте важкі операції (scrub, реплікація, масові бекапи) так, ніби вам справді важлива латентність.
Коли очищаєте локи — робіть це як хірург: підтвердьте, потім розрізайте. Ніякого фрістайлу.