Skip to main content
RunBook Academy

Proxmox VEXVIII · Maintenance & LifecycleMaintenance

Patching, repository management, and reboot planning

Intermediate⏱ ~14 min

What you'll learn

  • Manage Proxmox repositories correctly
  • Plan patching windows
  • Decide when to reboot
  • Handle major vs minor updates

Prerequisites

Verified against Proxmox VE 9.2.4 · Proxmox Backup Server 4.2.5 · Ceph Squid / Tentacle · Debian 13 (Trixie) · Linux kernel 7.0 (PVE 9.2 default) · 2026-08-07

Not yet marked complete on this device.

Why this matters in production

Unpatched Proxmox clusters are vulnerable. Patched clusters with no reboot plan are operationally dangerous. This lesson teaches both.

Repository configuration

The right repository choice determines what you receive:

RepoStabilityUse
enterpriseStable, testedProduction with subscription
no-subscriptionStableProduction without subscription
testUnstableLab only

Patching workflow

flowchart LR
  A[Check for updates] --> B[Review changelog]
  B --> C[Test in lab if possible]
  C --> D[Schedule maintenance window]
  D --> E[Apply to one node at a time]
  E --> F[Verify and reboot if needed]
  F --> G[Move to next node]
apt update && apt list --upgradable
apt full-upgrade -y

Major vs minor updates

Proxmox uses two channels:

  • Point releases: 9.2.1 → 9.2.4. Bug fixes, security patches. Generally safe to apply.
  • Major releases: 9.x → 10.x. New features, schema changes, upgrade path required.

Point releases are usually safe to apply without much planning. Major releases require careful planning, possibly DR testing.

Reboot decisions

Linux kernel updates require a reboot. Other updates may not.

[ -e /var/run/reboot-required ] && echo REBOOT REQUIRED || echo no reboot needed

When to reboot immediately:

  • Security kernel updates (CVEs in the kernel).
  • Updates to glibc, openssl, or other base libraries.
  • Updates that change kernel modules used by your workloads.

When to schedule:

  • Routine point releases with no critical CVE.
  • During off-peak windows.

Rolling maintenance

For multi-node clusters, patch one node at a time:

# On node 1
apt update && apt full-upgrade -y
# Verify cluster health
pvecm status
# Reboot if needed
systemctl reboot
# Wait for node to come back

# Repeat for node 2, 3, ...

This way the cluster always has quorum and most services remain available.

Production considerations

Common mistakes

  • Applying the test repository “in case I need it.”
  • Updating all nodes simultaneously.
  • Not rebooting after a kernel update.

Key takeaways

  • Disable test repo on production.
  • Apply updates one node at a time.
  • Reboot for kernel updates.

Knowledge check

Knowledge check · 3 questions

  1. Q1. How should updates be applied to a multi-node cluster?

  2. Q2. Test repository updates are safe to apply to production.

  3. Q3. Which file indicates that a reboot is required after updates?

Passing score: 75%. Answers are checked in this browser.