Proxmox «pmxcfs не змонтовано»: чому /etc/pve порожній і як відновити

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

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

Ви заходите на вузол Proxmox і веб-інтерфейс ніби забув усе, що ви коли-небудь створювали. Немає ВМ. Немає визначень сховищ. Немає налаштувань кластера. Ви відкриваєте shell і знаходите справжній жах: /etc/pve порожній. Потім ви запускаєте випадкову команду (бо так ми робимо під стресом) і вона каже: pmxcfs is not mounted.

Ця помилка виглядає ніби «мої конфіги зникли». Зазвичай це не так. Більшість випадків — ви дивитесь на мертвий або відмонтуваний кластерний файловий шар (pmxcfs), а не на очищений диск. Завдання — визначити, хто з трьох звичних підозрюваних тримає ніж: pve-cluster, corosync або quorum. Далі відновити систему так, щоб ви випадково не роздвоїли стан кластера в майбутню катастрофу.

Що pmxcfs насправді означає (і чому /etc/pve особливий)

/etc/pve у Proxmox — це не звичайний каталог у тому сенсі, якого ваша м’язова пам’ять очікує. Це файлова система, змонтована через FUSE, названа pmxcfs (Proxmox cluster filesystem). Процес, який її монтує і обслуговує, є частиною pve-cluster. Він зберігає конфігурацію кластера в невеликій базі й експонує її у вигляді файлів.

Отже, коли ви бачите «pmxcfs is not mounted» і /etc/pve виглядає порожнім, зазвичай це означає:

pmxcfs не змонтувався (сервіс не працює, падіння, права доступу, проблема з FUSE).
pmxcfs змонтований, але нездоровий (блокування бази, корупція або неможливість досягти quorum).
ви дивитесь на точку монтування без самого монтування (тому бачите порожній каталог на кореневому файловому шарі).

І так: ви можете зробити гірше. Неправильна «лікувальна» дія може створити split‑brain, перезаписати хорошу конфігурацію застарілою або назавжди розійняти стани кластера. Уникайте імпровізації.

Сухий факт: конфігурація Proxmox — це «просто файли» і «не лише файли». pmxcfs робить усе простим на вигляд, але тихо залежить від членства corosync і правил quorum.

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

pmxcfs базується на FUSE: це не файловий шар в ядрі; це користувацький простір, отже падіння або невдача монтування виглядають як «мій каталог зник».
/etc/pve охоплює весь кластер: навіть на одиночному вузлі Proxmox використовує абстракцію кластерного файлового шару для уніфікованих інструментів і поведінки UI.
Quorum контролює запис: у багатовузлових кластерах pmxcfs може відмовлятися писати без quorum, щоб уникнути split‑brain.
Corosync походить з HA‑світу: це система групової комунікації, яку часто застосовували в кластерах високої доступності; Proxmox використовує її для членства та повідомлень.
Proxmox успадкував підхід «файли як API»: редагування файлів у /etc/pve — це фактично виклик API конфігурації; UI та CLI сходяться тут.
pmxcfs зберігає локальну копію DB: вузли носять стан локально, тому вузол часто може відновити конфіги навіть коли мережа вогонь.
Двовузлові кластери історично проблемні: арифметика quorum карає парні числа. Proxmox підтримує двовузлову конфігурацію, але потрібно розуміти режими відмов.
QDevice існує, бо існує фізика: третій учасник кворуму може бути віртуальним (qnetd/qdevice), щоб не купувати третій сервер.

Одна цитата, що досі доречна в операціях, особливо коли UI порожній і ваш пульс не на місці: надія — не стратегія — приписують Gordon R. Sullivan (парафраз).

Симптоми, що виглядають як втрата даних (але зазвичай ні)

Коли pmxcfs не змонтовано, ви втрачаєте не просто список каталогу. Компоненти Proxmox, що очікують файли конфігурації кластера, починають падати каскадом:

Веб‑інтерфейс не показує ВМ/CT або видає помилки під час завантаження конфігурації.
pvesm status показує відсутні сховища, бо /etc/pve/storage.cfg «зник».
Файли конфігурацій ВМ у /etc/pve/qemu-server/*.conf виглядають відсутніми.
Команди кластера, наприклад pvecm status, падають або показують «no quorum».
Завдання бекапу, реплікації та HA‑менеджмент скаржаться, бо читають стан кластера.

Ось ключове діагностичне питання: Ми втратили ВМ, чи втратили вид конфігурації? У більшості випадків диски/LVM/ZFS‑томи залишаються; лише шар конфігурації офлайн.

Жарт #1: Якщо /etc/pve порожній — це не «мінімалізм», це ваш кластерний файловий шар, який мовчки вирішив взяти відгул.

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

Коли продукція впала, вам не потрібна лекція. Потрібен чіткий цикл: визначити, чи це проблема монтування, сервісу чи quorum. Робіть у цьому порядку.

Перше: чи `/etc/pve` взагалі змонтовано?

Якщо не змонтовано: зосередьтеся на pve-cluster і проблемах FUSE/монтування.
Якщо змонтовано, але порожнє/непідчитуване: зосередьтеся на здоров’ї pmxcfs і логах.

Друге: чи працює та чи здорова служба pve-cluster?

Якщо pve-cluster впав або рестартує: перевірте логи на предмет блокувань БД/корупції, проблем з правами або збоїв FUSE.

Третє: чи працює corosync, і чи є quorum?

Якщо corosync впав: pmxcfs може не сформувати членство кластера коректно.
Якщо corosync працює, але немає quorum: вирішуйте, чи це багатовузлова відмова (треба відновити quorum), чи одиночний вузол, де можна тимчасово форсувати очікувані голоси (обережно).

Четверте: чи ще існують диски ВМ?

Підтвердіть наявність ZFS‑dataset, LVM‑томів або вмісту директорій сховища. Якщо вони є, швидше за все ви маєте справу з доступністю конфігурації, а не втратою даних.

П’яте: оберіть шлях відновлення

Кластерний шлях: відновіть зв’язність corosync/quorum; уникайте будь‑яких «перебудов» поки не відновиться quorum.
Стенд‑алон шлях: виправте локальні сервіси; розгляньте відновлення /etc/pve з бекапа, якщо БД pmxcfs пошкоджена.

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

Нижче реальні завдання з командами, що означає вивід і яке рішення приймати далі. Виконуйте від root або через sudo. Ведіть нотатки. Під стресом ви забудете, що вже перевірили.

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

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

Значення: Якщо ви бачите pmxcfs on /etc/pve, монтування існує. Якщо нічого — значить не змонтовано.

Рішення: Якщо не змонтовано — переходьте до перевірок на рівні сервісів (Завдання 3). Якщо змонтовано, але порожнє — перевірте quorum і логи pmxcfs (Завдання 4–7).

Завдання 2: Перевірити, чи /etc/pve пустий через відсутність монтування

cr0x@server:~$ ls -la /etc/pve
total 0
drwxr-xr-x  2 root root  40 Dec 25 11:03 .
drwxr-xr-x 98 root root  80 Dec 25 10:58 ..

Значення: «Порожній» /etc/pve з лише . і .. — класика для незмонтованої точки монтування на кореневому файловому шарі.

Рішення: Розглядайте це як проблему монтування/сервісу, а не як відсутні конфіги. Не починайте відтворювати конфіги з пам’яті.

Завдання 3: Перевірити стан служби 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: failed (Result: exit-code) since Thu 2025-12-25 10:59:33 UTC; 2min ago
    Process: 2210 ExecStart=/usr/bin/pmxcfs (code=exited, status=1/FAILURE)
     Main PID: 2210 (code=exited, status=1/FAILURE)

Значення: Якщо сервіс впав — pmxcfs не обслуговує /etc/pve. Якщо активний — переходьте до corosync/quorum.

Рішення: У разі падіння служби читайте логи і виправляйте корінну причину перед сліпим перезавантаженням.

Завдання 4: Перевірити стан служби 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 Thu 2025-12-25 10:55:02 UTC; 6min ago
       Docs: man:corosync
   Main PID: 1020 (corosync)
      Tasks: 9 (limit: 15400)
     Memory: 23.4M

Значення: corosync — ваш транспорт членства кластера. Якщо він упав, буде порушено quorum і поведінку pmxcfs.

Рішення: Якщо corosync неактивний/впав — виправляйте його першим (мережа, конфіг, сертифікати не завжди тут; corosync головний).

Завдання 5: Швидко перевірити quorum за допомогою pvecm

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

Quorum information
------------------
Date:             Thu Dec 25 11:01:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Значення: «Quorate: No» часто є причиною, чому pmxcfs відмовляється коректно працювати у кластері, особливо для записів. Читання теж може деградувати залежно від обставин.

Рішення: Якщо ви в багатовузловому кластері і він не має quorum — зосередьтеся на відновленні зв’язності вузлів або qdevice. Уникайте кроків «перебудови pmxcfs», поки не відновиться quorum.

Завдання 6: Перевірити членство 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:	disconnected
		nodeid:          3:	disconnected

Значення: Цей вузол не бачить пірів. Це зазвичай проблема мережі або фаєрволу, або пір‑вимкнені.

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

Завдання 7: Прочитати логи pve-cluster, щоб знайти справжню причину

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 10:59:33 server pmxcfs[2210]: [main] notice: starting pmxcfs
Dec 25 10:59:33 server pmxcfs[2210]: [main] crit: Unable to acquire pmxcfs lock: Resource temporarily unavailable
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

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

Рішення: Шукайте застарілі процеси pmxcfs або залишковий стан блокування; не rm -rf випадкові директорії як терапію.

Завдання 8: Перевірити на наявність застарілих процесів pmxcfs

cr0x@server:~$ ps aux | grep -E 'pmxcfs|pve-cluster' | grep -v grep
root       1987  0.0  0.1  45620  9400 ?        Ss   10:58   0:00 /usr/bin/pmxcfs

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

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

Завдання 9: Рестарт сервісів у контрольованому порядку

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl restart pvedaemon pveproxy

Значення: Спершу corosync (членство), потім pmxcfs, потім демоні, що подають UI/API.

Рішення: Якщо pve-cluster все ще падає — повертайтесь до логів. Якщо він стартує, але quorum відсутній — не починайте редагувати конфіги.

Завдання 10: Підтвердити монтування /etc/pve і його вміст після рестарту

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
cr0x@server:~$ find /etc/pve -maxdepth 2 -type f | head
/etc/pve/corosync.conf
/etc/pve/storage.cfg
/etc/pve/user.cfg
/etc/pve/domains.cfg
/etc/pve/qemu-server/101.conf

Значення: Якщо ви бачите ці файли — pmxcfs змонтовано і подає дані знову.

Рішення: Тепер можна рухатись до виправлення стану кластера або проблем з виконанням ВМ. Якщо все ще порожньо — зупиніться і переосмисліть діагностику.

Завдання 11: Перевірити здоров’я кластерної файлової системи і операції з файлами

cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes
cr0x@server:~$ test -r /etc/pve/storage.cfg && echo "read ok"
read ok

Значення: Quorum «Yes» плюс читабельна конфігурація означає, що кластерний файловий шар у стабільному стані.

Рішення: Якщо quorate «No», уникайте змін конфігів. Якщо «Yes» — продовжуйте нормальні операції і прибирання.

Завдання 12: Підтвердити, що диски ВМ все ще існують (приклад ZFS)

cr0x@server:~$ zfs list -o name,used,avail,mountpoint | grep -E 'rpool/data|vm-'
rpool/data                 128G  1.72T  /rpool/data
rpool/data/vm-101-disk-0   64G   1.72T  -
rpool/data/vm-102-disk-0   64G   1.72T  -

Значення: Диски існують. Ймовірно ви «втратили» тільки шар конфігурації, а не дані ВМ.

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

Завдання 13: Підтвердити, що диски ВМ все ще існують (приклад LVM‑thin)

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
LV              VG   Attr       LSize   Data%  Meta%
data            pve  twi-aotz--  <1.80t  42.11  3.02
vm-101-disk-0    pve  Vwi-a-tz--  64.00g
vm-102-disk-0    pve  Vwi-a-tz--  64.00g

Значення: Ваші томи ВМ цілі.

Рішення: Не чіпайте thin‑пул. Термінова задача — конфігурація + здоров’я кластера.

Завдання 14: Шукати копії бекапів `/etc/pve`

cr0x@server:~$ ls -la /var/lib/pve-cluster/
total 20
drwxr-xr-x  5 root root 4096 Dec 25 10:59 .
drwxr-xr-x 50 root root 4096 Dec 25 10:58 ..
drwxr-xr-x  2 root root 4096 Dec 25 10:58 backup
drwxr-xr-x  2 root root 4096 Dec 25 10:59 config
drwx------  2 root root 4096 Dec 25 10:59 db
cr0x@server:~$ ls -la /var/lib/pve-cluster/backup | head
total 64
-rw------- 1 root root 65536 Dec 24 02:05 config-2025-12-24_02_05_01.tar

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

Рішення: Якщо БД pmxcfs пошкоджена, відновлення з цих бекапів зазвичай безпечніше, ніж ручне відтворення конфігів.

Завдання 15: Підтвердити базовий мережевий шлях для corosync (knet)

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.11/24
eno2             DOWN
cr0x@server:~$ ping -c 2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.10.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Значення: Якщо базова зв’язність до пір порвана — corosync не сформує членство. Якщо ping працює, але corosync ні — думайте про фаєрвол, MTU або фільтрацію портів.

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

Завдання 16: Перевірити на проблеми файлової системи або диска, що можуть зупиняти pmxcfs

cr0x@server:~$ dmesg -T | tail -n 20
[Thu Dec 25 10:57:10 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 25 10:57:10 2025] EXT4-fs (sda2): Remounting filesystem read-only

Значення: Якщо кореневий FS був перемонтований у режимі лише для читання, pmxcfs може не оновити свій DB/стан блокувань і сервіси впадуть.

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

Шляхи відновлення (одиночний вузол vs кластер)

Шлях A: Одиночний вузол (або «мені байдуже на членство кластера, мені потрібні конфіги назад»)

На справжній одиночній системі Proxmox (або вузлі, який ви навмисно відклaстерили) вам головне — змусити pve-cluster змонтувати pmxcfs і показати /etc/pve. Quorum зазвичай не є тим гейткіпером, як у багатовузлових кластерах.

Типові причини на одиночному вузлі:

pve-cluster не запустився через конкуренцію блокувань або застарілі процеси.
кореневий FS перейшов у режим read-only після проблем диска.
БД pmxcfs пошкоджена після крашу або відключення живлення.

Що я роблю спочатку: виправляю кореневий FS і сервіси. Тільки якщо логи вказують на пошкоджену БД pmxcfs — відновлюю з локального tar‑бекапу.

Коли pmxcfs не монтується через блокування/застарілий процес

Якщо journalctl каже про неможливість отримати pmxcfs lock — знайдіть застарілий процес, зупиніть сервіси і перезапустіть коректно. Не використовуйте «kill -9», поки не спробували нормальну зупинку і процес не завис.

cr0x@server:~$ systemctl stop pve-cluster
cr0x@server:~$ pkill -TERM pmxcfs || true
cr0x@server:~$ sleep 2
cr0x@server:~$ ps aux | grep pmxcfs | grep -v grep || echo "no pmxcfs running"
no pmxcfs running
cr0x@server:~$ systemctl start pve-cluster
cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Точка рішення: Якщо це виправило — усе готово. Якщо знову відмовляє — шукайте глибшу причину: диск у режимі read-only, відсутність FUSE або корупція DB.

Коли кореневий файловий шар перейшов у режим read-only

Це класична «усе падає, але корінь проблеми — один рядок у dmesg». Якщо ext4 перемонтовано у read-only, не варто довіряти поведінці pmxcfs і corosync.

Виправляйте базову проблему зі зберіганням. Можливо, доведеться перевірити SMART, запланувати fsck і перезавантаження. Якщо це віртуальний вузол — поправте сховище гіпервізора.

Коли БД pmxcfs пошкоджена і потрібне відновлення конфігів

Якщо у вас є локальні бекапи під /var/lib/pve-cluster/backup, відновлення звідти зазвичай безпечніше, ніж ручне відтворення storage.cfg, користувачів, прав і конфігів ВМ.

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

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

cr0x@server:~$ mkdir -p /root/pve-restore
cr0x@server:~$ tar -tf /var/lib/pve-cluster/backup/config-2025-12-24_02_05_01.tar | head
etc/pve/corosync.conf
etc/pve/storage.cfg
etc/pve/user.cfg
etc/pve/qemu-server/101.conf
etc/pve/lxc/103.conf

Точка рішення: Якщо tar містить очікувані конфіги — можна відновити вибірково файли після монтування pmxcfs. Якщо pmxcfs взагалі не змонтовано — треба спочатку ремонтувати pmxcfs; запис файлів у незмонтований /etc/pve просто запише їх у звичайний каталог на кореневому FS і нічого не вирішить.

Шлях B: Кластерний вузол (тут люди зазвичай втрачають вихідні вихідні вихідні)

У кластері pmxcfs тісно пов’язаний з членством corosync і правилами quorum. Правильне відновлення залежить від того, чи:

цей вузол ізольований, але інші в порядку;
весь кластер частково впав (втрачені вузли, мережа, qdevice);
є ризик split‑brain (дві частини вважають себе основними).

Правило, яке я застосовую: Якщо ви можете відновити quorum, повернувши вузли/мережу — зробіть це. Не форсуйте quorum як перший крок. Форсований quorum — як обійти запобіжник цвяхом. Працює, але вчить нових видів відмов.

Відновлення зв’язності corosync перед тим, як чіпати /etc/pve

Corosync чутливий до:

мережевих розділень та змін у фаєрволі
несумісності MTU (особливо при запровадженні jumbo frames)
помилкового прив’язування інтерфейсу після перейменування NIC або заміни обладнання
зламаних імен хостів або змін IP (особливо після відновлення вузла з шаблона)

Почніть з того, щоб вузли знову почали спілкуватися. Потім перевірте quorum. Потім підтвердьте стан монтування pmxcfs.

Двовузлові кластери і qdevice: математика не слухається вашого оптимізму

Двовузлові кластери можливі, але вони заміновані, якщо поводитися з ними як з тривузловими. Якщо один вузол падає — ви втрачаєте quorum, якщо немає qdevice або тимчасового зміни expected votes.

Тимчасові зміни expected-votes можуть вас витягнути, але це аварійні заходи. Їх потрібно відмінити, коли кластер повернеться до норми. Інакше ви «виправили» quorum, перекроївши реальність — смілива стратегія в системному інжинірингу.

Жарт #2: Quorum — як нарада: ніхто нічого не вирішує, поки достатньо людей не з’явиться, і той, хто прийшов один, завжди сердиться.

Коли безпечно(ніжно) використовувати аварійний обхід quorum

Використовуйте обхід лише якщо:

ви впевнені, що відсутні вузли дійсно вимкнені, а не живі й розділені мережею;
ви приймаєте ризик, що зміни конфігурації зараз можуть конфліктувати при поверненні вузлів;
ви намагаєтесь відновити сервіси ВМ, що живуть на цьому вузлі, і вам потрібно, щоб pmxcfs був записуваним.

Якщо сумніваєтесь — не робіть. Виправляйте мережу. Піднімайте вузли. Відновлюйте нормальний quorum.

Три міні‑історії з корпоративного життя

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

У них був три‑вузловий Proxmox кластер і акуратно сплановане вікно змін. Один вузол потребував оновлення прошивки. План: вивести його, оновити, повернути. Стандартно.

Хтось помітив, що кластер виглядає «здоровим» в UI після перезавантаження вузла, тож почали перезавантажувати другий вузол для оновлення. Припущення було простим: «якщо UI працює — кластер в порядку».

Друге перезавантаження втратило quorum. pmxcfs на залишковому вузлі не змонтувався коректно, і /etc/pve виглядав порожнім. UI перетворився з «здорово‑так» у «виглядає як чиста інсталяція» менше ніж за хвилину. Паніка, звісно, пішла далі.

Далі пішов неправильний крок: інженер почав відтворювати визначення сховищ у UI. Без quorum деякі записи блокувались, деякі були непослідовні, і кілька були зроблені на вузлі, який потім виявився не найкращим джерелом істини.

Коли другий вузол повернувся і quorum відновився, стан кластера зійшовся — але не так, як хотіли. Вони провели ніч, розплутуючи дублікати сховищ, застарілі конфіги ВМ і конфліктні визначення. Нічого не було «втрачено», але й не «правильно».

Що виправило ситуацію: вони відкотили імпровізовані правки, відновили оригінальні конфіги з відомого хорошого tar‑бекапу, потім по черзі реінтегрували вузли, перевіряючи quorum і стан монтування pmxcfs. Урок — не «ніколи не перезавантажувати вузли», а «ніколи не вважати UI оракулом quorum».

Міні‑історія 2: Оптимізація, що відвернулась

Команда хотіла знизити затримки між вузлами для corosync, Ceph‑трафіку і live migration. Вони консолідували кластерний трафік в «швидший» VLAN і ввімкнули jumbo frames. У лабораторії це працювало. Звісно, працювало.

У продакшені один шлях комутатора тихо не підтримував кінцево‑кінцево MTU. Ping працював, бо маленькі пакети не турбувалися. Corosync іноді працював, потім флапнув, потім оголосив пирів мертвими. Вузли з’являлись і зникали як ненадійні колеги.

На одному з вузлів pmxcfs час від часу відмонтовувався або відмовлявся від операцій через нестабільне членство/quorum. Оператори бачили симптом: /etc/pve пустий, ВМ зникли в UI, «pmxcfs is not mounted». Інженери зберігання бачили глибший симптом: шар членства кластера коливався під навантаженням.

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

Виправлення було нудне: повернути MTU до 1500 на кільці corosync, відокремити трафік corosync від масового трафіку зберігання і перевірити справжні розміри пакетів. Команда пізніше знову ввела jumbo frames лише там, де був доведений end‑to‑end‑підтримка і з моніторингом стану лінків corosync. Продуктивність повернулась пізніше. Стабільність — відразу.

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

Інша організація мала звичку: кожен вузол щодня копіював /var/lib/pve-cluster/backup на віддалений сховище, нечасто залучене до кластера. Не модно. Просто послідовно.

Вони також тримали «зошит катастроф»: інвентар вузлів, назву кластера, адреси corosync ring і односторінковий чекліст «як перевірити quorum». Його написав хтось, хто явно не довіряв пам’яті — навіть власній.

Під час відключення живлення один вузол піднявся з помилками кореневого FS і pmxcfs відмовився монтуватися. UI нічого не показував. Але вони не кинулись відновлювати. Вони перевірили монтування, corosync і впевнились, що інші вузли утримали quorum.

Вони відновили зламаний вузол як нову інсталяцію OS, потім приєднали його назад до кластера за збереженою інформацією. Після цього відновили потрібні хост‑специфічні налаштування і перевірили, що pmxcfs відображає правильну конфігурацію. ВМ не постраждали, бо їх сховища були на спільних бекендах.

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

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

Цей розділ суб’єктивний, бо ті самі помилки повторюються у різних командах. Деякі зрозумілі. Більшість — уникальні.

Помилка 1: «/etc/pve порожній, отже конфіги видалено»

Симптом: ls /etc/pve нічого не показує; UI не показує ВМ.

Причина: pmxcfs не змонтовано. Ви дивитесь у порожній каталог‑точку монтування на кореневому файловому шарі.

Виправлення: Перевірте mount | grep /etc/pve, потім виправляйте pve-cluster і corosync/quorum.

Помилка 2: Відтворення конфігів під час відсутності quorum

Симптом: Після «відновлення» ви бачите дублікати сховищ/ВМ або дивні права.

Причина: Ви змінили конфігурацію кластера в деградованому/без‑quorum стані. Пізніше кластер синхронізувався і вийшов Franken‑конфіг.

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

Помилка 3: Рестарт випадкових сервісів у надії на диво

Симптом: Іноді допомагає, іноді ні; рестарт pveproxy не вирішує проблему.

Причина: pveproxy/pvedaemon залежать від pmxcfs для конфігурації. Рестарт UI не монтує файлову систему.

Виправлення: Починайте з corosync і pve-cluster. Потім рестартуйте демони UI.

Помилка 4: Редагувати файли в /etc/pve коли він не змонтований

Симптом: Ви «виправили» /etc/pve/storage.cfg, але UI не реагує.

Причина: Ви записали у звичайний каталог на кореневому FS, а не в pmxcfs.

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

Помилка 5: Сприймати двовузловий кластер як такий, що має запас quorum

Симптом: Втрата одного вузла робить залишковий вузол не‑quorate і pmxcfs деградує.

Причина: Двовузлові кластери потребують qdevice або уважного управління голосами.

Виправлення: Додайте qdevice або прийміть, що втрата одного вузла — подія втрати quorum і плануйте операції відповідно.

Помилка 6: «Виправлення» видаленням БД pmxcfs без плану

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

Причина: Ви стерли локальний стан кластера, не розуміючи, чи був цей вузол авторитетним і як він буде ресинхронізований.

Виправлення: Деструктивні дії над БД робіть тільки коли визначили авторитетні вузли і маєте бекапи. Надавайте перевагу відновленню з /var/lib/pve-cluster/backup, коли це доречно.

Помилка 7: Ігнорувати помилки диска

Симптом: pmxcfs/corosync флапають, кореневий FS у read-only, сервіси падають дивними способами.

Причина: Реальна корупція або проблеми зі зберіганням.

Виправлення: Зупиніться і виправте диск. Жоден рестарт сервісів не вилікує перемонтований у read-only файловий шар.

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

Чекліст 1: Негайна триаж (10 хвилин, без героїки)

Перевірте монтування: mount | grep /etc/pve.
Перевірте стан pve-cluster і corosync.
Перевірте quorum: pvecm status.
Перевірте логи: journalctl -u pve-cluster -b -n 80 і journalctl -u corosync -b -n 80.
Підтвердіть існування дисків (ZFS/LVM). Це заощадить від панічних дій.

Чекліст 2: Якщо pmxcfs не змонтовано

Переконайтесь, що кореневий FS записуваний: перевірте dmesg -T | tail на події remount read-only.
Чисто зупиніть pve-cluster; шукайте застарілі процеси pmxcfs.
Запустіть corosync (якщо кластер), потім запустіть pve-cluster.
Підтвердіть, що /etc/pve змонтовано і не порожнє.
Тільки після монтування pmxcfs: рестартуйте pveproxy/pvedaemon.

Чекліст 3: Якщо проблема в corosync/quorum

Переконайтесь у мережевій досяжності і правильних IP інтерфейсів на corosync ring.
Перевірте членство: corosync-cfgtool -s.
Підніміть відсутні вузли, якщо можливо; відновіть нормальне членство.
Якщо двовузловий кластер: переконайтесь, що qdevice доступний, або погодьтеся на аварійну зміну expected-votes (і запишіть зміни).
Після відновлення quorum: перевірте, що /etc/pve показує очікувані файли і що вузли погоджуються щодо стану кластера.

Чекліст 4: Якщо БД pmxcfs, здається, пошкоджена

Зупиніться і зафіксуйте докази: логи, стани сервісів і копії tar‑бекапів.
Визначте авторитетний вузол (у кластері: той, що має здоровий quorum і очікувану конфігурацію).
Використовуйте бекапи з /var/lib/pve-cluster/backup, де доречно; уникайте ручного відтворення, якщо не любите тонких помилок.
Перевірте критичні файли: corosync.conf, storage.cfg, qemu-server/*.conf, ACL/конфіги користувачів.
Підійміть сервіси, перевірте UI, а потім перевірте відображення дисків ВМ перед запуском робочих навантажень.

Питання та відповіді (FAQ)

1) Чому /etc/pve стає порожнім замість того, щоб показувати старі файли?

Тому що /etc/pve — це точка монтування. Коли pmxcfs не змонтовано, ви дивитесь на підлягаючий каталог на кореневому файловому шарі, який зазвичай порожній.

2) Чи видалені диски ВМ, коли /etc/pve порожній?

Зазвичай ні. Диски ВМ зберігаються в ZFS datasets, LVM томах, Ceph RBD або в інших директоріях. Перевірте за допомогою zfs list, lvs або інструментів вашого бекенду сховища перед тим, як припускати втрату даних.

3) Чи можна просто перезавантажити, щоб виправити «pmxcfs is not mounted»?

Іноді так. Але якщо причина — помилки диска, мережеве розділення або зламаний конфіг corosync, перезавантаження — це просто довгий спосіб повторити ту саму відмову з додатковим часом простою.

4) Якщо corosync впав, чи може pmxcfs все одно змонтуватися?

На кластерному вузлі поведінка pmxcfs тісно пов’язана зі станом кластера. Він може змонтуватись, але бути деградованим, відмовлятися від записів або поводитись непослідовно. Розглядайте відмови corosync як пріоритетні, поки не доведено інше.

5) Яка найбезпечніша перша команда, коли я бачу цю помилку?

mount | grep /etc/pve і systemctl status pve-cluster corosync. Ви хочете знати, чи це питання монтування, сервісу чи quorum/членства.

6) Чи можу я редагувати файли в /etc/pve безпосередньо для відновлення?

Так — коли pmxcfs змонтовано і кластер здоровий/має quorum. Ні — коли не змонтовано, бо ви зміните неправильне місце і створите плутанину.

7) Що робити, якщо лише на одному вузлі /etc/pve порожній, а на інших ні?

Цей вузол ймовірно ізольований, має локальну мережеву помилку або проблему зі службами/диском. Порівняйте членство corosync і логи. Не «ремонтуйте кластер» з зламаного вузла.

8) Як запобігти, щоб це не стало більшим інцидентом наступного разу?

Тримайте конфіг‑бекапи поза кластером, моніторьте quorum і стан лінків corosync, уникайте ризикових мережевих «оптимізацій» без end‑to‑end перевірки і репетируйте сценарії втрати вузла.

9) Чи означає «no quorum» завжди, що /etc/pve буде порожнім?

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

10) Чи варто видаляти вузол і додавати його в кластер заново?

Лише після того, як ви підтвердите, чи локальний стан вузла корумпований і чи кластер стабільний. Перепідключення іноді — правильна відповідь, але це крайній захід, а не перша спроба.

Подальші кроки, які варто зробити

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

Переконайтесь у стабільності quorum і членства протягом кількох хвилин. Якщо corosync флапає — ви ще не закінчили.
Перевірте узгодженість конфігурацій між вузлами: визначення сховищ, конфіги ВМ і права доступу.
Підтвердіть відповідність дисків ВМ перед тим, як запускати важливі робочі навантаження. Невідповідність конфігу може вказувати на помилкову прив’язку до диска.
Експортуйте бекапи /var/lib/pve-cluster/backup поза кластер, якщо ще цього не зробили.
Запишіть корінну причину і точні кроки, які ви застосували. Майбутній ви — чужак з меншим сном.

Мета — не просто «повернути UI». Мета — відновити послідовну, кворумну і стійку контрольну площину, щоб комп’ютинг і зберігання не плавали в легендах.