Proxmox “unable to write /etc/pve/*”: диск, pmxcfs або права — як визначити

Ментальна модель: що насправді таке /etc/pve

У Proxmox VE /etc/pve — це не «просто конфігурація на диску». Це віртуальна файлова система, яку надає pmxcfs (Proxmox Cluster File System) і яка монтується через FUSE. Вона поводиться як спільна база конфігурації з семантикою файлової системи: файли і каталоги, атомарні оновлення, права доступу та inotify-події. Але істина під капотом ближча до «машини станів кластера плюс реплікація», ніж до простого «папки».

Один факт пояснює більшість дивностей:

• Якщо pmxcfs нездоровий або змонтований у режимі лише для читання, записи в /etc/pve зазнають невдачі, навіть якщо на кореневому розділі достатньо вільного місця.
• Якщо кластер втрачає кворум, pmxcfs часто переходить у режим лише для читання, щоб захистити вас від split brain. Помилка виглядає як проблема файлової системи, бо саме так ви з нею взаємодієте.
• Якщо права доступу неправильні, ви можете бути root на вузлі і все одно отримувати відмову залежно від того, в якому контексті виконується запис (API-токен, користувач, власник файлу або застарілий замок).

Тому коли ви бачите «unable to write /etc/pve/*», не поспішайте виконувати класичний Linux-танець з chown -R і chmod -R. Це саме той шлях, яким керівники проблем перетворюють керований інцидент у проект відновлення.

Ось операційний переклад:

• Проблема диска означає, що бекенд, від якого залежить pmxcfs, вичерпав простір або пошкоджений (зазвичай локальний кореневий fs для логів/стану, або гірше: корупція, перемонтування в RO, I/O помилки).
• Проблема pmxcfs/кворуму означає, що стан членства кластера не дозволяє записів; ваш вузол може втратити кворум, corosync має проблеми або pve-cluster завис.
• Проблема прав означає, що актор, який пише (CLI-користувач, API-користувач/токен, процес служби), не може записати, або існує замок/застарілий стан, що проявляється як помилка запису.

Одна операційна цитата варта того, щоб тримати її на видноті: «переказана ідея» від Werner Vogels (CTO Amazon): Ви побудували — ви експлуатуєте; зворотний зв’язок від операцій — частина інженерії. Сенс: не просто «полагодьте запис», виправте причину, через яку система вважає запис небезпечним.

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

Перше: підтвердити, що /etc/pve робить прямо зараз (секунди)

1. Чи pmxcfs змонтовано і чи дозволені записи? Перевірте тип монтування та статус тільки для читання.
2. Чи кластер має кворум? Якщо ні — очікуйте поведінки лише для читання.
3. Чи служби здорові? Зокрема pve-cluster і corosync.

Друге: виключити нудні вбивці (хвилини)

1. Наявність вільного місця на / або /var? Тиск на диск ламає все опосередковано.
2. Файлова система перемонтована в RO? Один I/O-сбоїв і ваші записи приречені.
3. Тиск по пам’яті? pmxcfs тримає метадані в оперативній пам’яті; екстремальний тиск може робити симптоми дивними.

Третє: перевірити акторів і конкретний шлях запису (хвилини)

1. Ви пишете через GUI/API-токен? Модель прав відрізняється від «root по SSH».
2. Чи є файл блокування або застаріла конфігурація? Блокування конфігів ВМ і задач реплікації можуть тримати процеси.
3. Чи цей вузол «особливий»? Розбіжність часу, втрата мережі або режим одного вузла можуть змінити поведінку.

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

Жарт #1: pmxcfs — як груповий чат: якщо половина команди не бачить повідомлень, ніхто не може редагувати прикріплене повідомлення.

Цікаві факти & історичний контекст (чому воно так поводиться)

• Факт 1: /etc/pve — це FUSE-монтування, яке надає pmxcfs, а не звичайний каталог на диску. Ось чому «помилки файлової системи» насправді маскують «стан кластера».
• Факт 2: Proxmox використовує Corosync для членства в кластері і рішень по кворуму; pmxcfs використовує це, щоб вирішити, коли безпечно приймати записи.
• Факт 3: Поведінка «тільки для читання при відсутності кворуму» — це захисна функція проти split brain. Це дратує, поки не врятує вас від двох вузлів, що роблять конфліктні зміни.
• Факт 4: pmxcfs зберігає більшість конфігурації кластера в пам’яті та синхронізує її; втрата pmxcfs — не те саме, що втрата всієї файлової системи ОС.
• Факт 5: Історично файлові системи кластера в віртуалізаційних стеках тяжіють до консервативного блокування записів. Модель VMware vCenter і багато HA-стеків також віддають перевагу «зупинити записи», коли членство невизначене.
• Факт 6: Дизайн Proxmox — робити конфіг кластеру схожим на файли — спрощує автоматизацію (редагувати файл, виконати команду), але також робить режими відмов схожими на «уніксові» проблеми.
• Факт 7: Багато відмов запису в Proxmox — це вторинні ефекти: повний диск зупиняє запис логів, служби заходять у цикл перезапуску, кворум флапає, і раптом /etc/pve виглядає зламаним, хоча реальна проблема — це ємність.
• Факт 8: Зсув часу може дестабілізувати членство corosync при поганих мережах. У кластерах час — це залежність на рівні живлення та охолодження — просто тихіша.

Завдання для триажу: команди, виводи, та рішення (12+)

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

Завдання 1: підтвердити, що /etc/pve — це pmxcfs FUSE-монтування

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

Значення: Очікуєте type fuse.pve. Якщо відсутнє, pmxcfs не змонтовано (pve-cluster впав або завис).

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

Завдання 2: протестувати шлях запису без побічних наслідків

cr0x@server:~$ touch /etc/pve/.diag-write-test
touch: cannot touch '/etc/pve/.diag-write-test': Read-only file system

Значення: «Read-only file system» зазвичай означає, що pmxcfs блокує записи (часто через кворум). «Permission denied» — актор/ACL. «No such file» натякає, що монтування відсутнє.

Рішення: Read-only → перевірити кворум і pve-cluster; permission denied → перевірити користувача/контекст API; no such file → pmxcfs не змонтовано.

Завдання 3: швидка перевірка стану кворуму

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

Quorum information
------------------
Date:             Thu Dec 25 12:10:03 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          No

Значення: Quorate: No — ваш явний індикатор. pmxcfs може перейти в режим тільки для читання, щоб запобігти розбіжностям.

Рішення: Виправте підключення corosync/кворум перед тим, як «латати права» або перезапускати випадкові служби.

Завдання 4: подивитися, кого corosync вважає присутнім

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
	id	= 192.0.2.11
	status	= ring 0 active with no faults
RING ID 1
	id	= 198.51.100.11
	status	= ring 1 active with no faults

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

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

Завдання 5: перевірити вигляд членства в кластері

cr0x@server:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Thu Dec 25 12:10:08 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.2
Quorate:          No

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

Значення: Total votes 1 означає, що ви ізольовані. Це не «проблема повного диска». Це «мережа/членство кластера» проблема.

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

Завдання 6: перевірити стан служби 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 Thu 2025-12-25 12:01:22 UTC; 8min ago
   Main PID: 1543 (pmxcfs)
      Tasks: 7
     Memory: 52.3M
        CPU: 9.122s

Значення: Якщо inactive/failed, /etc/pve або не буде змонтовано, або буде застарілим.

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

Завдання 7: читати релевантні логи, а не всі логи

cr0x@server:~$ journalctl -u pve-cluster -u corosync --since "30 min ago" --no-pager
Dec 25 11:55:02 pve1 pmxcfs[1543]: [status] notice: received write while not quorate - rejecting
Dec 25 11:55:04 pve1 corosync[1321]:   [QUORUM] This node is within the non-primary component
Dec 25 11:55:06 pve1 pmxcfs[1543]: [dcdb] notice: leaving CFS service because of lost quorum

Значення: pmxcfs явно відхиляє записи через втрату кворуму. Ось і вся історія.

Рішення: Відновіть членство corosync. Якщо це плановане відключення мережі — використайте плановану процедуру (див. контрольні списки).

Завдання 8: виключити просте виснаження диска

cr0x@server:~$ df -hT /
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4  110G  109G     0 100% /

Значення: 100% кореневої файлової системи — генератор інцидентів. Служби падають креативно. pmxcfs може бути змонтований, але інші компоненти не можуть записувати стан/логи.

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

Завдання 9: перевірити виснаження інодів (так, це ще трапляється)

cr0x@server:~$ df -i /
Filesystem     Inodes IUsed  IFree IUse% Mounted on
/dev/sda2     7208960 7208801    159  100% /

Значення: Можна мати вільні гігабайти і все одно не створити нові файли. Деякі відмови запису піднімаються як «unable to write» і виглядають як проблеми з правами.

Рішення: Знайдіть «лопату» інодів (часто дрібні файли під /var/lib або /var/log) і очистіть безпечно. Потім повторіть спробу запису в /etc/pve.

Завдання 10: виявити перемонтування в RO через I/O помилки

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

Значення: Файлова система ОС перемонтована в режим лише для читання. Ви не можете довіряти жодній поведінці запису, включаючи служби, які керують /etc/pve.

Рішення: Зупиніться. Виправте апаратне забезпечення/зберігання або відновіть файлову систему. Помилка запису конфігурації кластера — не основна проблема тут.

Завдання 11: підтвердити опції монтування /etc/pve (rw vs ro)

cr0x@server:~$ findmnt -no TARGET,FSTYPE,OPTIONS /etc/pve
/etc/pve fuse.pve rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other

Значення: Якщо показано ro, це керівне рішення (кворум або стан pmxcfs) або режим помилки монтування.

Рішення: ro + quorate=no → виправляйте кворум. ro + quorate=yes → копайте в діагностиці pmxcfs і логах.

Завдання 12: підтвердити, що вузол бачить пірів (перевірка мережі)

cr0x@server:~$ ping -c 2 192.0.2.12
PING 192.0.2.12 (192.0.2.12) 56(84) bytes of data.
64 bytes from 192.0.2.12: icmp_seq=1 ttl=64 time=0.332 ms
64 bytes from 192.0.2.12: icmp_seq=2 ttl=64 time=0.301 ms

--- 192.0.2.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Значення: Ping працює — не означає, що corosync працює, але якщо ping не працює, це зазвичай причина втрачених голосів.

Рішення: Якщо ping не проходить — виправляйте L2/L3 перш за все. Якщо ping працює — досліджуйте MTU, multicast/UDPU, правила фаєрволу або специфіку транспорту knet.

Завдання 13: перевідтворити помилку контрольовано через шар API

cr0x@server:~$ pvesh set /nodes/pve1/config -description "diag change"
unable to write file '/etc/pve/nodes/pve1/config': Permission denied

Значення: Якщо помилка «Permission denied» через pvesh, можливо, ви працюєте не в root-shell або використовуєте API-токен з недостатніми правами.

Рішення: Підтвердіть вашу особу і ролі. Якщо ви root і все одно отримуєте відмову — дивіться на ACL/власність або стан прав pmxcfs.

Завдання 14: підтвердити, ким ви є (це важливіше, ніж здається)

cr0x@server:~$ id
uid=1001(ops) gid=1001(ops) groups=1001(ops),27(sudo)

Значення: «sudo group» — не те саме, що «root». Якщо ваш інструмент не використав sudo, ви не root. Proxmox часто очікує записів від рівня root для конфігу кластера.

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

Завдання 15: перевірити, чи коренева файловa система здорова достатньо, щоб їй довіряти

cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!

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

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

Жарт #2: Баги з правами — це робочий еквівалент пропускної картки, що перестає працювати саме коли ви тримаєте каву.

Три великі категорії: диск, pmxcfs/кворум, права

Категорія A: проблеми з диском та файловою системою ОС

Проблеми з диском проявляються двома шляхами: ємність (заповнені блоки/іноди) і цілісність (I/O помилки, що викликають перемонтування в RO). Обидва можуть викликати «unable to write /etc/pve/*», бо компоненти Proxmox потребують локального диска для роботи, навіть якщо /etc/pve сам по собі віртуальний.

Типові ланцюги, спричинені диском:

• / full → служби працюють некоректно → служби кластера флапають → pmxcfs стає нестабільним. Це трапляється частіше, ніж багато хто визнає.
• Файлова система перемонтована в RO → pve-cluster може залишатися запущеним, але не може зберігати стан/логи. Ви бачите помилки запису, але вирішення — в зберіганні, а не в Proxmox.
• Вичерпання інодів → велика кількість дрібних файлів (логи контейнерів, черги резервних копій, spool моніторингу) → запис конфігів не вдається опосередковано.

Чого не робити: не «вирішуйте» заповнений диск, видаляючи випадкові файли під /var/lib/pve-cluster або інші файли, що нагадують стан кластера. Очищайте логи, обертайте, обрізайте резервні копії, видаляйте невикористані ISO, а потім перегляньте ситуацію.

Категорія B: pmxcfs і кворум (класика)

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

Ключові індикатори, що це ваша категорія:

• pvecm status показує Quorate: No
• journalctl -u pve-cluster згадує втрату кворуму та відмову записів
• /etc/pve змонтовано, але в режимі лише для читання
• Збої збереження в GUI по всьому спектру: створення ВМ, редагування сховища, мережеві конфігурації

Що викликає втрату кворуму в реальному житті?

• Мережеві розділення, особливо «працює TCP, але не працює corosync» (невідповідний MTU, правила фаєрволу, асиметрична маршрутизація)
• Вузол вимкнений (планово чи ні) і кластер має таку конфігурацію, що ви втрачаєте більшість голосів
• Дрейф часу, що викликає нестабільність членства
• Часткові або некоректно застосовані зміни конфігурації corosync

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

Категорія C: права доступу та шляхи доступу

Права — найлегша категорія, але часто трапляється у організаціях з автоматизацією, API-токенами і «тимчасовими» змінами, що стають постійними.

Типові випадки:

• Ви не root (або ваш інструмент не використовує sudo) і намагаєтесь змінити конфіг кластера.
• API-токен не має потрібної ролі/прав для зміни об’єктів.
• Хтось вручну змінив власника/режим під /etc/pve (так, таке буває; ні, це не хобі).
• Застаріла семантика блокувань: це не класичні UNIX-файлові блокування, а Proxmox «lock»-стани у конфігу (резервне копіювання, снепшот, міграція), які блокують запис у конфіг ВМ.

Ключова діагностична різниця — текст помилки:

• Permission denied зазвичай вказує на актор/ACL/власність.
• Read-only file system зазвичай вказує на кворум/pmxcfs або перемонтування ОС у RO.
• No space left on device — або OS диск, або прояв іншого виснаження ресурсів.

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

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

У віддаленому сайті було три вузли Proxmox. Оновлення прошивки комутатора запланували на 2:00 ночі — класика. План: оновлювати по одному комутатору, покладатись на резервні uplink’и, без простою. Класичне припущення.

Неправильне припущення було тонким: «Якщо ping працює, corosync теж працюватиме». Після першого перезавантаження комутатора мережа управління залишилась доступною. SSH працював. Моніторинг показував вузли «up». Але трафік corosync ішов по іншому VLAN з іншим MTU, і нова прошивка змінила поведінку jumbo-frame. Не настільки, щоб обірвати весь трафік — але достатньо, щоб викликати періодичну втрату пакетів на більших кадрах.

Через півгодини on-call спробував створити ВМ для термінового навантаження. GUI впав: unable to write /etc/pve/nodes/.... Вони зробили те, що багато розумних людей роблять під стресом: вирішили, що це локальна проблема. Почистили диск, перезапустили pve-cluster, навіть перезавантажили вузол. Це не допомогло. Навпаки — членство почало ще більше флапати, бо кластер постійно переобирав лідерів на фоні нестабільної мережі.

Вирішення було не в Proxmox. Потрібно було зробити corosync надійним знову: узгодити MTU по всьому шляху, підтвердити стабільність knet-з’єднання, і лише тоді дати кворуму осісти. Як тільки кворум стабілізувався, /etc/pve миттєво став доступним для запису — без правок і без магії.

Урок: не діагностуйте розподілену систему як одиночну машину. «Я можу SSH» — це низький поріг. Трафік кворуму має суворіші вимоги, ніж ваш термінал.

Міні-історія 2: оптимізація, що відігралась боком

Інша організація хотіла швидших фейловерів. Вони агресивно налаштували: коротші таймаути corosync, чутливіше виявлення збоїв, і «тонкий» мережевий шлях. Також консолідували трафік кластера на тих же інтерфейсах, що й реплікація сховища, бо «все 10GbE, що може піти не так?»

У спокійну погоду це працювало чудово. Потім стартували щомісячні бекупи і трафік реплікації різко підскочив. Інтерфейси були настільки насичені, що з’явився джиттер. Corosync не потребує багато пропускної здатності, але він не любить непередбачувану затримку. Членство почало флапати. Кворум коротко падав, повертався, знову падав. Оператори не бачили «мережа впала»; вони бачили «Proxmox не може записати конфіг».

Відкат був операційним, а не теоретичним. Кожного разу, коли кворум падав, pmxcfs зупиняв прийом записів. Зміни через GUI частково застосовувалися, потім відкатувалися. Автоматизація, що очікувала идемпотентність, почала трястись: «set storage», «fail», «retry», створюючи лавину задач і логів. А цей лавинний лог у свою чергу штовхнув вузол ближче до тиску на диск. Тиха оптимізація перетворилась на багаторівневу відмову.

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

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

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

Одна медично орієнтована організація працювала на трьох вузлах з четвертим «свідком» для голосування. Нічого особливого. Вони ще мали звичку, яку інженери люблять глузувати: писаний ранбук з «pre-checks» і «stop conditions».

Одного дня контролер зберігання почав видавати періодичні помилки. ОС перемонтував файлову систему в RO на одному вузлі. Той вузол залишався досяжним, але служби деградували. On-call побачив unable to write /etc/pve/... при спробі відключити заплановане завдання. Замість того, щоб форсувати перезапуск всього, вони дотримались ранбука: перевірили dmesg, статус монтування, кворум, здоров’я диска. Ранбук змусив їх довести або спростувати кожну категорію.

За кілька хвилин вони зрозуміли, що це не кворум. Кластер мав кворум; pmxcfs був у порядку. Місцева файлова система була RO через помилки ядра. Це змінило відповідь: евакуювати ВМ з цього вузла, зазначити його як cordon і почати заміну апаратного забезпечення. Вони не «ремонтували права» і не ризикували пошкодити стан кластера.

Наступного дня звіт про інцидент був нудним. Це комплімент. Причина його нудності в тому, що вони сприйняли «unable to write /etc/pve» як симптом, а не діагноз, і мали дисциплінований шлях до ізоляції причини.

Урок: нудний чек-лист — не бюрократія. Це функція надійності.

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

1) Симптом: «Read-only file system» при спробі торкнутися /etc/pve

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

Виправлення: Відновіть кворум (мережа, corosync членство). Переконайтесь, що pvecm status показує Quorate: Yes. Не вирішуйте це через chmod.

2) Симптом: збереження в GUI не вдається, CLI як root теж не працює

Корінь: pmxcfs блокує записи (кворум) або pmxcfs нездоровий; менш ймовірно — файлова система ОС в RO.

Виправлення: Перевірте findmnt /etc/pve на ro, прочитайте journalctl -u pve-cluster, перегляньте dmesg на предмет перемонтувань у RO.

3) Симптом: «Permission denied» тільки в GUI або автоматизації, але root по SSH може редагувати

Корінь: API-токен/користувач не має прав; або автоматизація не запускається з sudo.

Виправлення: Аудит ролей/ACL і підтвердження ідентичності. Повторіть ту саму дію через pvesh як root, щоб ізолювати шлях доступу.

4) Симптом: лише одна конфігурація ВМ не оновлюється; інші в порядку

Корінь: ВМ заблокована (backup, snapshot, migration) або існує застарілий lock-стан.

Виправлення: Перевірте статус блокування ВМ у конфігу і список задач; вирішіть фонову задачу. Уникайте ручного видалення блокувань, якщо ви не впевнені, що операція мертва і не буде відновлена.

5) Симптом: помилки почалися після перезавантаження вузла / техобслуговування

Корінь: Вузол піднявся ізольовано (відсутній VLAN trunk, правило фаєрволу, неправильний інтерфейс), тому він втратив кворум і pmxcfs перейшов у RO.

Виправлення: Перевірте інтерфейси corosync, VLAN-теги, MTU і досяжність пірів перед тим, як торкатись служб Proxmox.

6) Симптом: «No space left on device» під час запису в /etc/pve

Корінь: Коренева файловa система або іноди вичерпані; іноді це спричинено лавиною логів або спулом резервних копій.

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

7) Симптом: /etc/pve відсутній або порожній

Корінь: pve-cluster/pmxcfs не змонтовано; або монтування не виконалося під час завантаження.

Виправлення: Запустіть/відновіть pve-cluster; перевірте, чому він впав у логах. Підтвердіть, що FUSE працює і залежності служби здорові.

8) Симптом: змінна здатність запису; працює хвилину, потім падає

Корінь: кворум флапає через мережевий джиттер, невідповідний MTU, завантажені канали corosync або агресивні таймаути.

Виправлення: Стабілізуйте транспорт corosync. Зменшіть конкуренцію за мережу. Не налаштовуйте таймаути заради «швидкості» без вимірювання джиттеру під навантаженням.

Контрольні списки / поетапний план (безпечна послідовність)

Чекліст A: щойно побачили «unable to write /etc/pve/*» і хочете швидко дізнатися правду

1. Підтвердьте монтування і режим: findmnt /etc/pve. Якщо відсутнє → проблема служби/монтування; якщо ro → ймовірно кворум/pmxcfs.
2. Підтвердьте кворум: pvecm status. Якщо немає кворуму — не марнуйте час на права.
3. Підтвердьте служби: systemctl status pve-cluster corosync.
4. Перевірте логи: journalctl -u pve-cluster -u corosync --since "30 min ago".
5. Виключіть тиск на диск: df -h, df -i і dmesg на предмет перемонтувань у RO.
6. Відтворіть контрольним записом: touch /etc/pve/.diag-write-test і інтерпретуйте точну помилку.
7. Прийміть рішення: якщо втрата кворуму — виправляйте мережу/кворум. Якщо диск помер — евакуюйте вузол. Якщо це права — виправте ACL/ідентичність.

Чекліст B: якщо кворум втрачено, визначте свою операційну позицію (не імпровізуйте)

1. Це реальна мережна партіція чи просто вузол відсутній? Визначте, чи доступні пірі і чи відсутній вузол очікувано.
2. Чи є у вас більшість голосів десь ще? У 3-вузловому кластері один ізольований вузол означає відсутність кворуму; інші два ймовірно мають більшість.
3. Переважно відновлюйте конект, а не форсуйте записи. «Примус» — останній захід, бо може створити розбіжний стан.
4. Стабілізуйте мережевий шлях: перевірте VLAN, MTU, правила фаєрволу; перевірте насичення лінків corosync.
5. Після повернення кворуму: повторіть спробу запису. Не перезапускайте служби без чіткої причини.

Чекліст C: якщо це диск/повний/RO — ставтесь до цього як до інциденту з зберіганням

1. Підтвердіть стан диска: dmesg і SMART/стан RAID.
2. Якщо FS в RO через помилки: припиніть намагання «ремонтувати Proxmox». Евакуюйте навантаження, якщо можливо. Плануйте ремонт.
3. Якщо просто повний: очищайте місце безпечно (обертання логів, обріз резервних копій, видалення невикористаних ISO). Уникайте видалення стану Proxmox.
4. Перевірте служби і поведінку /etc/pve після відновлення простору. Інциденти ємності часто каскадують.

Чекліст D: якщо це права, виправляйте найменше можливе

1. Підтвердіть ідентичність і контекст виконання (id, sudo -l, ролі API-токена).
2. Не робіть рекурсивного chmod/chown /etc/pve. Це шлях до створення невідомих прав.
3. Виправляйте ролі/ACL на рівні Proxmox (користувачі, групи, ролі), а не правами файлів.
4. Перевірте, повторіть дію і підтвердіть, що аудиторські логи/таски пройшли успішно.

FAQ

1) Чому Proxmox розміщує конфігурацію кластера в /etc/pve замість бази даних?

Тому що файли — універсальний інтерфейс. Інструменти, скрипти й адміністратори можуть легко читати їх, порівнювати diff і робити бекапи. pmxcfs дає семантику «файлів», одночасно керуючи синхронізацією кластера і контролем доступу.

2) Якщо /etc/pve віртуальний, чому мій локальний диск має значення?

Тому що ОС, служби, логи і runtime-стан все одно потребують локального диска. Заповнені диски або перемонтування в RO дестабілізують служби, які тримають pmxcfs здоровим.

3) Який найшвидший спосіб відрізнити кворум від прав?

Запустіть pvecm status і зробіть нешкідливий touch під /etc/pve. «Quorate: No» або «Read-only file system» сильно вказують на кворум/pmxcfs. «Permission denied» вказує на права/ідентичність.

4) Чи можна просто перезапустити pve-cluster, щоб виправити це?

Іноді так, але це не перший крок. Якщо кворум втрачено, перезапуск pve-cluster не створить голосів з повітря. Якщо файлову систему ОС перемонтовано в RO — перезапуски не допоможуть. Читайте логи перш ніж діяти.

5) Чому GUI-файли не зберігаються, але редагування по SSH працює (або навпаки)?

Тому що GUI використовує API з власною моделлю прав і може відхилятись через ACL, навіть якщо SSH як root може писати. Або навпаки: root не може писати, бо pmxcfs в RO, а GUI показує загальну помилку запису.

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

Це крихка ідея без додаткового голосу (qdevice/witness) або готовності прийняти, що втрата одного вузла може заблокувати записи. Двовузловий кластер може працювати, але режим відмови — саме той, що ви відлагоджуєте.

7) Що насправді захищає pmxcfs, відхиляючи записи при відсутності кворуму?

Від split brain і розбіжності конфігурації: два вузли, що незалежно «успішно» оновлюють конфіг ВМ, сховища або правила firewall в ізоляції. Після з’єднання вирішення таких розбіжностей складне і іноді руйнівне.

8) Чи можу я форсувати Proxmox приймати записи без кворуму?

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

9) Що робити, якщо лише записи до конкретного шляху не вдаються, наприклад одна конфіг ВМ?

Шукайте блокування і стан задач (backup/migration/snapshot) для цієї ВМ. Глобальна відмова запису зазвичай вказує на кворум/pmxcfs; відмова на конкретному об’єкті — частіше через блокування/задачу або пошкоджений конфіг-файл.

10) Як запобігти цьому в майбутньому?

Проєктуйте для стабільності кворуму (непарна кількість голосів, надійна мережа corosync), стежте за ємністю диска (оповіщення про простір і іноди) і стандартизируйте привілеї (API-токени з явними ролями, автоматизація з правильними привілеями).

Висновок: наступні кроки, що справді запобігають повторенню

«Unable to write /etc/pve/*» — це Proxmox, який говорить, що не приймає зміни конфігурації, бо щось фундаментальне неправильно або небезпечно. Ваше завдання — швидко класифікувати відмову:

• Якщо втрата кворуму: виправляйте corosync-підключення та членство. Не боріться з pmxcfs — він вас захищає.
• Якщо диск повний або в RO: поводьтесь із цим як з інцидентом з зберіганням. Звільніть простір безпечно або евакуюйте й ремонтуйте апарат/файлову систему.
• Якщо це права: виправляйте ідентичність, ролі й ACL на рівні Proxmox. Не робіть рекурсивні chmod для «мозку» кластера.

Практичні кроки на ранок понеділка (коли ви не в інциденті):

1. Додайте моніторинг за pvecm status (кворум), здоров’ям pve-cluster і стабільністю лінків corosync.
2. Налаштуйте оповіщення за df -h і df -i для кореня і /var. Вичерпання інодів — прихований інцидент.
3. Працюйте з непарною кількістю голосів. Якщо змушені мати два вузли — додайте свідка і вважайте мережу критичною інфраструктурою.
4. Напишіть короткий внутрішній ранбук з «Швидким планом діагностики» вище. Майбутній ви має бути ліним і правильним.