PVE集群升级实战：零停机滚动升级与跨集群迁移完整指南

Proxmox VE (PVE) 集群从8.x版本升级到9.x版本时，可能会遇到升级失败导致虚拟机失联、跨集群迁移数据丢失、业务连续性要求高等挑战。本文基于官方文档和一线运维经验，系统介绍三种升级路径，详细解析滚动升级步骤，并提供跨集群迁移的实用方案。

一、3 条升级路径评估与选择

（按停机时间从短到长、风险从低到高排序）

1. 滚动升级——高可用集群的优选方案

   • 停机时间：约等于单节点重启时间
   • 风险等级：★☆☆
   • 核心思路：逐节点迁空虚拟机→升级节点→回迁业务，确保集群法定票数始终在线。
   • 适用场景：生产环境高可用集群，要求业务零中断。

2. 并行新集群——资源充足的平滑过渡方案

   • 停机时间：仅虚拟机/容器迁移瞬间
   • 风险等级：★★☆
   • 核心思路：全新部署9.x集群，通过在线或离线迁移将业务移至新集群，旧集群随后下线。
   • 适用场景：预算充足，可部署新硬件，追求纯净的系统环境。

3. 备份-重装-还原——简单稳妥的基准方案

   • 停机时间：整个集群业务停止
   • 风险等级：★★★
   • 核心思路：使用Proxmox Backup Server进行全量备份，全新安装9.x系统，然后一键还原备份。
   • 适用场景：测试环境、小规模集群或对系统清洁度有极高要求。

二、滚动升级详细操作流程

0️⃣ 升级前预检
执行命令 pve8to9 --full，彻底检查并解决所有告警项，确保升级清单无遗留问题。

1️⃣ 全面备份
使用 Proxmox Backup Server 对全部虚拟机、容器及关键配置文件进行一次全量备份。同时，建议使用 tar 命令额外备份 /etc/pve 和 /etc/network/interfaces 等核心配置目录。

2️⃣ 迁移非主节点业务

• 若使用共享存储（如NFS、Ceph），可直接执行在线迁移：qm migrate --online --with-local-disks。
• 若使用本地存储，需先将虚拟磁盘迁移至共享存储：qm move-disk，然后再执行在线迁移。

3️⃣ 升级节点系统
在清空的节点上执行：apt update && apt full-upgrade -y，完成后重启节点，并通过 pveversion 确认已成功升级至9.x。

4️⃣ 验证集群状态
节点重启后，运行 pvecm status 检查集群版本一致性、节点状态及投票权是否正常。确认无误后，再对下一个节点重复步骤2-4。

5️⃣ 最后升级主节点
将集群主节点安排在最后升级，以避免集群管理IP地址在升级期间发生不可控的漂移。

6️⃣ Ceph 用户特别注意
如果集群中使用 Ceph 作为存储后端，升级顺序至关重要：必须先升级 Ceph（例如从 Reef 升级至 Squid），命令为 ceph orch upgrade，然后再升级 PVE 节点，顺序颠倒可能导致存储服务异常。

三、跨集群迁移关键技术方案

场景一：源与目标集群共享存储（NFS/Ceph）

• 命令：qm migrate --online --targetstorage <共享存储名>
• 前提：目标集群PVE版本不低于源集群，且网络需放通SSH（22）和PVE API（8006）端口。

场景二：将本地磁盘虚拟机迁移至异地集群

• 步骤：
  1. 关闭虚拟机：qm shutdown
  2. 迁移虚拟磁盘至共享存储：qm move-disk scsi0 <共享存储名>。此操作会将本地磁盘卷复制到共享存储。
  3. 执行在线迁移：qm migrate。此时虚拟机配置与磁盘均已在目标集群。
• 要点：通过move-disk先将本地盘转为“共享盘”，是实现跨集群在线迁移本地盘虚拟机的关键。

场景三：离线备份与还原迁移

• 导出备份：在源集群执行 vzdump --mode stop --storage backup-server 生成离线备份文件。
• 导入还原：在目标集群使用 qmrestore vzdump-qemu-xxx.vma.zst 命令还原虚拟机。
• 效率参考：千兆内网环境下，迁移1TB数据约需30分钟。此方法也支持通过USB 3.0移动硬盘等物理介质进行迁移。

四、故障处理与回滚指南

五、核心要点总结

1. 首选滚动升级：在条件允许的情况下，采用逐节点滚动升级策略，最大限度保障业务连续性。
2. 次选并行迁移：若资源许可，搭建新集群并行迁移是风险可控的平滑过渡方式，旧集群可保留作为应急备份。
3. 底线是充分备份与测试：无论选择哪种方案，升级前必须使用 pve8to9 脚本进行预检，并完成可靠的全量备份，必要时在测试环境进行演练。