Proxmox «cannot get exclusive lock»: хто тримає блокування VM і як його зняти

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

Proxmox VE (PVE) — це багатопроцесна система, яка оркеструє найменш гламурним способом: файлові блокування і послідовні завдання. Це добре. Воно запобігає одночасному втручанню двох операцій в одну конфігурацію VM або диск.

Коли ви бачите «cannot get exclusive lock», PVE каже: «Я намагався взяти блокування для цієї VM, але хтось інший його вже має». Тим «кимось» може бути:

• законне довготривале завдання (резервне копіювання, снапшот, реплікація, міграція)
• зависле завдання, яке не звільнило блокування (перезапуск демона, збій ноди, зависле сховище)
• HA-менеджер або компонент кластера, що координує доступ
• блокування на рівні сховища (Ceph RBD lock, LVM activation lock, NFS file lock)
• запущений процес QEMU, який все ще володіє станом VM навіть якщо UI виглядає неконсистентним

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

Сухий факт: блокування — це попереджувальна наклейка. Зняття її не робить вміст безпечним.

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

1. Блокування на рівні PVE (типово в стані конфігурації VM). Вони блокують дії в qm, UI і API.
2. Блокування на рівні сховища (Ceph RBD, ZFS «dataset busy», LVM activation, NFS stale locks). Вони можуть блокувати QEMU, снапшоти або бекапи навіть якщо PVE виглядає «розблокованим».

Швидкий план діагностики

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

Перше: чи є активне завдання PVE для VM?

• Перевірте історію завдань для ID VM і шукайте «running» завдання.
• Підтвердіть, чи активний backup, snapshot, migrate або replication job.
• Якщо так: ще не розблоковуйте; вирішіть, чекати, скасувати чи вбити воркер-процес.

Друге: чи QEMU все ще працює (або напівпрацює)?

• Перевірте процес kvm/qemu-system-x86_64 для цього VM ID.
• Перевірте, чи відповідає QMP, або чи процес застряг у стані uninterruptible I/O (D).
• Якщо QEMU живий: блокування часто коректне. Якщо QEMU застряг: зазвичай справжній винуватець — сховище.

Трете: чи блокує сховище?

• ZFS: перевірте zpool status, затримки I/O та завислі операції zfs destroy/snapshot.
• Ceph: перевірте стан кластера і RBD locks/watchers.
• NFS: шукайте stale file handles і заблоковані точки монтування.
• LVM: перевірте активацію LV і завислі команди lvchange/lvs.

Тоді: тільки тоді розгляньте зняття блокувань

Якщо немає активного завдання, QEMU не працює (або зник), і сховище не виконує операцію, то зняття застарілого блокування зазвичай безпечне.

Правило великого пальця: якщо є будь-яка можливість, що операція з диском триває, ставтеся до «розблокування» як до інциденту, а не до рішення.

Завдання та команди: знайти утримувача, довести причину, обрати виправлення

Нижче — практичні завдання, які можна виконати на вузлі PVE. Кожне містить: команду, що типовий вивід означає, та яке рішення слід прийняти.

Завдання 1: Ідентифікуйте точне повідомлення про блокування та операцію

cr0x@server:~$ qm start 101
cannot get exclusive lock on VM 101 (snapshot-delete)

Що це означає: блокування не є загальним; воно підказує, яка категорія операції його тримає (тут: snapshot-delete).

Рішення: шукайте завдання видалення снапшоту, а не просто «якесь випадкове блокування». Це також підказує про залучення сховища.

Завдання 2: Перевірте конфігурацію VM на наявність поля lock

cr0x@server:~$ grep -E '^(lock|parent|snapname):' /etc/pve/qemu-server/101.conf
lock: snapshot-delete

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

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

Завдання 3: Знайдіть останні завдання, що згадують VM ID у логах ноди

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "2 hours ago" | grep -E 'vmid=101|VM 101|101.conf' | tail -n 30
Dec 26 01:41:10 server pvedaemon[2143]: starting task UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:
Dec 26 01:41:11 server pvedaemon[2143]: INFO: backup job started
Dec 26 01:55:44 server pvedaemon[2143]: ERROR: backup failed: storage 'nfs-backup' not online
Dec 26 01:55:44 server pvedaemon[2143]: TASK ERROR: job failed

Що це означає: у вас була операція, яка завершилася помилкою. Залежно від того, де сталася помилка, блокування може лишитися.

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

Завдання 4: Перелічіть запущені завдання і відфільтруйте по VM

cr0x@server:~$ pvesh get /nodes/server/tasks --running 1 | grep -E 'vzdump|qm|vmid.?101' || true
UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:

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

Рішення: інспектуйте той UPID і вирішіть, чекати, скасувати чи вбити воркер.

Завдання 5: Перевірте статус завдання (чи воно справді живе)

cr0x@server:~$ pvesh get /nodes/server/tasks/UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:/status
{"exitstatus":null,"id":"UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:","node":"server","pid":10783,"starttime":1735177270,"status":"running","type":"vzdump","upid":"UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:","user":"root@pam"}

Що це означає: PVE вважає, що PID 10783 ще працює і тому блокування вважається валідним.

Рішення: підтвердіть, що PID існує і не застряг у I/O wait назавжди.

Завдання 6: Переконайтеся, що PID завдання існує і подивіться, що він робить

cr0x@server:~$ ps -o pid,ppid,stat,etime,cmd -p 10783
  PID  PPID STAT     ELAPSED CMD
10783  2143 D+     00:14:28 /usr/bin/vzdump 101 --storage nfs-backup --mode snapshot

Що це означає: стан D означає uninterruptible sleep, зазвичай заблокований на I/O. Вбити його може не вийти, поки I/O не відновиться.

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

Завдання 7: Перевірте, чи QEMU все ще працює для цієї VM

cr0x@server:~$ pgrep -a -f "qemu-system-x86_64.*-id 101"
24591 /usr/bin/kvm -id 101 -name vm101,debug-threads=on -m 8192 ...

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

Рішення: не робіть qm unlock як перший крок. Визначте, чи VM здорова і яка дія заблокована.

Завдання 8: Запитайте Proxmox, який він вважає статус VM

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

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

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

Завдання 9: Перегляньте дерево снапшотів і знайдіть застряглий снапшот

cr0x@server:~$ qm listsnapshot 101
`-> current
   `-> pre-upgrade-2024-12-01
   `-> vzdump

Що це означає: імена снапшотів важливі. Снапшоти «vzdump» часто лишаються після збоїв бекапів.

Рішення: якщо присутній снапшот «vzdump» і бекапи падають, спочатку виправте storage для бекапів, потім видаліть снапшот коректно.

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

cr0x@server:~$ pvesh create /nodes/server/tasks/UPID:server:00002A1F:00014B77:676D1A46:vzdump:101:root@pam:/stop
{"data":null}

Що це означає: ви запросили зупинку. Воно все ще може зависнути, якщо процес у стані D.

Рішення: якщо воно зупиниться швидко — чудово. Якщо ні — налагодження сховища обов’язкове. Уникайте escalation до SIGKILL без розуміння, на чому воно застрягло.

Завдання 11: Коли немає запущеного завдання, безпечно розблокуйте на рівні PVE

cr0x@server:~$ qm unlock 101

Що це означає: це видаляє запис lock: з конфігурації VM. Це не вирішує блокувань на рівні сховища або завислих процесів QEMU.

Рішення: робіть це тільки після підтвердження відсутності активної операції. Після розблокування повторіть заблоковану дію та спостерігайте логи.

Завдання 12: Перевірте доступність сховища в PVE (нудна перевірка «а воно взагалі змонтовано?»)

cr0x@server:~$ pvesm status
Name         Type     Status     Total     Used     Available
local        dir      active    98.00GB   12.40GB     85.60GB
nfs-backup   nfs      inactive       0B        0B          0B
rbd-ceph     rbd      active     3.00TB    1.90TB      1.10TB

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

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

Завдання 13: Специфічно для NFS: перевірте здоров’я монтування і ризик “stale file handle”

cr0x@server:~$ mount | grep nfs-backup
10.0.20.15:/export/pve-backup on /mnt/pve/nfs-backup type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

cr0x@server:~$ timeout 3 ls -la /mnt/pve/nfs-backup | head
ls: cannot access '/mnt/pve/nfs-backup': Stale file handle

Що це означає: «hard» NFS-монтування зі stale handle може зависати процеси у стані D. Сюди потрапляють vzdump і очищення снапшотів.

Рішення: усуньте стан NFS (перезапуск сервера/export, ремоунт). Не просто вбивайте завдання і надійтеся. Воно знову застрягне.

Завдання 14: Специфічно для Ceph: швидко перевірте стан кластера

cr0x@server:~$ ceph -s
  cluster:
    id:     0f3c6f1a-9f72-4a1f-9e35-7b4c9b2a1c0a
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 34 sec
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    mgr: active: mgr1
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   4 pools, 256 pgs
    usage:   1.9 TiB used, 1.1 TiB / 3.0 TiB avail
    pgs:     256 active+clean

Що це означає: «slow ops» корелює з завислими снапшотами/міграціями і таймаутами блокувань, бо завершення I/O затримується.

Рішення: вирішіть проблему повільності Ceph (мережа, OSD, backfill, recovery) перед тим, як маніпулювати блокуваннями. Інакше ви просто пришвидшите цикл помилок.

Завдання 15: Ceph RBD lock/watchers: подивіться, хто приєднаний

cr0x@server:~$ rbd status vm-101-disk-0 --pool rbd
Watchers:
    watcher=10.0.10.21:0/1689456502 client.48231 cookie=18446744073709551615

Що це означає: якийсь клієнт (ймовірно PVE-нода) все ще має диск відкритим. Снапшоти або ексклюзивні операції можуть блокуватися.

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

Завдання 16: ZFS-специфічно: підтвердіть стан пулу і шукайте довготривалі операції

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

cr0x@server:~$ zfs list -t snapshot | grep -E '^rpool/data/vm-101-disk-0@' | tail -n 5
rpool/data/vm-101-disk-0@vzdump                         2.10G  -  58.3G  -

Що це означає: пул здоровий; снапшот існує. Якщо видалення застрягло, зазвичай причина — hold, залежність clone або I/O-століття в іншому місці.

Рішення: перевірте наявність клонів/hold перед примусовими діями.

Завдання 17: ZFS holds: знайдіть причину, чому снапшот не видаляється

cr0x@server:~$ zfs holds rpool/data/vm-101-disk-0@vzdump
NAME                               TAG                 TIMESTAMP
rpool/data/vm-101-disk-0@vzdump     pve-vzdump          Thu Dec 26 01:41 2025

Що це означає: є явний hold. Proxmox (або скрипт) поставив його, щоб запобігти випадковому видаленню під час бекапу.

Рішення: знімайте hold лише якщо backup-завдання підтверджено мертвим і снапшот безпечний для видалення.

Завдання 18: Зняти ZFS hold (хірургічно, не випадково)

cr0x@server:~$ zfs release pve-vzdump rpool/data/vm-101-disk-0@vzdump

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

Рішення: негайно запустіть видалення через Proxmox ще раз (бажано), щоб стан PVE залишився консистентним.

Завдання 19: Перевірте, хто блокує /var/lock на рівні ОС (рідко, але буває)

cr0x@server:~$ ls -la /var/lock/qemu-server/
total 0
-rw-r----- 1 root root 0 Dec 26 01:41 lock-101.conf

cr0x@server:~$ lsof /var/lock/qemu-server/lock-101.conf || true
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pvedaemon 2143 root    8u   REG  0,53        0  512 /var/lock/qemu-server/lock-101.conf

Що це означає: демон сам володіє дескриптором файлу. Таке трапляється під час легітимних операцій — або коли демон завис.

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

Завдання 20: Перезапустити керуючі демони (останній засіб, але іноді правильний)

cr0x@server:~$ systemctl restart pvedaemon pveproxy pvestatd

Що це означає: ви перезапустили контрольну площину. Це може очистити застарілі блокування та облікові записи завдань. Це не розблокує заблокований kernel I/O.

Рішення: робіть це коли: (1) ви підтвердили, що QEMU і сховище в порядку, (2) завдання — фантоми, і (3) стан HA/кластера стабільний. Інакше ви просто перезавантажуєте панель керування під час пожежі в двигуні.

Жарт №1: Розблокувати VM, не перевіривши сховище, — як відключити сигналізацію диму, бо вона гучна. Шум припиниться; проблема залишиться.

Типи блокувань у Proxmox: що зазвичай означає кожен

Рядок із причиною блокування (частина в дужках) — ваш підказувач. Розглядайте його як стартову гіпотезу, а не як вирок.

backup / vzdump

Зазвичай означає: виконується резервне копіювання або воно аварійно завершилося посеред процесу, часто лишаючи снапшот (особливо на ZFS/Ceph).

Поширені первинні причини: ціль бекапу офлайн, NFS stale handle, PBS datastore недоступний, повільне сховище.

Що робити: перевірте завдання, потім стан цілі бекапу, а потім снапшоти.

snapshot / snapshot-delete

Зазвичай означає: створення/видалення снапшоту в процесі або попередня спроба померла після встановлення стану.

Поширені первинні причини: ZFS holds, Ceph slow ops, RBD watchers все ще приєднані, очікувані I/O.

Що робити: перевірте список снапшотів, стан бекенда сховища та наявність hold/watchers.

clone

Зазвичай означає: виконується клонування з шаблону або воно частково завершилось.

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

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

migrate

Зазвичай означає: виконується міграція або вона не завершилася і не очистила стан.

Поширені первинні причини: цільова нода недоступна, перебої SSH, проблеми зі спільним сховищем, втручання HA.

Що робити: знайдіть UPID міграції, перевірте обидві ноди щодо VM і підтвердіть, що диски не активні одночасно на обох сторонах.

rollback

Зазвичай означає: відкат до снапшоту в процесі, що є по суті ексклюзивною операцією.

Поширені первинні причини: відкат почався і VM була вимкнена примусово, сховище відчуло труднощі, або відкат завершився з помилкою і лишив стан.

Що робити: ставтеся до цього як до високого ризику. Підтвердіть консистентність дисків і не розблокуйте легковажно.

Несправності залежно від сховища (ZFS, Ceph, LVM, NFS, iSCSI)

Більшість звернень «cannot get exclusive lock» — це насправді звернення зі сховища у віртуалізаційній одежі.

ZFS: «dataset busy», holds і приховані залежності

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

• holds, встановлених інструментами бекапу (щоб не видалити посеред бекапу)
• clones, що залежать від снапшоту
• busy datasets через монтування або процеси, що тримають посилання
• польова напруга пулу (латентність, відмови пристроїв), що робить операції безкінечними

Чого слід уникати: вручну знищувати снапшоти в обхід Proxmox, поки він все ще вважає операцію активною. Краще використовувати qm delsnapshot після очищення блокуючого фактора; це зберігає консистентність метаданих Proxmox.

Ceph RBD: watchers, ексклюзивні замки і «slow ops»

Ceph має власну концепцію клієнтів, що відкрили RBD-образ. Навіть якщо PVE зніме конфігураційне блокування, образ може бути все ще відкритий QEMU десь.

Якщо нода впала, ви можете отримати «фантомні приєднання»: кластер все ще вважає, що клієнт тримає образ. Ви побачите watchers, і ваші дії з видалення/снапшоту застрягнуть або впадуть.

Під час інцидентів Ceph помилка блокування часто є першим видимим симптомом глибшої проблеми: recovery/backfill, що насичує диски, втрата пакетів мережі або нестабільні OSD. Виправлення здоров’я Ceph часто — найшвидший «розблокувальний» крок.

LVM-thin: activation locks і завислий lvchange

LVM-thin надійний, поки не закінчиться метаданих або VG не буде зайнято у способі, якого ви не очікували. Якщо lvs зависає, ви в тій самій категорії, що і проблеми з «hard» NFS-монтуваннями: процеси заблоковані в kernel I/O, а не це ввічливі userland-помилки.

NFS: hard mounts, stale handles і чому kill -9 не допоміг

NFS — чудовий вибір для бекапів. Він також — майстер-клас у компромісах розподілених систем. З hard монтуванням процеси чекатимуть вічно на відповідь сервера. Це «надійність» в одному сенсі і «мій кластер приклеївся до мертвого експорту» в іншому.

Коли NFS повертає Stale file handle, зазвичай це подія на боці сервера (перезавантаження, failover, ремонтування, зміни експорту). Процеси на клієнті можуть заблокуватися. Блокування лишаються «утриманими», бо завдання ніколи не завершуються.

iSCSI / multipath: втрата шляху і QEMU у D-state

Проблеми з шляхами блочного сховища люблять проявлятися як проблеми з блокуваннями, бо QEMU може заблокуватися на I/O. Потім plane управління блокується, чекаючи на QEMU або завершення операції зі сховищем. Якщо бачите QEMU у стані D, думайте про multipath або SAN перед тим, як звинувачувати «баг Proxmox».

Жарт №2: Збої сховищ щедрі — вони ділять свій біль зі всіма верхніми шарами без додаткової плати.

Три реальні міні-історії (як це йде не за планом)

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

Команда мала невеликий кластер із загальним Ceph RBD. Нода перезавантажилася під час вікна техобслуговування, і після цього VM не мігрувала. UI показував «cannot get exclusive lock», тож on-call припустив, що Proxmox просто перебережний, і виконав qm unlock.

Міграція все одно провалилася. Тепер конфігурація стала редагованою, тож вони «вирішили» проблему від’єднавши й знову приєднавши диск у конфігурації VM. Це створило чисто виглядаючу конфігурацію, яка виявилася несинхронною з реальністю: старий RBD-образ усе ще мав watcher, а нові спроби приєднати давали помилки.

Вони витратили дві години на «повторні спроби» й перезапуски демонів, бо всім подобається ритуал, коли причина незрозуміла. Справжня причина була видима за кілька хвилин: Ceph мав slow ops і RBD-образ все ще мав watcher від ноди, що перезавантажилася.

Що змінило результат — не якийсь хитрий командний прийом. Це було рішення припинити трактувати блокування як проблему і почати трактувати його як доказ. Коли Ceph відновився і залишкове приєднання було вирішено, помилка блокування зникла сама по собі.

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

Інша компанія захотіла швидших бекапів. Хтось налаштував NFS-монтування для високої пропускної здатності і встановив великі розміри r/w та агресивні параметри. Воно було швидким. У хороші дні.

Потім NFS-сервер мав короткий failover. Монтування було hard, що можна виправдати, але вони не врахували оперативну реальність: backup-процеси потрапили в uninterruptible sleep, чекаючи I/O. Ці завдання тримали VM-блокування, очищення снапшотів застопорилося, і наступного дня бекапи стикнулися з наслідками попереднього дня.

До середини ранку кілька VMs були «заблоковані», і команді сховища задавали питання, чому віртуалізація не може «просто розблокувати». Вони могли розблокувати. Вони також могли погіршити ситуацію, дозволивши новим снапшотам накопичуватися на вершині вже зламаного ланцюжка.

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

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

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

Однієї ночі видалення снапшоту застрягло після втрати зв’язку ноди з ціллю бекапу. On-call побачив помилку блокування і виконав чекліст. Завдання показало running vzdump з PID у стані D. Стан сховища показав NFS-монтаж неактивним.

Вони зробили найменш захопливу річ: відновили NFS-експорт, перемонтували чисто, чекали, поки зависле завдання вийде, потім заново виконали видалення снапшоту через Proxmox. Жодна команда розблокування не була потрібна. VM не опинилася під додатковим ризиком.

Це було настільки нудно, що майже не відчувалося як успіх. Ось у чому суть. Їхня практика запобігла каскаду: жодних примусових розблокувань, жодних редагувань конфігурації, жодних напівзавершених снапшотів, жодного наступного квитка «чому ланцюг бекапів зламався».

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

1) «Cannot get exclusive lock (backup)» і ви одразу виконуєте qm unlock

Симптом: бекапи падають, VM заблокована, і накопичуються снапшоти з іменем «vzdump».

Причина: ціль бекапу офлайн або зависла (NFS/PBS), що лишає vzdump-завдання застряглими або зруйнованими під час снапшоту.

Виправлення: відновіть з’єднання з бекап-ціллю; підтвердіть відсутність запущених завдань; очистіть снапшоти через Proxmox; лише потім розблокуйте, якщо воно застаріле.

2) Блокування залишається після перезавантаження ноди

Симптом: VM показує блокування, хоча «нічого не працює».

Причина: застаріле поле lock: в /etc/pve/qemu-server/*.conf від перерваної операції.

Виправлення: підтвердіть відсутність завдань і процесу QEMU; тоді qm unlock <vmid>.

3) Вбити PID завдання не очищає блокування

Симптом: ви надсилаєте SIGTERM/SIGKILL; процес лишається; блокування лишається.

Причина: процес у uninterruptible I/O (D) через NFS/SAN/Ceph stall; ядро не вб’є його, поки I/O не повернеться.

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

4) Блокування міграції, яке «не зникає»

Симптом: VM заблокована з (migrate), але міграція провалилася години тому.

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

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

5) Видалення снапшоту постійно не вдається на ZFS

Симптом: блокування показує snapshot-delete; видалення не вдається; снапшот лишається.

Причина: ZFS hold або залежність clone заважає видаленню.

Виправлення: перевірки zfs holds і zfs get origin; знімайте holds лише коли безпечно; видаляйте через Proxmox після цього.

6) Помилки Ceph RBD під час stop/start

Симптом: зупинка зависає; потім з’являються помилки «exclusive lock» при операціях.

Причина: Ceph slow ops або залишкові watchers; QEMU все ще приєднаний або кластер Ceph деградований.

Виправлення: стабілізуйте Ceph (ceph -s); підтвердіть watchers; переконайтеся, що QEMU зупинено коректно; потім продовжуйте.

7) Перезапуск pvedaemon «вирішує» проблему раз, а потім вона повертається

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

Причина: основна проблема зі сховищем залишається; скидання control-plane маскує симптоми.

Виправлення: припиніть використовувати перезапуски як лікування; інструментуйте здоров’я сховища; спочатку виправте mount/cluster.

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

Чекліст A: «VM заблокована і не стартує»

1. Зафіксуйте точний рядок помилки (тип операції).
2. Перевірте конфігураційне блокування: grep '^lock:' /etc/pve/qemu-server/<vmid>.conf.
3. Перевірте запущені завдання для VM: pvesh get /nodes/<node>/tasks --running 1.
4. Якщо завдання працює: інспектуйте його PID і стан (ps); якщо D, переходьте до сховища.
5. Перевірте, чи QEMU вже запущений: pgrep -a -f "-id <vmid>".
6. Перевірте статус сховища в PVE: pvesm status.
7. Перевірте стан бекенда (ZFS/Ceph/NFS) в залежності від місця зберігання дисків/бекапів.
8. Лише якщо немає завдань, немає QEMU і сховище стабільне: qm unlock <vmid> і повторіть спробу запуску.

Чекліст B: «Блокування видалення снапшоту»

1. Перелічіть снапшоти: qm listsnapshot <vmid> і визначте ціль.
2. Перевірте наявність поточних бекап-завдань: running vzdump часто лишає snapshot-delete locks.
3. ZFS: перевірте holds: zfs holds <dataset>@<snap>.
4. Ceph: перевірте watchers: rbd status <image> --pool <pool>.
5. Виправте бекенд-блокер (holds/watchers/slow ops).
6. Видаліть снапшот через Proxmox ще раз (бажано): qm delsnapshot <vmid> <snapname>.
7. Якщо Proxmox все ще показує застаріле блокування і нічого не активне: qm unlock <vmid>.

Чекліст C: «Блокування бекапу»

1. Підтвердіть, що ціль бекапу доступна і активна: pvesm status.
2. NFS: перевірте, що монтаж чуйний: timeout 3 ls /mnt/pve/<storage>.
3. PBS: перевірте доступність datastore (з погляду PVE) і автентифікацію.
4. Інспектуйте статус задачі vzdump і стан PID.
5. Вирішіть проблему зі сховищем, дайте завданню завершитися/вийти коректно або зупиніть його, якщо воно може зупинитися.
6. Очистіть залишкові снапшоти «vzdump», якщо вони є.
7. Запустіть один ручний бекап для перевірки перед повторним включенням розкладів.

Чекліст D: «Коли безпечно використовувати qm unlock»

• Немає жодного запущеного завдання, що посилається на VM ID.
• Немає процесу QEMU для цього VM ID.
• Сховище бекенду здорове і відповідає.
• Жодна операція зі снапшотом на рівні бекенду не виконується.
• Ви розумієте, яка операція встановила блокування, і приймаєте наслідки розблокування.

Цікаві факти та історичний контекст

• Proxmox VE виріс із прагматичної культури Linux-операцій: файлові конфіги і просте блокування свідомо використовуються, бо їх можна інспектувати під тиском.
• /etc/pve — це не звичайний файловий система: це кластерна файлова система (pmxcfs). «Блокування в конфігу» — це спільний стан кластера, а не просто локальний текст.
• Блокування стали першочерговою проблемою з ростом кластерів: рання однонодова віртуалізація могла «відрощувати крила»; кластерна оркестрація — ні.
• Семантика снапшотів залежить від бекенду: ZFS снапшоти поводяться інакше, ніж Ceph RBD снапшоти, і Proxmox мусить узгоджувати обидва в одному UI.
• Hard NFS-монтування — це свідомий компроміс: вони запобігають тихій корупції даних ціною «все зависає, коли сервер зникає».
• Ceph watchers дають видимість: вони показують, які клієнти мають образ відкритим, і часто пояснюють помилки ексклюзивного блокування без здогадок.
• Uninterruptible sleep (D-state) — це функція Linux, а не баг: це ядро відмовляється вбивати процеси, що чекають на критичні I/O-шляхи.
• HA додає ще один шар блокувань: у HA-настройках VM може «триматися» рішенням менеджера, навіть якщо люди хочуть втрутитися.

Операційна цитата (перефразована думка): «Надія — не стратегія», часто цитують в SRE-кругах як прагматичне мислення надійності. Ставтеся до помилок блокувань так само: перевірте, а потім дійте.

FAQ

1) Що означає «cannot get exclusive lock» у Proxmox?

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

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

Безпечно, коли блокування застаріле: немає запущених завдань, немає процесу QEMU і бекенд-сховище здорове. Небезпечно, коли backup/snapshot/migration справді в процесі або застрягли в I/O — розблокування може дозволити конфліктні операції.

3) Чому в повідомленні блокування згадується «snapshot-delete», коли я просто намагаюся запустити VM?

Тому що VM заблокована на операцію видалення снапшоту, яка очікує або застрягла, і Proxmox блокує інші дії, щоб уникнути неконсистентного стану. Ваш запит на «start» є побічною жертвою.

4) Я вбив процес бекапу, але блокування лишається. Чому?

Або процес фактично не помер (часте у стані D), або Proxmox записав блокування в конфіг і воно не було очищене. Підтвердіть списки завдань і стан процесу; тоді розблокуйте тільки після перевірки, що сховище не працює.

5) Який найшвидший спосіб знайти, хто тримає блокування?

Перевірте (a) запущені завдання через pvesh, (б) journalctl за останні завдання, що торкалися VM, і (в) чи запущений QEMU. Потім перевірте індикатори бекенду: Ceph watchers, ZFS holds, реактивність NFS-монтувань.

6) Чи може HA спричинити проблему з ексклюзивним блокуванням?

Так. Ресурси, які управляє HA, можуть стартуватись/зупинятись/мігруватись HA-менеджером, і збої можуть лишити «операції в процесі». Завжди перевіряйте стан HA і де VM повинна бути запущена перед ручним втручанням.

7) Чому проблеми NFS проявляються як блокування VM?

Бо backup/snapshot-завдання залежать від читання/запису в NFS. З hard-монтуванням ці процеси можуть блокуватися в ядрі назавжди. Proxmox тримає блокування, бо завдання ніколи не виходить.

8) UI не показує запущених завдань, але блокування лишається. Що робити?

Подивіться прямо в конфігурацію VM на наявність lock:, перевірте логи на попередні збої. Потім перевірте ОС-рівневі lock-файли і стан демонів. Якщо все справді просто просто просто просто idle, розблокування є розумним кроком.

9) Якщо Ceph у стані HEALTH_WARN, чи слід розблоковувати, щоб все пришвидшити?

Зазвичай ні. HEALTH_WARN зі slow ops часто означає, що I/O затримується; розблокування не змусить операції завершитися. Стабілізуйте Ceph спершу, інакше ви обміняєте одне зависле завдання на купу напівзавершених.

10) Чи можна вручну видаляти рядок lock: з 101.conf?

Уникайте цього, якщо ви не в режимі відновлення і не розумієте наслідків для pmxcfs. Краще використовувати qm unlock, що є підтримуваним шляхом і зберігає очікування інструментів.

Висновок: практичні наступні кроки

Коли Proxmox каже «cannot get exclusive lock», не сперечайтеся з ним. Допитуйтеся. Причина блокування підказує, яку підсистему варто дослідити, а найшвидші перемоги приходять від підтвердження, чи завдання ще живе і чи сховище дійсно відповідає.

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

1. Прийміть порядок швидкої діагностики: tasks → QEMU → storage → unlock.
2. Додайте одне операційне правило: ніяких qm unlock, поки не перевірено стан задач і здоров’я сховища.
3. Для блокувань, пов’язаних з бекапами, ставтеся до цілі бекапу як до продакшн-залежності. Моніторьте її як таку.
4. Для Ceph/ZFS вивчіть їхні нативні індикатори (watchers, holds). Вони часто дають справжнє пояснення.
5. Напишіть власний внутрішній runbook із іменами сховищ, пулами та шаблонами відмов — бо наступне блокування станеться, коли ви втомлені.