How to Safely Shut Down or Reboot a Proxmox VE Host (Without Breaking Your VMs)

Introduction

Somebody always does it eventually: they hold the power button on a Proxmox box because the web interface froze, or they run shutdown -h now over SSH without checking what's actually running. Most of the time nothing bad happens. Then one day it does — a VM's filesystem comes up dirty after the next boot, or a container that was supposed to auto-start just... doesn't.

Proxmox VE runs on top of a normal Debian install, so the host itself shuts down the same way any Linux server does. The part people miss is everything happening underneath that: guest operating systems that need their own graceful shutdown, an HA stack that reacts to a node disappearing, and containers that behave more like a stack of Linux processes than a single big VM.

This guide walks through the right way to power off or restart a Proxmox VE host, whether it's a single homelab box or one node in a three-node cluster with High Availability turned on.

What You Will Learn

• What actually happens, step by step, when you shut down or reboot a Proxmox VE node
• How to do it safely from the web GUI and from the shell
• Why VMs and LXC containers shut down differently, and what that means for you
• How High Availability (HA) changes the picture, and how to put a node into maintenance mode first
• The commands to check before you pull the trigger, and what to do when a shutdown hangs

What Is This Feature?

There isn't a special "Proxmox shutdown" system separate from Linux. When you click Shutdown in the GUI or run reboot on the console, you're triggering the same systemd shutdown sequence any Debian server uses. What makes it worth its own guide is that Proxmox VE hooks into that sequence to stop your guests first.

Before the host itself powers down, Proxmox tries to shut down every running VM and LXC container in an orderly way, using whatever order and delay settings you've configured for each guest. Only once those are stopped (or forcibly killed after a timeout) does the actual hardware power-off happen.

A quick vocabulary check, since these come up below:

• LXC container — a lightweight virtual environment that shares the host's Linux kernel instead of running its own. It starts and stops more like a set of processes than a full computer, which is why containers shut down faster than VMs.
• QEMU Guest Agent — a small service you install inside a VM that lets Proxmox talk to the guest OS directly, instead of just sending it a generic power signal. It makes shutdowns (and a few other things, like getting the VM's IP address) more reliable.
• ACPI — the same power-signaling standard your laptop uses when you press its power button briefly. Proxmox sends this to a VM if there's no guest agent to talk to, and the guest OS decides how to respond to it.
• High Availability (HA) — a Proxmox feature where a cluster automatically restarts a VM or container on another node if the node it was running on disappears. Handy for uptime, but it changes what "just reboot the node" means, as you'll see below.

Why Would You Use It?

You'll hit this any time you need to touch the physical (or virtual) hardware under Proxmox: installing RAM, swapping a failed drive, applying a kernel update that needs a reboot to take effect, or just moving the box to a different rack. None of that is unusual. What's avoidable is doing it in a way that corrupts a guest's disk or leaves your HA cluster confused about where a VM is supposed to be running.

A clean shutdown gives every guest OS the chance to flush its disk cache and stop its own services in order — the same reason you don't yank power from your laptop mid-write. Skip that step often enough and eventually you'll be restoring a VM from backup instead of just rebooting it.

Prerequisites

• Root or an account with Sys.PowerMgmt permission on the node (the default admin role has this)
• Access to the Proxmox web GUI, or SSH access to the node's shell
• If you're on a cluster: know whether any VMs or containers on this node are managed by HA (Datacenter → HA will show you)
• A recent backup of anything important. This isn't strictly required for a normal shutdown, but if you're about to reboot a host you haven't rebooted in months — say, for a kernel update — it's worth having one ready in case the new kernel doesn't boot cleanly

Step-by-Step Tutorial

1. Check what's running, and what HA controls

Before touching power, look at what's actually on the node. Click the node in the left-hand tree, then check the Summary tab for a guest count, or open Datacenter → HA to see which VMs and containers are HA-managed. This matters because HA-managed resources behave differently during a reboot than plain ones, which I'll get to in a moment.

2. If HA is in play, put the node into maintenance mode first

Skip this step if you don't use HA — most homelab setups don't. If you do, run this from the shell on any node in the cluster:

ha-manager crm-command node-maintenance enable pve-node2

Swap pve-node2 for your actual node name. This tells the HA cluster resource manager to migrate the node's HA-managed guests to other nodes in the cluster before you take it down, rather than just noticing it vanished. It's the difference between a planned migration and an unplanned failover.

Once you're done and the node is back up, disable maintenance mode so it rejoins normal HA scheduling:

ha-manager crm-command node-maintenance disable pve-node2

You can confirm the current state of every HA resource at any point with:

ha-manager status

3. Shut down or reboot from the GUI

For a single node with no HA guests to worry about, this is the easiest path. Click the node's name in the left panel, then look at the top-right corner of the screen. You'll see Reboot and Shutdown buttons there. Click whichever one you need and confirm the prompt.

Behind the scenes, Proxmox now starts working through every running VM and container on that node, stopping them in the reverse of their configured startup order, before it actually restarts or powers off the underlying OS.

4. Or do it from the shell

SSH into the node and run one of the standard commands:

reboot

or

shutdown -h now

Both trigger the same systemd shutdown target the GUI buttons use, so you get the same guest-shutdown behavior either way. There's no special Proxmox-only reboot command — it really is just Debian underneath.

5. Watch it happen (optional, but reassuring the first time)

If you want to see the guest shutdowns happening rather than just trusting it, open a second SSH session before you reboot and run:

watch -n 2 qm list

You'll see each VM's status flip from running to stopped one at a time as the host works through its list, right up until the connection drops when the reboot actually fires.

6. Shut down individual guests manually, if you'd rather control the order yourself

Sometimes you don't want to trust the automatic sequence — maybe a database VM needs to go down before the app server that depends on it. Shut guests down manually first:

qm shutdown 101
pct shutdown 201

Once everything you care about is confirmed stopped (check with qm list and pct list), reboot the host as normal.

Commands Explained

Command	What it does
reboot	Standard Linux command that restarts the host. Proxmox intercepts the shutdown sequence to stop guests first.
shutdown -h now	Powers the host off immediately after the normal shutdown sequence runs.
qm shutdown <vmid>	Sends a graceful shutdown request to one VM — via the QEMU Guest Agent if it's installed and enabled, otherwise via ACPI.
qm stop <vmid>	Force-stops a VM immediately, like pulling its power cord. Use it only when a graceful shutdown has already failed.
pct shutdown <ctid>	Asks an LXC container's own init system (systemd, usually) to shut down cleanly.
pct stop <ctid>	Force-stops a container immediately, skipping its normal shutdown process.
ha-manager crm-command node-maintenance enable <node>	Marks a node for maintenance so HA migrates its resources elsewhere before you take it down.
ha-manager status	Shows the current state of every HA-managed resource and node in the cluster.

Common Errors

"VM quit/powerdown failed - got timeout" — this is the one you'll see most. Proxmox waited 180 seconds by default for the guest to shut itself down and never heard back. It usually means the guest OS didn't understand the ACPI signal, or the QEMU Guest Agent option is enabled in the VM's settings but the agent isn't actually installed and running inside the guest. Enabled-but-absent is worse than not enabled at all, since Proxmox won't automatically fall back to ACPI once it expects the agent to answer.

The GUI reboot spinner never finishes — almost always a VM stuck mid-shutdown, not the host itself hanging. Check qm list from a second session; something is probably still marked running.

HA restarts a VM on a different node than expected after a reboot — you skipped maintenance mode. Without it, HA sees the node go offline and treats it as a failure, which is exactly what it's designed to react to.

Troubleshooting

If a specific VM refuses to shut down cleanly, don't jump straight to qm stop. First check whether the QEMU Guest Agent is actually running inside the guest — on a Linux VM, systemctl status qemu-guest-agent tells you in one line. If it's not installed at all, either install it or disable the "Qemu Agent" checkbox under the VM's Options tab so Proxmox falls back to plain ACPI instead of waiting on an agent that will never respond.

If ACPI shutdown itself isn't working, that's usually a guest OS setting, not a Proxmox problem. Windows guests occasionally have "fast startup" or power-plan settings that interfere with ACPI shutdown signals; older or minimal Linux distributions sometimes lack ACPI daemon support entirely.

For a container that hangs, log into it directly (pct enter <ctid>) and check whether something inside is refusing to stop — a runaway process or a broken systemd unit is the usual culprit, same as troubleshooting a stuck shutdown on any regular Linux box.

If the node itself seems to hang after all guests report stopped, give it a minute before assuming it's actually frozen. Filesystem sync and storage unmounts (especially with ZFS pools or network storage attached) can take longer than people expect on a first shutdown after a long uptime.

Best Practices

Set a sensible startup order and delay on guests that depend on each other — a database VM with order 1, its app server with order 2 and a short up-delay, and so on. Shutdown just runs that sequence backward, so getting it right once means every future reboot handles dependencies correctly without you thinking about it.

Install the QEMU Guest Agent in every VM where you can. It's a small, low-risk addition (usually just qemu-guest-agent from your distro's package manager, plus the checkbox in the VM's Options tab) and it turns shutdowns from a "hope ACPI works" situation into a "the guest OS actually confirms it's stopping" one.

On a cluster, get comfortable with maintenance mode before you need it in a hurry. Practicing it once on a quiet Sunday afternoon is a lot better than learning the command while a drive is already failing.

Honestly, unless you're chasing a specific kernel CVE, I wouldn't reboot a stable production node just because an update is available. Batch host reboots into a planned maintenance window instead of doing it the moment apt tells you there's a new kernel.

Keep at least one backup of anything you'd be annoyed to lose, especially before a reboot on a host you haven't restarted in a long time. Kernel or firmware surprises are rare, but they're exactly the kind of thing that only shows up when you actually restart.

Frequently Asked Questions

Will rebooting the Proxmox host stop my VMs permanently?
No. As long as each guest has "Start at boot" enabled, it comes back up automatically once the host finishes rebooting.

Can I reboot just one node in a cluster without affecting the others?
Yes. Other nodes keep running normally. If HA is managing guests on the node you're rebooting, use maintenance mode first so they migrate cleanly instead of triggering a failover.

What's the difference between qm stop and qm shutdown?
qm shutdown asks the guest OS to power itself down gracefully. qm stop just kills the VM process outright, the equivalent of cutting power. Only use stop when shutdown has already failed.

Is it safe to just hold the physical power button?
Only as a last resort. It skips every graceful shutdown step for every running guest at once, which is a good way to end up with filesystem corruption on a VM that was mid-write.

Do LXC containers need the QEMU Guest Agent?
No, that's a VM-only concept. Containers share the host kernel directly, so pct shutdown talks straight to the container's own init system.

Conclusion

None of this is complicated once you've seen it happen a couple of times. The short version: check what's running, put HA-managed nodes into maintenance mode first, use the GUI buttons or a plain reboot/shutdown command, and let Proxmox work through the guest list before the hardware actually powers down. Do that consistently and a host reboot becomes routine maintenance instead of something you cross your fingers over.