从 PVE 8 升级到 9

这篇只讲 PVE 8 → 9 这一次大版本升级的具体流程。小版本更新的节奏、重启前后的通用检查已经在更新与大版本升级里写过，这里不重复，只补充 8 到 9 这一步特有的细节：官方检查工具、软件源格式变化、Ceph 的前置要求，以及升级失败之后现实的退路。

PVE 8.4 的支持期已于 2026-08 结束，还停留在 8.x 的环境应当规划升级。

这是一次发行版升级，期间宿主机整机不可用

• 影响范围：升级过程中该节点上所有虚拟机和容器都需要提前关闭，宿主机本身在 apt dist-upgrade 执行期间状态不稳定，不接受新的管理操作。集群环境里未升级的节点在此期间可以继续对外服务，但正在升级的这一台会短暂离线。
• 前置条件：当前已是 PVE 8.4 最新小版本；备份已经过恢复演练验证；有物理控制台或带外管理（IPMI）作为网络中断时的后路；根分区有足够空闲空间；预留以小时计的时间窗口。
• 怎么回退：大版本升级基本没有「回退」这回事。Debian 不支持整体降级，卡在升级中途通常只能继续排查修复；如果修复不了，现实的退路是用 PVE 9 的安装介质重装，再从验证过的备份恢复所有客户机。这也是为什么备份验证要排在前置条件的第一位。

前提条件清单

开始之前，逐条确认：

条件	说明
已在 8.4 最新版	pveversion 显示的版本号是当前 8.4 分支里最新的，不能从更早的 8.0/8.1 直接跳到 9
Ceph 已在 Squid（19.2）	只对跑 Ceph 超融合的环境适用：先升到 Squid，再升 PVE 本体，顺序不能反
备份已验证	不是「有备份任务」，是最近做过一次恢复演练
带外访问或物理控制台	只有 SSH 时，先在同型号的非生产硬件或虚拟机上完整演练一遍
根分区空闲空间充足	升级要下载和解压大量包，df -h / 确认留了几个 GB 到十几个 GB 余量
时间窗口充足	按小时预留，不是按分钟
/etc/pve 已归档	参考备份宿主机配置

Ceph 集群不能直接跳级

Proxmox 官方要求超融合 Ceph 环境先把 Ceph 从 Quincy 升到 Reef，再从 Reef 升到 Squid（19.2），确认 ceph --version 和集群健康状态都正常之后，再开始 PVE 本体从 8 到 9 的升级。跳过这一步、直接升级 PVE 本体，是已知会出问题的路径。

第一步：跑官方检查工具

# 宿主机 shell
pve8to9 --full

输出分三类：

• PASS —— 没问题。
• WARN —— 需要你看一眼、理解影响。
• FAIL —— 必须先解决，不能继续升级。

它会检查几十项内容：包版本是否过旧、LVM/LVM-Thin 共享卷是否开着自动激活（有已知问题，官方提供了修复脚本 /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation）、集群仲裁状态、存储状态等。

反复跑，直到没有 FAIL

每处理完一项就重新跑一次 pve8to9 --full，升级前、软件源换好之后、升级过程中，都建议再跑一遍确认状态。这个工具只报告问题，不会自动帮你修。

第二步：关闭客户机

在单机环境，建议把这个节点上所有客户机正常关闭，而不是指望在线升级：

for id in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do qm shutdown $id; done
for id in $(pct list | awk 'NR>1 && $2=="running" {print $1}'); do pct shutdown $id; done
qm list; pct list

确认全部停止后再继续。集群环境可以先把重要的客户机迁移到还没升级的节点上（8 升到 9 方向的迁移官方支持；反方向「一般不受支持」，不要在升级中途把客户机从 9 迁回 8）。

第三步：切换软件源

具体路径与内容以官方页面为准

下面只列出结构性的变化，不提供整段可以直接复制执行的换源脚本——写死的代号和路径过一段时间就会过时，照抄旧文章的换源命令是升级失败的常见原因之一。操作前对照官方 Wiki「Upgrade from 8 to 9」页面当时的最新内容逐条核对。

结构上会发生这些变化：

1. Debian 基础源里的代号从 bookworm 改成 trixie。
2. PVE 自己的源改用 deb822 格式（.sources 后缀，Types/URIs/Suites/Components/Signed-By 分字段写），企业源和无订阅源分别对应新的 .sources 文件，旧的 .list 文件要同步移除或注释掉，避免新旧源重复导致冲突。
3. 如果启用了 Ceph 仓库，同样要切到新的代号对应的 Ceph 源（Squid 分支），并移除旧的 ceph.list。

换完执行：

apt update

确认没有 404 或签名错误。有 401 报错（企业源需要有效订阅）的话，先检查订阅状态。

apt modernize-sources 可以辅助转换

它能把旧格式的 .list 文件转换成新的 deb822 .sources 格式，并保留 .list.bak 备份，可以作为参考，但转换结果仍然要人工核对代号和组件名是否正确。

第四步：执行升级

apt dist-upgrade

过程中会问配置文件冲突

常见的几处，供参考（不代表你的系统一定会遇到）：

• /etc/lvm/lvm.conf、/etc/ssh/sshd_config：没有特殊自定义的话，选维护者的新版本。
• /etc/issue：不影响功能，保留哪个都行。
• /etc/default/grub：改过启动参数的话保留自己的版本，升级完确认参数依然有效。

拿不准时选查看差异（通常有个 D 选项），看完再决定。

这个过程可能持续很久，建议在 tmux 或 screen 会话里执行，SSH 断线不会中断进程：

tmux new -s upgrade
# 断线后重连
tmux attach -t upgrade

第五步：复查、重启并验证

再跑一次检查工具，确认没有残留的 FAIL：

pve8to9 --full
reboot

重启后逐项确认：

pveversion -v
systemctl --failed
pvesm status
ip -4 addr show
qm list; pct list

浏览器访问 Web UI 前先强制刷新（Ctrl+Shift+R）或清缓存，避免旧版本的静态资源缓存导致界面异常。逐台启动客户机并验证，不要一次全开，先开不重要的那台。

集群环境：一个节点一个节点来

集群没有强制的节点顺序，但过程中会短暂处于 8 和 9 混合的状态：

• 每次只升级一个节点，这台节点走完整套流程（前提条件 → 检查 → 停机 → 换源 → 升级 → 重启 → 验证）之后，再对下一个节点重复。
• 混合版本期间如果迁移遇到问题，从 8 那台节点的 GUI 发起操作。
• 等所有节点都升级到 9 之后，旧的 HA 组 (HA Groups) 会自动转换成新的 affinity 规则，可以用 journalctl -eu pve-ha-crm 确认转换过程没有报错。

升级失败时的现实情况

没有「一键回退」这回事

升级卡在中途通常是某个包的依赖冲突，多数情况下 apt -f install 或根据报错手动处理能继续走完。如果系统已经进入无法修复的状态：

唯一现实的退路是重装 + 恢复备份：用 PVE 9 的安装介质重新装这台机器，然后从验证过的备份把客户机一台台恢复回来。Debian 大版本之间不支持整体降级，也没有官方的「一键回退到 8」流程。这也是为什么升级前必须先做过恢复演练，而不是升级失败之后才第一次尝试恢复。

检查结果

检查项	命令
版本号正确	pveversion -v
没有失败的服务	systemctl --failed
存储都在线	pvesm status
网络配置正常	ip -4 addr show
客户机能正常开机	逐台 qm start / pct start，检查网络和磁盘
集群仲裁正常（集群环境）	pvecm status

常见问题

升级过程中断网了。 这是带外访问/物理控制台作为前置条件的原因——没有它，网络中断意味着升级过程完全失控。

升级完某些自定义配置消失或失效了。 检查升级过程中「配置文件冲突」环节选择了保留哪个版本；被替换成维护者版本的自定义配置需要重新应用。

PCI 直通或某个内核相关功能升级后不工作。 官方已知问题列表里提到部分场景需要固定使用某个内核版本，具体以官方 Wiki 当时的「已知问题」章节为准，不要凭旧经验下结论。

Ceph 集群升级后状态异常。 确认 Ceph 是先升到 Squid、再进行的 PVE 本体升级，顺序反了是常见故障原因。

参考资料

• Upgrade from 8 to 9（官方 Wiki，升级流程与已知问题的权威来源）
• 更新与大版本升级
• 恢复演练
• Proxmox VE 9.0