Ця помилка з’являється в найгірший момент: ви перезавантажили вузол (або він перезавантажився сам), і кластер відчуває себе «напівживим».
pve-cluster поводиться некоректно, /etc/pve порожній або доступний лише для читання, а логи corosync постійно повторюють:
cannot initialize CMAP service.
Це один з тих випадків у Proxmox, де з голосом виступають сховище, мережа і розподілені системи. Якщо слухати лише одну сторону,
ви нічого не виправите і вивчите нові нецензурні слова. Нижче — промисловий чекліст: спочатку швидка діагностика, потім системна ізоляція, потім безпечне відновлення.
Що насправді означає “cannot initialize CMAP service”
CMAP — це внутрішня конфігураційна та runtime key-value база corosync. Уявіть її як «інтерфейс спільної пам’яті кластера» для налаштувань і стану:
ідентифікатори вузлів, членство в кільці, біти кворуму, таймінги totem, логування та інше. Коли процес каже, що він cannot initialize CMAP service, він не може
підключитися до CMAP API corosync — зазвичай тому, що corosync не запущений, завис, перезавантажується або його IPC-сокети недоступні.
У кластерах Proxmox це зазвичай проявляється наступними сценаріями:
- Corosync не працює →
pve-clusterне може читати членство →/etc/pveповодиться дивно. - Corosync не може сформувати кільце (мережа/MTU/фаєрвол) → немає кворуму → файлову систему кластера може бути змонтовано лише для читання або не змонтовано.
- Несумісна конфігурація corosync або неправильне ім’я/IP вузла → corosync стартує, але не може приєднатися до пірів → CMAP недоступний для залежних демонів.
- Зсув часу або сильні затримки планувальника → тайм-аути токенів → флопи членства → споживачі CMAP періодично падають.
Практичний переклад: сприймайте помилки CMAP як «corosync недостатньо здоровий, щоб надавати runtime-стан кластера». Спочатку виправте corosync,
потім pmxcfs, і лише потім торкайтеся вищих сервісів Proxmox.
Швидка діагностика (перший/другий/третій)
Перший: вирішіть, чи це проблема кластера або одного вузла
Найшвидший успіх — знати, чи налагоджуєте ви локальний збій демона чи розділення мозку / кворум. Запустіть ці три команди на зламаному вузлі та на одному здоровому вузлі (якщо є).
cr0x@server:~$ systemctl is-active corosync pve-cluster
inactive
active
Сенс: Якщо corosync inactive/failed, помилки CMAP — симптом, а не хвороба.
Якщо corosync активний, але споживачі все ще скаржаться, шукайте проблеми кільця/кворуму/конфігурації.
Рішення: Виправляйте corosync перш за все. Не перезапускайте pvedaemon, pveproxy або випадкові служби «подивитися, що станеться».
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 18
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Thu Dec 25 12:07:21 2025
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000001
Ring ID: 1.52
Quorate: No
Сенс: «Quorate: No» — ваш заголовок. Без кворуму pmxcfs може відмовлятися від записів і деякі операції кластера не працюватимуть.
Рішення: Визначте, чи відсутні вузли справді вимкнені, ізольовані мережею чи неправильно сконфігуровані. Не форсуйте кворум необдумано.
cr0x@server:~$ journalctl -u corosync -b --no-pager | tail -n 40
Dec 25 12:05:12 pve1 corosync[1789]: [TOTEM ] A processor failed, forming new configuration.
Dec 25 12:05:14 pve1 corosync[1789]: [KNET ] link: host: 2 link: 0 is down
Dec 25 12:05:18 pve1 corosync[1789]: [QUORUM] Members[1]: 1
Dec 25 12:05:18 pve1 corosync[1789]: [QUORUM] This node is within the non-primary component and will NOT provide any services.
Сенс: Класичне розділення мережі або мертвий пир. KNET каже, що лінк вниз.
Рішення: Забудьте про CMAP і почніть думати про мережу corosync: маршрутизацію, VLAN, MTU, фаєрвол, стан лінку.
Другий: доведіть, що шлях мережі кластера чистий (не «пінгується»)
Corosync у старих налаштуваннях використовує multicast, а в сучасних Proxmox — unicast (knet), зазвичай поверх UDP із суворими таймінгами.
Одна фаєрвол-правило, асиметрична маршрутизація або невідповідність MTU можуть тримати ICMP улюбленим, поки corosync тихо горить.
cr0x@server:~$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eno1 UP 10.10.10.11/24
eno2 UP 172.16.20.11/24
Сенс: Визначте інтерфейс(и), які реально повинен використовувати corosync. Багато кластерів виділяють NIC/VLAN для corosync — поки хтось не «спростив» це.
Рішення: Порівняйте з /etc/pve/corosync.conf (або локальною копією, якщо pmxcfs не здоровий) і перевірте, чи адреса кільця відповідає реальності.
Третій: підтвердіть стан pmxcfs і чи ви застрягли в режимі лише для читання
cr0x@server:~$ mount | grep -E '/etc/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)
Сенс: Якщо цей примонт відсутній, застарілий або лише для читання, Proxmox поводитиметься так, ніби має амнезію.
Рішення: Якщо corosync зламався, pmxcfs може не змонтуватися або змонтуватися, але відмовлятися від записів. Не редагуйте /etc/pve без коректного монтованого стану.
Цікаві факти та історичний контекст (чому так відбувається)
- Назва Corosync походить від «coros», старої проєктної лінії, пов’язаної з груповою комунікацією і членством у кластері — це десятиліття «шрамів» розподілених систем.
- CMAP замінив ранні підходи до конфігурації, щоб демони могли читати і реагувати на стан кластера через консистентний API замість повторного парсингу файлів.
- Протокол Totem (який використовує corosync) призначений для збереження впорядкованої доставки повідомлень і членства незважаючи на відмови — відмінно, коли система здорова, безжально, коли таймінги йдуть не так.
- Proxmox обрав FUSE-базований кластерний файловий простір (
pmxcfs) для швидкого розповсюдження невеликого конфігураційного стану, а не як загальноцільове сховище даних. - pmxcfs зберігає «авторитетну» конфігурацію кластера в SQLite/DB файлах під
/var/lib/pve-cluster/;/etc/pve— змонтований перегляд, а не оригінальна директорія джерела. - Правила кворуму походять з класичної безпеки консенсусу: краще відмовити у записах, ніж прийняти конфліктні оновлення, які потім не можна буде зрозуміло примирити.
- knet transport став стандартним шляхом для поліпшення обробки лінків і можливостей мульти-лінку порівняно з давнішими мультикаст-орієнтованими патернами.
- Багато «проблем corosync» — це насправді проблеми часу: членство на основі токенів дуже чутливе до джиттера, голодування CPU та стрибків часу.
Corosync + CMAP + pmxcfs: складові, які ви налагоджуєте
Corosync: членство, повідомлення, кворум
Corosync — це рушій членства кластера. Він вирішує, хто всередині, хто поза, і наскільки він упевнений у цьому твердженні.
Його конфігурація знаходиться в corosync.conf. Його runtime-стан відкритий через CMAP. Якщо corosync не може працювати або стабілізувати членство, все вище нього
стає декоративним.
CMAP: інтерфейс runtime-стану
CMAP — це місце, де corosync надає конфігурацію та стан клієнтам. Компоненти Proxmox і інструменти corosync звертаються до нього.
Коли ви бачите «cannot initialize CMAP service», клієнт не зміг підключитися до runtime-інтерфейсу corosync — часто через IPC-сокети.
Ось чому помилка може з’являтися навіть на одно-вузловому «кластері» після оновлення або проблем з правами/SELinux/AppArmor (рідко на Proxmox), або після аварії, що лишила застарілі сокети.
pmxcfs: кластерний файловий простір Proxmox
pmxcfs — це FUSE-файлова система, змонтована в /etc/pve. Тут Proxmox очікує глобальні конфіги кластера:
визначення сховищ, конфіг файрволу, конфіги VM, конфіг кластера, realms користувачів. Вона залежить від corosync для рішень про членство і кворум.
Якщо corosync вимкнено або ви не маєте кворуму, pmxcfs може:
- не змонтуватися зовсім, залишаючи
/etc/pveяк порожню директорію або застарілий монт, - змонтуватися лише для читання, через що записи зазнаватимуть помилок,
- змонтуватися, але показувати тільки локальний стан вузла, якщо ви ізольовані, залежно від способу відмови.
Перефразована думка від Werner Vogels (CTO Amazon): Все ламається, весь час; будуйте системи, які цього очікують і швидко відновлюються.
Жарт №1: Corosync — як запрошення на зустріч. Якщо половина учасників не може підключитися, ніхто не може редагувати порядок денний.
Практичні завдання (команди, очікуваний вивід, рішення)
Це ті завдання, які я реально виконую, коли хтось у Slack пише «CMAP service» о 02:00. Кожне включає, що означає вивід і яке рішення робити далі.
Виконуйте їх спочатку на зламаному вузлі, потім порівнюйте зі здоровим, якщо є.
Завдання 1: Перевірка стану сервісів і останніх збоїв
cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
Active: failed (Result: exit-code) since Thu 2025-12-25 12:01:03 UTC; 4min ago
Docs: man:corosync
Process: 1732 ExecStart=/usr/sbin/corosync -f $COROSYNC_OPTIONS (code=exited, status=1/FAILURE)
Сенс: Corosync не працює; помилки CMAP очікувані.
Рішення: Йдіть одразу до логів і перевірки конфігурації. Не перезапускайте все підряд; виправляйте перший доміно-камінь.
Завдання 2: Читати логи corosync із контекстом, а не лише останній рядок
cr0x@server:~$ journalctl -u corosync -b --no-pager -n 200
Dec 25 12:00:58 pve1 corosync[1732]: [CFG ] Parsing config file '/etc/corosync/corosync.conf'
Dec 25 12:00:58 pve1 corosync[1732]: [CFG ] No valid name found for nodeid 1
Dec 25 12:00:58 pve1 corosync[1732]: [MAIN ] Corosync Cluster Engine exiting with status 8 at main.c:1835.
Сенс: Невірна конфігурація: відображення nodeid або nodelist неправильне.
Рішення: Перевірте nodelist, імена вузлів та адреси кільця. Ще не чіпайте налаштування кворуму; у вас детермінована помилка конфігурації.
Завдання 3: Підтвердіть, яку corosync.conf ви реально використовуєте
У здоровому кластері канонічна конфігурація зазвичай знаходиться під /etc/pve/corosync.conf (вид файлової системи кластера), а corosync читає
/etc/corosync/corosync.conf, яке зазвичай є симлінком у /etc/pve. Коли pmxcfs зламаний, цей симлінк може вказувати в нікуди.
cr0x@server:~$ ls -l /etc/corosync/corosync.conf /etc/pve/corosync.conf
lrwxrwxrwx 1 root root 17 Dec 25 11:58 /etc/corosync/corosync.conf -> /etc/pve/corosync.conf
-rw-r----- 1 root www-data 512 Dec 25 11:57 /etc/pve/corosync.conf
Сенс: Симлінк правильний і файл існує в /etc/pve.
Рішення: Якщо /etc/pve/corosync.conf відсутній або недоступний для читання, треба відновити його з локальних DB файлів кластера або з бекапу.
Завдання 4: Перевірте синтаксис конфігурації corosync
cr0x@server:~$ corosync -t
Parsing of config file successful
Сенс: Синтаксис в порядку. Це не доводить, що конфіг правильний; воно лише доводить, що парситься.
Рішення: Якщо парсинг падає, виправляйте синтаксис перед будь-якими іншими діями. Якщо парс успішний — фокусуйтеся на семантиці: IP, node IDs, лінки, crypto, MTU.
Завдання 5: Перевірте членство і стан кворуму через інструменти Proxmox
cr0x@server:~$ pvecm status
Cluster information
-------------------
Name: prod-cluster
Config Version: 18
Transport: knet
Quorum information
------------------
Nodes: 3
Node ID: 0x00000001
Quorate: Yes
Сенс: Якщо це повертає чисто і каже quorate, CMAP ймовірно функціонує, і ваша помилка могла виникнути через сервіс, що стартував занадто рано.
Рішення: Якщо corosync здоровий, перемикайтеся на pmxcfs і порядок старту сервісів; перевірте логи pve-cluster.
Завдання 6: Запитуйте runtime corosync прямо через інструменти CMAP
cr0x@server:~$ corosync-cmapctl | head
runtime.config.totem.token (u32) = 3000
runtime.config.totem.token_retransmits_before_loss_const (u32) = 10
runtime.config.totem.consensus (u32) = 3600
runtime.totem.pg.mrp.srp.members (str) = 1 2 3
Сенс: Якщо це працює, CMAP доступний. Якщо воно падає з помилкою ініціалізації CMAP, corosync недоступний через IPC.
Рішення: Якщо CMAP недоступний, але corosync показує «active», підозрюйте проблеми з правами/сокетами, застарілий runtime-каталог або циклічні рестарти.
Завдання 7: Перевірте runtime-сокети corosync і права
cr0x@server:~$ ls -ld /run/corosync /run/corosync/* 2>/dev/null | head
drwxr-xr-x 2 root root 80 Dec 25 12:06 /run/corosync
srwxrwx--- 1 root root 0 Dec 25 12:06 /run/corosync/corosync.sock
srwxrwx--- 1 root root 0 Dec 25 12:06 /run/corosync/cmap.sock
Сенс: Сокети існують. Якщо сокети відсутні, клієнти CMAP не можуть підключитися. Якщо права надто суворі, клієнти не-root можуть зазнати збою.
Рішення: Відсутні сокети → corosync фактично не працює або завис на ранній стадії. Дивні права → перевірте цілісність пакета та локальні жорсткі налаштування.
Завдання 8: Підтвердіть здоров’я примонту pmxcfs і повідомлення про помилки
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:03:11 UTC; 3min ago
Main PID: 2011 (pmxcfs)
Сенс: pmxcfs працює, але він все ще може бути лише для читання через відсутність кворуму.
Рішення: Перевірте кворум і безпечно протестуйте запис (створіть тимчасовий файл у безпечному місці, наприклад /etc/pve/nodes/<node>/, якщо доречно).
Завдання 9: Виявити файлову систему кластера лише для читання (без здогадок)
cr0x@server:~$ touch /etc/pve/.ro-test
touch: cannot touch '/etc/pve/.ro-test': Read-only file system
Сенс: pmxcfs змонтований, але відмовляє в записах. Зазвичай це відповідає відсутності кворуму або локальному режиму захисту.
Рішення: Відновіть кворум (переважно) або використайте контрольований тимчасовий оверрайд кворуму лише якщо ви дійсно є єдиним живим вузлом і погоджуєтеся на ризик.
Завдання 10: Перевірте зсув часу і стан NTP
cr0x@server:~$ timedatectl status
Local time: Thu 2025-12-25 12:08:30 UTC
Universal time: Thu 2025-12-25 12:08:30 UTC
RTC time: Thu 2025-12-25 12:08:29
System clock synchronized: yes
NTP service: active
Сенс: Добре. Якщо годинник не синхронізований або стрибає, таймінги corosync швидко псуються.
Рішення: Якщо несинхронізовано — виправте NTP/chrony/systemd-timesyncd. Потім перезапустіть corosync для стабілізації членства.
Завдання 11: Перевірте мережевий шлях і MTU (бо «ping працює» бреше)
cr0x@server:~$ ping -M do -s 1472 -c 3 172.16.20.12
PING 172.16.20.12 (172.16.20.12) 1472(1500) bytes of data.
1480 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.352 ms
1480 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.339 ms
1480 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.347 ms
Сенс: PMTU для 1500-байт фреймів в порядку. Якщо це падає, але менший ping працює — у вас проблеми MTU/фрагментації.
Рішення: Вирівняйте MTU на комутаторах, бондах, VLAN і NIC. Corosync/knet не любить мовчазних чорних дір фрагментації.
Завдання 12: Перевірте правила фаєрволу, що часто ламають corosync мовчки
cr0x@server:~$ pve-firewall status
Status: enabled/running
cr0x@server:~$ iptables -S | grep -E 'corosync|5405|5404|knet' | head
Сенс: Proxmox firewall увімкнено. Corosync з knet зазвичай використовує UDP і динамічні порти; старі версії corosync використовували UDP 5405 за замовчуванням.
Порожній grep не доводить, що трафік дозволено; це просто означає, що правила не підписані явно (що часто буває).
Рішення: Якщо ви нещодавно увімкнули фаєрвол, явно дозволіть трафік кластера на виділеній мережі corosync. Також перевірте мережеві фаєрволи поза Proxmox-інструментами.
Завдання 13: Проінспектуйте статус лінку corosync і досяжність пірів
cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
id = 172.16.20.11
status = ring 0 active with no faults
Сенс: Локальне кільце активне. Якщо показує faults або down — у вас проблема на рівні лінку або невірні bindnetaddr/адреси кільця.
Рішення: Якщо кільце хворе — перевірте, що мережа правильна, VLAN-тегінг, і що IP-адреси пірів відповідають фізичній топології.
Завдання 14: Шукайте split brain / множинні розділення
cr0x@server:~$ pvecm nodes
Membership information
----------------------
Nodeid Votes Name
1 1 pve1 (local)
2 1 pve2
Сенс: Видно лише два вузли. Якщо ви чекали три — можливо один вузол вимкнений або є розділення.
Рішення: Якщо вузол назавжди зник, видаліть його коректно (після того, як стабілізуєтеся). Не тримайте мертвий вузол у конфігу «на всякий випадок».
Завдання 15: Перезапуск corosync (тільки після наявності гіпотези)
cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl is-active corosync
active
Сенс: Перезапуск пройшов успішно. Одразу перевірте кворум і доступ до CMAP.
Рішення: Якщо сервіс скаче між active/failed — ви в циклі падінь; поверніться до логів і валідації конфігу. Не перезапускайте постійно — це лише трясе систему.
Завдання 16: Перевірте логи pve-cluster для підказок, специфічних для pmxcfs
cr0x@server:~$ journalctl -u pve-cluster -b --no-pager | tail -n 60
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: cpg_initialize failed: 2
Dec 25 12:03:12 pve1 pmxcfs[2011]: [status] notice: retrying in 1 seconds
Dec 25 12:03:18 pve1 pmxcfs[2011]: [status] notice: resolved node name 'pve1' to '172.16.20.11'
Сенс: pmxcfs не може ініціалізувати свою групову комунікацію (CPG), зазвичай тому, що corosync не готовий або членство нестабільне.
Рішення: Розглядайте це як ще один сигнал «спочатку corosync здоров’я». Виправте кільце/кворум, і pmxcfs перестане скаржитися.
Завдання 17: Перевірте стабільність резолюції імен вузла та відповідність corosync конфігу
cr0x@server:~$ hostname -f
pve1.prod.example
cr0x@server:~$ getent hosts pve1
172.16.20.11 pve1.prod.example pve1
Сенс: Hostname резолюється у очікуваний IP кластера. Якщо він одного дня повертає management-мережу, а іншого — storage, corosync матиме проблеми.
Рішення: Зафіксуйте правильні записи в DNS або в /etc/hosts для імен кластера; уникайте «розумного» DNS, що повертає різні адреси залежно від джерела.
Завдання 18: Якщо потрібно працювати без кворуму (контрольовано, тимчасово)
Тут ви можете зробити ще гірше з упевненістю. Робіть це лише якщо ви дійсно є єдиним живим вузлом і вам потрібен доступ до конфігів для відновлення робочих навантажень. Як тільки кластер здоровий — відміняйте це.
cr0x@server:~$ pvecm expected 1
expected votes set to 1
Сенс: Ви сказали кластеру очікувати 1 голос, що може відновити стан quorate на самотньому вузлі.
Рішення: Використайте це, щоб розблокуватися, а не працювати довго. Якщо «відсутній» вузол повернеться несподівано, ви опинитеся у зоні конфліктних істин.
Жарт №2: Форсування кворуму — як робити податки з допомогою флактора. Може спрацювати, але пізніше відчуватимете запах.
Поширені помилки: симптом → причина → виправлення
1) Симптом: “cannot initialize CMAP service” і corosync «active»
- Причина: corosync скаче (restarting), або IPC-сокети під
/run/corosyncвідсутні/мають неправильні права. - Виправлення: Перевірте
journalctl -u corosync -bна цикли падіння; перевірте існування сокетів; перевстановіть/відремонтуйте пакети corosync при потребі; виправте семантику конфігу.
2) Симптом: /etc/pve порожній, і UI Proxmox показує дивності типу «node has no valid subscription»
- Причина: pmxcfs не змонтований (FUSE mount відсутній), часто тому, що
pve-clusterвпав або corosync недоступний. - Виправлення: Почніть з перевірки стану corosync, потім перезапустіть
pve-cluster. Перевірте монт черезmount | grep /etc/pve.
3) Симптом: pmxcfs змонтований, але лише для читання; touch файли не працюють
- Причина: відсутність кворуму або ізольований вузол у непріоритетній компоненції.
- Виправлення: Відновіть мережеве з’єднання/кворум. Якщо втрата вузла постійна — видаліть мертвий вузол правильно і повторно встановіть кворум. Тимчасовий обхід:
pvecm expected 1лише якщо ви дійсно ізольовані і плануєте це ретельно.
4) Симптом: Corosync падає з помилками nodeid/name після зміни IP
- Причина: corosync конфіг все ще посилається на старі адреси кільця; hostname резолюється в інший IP, ніж той, що в
nodelist. - Виправлення: Оновіть записи nodelist ring0_addr (в авторитетній конфігурації кластера), вирівняйте DNS/hosts і перезапустіть corosync на всіх вузлах у контрольованому порядку.
5) Симптом: Все працює до резервного копіювання або міграцій, потім corosync скаче
- Причина: голодування CPU, IO wait або насичення мережі, що призводить до тайм-аутів токенів. Corosync чутливий до таймінгу; ваша мережа може «здаватися» нормальною, поки навантаження не підніметься.
- Виправлення: Перемістіть трафік corosync на тихішу мережу/VLAN; вирівняйте MTU; зарезервуйте CPU (уникайте оверсубскрипшн на хості); перевірте проблеми з бондами/драйверами NIC.
6) Симптом: Після перезавантаження кластер не формується; логи згадують «wrong authkey»
- Причина: mismatched
authkeyміж вузлами, часто через часткове відновлення або неправильне ручне копіювання. - Виправлення: Синхронізуйте corosync authentication key між вузлами з відомого хорошого джерела, потім перезапустіть corosync скрізь.
7) Симптом: Одновузловий кластер все ще показує помилки CMAP
- Причина: локальна служба corosync не працює; це не «кластерна» проблема. Часті причини: зламана конфігурація файлу, пошкоджений стан пакета, збій диска або права.
- Виправлення: Перевірте конфіг, впевніться, що runtime-директорії існують, перевірте стан диска та логи, перевстановіть corosync при потребі.
Три короткі історії з практики
Коротка історія 1: Інцидент через хибне припущення
Середня компанія мала чистий три-вузловий Proxmox кластер. «Чистий» тут означає, що він працював часто настільки, що ніхто не нервував.
Під час рутинного вікна змін інженер оновив записи DNS, щоб стандартизувати імена: pve1, pve2, pve3 тепер резолювалися у management-мережу,
а не в мережу corosync. Припущення здавалось безпечним: «імена мають вказувати на primary інтерфейс».
Corosync не погодився. Після першого перезавантаження вузла corosync запустився, спробував прив’язатися і оголоситися на одній мережі, тоді як інші вузли очікували іншої.
З’явилися тайм-аути токенів, кворум скакав, і pmxcfs став лише для читання саме в момент, коли йшла міграція VM.
Міграція провалилася так, що виглядало ніби пошкодження сховища — бо UI не міг коректно зафіксувати оновлення конфігів.
Виправлення не було магічним. Вони зафіксували розв’язування імен кластера в /etc/hosts для імен, які використовує corosync, щоб pve1 завжди мапився на адресу кільця.
Також перестали використовувати «загальні» імена для мульти-мережевих кластерів; ввели явні імена для трафіку кластера і для management-трафіку.
Це було нудно. Працювало. Головний урок був психологічним: зміни в DNS — це інфраструктурні зміни, а не «просто чистка».
Коротка історія 2: Оптимізація, що дала зворотний ефект
Інша команда мала виділений VLAN для corosync і вирішила «оптимізувати», поєднавши його зі storage VLAN, щоб зменшити складність комутаторів.
Їхня storage-мережа була 10GbE і загалом стабільна. Припущення: швидша мережа = щасливіший corosync.
Вони також увімкнули jumbo frames на storage-мережі — бо сховище це любить.
Через місяць вони почали бачити періодичні повідомлення «cannot initialize CMAP service» під час ночей бекапів.
Не постійно; лише інколи, достатньо, щоб створити плутанину. Corosync не був повністю згаслим, але флапав членство на кілька секунд,
що достатньо, щоб pmxcfs клієнти кинули помилки і люди почали панікувати.
Причиною була невідповідність MTU через пару транковой портів і конфіг бонда на одному вузлі. ICMP-пінги працювали, бо вони були малі.
Storage-трафік в основному працював, бо TCP перезапускав і «потужував» помилки. Corosync, яке використовує UDP і припущення про таймінги, постраждало.
«Оптимізація» створила режим відмови, який не існував, коли corosync мав маленьку, тиху, контрольовану мережу.
Ремедіація була розділити трафік corosync назад на виділений VLAN зі строгим MTU=1500 end-to-end і обмежити шумні broadcast-домени.
Їм не потрібна була швидша мережа. Потрібна була передбачувана.
Коротка історія 3: Нудна, але правильна практика, що врятувала день
Фінансова організація керувала чотиривузловим Proxmox кластером. Ніякої героїки. Але в них була одна практика, що виглядала старомодною: після кожної зміни кластера
(додавання/видалення вузлів, зміни IP, налаштування corosync) вони архівували знімки /etc/pve і /var/lib/pve-cluster на кожному вузлі,
і вели короткий журнал змін з таймштампами та «чому».
Одного ранку кореневий розділ одного вузла отримав помилки. Вузол перезавантажився, corosync впав, потім pmxcfs, і /etc/pve виглядав неправильно.
On-call не почав гадати. Вони порівняли локальний архівований corosync конфіг з поточним, побачили, що поточний файл був обрізаний,
і негайно запідозрили локальне пошкодження диска, а не «кластерну дивність».
Вони відновили вузол чисто, знову приєднали його з відомо-правильною конфігурацією кластера і повернули сервіси без погіршення кворуму.
Правильна практика не була гламурною. Вона скоротила час на прийняття рішень, коли все виглядало підозріло.
Чеклісти / покроковий план
Чекліст A: Стабілізувати corosync спочатку (робіть це перед тим, як чіпати pmxcfs)
-
Підтвердіть здоров’я сервісів.
cr0x@server:~$ systemctl is-active corosync activeРішення: Якщо не active, читайте логи і виправляйте конфіг/мережу перед усім іншим.
-
Перевірте, що конфіг парситься.
cr0x@server:~$ corosync -t Parsing of config file successfulРішення: Помилка парсингу означає зупинитися і виправити синтаксис, а не «спробувати ще раз перезапустити».
-
Перевірте адреси кільця і резолюцію імен.
cr0x@server:~$ grep -E 'ring0_addr|name|nodeid' -n /etc/pve/corosync.conf | head -n 40 12: name: pve1 13: nodeid: 1 14: ring0_addr: 172.16.20.11Рішення: Якщо IP кільця відсутній на хості — вирівняйте цю невідповідність перед продовженням.
-
Перевірте статус кільця і помилки.
cr0x@server:~$ corosync-cfgtool -s Printing ring status. Local node ID 1 RING ID 0 id = 172.16.20.11 status = ring 0 active with no faultsРішення: Faults вказують на MTU/фаєрвол/маршрутизацію/VLAN. Йдіть туди, а не в UI Proxmox.
-
Підтвердіть, що CMAP доступний для запитів.
cr0x@server:~$ corosync-cmapctl totem.cluster_name totem.cluster_name (str) = prod-clusterРішення: Якщо запит CMAP не працює — corosync не здоровий. Розв’язуйте це перед pmxcfs.
Чекліст B: Безпечно відновити кворум
-
Перевірте стан кворуму.
cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Node ID' Nodes: 2 Node ID: 0x00000001 Quorate: NoРішення: Якщо «No», ідентифікуйте відсутніх голосуючих і чи вони справді досяжні.
-
Перевірте досяжність пірів по мережі corosync (не management).
cr0x@server:~$ ping -c 3 172.16.20.12 PING 172.16.20.12 (172.16.20.12) 56(84) bytes of data. 64 bytes from 172.16.20.12: icmp_seq=1 ttl=64 time=0.301 ms 64 bytes from 172.16.20.12: icmp_seq=2 ttl=64 time=0.287 ms 64 bytes from 172.16.20.12: icmp_seq=3 ttl=64 time=0.294 msРішення: Якщо ping падає — виправляйте мережу. Якщо ping успішний — все одно перевірте MTU і фаєрвол.
-
Тільки якщо вузол остаточно мертвий: плануйте видалення, не панікуйте і не видаляйте наосліп.
cr0x@server:~$ pvecm nodes Membership information ---------------------- Nodeid Votes Name 1 1 pve1 (local) 2 1 pve2 3 1 pve3Рішення: Підтвердіть, який вузол мертвий і чому. Якщо він може повернутися — ремонтуйте його замість видалення.
-
Тимчасовий режим виживання (тільки для одного вузла): встановіть expected votes.
cr0x@server:~$ pvecm expected 1 expected votes set to 1Рішення: Використайте це, щоб отримати доступ до конфігів та відновити ОС. Скасуйте, як тільки нормальний кворум відновлено.
Чекліст C: Повернути pmxcfs у санний змонтований стан
-
Перевірте примонт.
cr0x@server:~$ mount | grep /etc/pve pve-cluster on /etc/pve type fuse.pve-cluster (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other)Рішення: Відсутній монт означає, що
pve-clusterне працює; дивіться його логи і здоров’я corosync. -
Перезапустіть pmxcfs лише після стабілізації corosync.
cr0x@server:~$ systemctl restart pve-clusterРішення: Якщо він одразу помиляється з CPG/CMAP помилками — ви ще не закінчили з corosync.
-
Перевірка здоров’я: перелік директорій вузлів.
cr0x@server:~$ ls -1 /etc/pve/nodes pve1 pve2 pve3Рішення: Відсутні вузли можуть означати партицію, відсутність кворуму або невідповідність конфігурації. Порівняйте з
pvecm nodes.
FAQ
1) Чи є “cannot initialize CMAP service” багом Proxmox?
Зазвичай ні. Це сигнал про стан corosync. Proxmox його показує, тому що компоненти Proxmox залежать від runtime-стану corosync. Виправте underlying corosync
service/ring/quorum і помилки CMAP зазвичай зникнуть.
2) Чи можна просто перезапустити все: corosync, pve-cluster, pvedaemon, pveproxy?
Можна, але це як перезавантажити датчик диму, щоб загасити кухонну пожежу. Перезапуск corosync без розуміння причин може призвести до сильного флапання членства,
що ускладнить pmxcfs, UI і API ще більше.
3) Чому /etc/pve поводиться як порожній або лише для читання?
Бо це FUSE-монт, який надає pmxcfs. Якщо pmxcfs не змонтований — ви бачите просто папку. Якщо немає кворуму — pmxcfs може змонтуватися, але відмовляти в записах.
Завжди перевіряйте монт і стан кворуму перед редагуванням чого-небудь.
4) Який найбезпечніший порядок перезапуску сервісів?
Corosync першим (але лише після перевірки конфігу/мережі). Потім pve-cluster. Потім UI/API демони (pveproxy, pvedaemon) якщо вони некоректні.
Починати зверху — марнувати час.
5) Чи потрібен multicast для corosync?
Більшість сучасних Proxmox кластерів використовують knet transport (unicast). Multicast був поширений історично, але часто блокується або погано підтримується в корпоративних мережах.
Не гонись за multicast, якщо ваша конфігурація його явно не використовує.
6) Чи безпечно форсувати кворум з pvecm expected 1?
Це інструмент, а не спосіб життя. Воно може бути безпечним у реальній одно-вузловій ситуації виживання, коли ви розумієте, що відключаєте правила безпеки,
щоб повернути керованість. Небезпечно, якщо інші вузли можуть все ще бути живими і записувати конфліктні конфіги.
7) Чи можуть проблеми зі сховищем викликати помилки CMAP?
Опосередковано — так. Якщо хост у сильному IO wait (пошкоджений завантажувальний диск, перевантажений ZFS пул, насичений CEPH OSD на тому самому вузлі),
corosync може пропустити таймінги, членство флапає, і CMAP-клієнти падають. Corosync не жалкує про ваші графіки затримок.
8) Що робити, якщо я змінив IP-адреси мережі кластера?
Чекайте болю corosync, поки всі nodelist у corosync.conf і резолюція імен на кожному вузлі не узгоджуються. Часткові зміни викликають асиметричне членство.
Плануйте зміну IP як міграцію: оновіть конфіг послідовно, перевірте MTU, фаєрвол і перезапускайте у контрольованому порядку.
9) Чому після перезапуску все працює якийсь час, а потім знову падає?
Це класично для проблем таймінгу або мережевого джиттера: тайм-аути токенів, MTU-чорні діри під навантаженням, голодування CPU під час бекапів. Також це може свідчити про флапаючий лінк
(bonding, LACP, порти комутатора). Шукайте закономірності: «падає під навантаженням» — не випадковість.
10) Як зрозуміти, чи це партиція чи мертвий вузол?
Порівняйте вивід pvecm nodes на декількох вузлах. Якщо різні вузли бачать різне членство — у вас партиція.
Якщо всі здорові вузли погоджуються, що певний вузол відсутній і він недоступний по мережі corosync — ймовірно, він мертвий або ізольований.
Висновок: наступні кроки без створення другого інциденту
Коли Proxmox викидає «cannot initialize CMAP service», не сприймайте це як загадковий настрій Proxmox. Це corosync каже, що не може надати
стабільний runtime-стан. Ваше завдання — стабілізувати кільце, відновити кворум, і лише потім чекати коректної роботи pmxcfs і UI.
Практичні наступні кроки:
- Пройдіть швидку діагностику: стан сервісів → кворум → мережа/MTU кільця → стан примонту pmxcfs.
- Збирайте доказову базу до перезапусків: логи corosync, статус кільця, запит CMAP і стан синхронізації часу.
- Виправляйте нудні причини першими: невідповідність IP/імен, MTU, правила фаєрволу та зсуви часу.
- Якщо доводиться форсувати кворум — робіть це свідомо, документуйте і скасуйте, щойно з’явиться можливість.
- Після відновлення заплануйте hardening: виділена мережа corosync, консистентна резолюція імен і надійні бекапи конфігів.