Introduction
Power goes out. The UPS runs dry after twenty minutes. The Proxmox box comes back up on its own once the electricity does — and then nothing happens. No VMs, no containers, just an empty node sitting there waiting for you to notice and log in.
This trips up almost everyone who's new to Proxmox VE. You install it, create a few VMs, get everything working, and assume the server will just pick up where it left off after a reboot. It won't, not unless you tell it to. Each virtual machine and each LXC container has its own independent switch for this, and it's off by default.
The good news is that fixing it takes about two minutes per guest, and once you understand the two settings involved — Start at boot and Start/Shutdown order — you can build a startup sequence that brings your whole stack back online in the right order, automatically, every time.
What You Will Learn
- Why VMs and containers don't start automatically by default
- How to enable "Start at boot" from the GUI and from the shell
- How to control the order guests start in, and why order matters
- How startup and shutdown delays prevent race conditions between dependent VMs
- The service Proxmox actually uses to run all this at boot time
- What to check when a guest refuses to come up automatically
What Is This Feature?
Every VM and container in Proxmox VE has a configuration option called onboot. When it's set to 1, that guest is included in the list of things Proxmox brings up automatically when the physical host boots. When it's 0 (the default for anything you create), Proxmox leaves it alone until you manually click Start.
Alongside that, there's a second, related setting called startup, which controls three things: the order a guest starts in relative to the others, how long Proxmox waits after starting it before moving on to the next one, and how long it waits during shutdown before giving up and force-stopping it.
Both settings live on a per-guest basis, on the Options tab of each VM or container in the web interface. There's no global "start everything" toggle — you set this individually, which is annoying if you have thirty guests but exactly what you want if you only want some of them to come back automatically.
Why Would You Use It?
The obvious case is a power outage or an unattended reboot after a kernel update. If your Pi-hole VM, your Home Assistant instance, or your Nextcloud box doesn't come back on its own, whoever relies on it (often that's you, at 2 a.m., wondering why the internet at home looks broken) has to notice and fix it manually.
Order matters more than people expect. Say you run a database VM and an application VM that connects to it. If the app VM starts first and tries to connect before the database is even listening on its port, it'll throw a connection error and might not retry gracefully. Proxmox's startup order and delay settings exist specifically to avoid that kind of race.
There's also a boring but important reason: unattended maintenance. If your host reboots itself after installing a kernel update (which, if you've set up unattended-upgrades, it might), you want your services back without having to be at a keyboard.
One thing worth being upfront about — if you're running a Proxmox cluster with High Availability (HA) enabled for a guest, HA takes over responsibility for keeping it running and largely overrides these per-node boot settings for that guest. Everything in this guide applies to standalone nodes and to cluster guests that aren't HA-managed, which covers the overwhelming majority of homelab and small-business setups.
Prerequisites
- A working Proxmox VE installation (this guide applies to both 8.x and 9.x)
- At least one VM or LXC container already created
- Access to the Proxmox web interface at
https://your-server-ip:8006 - SSH or shell access to the Proxmox host, if you want to use the command-line steps
- Root or an account with the
VM.Config.Optionspermission on the guest
Step-by-Step Tutorial
Step 1: Enable "Start at boot" from the GUI
Click on the VM or container in the left-hand tree, then open its Options tab. Find the row labeled Start at boot — it'll show "No" by default. Double-click it, or select it and click Edit, check the box, and click OK.
That's the whole setting for a single guest. Repeat it for every VM and container you want to survive a reboot. Skip the ones you don't — a scratch VM you spin up for testing probably doesn't need to come back automatically.
Step 2: Do the same from the command line
If you'd rather script this or you're managing a headless box over SSH, the CLI equivalent for a VM is:
qm set 101 --onboot 1Replace 101 with your actual VM ID. For a container, the command is pct instead of qm:
pct set 201 --onboot 1To turn it back off, run the same command with --onboot 0.
Step 3: Set a startup order for guests that depend on each other
Back in the GUI, on the same Options tab, find Start/Shutdown order and click Edit. You'll see three fields:
- Start/Shutdown order — a number. Lower numbers start first. A guest with order 1 starts before a guest with order 2. Guests with no order set start last, in no particular sequence.
- Startup delay — how many seconds Proxmox waits after issuing the start command for this guest before it moves on to starting the next one in the queue.
- Shutdown timeout — how many seconds Proxmox waits for a graceful shutdown before forcing the guest off during a host shutdown.
For the database-and-app example from earlier, you might set the database VM to order 1 with a 30-second startup delay, and the app VM to order 2. That gives the database half a minute of head start — usually more than enough for something like PostgreSQL or MySQL to finish its startup checks and start accepting connections.
Step 4: Set order and delay from the command line
The CLI version bundles all three values into one comma-separated argument:
qm set 101 --startup order=1,up=30,down=60Here, order=1 means this guest starts first, up=30 is the 30-second startup delay before Proxmox starts the next guest, and down=60 gives it 60 seconds to shut down cleanly before Proxmox forces it. Any of the three can be omitted if you don't need it, for example --startup order=2 on its own just sets the order with no delay values.
Step 5: Verify your settings actually saved
Don't just trust the GUI — check the underlying config file. Run:
qm config 101 | grep -E 'onboot|startup'You should see something like onboot: 1 and startup: order=1,up=30,down=60. If onboot is missing entirely from the output, it was never enabled (a guest with no onboot line at all behaves the same as onboot: 0).
Step 6: Test it without waiting for a real power outage
The easiest way to confirm everything works is a full host reboot during a maintenance window:
rebootWait for the node to come back up, log into the web UI, and check that the guests you enabled actually started and came up in the order you expected. If something didn't start, jump to the Troubleshooting section below.
Commands Explained
| Command | What it does |
|---|---|
qm set <vmid> --onboot 1 | Marks a VM to start automatically when the host boots. |
pct set <ctid> --onboot 1 | Same thing, for an LXC container instead of a VM. |
qm set <vmid> --startup order=1,up=30,down=60 | Sets boot order, startup delay in seconds, and shutdown timeout in seconds. |
qm config <vmid> | Prints the guest's full configuration, useful for confirming a setting actually took effect. |
pct config <ctid> | Same as above, for containers. |
systemctl status pve-guests.service | Shows the status of the systemd service responsible for starting and stopping all onboot-enabled guests. |
journalctl -u pve-guests -b | Shows the boot log for that service, filtered to the current boot — the first place to look when something didn't start. |
Common Errors
The most common "error" isn't really an error at all — it's silence. You set onboot: 1 on a guest, reboot the host, and the guest just isn't running, with no obvious message telling you why. That's almost always one of three things: the setting didn't actually save, the guest is HA-managed and HA decided not to start it, or the underlying storage wasn't available yet when pve-guests.service tried to start it.
You might also see this in the task log after a boot:
TASK ERROR: storage 'local-zfs' is not online
That means the guest's disk lives on a storage pool (often ZFS or an NFS mount) that wasn't fully mounted and ready by the time Proxmox tried to start the VM. It's more common on setups where storage comes from a slower-to-initialize source, like a USB-attached ZFS pool or a remote NFS server that takes a few extra seconds to respond after a reboot.
Another one worth knowing:
can't lock file '/var/lock/qemu-server/lock-101.conf' - got timeout
This usually shows up if a previous shutdown didn't finish cleanly and left a stale lock behind. A reboot of the host generally clears it, since the lock files live in a tmpfs-backed directory that gets wiped on restart.
Troubleshooting
Start with the log, not the GUI. journalctl -u pve-guests -b shows exactly what the autostart service tried to do on the most recent boot, in order, with timestamps. It'll tell you if a guest was skipped, if it errored out, or if it started fine and something else is the actual problem.
If a guest didn't start at all, double check onboot is really set with qm config <vmid> | grep onboot. It's easy to click Edit, forget to actually check the box, and click OK anyway — the GUI won't warn you.
If you're on a cluster, check whether the guest has HA enabled under Datacenter → HA. An HA-managed guest is started by the HA stack, not by pve-guests.service, and it follows its own request state (started, stopped, disabled) rather than the plain onboot flag.
If the problem is storage not being ready in time, there isn't a delay setting for storage the way there is for guest startup order. The real fix is making sure the storage itself comes up reliably at boot — for a ZFS pool that usually means checking zpool status after a reboot to confirm it imported cleanly, and for NFS or iSCSI storage it means checking that the network is actually up before the mount is attempted.
Finally, if a guest starts but the order looks wrong, remember that guests with no order value set at all are treated as lowest priority and start after everything that does have an order — not necessarily in the order they appear in the guest list.
Best Practices
Don't enable "Start at boot" on everything by reflex. If you've got test VMs, throwaway environments, or anything you spin up and tear down often, leave those off. It keeps your boot sequence shorter and makes it obvious, at a glance, which guests actually matter.
Give infrastructure guests the lowest order numbers. Things like a DNS resolver, a reverse proxy, or a database should start before the services that depend on them. I'd set order in wide steps — 1, 5, 10 — rather than 1, 2, 3, so you have room to slot something in between later without renumbering everything.
Be realistic about startup delay values. A 10-second delay might be enough for a lightweight LXC container running a static site, but a full Windows VM or a database doing crash recovery can easily need 60 seconds or more before it's actually ready to be useful to something downstream.
If you're running anything genuinely critical, don't rely on onboot alone as your entire recovery plan. It solves "the host rebooted," not "the host's boot drive died." Pair it with regular backups.
Frequently Asked Questions
Does "Start at boot" also restart a guest if it crashes while the host stays running?
No. It only controls what happens when the physical host itself boots. If a VM crashes but the host keeps running, Proxmox won't restart it on its own unless that guest is under HA management.
What happens to a guest with no startup order set at all?
It still starts, as long as onboot is enabled. It just starts after every guest that has an explicit order number, and in no guaranteed sequence relative to other order-less guests.
Can I set a startup delay without setting an order?
Yes. qm set 101 --startup up=20 on its own is valid and just adds a 20-second delay after this guest starts, without assigning it a specific position in the sequence.
Does this work the same for LXC containers as it does for VMs?
Yes, both onboot and startup order apply identically to containers. Just use pct instead of qm on the command line, or the same Options tab in the GUI.
Will enabling this slow down my host's boot time?
A little, by design — that's what the startup delay is for. If you don't need staggered starts, leave the delay at 0 and every onboot-enabled guest will start back to back with no artificial pause between them.
Conclusion
Two settings, both tucked into the same Options tab, are the difference between a homelab that quietly puts itself back together after a power blip and one that leaves you SSH'd in at midnight starting VMs by hand. Turn on "Start at boot" for what actually matters, give the things that depend on each other a sensible order and a little breathing room to start up, and then actually test it with a real reboot instead of assuming it'll work.
If you haven't touched this on your own node yet, it's worth five minutes right now, before you're troubleshooting it during an actual outage.