Column 1
Skip to content
Column 1

Proxmox Kernel 6.17 End of Support: VE 9 Upgrade Checklist

Short version: Proxmox will end support for the 6.17-based kernel series at the end of July 2026. For Proxmox VE 9 and other Debian Trixie-based Proxmox releases, kernel 7.0 is now the default supported kernel. Treat this as a planned maintenance change: inventory the nodes that still boot 6.17, validate recovery readiness, and roll the newer kernel through a cluster one node at a time.

What Changes at the End of July

Proxmox says it is ending support for the 6.17 series as Ubuntu upstream phases that kernel out and backporting fixes becomes increasingly costly. The same vendor notice identifies kernel 6.8 as the supported lane for Proxmox VE 8 and other Debian Bookworm-based releases only until the end of August, while kernel 7.0 is the current default for Proxmox VE 9 and other Debian Trixie-based releases.

Who Should Schedule This Work

  • Proxmox VE 9 hosts that still boot a 6.17-based kernel.
  • Clusters with HA, shared storage, replication, or live-migration dependencies.
  • Hosting and managed-service nodes where a delayed reboot can leave the running kernel behind installed packages.
  • Teams still operating Proxmox VE 8 on Bookworm, because the 6.8 support window also needs a separate upgrade plan.

Plan the Maintenance Window

  1. Record the kernel each node is currently booting and identify every workload that depends on that node.
  2. Confirm that the intended Proxmox VE 9 kernel 7.0 packages are available through the repository and subscription lane your environment uses.
  3. Check recent backup completion and a recovery path before changing a production host. A successful backup job is useful only when the team can locate and restore the required workload.
  4. Review cluster quorum, storage health, network paths, and guest placement so one node can be maintained without creating an avoidable HA event.
  5. Notify stakeholders of the node sequence, expected guest movement, validation window, and rollback decision owner.

Use a Rolling Cluster Sequence

Maintain one node at a time. Move or stop eligible workloads according to the environment's approved plan, place only that node into maintenance, restart it into the supported kernel, and wait for it to rejoin cleanly before moving on. Do not turn a kernel-support change into a simultaneous cluster reboot.

Validate Before the Next Node

  • The maintained host reports the intended supported kernel after reboot.
  • Cluster membership, quorum, storage, bridges, and expected VM or container states are healthy.
  • Representative customer workloads start and communicate normally.
  • Scheduled backup and monitoring services resume as expected.
  • The team records any driver, storage, or guest-compatibility concern before continuing the rollout.

Avoid These Traps

  • Do not assume an installed package means a host is already running the supported kernel.
  • Do not leave 6.17 as the long-term Proxmox VE 9 production kernel after its support window closes.
  • Do not combine this work with unrelated guest-platform, storage, or application upgrades unless the change plan explicitly connects them.
  • Do not use a maintenance window to make untested recovery changes. Keep the rollback and restore decision clear.

Related Proxmox Planning

Sources Checked

Bottom line: move Proxmox VE 9 production nodes away from kernel 6.17 before its support window closes, use a staged kernel 7.0 rollout, and validate cluster, workload, backup, and recovery health after every node.