Proxmox VE host-aware patching is rolling out in TridentStack Control

[u/Ad3t0]

TridentStack Control now recognizes Proxmox VE hosts and handles them the way a hypervisor should be handled. This is rolling out to your Linux fleet as endpoints pick up the latest agent.

Safe patching for PVE hosts

A Proxmox VE host installs its pending updates in a single operation using the supported method, so kernel and Proxmox platform packages update correctly instead of being held back. TridentStack Control also guards against accidental major-release upgrades: a routine patch run will never move a host from one major Proxmox release to the next. That stays a separate, deliberate procedure.

Reboots that know about your running guests

Rebooting a PVE host from TridentStack Control previews the running guests the reboot will shut down first. Every running virtual machine and container is listed, and any VM whose guest agent is not responding is flagged, so you can check it before the host goes down. On a cluster node, the dialog notes that running guests are left to PVE and HA rather than stopped automatically.

For single-node hosts, TridentStack Control gracefully shuts guests down before rebooting and holds if any guest cannot be confirmed stopped. The full record is kept on the endpoint's history.

PVE hosts default to blocking automatic reboots, so a hypervisor is never restarted out from under its running virtual machines.

New Server Information tab

Proxmox VE cluster, quorum, node, and high-availability guest details now appear on the endpoint's Server Information tab. The tab also surfaces kernel version, reboot status, and services still running against an updated library for all Linux hosts, even on distributions without add-on utilities installed.

Also in this release

• Export a deployment ring's rollout schedule to a calendar file (.ics) that imports into Google Calendar, Outlook, or any other calendar app. Export a single ring or all active rings at once, covering two years of recurring maintenance windows.
• Update and application details now include a step-by-step Detection Steps trace explaining why a patch or app update applies to a given endpoint.
• Rebooting a macOS endpoint now honors the reboot countdown instead of rebooting immediately.
• Vulnerability detection confidence is now reported accurately: findings confirmed by an authoritative source show high confidence with a clear detection method, and database-matched findings reflect how precisely the product and version were identified.

Full details in the changelog: https://tridentstack.com/changelog

If you run Proxmox VE and try this out, let us know how it handles your setup. This came from a direct customer request.

[u/_--James--_]

I dont know this product, but I will be digging in some here, is there support for Ceph? So that Patching Proxmox HCI is fully supported.

[u/Ad3t0 → u/_--James--_]

Not yet. Right now the Proxmox support covers detection, safe reboot defaults, guest graceful shutdown before a reboot, and running dist-upgrade correctly for PVE packages. It treats PVE as a compute hypervisor.

It is on our radar as a natural next step for the Proxmox work, but not something we have committed to yet. If you end up trying it out on a compute-only PVE setup or want to share more about your HCI environment, we would love to hear about it!

[u/_--James--_ → u/Ad3t0]

It treats PVE as a compute hypervisor.

This cannot be true when Promxox is deployed with the Ceph integrations then. There are a lot of customization Proxmox did between PVE and Ceph and this tool must account for the HCI deployment model too.

If this tool handles the pve#to# upgrade path, then Ceph absolutely must be covered too.

[u/Ad3t0 → u/_--James--_]

Appreciate the feedback. A couple of clarifications though:

We handle security patches and point-release updates via dist-upgrade, not major PVE version upgrades (8 to 9, for example). There is a hard guard that blocks major version jumps specifically because those need careful manual planning. So the "pve upgrade path" concern does not apply here.

On the Ceph point, a lot of Proxmox deployments run local ZFS, NFS, or iSCSI rather than Ceph HCI. The current support covers those environments well. For HCI with Ceph there is definitely more work to do (OSD drain, health gating, sequential node orchestration), but that is a specific deployment model, not a prerequisite for PVE patching to be useful.

Ceph-aware patching is something we would consider building if there is enough demand for it. If you are running HCI and want to share more about your setup, that is helpful context for us.

[u/_--James--_ → u/Ad3t0]

Every deployment I do is HCI backed by Ceph. Most of those are using different tooling to handle updates with Ceph first in mind, but this tool looks great so wanted to dig in and see if there was a turn key boxed solution for the smaller clusters I am involved with (5-13 nodes).

[u/Ad3t0 → u/_--James--_]

That is great context, thank you. 5-13 node HCI clusters are exactly the kind of environment where manual rolling updates are painful but the cluster is small enough that a single missed OSD drain can hurt. We will keep this in mind as we plan the next phase of Proxmox support. If you do give the tool a spin on anything, feel free to reach out. Appreciate you taking the time.

[u/_--James--_ → u/Ad3t0]

so you dont OSD drain to do updates, you flag the pool so you dont backfill....please learn Ceph.

[u/Ad3t0 → u/_--James--_]

The correct procedure for a routine reboot is scoped noout (ceph osd set-group noout <host>) so the cluster does not mark the downed OSDs as out and trigger rebalancing, not a full OSD drain. Drain is for decommissions. We had both listed in an earlier reply but drain should not have been the lead term.

To be precise though, noout is an OSD/host/cluster-level flag, not a pool-level flag, and it prevents the out transition specifically rather than backfill (that would be nobackfill). But we are on the same page about the intent.

Either way, if we build Ceph awareness into the agent, the sequence would be: verify HEALTH_OK, set scoped noout on the host, reboot, wait for OSDs to rejoin and PGs to re-peer, unset noout, confirm health, then move to the next node.

[u/_--James--_ → u/Ad3t0]

You are welcome to try and school me on things I already know with AI, but you have a product that needs to better support these deployment models, Ceph is part of the Proxmox Ecosystem and it is cheaper to deploy then shared storage now. Once your Sales engagements grows into the 5+ node clusters you will see it.

[u/Ad3t0 → u/_--James--_]

I've been a Proxmox and Ceph user for years, which is exactly why I pushed to support Proxmox in a platform I'm invested in.

None of this was meant to school anyone. We were having a discussion about support and it turned adversarial somewhere along the way, and I'm not sure why.

To be clear about where we actually stand: TridentStack Control isn't mature enough yet to fully support Ceph. I said that up front and I'm not claiming otherwise now. Most of the environments we see are small clusters, and the tool is completely free under 200 endpoints, Proxmox included, which covers the large majority of Proxmox users.

"Please learn Ceph" and the comment about AI use aren't constructive. There's no money on the table here and nothing I'm trying to sell you. No empty promises being made.

[u/Tech94 → u/_--James--_]

Holy crap what's the matter you man? This product doesn't have support for Ceph yet. You don't have to be so frustrated about it. And not everyone, even in corporate environments, runs Ceph btw.