Rolling Updates
Rolling Updates automate the process of updating Proxmox VE nodes across a cluster sequentially, ensuring that workloads remain available throughout the update process. Instead of manually updating each node and handling migrations by hand, ProxCenter orchestrates the entire workflow.
Overview
Updating a Proxmox cluster typically involves: putting a node in maintenance, migrating VMs off, running apt upgrade, rebooting if needed, and moving VMs back. Doing this manually across 5, 10, or 50 nodes is tedious and error-prone. Rolling Updates handle this automatically with safety checks at every step.
Update Workflow
For each node in the cluster, ProxCenter performs the following steps in order:
1. Pre-Checks
Before starting, ProxCenter verifies:
- The cluster has enough capacity to absorb workloads from the node being updated
- No other node is already in maintenance or being updated
- All VMs on the node are migratable (no local-only resources blocking migration)
- The node is reachable via SSH, and the SSH user can run privileged commands without a password, see The SSH user and sudo
- The APT repositories are readable and consistent: an enterprise repository enabled without a no-subscription alternative is reported, and so is a file under
/etc/apt/sources.list.d/that APT cannot read - The root filesystem has room for the update: less than 2 GB free blocks the node, 2 to 5 GB free is a warning, and the free and total space are shown. A node with no pending update is never blocked on disk space
ProxCenter reaches each node over SSH on its management address: the interface that carries the host of the Proxmox URL, then the interface of the default gateway, then vmbr0, and only then any other bridge. A node whose first bridge sits on a Corosync or Ceph network is therefore reached on the network ProxCenter already talks to.
2. Workload Evacuation
Running VMs and containers are live-migrated to other nodes in the cluster. The guests of the evacuated node are spread across the candidate targets by projected load, memory weighing more than CPU, and a target is refused once its projected memory use would pass 90 %. Candidates exclude the source node, offline nodes, the nodes you excluded from the run and nodes in HA maintenance. The DRS affinity rules of the cluster, stored or derived from tags, are honoured with the same logic as the balancing engine, and the pre-flight plan names the targets the run will really use.
Migrations run through a worker pool sized by Maximum parallel migrations, 1 to 5 workers, 2 by default. HA-managed guests are moved by Proxmox itself when the node enters maintenance mode; when the node hosts HA guests and maintenance mode cannot be enabled, the node fails rather than being rebooted under them.
3. System Update
The node runs apt update && apt dist-upgrade to install the latest Proxmox packages. The progress bar follows apt's own position while it runs (Downloading packages 186/243, Configuring packages 56/245, Waiting for the apt lock (45s)), and each node row carries a collapsible apt output panel. The panel opens by itself when the step fails, with apt's last E: line appended to the error, so a 401 on the enterprise repository or an unsigned repository is readable on screen instead of a bare exit status 100. The full output is also kept in the log and visible in the Task Center.
4. Reboot (if required)
If a kernel update or other reboot-required package was installed, the node is rebooted. ProxCenter waits for the node to come back online and rejoin the cluster before proceeding.
With Wait for Ceph HEALTH_OK between each node enabled, the run then holds until Ceph has finished recovering, up to 5 minutes. Only HEALTH_ERR and the recovery checks hold the run: the noout flag ProxCenter set itself and unrelated warnings such as BLUESTORE_SLOW_OP_ALERT or MON_DISK_LOW do not consume the budget, and when the budget does elapse the message names the checks still pending.
5. Workload Restoration
After the node is updated and healthy, previously migrated VMs can optionally be migrated back to their original node.
6. Next Node
The process repeats for the next node in the cluster until all nodes are updated.
With Manual approval between each node enabled, the run pauses before each node. The node row shows an Awaiting approval chip, a banner names the node that waits, and an Approve button carrying the node name lets it proceed. The same button is offered in the detail dialog of the Task Center, so a run can be approved without reopening the wizard. Resume only resumes a paused run and never approves a node on its own.
Cancel is honoured while the run is paused or awaiting approval: the noout flag is unset, the SSH sessions are closed, and the run ends as cancelled, not failed.
Configuration
| Setting | Description | Default |
|---|---|---|
| Reboot policy | Always reboot, only if needed, or never | Only if needed |
| Restore VMs | Migrate VMs back to their original node after update | Enabled |
| Maximum parallel migrations | Number of guest migrations run at the same time while a node is evacuated, 1 to 5 | 2 |
| Manual approval between each node | Pause before each node until an operator approves it, from the wizard or the Task Center | Disabled |
| Wait for Ceph HEALTH_OK between each node | Hold after a node is back while Ceph is in HEALTH_ERR or recovering, up to 5 minutes | Enabled on a Ceph cluster |
| Timeout | Maximum time to wait for a node reboot before marking it failed | 10 minutes |
Every parameter of the wizard carries a tooltip that explains what it does. The Estimated time shown before the run opens a per-node breakdown on hover: fixed allowances, packages, migrations and reboot.
Monitoring Progress
The Rolling Update dashboard shows:
- A visual overview of all nodes with their current state (pending, updating, rebooting, completed, failed). Each node carries the Proxmox icon with a status dot, offline while it reboots and maintenance while it is in HA maintenance; a transitional state shows a spinner and a skipped node is informational, not a warning
- The current step being executed on the active node, with apt's own progress during the package upgrade and the apt output panel described above
- Live logs from the update and reboot process
- Estimated time remaining based on previous node durations
The verification step shows the cluster health as tiles (quorum, nodes online, Ceph) and, per node, the disk space, memory, load and services checks.
Closing the wizard while a run is in progress asks for a confirmation first. Finished runs stay listed in the Task Center with their full log, and a cancelled run reads cancelled there.
If a node fails to come back online after a reboot, the rolling update pauses and alerts you. It does not proceed to the next node to avoid risking cluster quorum.
Schedule rolling updates during a maintenance window. Even though VMs are live-migrated, there may be brief performance impacts during the migration and reboot phases.
Rolling Updates is available in the Enterprise edition.
Permissions
| Permission | Description |
|---|---|
node.manage | Required to execute updates and reboot nodes |
vm.migrate | Required to evacuate and restore workloads |
The SSH user and sudo
The orchestrator wraps every privileged command in sudo -n sh -c, so a non-root SSH user needs NOPASSWD: ALL. A per-command sudoers allowlist, including the one generated by Settings > SSH Commands, is not enough, and the pre-flight then reports that the SSH user lacks passwordless sudo. Either grant proxcenter ALL=(ALL) NOPASSWD: ALL (the generated sudoers template ends with that line, commented out) or connect as root. The SSH Commands settings page carries the same warning.
Beyond ProxCenter's own roles above, the connection's Proxmox API token needs Sys.Modify on the node so ProxCenter can refresh the package list (apt update). The built-in PVEAdmin role does not include it. See Connect Your Infrastructure for the one-line fix.