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.
\nThe 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.
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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nChoose 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.
\nPrepare 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.
\nKeep 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.
\nProposed 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.
\nCheck 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact node and guest IDs are authorized for the maintenance action?\nWhat application shutdown requirements apply to each guest?\nWhat timeout and hard-stop consequence has the workload owner approved?\nWhich guests and services must remain running outside the selected population?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nChoose 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.\nPrepare 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nProxmox — pvenode(1) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [Proxmox pvenode reference](https://pve.proxmox.com/pve-docs/pvenode.1.html) 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact node and guest IDs are authorized for the maintenance action?\n\n- What application shutdown requirements apply to each guest?\n\n- What timeout and hard-stop consequence has the workload owner approved?\n\n- Which guests and services must remain running outside the selected population?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nChoose 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.\n\nPrepare 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.\n\nKeep 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCheck 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.\n\n## Official references\n\n- [Proxmox — pvenode(1)](https://pve.proxmox.com/pve-docs/pvenode.1.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/", "url": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Networks & Infrastructure", "item": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "@type": "ListItem", "position": 3, "name": "Bound Proxmox bulk guest shutdown before using stopall", "item": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/#article", "identifier": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/", "url": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/", "headline": "Bound Proxmox bulk guest shutdown before using stopall", "description": "The pvenode reference documents guest selection, a 180-second shutdown timeout and a default hard-stop branch.", "abstract": "The pvenode reference documents guest selection, a 180-second shutdown timeout and a default hard-stop branch. Review those choices before running a bulk maintenance action.", "articleBody": "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.\nSource fact: what the authority says\nThe 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact node and guest IDs are authorized for the maintenance action?\nWhat application shutdown requirements apply to each guest?\nWhat timeout and hard-stop consequence has the workload owner approved?\nWhich guests and services must remain running outside the selected population?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nChoose 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.\nPrepare 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.\nKeep 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.\nVerification and evidence\nProposed 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.\nCheck 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.\nOfficial references\n\nProxmox — pvenode(1) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:31+00:00", "dateModified": "2026-10-29T19:50:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/bound-proxmox-bulk-guest-shutdown-before-using-stopall/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Bound Proxmox bulk guest shutdown before using stopall" }, "articleSection": [ "Networks & Infrastructure" ], "keywords": [ "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 511, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Proxmox — pvenode(1)", "url": "https://pve.proxmox.com/pve-docs/pvenode.1.html" } } ] } }