Proxmox «VM заблоковано (резервне копіювання/знімок)»: як безпечно зняти блокування

Що насправді означає блокування (і що не означає)

Блокування VM у Proxmox — це механізм координації. Це невеликий фрагмент метаданих, який каже: «Деяка операція виконується і не повинна перекриватися з іншими операціями». Зазвичай цим «чимось» є одне з наступного:

• backup (vzdump, PBS або інтеграція від третьої сторони)
• snapshot (qemu snapshot і/або знімок на сховищі)
• clone (часто на базі знімка)
• migration (live або offline)
• replication (завдання реплікації Proxmox)

Повідомлення зазвичай з’являється, коли ви намагаєтеся:

• запустити/зупинити/перезавантажити VM (іноді дозволено, часто блокується залежно від операції)
• видалити VM
• видалити диск
• зробити ще один знімок
• перемістити сховище

Основне правило: знімайте блокування лише коли доведете, що нічого не виконується

Застаріле блокування дратує. Передчасне зняття блокування може дорого обійтися. Якщо резервне копіювання активно передає стан диска, а ви знімаєте блокування і видаляєте знімок під ним, ви отримуєте «резервну копію», яка не є ані послідовною, ані чесною. Відновлення дасть «VM-подібну» таємницю.

Блокування також можуть бути «істинними», навіть якщо в GUI нічого не виглядає активним. Можливо, процес-воркер Proxmox помер, вузол перезавантажився під час роботи, сховище завагіталося, або завдання зависло в невідривному очікуванні ядра. UI не бреше; він просто не завжди каже, чому.

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

Жарт #1: Блокування Proxmox — це як табличка «Не турбувати» на дверях готелю — тільки візок прибирання тут ваш масив сховища, і він важить кілька тонн.

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

Це цикл «перестаньте гадати». Мета: швидко вирішити, чи слід вам чекати, скасувати чи розблокувати.

Перше: підтвердіть тип блокування і знайдіть завдання, що його встановило

1. Визначте VMID і тип блокування з помилки (backup/snapshot/migrate/clone/replicate).
2. Перегляньте недавні завдання на вузлі та в кластері.
3. Шукайте запущений vzdump, pvescheduler, pveproxy, pvestatd або pve-storage worker, пов’язаний з цим VMID.

Друге: доведіть, чи робота ще виконується

1. Перевірте ввід/вивід на сховищі, що підтримує VM (ZFS zpool iostat, Ceph rbd status, NFS mount stats).
2. Перевірте процес QEMU і чи він заблокований (ps, top і ознаки стану ядра «D state»).
3. Перевірте прогрес артефактів знімка/резервної копії (інгест чанків PBS, тимчасові файли vzdump, наявність знімка ZFS).

Третє: оберіть найбезпечніший шлях вирішення

• Якщо завдання ще прогресує: чекайте. Якщо це критично, перемістіть людську проблему (вікно змін), а не проблему диска.
• Якщо завдання зависло, але його можна скасувати: зупиніть роботу акуратно (вбийте правильний worker, скасуйте завдання, видаліть застарілий PID).
• Якщо все мертве і лишилося лише блокування: розблокуйте, а потім негайно перевірте диски VM і стан знімків.

Якщо ви вагаєтеся між «розблокувати» і «нічого не робити», оберіть «нічого не робити», поки не отримаєте доказів. Блокування — дешеві; відновлення даних — ні.

Цікаві факти та історія, що пояснюють поведінку сьогодні

• Факт 1: Конфігурація VM у Proxmox — це простий текст, що зберігається під /etc/pve/ на розподіленій файловій системі (pmxcfs). Це робить блокування простими для представлення як рядок у файлі конфігурації.
• Факт 2: pmxcfs — це кластерна файлова система, підкріплена Corosync; вона призначена для невеликих конфіг/станів, а не для об’ємних даних. Коли вона неспокійна, запис конфігів (включно з оновленнями блокувань) може затримуватися або падати.
• Факт 3: Блокування «backup» зазвичай встановлюється vzdump (класичний) або воркерами, пов’язаними з резервними копіями; воно має на меті запобігти перекриванню операцій знімків/резервного копіювання, які порушать узгодженість.
• Факт 4: Знімки в Proxmox можуть бути «внутрішніми QEMU», «знімками сховища» або змішаними — залежно від типу сховища і налаштувань. Саме тому очищення блокування без очищення стану сховища може залишити вас із знімком, який неможливо видалити.
• Факт 5: Гостьовий агент «freeze/thaw» використовується для покращення узгодженості файлової системи, але якщо агент відсутній або завис, оркестрація знімка може зупинитися в несподіваних місцях.
• Факт 6: Операції знімків QEMU залежать від QMP (QEMU Machine Protocol). Якщо QEMU завис або QMP перестає відповідати, Proxmox не може завершити workflow знімка, і блокування може залишитися.
• Факт 7: «Зависше резервне копіювання» часто не є проблемою самого резервного копіювання. Це проблема вводу/виводу. Повільний або несправний диск може зробити вигляд, що знімок нічого не робить. Насправді він рухається крижаними темпами.
• Факт 8: На CoW-сховищах (ZFS, Ceph) створення знімків дешеве, але інколи їх видалення дороге — особливо якщо після знімка змінилося багато блоків.
• Факт 9: Proxmox історично підтримує кілька бекендів сховища з різною семантикою (LVM-thin, ZFS, RBD, NFS). Блокування — це уніфікуюча абстракція над цією неоднорідністю.

Де Proxmox зберігає блокування і чому вони зависають

Блокування — зазвичай рядок у конфігу VM

У більшості випадків блокування записане у файлі конфігурації VM під управлінням pmxcfs, наприклад:

• /etc/pve/qemu-server/101.conf для VMID 101
• /etc/pve/lxc/202.conf для контейнера 202 (контейнери теж мають блокування)

Зазвичай ви побачите щось на кшталт:

• lock: backup
• lock: snapshot
• lock: migrate

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

Чому застаріле блокування безпечніше за оптимістичну систему

Proxmox обирає консервативний режим відмови: якщо в ньому немає впевненості, він блокує. Це дратує людей, але не дозволяє вам виконувати руйнівні операції, поки можливий мердж/коміт знімка в процесі.

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

Що насправді означає «безпечне розблокування»

Безпечне розблокування — це не «запустити qm unlock і забути». Безпечне розблокування — це:

1. Знайти завдання, яке встановило блокування.
2. Підтвердити, що воно більше не працює (або застрягло за межами відновлення).
3. Підтвердити, що шар сховища не посеред транзакції (коміт знімка, відправлення реплікації, RBD flatten тощо).
4. Видалити блокування.
5. Перевірити, що VM запускається і операції зі знімками знову коректні.

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

Усі приклади припускають VMID 101 на вузлі pve1. Підлаштуйте під своє середовище. Команди навмисно нудні; нудне — це як ви зберігаєте дані.

Завдання 1: Підтвердьте блокування та його тип

cr0x@server:~$ qm config 101 | grep -E '^lock:|^name:|^scsi|^virtio'
name: app-prod-01
lock: backup
scsi0: local-zfs:vm-101-disk-0,size=120G

Що це означає: Proxmox вважає, що для VM 101 активний або незавершений workflow backup.

Рішення: Не розблоковуйте поки що. Знайдіть завдання резервного копіювання і перевірте його стан.

Завдання 2: Знайдіть недавні завдання, що посилаються на VMID

cr0x@server:~$ pvesh get /nodes/pve1/tasks --limit 20 --output-format json-pretty | grep -n "101"
42:     "id": "UPID:pve1:0000A1B2:0123ABCD:676D7B22:vzdump:101:root@pam:",

Що це означає: Для VM 101 було завдання vzdump.

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

Завдання 3: Прочитайте лог завдання (найшвидша правда в Proxmox)

cr0x@server:~$ pvesh get /nodes/pve1/tasks/UPID:pve1:0000A1B2:0123ABCD:676D7B22:vzdump:101:root@pam:/log
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
INFO: creating Proxmox backup snapshot
INFO: status = running

Що це означає: Завдання каже «running» і не зафіксувало завершення. Це може бути реально активне завдання або зависле.

Рішення: Перевірте, чи процес існує і чи прогресує він.

Завдання 4: Перевірте, чи працює worker vzdump

cr0x@server:~$ ps aux | egrep 'vzdump|pvescheduler|pve-backup' | grep -v grep
root      41233  0.5  0.2  24572  9120 ?        Ss   01:12   0:03 vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Що це означає: Процес vzdump живий.

Рішення: Не розблоковуйте. Наступне: визначте, чи він прогресує, або завис.

Завдання 5: Слідкуйте за тимчасовими файлами резервної копії (класична поведінка vzdump)

cr0x@server:~$ ls -lh /var/lib/vz/dump | tail -n 5
-rw-r--r-- 1 root root  88G Dec 26 01:18 vzdump-qemu-101-2025_12_26-01_12_04.vma.zst.tmp

Що це означає: Є тимчасовий файл. Якщо його розмір зростає з часом — резервне копіювання прогресує.

Рішення: Виміряйте розмір двічі (або використайте watch). Якщо зростання триває — чекайте. Якщо зависло — перевіряйте сховище та стан процесу.

Завдання 6: Перевірте, чи тимчасовий файл ще росте

cr0x@server:~$ stat -c '%n %s %y' /var/lib/vz/dump/vzdump-qemu-101-2025_12_26-01_12_04.vma.zst.tmp
/var/lib/vz/dump/vzdump-qemu-101-2025_12_12_04.vma.zst.tmp 95182411264 2025-12-26 01:18:27.000000000 +0000

Що це означає: Це одна точка часу. Запустіть ще раз через 30–60 секунд.

Рішення: Якщо розмір і mtime не змінюються — вважайте завдання можливим завислим і переходьте до перевірок сховища.

Завдання 7: Перевірте стан процесу VM і відповідь QEMU

cr0x@server:~$ qm status 101
status: running

Що це означає: VM продовжує працювати; резервні копіювання в режимі знімка часто тримають VM увімкненою під час знімкування.

Рішення: Якщо резервне копіювання зависло, не перезавантажуйте VM «щоб виправити». Так ви перетворите зависле резервне копіювання на зависле резервне копіювання + завислу VM.

Завдання 8: Шукайте стан ядра «D state» у потоках backup або QEMU

cr0x@server:~$ ps -eo pid,stat,cmd | egrep 'vzdump 101|kvm -id 101' | head
41233 D    vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
20987 Sl   /usr/bin/kvm -id 101 -name app-prod-01 ...

Що це означає: Процес vzdump у стані D (невідривний сон), зазвичай чекає на I/O (NFS, диск, ZFS, Ceph тощо). Вбити його може не вийти, поки не повернеться I/O.

Рішення: Не починайте з kill -9. Спочатку знайдіть вузьке місце вводу/виводу.

Завдання 9: Визначте, на якому сховищі знаходиться диск VM

cr0x@server:~$ qm config 101 | grep -E '^(scsi|virtio|sata)[0-9]+:'
scsi0: local-zfs:vm-101-disk-0,size=120G

Що це означає: Диск на ZFS-сховищі local-zfs. Семантика створення/видалення знімків залежить від ZFS.

Рішення: Перед розблокуванням перевірте стан пулу ZFS і наявність знімків.

Завдання 10: Перевірте стан пулу ZFS (швидкий тест на корупцію)

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

Що це означає: ZFS не повідомляє про відомі помилки.

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

Завдання 11: Перевірте I/O та затримку ZFS

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
rpool       1.10T  700G     12    340   2.1M  110M
  mirror    1.10T  700G     12    340   2.1M  110M
    sda         -      -      6    170   1.0M   55M
    sdb         -      -      6    170   1.1M   55M

Що це означає: Записи відбуваються; резервне копіювання може прогресувати (коміт знімка, активність zvol тощо). Це не гарантує, що це саме резервне копіювання, але свідчить проти «нічого не відбувається».

Рішення: Якщо бачите стабільний I/O і немає помилок, краще чекати, ніж примусово втручатися.

Завдання 12: Перевірте, чи існують метадані знімка Proxmox

cr0x@server:~$ qm listsnapshot 101
`-> pre-backup-2025-12-26 2025-12-26 01:12:10

Що це означає: Існує знімок. Резервні копіювання в режимі знімка часто створюють знімок і пізніше видаляють/комітують його.

Рішення: Якщо резервне копіювання зависло і знімок лишається — доведеться обережно обробляти очистку знімків після зупинки роботи.

Завдання 13: Знайдіть блокування у файлі конфігу VM (не редагуйте поки що, лише спостерігайте)

cr0x@server:~$ grep -n '^lock:' /etc/pve/qemu-server/101.conf
7:lock: backup

Що це означає: Блокування записане в конфігу.

Рішення: Віддавайте перевагу qm unlock 101 над ручними правками файлу. Ручні правки — це для випадків, коли pmxcfs зламаний або ви в режимі інциденту з планом змін.

Завдання 14: Скасуйте запущене завдання акуратно (коли це безпечно і необхідно)

Якщо робота дійсно зависла й бізнес вимагає дії, ви можете зупинити завдання. Спочатку спробуйте м’яке завершення.

cr0x@server:~$ kill -TERM 41233
cr0x@server:~$ sleep 2
cr0x@server:~$ ps -p 41233 -o pid,stat,cmd
  PID STAT CMD
41233 D    vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Що це означає: Процес все ще в стані D; він не може обробляти сигнали, бо заблокований на I/O.

Рішення: Не ескалюйте відразу до kill -9 як плану дій. Усуньте проблему I/O (NFS впав, шлях до сховища флапає, Ceph завис тощо) або прийміть очікування.

Завдання 15: Коли завдання зникне, видаліть блокування підтримуваним способом

cr0x@server:~$ qm unlock 101

Що це означає: Рядок блокування має бути видалений з конфігу, якщо внутрішні обмеження не блокують це.

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

Завдання 16: Підтвердіть, що блокування знято і операції VM працюють знову

cr0x@server:~$ qm config 101 | grep '^lock:' || echo "no lock set"
no lock set

Що це означає: Proxmox більше не блокує операції на основі цього блокування.

Рішення: Перевірте список знімків, виконайте невелику операцію (наприклад, qm status, qm agent ping, якщо доступно), і заплануйте нове резервне копіювання найближчим часом.

Особливості сховища (ZFS, LVM-thin, Ceph RBD, NFS)

ZFS: «Створення знімка було миттєвим; видалення триває вічно»

ZFS-знімки — це посилання в метаданих. Їхнє створення зазвичай миттєве. Видалення може вимагати звільнення великої кількості блоків, особливо якщо VM багато писала після знімка. То «зависле резервне копіювання» може бути на етапі очищення знімка.

Що робити: підтвердіть I/O, підтвердіть наявність знімка, і розблокуйте лише після того, як зупините job і переконаєтесь, що жодна операція zfs send/receive або snapshot destroy не виконується.

LVM-thin: мерджі та виснаження метаданих

LVM-thin знімки і мерджі — інша історія. Якщо thin pool має мало метаданих, мерджі можуть повзти або падати. Ви можете отримати блокування, яке здається не пов’язаним із реальною проблемою.

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

Ceph RBD: блокування — не єдині блокування

У Ceph є свої watch/lock концепції, плюс операції RBD snapshot і flatten. Proxmox може блокуватися через повільний Ceph або через те, що операція RBD очікує на кластер.

Що робити: перевірте стан RBD і слідкуйте за завислими операціями. Розблокування Proxmox не скасовує операцій Ceph.

NFS як ціль для бекапів: ваш бекап живий настільки, наскільки живий ваш маунт

Поширений сценарій відмови: NFS-глюк. Процес vzdump переходить у стан D, Proxmox тримає блокування, і GUI показує «running» назавжди. Вузол може виглядати нормально. Насправді — ні.

Що робити: ставтесь до NFS-маунту як до залежності. Перевірте статистику маунта, шукайте таймаути сервера, і будьте готові вирішувати проблему шляху до сховища, а не «чинити Proxmox».

Три корпоративні міні-історії з «траншеї» блокувань

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

Команда мала приємну віру: «Якщо GUI Proxmox не показує запущене завдання, нічого не працює». Це було не необґрунтовано — поки вони не потрапили на вузол з періодичною затримкою pmxcfs під час напруженого ранку.

VM була заблокована «(snapshot)». Інженер на чергуванні перевірив список завдань у GUI, не побачив нічого очевидного і виконав qm unlock. VM запустилася, і це здавалося перемогою. Потім вони видалили знімок, який «мав бути старим».

Що насправді відбувалося: на шарі сховища ще тривав коміт знімка. Вид управління не відображав цього коректно, бо worker, що ініціював операцію, помер, а кластерна файлова система повільно оновлювала стан завдання. Видалення пересіклося з комітом, і диск VM опинився з неконсистентними метаданими знімків у Proxmox та напівзавершеним станом на сховищі.

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

Тривале виправлення було культурним: runbook поміняли з «розблоковувати, якщо GUI тихий» на «розблоковувати тільки після доведення, що worker пішов і сховище не серед операції». Також ввели звичку перевіряти завдання через CLI і перевіряти списки знімків перед будь-якими руйнівними діями.

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

Платформна команда хотіла швидші бекапи. Вони перейшли від stop-mode до snapshot-mode майже скрізь, увімкнули стиснення і запустили всі job одночасно «щоб встигнути до робочих годин». На папері було красиво: менше даунтайму, швидші бекапи, задоволені люди.

Насправді snapshot-mode просто змістив навантаження, а не усунув його. Вікно бекапів тепер навалювало навантаження на сховище і мережу одночасно. У найгірші ранки затримки Ceph підскакували, гостьові агенти підмерзали в кількох VM, і кілька бекапів зависли на етапі очищення знімків.

До 9 ранку кілька VM були заблоковані. Рефлекс був — розблокувати, щоб команди могли деплоїти. Це «вирішення» спрацювало — поки система бекапів не почала повідомляти про непридатні архіви через порушені ланцюжки знімків.

Проблема була не в snapshot-mode сам по собі. Проблема була в конкуренції. Вони трактували бекапи як обчислювальні завдання, тоді як це були завдання сховища. Після того як рознесли графік, обмежили паралелізм на бекенд сховища та встановили таймаути/нешлі для «блокування старше X», інциденти з блокуваннями майже зникли.

Міні-історія 3: Нудна, але правильна практика, яка врятувала день

Середовище, пов’язане з фінансами, мало одну чесноту: дисципліну. Кожна зміна вимагала тікета. Кожен тікет — передперевірки. І кожна передперевірка — верифікація бекапів і стану знімків.

Одного дня VM показала «locked (backup)». Інженер на чергуванні не розблокував її. Він відкрив лог завдання, побачив завислий у D state backup і ескалував у службу сховища. Сховище виявило, що NFS-сервер робив оновлення ядра з оптимістичним планом перезавантаження.

Коли NFS відновився, vzdump завершився, блокування знялося автоматично, і знімок зник як очікувалось. Розблокування вручну не знадобилося. Вікно змін змістилося, люди пішли незадоволені, але дані VM залишилися цілими.

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

Контрольні списки / покрокові плани

План A: Безпечний дефолт (у більшості випадків)

1. Ідентифікуйте блокування: qm config <vmid> | grep '^lock:'
2. Знайдіть завдання: опитайтеся отримати недавні завдання на вузлі; знайдіть UPID для vzdump/snapshot/migrate/replicate.
3. Прочитайте лог завдання: якщо воно все ще логує і прогресує — чекайте.
4. Перевірте стан процесу: підтвердіть, чи існує worker-процес; перевірте на D state.
5. Перевірте здоров’я сховища: відповідні перевірки для ZFS/Ceph/LVM/NFS.
6. Якщо прогресує: чекайте і сповіщайте зацікавлених.
7. Якщо зависло через залежність: ремонтуйте залежність (мережа/сховище), а не блокування.
8. Якщо завдання мертве і сховище стабільне: розблокуйте з qm unlock.
9. Після розблокування: перевірте знімки; запустіть VM; проведіть невелику валідацію I/O; заплануйте нове резервне копіювання.

План B: Потрібне втручання (зависле завдання, вплив на бізнес)

1. Переконайтеся, що VM не посеред міграції/реплікації. Якщо так — зупиніться і переосмисліть план дій.
2. Переконайтеся, що жоден процес резервного копіювання не записує вихід (зростання тимчасового файлу, пропускна здатність сховища).
3. Спробуйте м’яко скасувати/термінувати worker-процес або завдання (не kill -9 спочатку).
4. Якщо процес у стані D: ремонтуйте шлях I/O. Вбивати не допоможе, поки системний виклик не повернеться.
5. Після того, як worker зник і сховище стабільне — розблокуйте командою qm unlock <vmid>.
6. Очистіть артефакти знімків (видаляйте залишкові знімки лише після впевненості, що жоден merge/commit не виконується).
7. Документуйте інцидент. Ви забудете деталі швидше, ніж думаєте.

План C: pmxcfs або стан кластера зламаний (рідко, гостро)

1. Переконайтеся в кворумі кластера і здоров’ї pmxcfs на вузлі.
2. Уникайте редагувати /etc/pve/ вручну, якщо не розумієте ефекту на кластер.
3. Відновіть здоров’я кластера спочатку. Якщо стан конфігу не може бути записаний, команди розблокування можуть «успішно» спрацювати номінально, але не в реальності.
4. Коли pmxcfs стане стабільним — повторіть нормальний workflow.

Жарт #2: «Просто розблокуй» — це віртуалізаційний еквівалент «просто перезавантаж prod» — іноді правильно, часто шкідливо для кар’єри.

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

1) «Блокування не зникає, але бекап виглядає завершеним»

Симптом: архів vzdump існує; GUI все ще показує блокування (backup).

Корінна причина: завдання впало під час очищення або пост-бекап кроків; рядок блокування не видалився через падіння worker або помилку запису pmxcfs.

Виправлення: переконайтеся, що жодне завдання не працює; підтвердіть, що список знімків чистий; виконайте qm unlock; потім перевірте бекапи через тест відновлення (не лише «файл існує»).

2) «Я розблокував, тепер знімки не видаляються»

Симптом: видалення знімка не вдається або зависає; Proxmox показує неконсистентне дерево знімків.

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

Виправлення: повторно перевірте операції на сховищі; для ZFS — перелічіть знімки і оцініть, чи destroy в процесі; для Ceph — перевірте стан RBD/операцій; лише потім видаляйте або узгоджуйте знімки.

3) «Завдання бекапу працює вічно і не вбивається»

Симптом: процес у стані D; сигнали не діють.

Корінна причина: блокований I/O (NFS-сервер недоступний, проблеми з шляхом до диска, завислий Ceph або ядро чекає на сховище).

Виправлення: виправте залежність I/O. Якщо NFS — відновіть з’єднання або перемонтуйте після стабілізації; якщо Ceph — виправте стан кластера; якщо локальні диски — перевірте апаратні помилки та dmesg. Потім дочекайтеся повернення системного виклику і завершення процесу.

4) «VM заблокована (snapshot) після freeze guest-agent»

Симптом: операція знімка почата; VM залишається заблокованою; гість виглядає замороженим.

Корінна причина: гостьовий агент QEMU не відповів на thaw, або freeze таймаутнувся посеред workflow.

Виправлення: перевірте статус агента всередині VM і на Proxmox; розгляньте відключення freeze для цього робочого навантаження або виправлення служби агента; розблокуйте лише після впевненості, що жоден merge/commit знімка не виконується.

5) «Блокування трапляються щовечора в один і той же час»

Симптом: повторювані інциденти блокувань під час вікна бекапів.

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

Виправлення: рознесіть jobs у часі, встановіть реалістичні ліміти пропускної здатності, зменшіть паралельні бекапи на вузол/сховище і додайте сповіщення для завдань, що перевищують очікуваний час виконання.

6) «qm unlock працює, але GUI все ще показує блокування»

Симптом: CLI повідомляє успіх; UI все ще блокує операції.

Корінна причина: затримка поширення pmxcfs/стану кластера або кешування GUI; іноді ви розблокували на неавторитетному вузлі під час проблем кластера.

Виправлення: перевірте файл конфігу на кластерній файловій системі, підтвердіть кворум і повторну перевірку з вузла, що хостить VM. Якщо кластер хворий — спочатку лікуйте це.

FAQ (реальні запитання опів на третю)

1) Чи завжди безпечно запускати qm unlock <vmid>?

Ні. Це безпечно, коли блокування застаріле: жодного worker-а не працює, жодна операція сховища не триває і ви перевірили стан знімків/резервних копій. Інакше — це рулетка з красивим брендингом.

2) У чому різниця між «locked (backup)» та «locked (snapshot)»?

«backup» зазвичай означає workflow резервного копіювання (часто на основі знімків). «snapshot» звичайно означає, що активна саме операція знімка (create/delete/rollback). Обидва варіанти можуть задіювати знімки на рівні сховища.

3) Чи можна просто видалити рядок lock: з /etc/pve/qemu-server/<vmid>.conf?

Можна, але не слід, якщо тільки це не вимушено. Використовуйте qm unlock, щоб Proxmox зробив внутрішню роботу коректно. Ручні правки — для випадків, коли сервіс керування зламаний і у вас є план інциденту.

4) Завдання показує «running», але процесу немає. Що робити?

Припустіть, що worker помер. Переконайтеся, що немає активності на сховищі і перевірте списки знімків. Якщо воно справді мертве і стабільне — розблокуйте і потім акуратно приберіть знімки.

5) Чому блокування резервного копіювання блокує перезавантаження або вимкнення?

Бо резервні копіювання в режимі знімка залежать від узгодженого стану диска, і перезавантаження/вимкнення може перервати створення/коміт знімка. Proxmox блокує операцію, щоб зберегти узгодженість сховища.

6) Як дізнатися, чи резервне копіювання «робить прогрес»?

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

7) Якщо я розблокую, чи скасує це резервне копіювання/знімок?

Ні. Розблокування лише прибирає захисну обгортку Proxmox. Підлеглий процес (якщо ще працює) буде продовжувати свою роботу, і операції на сховищі можуть тривати. Ось чому раннє розблокування небезпечне.

8) Що робити після розблокування застарілого блокування?

Перевірте список знімків (qm listsnapshot), переконайтеся, що VM стартує, перевірте здоров’я сховища і заплануйте нове резервне копіювання найближчим часом. Також розберіться, чому завдання зависло, щоб уникнути повторення.

9) Чи може проблема кворуму кластера спричиняти застряглі блокування?

Так. Якщо pmxcfs не може закомітити оновлення конфігу через проблеми з кворумом або файловою системою, завдання можуть некоректно не фіксувати завершення. Відновіть здоров’я кластера спочатку; інакше ви боретесь з привидами.

10) Яка найшвидша «перевірка здорового глузду», якщо я збираюся робити щось ризиковане?

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

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

Коли Proxmox каже «VM заблоковано (резервне копіювання/знімок)», ставтеся до цього як до запобіжного блокування, а не як до незручності. Ваше завдання — не очистити повідомлення; ваше завдання — зберегти узгодженість стану.

Зробіть це далі, по порядку:

1. Операціоналізуйте швидкий план діагностики: лог завдання → стан процесу → стан сховища.
2. Уніфікуйте правила «коли дозволено розблокувати»: немає працюючого worker-а, немає поточних операцій сховища, список знімків зрозумілий.
3. Зменшіть повторюваність: рознесіть бекапи, обмежте паралелізм по бекендах сховища і сповіщайте про завдання, що перевищують очікуваний час.
4. Тренуйте відновлення: реальний критерій успішності резервного копіювання — тест відновлення, а не просто файл на диску.

Цитата, що тримає вас чесним — парафраз ідеї Річарда Кука (інженерія стійкості): Успіх і невдача часто походять від тієї ж повсякденної роботи; надійність — це те, як ви керуєте цією роботою.