Proxmox VEXVIII · Maintenance & LifecycleMaintenance
Patching, repository management, and reboot planning
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
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:
| Repo | Stability | Use |
|---|---|---|
| enterprise | Stable, tested | Production with subscription |
| no-subscription | Stable | Production without subscription |
| test | Unstable | Lab 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
Q1. How should updates be applied to a multi-node cluster?
Q2. Test repository updates are safe to apply to production.
Q3. Which file indicates that a reboot is required after updates?
Passing score: 75%. Answers are checked in this browser.