给已有业务的 PVE 增加一个集群节点

Checo2026/9/19大约 7 分钟

给已有业务的 PVE 增加一个集群节点

第一台 PVE 已运行域控、ASR、监控等服务，第二台是新装空机。我希望统一管理、保留手动迁移能力，并让现有业务继续运行。2026 年 9 月 19 日，两台机器成功组成集群；没有配置 HA 资源，QDevice 也尚未部署。

这次最重要的操作并不是 pvecm add 本身，而是确定由哪台创建、哪台加入，以及用什么证据证明来宾没有重启。

先分清四件事

组件	作用
PVE 集群 / pmxcfs	分发配置、统一管理
Corosync / Knet	成员关系和集群通信
QDevice	帮助仲裁，提供外部投票
PVE HA	对显式纳入管理的资源执行故障恢复

本次没有启用 HA，创建集群不会自动搬走 VM。两台都有 local-lvm，也不表示它们共享磁盘。

已有业务的节点创建，空节点加入

加入集群会替换加入节点的 /etc/pve 配置，所以方向必须明确：

pve（已有 VM/LXC）创建集群 → pve2（空节点）加入

不能让已有业务节点加入空机创建的集群。检查加入节点的 qm list、pct list、虚拟磁盘、旧 Corosync 配置和任务状态，发现来宾或旧集群状态就先处理，不用 --force 绕过。

本次还检查了已安装版本的 PVE::Cluster::Setup::assert_joinable()，结果 JOINABLE_OK。这是版本内部接口的补充证据，不能替代官方加入流程或视为稳定 API。

预检比补救更便宜

实际记录中，两台 PVE Manager 分别为 9.2.2 和 9.2.20，Join API 兼容检查通过。它只说明本次组合可以加入，不保证任意跨版本组合安全；长期仍应统一受支持版本。

预检覆盖：唯一主机名/IP、稳定名称解析、NTP、MTU、无备份/迁移/升级任务、来宾无 lock/pending，以及双向 TCP 22/8006、UDP 5405–5412。管理 LAN 的十次探测约 1.2 ms、无丢包，这是小样本，不是长期网络 SLA。

Corosync 对延迟和抖动敏感，未来大量磁盘迁移不能长期与它争用链路。Proxmox 集群文档源码

保存配置之外，还要记 PID 与运行时间

先备份 VM/LXC 定义、存储和任务配置，并验证归档。配置备份不是来宾磁盘备份，域控另有既有 vzdump 归档。

基线	创建、加入后比较什么
配置 SHA-256	VM/LXC 配置及 storage/jobs 等文件是否改变
运行进程 PID	是否仍是同一个 QEMU/LXC 进程
uptime	是否持续增长
服务探针	DNS、LDAP、SMB、ASR、监控是否仍可用

仅凭控制台显示 running 不够：来宾重启后仍会显示 running。PID、uptime 和配置联合比较，再加业务验收，才能支持本次连续运行的结论。

创建、加入与短暂仲裁窗口

以下为现场命令的示例化写法。地址属于文档网段，运行前必须替换，SSH 加入路径需先建立并验证节点间授权：

# 已有业务的节点
pvecm create lab-pve --link0 address=192.0.2.10

# 完全空的加入节点
pvecm add 192.0.2.10 \
  --link0 address=192.0.2.20 --use_ssh 1

创建后曾短暂出现 Cannot initialize CMAP service。最终服务恢复、单节点 Quorate，不能只凭第一次状态查询判定失败：

systemctl status corosync pve-cluster
journalctl -u corosync -u pve-cluster --since '10 minutes ago'
pvecm status
corosync-quorumtool -s

加入时，节点列表先变成两台，第二台稍后启动 Corosync。第一台约五秒失去 quorum，随后恢复 2/2 投票。期间来宾未停止，但这说明加入有真实状态转换：若空节点无法完成加入，管理配置可能持续只读。

最终验收结果

两台均报告：

Nodes:          2
Expected votes: 2
Total votes:    2
Quorum:         2
Flags:          Quorate

Link 0 connected、管理服务 active、配置哈希不变、运行实例 PID 不变、uptime 增长。AD 复制摘要中三台域控各为 0 / 10 failures；ASR、Firecrawl、Prometheus 和 macOS SSH 探针通过。

第二台能看到第一台来宾的集群配置视图，但本地来宾目录仍为空，没有复制磁盘。这些检查证明了本次组建结果，不构成日后任何变更都无中断的保证。

配置同步与来宾连续性要用不同证据验收

/etc/pve 是集群配置视图，不是 VM 磁盘共享目录。加入后在第二台看到 VM 定义，是控制平面的结果；要启动或迁移来宾，还得具备所需磁盘、网络和设备。相同 storage ID 只是一项配置名称，不能代替逐节点检查 volume 是否存在。

可以在变更前后各保存一次只读清单，再对比。以下命令在各自节点执行，输出留在受限审计目录：

pvecm nodes
pvesm status
qm list
pct list
qm pending 101
qm config 101
pvesh get /nodes/pve/qemu/101/status/current --output-format json

节点名和 VMID 是示例，空节点不能对并不存在的本地运行 VM 照抄状态查询。配置哈希不变只证明所选文件不变；来宾 PID 相同也不能单独证明来宾内部没重启。实际验收应加入 Windows boot time/Linux uptime、进程连续性和应用探针，注明探针窗口。短时 DNS/LDAP 查询正常，不证明所有客户端请求从未失败。

这次约五秒仲裁变化是管理层事件，来宾连续运行证据是另一层。不要把二者合并为“集群加入完全没有影响”。后续若发现管理任务只读而 VM 还活着，先看 quorum 和 pmxcfs，别为了解开配置把正在运行的来宾全部重启。

故障与回退应在创建之前讨论

加入尚未完成时，先查看两端 Corosync/pve-cluster 日志、地址、时间、链路与实际节点投票，避免同时重建两台的配置。已形成集群后，删除节点、清理残余配置和恢复磁盘引用会影响控制平面，不能当作撤销一个普通 UI 操作。

场景	判断重点	不应直接执行的“快捷修复”
一节点离线，另一台来宾仍运行	仲裁、来宾归属、断联还是关机	无确认地强制改 expected votes
网络分区，两台都可独立访问	是否可能双边操作同一资源	两边同时强制恢复写入
第二台缺磁盘，能看到 VM 配置	存储存在性、迁移方式与设备依赖	认为集群已自动复制磁盘
加入失败且管理配置只读	两端日志、集群成员与恢复路径	强行覆盖 /etc/pve

当前没有 QDevice 和 HA，下一轮规划必须分开验证第三票、节点故障、网络分区、存储可达和业务恢复时间。第三票不能让丢失的本地盘突然可用；迁移测试也不能代替故障接管测试。这些没有在原记录执行的部分应保留为后续验收，不能通过补几条命令改写成已完成。

两节点集群仍需解决仲裁

当前两台各一票，共两票，多数要求两票。一台离线后只剩 1/2。在没有 HA 的本次部署里，已运行的来宾通常继续运行，但配置修改、启动和迁移会受仲裁限制。

QDevice 应放在独立故障域，不能靠这两台 PVE 上的一台 VM 承担唯一第三票。它改善仲裁，不提供共享存储，也不代替备份和 HA 资源配置。本次只完成规划，没有部署或做断网、关机故障演练。

接下来把第二台域控部署到 PVE2，可改善物理故障隔离；具体替换与功能验收见域控接管旧 IP 实战。这依然不会自动补上集群第三票。

本文日期采用主 KB 首次 Git 提交日期 2026-09-19（UTC+8），提交 eee5a4c。操作与评测时间在正文单独注明；写作期间未连接或修改生产设备。