Ви натиснули кнопку в Proxmox. Запустити VM. Зупинити контейнер. Знімок. Бекап. Міграція. І потім: TASK ERROR: timeout waiting for …. Інтерфейс дає вам розпливчасту іменну фразу та зупинений секундомір. В проді — сердиті люди і секундомір, що ніколи не зупиняється.
Ключова дія — перестати вважати «timeout» самою проблемою. Тайм‑аут Proxmox — це симптом: якийсь процес чекав на конкретний лок, стан ядра, операцію сховища або крок кластерної файлової системи, і це не завершилося до того, як Proxmox здався. Ваше завдання — визначити на що саме він чекав, а потім виправити подсистему, яка зависла.
Що насправді означають тайм‑аути Proxmox (і чому інтерфейс приховує правду)
Proxmox — це оркестратор. Він координує багато рухомих частин: systemd-сервіси, QEMU, LXC, ZFS, Ceph, блочні пристрої ядра, мережеве сховище та кластерну конфігураційну файлову систему. Коли ви натискаєте «Stop», Proxmox не зупиняє VM магією. Він ввічливо просить QEMU, чекає, поки гість співпрацює, можливо ескалує до SIGKILL, потім чекає від’єднання блочних пристроїв, розмапування томів та звільнення локів конфігурації.
Повідомлення «timeout waiting for …» зазвичай генерує Perl‑шар Proxmox (помічники pvedaemon/pveproxy), який чекає на перехід стану. Тайм‑аути відрізняються залежно від операції і часто захищають від найгіршого дня в експлуатації: завдання, що назавжди зависло, утримує лок і блокує все інше.
Філософія така. Реальність заплутана: якщо ядро зависло в I/O wait, Proxmox покаже «timeout waiting for …» для чогось цілком розумного, наприклад для unmap пристрою, тоді як реальна проблема — померлий HBA, завислий multipath‑шлях або нестабільний OSD Ceph. Потрібно зіставити фразу в логу задачі з конкретним ланцюжком залежностей.
Ось ментальна модель, яка реально працює:
- Завдання Proxmox (UPID) виконується як процес.
- Воно чекає на певну умову: лок, вихід PID, операцію тома, оновлення кластерного файлу.
- Умова залежить від підсистеми: ядро, сховище, мережа, кластер, гість.
- Тайм‑аут показує, яку саме умову не виконано. Логи розкажуть, чому.
Одна операційна істина: «timeout waiting for…» часто означає, що Proxmox ввічливо каже «щось зависло в D‑state і я не можу його вбити». Якщо ви ще не шукали D‑state — ви все ще вгадуєте.
Жарт №1 (короткий і заслужений): Коли Proxmox каже «timeout waiting for lock», це по суті ваш датацентр, що виконує танець «після вас» біля дверей… вічно.
План швидкої діагностики: перші/другі/треті перевірки, що знаходять вузьке місце
Якщо ви зробите лише одну річ інакше після прочитання цього: припиніть ганятися за рядком UI. Починайте з UPID, знайдіть блокуючий процес, а потім визначте підсистему за тим, на що цей процес заблоковано.
Перше: чи сам вузол хворий?
- Перевірте навантаження, D‑state, тиск пам’яті та затримки I/O ядра. Якщо вузол нездоровий — усі задачі підозрілі.
- Якщо ви бачите багато процесів у D‑state, вважайте це інцидентом сховища, поки не доведено інше.
Друге: чи це I/O сховища, контроль‑plane сховища або лок кластера?
- Дані сховища: повільні читання/записи, завислі unmap, затримки flush, SCSI‑reset’и.
- Контроль‑план сховища: повільні mon Ceph, застиглі TXG ZFS, сесії iSCSI, що флапають.
- Кластерний лок: contention в pmxcfs або мертве завдання, що тримає файл‑лок.
Третє: чи гість відмовляється співпрацювати?
- Тайм‑аути зупинки VM часто — гостева ОС, яка ігнорує ACPI.
- Але якщо зупинка блокується на від’єднанні пристроїв — це все одно сховище/хост.
Швидкий чек‑лист для триажу (що виконати негайно)
- Знайдіть UPID у перегляді завдань; зіставте його з рядками логів у
/var/log/pve/tasks/. - Визначте PID і точну точку очікування (лок vs I/O vs вихід процесу).
- Перевірте
dmesgна предмет тайм‑аутів/сбросів сховища у той же проміжок часу. - Перевірте здоров’я Ceph або ZFS (залежно від бекенду).
- Перевірте кворум кластера і відгукливість pmxcfs, якщо зачіпаються конфігурації/локи.
Як зіставити “waiting for …” з реальною підсистемою
Рядки «waiting for …» в Proxmox не випадкові. Зазвичай вони відповідають одній із цих категорій:
1) Очікування локу (серіалізація конфігурації й життєвого циклу)
Поширені фрази: «timeout waiting for lock», «can’t lock file», «lock for VM …», «lock for storage …».
Що насправді вичерпало тайм‑аут: захоплення лока в Proxmox (часто під /var/lock/pve-manager/ або лок всередині pmxcfs), або лок, який утримує інша задача, що ніколи не завершилася.
Ймовірні причини: попередня задача зависла (часто через сховище), або pmxcfs працює повільно/невідповідно через проблеми кластера.
2) Очікування завершення процесу (життєвий цикл QEMU/LXC)
Поширені фрази: «timeout waiting for VM to shutdown», «timeout waiting for ‘qemu’ to stop», «timeout waiting for CT to stop».
Що насправді вичерпало тайм‑аут: Proxmox відправив запит на вимкнення/зупинку і чекав на вихід QEMU/LXC; цього не сталося. QEMU може бути заблокований в I/O ядра, гостя ігнорує вимкнення, або QEMU призупинено і чекає на сховище.
3) Очікування операцій сховища (create/destroy/snapshot/clone/unmap)
Поширені фрази: «timeout waiting for RBD unmap», «timeout waiting for zfs destroy», «timeout waiting for lvremove», «timeout waiting for qm» (під час операцій з дисками), «timeout waiting for vzdump».
Що насправді вичерпало тайм‑аут: команда сховища (rbd, zfs, lvm, iscsiadm, mount) не завершилася. Тут ядро й бекенд сховища зустрічаються — і сперечаються.
4) Очікування оновлень кластерної файлової системи (pmxcfs)
Поширені фрази: «timeout waiting for pmxcfs», «unable to read/write /etc/pve/…», «cfs-lock ‘…’ timed out».
Що насправді вичерпало тайм‑аут: pmxcfs не змогла швидко завершити лок чи оновлення. Корінні причини включають проблеми corosync/kворуму, перевантаження CPU або заповнений диск, що блокує запис (так, буває).
5) Очікування мережі (міграції та віддалене сховище)
Поширені фрази: «migration aborted: timeout», «waited too long for …», «ssh connection timeout» (іноді приховано під загальними тайм‑аутами задач).
Що насправді вичерпало тайм‑аут: TCP застряг, невідповідність MTU, втрата пакетів, або віддалена сторона зависла на операції зі сховищем.
Розбір завдання Proxmox: від UPID до блокуючої системної виклики
Задачі Proxmox логуются з UPID (Unique Process ID), який кодує вузол, PID, час початку та тип задачі. Ваш робочий процес має трактувати UPID як первинний ключ.
Ось практичний спосіб прорватися через шум:
- Знайдіть UPID у логах GUI.
- Відкрийте файл задачі на вузлі, щоб побачити точні внутрішні кроки й часові мітки.
- Знайдіть PID робітника і подивіться його стан (running, D‑state, blocked).
- Використайте інструменти на рівні ядра (стек‑трейси, статистику I/O), щоб побачити, на що він чекає.
Якщо ви читаєте лише високорівневе повідомлення Proxmox, ви пропустите момент, коли ядро десять хвилин кричало «SCSI timeout» у dmesg.
Цитата, бо вона досі орієнтир для операцій: «Hope is not a strategy.» — General Gordon R. Sullivan
Практичні завдання: команди, що означає вивід, і рішення, яке ви приймаєте
Це не «приємні знання». Це ті команди, які ви запускаєте, поки хтось чекає на відновлення, ваше HA флапає, і потрібно вирішити, перезавантажувати вузол чи ганяти кабель.
Завдання 1: Знайти файл лога UPID і читати його як таймлайн
cr0x@server:~$ ls -1t /var/log/pve/tasks/ | head
active
index
UPID:pve01:0000A1B2:019F3A2C:676D3B1C:vzdump:101:root@pam:
UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
cr0x@server:~$ sed -n '1,120p' /var/log/pve/tasks/UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
starttime 1735163817
status: started
command: /usr/sbin/qm shutdown 104 --timeout 60
shutdown VM 104: initiated
shutdown VM 104: waiting for guest to shutdown...
shutdown VM 104: timeout waiting for shutdown
TASK ERROR: timeout waiting for shutdown
Значення: Тепер ви знаєте точну команду та параметр тайм‑ауту (qm shutdown --timeout 60).
Рішення: Якщо гість не відповідає на ACPI, можна ескалювати до qm stop. Якщо це повторюється і збігається з помилками сховища — спочатку діагностуйте I/O хоста.
Завдання 2: Зіставити часові мітки задачі Proxmox з журналами systemd
cr0x@server:~$ journalctl -u pvedaemon -S "2025-12-26 09:30:00" -U "2025-12-26 09:40:00" --no-pager | tail -n 40
Dec 26 09:33:22 pve01 pvedaemon[1412]: starting task UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
Dec 26 09:34:22 pve01 pvedaemon[1412]: task UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam: finished with exit code 255
Значення: Підтверджує, який демон виконав задачу і коли вона провалилася.
Рішення: Якщо pvedaemon регулярно тайм‑аутить у багатьох задачах — дивіться здоров’я вузла і сховища, а не окремі VMs.
Завдання 3: Визначити, чи робітник процес завис (і в якому стані)
cr0x@server:~$ ps -eo pid,ppid,stat,wchan:24,cmd | egrep 'pvedaemon|pveworker|qmshutdown|vzdump' | head -n 20
1412 1 Ss ep_poll /usr/bin/pvedaemon
9856 1412 S do_wait pveworker UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam:
9874 9856 D io_schedule /usr/bin/qemu-system-x86_64 -id 104 -name vm104
Значення: QEMU знаходиться в D‑state (D в STAT) і чекає в io_schedule. Це не «гість не хоче вимикатися». Це «ядро хоста чекає на I/O».
Рішення: Перестаньте намагатися вбити QEMU. Діагностуйте сховище й журнали ядра. Можливо, єдиний вихід — перезавантаження, якщо ядро не може завершити I/O.
Завдання 4: Перевірити dmesg на тайм‑аут/шторм скидів сховища у вікні помилки
cr0x@server:~$ dmesg -T | egrep -i 'timed out|reset|abort|blk_update_request|I/O error|nvme|scsi' | tail -n 30
[Thu Dec 26 09:33:51 2025] sd 2:0:0:1: rejecting I/O to offline device
[Thu Dec 26 09:33:51 2025] blk_update_request: I/O error, dev sdb, sector 9412896 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
[Thu Dec 26 09:33:52 2025] scsi host2: sas: task abort: SUCCESS scmd(0x00000000a1b2c3d4)
[Thu Dec 26 09:33:58 2025] sd 2:0:0:1: timing out command, waited 180s
Значення: Це палкий доказ того, «що саме вичерпало тайм‑аут»: блочний шар ядра не зміг завершити I/O. Proxmox просто вчасно чекав.
Рішення: Розглядайте як інцидент сховища: перевірте кабелі/HBA/шляхи, multipath, стан масиву і подумайте про евакуацію VM.
Завдання 5: Визначити, чи pmxcfs (/etc/pve) повільний або заблокований
cr0x@server:~$ timeout 3 ls -la /etc/pve/nodes/pve01/qemu-server/ | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 26 09:35 .
drwxr-xr-x 4 root www-data 0 Dec 26 09:20 ..
-rw-r----- 1 root www-data 0 Dec 26 09:35 104.conf
Значення: Якщо це зависає або тайм‑аутиться — ваша кластерна файлова система хвора. Коли ls на /etc/pve зависає, багато помилок «timeout waiting for lock» — просто шум наслідків.
Рішення: Перевірте corosync/kворум, процес pmxcfs і завантаження вузла перед тим, як торкатися операцій VM.
Завдання 6: Перевірити кворум і стан corosync (тайм‑аути на рівні кластера)
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 42
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Thu Dec 26 09:36:01 2025
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000001
Ring ID: 1.98
Quorate: Yes
Значення: Якщо Quorate: No або вузли флапають — локи pmxcfs можуть застопоритися або падати.
Рішення: Стабілізуйте мережу кластера, перш ніж довіряти діагностиці «timeout waiting for lock».
Завдання 7: Визначити, який лок утримується і якою задачею
cr0x@server:~$ ls -la /var/lock/pve-manager/ | head
total 0
drwxr-xr-x 2 root root 120 Dec 26 09:36 .
drwxr-xr-x 9 root root 180 Dec 26 08:10 ..
-rw-r--r-- 1 root root 0 Dec 26 09:31 lock-104.conf
-rw-r--r-- 1 root root 0 Dec 26 09:33 vzdump-101.lock
cr0x@server:~$ fuser -v /var/lock/pve-manager/lock-104.conf
USER PID ACCESS COMMAND
/var/lock/pve-manager/lock-104.conf:
root 9856 F.... pveworker
Значення: Лок не містить містики. Це файл, і PID утримує його відкритим.
Рішення: Дослідіть, чому цей PID завис. Вбити робітника може звільнити лок, але якщо він у D‑state — ви його не вб’єте сигналом. Виправте базовий I/O або плануйте перезавантаження вузла.
Завдання 8: Інспектувати завислий PID за допомогою стек‑трейсів ядра (допрацьований, вирішальний крок)
cr0x@server:~$ cat /proc/9874/stack
[<0>] io_schedule+0x12/0x40
[<0>] bit_wait_io+0x11/0x60
[<0>] __wait_on_bit+0x6a/0x90
[<0>] out_of_line_wait_on_bit+0x8a/0xb0
[<0>] __filemap_fdatawait_range+0xd3/0x120
[<0>] filemap_write_and_wait_range+0x4a/0x90
[<0>] blkdev_fsync+0x2e/0x50
[<0>] vfs_fsync_range+0x4a/0xb0
Значення: QEMU блокується, чекаючи завершення flush/fsync. Це — сховище. Можливо, бекенд задубів, пристрій перевантажений або йде фензинг.
Рішення: Припиніть підлаштовувати тайм‑аути вимкнення гостьової ОС. Пішли виправляти шлях до сховища або бекенд.
Завдання 9: Якщо використовуєте ZFS, перевірте стан пулу і джерела латентності
cr0x@server:~$ zpool status -v
pool: rpool
state: ONLINE
scan: scrub repaired 0B in 00:10:12 with 0 errors on Thu Dec 26 03:10:21 2025
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sda2 ONLINE 0 0 0
sdb2 ONLINE 0 0 0
errors: No known data errors
cr0x@server:~$ zpool iostat -v rpool 1 5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
rpool 92.3G 380G 12 420 1.2M 48.9M
mirror 92.3G 380G 12 420 1.2M 48.9M
sda2 - - 6 210 600K 24.4M
sdb2 - - 6 210 600K 24.5M
Значення: zpool status показує, чи ви DEGRADED/FAULTED; zpool iostat показує, чи ви «лупите» пул. Не всі зависання виглядають як DEGRADED — латентність може бути жахливою при «ONLINE» пулі.
Рішення: Якщо iostat показує високі записи і ваші задачі стосуються знімків/знищень, розгляньте contention (вікно бекапу, реплікацію, scrub) і обмежте/переплануйте роботу.
Завдання 10: Якщо використовуєте Ceph, перевірте здоров’я кластера і повільні опи
cr0x@server:~$ ceph -s
cluster:
id: 3c9f3a2c-1111-2222-3333-019f39f0abcd
health: HEALTH_WARN
12 slow ops, oldest one blocked for 87 sec, mon.pveceph01 has slow ops
services:
mon: 3 daemons, quorum pveceph01,pveceph02,pveceph03 (age 6h)
mgr: pveceph01(active, since 6h)
osd: 9 osds: 9 up (since 6h), 9 in (since 6h)
data:
pools: 2 pools, 256 pgs
objects: 1.2M objects, 4.6 TiB
usage: 14 TiB used, 18 TiB / 32 TiB avail
pgs: 255 active+clean, 1 active+undersized+degraded
cr0x@server:~$ ceph health detail | head -n 40
HEALTH_WARN 12 slow ops, oldest one blocked for 87 sec, mon.pveceph01 has slow ops
SLOW_OPS 12 slow ops, oldest one blocked for 87 sec, osd.4 has slow ops
slow ops on osd.4, oldest one blocked for 87 sec, committed, flags = none
Значення: Повільні опи — це те, «що насправді вичерпало тайм‑аут». Proxmox чекає на операцію RBD; Ceph не може її завершити.
Рішення: Припиніть повторювати задачі Proxmox. Стабілізуйте Ceph: перевірте латентність OSD, тиск на backfill/recovery, мережу і відмови дисків.
Завдання 11: Якщо iSCSI/multipath — перевірте сесії та стан шляхів
cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2001-05.com.example:storage.lun1 (non-flash)
tcp: [2] 10.10.20.51:3260,1 iqn.2001-05.com.example:storage.lun1 (non-flash)
cr0x@server:~$ multipath -ll | head -n 60
mpatha (3600a098038314b6d4a2b4b6f6f4b6d31) dm-3 EXAMPLE,Array
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
`- 3:0:0:1 sdc 8:32 active ready running
Значення: Якщо сесій немає або шляхи показують failed/faulty, ваші тайм‑аути — це хост, що чекає на мертвий шлях. Якщо ви бачите queue_if_no_path, I/O може «ввічливо» зависнути замість негайної помилки.
Рішення: Виправте маршрути перед тим, як чіпати Proxmox. Подумайте, чи потрібні вам можливості multipath для віртуалізації; «вішатися вічно» рідко бажано.
Завдання 12: Для NFS/CIFS — перевірте, чи mount’и не зависли (класична «все гальмує»)
cr0x@server:~$ mount | egrep ' type nfs| type cifs'
10.10.30.10:/exports/vmstore on /mnt/pve/nfs-vmstore type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,sec=sys,clientaddr=10.10.30.21)
cr0x@server:~$ timeout 3 stat /mnt/pve/nfs-vmstore
File: /mnt/pve/nfs-vmstore
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 0,53 Inode: 2 Links: 15
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2025-12-26 09:36:10.000000000 +0000
Modify: 2025-12-26 09:33:01.000000000 +0000
Change: 2025-12-26 09:33:01.000000000 +0000
Birth: -
Значення: Якщо stat зависає — NFS заблокований і ваш «timeout waiting for …» — це наслідок. З hard монтами процеси можуть сидіти в D‑state вічно, чекаючи сервера.
Рішення: Поправте NAS/мережу першочергово. Розгляньте опції mount і моніторинг, щоб ненадійний філер не заморожував весь вузол.
Завдання 13: Підтвердити, чи vzdump/бекапи не є схованим власником лока
cr0x@server:~$ pvesh get /nodes/pve01/tasks --limit 5
┌──────────────────────────────────────────────────────────────────────────────┬───────────┬─────────┬────────────┬──────────┬────────────┐
│ upid │ user │ status │ starttime │ type │ id │
╞══════════════════════════════════════════════════════════════════════════════╪═══════════╪═════════╪════════════╪══════════╪════════════╡
│ UPID:pve01:0000A1B2:019F3A2C:676D3B1C:vzdump:101:root@pam: │ root@pam │ running │ 1735163950 │ vzdump │ 101 │
│ UPID:pve01:00009C88:019F39F0:676D39A9:qmshutdown:104:root@pam: │ root@pam │ error │ 1735163817 │ qmshutdown│ 104 │
└──────────────────────────────────────────────────────────────────────────────┴───────────┴─────────┴────────────┴──────────┴────────────┘
Значення: Запущений бекап може утримувати локи знімків або конфігурацій, або просто насичувати сховище і робити інші задачі тайм‑аутними.
Рішення: Якщо бекапи перекриваються з операційними задачами — або краще плануйте, або приймайте ризик. Виберіть свідомо.
Завдання 14: Швидко перевірити I/O тиск на вузлі
cr0x@server:~$ iostat -x 1 3
Linux 6.2.16-20-pve (pve01) 12/26/2025 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
11.20 0.00 6.10 42.30 0.00 40.40
Device r/s w/s rkB/s wkB/s await svctm %util
dm-3 1.2 420.0 9.6 48960.0 85.3 1.9 98.7
Значення: %iowait величезний; await і %util високі. Ваш вузол чекає на сховище. Тайм‑аути Proxmox — лише кур’єр.
Рішення: Обмежте навантаження, призупиніть важкі задачі, діагностуйте перенавантаження бекенду або відмову. Якщо це загальний масив — координуйтеся зі storage‑командою (або станьте storage‑командою).
Моделі відмов, специфічні для сховища (ZFS, Ceph, iSCSI/NFS)
Більшість інцидентів «timeout waiting for …» в Proxmox — це інциденти сховища, одягнені в оболонку UI. UI тайм‑аутиться тому, що сховище повільне. Або зникло. Або «якось там відповідає», що гірше.
ZFS: коли «ONLINE» усе одно болить
ZFS чудово працює з цілісністю даних і досить чесно повідомляє про відмови. Він не зобов’язаний бути швидким, коли ви просите дорогі метадані‑операції, а тим часом ви б’єте пул записами VM.
Шаблони тайм‑аутів, які ви побачите:
- Затримки операцій snapshot/destroy/clone через високий тиск TXG або повільний flush пристрою.
- Затримки зупинки/вимкнення VM, бо QEMU чекає fsync/flush до ZVOL‑пристрою.
- Тайм‑аути реплікацій, бо відправка знімків не встигає або мережа перевантажена.
На що дивитися:
- Латентність на рівні пулу:
iostatawaitі ZFSzpool iostatпропускна здатність. - Тиск ARC і пам’ять: ZFS — споживач пам’яті з власними вподобаннями.
- Час синхронізації транзакцій: довгі sync означають, що все, що потребує sync, чекає довше.
Ceph RBD: контроль‑plane здоров’я перетворюється на латентність data‑plane
Трюк Ceph — розподілена надійність. Податок — коли кластер нездоровий, навіть «прості» операції сповільнюються: мап/unmap RBD, знімки, resize, flatten тощо.
Шаблони тайм‑аутів:
- «timeout waiting for RBD unmap» під час зупинки VM, прибирання міграцій або видалення диска.
- Завдання бекапу тайм‑аутяться, бо читання повільні під час recovery/backfill.
- HA‑failover виглядає зламаним, бо операції зі сховищем застрягли, а не тому, що HA‑логіка погана.
Ceph‑специфічні реаліті‑чекі:
- Повільні опи старші за хвилину — це не «фоновий шум» у VM‑кластерах. Це симптом ресурсного голоду, проблем мережі або дисків, що йдуть у відмову.
- Якщо Ceph відновлюється/робить backfill у повну силу, задачі Proxmox, які чекають своєчасних відповідей від сховища, будуть тайм‑аутитись. Ви або налаштовуєте recovery, або плануєте руйнівні операції поза піком.
iSCSI і multipath: радість «queue_if_no_path»
Найболючіші iSCSI‑відмови — не гучні. Це тихі зависання: шлях помер, multipath ставить I/O у чергу, і кожен процес, що працює з тим LUN, переходить у D‑state. Proxmox не знає. Він чекає на завершення команди. Вона ніколи не приходить.
Якщо ви запускаєте віртуалізацію на iSCSI, вам потрібно свідомо вирішити:
- Fail fast: задачі хибяться, VMs падають або призупиняються, але вузол можна відновити без перезавантаження.
- Hang forever: data‑plane чекає повернення сховища, що може зберегти порядок I/O, але може заморозити ваш хост.
Не дозволяйте конфігурації multipath вирішувати це за вас. За замовчуванням параметри прийняті комісіями, а комісій вас не викликають на пейджинг.
NFS: «hard» монтовання може заморозити і менеджмент
У NFS несподіванка в тому, що сховище — це не тільки місце для дисків; там ще бекапи, шаблони, інколи ISO. Завислий NFS‑mount може призвести до зависання бекапів, але також блокує операції, що перераховують або оновлюють вміст на цьому сховищі.
Коли NFS флапає, Proxmox може тайм‑аутитись під час сканування сховища, запису бекапу або операції монтування. Тим часом ваші shell‑команди зависають, і простий план «перезавантажити» перетворюється на план фензингу.
Кластерна файлова система і локи: pmxcfs, corosync та міфи про застарілі локи
Кластерна конфігурація Proxmox живе в /etc/pve, підкріплена pmxcfs. Це зручно і водночас причина, чому «проблема зі сховищем» може виглядати як «не можу записати конфіг». Якщо вузол перевантажений або кластер нестабільний — прості файлові операції блокуються.
Симптоми pmxcfs, які маскуються під інше
- CLI‑команди зависають, коли вони звертаються до
/etc/pve(наприклад,qm config). - «timeout waiting for cfs-lock» при старті/зупинці VM, особливо навколо HA чи міграцій.
- GUI повільний, бо pveproxy часто торкається конфігурації кластера.
Локи: хороші, погані й завислі
Локи існують, щоб уникнути одночасних операцій над однією конфігурацією VM або станом диска. Вони коректні. Вони також болючі, коли утримувач мертвий.
Правила, що врятують вас:
- Ніколи не видаляйте файли лока бездумно як перший крок. Якщо лок захищає активну операцію зі сховищем — ви можете створити split‑brain на рівні VM (дві конфліктні дії), навіть якщо кластер у порядку.
- Визначте PID‑власника лока. Якщо це нормальний завислий процес (не D‑state), ви можете коректно його завершити. Якщо це D‑state — перестаньте вірити сигналам.
- Тайм‑аути локів часто вторинні. Завислий unmap сховища викликає зависле завдання; це завдання тримає лок; наступна задача тайм‑аутиться, чекаючи лока.
Жарт №2 (короткий і надто правдивий): Ви не можете kill -9 процес у D‑state. Це спосіб Linux сказати «тримайте, будь ласка».
Три короткі історії з корпоративної практики
Коротка історія 1: Інцидент через неправильне припущення
У невеликому кластері Proxmox працювали внутрішні сервіси: тикетинг, CI‑ранери, кілька баз даних, що «не були критичні» (доки не стали). Одного ранку зупинки VM почали падати з “TASK ERROR: timeout waiting for shutdown”. On‑call помилився, вирішивши, що це проблема гостя: «знову Windows update», хтось впевнено пробурмотів — і виявився неправий.
Вони збільшили тайм‑аут вимкнення. Потім спробували qm stop. Воно зависло. Спроби вбити QEMU не дали результату. Переконалися, що це «баг Proxmox», перезапустили pvedaemon — без змін. Тим часом задачі накопичувалися і всі тайм‑аутіли, чекаючи локів.
Поворотна точка — простий ps, що показав кілька процесів QEMU в D‑state, усі в io_schedule. Швидкий погляд у dmesg показав шторм SCSI‑тайм‑аутів на одному шляху. Multipath був налаштований на чергування I/O при зникненні шляху. Чудово для деяких робіт. Катастрофа для гіпервізора, коли контролер масиву перезавантажився.
Виправлення не було «більше тайм‑аутів». Виправлення — відновити здоровий шлях (а пізніше змінити поведінку multipath, щоб хост падав швидше і відновлювався). Постмортем був різким: тайм‑аут вимкнення VM рідко про shutdown, якщо гіпервізор завис у I/O. Вони почали трактувати «D‑state + тайм‑аути» як інцидент сховища за замовчуванням, що скоротило час реагування і зменшило драму.
Коротка історія 2: Оптимізація, що відпрацювала проти
Інша компанія хотіла швидших бекапів. У них було нічне вікно vzdump, яке повзло в години роботи. Хтось запропонував «легку перемогу»: увімкнути більше паралелізму і прискорити знімкові бекапи. Сховище «була достатньо швидким», за піковими показниками від вендора.
Перші ночі були гарні. Бекапи завершувалися раніше. Потім настав день із більшим денним навантаженням. Під час перетину з вікном бекапів з’явилася хвиля помилок timeout waiting for …: комміти знімків застопорилися, зупинки VM тайм‑аутяться, реплікація відстає. Команда гнала локи, кидала задачі і боролася з симптомами.
Реальна причина — транзакційна латентність: часи sync ZFS вилізли при одночасному хворобливому знімковому трафіку і записах VM. Пул залишився «ONLINE», але латентність стала жахливою. Оптимізація — більше паралелізму — виявилася підсилювачем хвостової латентності.
Виправлення — не драматичне: зменшили конкуренцію бекапів, перенесли важкі роботі в окреме вікно і додали прості оповіщення про латентність I/O. Пропускна здатність лишилася пристойною, і система перестала тайм‑аутитись. Урок — класичний SRE: оптимізація для приємного чисельника (тривалість бекапу) може тихо зруйнувати метрику, якою користуються користувачі (tail latency).
Коротка історія 3: Нудна, але правильна практика, що врятувала день
В регульованому середовищі Proxmox працював з Ceph. Нічого екстраординарного, за задумом. Їхня «нудна практика» — сувора кореляція: кожен збій задачі мав бути прив’язаний до часово‑маркованого сигналу бекенду (деталі здоров’я Ceph, журнали ядра, мережні помилки). Ніяких винятків. Це здавалося бюрократією… поки ні.
Одного дня міграції почали падати з тайм‑аутом, а кілька зупинок VM зависли. Повідомлення UI різнилися — хтось говорив про тайм‑аути сховища, інші виглядали як лок‑тайм‑аути. Сувора практика змусила їх витягнути Ceph slow ops і журнали ядра для того самого інтервалу часу.
Вони виявили закономірність: slow ops стрибали у моменти, коли певний порт топ‑of‑rack комутатора флапав. Corosync лишався кворумним, тож кластер виглядав «файн», але Ceph‑трафік бачив переривання і ретр anсмити. Це збільшувало латентність, що збільшувало тайм‑аути, що збільшувало contention локів. Каскадна відмова з ввічливою маскою.
Оскільки вони мали звичку кореляції, інцидент не перетворився на довготривале полювання на відьом. Перемкнули Ceph‑трафік з флапаючого порту, замінили трансивер — і тайм‑аути зникли. Постмортем був нудний. Це комплімент.
Типові помилки: симптом → корінна причина → виправлення
1) Симптом: «timeout waiting for lock …» по багатьох VM
Корінна причина: одна зависла задача утримує лок; часто ця задача блокується на I/O сховища або pmxcfs.
Виправлення: Визначте власника лока за допомогою fuser, перевірте його стан (D‑state?), потім лагодьте сховище/pmxcfs. Не видаляйте локи як перший крок.
2) Симптом: тайм‑аути вимкнення VM, потім «qm stop» теж зависає
Корінна причина: QEMU заблоковано в ядрі (D‑state), зазвичай на disk flush/unmap або мертвому шляху сховища.
Виправлення: Перевірте ps на D‑state і dmesg на помилки блоку. Відновіть здоров’я сховища; перезавантажте вузол, якщо I/O ядра безнадійно завис.
3) Симптом: vzdump jobs тайм‑аутяться і залишають знімки/локи
Корінна причина: ціль бекапу повільна/недоступна (часто NFS), або комміт знімка повільний (Ceph slow ops / ZFS латентність).
Виправлення: Перевірте відгукливість mount з stat і здоров’я бекенду. Зменшіть паралельність, переплануйте і контролюйте бекап‑сховище як production.
4) Симптом: «timeout waiting for RBD unmap» під час stop/delete
Корінна причина: Ceph slow ops, завислий клієнтський I/O або мережні проблеми між вузлом і Ceph.
Виправлення: Перевірте ceph -s і ceph health detail. Якщо є slow ops — лікуйте Ceph спочатку. Розгляньте тимчасову паузу руйнівних операцій.
5) Симптом: операції, що торкаються /etc/pve, зависають або помиляться
Корінна причина: pmxcfs заблокований через нестабільність corosync, голод CPU або завислий вузол.
Виправлення: Перевірте кворум (pvecm status), журнали corosync, завантаження CPU/пам’яті і стабілізуйте мережу кластера.
6) Симптом: міграції тайм‑аутяться, але сховище здається ОК
Корінна причина: мережна перевантаженість/несумісність MTU для міграції або латентність сховища на віддаленому вузлі.
Виправлення: Перевірте мережеве здоров’я; запускайте міграції за менших навантажень; перевірте I/O‑wait обох вузлів. Міграція — це дві машини і мережа, а не просто галочка.
Контрольні списки / покроковий план
Покроково: визначити, що насправді вичерпало тайм‑аут
- Отримайте UPID з перегляду задач Proxmox.
- Прочитайте файл задачі в
/var/log/pve/tasks/, щоб ідентифікувати точну команду і фазу, що застопорилася. - Визначте PID‑робітника, що тримає лок (якщо є) через
fuserна файлі лока або зіставлення команд процесів. - Перевірте стан процесу через
ps:- Якщо
D: не марнуйте час на сигнали; це I/O або блокування ядра. - Якщо
S/R: можливо чекає іншого процесу, мережі або лока.
- Якщо
- Перевірте журнали ядра (
dmesg -T) на тайм‑аути/скиди сховища в тому ж часовому інтервалі. - Перевірте здоров’я бекенду:
- ZFS:
zpool status,zpool iostat - Ceph:
ceph -s,ceph health detail - iSCSI:
iscsiadm -m session,multipath -ll - NFS:
statна точках монтування
- ZFS:
- Вирішіть дію відновлення:
- Якщо сховище падає: евакуюйте/мігруйте де можливо; зупиніть хоровод операцій; лагодьте бекенд; перезавантаження вузла, якщо ядро зависло.
- Якщо pmxcfs/kворум: стабілізуйте corosync і кластерні комунікації спочатку.
- Якщо гість не вимикається, але хост здоровий: ескалація stop/kill з розумінням ризику для даних.
Чек‑лист: «Чи має сенс перезавантажити цей вузол?»
- Чи є процеси в D‑state, пов’язані з критичними задачами?
- Чи журнали ядра показують повторювані I/O‑тайм‑аути або події «пристрій офлайн»?
- Чи бекенд сховища вже відновився, але вузол усе одно завис?
- Чи можна спочатку мігрувати/евакуювати VMs (shared storage, HA або планове вікно)?
Якщо на перші два питання відповідь «так» і ви не можете усунути умову — контрольоване перезавантаження часто найменше зло. Найгірше — дозволити вузлу гнити в напівмертвому стані, поки задачі накопичуються й локи множаться.
Факти та контекст: чому існують ці тайм‑аути
- Факт 1: Proxmox відстежує задачі за UPID, щоб асинхронні операції логулись і аудитились незалежно від сесії GUI.
- Факт 2: pmxcfs — це FUSE‑базована кластерна файлова система; ця зручність означає, що звичайні файлові операції можуть блокуватися на стані кластера.
- Факт 3: Linux D‑state (непереривний сон) існує, щоб захищати цілісність ядра і I/O; саме тому деякі «kill» не працюють.
- Факт 4: Шляхи вимкнення QEMU часто включають semantics flush для сховища; «shutdown timeout» може бути тим самим disk flush‑тайм‑аутом під маскою.
- Факт 5: Ceph «slow ops» — це не просто метрика продуктивності; вони можуть прямо блокувати клієнтські операції, як‑от RBD unmap/snapshot/remove.
- Факт 6: Поведінка multipath
queue_if_no_pathпризначена для збереження порядку I/O при відмовах шляхів, але може заморозити гіпервізор під тривалими відмовами. - Факт 7: NFS «hard» монти за замовчуванням повторюють спроби вічно; це добре для коректності даних і погано для інтерактивного управління, коли сервер зник.
- Факт 8: Робочі процеси з великою кількістю знімків перемикають навантаження з чистої пропускної здатності на метадані й латентність; тайм‑аути часто корелюють з хвостовою латентністю, а не з середньою пропускною здатністю.
- Факт 9: Тайм‑аути локів часто з’являються після початкового інциденту; вони зазвичай вторинні наслідки ранніх затримок.
Питання й відповіді (FAQ)
1) Що зазвичай означає «timeout waiting for lock» у Proxmox?
Це означає, що задача Proxmox не змогла отримати лок (конфігурація VM, сховище або кластерна конфігурація) протягом дозволеного часу. Реальна причина зазвичай — попередня задача, що утримує лок, і вона часто блокується на I/O сховища або pmxcfs.
2) Якщо вимкнення VM тайм‑аутиться, чи варто просто збільшити тайм‑аут?
Тільки якщо хост здоровий і гість просто повільно вимикається. Якщо QEMU в D‑state або вузол у великому I/O‑wait — збільшення тайм‑ауту лише змусить вас довше чекати на те, що не може завершитися.
3) Як відрізнити проблему гостя від проблеми хоста/сховища?
Перевірте стан процесу QEMU. Якщо він у D‑state з io_schedule або блокується в fsync — це хост/сховище. Якщо процес працює нормально і лише ігнорує ACPI‑вимкнення — швидше за все, це поведінка гостя.
4) Чому локи накопичуються після однієї поганої задачі?
Бо Proxmox серіалізує багато життєвих операцій, щоб уникнути корупції. Одна зависла операція тримає лок; наступні операції тайм‑аутяться в очікуванні. Накопичення локів — це дим, а не вогонь.
5) Який найшвидший індикатор того, що Ceph — проблема?
ceph -s з повідомленням про slow ops, деградовані PGs або активний backfill/recovery під навантаженням. Якщо є slow ops — вважайте, що операції Proxmox зачекають, поки Ceph не стабілізується.
6) Чи можна безпечно видаляти файли лока в /var/lock/pve-manager?
Іноді можна, але це крайній захід. Спочатку ідентифікуйте PID‑власника. Якщо власник — легітимна задача, видалення лока може створити одночасні конфліктні операції. Якщо власник зник і ви впевнені, що ніяких активних операцій сховища немає — видалення застарілого лока може бути прийнятним — задокументуйте ваші дії.
7) Чому доступ до /etc/pve зависає, коли кластер має проблеми?
Бо /etc/pve — це pmxcfs (FUSE). Файлові операції можуть залежати від кластерної координації і обміну повідомленнями. Якщо corosync нестабільний або вузол перевантажений, звичайні читання/записи в цьому дереві можуть блокуватися.
8) У якій послідовності розбиратися: логи Proxmox чи журнали ядра?
Почніть із логу задачі, щоб визначити, що саме робив Proxmox, а потім негайно перевірте журнали ядра на помилки I/O у тому ж проміжку часу. Журнали ядра зазвичай відповідають на питання чому операція застопорилася.
9) Чому тайм‑аути частіше відбуваються під час бекапів?
Бекапи сильно навантажують I/O, знімки і метадані. Вони підсилюють як пропускну здатність, так і хвостову латентність. Навіть якщо сховище «в порядку» під нормальним навантаженням, бекапи можуть штовхнути його в повільну зону, де цикли очікування Proxmox доходять до межі тайм‑ауту.
Наступні кроки, які варто виконати цього тижня
Якщо ви хочете менше несподіваних тайм‑аутів і коротші інциденти, зробіть ці практичні кроки:
- Навчіть команду починати з UPID і читати
/var/log/pve/tasks/. Зробіть це звичкою. - Додайте моніторинг D‑state і I/O‑wait на кожен вузол. Якщо ваш моніторинг не може сповістити про сплески D‑state — це не моніторинг, а скрапбукінг.
- Зніміть базовий профіль вашого бекенду під час бекапів і міграцій. Фіксуйте iostat‑латентність, Ceph slow ops, ZFS iostat — що б ви не використовували.
- Визначте політику відмов для multipath/NFS (fail‑fast vs hang). За замовчуванням — це не стратегія.
- Проведіть один game day: навмисно наситіть бекап‑сховище або симулюйте флап шляху у контрольований період і відпрацюйте ідентифікацію «що насправді вичерпало тайм‑аут» за менш ніж десять хвилин.
Тайм‑аути Proxmox здаються загадковими, бо це шар управління, що чекає на нижчі шари. Як тільки ви послідовно простежите очікування до процесу, далі до системної виклики, а потім до бекенду — повідомлення перестане бути містичним. Воно стане крихтою шляху.