ProxmoxVE on Margrop Blog

Proxmox VE 9.2 Is Out: Not Just a New Kernel, but a Cluster That Can Start Balancing Itself

Sat, 23 May 2026 12:46:00 +0800

Short version

Proxmox VE 9.2 was officially released on May 21, 2026. On the surface it is a platform refresh: Debian 13.5 Trixie, Linux kernel 7.0, QEMU 11.0, LXC 7.0, ZFS 2.4, and updated Ceph options. The more interesting story is operational: dynamic load balancing through CRS, safer HA maintenance with arm/disarm, a much stronger SDN fabric story, web-based custom CPU model management, and many smaller fixes around guests, storage, security, and automation.

If you run a single-node homelab, Proxmox VE 9.2 may not feel dramatic on day one. If you operate a multi-node cluster with HA resources, Ceph, software-defined networking, custom CPU compatibility requirements, Windows secure boot, external automation, or strict maintenance windows, this release deserves a careful read.

This article summarizes the official Proxmox VE 9.2 release and adds an operator’s view: what changed, what problem each change addresses, what to test before upgrading, and when it is reasonable to wait. All hostnames, addresses, cluster names, accounts, and command outputs are placeholders. No private environment details are included.

Upgrading PVE 8 to 9 Without Brute Force: Let an Agent Drive It, or Follow This Manual Checklist

Tue, 12 May 2026 19:00:00 +0800

Short version

Upgrading Proxmox VE 8 to 9 is not just copying a few commands. It is a major system upgrade from Debian Bookworm to Trixie, from PVE 8.4 to PVE 9.x, with kernel, storage, networking, Ceph, and HA behavior in the blast radius. The fastest practical path is to let Codex, Claude, OpenClaw, HermesAgent, or a similar Agent handle checks, command sequencing, logging, and post-upgrade verification. The human operator still needs to approve repository changes, package removals, configuration prompts, reboot timing, and recovery decisions. If you prefer doing everything by hand, the second half of this article gives a concrete manual checklist.

This article is for two groups of operators. The first group already uses Agents over SSH and wants a scoped one-sentence task for upgrading PVE. The second group prefers typing every command manually and wants a clear, ordered procedure with the main risk points called out.

All hostnames, addresses, repositories, tokens, and accounts in this article are placeholders. Replace values such as <PVE_NODE>, <BACKUP_TARGET>, and <ADMIN_CONSOLE> with your own environment. Before touching a production host, read the official Proxmox documentation and verify that your backups are restorable.

Adding Proxmox VE local-lvm Usage and Link-Speed Monitoring to Uptime Kuma

Tue, 05 May 2026 17:20:00 +0800

Short version

Proxmox VE local-lvm is usually an LVM-thin pool, not a normal mounted directory, so df -h is not enough to catch it before it becomes full. Network link speed is another quiet failure mode: services may stay online while a NAS or router uplink falls back to 100 Mb/s and turns large file transfers into a crawl. A practical fix is to feed both checks into the Uptime Kuma you already use: expose a small HTTP health endpoint for local-lvm, and push link-speed status from the Proxmox host with an ethtool script.

This article walks through the design, the problems in a naive implementation, improved scripts, systemd units, Uptime Kuma configuration, verification steps, and safety notes. All addresses, tokens, host names, and environment-specific values are placeholders. Replace <PVE_HOST>, <KUMA_URL>, <PUSH_TOKEN>, and <INTERFACE> with values from your own environment.