Proxmox LXC Management Dashboard: 4 Power Actions, Bulk Ops

A Proxmox LXC management dashboard earns its keep on the boring daily jobs: starting a container, shutting one down without breaking anything, finding out why it’s slow, and patching twenty of them before lunch. Stashboard V6.4 added power actions to every LXC and turned its Stats tab into a live view, V6.11 added host-wide bulk monitoring and update runs with an audit trail, and V6.14 made Shutdown honest about what it has actually done. ⚙️

This guide covers that day-to-day layer of the Proxmox LXC management dashboard: what each power button does on the host, how to read live stats and tasks, how to run bulk operations safely, how to verify it all, and what can go wrong. New to Stashboard’s Proxmox side? Start with the Proxmox pillar guide.

What the Proxmox LXC Management Dashboard Covers Day to Day

Everything lives on the Proxmox page:

Power actions: Start, Shutdown, Reboot and Stop.
Stats: live CPU, RAM, network and disk I/O sparklines, plus RRD history.
Tasks: the container’s recent Proxmox tasks with their logs.
Bulk operations: Enable all, Disable all and Update all per host.
Audit: every monitoring change and update run.

Power actions, stats and tasks use only the Proxmox API token. The Proxmox LXC management dashboard needs SSH only for apt work: reading update counts and applying updates.

Prerequisites

Before you rely on the Proxmox LXC management dashboard for daily work, check these:

Stashboard 6.14.0 or newer. Lifecycle arrived in 6.4.0 and bulk in 6.11.0; 6.14.0 added the confirm dialog and the Shutdown behavior below. Any current 10.x image qualifies.
A Proxmox VE host connected with an API token, as set up in the pillar guide.
Token privileges: VM.PowerMgmt for power actions and VM.Audit for the status and RRD reads behind Stats. To see tasks started by other users, such as backup jobs or clicks in the Proxmox UI, the token also needs Sys.Audit on /nodes/{node}.
For bulk updates: SSH credentials on the host, the Settings → Proxmox updates switch and the host’s Allow apply updates opt-in, all off by default. The LXC update monitoring guide covers these gates and the single-container Update now.

Check and grant the token’s rights

On the node, list the token’s effective permissions (use your own user, token and VMID):

pveum user token permissions root@pam stashboard --path /vms/101

If something is missing, grant a narrow role plus read-only node access (replace pve with your node name):

pveum role add StashboardOps --privs "VM.Audit VM.PowerMgmt"
pveum acl modify /vms --tokens 'root@pam!stashboard' --roles StashboardOps
pveum acl modify /nodes/pve --tokens 'root@pam!stashboard' --roles PVEAuditor

⚠️ Keep the single quotes, or bash treats ! as history expansion. With privilege separation, a token gets the intersection of its own ACLs and its user’s, so the user needs the rights too (pveum manual).

Power Actions in the Proxmox LXC Management Dashboard

Four verbs cover the power lifecycle in the Proxmox LXC management dashboard, and two of them sound alike but behave very differently.

Where the buttons are

A running container’s card shows Shutdown and Reboot; a stopped one shows Start. Right-click the card for the same actions plus a red Stop. The modal’s Overview tab has a Lifecycle section with the full set, plus Clone and Destroy if you’ve enabled them.

Graceful Shutdown vs hard Stop on the host

Each button calls Stashboard’s POST …/lxc/{vmid}/status/{verb} endpoint, which forwards the verb to Proxmox. Per the pct manual and the pve-container source:

Start runs a vzstart task.
Shutdown runs vzshutdown: lxc-stop sends the container’s init its halt signal (SIGPWR by default), and Proxmox waits up to 60 seconds. Stashboard doesn’t set forceStop, so a container that ignores the request isn’t killed: the task fails with container did not stop and the container keeps running.
Reboot runs vzreboot, a clean shutdown plus a start that also applies pending config changes, such as a hostname edit from the Config tab. ⚠️ Unlike Shutdown, it falls back to a hard kill if the container hasn’t stopped after 60 seconds.
Stop runs vzstop and kills every process in the container at once. Services can’t finish their writes, so a database may need crash recovery afterwards.

The confirm dialog

Start and Reboot run immediately. Shutdown and Stop first open a confirm dialog naming the target (CT 101 · pihole) and the action (Shutdown — graceful or Stop — hard power-off):

Shutdown: the OS is asked to power off cleanly, no data is lost, it may take a while, and the card keeps showing running until the container actually stops.
Stop: compared to pulling the power cord, with a warning that unsaved data can be lost and a red confirm button.

Why a graceful Shutdown isn’t marked stopped

A Proxmox LXC management dashboard that shows stopped for a running container is worse than none. After Start, Reboot or Stop, the backend updates the stored running state at once, so the card flips immediately; those outcomes are quick and predictable. A Shutdown is asynchronous, can take a minute, and can be ignored. So Stashboard deliberately leaves the card on running and lets the live-status sync fix it: while the Proxmox page is open, it lists guests over the API (no SSH) about every 20 seconds and flips the card to Stopped once Proxmox reports it. Earlier builds flipped it instantly. The modal only confirms “shutdown” sent. Proxmox is applying it; the Tasks tab shows how it ended.

⚠️ Critical: don’t send Stop while a Shutdown is still running. The vzshutdown task holds the container’s config lock while it waits, and Stashboard’s Stop doesn’t use Proxmox’s overrule-shutdown option, so the two can collide. Wait for the task to end (about a minute at most), then Stop.

Live Stats in the Proxmox LXC Management Dashboard 📊

The Stats tab opens in Live mode. Proxmox has no stats stream for LXC, so the Proxmox LXC management dashboard polls status/current every 2 seconds and keeps a rolling window of 120 samples (about four minutes). Pause freezes the window; Resume carries on. Four tiles, each with a sparkline:

CPU in percent.
Memory used against the container’s limit.
Network ↓ / ↑ receive and send rates.
Disk I/O R / W read and write throughput.

Proxmox reports network and disk traffic as running totals, so Stashboard converts consecutive samples into rates. “Disk” means I/O here; disk usage is on the Config tab. Leaving the tab stops polling and drops the window, so keep Stats open while you reproduce a problem.

History shows Proxmox’s RRD data for Hour / Day / Week, refreshed every 30 seconds, for questions like “why was it slow last night?”.

The Tasks Tab: What Actually Happened

Tasks lists the container’s last 25 finished Proxmox tasks, newest first: type (vzstart, vzshutdown, vzstop, vzdump and so on), result (OK or the error), start time and duration. Expand a row for up to 512 log lines and the user who ran it; Stashboard’s actions show your token, such as root@pam!stashboard.

Stashboard reads the task archive, so a running task appears once it ends (switch tabs to refresh). And because power actions get no Stashboard audit row, in the Proxmox LXC management dashboard this tab is your record of who stopped what, and when.

Bulk Operations in the Proxmox LXC Management Dashboard

Per-container buttons stop scaling around the tenth container, so V6.11 gave the Proxmox LXC management dashboard host-wide controls in each host’s ⋮ menu (or right-click the host’s section).

Enable all / Disable all

After a confirm dialog, one PUT …/lxc/monitoring/bulk call flips update monitoring for every LXC on the host in a single transaction; VMs and the node are untouched. Disabled cards get a Disabled badge, lose their pending count, and are skipped by checks and notifications. Containers already in that state are skipped and add no audit rows.

For one container and a fixed window, use Maintenance snooze on its Watch tab (1h, 6h, 24h or 7d). It’s re-included automatically afterwards, and snoozed containers stay out of bulk updates.

Update all, step by step

Refresh the counts with Check now on the node card.
Snapshot critical containers first; see the clone and snapshot guide.
Open ⋮ → Update all. The checklist holds every eligible target: running, monitored, not snoozed, with pending updates. The node appears if it has updates. All start ticked.
Trim the list. ⚠️ Untick the container that runs Stashboard itself (or its Docker host). If an upgrade restarts Docker there, the run dies mid-way, later targets never start, and that audit row can stay stuck as Active.
Read the warning and click Update N now (N is the number of ticked targets). Stashboard checks the three gates once, then runs targets one by one in VMID order, node (VMID 0) first. Inside a container it runs:

pct exec 101 -- sh -c 'export DEBIAN_FRONTEND=noninteractive; if ! command -v apt-get >/dev/null 2>&1; then echo NOAPT; exit 3; fi; apt-get update && apt-get -y -o Dpkg::Options::=--force-confold -o Dpkg::Use-Pty=0 dist-upgrade' 2>&1

Watch the run. Each target gets a spinner, then a tick or a cross, and its apt log streams under a ── pihole (CT 101) ── separator. A failure doesn’t stop the rest, a container without apt is marked not apt-based, and each target gets 20 minutes at most.
Check the result: Bulk update complete or Bulk update finished with errors, with counts. Pending counts refresh after each successful target.

⚠️ Keep the browser tab open until it finishes. A disconnect cancels the run: the current target is closed as Client disconnected and the rest never start. An apt run cut off halfway can leave dpkg half-configured; fix it with dpkg --configure -a inside the container, for example from the browser LXC console.

The audit trail 🧾

The Audit page (sidebar) records both kinds of bulk work:

Proxmox updates: one row per target of every run, with host, target, start, end, duration, exit status, output size and end reason.
LXC monitoring: the container, the change (Enabled, Disabled, Snoozed, Snooze cleared), the new state, the scope (Single or Bulk (all)) and the time.

Between the two tabs, the Proxmox LXC management dashboard keeps a who / when / what record of every change except power actions. An expired snooze clears itself on the next scan without a new row.

How to Verify Your Proxmox LXC Management Dashboard

Test the Proxmox LXC management dashboard on a throwaway container (CT 999) with a shell on the node:

Start it. The card flips to running at once, pct status 999 prints status: running, and Tasks shows vzstart OK, run by your token.
Stats: generate 30 seconds of CPU load and watch the CPU tile jump and fall, then compare memory with pvesh:

pct exec 999 -- sh -c 'timeout 30 yes > /dev/null'
pvesh get /nodes/pve/lxc/999/status/current --output-format json-pretty

Shutdown: the card still says running right after, then flips to Stopped within about 20 seconds of the container stopping; Tasks shows vzshutdown OK.
Stop: start it again and Stop it from the Lifecycle section. The card flips at once; the task is vzstop.
Bulk monitoring: Disable all, check the badges and the Bulk (all) rows in Audit → LXC monitoring, then Enable all.
Bulk update: run Update all with only CT 999 ticked. Audit → Proxmox updates should show exit status 0, and this should list no packages:

pct exec 999 -- apt list --upgradable

Troubleshooting

Most Proxmox LXC management dashboard problems come down to token rights or a gate:

A power action fails with “Proxmox host unreachable” and a 403. The host answered; the token lacks VM.PowerMgmt. Stashboard puts that prefix on every HTTP failure.
Shutdown did nothing. The container’s init ignored the request for 60 seconds, and the task log says container did not stop. Check inside with the console, then Stop.
Tasks misses backups or UI actions. Grant Sys.Audit on the node.
No Update all in the menu. A gate is off: the master switch, Allow apply updates or SSH.
A container is missing from the checklist. It’s stopped, unmonitored, snoozed or up to date; run Check now.

Risks of a Proxmox LXC Management Dashboard

Every shortcut in a Proxmox LXC management dashboard is also a faster way to break something:

Stop is a power-cord pull. Save it for containers that ignore Shutdown.
Reboot can end in a kill after 60 seconds.
Bulk updates run as root without prompts. --force-confold keeps your existing config files, so new upstream defaults don’t land, and services restart as packages upgrade. Update DNS and proxy containers on their own so the LAN doesn’t blink.
A new node kernel needs a manual reboot, and rebooting the node takes every guest down with it.
Power actions have no Stashboard audit row; Proxmox’s task history is the record.
Bulk upgrades are manual by design. There’s no schedule.

Proxmox LXC Management Dashboard FAQ

Does the Proxmox LXC management dashboard need SSH for power actions?

No. Power actions, Stats and Tasks use only the API token. SSH is needed for apt work, the console and the Logs tab.

Why does the Proxmox LXC management dashboard still show running after a Shutdown?

Because the container may still be running. The card waits for Proxmox to report it stopped, which the live-status sync picks up within about 20 seconds.

Can the Proxmox LXC management dashboard start or stop containers in bulk?

No. Bulk operations cover monitoring and updates only; power actions stay per container, and VMs aren’t part of bulk updates.

Bottom Line

The Proxmox LXC management dashboard in Stashboard covers the daily loop without opening the Proxmox web UI: the right power verb, live stats, the task log, and a whole host patched from one checklist, with every monitoring change and update run on record. Run the verification pass on a throwaway container, then let the Proxmox LXC management dashboard take over the routine. 🚀

Stashboard is open source: code on GitHub, image on Docker Hub.

Proxmox LXC Management Dashboard Guide: Clean Shutdowns, Live Stats, Bulk Updates