Короткий ответ

Без quorum pmxcfs (/etc/pve) становится read-only: GUI полуживой, qm не пишет конфиги. Лечение — вернуть голоса живых узлов и сеть corosync, не запускать одни и те же VMID на двух разделах кластера. pvecm expected снижает ожидаемые голоса: это аварийный рычаг, не «чтобы GUI сохранился».

Снимите pvecm status на каждом узле, который ещё слушается, до любых expected.

Симптомы и как отличить

Типичная картина:

  • баннер no quorum;
  • pvecm status: Quorate: No;
  • файлы в /etc/pve не сохраняются;
  • HA не переезжает или наоборот дёргается.

Отличия:

Что видноКуда
Один узел offline, кворум естьУзел выпал
GUI 8006 refusedpveproxy
Миграция fails при живом quorumМиграция
Два узла, оба думают что они единственныеsplit-brain — этот текст

Возможные причины

  1. Упала сеть corosync (отдельный ring или тот же vmbr0).
  2. Большинство узлов выключены/не грузятся.
  3. Рассинхрон времени, токены totem.
  4. После неудачного pvecm expected забыли вернуть.
  5. Разный corosync.conf на узлах.
  6. Firewall режет UDP порты кластера.

Диагностика

На pve1 и на pve2:

pveversion
pvecm status
pvecm nodes
systemctl status corosync pve-cluster --no-pager
journalctl -u corosync -b --no-pager | tail -n 50

Смотрите Expected votes, Total votes, Quorate, IP кольца.

grep -E 'ring|bindnet|nodelist' /etc/pve/corosync.conf
ip -br addr

Если /etc/pve уже RO, читайте /etc/corosync/corosync.conf (локальная копия).

Проверка сети кольца (подставьте адрес кластерного линка):

ping -c 3 10.0.10.12

Решение

Сценарий A. Сеть моргнула, узлы живы

Почините L2/L3 corosync, firewall UDP 5405–5412 (классические порты corosync в документации PVE). Когда ping/knet жив, quorum часто возвращается сам. Не expected.

Сценарий B. Узлы действительно мертвы, остался один

  1. Зафиксируйте: BMC показывает power off, не «сеть отвалилась на минуту».
  2. Shared disks: убедитесь, что мёртвые узлы не держат VM.
  3. Только тогда, понимая риск:
pvecm expected 1
pvecm status
  1. Когда узлы вернутся: верните expected к норме (число голосов кластера), не оставляйте 1 навсегда.

Документируйте в заявке, кто принял решение.

Сценарий C. Split уже случился

Не merge конфигов руками. Остановите VM на одном из разделов, разберитесь, кто писал в shared LUN. Это инцидент целостности, не «restart corosync на обоих».

Сценарий D. QDevice

Для двух узлов — внешний qdevice. Настраивается заранее, не во время аварии как первая мысль, если его не было.

Сценарий E. pmxcfs

После quorate:

systemctl restart pve-cluster
ls /etc/pve/qemu-server/101.conf

Не копируйте 101.conf scp между узлами как замену кластеру.

Как читать votes и почему 2-node особенный

pvecm status : Nodes: 2, Quorum: 2, Flags: Quorate — норма для двух узлов без qdevice пока оба живы. Падение одного даёт Non quorate. Это ожидаемо. QDevice даёт третий голос.

pvecm status
corosync-quorumtool -s
cat /etc/pve/corosync.conf

corosync-quorumtool дублирует картину votes. Расхождение с pvecm — повод смотреть, не запущен ли второй corosync/старый конфиг.

HA VM при потере кворума не должны стартовать «на всякий случай». Если стартовали — проверьте qm list на обоих разделах сети. Shared LUN с двумя writer — порча ФС гостя, дальше не migrate, а restore.

После аварийного pvecm expected 1 верните expected, когда второй узел online: иначе один узел продолжает работать при ситуации, когда второй уже жив и тоже пишет. Это и есть split-brain window.

Не используйте pvecm expected чтобы обойти read-only /etc/pve во время планового reboot соседа: для 3-node reboot одного узла кворум сохраняется сам.

Как проверить, что проблема устранена

pvecm status
ls -l /etc/pve/nodes
qm config 101

Quorate: Yes. Сохранение описания VM в GUI проходит. Все ожидаемые узлы в pvecm nodes. HA consistent. Expected votes снова штатные. Нет двух running одной VM на разных узлах (qm list на каждом).

Зафиксируйте в заявке: число узлов, есть ли QDevice, где ring IP, кто принял expected. Без этого через месяц никто не знает, почему кластер живёт с expected=1. После возврата соседа выполните pvecm status на всех узлах, не только на pve1: картина votes должна совпасть. Если на одном узле quorate, на другом нет — сеть knet всё ещё порвана, GUI вас обманывает кэшем.

Не поднимайте HA-группу, пока не сверили, что VMID 101 running только где надо.

Если не помогло

  • Quorate Yes, GUI всё ещё RO: pve-cluster fuse, рестарт службы на узле.
  • Голоса не те: забытый expected.
  • Corosync flapping: MTU, Wi-Fi между площадками, асимметрия.
  • После обновления несовместимость пакетов — добейте апдейт поузлово, не expected.
  • Три узла, один в «странном» состоянии: не включайте его в сеть, пока не разберёте диск VM.

Профилактика

  • Три узла или два + QDevice.
  • Отдельная сеть corosync.
  • Мониторинг pvecm status / quorate.
  • Запрет expected без runbook.
  • Health-check перед патчем.

FAQ

Чем quorum отличается от «узел offline»?

Offline при живом большинстве — кворум есть, правите один узел. Нет большинства — кворума нет.

pvecm expected 2 на трёх узлах?

Меняет ожидаемые голоса. Любой expected — осознанный. Не копируйте числа с форумов.

Можно ли править VM без кворума?

Чтение часто да, запись cfg нет. Не обходите bind-mount RO.

HA при no quorum?

HA не должен стартовать VM вслепую. Если стартовал — проверяйте split.

Нужен ли multicast?

PVE 8 использует corosync с kronosnet (unicast-ориентированный knet). Не чините «multicast IGMP» как первый шаг, пока corosync.conf не показывает, что вы на старой схеме.

Достаточно ли systemctl restart corosync на всех узлах вместо разбора votes?

Нет. Массовый рестарт может сам уронить кворум. Сначала сеть и pvecm status по узлам. Restart — точечно, когда knet уже должен работать.