Bound Proxmox bulk guest shutdown before using stopall

Bottom line: Approve the guest population and timeout consequence before the bulk action. Keep a requested clean shutdown separate from the documented hard-stop fallback and from confirmation that an application has closed safely.

Source fact: what the authority says

The Proxmox pvenode reference defines pvenode stopall as stopping VMs and containers on the node. Its --vms option limits the operation to the specified guest IDs. The shutdown timeout defaults to 180 seconds for each guest, after which the operation aborts or forces a hard stop depending on --force-stop, which defaults to enabled. The bulk-operation guidance says guests still running are hard stopped unless the force-stop parameter is explicitly set to zero.

What the source does not establish

This article covers the documented bulk-stop options, not an application-consistent shutdown guarantee or a complete high-availability maintenance procedure. It does not authorize stopping an unidentified guest or assume that a timeout proves the guest cannot recover normally.

Applicability questions

• Which exact node and guest IDs are authorized for the maintenance action?
• What application shutdown requirements apply to each guest?
• What timeout and hard-stop consequence has the workload owner approved?
• Which guests and services must remain running outside the selected population?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a guest-selection record containing the node, guest IDs, workload owners and intended shutdown behavior. Have another operator compare it with the current inventory immediately before the action. Keep guests outside the maintenance scope explicitly listed where confusion is possible.

Choose the timeout and hard-stop policy deliberately. For a proposed no-force rehearsal, use the documented disabled force-stop branch on disposable guests and define who investigates a guest that remains running. For an approved hard-stop case, obtain the workload owner’s acceptance of that consequence before execution rather than relying on the default.

Prepare one cooperative test guest and a separately controlled timeout case. Select the test method with the virtualization and application owners without disabling operational recovery controls. Record which observation distinguishes requested shutdown, stopped guest and completed application maintenance.

Keep startup and service return as separate approved steps. Preserve the original guest state and agree how to resume an interrupted rehearsal. Do not combine an unexplained shutdown failure with unrelated CPU, storage or networking changes merely to make the bulk action finish.

Verification and evidence

Proposed verification: confirm the effective node, guest list, timeout and force-stop setting before the run. Observe each disposable guest through the selected shutdown branch and record whether it stopped normally, remained running or was forcibly stopped. Retain the corresponding task result and timestamps.

Check an out-of-scope control guest where the approved plan requires it. After the separately approved restart, run the harmless application checks and compare them with the initial state. Keep task completion and application acceptance separate, preserving timeout cases as findings rather than declaring the entire maintenance successful from one command result.

Official references

• Proxmox — pvenode(1) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.