Proxmox «failed to start pve-ha-lrm»: чому HA не запускається і що перевірити

Той червоний рядок статусу — failed to start pve-ha-lrm — з’являється саме тоді, коли вам потрібно, щоб HA поводився як HA. Вузол перезавантажується, шлях до сховища підгальмовує або хтось «покращив» комутатор із блокнотом у руках — і раптом Local Resource Manager (LRM) не стартує. Кластер досить живий, щоб насміхатися з вас, але недостатньо здоровий, щоб виконати фейловер.

Це не ситуація «перезапустіть сервіс». pve-ha-lrm — це симптом. Причина майже завжди в одному з наступного: файловій системі кластера не подобається щось, проблеми з corosync/кворумом, дивні збої часу або резолюції імен, налаштування fencing/watchdog або граничні ситуації зі сховищем, щодо яких HA відмовляється робити припущення.

Що насправді робить pve-ha-lrm (і чому він відмовляється запускатися)

Proxmox HA розділений на дві основні ролі:

• pve-ha-manager: мозок кластера, що вирішує, де повинні працювати ресурси (VM/CT).
• pve-ha-lrm: локальний шар виконання на вузлі, який стартує/зупиняє/мігрує ресурси і відправляє статус назад.

LRM навмисно консервативний. Якщо він не може довіряти стану кластера, не може прочитати файлову систему кластера, не може надійно проспілкуватися з corosync або виявляє невідповідності у fencing/watchdog, він відмовиться працювати. Це не «капризність». Це спосіб уникнути split-brain подвійних стартів — HA версія підпалювання даних із супровідними паперами.

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

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

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

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

Перший: визначте, чи це проблема кластера/кворуму

1. Перевірте, чи corosync запущений і чи є кворум.
2. Перевірте, чи змонтований і записуваний pmxcfs.
3. Перевірте членство кластера та узгодженість імен вузлів.

Якщо кворум відсутній або pmxcfs пошкоджений, HA не має безпечної моделі світу. Виправте це, перш ніж торкатися HA-сервісів.

Другий: підтвердіть статус HA-сервісів і їхні негайні помилки

1. Перегляньте systemd-статус для pve-ha-lrm та pve-ha-manager.
2. Прочитайте журнали systemd навколо часу збою.
3. Перевірте, чи вузол не застряг у стані fenced/maintenance.

Третій: підтвердіть вимоги до сховища для HA-ресурсів

1. Спільне сховище доступне там, де очікується (або ви правильно використовуєте реплікацію).
2. Конфігурація сховища узгоджена між вузлами.
3. Старі блокування або помилки на рівні сховища не блокують дії старту.

Скорочена евристика: Якщо інтерфейс показує дивний статус кластера — ваша проблема не в HA. Якщо інтерфейс показує здоровий кластер, але HA не може управляти однією VM — проблема, ймовірно, в сховищі або конфігурації ресурсу.

Жорсткі вимоги, перш ніж HA взагалі захоче стартувати

1) Членство corosync і кворум мають бути в порядку

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

2) pmxcfs має бути змонтований і консистентний

pmxcfs — це кластерна файлова система Proxmox (FUSE), яка надає розподілену конфігурацію під /etc/pve. Якщо вона не змонтована, HA не зможе надійно читати стан і конфіг.

3) Ідентичність вузла має збігатися через усі шари

Невідповідності імен вузлів — між hostname, /etc/hosts, nodelist corosync і тим, що бачить Proxmox — спричиняють тонкі збої. HA-процеси не зацікавлені у вашій креативності з DNS-аліасами.

4) Час не повинен «провалюватися» в дивну зону

Corosync і розподілена координація поводяться погано, коли час стрибає. Проблеми з NTP/chrony можуть створювати симптоми, які виглядають як «випадкові» флапи членства. Спойлер: вони не випадкові.

5) Конфігурація fencing/watchdog має бути послідовною

HA без fencing — фактично «найкраща спроба». Proxmox може використовувати fencing на основі watchdog (і інтегруватися з зовнішніми підходами за потреби). Якщо LRM бачить невиконані вимоги до watchdog, він може відмовитися працювати або поводитися так, ніби виникли блокування.

Жарт #1: HA без кворуму — як комітет без протоколів: кожен пам’ятає різну реальність, і якось фінанси все одно перемагають.

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

Нижче — 14 практичних завдань, які ви можете виконати на вузлі з помилкою failed to start pve-ha-lrm. Кожне містить, що означає вивід і яке рішення ухвалити далі. Виконуйте їх спочатку на проблемному вузлі, потім як мінімум на одному здоровому для порівняння.

Завдання 1: Перевірте systemd-статус для pve-ha-lrm

cr0x@server:~$ systemctl status pve-ha-lrm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-lrm.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 09:11:02 UTC; 2min 3s ago
    Process: 2149 ExecStart=/usr/sbin/pve-ha-lrm (code=exited, status=1/FAILURE)
   Main PID: 2149 (code=exited, status=1/FAILURE)

Dec 26 09:11:02 server pve-ha-lrm[2149]: unable to read cluster config: /etc/pve/corosync.conf: No such file or directory
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Failed with result 'exit-code'.

Значення: Рядок помилки зазвичай підказує, яка підсистема зламана. Тут він скаржиться на /etc/pve, що кричить про те, що pmxcfs не змонтований або кластерна ФС недоступна.

Рішення: Якщо в помилках згадується /etc/pve, переходьте прямо до Завдань 4–6 (pmxcfs + corosync + кворум).

Завдання 2: Прочитати останні журнали для pve-ha-lrm

cr0x@server:~$ journalctl -u pve-ha-lrm -b --no-pager -n 120
Dec 26 09:10:59 server systemd[1]: Starting PVE Local Resource Manager Daemon...
Dec 26 09:11:02 server pve-ha-lrm[2149]: starting lrm service
Dec 26 09:11:02 server pve-ha-lrm[2149]: can't initialize HA stack - aborting
Dec 26 09:11:02 server pve-ha-lrm[2149]: cfs-lock 'file-ha_agent' error: no quorum
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Main process exited, code=exited, status=1/FAILURE
Dec 26 09:11:02 server systemd[1]: pve-ha-lrm.service: Failed with result 'exit-code'.

Значення: Класичний випадок: no quorum. HA відмовляється працювати, бо не може безпечно координуватися.

Рішення: Не намагайтеся «примусово» запускати HA-сервіси. Відновіть кворум: членство corosync, мережу, голоси або кількість вузлів. Перейдіть до Завдань 7 і 8.

Завдання 3: Підтвердіть статус pve-ha-manager (це важливо)

cr0x@server:~$ systemctl status pve-ha-manager --no-pager
● pve-ha-manager.service - PVE HA Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-manager.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:01:18 UTC; 12min ago
   Main PID: 1422 (pve-ha-manager)
      Tasks: 6 (limit: 154838)
     Memory: 33.4M
        CPU: 1.820s
     CGroup: /system.slice/pve-ha-manager.service
             └─1422 /usr/sbin/pve-ha-manager

Значення: Запущений manager не гарантує, що LRM може стартувати. Але якщо обидва впали, швидше за все це проблема більш глибоко на рівні кластеру/pmxcfs, а не локальна.

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

Завдання 4: Перевірте, чи змонтований pmxcfs

cr0x@server:~$ mount | grep -E 'pve|pmxcfs'
pve-cluster on /etc/pve type fuse.pve-cluster (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Значення: Якщо ви не бачите pve-cluster on /etc/pve, HA не працюватиме, бо конфіг/стан кластера недоступні.

Рішення: Якщо відсутній, перевірте pve-cluster і corosync (Завдання 5 і Завдання 7). Не запускайте HA, доки /etc/pve не змонтується.

Завдання 5: Перевірте сервіс pve-cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:00:32 UTC; 13min ago
   Main PID: 1120 (pmxcfs)
      Tasks: 12 (limit: 154838)
     Memory: 41.6M
        CPU: 4.122s
     CGroup: /system.slice/pve-cluster.service
             └─1120 /usr/bin/pmxcfs

Значення: Якщо pve-cluster не працює, /etc/pve не буде доступним.

Рішення: Якщо він падає, у логах часто буде «no quorum» або помилки підключення corosync. Виправте corosync/кворум спочатку; перезапуск pmxcfs без кворуму — це whack-a-mole.

Завдання 6: Перевірте, чи /etc/pve доступний для запису (індикатор кворуму)

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

Quorum information
------------------
Date:             Fri Dec 26 09:13:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.4c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Значення: Quorate: Yes — зелений сигнал. Якщо No, HA очікувано зупиниться.

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

Завдання 7: Проінспектуйте статус corosync

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:00:25 UTC; 13min ago
       Docs: man:corosync
   Main PID: 1011 (corosync)
      Tasks: 17 (limit: 154838)
     Memory: 30.1M
        CPU: 2.033s
     CGroup: /system.slice/corosync.service
             └─1011 /usr/sbin/corosync -f

Значення: Запущений corosync не гарантує стабільність членства. Потрібно перевірити вигляд кластера (Завдання 8) і логи (Завдання 9).

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

Завдання 8: Подивіться на членство corosync і стан лінків

cr0x@server:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status:
                nodeid:          1:  connected
                nodeid:          2:  connected
                nodeid:          3:  connected

Значення: «connected» серед пір — те, що вам потрібно. Якщо бачите «disconnected», «faulty» або відсутній вузол — це ваша проблема кворуму.

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

Завдання 9: Прочитайте логи corosync, щоб знайти справжню причину

cr0x@server:~$ journalctl -u corosync -b --no-pager -n 160
Dec 26 09:07:44 server corosync[1011]: [KNET  ] link: host: 2 link: 0 is down
Dec 26 09:07:45 server corosync[1011]: [TOTEM ] A new membership (1.4b) was formed. Members left: 2
Dec 26 09:07:45 server corosync[1011]: [QUORUM] Members[1]: 1
Dec 26 09:07:45 server corosync[1011]: [QUORUM] This node is within the non-quorate partition
Dec 26 09:07:49 server corosync[1011]: [KNET  ] link: host: 2 link: 0 is up

Значення: Події link down/up корелюють з втратою кворуму і тим, що HA відмовляється блокувати стан кластера.

Рішення: Розглядайте як мережеву/транспортну проблему. Шукайте зміни MTU, проблеми з VLAN, асиметричну маршрутизацію або баги офлоуду NIC під навантаженням. Якщо це відбувається під нагрузкою — підозрюйте мікропориви або політику комутатора, що «захищає» від мультикасту/UDP.

Завдання 10: Перевірте узгодженість імен вузлів і резолюцію

cr0x@server:~$ hostname -f
pve01.corp.local

cr0x@server:~$ grep -E '(^127\.0\.1\.1|10\.10\.10\.)' /etc/hosts
127.0.1.1 pve01.corp.local pve01
10.10.10.11 pve01.corp.local pve01
10.10.10.12 pve02.corp.local pve02
10.10.10.13 pve03.corp.local pve03

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

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

Завдання 11: Перегляньте статус HA і стани вузлів

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Wed Dec 26 09:13:55 2025)
lrm pve01 (active, Wed Dec 26 09:13:54 2025)
lrm pve02 (active, Wed Dec 26 09:13:51 2025)
lrm pve03 (idle, Wed Dec 26 09:12:10 2025)

service vm:101 (started)
service vm:102 (stopped)
service ct:201 (started)

Значення: Якщо на проблемному вузлі видно lrm ... (idle) або він відсутній — він не бере участі. Якщо master бовтається або відсутній — ваш HA-manager нестабільний.

Рішення: Якщо кворум OK, але LRM idle/відсутній — зосередьтеся на локальних проблемах вузла: systemd, watchdog, права, монтування pmxcfs або помилки агентів ресурсів.

Завдання 12: Перевірте пристрій watchdog (передумова fencing у багатьох налаштуваннях)

cr0x@server:~$ ls -l /dev/watchdog*
crw------- 1 root root 10, 130 Dec 26 09:00 /dev/watchdog
crw------- 1 root root 10, 129 Dec 26 09:00 /dev/watchdog0

cr0x@server:~$ systemctl status watchdog-mux --no-pager
● watchdog-mux.service - Proxmox VE watchdog multiplexer
     Loaded: loaded (/lib/systemd/system/watchdog-mux.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:00:28 UTC; 13min ago

Значення: Відсутні пристрої watchdog або мертвий multiplex можуть блокувати припущення fencing і змушувати HA бути консервативним (або поводитися як заблокований при відмовах).

Рішення: Якщо watchdog відсутній і ваша політика HA очікує fencing — виправте апарат/драйвер/BIOS-настройки watchdog перед тим, як довіряти HA.

Завдання 13: Перевірте помилки старту через сховище (видимість спільного сховища)

cr0x@server:~$ pvesm status
Name             Type     Status           Total        Used       Avail      %
local             dir     active        19688240     4680128    14073520  23.77%
shared-nfs         nfs     active      984320000   612480000   371840000  62.22%
ceph-vm            rbd     active      204800000    73216000   131584000  35.75%

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

Рішення: Якщо спільне сховище неактивне на проблемному вузлі — припиніть звинувачувати HA. Виправте монтування/аутентифікацію/мережевий шлях; потім повторіть дії HA.

Завдання 14: Пошук застряглих блокувань або заблокованих операцій файл.системи кластера

cr0x@server:~$ pveperf /etc/pve
CPU BOGOMIPS:      55866.40
REGEX/SECOND:      3966050
HD SIZE:           29.34 GB (local-lvm)
BUFFERED READS:    201.15 MB/sec
FSYNCS/SECOND:     1248.61
DNS EXT:           63.63 ms
DNS INT:           0.09 ms (pve01.corp.local)

Значення: pveperf проти /etc/pve — груба перевірка здоров’я. Якщо воно зависає або дає дивні помилки, ваша кластерна файлова система хвора (часто через нестабільний кворум або перевантаження вузла).

Рішення: Якщо pveperf /etc/pve зависає — розглядайте це як проблему комунікацій/кворуму або серйозного ресурсного тиску на вузлі. Виправте стабільність перед HA.

Режими відмов, що прямо відповідають «failed to start pve-ha-lrm»

1) Немає кворуму (найпоширеніше, найкоректніша поведінка)

HA потребує консенсусу. Без кворуму вона не може безпечно отримувати блокування в кластерній файловій системі. Ви побачите помилки типу:

• cfs-lock ... error: no quorum
• unable to read cluster config (бо pmxcfs у режимі read-only/без кворуму)

Напрям виправлення: відновіть членство. Поверніть відсутній вузол, виправте мережу corosync або налаштуйте очікування голосів. Якщо у вас двовузловий кластер — прочитайте розділ FAQ про те, чому це пастка без qdevice.

2) pmxcfs не змонтований або нездоровий

Якщо /etc/pve не змонтований, ви фактично не маєте кластерної конфігурації на цьому вузлі. HA впаде. Це може статися якщо:

• pve-cluster не зміг стартувати
• corosync не працює або не аутентифікований
• вузол завантажився у стані, де не може дістатися пір і тому не отримує кворум

Напрям виправлення: розглядайте це як «кластер не сформований». Вирішіть corosync і ідентичність, потім перезапустіть pve-cluster, потім HA.

3) Flapping лінків corosync (мережеві та MTU-провини)

Коли corosync нестабільний, HA виглядає «довільно зламаною». Це не випадково; вона реагує на зміни членства. Причини:

• MTU mismatch (особливо з VLAN, bond, jumbo frames)
• тимчасово додані правила файрволу
• switch storm control / multicast filtering / UDP policing
• проблеми NIC/драйвера офлоуду під навантаженням

Напрям виправлення: зробіть мережу corosync нудною: узгоджений MTU end-to-end, без фільтрації, з низькою втратою і передбачуваною затримкою.

4) Невідповідність імен вузлів або застаріла ідентичність кластера

Якщо імена вузлів змінилися (hostname змінено після створення кластера, DNS повертає інші імена або /etc/hosts відрізняється), членство кластера може формуватися, але вищі шари не зможуть узгодити ідентичності. HA може не змогти відобразити ресурси на вузли.

Напрям виправлення: стандартизуйте імена. Віддавайте перевагу стабільним hostname і статичним відповідникам для трафіку кластера. Якщо потрібно змінювати імена — робіть це як контрольовану міграцію з повною перевіркою corosync.

5) Передумови fencing/watchdog не задоволені

У HA fencing — це спосіб переконатися, що вузол дійсно помер перед тим, як стартувати його навантаження десь ще. Якщо пристрій watchdog відсутній або неправильно налаштований, деякі налаштування HA відмовляться працювати або будуть консервативними. Відмова може проявлятися як LRM, що відмовляється стартувати або швидко зупиняється.

Напрям виправлення: перевірте наявність пристрою watchdog, налаштування BIOS, Kernel-модулі і статус сервісу. Якщо ваша політика вимагає fencing — не відмовляйтеся від неї легковажно.

6) Збої агентів ресурсів, що виглядають як помилки LRM

Іноді pve-ha-lrm стартує нормально, але одразу повідомляє про помилки ресурсів, і оператор сприймає це як «LRM не стартує». Логи показують правду: дія старту/міграції VM провалюється через сховище, блокування або конфігурацію.

Напрям виправлення: відокремте «демон LRM не стартував» від «LRM не зміг виконати дії над ресурсами». Використовуйте ha-manager status та логи по VM.

Цитата (парафраз думки): Урок Пітера Друкера для надійності: «Ви не можете керувати тим, що не вимірюєте». В HA вимірюваннями, що мають значення, є членство і кворум.

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

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

Помилка 1: «Перезапустити HA-сервіси», коли кворум втрачено

Симптом: pve-ha-lrm падає з no quorum і ви постійно його перезапускаєте.

Корінь: Кластер не може безпечно блокувати стан; перезапуск не відновлює консенсус.

Виправлення: Відновіть членство corosync і кворум. Тільки потім перезапускайте HA (якщо вони не відновляться автоматично).

Помилка 2: Двовузловий кластер без вирішального голосу

Симптом: Перезавантаження одного вузла або дрібна проблема в мережі зводить HA нанівець; pve-ha-lrm відмовляється; Quorate: No.

Корінь: У двох вузлах втрата будь-якого з них знімає більшість, якщо не використовувати qdevice або третій голос.

Виправлення: Додайте qdevice (або третій вузол). Якщо не можете — прийміть, що «HA» умовне і операційно дороге.

Помилка 3: Зміна hostname/DNS після створення кластера

Симптом: Corosync працює, але вузли показують дивні ідентичності; HA не координує; LRM помилки посилаються на відсутніх вузлів.

Корінь: Ідентичність вузла — це не просто «що DNS каже сьогодні».

Виправлення: Тримайте стабільні hostname. Якщо перейменування обов’язкове — робіть контрольовану перебудову конфігурації з перевіркою кожного вузла.

Помилка 4: Мережа corosync та трафік сховища/VM на одному переповненому шляху

Симптом: HA відвалюється під час бекапів, міграцій або ребалансування сховища; членство флапає.

Корінь: Трафік corosync чутливий до втрат/затримок. Переповнення створює враження, що вузли падають.

Виправлення: Виділіть corosync на окрему, низьковтратну мережу (або хоча б захищений VLAN/QoS). Тримайте MTU узгодженим.

Помилка 5: «Оптимізація» MTU або bonding без тестування corosync

Симптом: Випадкова втрата кворуму після мережевих «поліпшень».

Корінь: MTU mismatch або зміни hash LACP спричиняють втрату/перепорядкування UDP-пакетів.

Виправлення: Перевірте MTU end-to-end реальними тестами і підтверджуйте стабільність corosync під навантаженням. Якщо не можете довести — не впроваджуйте.

Помилка 6: HA-ресурси налаштовані без гарантій спільного сховища

Симптом: HA відмовляється стартувати або одразу дає помилку при спробі старту VM на іншому вузлі.

Корінь: Диски VM живуть на локальному сховищі; failover не має доступу до даних.

Виправлення: Перенесіть диски на спільне сховище, використайте Ceph/RBD або реплікацію там, де це потрібно. «HA» не телепортує дані.

Жарт #2: Єдине, що страшніше за split-brain — це коли обидві його половини вважають себе «primary», бо ви так їх назвали.

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

Чекліст A: Безпечно повернути HA на одному вузлі

1. Підтвердіть стабільність corosync: у логах немає флапів членства при нормальному трафіку хоча б кілька хвилин.
2. Підтвердіть кворум: pvecm status показує Quorate: Yes.
3. Підтвердіть pmxcfs: mount | grep /etc/pve показує, що змонтовано на читання-запис.
4. Підтвердіть синхронізацію часу: chrony/ntp стабільні; немає великих зсувів.
5. Підтвердіть watchdog (якщо використовується): пристрої присутні і сервіс активний.
6. Запустіть стек HA (якщо ще не запущено): стартуйте manager, потім LRM, і спостерігайте логи.
7. Перевірте статус HA: ha-manager status показує LRM active.

Чекліст B: Коли слід зупинитись і оголосити інцидент

• Кворум флапає повторно і ви не можете зв’язати це з одним відомим відключенням вузла.
• /etc/pve періодично зникає або стає read-only.
• Логи corosync показують часті link up/down без явної фізичної причини.
• Вузли не погоджуються щодо членства або очікуваних голосів.
• Є ознаки корупції сховища або повторювані I/O-помилки на системному диску (pmxcfs також залежить від стану вузла).

Чекліст C: Чистий порядок перезапуску (тільки після стабілізації кворуму)

cr0x@server:~$ systemctl restart pve-ha-manager
cr0x@server:~$ systemctl restart pve-ha-lrm
cr0x@server:~$ systemctl status pve-ha-lrm --no-pager
● pve-ha-lrm.service - PVE Local Resource Manager Daemon
     Loaded: loaded (/lib/systemd/system/pve-ha-lrm.service; enabled)
     Active: active (running) since Fri 2025-12-26 09:20:05 UTC; 3s ago
   Main PID: 3011 (pve-ha-lrm)

Значення: Якщо тепер старт чистий — попередній збій майже напевне був через кворум/pmxcfs/ідентичність, а не «зламаний пакет HA».

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

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

Інцидент через неправильне припущення: «DNS в порядку; це тільки імена»

Середня компанія тримала Proxmox-кластер у регіональному офісі. Він не був фешенебельним, але запускав типову інфраструктуру. HA був увімкнений, бо хтось пообіцяв автоматичний фейловер.

В один понеділок вони мігрували внутрішній DNS на нові сервери. План був простий: реплікація зон, оновлення DHCP-опцій, виведення старих серверів. Ніяких змін у Proxmox не планувалося, бо в заявці на зміну було: «DNS не впливає на кластерний гіпервізор».

Після cutover HA почав поводитися моторошно. pve-ha-lrm падало на одному вузлі, потім на іншому. Corosync «бігав», але кворум хитався під час нормальної роботи. Справжній винуватець не був у аптаймі DNS — а в поведінці резольвера. Новий резолвер повертав різні відповіді для коротких імен проти FQDN, і один вузол мав застарілий запис у /etc/hosts. Членство corosync формувалося, але вищі рівні не узгоджували ідентичності. Кластер мав екзистенційну кризу.

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

Неправильне припущення було в тому, що імена — косметика. У кластерах імена — це ідентичність. Ідентичність — це безпека. Безпека — це координація. Координація визначає, чи VM стартує один раз чи двічі.

Оптимізація, що провалилася: «Давайте всюди jumbo frames»

Команда enterprise мала три вузли Proxmox з окремим VLAN для corosync. Вони хотіли швидших міграцій і менше навантаження CPU, тому ввели jumbo frames у всій віртуалізаційній мережі. Зміни були швидко затверджені — у них уже працювало в інших оточеннях.

Вони встановили MTU 9000 на NIC хостів і верхньо-стойкові комутатори. Сховище стало швидшим. Міграції пішли швидше. Усі святкували.

Потім HA почав відмовлятися стартувати на одному вузлі після перезавантажень. Помилка була переривчастою: іноді pve-ha-lrm стартував, іноді видавав коротке no quorum і залишався мертвим. Логи corosync показували лінк-флапи, зазвичай під час бекапів.

Оптимізація була неповною: один trunk у шляху corosync мав MTU 1500. При легкому трафіку фрагментація маскувала проблему. Під навантаженням пакети падали. Corosync тлумачила втрату як нестабільність вузла, кворум падали — і HA відмовлялася блокувати стан.

Виправлення не було героїчним: зробити MTU узгодженим скрізь і перевірити реальними пакетними тестами під тривалим трафіком. Після цього HA знову поводився пристойно.

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

Нудна, але правильна практика, що врятувала день: «Виділений corosync + передбачуване fencing»

Одна медична організація (та, що любить папери більше, ніж кисень) тримала Proxmox для непрофільних навантажень. SRE-лідер наполягав на двох правилах: (1) corosync на окремій фізичній мережі і (2) watchdog fencing налаштований і протестований раз на квартал. Команда бурчала, бо це здавалося процесом заради процесу.

Під час події з електропостачання один вузол повернувся у поганому стані: ОС була в порядку, але драйвер NIC завис і скидала пакети. Ззовні він здавався «живим» і бентежив людей. Якщо б не було fencing, кластер повільно би вмер у дебатах, чи «вузол справді мертвий».

Watchdog зробив свою роботу. Хворий вузол був гарантовано зафенсений, кворум стабілізувався, і HA запустив навантаження на інших вузлах. Користувачі побачили коротку паузу, а не день «інтермітентної повільності», що перетворюється на фестиваль звинувачень.

Після інциденту розбір був майже нудним. Рукбук відповідав реальності, домен відмови був ясний, а виправлення — конкретне: замінити NIC, оновити прошивку, повторно протестувати. Без містики. Без фольклору.

Нудні практики не гламурні. Вони також причина, чому ви можете спати.

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

• Факт 1: Конфігурація кластера Proxmox живе в pmxcfs, FUSE-базованій розподіленій файловій системі, змонтованій у /etc/pve, а не в «звичайних» локальних файлах.
• Факт 2: Сучасний транспорт corosync у Proxmox часто використовує knet, створений для роботи з мульти-лінками та кращою поведінкою мережі, ніж старі підходи.
• Факт 3: Концепція кворуму старша за сучасну віртуалізацію; вона походить із задач координації розподілених систем, де більшість запобігає split-brain.
• Факт 4: HA-стеки часто розділяють «вирішувати» і «виконувати» (manager vs local agent). Proxmox слідує цій схемі з manager та LRM для безпеки й ясності.
• Факт 5: Fencing не винахід Proxmox; це давній кластерний принцип: якщо ви не можете довести, що вузол мертвий, припускайте, що він живий і небезпечний.
• Факт 6: Двовузлові кластери історично проблемні в багатьох вендорів, бо будь-яка відмова знімає більшість; хитрості типу qdevice/witness — стандартний фікс.
• Факт 7: Кластерні файлові системи і механізми консенсусу часто деградують «безпечно», переходячи у read-only або відмовляючись брати блокування при втраті кворуму — це навмисний захист.
• Факт 8: Багато «помилок HA» насправді пов’язані із семантикою сховища — спільне сховище має бути не просто «змонтоване», а консистентне, продуктивне і однаково налаштоване на всіх вузлах.

FAQ

1) Чи означає «failed to start pve-ha-lrm» завжди, що corosync зламаний?

Ні. Corosync/кворум — найпоширеніша причина, але LRM також може падати через проблеми з /etc/pve, невідповідність імен, fencing/watchdog або локальну корупцію/перевантаження. Починайте з кворуму, бо це жорсткий фільтр.

2) Якщо кворум втрачено, чи можу я змусити HA стартувати все одно?

Можна спробувати, але ви просите HA працювати без узгодженої реальності. Це рецепт split-brain і корупції сховища. Правильний крок — відновити кворум або навмисно відключити HA і керувати навантаженнями вручну, поки кластер не стане безпечним.

3) Чому pmxcfs має значення для pve-ha-lrm?

HA використовує кластерну конфігурацію і блокування, що зберігаються під /etc/pve. Якщо pmxcfs не змонтований або в режимі read-only через відсутність кворуму, HA не може координувати стан і відмовиться працювати.

4) У чому різниця між падінням pve-ha-manager і pve-ha-lrm?

pve-ha-manager — координатор; якщо він впав по всьому кластеру, рішення не прийматимуться. pve-ha-lrm — локальний агент; якщо він впав на одному вузлі, той вузол не може виконувати HA-дії, навіть якщо кластер загалом у порядку.

5) Чи може один поганий вузол перешкодити роботі HA на інших вузлах?

Так, якщо цей вузол спричиняє втрату кворуму або нестабільність членства. Якщо кворум зберігається, інші вузли зазвичай можуть продовжувати. Ключове — чи може кластер сформувати стабільну majority partition.

6) Мій кластер — двовузловий. Чи це «реальний HA»?

Може бути, але лише якщо ви додаєте вирішальний голос (qdevice/witness). Без цього втрата будь-якого вузла або мережевий розділ зазвичай вбиває кворум, і HA відмовиться діяти.

7) HA увімкнено, але VM не фейловерять. Чи це все ще проблема LRM?

Іноді. LRM може працювати, але дії ресурсів провалюються через недоступність сховища на цільовому вузлі, обмеження міграції або конфігурацію ресурсу. Перевірте ha-manager status, статус сховищ і логи конкретної VM.

8) Який найшвидший індикатор, що потрібно припинити чіпати HA і виправляти кластер?

Якщо бачите cfs-lock ... no quorum або Quorate: No. HA — це downstream. Спочатку виправляйте кворум і corosync.

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

Так. Стрибки часу і нестабільна синхронізація можуть корелювати з проблемами членства corosync і дивною поведінкою блокувань. Це рідше перша підозра, але це реальний фактор у заплутаних середовищах.

10) Якщо я відновлю кворум, чи потрібно перезавантажувати вузли, щоб повернути HA?

Зазвичай ні. Коли кворум і pmxcfs здорові, зазвичай достатньо перезапустити HA-сервіси. Перезавантаження може допомогти лише якщо вузол завис (проблеми з драйвером, пам’яттю, помилками файлової системи).

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

Коли Proxmox каже failed to start pve-ha-lrm, це рідко «баг HA». Це HA, що відмовляється працювати без надійного кластера. Сприймайте цю відмову як функцію безпеки, а не перешкоду.

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

1. Підтвердіть кворум і стабільність членства за допомогою pvecm status, corosync-cfgtool -s та логів corosync.
2. Перевірте здоров’я pmxcfs: /etc/pve має бути змонтованим, читаним і записуваним (коли кворум є).
3. Перевірте ідентичність і час: hostname, /etc/hosts і синхронізацію часу.
4. Підтвердіть припущення про watchdog/fencing, щоб HA могла приймати безпечні рішення під час часткових збоїв.
5. Лише потім перезапускайте HA-сервіси і перевіряйте через ha-manager status.

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