宿主机断电、来电之后PVE 起来了虚拟机还躺着。手动点一次开机一切正常。这不是坏了是没人告诉 PVE「这台机器该自己起来」。本文按「现象 → 原因 → 参数 → 命令 → 验证」的顺序走完一遍命令可以直接复制。一、先分清配置问题还是硬件问题第一步不是改配置是手动开机试一次。手动能起来硬件、驱动、直通都是好的问题在自启配置上往下看。手动也起不来那是硬件、驱动、直通方向的事和自启参数无关先查别的。这一步把两条路一次分开省掉在配置里空转的时间。二、控制自启的三个参数PVE 把自启相关的控制项拆散在不同页面名字也不起眼这是最容易踩的地方参数作用在哪看onboot宿主机启动时这台 VM 是否自动启动VM → 选项 → 开机自启startup启动顺序与延迟order,upVM → 选项 → 启动顺序disable整个存储是否被禁用存储 → 概览被禁用时内容不可用三个参数管三件不同的事onboot1只是「允许」自启不保证这台机器真能起来startup里的order数字决定它第几个启动数字小的先起存储被标了disable1宿主机启动时不会去挂载它VM 找不到盘顺序错了照样起不来。最常见的一刀切所有 VM 都写order1结果存储还没挂上VM 就去读盘了直接启动失败。三、命令行查现状图形界面看不全排查建议直接上命令行。查单台 VM 的自启配置bash查看 804 号 VM 的启动参数qm config 804 | grep -E onboot|startup如果输出里没有 startup说明没设启动顺序批量过一遍整个宿主机上所有 VM 的自启状态bash列出所有 VM 及其自启状态for id in $(qm list | awk NR1 {print $1}); doprintf %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 为例onboot1允许自启order1排第一个启动up10表示启动后等 10 秒。bashqm set 804 --onboot 1 --startup order1,up10改完不用重启 PVE配置即刻生效。五、三个比参数更隐蔽的坑### 坑一存储被整体禁用VM 建在某个存储上而这个存储在配置文件里被标了disable1宿主机启动时不会去挂载它结果 VM 找不到盘。bash看所有存储的状态Name/Type/Status/Enabled/Contentpvesm status只看启用中的存储pvesm status --enabled 1Enabled一列是yes才正常被禁用时会是no。### 坑二VM 在 HA 资源池里行为会被接管如果这台 VM 被放进了 HA高可用资源池宿主机启动后的自启行为由 HA 集群接管不再由onboot决定。这时要查的是 HA 任务状态不是 VM 的onboot。bash看 HA 资源和任务ha-manager status### 坑三存储是网络挂载的依赖顺序没排对NFS/iSCSI 存储在宿主机启动时需要网络先通。如果 VM 的启动顺序排在网络挂载之前就会启动失败。这种情况要给存储本身设置启动优先级存储 → 选项 → 内容 → 启动顺序排在所有 VM 之前。六、验证配置到底写进去没有改完参数用同一条命令回读一次bashqm config 804 | grep -E onboot|startup输出里看到onboot: 1和startup: order1,up10才算生效。命令跑通不代表配置对要看输出内容。七、完整排查顺序碰到「宿主机重启后 VM 没起来」按这六步走不要跳步1.先手动开机试一次能起来就是配置问题起不来是硬件方向2.qm config vmid | grep -E onboot|startup确认onboot1且startup已设3.pvesm status确认存储都是Enabledyes4.看系统日志journalctl -b | grep -iE qm|start|failed启动失败的原因在日志里通常比界面写得清楚5.ha-manager status确认是不是 HA 接管的6.检查启动顺序依赖网络存储需要排在所有 VM 之前八、上线前自检清单宿主机断过电或者重启过之后VM 是自己起来的还是等人点的存储列表里的每一项都是Enabledyes吗网络存储的启动顺序排在所有 VM 之前了吗有没有哪台 VM 长期是「手动开机」的你自己没注意整套分层排查顺序和常见故障处理步骤我整理在官网的故障排查文档里https://hyperhan.com/docs-troubleshooting.html第一条答不上来或者有几台长期靠手动建议花半小时把整套参数理一遍。我是老金做了十几年 IT 基础设施华为、锐捷网络设备和云桌面方案都做专做中小规模落地交付。PVE 这类虚拟化底座上的自启动、存储挂载、直通配置遇到过的大坑不算少。上面这套命令建议收藏现场直接翻拿不准的把qm config输出贴评论区我看到就回。 
长河君 · 2026/10/28 23:58:44 · 阅读 1.2k Proxmox PVE 虚拟机开机自启配置详解：onboot/startup 参数与排查命令
宿主机断电、来电之后PVE 起来了虚拟机还躺着。手动点一次开机一切正常。这不是坏了是没人告诉 PVE「这台机器该自己起来」。本文按「现象 → 原因 → 参数 → 命令 → 验证」的顺序走完一遍命令可以直接复制。一、先分清配置问题还是硬件问题第一步不是改配置是手动开机试一次。手动能起来硬件、驱动、直通都是好的问题在自启配置上往下看。手动也起不来那是硬件、驱动、直通方向的事和自启参数无关先查别的。这一步把两条路一次分开省掉在配置里空转的时间。二、控制自启的三个参数PVE 把自启相关的控制项拆散在不同页面名字也不起眼这是最容易踩的地方参数作用在哪看onboot宿主机启动时这台 VM 是否自动启动VM → 选项 → 开机自启startup启动顺序与延迟order,upVM → 选项 → 启动顺序disable整个存储是否被禁用存储 → 概览被禁用时内容不可用三个参数管三件不同的事onboot1只是「允许」自启不保证这台机器真能起来startup里的order数字决定它第几个启动数字小的先起存储被标了disable1宿主机启动时不会去挂载它VM 找不到盘顺序错了照样起不来。最常见的一刀切所有 VM 都写order1结果存储还没挂上VM 就去读盘了直接启动失败。三、命令行查现状图形界面看不全排查建议直接上命令行。查单台 VM 的自启配置bash查看 804 号 VM 的启动参数qm config 804 | grep -E onboot|startup如果输出里没有 startup说明没设启动顺序批量过一遍整个宿主机上所有 VM 的自启状态bash列出所有 VM 及其自启状态for id in $(qm list | awk NR1 {print $1}); doprintf %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 为例onboot1允许自启order1排第一个启动up10表示启动后等 10 秒。bashqm set 804 --onboot 1 --startup order1,up10改完不用重启 PVE配置即刻生效。五、三个比参数更隐蔽的坑### 坑一存储被整体禁用VM 建在某个存储上而这个存储在配置文件里被标了disable1宿主机启动时不会去挂载它结果 VM 找不到盘。bash看所有存储的状态Name/Type/Status/Enabled/Contentpvesm status只看启用中的存储pvesm status --enabled 1Enabled一列是yes才正常被禁用时会是no。### 坑二VM 在 HA 资源池里行为会被接管如果这台 VM 被放进了 HA高可用资源池宿主机启动后的自启行为由 HA 集群接管不再由onboot决定。这时要查的是 HA 任务状态不是 VM 的onboot。bash看 HA 资源和任务ha-manager status### 坑三存储是网络挂载的依赖顺序没排对NFS/iSCSI 存储在宿主机启动时需要网络先通。如果 VM 的启动顺序排在网络挂载之前就会启动失败。这种情况要给存储本身设置启动优先级存储 → 选项 → 内容 → 启动顺序排在所有 VM 之前。六、验证配置到底写进去没有改完参数用同一条命令回读一次bashqm config 804 | grep -E onboot|startup输出里看到onboot: 1和startup: order1,up10才算生效。命令跑通不代表配置对要看输出内容。七、完整排查顺序碰到「宿主机重启后 VM 没起来」按这六步走不要跳步1.先手动开机试一次能起来就是配置问题起不来是硬件方向2.qm config vmid | grep -E onboot|startup确认onboot1且startup已设3.pvesm status确认存储都是Enabledyes4.看系统日志journalctl -b | grep -iE qm|start|failed启动失败的原因在日志里通常比界面写得清楚5.ha-manager status确认是不是 HA 接管的6.检查启动顺序依赖网络存储需要排在所有 VM 之前八、上线前自检清单宿主机断过电或者重启过之后VM 是自己起来的还是等人点的存储列表里的每一项都是Enabledyes吗网络存储的启动顺序排在所有 VM 之前了吗有没有哪台 VM 长期是「手动开机」的你自己没注意整套分层排查顺序和常见故障处理步骤我整理在官网的故障排查文档里https://hyperhan.com/docs-troubleshooting.html第一条答不上来或者有几台长期靠手动建议花半小时把整套参数理一遍。我是老金做了十几年 IT 基础设施华为、锐捷网络设备和云桌面方案都做专做中小规模落地交付。PVE 这类虚拟化底座上的自启动、存储挂载、直通配置遇到过的大坑不算少。上面这套命令建议收藏现场直接翻拿不准的把qm config输出贴评论区我看到就回。