Proxmox PVE 虚拟机开机自启配置详解：onboot/startup 参数与排查命令

宿主机断电、来电之后，PVE 起来了，虚拟机还躺着。手动点一次开机，一切正常。

这不是坏了，是没人告诉 PVE「这台机器该自己起来」。本文按「现象 → 原因 → 参数 → 命令 → 验证」的顺序走完一遍，命令可以直接复制。

一、先分清：配置问题还是硬件问题

第一步不是改配置，是手动开机试一次。

• 手动能起来：硬件、驱动、直通都是好的，问题在自启配置上，往下看。
• 手动也起不来：那是硬件、驱动、直通方向的事，和自启参数无关，先查别的。

这一步把两条路一次分开，省掉在配置里空转的时间。

二、控制自启的三个参数

PVE 把自启相关的控制项拆散在不同页面，名字也不起眼，这是最容易踩的地方：

三个参数管三件不同的事：

• onboot=1只是「允许」自启，不保证这台机器真能起来
• startup里的order=数字决定它第几个启动，数字小的先起
• 存储被标了disable=1，宿主机启动时不会去挂载它，VM 找不到盘

顺序错了照样起不来。最常见的一刀切：所有 VM 都写order=1，结果存储还没挂上，VM 就去读盘了，直接启动失败。

三、命令行查现状

图形界面看不全，排查建议直接上命令行。

查单台 VM 的自启配置：

`bash

查看 804 号 VM 的启动参数

qm config 804 | grep -E "onboot|startup"

如果输出里没有 startup，说明没设启动顺序

`

批量过一遍整个宿主机上所有 VM 的自启状态：

`bash

列出所有 VM 及其自启状态

for id in $(qm list | awk 'NR>1 {print $1}'); do

printf "%s %-20s onboot=%s startup=%s\n" \

"$id" \

"$(qm config $id | grep -E '^name:' | cut -d' ' -f2-)" \

"$(qm config $id | grep -oP 'onboot:\s*\K\d+' || echo 0)" \

"$(qm config $id | grep -oP 'startup:\s*\K.*' || echo '未设置')"

done

`

四、命令行改参数

以 804 为例：onboot=1允许自启，order=1排第一个启动，up=10表示启动后等 10 秒。

`bash

qm set 804 --onboot 1 --startup order=1,up=10

`

改完不用重启 PVE，配置即刻生效。

五、三个比参数更隐蔽的坑

### 坑一：存储被整体禁用

VM 建在某个存储上，而这个存储在配置文件里被标了disable=1，宿主机启动时不会去挂载它，结果 VM 找不到盘。

`bash

看所有存储的状态（Name/Type/Status/Enabled/Content）

pvesm status

只看启用中的存储

pvesm status --enabled 1

`

Enabled一列是yes才正常，被禁用时会是no。

### 坑二：VM 在 HA 资源池里，行为会被接管

如果这台 VM 被放进了 HA（高可用）资源池，宿主机启动后的自启行为由 HA 集群接管，不再由onboot决定。这时要查的是 HA 任务状态，不是 VM 的onboot。

`bash

看 HA 资源和任务

ha-manager status

`

### 坑三：存储是网络挂载的，依赖顺序没排对

NFS/iSCSI 存储在宿主机启动时需要网络先通。如果 VM 的启动顺序排在网络挂载之前，就会启动失败。这种情况要给存储本身设置启动优先级（存储 → 选项 → 内容 → 启动顺序），排在所有 VM 之前。

六、验证：配置到底写进去没有

改完参数，用同一条命令回读一次：

`bash

qm config 804 | grep -E "onboot|startup"

`

输出里看到onboot: 1和startup: order=1,up=10才算生效。命令跑通不代表配置对，要看输出内容。

七、完整排查顺序

碰到「宿主机重启后 VM 没起来」，按这六步走，不要跳步：

1.先手动开机试一次，能起来就是配置问题，起不来是硬件方向

2.qm config <vmid> | grep -E "onboot|startup"，确认onboot=1且startup已设

3.pvesm status，确认存储都是Enabled=yes

4.看系统日志，journalctl -b | grep -iE "qm|start|failed"，启动失败的原因在日志里通常比界面写得清楚

5.ha-manager status，确认是不是 HA 接管的

6.检查启动顺序依赖，网络存储需要排在所有 VM 之前

八、上线前自检清单

• 宿主机断过电或者重启过之后，VM 是自己起来的还是等人点的？
• 存储列表里的每一项都是Enabled=yes吗？
• 网络存储的启动顺序排在所有 VM 之前了吗？
• 有没有哪台 VM 长期是「手动开机」的，你自己没注意？

整套分层排查顺序和常见故障处理步骤，我整理在官网的故障排查文档里：https://hyperhan.com/docs-troubleshooting.html

第一条答不上来，或者有几台长期靠手动，建议花半小时把整套参数理一遍。

我是老金，做了十几年 IT 基础设施，华为、锐捷网络设备和云桌面方案都做，专做中小规模落地交付。PVE 这类虚拟化底座上的自启动、存储挂载、直通配置，遇到过的大坑不算少。上面这套命令建议收藏，现场直接翻；拿不准的把qm config输出贴评论区，我看到就回。