外观
集群失去 quorum
适用范围
Web UI 报权限或写入错误、节点之间互相显示离线、/etc/pve 下的文件改不动，pvecm status 里 Quorate 显示 No。
不适用于单纯"某个节点在 Web UI 里显示灰色离线，但集群整体仲裁正常"的情况——那更可能是时间不同步或主机名解析问题，见下面的分流说明。
开始排查前
先搞清楚仲裁 (quorum) 解决的是什么问题：集群里多个节点共享同一份配置（/etc/pve），需要保证任意时刻只有一个"多数派"分区能修改它，否则两边各自改出不同的配置，合并不回来，这就是脑裂 (split-brain)。
失去 quorum 时，PVE 会把 /etc/pve 变成只读，这是设计如此，不是故障——目的正是防止脑裂。理解这一点后再往下看，能避免病急乱投医。
开始排查前，先确认这不是网络对称的问题
如果是两部分节点还能各自跟一部分节点通信、只是整体连不上"多数派"，先不要做任何强制改动仲裁票数的操作。这种情况下强行让两边都达到"仲裁"，就是在制造脑裂。往下看完排查步骤，先定位到底是哪种情况。
排查步骤
第一步：确认仲裁状态和票数
sh
pvecm status重点看这几行：
Quorate：Yes/No，当前是否有仲裁。Expected votes：集群预期的总票数，通常等于节点数（每节点默认 1 票，加上 QDevice 的话再加相应票数）。Total votes：当前实际能联系上、参与计票的票数。Quorum：达到仲裁所需的最小票数（通常是Expected votes的多数）。
Total votes 明显小于 Expected votes 时，说明有节点掉线或者网络分区。
第二步：区分"节点真的挂了"还是"网络问题"
sh
# corosync 链路状态
corosync-cfgtool -s
# corosync 日志
journalctl -u corosync -n 100 --no-pager
# 逐个节点测试延迟和连通性（用 corosync 走的那个网络）
ping <其他节点的 corosync 网络 IP>| 现象 | 方向 |
|---|---|
| 能 ping 通其他节点，但 corosync 报超时/丢包 | 网络抖动、延迟过高（官方建议节点间延迟稳定在 5 毫秒以内），或者 corosync 和其他流量抢带宽 |
| ping 不通任何其他节点 | 这台节点自己的网络接口或交换机端口有问题 |
| 部分节点之间能通、部分不能 | 网络分区，是最需要谨慎处理的情况——继续往下看，不要急着改票数 |
其他节点 Web UI 显示离线，但 pvecm status 显示 quorum 正常 | 通常是时间不同步（timedatectl）或 /etc/hosts 解析问题，不是仲裁问题 |
第三步：修网络，而不是先改票数
绝大多数失去 quorum 的场景，根因是网络：交换机故障、网线松动、corosync 没有独立链路和其他流量抢带宽、防火墙规则误拦了 corosync 端口。
先按第二步的结果处理网络层面的问题。网络恢复后，quorum 通常会自动恢复，不需要任何手动干预：
sh
# 网络修好后，重新确认
pvecm status第四步：真正只剩你能确认的时候，pvecm expected 才是选项
pvecm expected 只能作为有明确前置条件的应急手段
pvecm expected <N> 会临时修改集群计算仲裁所需的票数，让当前能联系上的这部分节点凑够"多数"，从而恢复 /etc/pve 的可写状态。
它不检查、也无法检查你的判断是否正确。 如果你的前提错了——比如你以为已经宕机的节点其实还在运行、只是网络暂时分区——这条命令会导致两个分区同时认为自己拥有仲裁，各自都能写 /etc/pve，这就是脑裂。脑裂之后两边的配置无法自动合并，通常意味着丢失一部分改动，最坏情况需要手动比对甚至重建集群配置。
只有同时满足以下条件才可以使用：
- 你能物理确认（不是猜测）掉线的节点确实关机或者已经损坏，短时间内不会再上线参与仲裁。
- 你已经处理完第二、三步，确认这不是可以修复的网络问题。
- 你清楚一旦判断错误，代价是集群配置的脑裂和潜在数据丢失，并且愿意承担这个风险来换取继续操作剩余节点的能力。
影响范围：命令执行后，/etc/pve 立即变为可写，本节点及能联系上的节点上的所有配置改动都会生效。如果掉线的节点之后重新上线，需要人工核对配置差异，必要时以健康分区的配置为准覆盖掉重新上线节点的旧配置。
回退方式：网络或掉线节点恢复正常后，重启 corosync 服务或直接重启涉及的节点，让集群按正常方式重新协商票数，不需要再手动改回来。如果期间发生了脑裂（两边都被临时改过票数并各自写入），需要人工比对哪边的配置是最新、最正确的，再决定以哪边为准。
命令示例（仅在满足以上前提后使用，<N> 填你判断出的、当前应该参与计票的节点数）：
sh
pvecm expected <N>官方文档给出的典型场景是：需要在失去 quorum 的节点上修改 /etc/pve/corosync.conf 本身（比如永久移除一个已确认报废的节点）时，用 pvecm expected 1 让当前节点先恢复可写，改完配置或者从已知正常的备份恢复配置后，再重新评估集群状态——这仍然是一个需要你先确认物理情况的操作，不是常规排查手段。
确认恢复
pvecm status里Quorate: Yes，Total votes恢复到等于Expected votes。- 能正常创建、修改虚拟机和容器配置，Web UI 不再报权限或只读错误。
- 所有节点在 Web UI 里都显示在线。
- 如果期间用过
pvecm expected，掉线节点重新上线后，人工核对它上面的配置和当前集群是否一致，处理可能的冲突。
仍未解决
按如何有效求助准备：
sh
pveversion -v
pvecm status
cat /etc/pve/corosync.conf加上 corosync-cfgtool -s 和 journalctl -u corosync 的相关片段。涉及是否使用过 pvecm expected 请如实说明，这对判断当前配置状态很重要。