外观
安全移除节点
这是集群相关操作里风险最高的一类：顺序错了会让剩余节点丢 quorum，或者留下一个"幽灵节点"长期干扰后续操作。本文严格按官方管理指南的 Cluster Manager 章节来写，任何和记忆不一致的地方，请以你当前版本的官方文档为准。
移除之前必须知道的三件事
- 被移除的节点不能以原身份直接重新加入同一个集群。 它的
/etc/pve状态和集群证书体系已经和集群"分家"，要再加入必须先重装 Proxmox VE，然后当作全新节点执行pvecm add。 - 执行
pvecm delnode前，该节点必须已经关机，并且确保它不会在这个网络上以现有配置重新上线。 官方文档明确警告：一台仍在线、或者关机后又意外用旧配置重新联网的节点，可能让集群处于损坏状态。 - 这是单向操作。没有"撤销移除"这个功能，唯一的补救是重装该节点后重新加入，原有客户机配置需要从备份恢复。
开始之前
按顺序确认这些前置条件，漏掉任何一条都可能让后续步骤失败或留下隐患：
| 步骤 | 说明 |
|---|---|
| 1. 迁走客户机 | 把这台节点上所有虚拟机和容器迁移到其他节点，或者确认它们可以直接删除 |
| 2. 备份本地数据 | 这台节点上如果有本地存储的数据（ISO、备份文件等），先备份或转移 |
| 3. 清理存储复制 | 如果这台节点参与了 ZFS 存储复制，先移除相关复制任务；留着不清理，任务会变成删不掉的僵尸配置 |
| 4. 移除 QDevice | 如果集群配了 QDevice（通常出现在两节点场景），必须先 pvecm qdevice remove 再移除节点 |
| 5. Ceph 单独处理 | 如果这台节点跑了 Ceph 组件(OSD/Monitor/Manager/MDS)，必须先把它们逐个从 Ceph 集群里移除，并确认 Ceph 集群仍然 HEALTH_OK，这部分属于集群进阶/Ceph 运维的内容，不要跳过直接删节点 |
| 6. 检查剩余 quorum | 移除后剩余节点数是否还够 quorum(见集群与高可用的投票表)，必要时先加节点再移除，不要让集群先跌破半数 |
操作步骤
以下流程对照官方 Cluster Manager 文档整理，每一步都先确认上一步的结果再继续。
1. 清空节点上的客户机和复制任务
参照上面的前置条件表逐项完成。
2.（如涉及 Ceph）先从 Ceph 里移除该节点的组件
顺序很重要：逐个销毁该节点上的 OSD，每销毁一个等 Ceph 恢复到 HEALTH_OK 再销毁下一个；再销毁它的 Manager、Monitor；最后执行 Ceph 的 crush 表清理。这部分操作依赖你的 Ceph 拓扑和冗余程度，没有把握时先在测试集群上演练一遍。
3. 关闭该节点
物理或虚拟地关机，并且确保它不会带着旧的集群配置重新联网（比如临时断开网线，或者在下一步完成前不要插电）。
这一步不能跳过或颠倒顺序
如果节点在你执行下一步 pvecm delnode 之后又带着旧配置重新上线，它会尝试以旧成员身份重新参与集群通信，可能导致集群状态混乱。先关机，确认断网，再执行下一步。
4. 在任意一个仍在集群里的节点上执行删除
sh
pvecm delnode <被移除节点名>如果提示 cs_err_not_exist 之类的错误，通常可以忽略，继续确认结果。
5. 确认结果
sh
pvecm nodes
pvecm status确认被移除节点已经不在列表里，且剩余节点 Quorate: Yes。
6. 清理残留
- 到
/etc/pve/nodes/<被移除节点名>/确认没有还需要保留的内容后，删除这个目录。 - 检查HA 资源与 affinity 规则，把提到这台节点的规则清理掉。
- 从
/etc/pve/priv/authorized_keys删除该节点对应的密钥条目。
应急手段：pvecm expected——只在真正卡住时使用
不是常规步骤，只在 delnode 因剩余节点丢失 quorum 而失败时使用
正常流程走到第 4 步时，剩余节点应该还有 quorum。如果因为某些原因（比如同时有多台节点不可用）导致剩余节点在执行 delnode 前就已经丢失 quorum，官方文档给出的临时手段是：
sh
pvecm expected 1这条命令会强行告诉 corosync"现在只需要 1 票就算有 quorum"，让只剩一台在线节点的集群重新变成可写状态，以便完成 delnode。
风险：执行期间集群失去了正常的"多数票"保护，如果此时还有其他节点在别的网络分区里独立运行，可能出现两边都"自认为有 quorum"并各自写入配置的情况（脑裂），事后难以合并。
前置条件：确认之前失联的节点确实已经下线、不会再突然出现在网络里，才能安全地这样做。
回退方式：这个值不需要手动"改回去"——移除节点后集群的 Expected votes 会随着 pvecm delnode 重新计算。操作期间不要做加节点、加存储等其他集群级别的变更，完成 delnode 后立刻用 pvecm status 确认票数恢复正常。
不要把 pvecm expected 1 当作日常操作的一部分，也不要在文档或脚本里把它写成"常规步骤"——它只用于官方文档描述的这一种应急场景。
检查结果
pvecm nodes不再列出被移除的节点。pvecm status里Expected votes/Total votes与剩余节点数一致。- Web UI 左侧树不再显示该节点。
- 之前依赖该节点的 HA 规则、存储复制任务都已经清理或调整完毕。
常见问题
Web UI 里还能看到已经删除的节点（幽灵节点）。 检查 /etc/pve/nodes/ 下是否还有该节点的目录残留，清理掉并刷新页面。
想把同一台服务器重新加回集群。 不能直接 pvecm add——需要先重装 Proxmox VE，当作全新节点处理。用相同 IP/主机名重装后加入时如果遇到 SSH 指纹报错，在新节点上执行一次 pvecm updatecerts。
移除节点后 HA 资源报错或卡在 error 状态。 检查HA 资源与 affinity 规则里是否还引用了这台已被移除的节点，清理相关规则。
不确定当前 Ceph/QDevice/复制状态是否已经清理干净。 停下来，先分别核对这三项前置条件，不要为了赶进度直接执行 delnode——这是本文开头强调的高风险操作，宁可多花时间确认。