中文 English

PVE 8 升 9 别硬刚：一句话交给 Agent，或者按这份清单手工升级

发布时间: 2026-05-12
ProxmoxVE PVE Proxmox VE 9 Debian Trixie Homelab Agent Codex Claude OpenClaw HermesAgent 运维

先说结论

Proxmox VE 8 升级到 9 的本质不是“复制几条命令”，而是一次 Debian Bookworm 到 Trixie、PVE 8.4 到 PVE 9.x、内核与存储网络组件一起变化的系统升级。最省时间的方式，是把检查、备份核对、日志记录、命令执行和升级后验证交给 Codex、Claude、OpenClaw、HermesAgent 这类 Agent；但涉及重启、仓库切换、包删除提示、配置文件覆盖提示时，仍然必须由人确认。想完全手工做也没问题，本文后半部分给出一套可以逐步执行的人工升级清单。

这篇文章写给两类人：一类是已经习惯让 Agent 管理机器，想用一句话把 PVE 8 到 9 的升级流程交给工具跑完；另一类是更喜欢自己敲命令，希望有一份顺序清楚、风险点明确、可以照着核对的手工操作稿。

文中所有主机名、地址、仓库、token、账号都使用占位符，不包含任何真实内网信息。请把 <PVE_NODE>、<BACKUP_TARGET>、<ADMIN_CONSOLE> 这类内容替换成你自己的环境。生产环境升级前，请以 Proxmox 官方文档为准，并先确认备份可以恢复。

PVE 8 到 9 升级路线图

图 1：不管是 Agent 执行还是人工执行，路线都一样：备份、升到 PVE 8.4 最新、跑 pve8to9、切到 Trixie 源、dist-upgrade、重启验证。

1. 为什么 PVE 8 升 9 不能当成普通小版本更新

PVE 8 到 9 不是点一下“更新”这么简单。PVE 8 基于 Debian 12 Bookworm，PVE 9 基于 Debian 13 Trixie；官方升级文档也明确把它当作需要计划、备份、测试和人工确认的 major upgrade。它会影响包源、内核、服务、存储工具、网络组件、Ceph 版本以及部分 HA 行为。

如果你是单节点 Homelab，风险主要集中在三处：升级中断、升级后不能启动、某些虚拟机或容器因为老系统、老 cgroup、直通设备或驱动兼容性而异常。如果你是集群，风险会再多一层：节点升级顺序、迁移方向、Ceph 版本、HA 规则迁移、共享 LVM 自动激活策略，都需要提前看清楚。

所以本文不建议“看到别人一行命令成功，就直接在自己机器上复制”。更稳的思路是把升级拆成几个可验证的关口：

  1. 备份是否存在，并且真的做过恢复验证。
  2. 所有节点是否已经升级到 PVE 8.4 最新小版本。
  3. pve8to9 --full 是否跑过，警告是否理解并处理。
  4. apt 源是否完整从 bookworm 切到 trixie，没有混入旧源。
  5. apt dist-upgrade 是否没有试图移除 proxmox-ve 这类关键包。
  6. 重启后是否进入 PVE 9 内核，服务、存储、网络和虚拟机是否正常。

这些步骤人可以做，Agent 也可以做。区别不在技术路线，而在谁负责打字、记录、复查和提醒。

2. 一句话交给 Agent：适合什么，不适合什么

Agent 辅助升级与人工升级的区别

图 2：Agent 适合处理重复检查、命令编排和日志记录；人仍然要负责授权、维护窗口、备份恢复和异常决策。

如果你已经在使用 Codex、Claude、OpenClaw、HermesAgent 或其他能 SSH 到目标机器的 Agent，可以直接给它一个范围清楚的任务。关键是不要只说“帮我升级 PVE”，而要把边界、停顿点和验收条件说清楚。

可以直接复制下面这段提示词：

请通过 SSH 登录 <PVE_NODE>，协助把 Proxmox VE 8 升级到 Proxmox VE 9。
要求：
1. 先只做只读兼容性检查，不要修改系统：收集 pveversion、apt 源、磁盘空间、集群状态、Ceph 状态、pve8to9 --full 输出、关键服务状态和备份位置。
2. 用官方 Proxmox VE 8 to 9 升级文档作为依据，列出必须处理的 warning 和风险点。
3. 在我明确确认前，不允许改 apt 源、不允许执行 dist-upgrade、不允许 reboot。
4. 确认后按步骤升级：先升到 PVE 8.4 最新，再切换 bookworm 到 trixie，再 apt update，再 apt dist-upgrade。
5. 任何提示会移除 proxmox-ve、pve-manager、pve-kernel、qemu-server、pve-cluster 等关键包时立即停止并汇报。
6. 升级后重启，并验证 pveversion、systemctl、journalctl、存储状态、网络状态、VM/CT 状态和 Web UI。
7. 全程不要输出真实公网或内网地址、token、密码、密钥；最终只给脱敏总结和可复现命令记录。

这段提示词的重点不是“让 Agent 更聪明”，而是让 Agent 不要越权。升级这类任务最怕两个极端：一个是 Agent 只会聊天，不真正检查；另一个是 Agent 太主动，看到命令就一路执行。上面的提示把任务拆成只读检查、人工确认、执行升级、重启验证四段，每一段都有停顿点。

如果你的 Agent 支持计划、审批或工具权限，建议再加三条规则：

  1. apt dist-upgrade 前必须展示将安装、升级、删除的关键包摘要。
  2. 配置文件冲突时必须先展示 diff，再由人选择保留当前版本或安装维护者版本。
  3. 重启前必须确认有可用的独立管理通道，例如物理控制台、IPMI、KVM、宿主机外部 console，或者至少确认 SSH 中断后可以恢复。

Agent 能节省大量时间：它可以替你跑十几条检查命令、整理 pve8to9 输出、比较 apt 源、记录升级日志、重启后回连验证。但是 Agent 不能替你承担业务影响。有没有维护窗口、备份能不能恢复、某个虚拟机能不能停、某块直通设备是否影响关键业务，这些还是人负责。

3. 升级前准备：先把退路准备好

PVE 官方文档把有效且经过测试的备份放在升级前提里，这一点不要省。很多人说“我有备份”，实际意思是“备份任务显示成功”；但真正升级前要确认的是：备份文件在外部存储上、能被新系统看到、至少抽样恢复过一台 VM 或 CT。

建议准备这几类内容：

  1. 所有 VM/CT 的外部备份，目标可以是 PBS、NAS、远端存储或可离线保存的位置。
  2. /etc 里关键配置的备份，尤其是 /etc/pve、/etc/network/interfaces、/etc/resolv.conf、用户和认证相关配置。
  3. 当前 pveversion -v、apt policy、pvesm status、qm list、pct list、ip addr、ip route 的输出快照。
  4. 如果是集群，记录 pvecm status、ha-manager status、Ceph 健康状态和节点升级顺序。
  5. 如果有 GPU、HBA、网卡直通、vGPU、DKMS 驱动、第三方 apt 源，提前确认它们是否支持 PVE 9 使用的内核与 Debian Trixie。

另一个容易被忽略的准备是 root 分区空间。官方文档要求 root 挂载点至少 5GB 可用，最好超过 10GB。实际经验里，如果机器很久没清理旧内核、旧日志、下载缓存，升级到一半空间不够会非常麻烦。升级前至少跑：

df -h /
apt autoremove --dry-run
journalctl --disk-usage

不要在升级窗口里临时决定删什么业务数据。能用 apt autoremove、清理旧日志、清理包缓存解决的，就不要动虚拟机磁盘和备份目录。

4. 人工升级总览：先看整条路

下面是人工升级的整体顺序。真正执行时，建议在物理控制台、IPMI/KVM 或 tmux/screen 里做，避免 SSH 断开导致升级过程无人接管。不要使用 PVE Web UI 里的虚拟控制台来升级宿主机，因为升级过程可能影响 Web 服务本身。

tmux new -s pve-upgrade

# 记录当前状态
pveversion -v
apt update
apt dist-upgrade
pveversion

# 升级前检查
pve8to9 --full

# 处理 warning 后反复检查
pve8to9 --full

# 切换 apt 源到 trixie
# apt update
# apt dist-upgrade

# 升级完成后
pve8to9 --full
reboot

这只是鸟瞰。下面把每一步拆开。

5. 第一步：先升级到 PVE 8.4 最新小版本

官方要求所有节点先升级到最新的 Proxmox VE 8.4。不要从一个很旧的 PVE 8.x 直接切 Trixie 源。

apt update
apt dist-upgrade
pveversion

pveversion 至少应显示 8.4.1 或更新版本。这里仍然使用 dist-upgrade，不是普通 upgrade，因为 Proxmox 的内核和元包依赖经常需要 apt 处理新增或替换包。执行完如果提示需要重启，建议先重启到当前 PVE 8 的最新内核，再进入下一阶段。

如果是集群，先在一个非关键节点上验证流程。需要持续运行的 VM/CT，先迁移到暂不升级的节点。官方也提醒：从旧版本迁移到新版本通常可行，但从新版本迁回旧版本一般不作为支持路径依赖，所以节点顺序要提前规划。

6. 第二步：反复运行 pve8to9 --full

pve8to9 是 PVE 8.4 包里提供的升级检查脚本。它默认只检查和报告，不会自动修改系统。升级前至少运行一次 full check：

pve8to9 --full

看到 warning 不要急着无脑清理。常见需要关注的类型包括：

  1. apt 源仍然混乱，或有第三方源没有 Trixie 版本。
  2. Ceph 版本不满足要求。使用超融合 Ceph 的环境，需要先升级到 Ceph 19.2 Squid。
  3. LVM/LVM-thin guest volumes 的 autoactivation 策略需要迁移。
  4. systemd-boot 元包在某些安装方式下应按脚本提示处理。
  5. 某些旧容器依赖 cgroup v1，PVE 9 不再支持 legacy cgroup v1。
  6. NVIDIA vGPU、PCI passthrough、Veeam 备份等特殊场景有额外兼容性问题。

处理完一个问题，就再跑一次：

pve8to9 --full

这一步最能体现 Agent 的价值。让 Agent 帮你把脚本输出分成“必须处理”“可以接受”“需要人工判断”三类，比自己在长输出里翻来翻去快很多。但最终哪些 warning 可以接受，还是要结合你的环境判断。

7. 第三步：切换 Debian 与 Proxmox apt 源到 Trixie

只有在 PVE 8.4 最新、pve8to9 --full 关键问题处理完之后，才切换 apt 源。官方文档给出的基础方向是把 Debian 和 PVE 源从 bookworm 改成 trixie。

传统 .list 写法可以这样处理：

cp -a /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%Y%m%d%H%M%S)
cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.bak.$(date +%Y%m%d%H%M%S)

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

如果你使用 no-subscription 仓库，建议采用 deb822 .sources 格式写清楚。例如 PVE no-subscription 源可以是：

Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

如果使用 Ceph，也要把 Ceph 源切到对应的 Squid/Trixie 组合；没有订阅时使用 ceph-squid 的 no-subscription 源。切完之后不要马上升级，先检查：

apt update
apt policy
grep -R "bookworm" /etc/apt/sources.list /etc/apt/sources.list.d || true

这里的原则是：不能混着来。旧 Bookworm 源、新 Trixie 源、第三方源交叉在一起，最容易导致 apt 计划删除关键包。一旦看到 apt update 报错，先修源，不要硬跑 dist-upgrade。

8. 第四步：执行 apt dist-upgrade

源确认无误后，执行：

apt dist-upgrade

这个阶段需要认真看 apt 计划。特别注意它是否试图移除 proxmox-ve、pve-manager、pve-cluster、qemu-server、pve-kernel 等关键组件。如果出现类似 PVE apt hook 警告，提示正在尝试移除 proxmox-ve，立刻停止，回去检查仓库和冲突包。

升级过程中可能会问配置文件怎么处理。官方文档提到几个常见文件：

  1. /etc/issue：通常只是登录提示，保留当前版本一般安全。
  2. /etc/lvm/lvm.conf：如果你没有做过特殊修改，安装维护者版本通常更合适。
  3. /etc/ssh/sshd_config：如果只有注释或弃用参数变化，可以考虑安装维护者版本；如果有自定义登录策略，必须先看 diff。
  4. /etc/default/grub：如果加过内核参数，谨慎处理，通常先保留当前版本并手工合并。
  5. /etc/chrony/chrony.conf：有自定义时间源时先看 diff，必要时迁移到 conf.d 或 sources.d。

不要把这些提示当成“按回车就行”。PVE 升级失败并不一定发生在 apt 命令本身，很多是配置被覆盖、引导项没更新、网络配置不兼容、驱动不支持导致重启后才暴露。

9. 第五步：升级后复查、重启、再复查

apt dist-upgrade 成功返回 shell 后，不代表升级结束。先跑：

pve8to9 --full
pveversion -v
systemctl --failed

然后重启：

reboot

重启后从独立控制台或 SSH 回连，检查：

pveversion -v
uname -a
systemctl --failed
journalctl -p warning..alert -b --no-pager | tail -n 100
pvesm status
qm list
pct list

Web UI 也要强制刷新浏览器缓存。PVE 前端资源升级后，浏览器旧缓存偶尔会制造“页面奇怪报错”的假象。

如果是集群，还要检查：

pvecm status
ha-manager status

所有节点都升级到 PVE 9 后，再观察 HA groups 到 HA rules 的迁移情况。遇到 HA 异常时，优先看 active CRM 节点上的 pve-ha-crm 日志。

10. 常见坑：真正危险的不是命令，而是跳过检查点

PVE 8 到 9 升级风险检查点

图 3：升级前、升级中、升级后的关键检查点。跳过任意一个，都可能把简单升级变成恢复现场。

几个坑值得单独写出来。

第一，备份没有恢复验证。备份系统显示成功，不等于备份能恢复。至少抽样恢复一台不重要的 VM/CT，确认存储、权限、网络都没问题。

第二，Ceph 顺序错。使用超融合 Ceph 时，不要在 Ceph 还停留在旧大版本时直接升 PVE 9。官方要求 PVE 升级前先完成 Ceph Squid 相关升级。

第三，第三方源没有处理。Docker、监控、驱动、厂商工具、手工加过的 backports，都可能在 Trixie 阶段变成冲突源。升级前把它们逐项列出来，能禁用就先禁用，能确认支持再启用。

第四，只看命令结束，不看删除包列表。apt dist-upgrade 的能力很强，强到它会为了满足依赖而删除包。PVE 环境里，只要它计划移除关键 Proxmox 元包，就不要继续。

第五，远程升级没有独立控制台。SSH 足够常用，但 major upgrade 最好不要只依赖 SSH。网络服务、sshd 配置、内核、网卡命名都有可能变化；没有外部控制台，恢复难度会明显上升。

第六，老容器没处理。PVE 9 不支持 legacy cgroup v1。非常老的系统容器，比如依赖 systemd 230 或更老版本的发行版，应该提前迁移或替换。

第七，PCI passthrough、vGPU、备份软件没有验证。PVE 9 使用更新内核，驱动和备份软件需要兼容。尤其是 NVIDIA vGPU、PCI 直通、Veeam 这类场景，不要把“能开机”当成“业务没问题”。

11. Agent 执行时的验收清单

如果你让 Agent 做，最后不要只听它说“升级完成”。让它给出下面这些脱敏证据：

  1. 升级前后的 pveversion -v 摘要。
  2. pve8to9 --full 最终输出摘要，至少说明没有未处理的关键 blocker。
  3. apt 源里不再包含 bookworm 的检查结果。
  4. systemctl --failed 的结果。
  5. 当前内核版本和启动时间。
  6. 存储状态、VM/CT 列表状态。
  7. 集群和 HA 状态，如果适用。
  8. 升级过程中所有人工确认点：配置文件选择、包删除提示、重启时间。

如果 Agent 给不出这些证据，只说“应该好了”，就当没完成。运维任务不是作文，证据比语气重要。

12. 一份最小手工命令清单

最后给一份适合复制到维护记录里的最小清单。它不是替代官方文档，而是帮助你按顺序执行。

# 0. 建议在 tmux / screen 或独立控制台里执行
tmux new -s pve8to9

# 1. 当前状态
pveversion -v
df -h /
pvesm status
qm list
pct list

# 2. 先升到 PVE 8.4 最新
apt update
apt dist-upgrade
pveversion

# 3. 升级前检查
pve8to9 --full

# 4. 处理 warning 后重复检查
pve8to9 --full

# 5. 备份 apt 源并切换 bookworm -> trixie
cp -a /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%Y%m%d%H%M%S)
cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.bak.$(date +%Y%m%d%H%M%S)
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

# 6. 检查源
apt update
apt policy
grep -R "bookworm" /etc/apt/sources.list /etc/apt/sources.list.d || true

# 7. 执行升级
apt dist-upgrade

# 8. 重启前检查
pve8to9 --full
systemctl --failed

# 9. 重启
reboot

# 10. 重启后验证
pveversion -v
uname -a
systemctl --failed
pvesm status
qm list
pct list
journalctl -p warning..alert -b --no-pager | tail -n 100

如果你使用 no-subscription、Ceph、企业订阅源或第三方源，上面的源切换部分需要按实际仓库改写。不要把示例里的源配置当成所有环境的唯一答案。

13. 结语：能交给 Agent，但不能放弃判断

PVE 8 升 9 很适合让 Agent 帮忙，因为它步骤多、检查多、日志多、容易漏细节。Agent 可以帮你节约时间，尤其是在多节点集群里，它能把重复检查和升级后验证做得更稳定。

但这类升级不适合“全自动无人值守”。真正的关键不是谁敲命令，而是每个检查点有没有证据：备份能不能恢复，pve8to9 有没有处理，apt 源是否干净，升级计划是否安全，重启后服务是否正常。把这些证据拿到手，再决定继续，才是稳妥的升级方式。

来源与参考

  1. Proxmox 官方文档：Upgrade from 8 to 9，https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
  2. Proxmox 官方 Roadmap / PVE 9.0 known issues，https://pve.proxmox.com/wiki/Roadmap
  3. Proxmox 官方文档：Ceph Reef to Squid，https://pve.proxmox.com/wiki/Ceph_Reef_to_Squid
  4. Debian 官方文档：Debian 13 Trixie Release Notes，https://www.debian.org/releases/trixie/release-notes