There is a table in the Ceph documentation that never makes it into a press release and that organises this autumn's work better than any roadmap: the version lifecycle table. It says Squid (19.2) —the branch underneath almost every hyperconverged cluster built in the last two years— has its estimated end of life on 19 September 2026. Fifty days from today. The part that hurts shows up on closer inspection: upgrading Ceph almost never fits into a single maintenance window.
We run Proxmox VE with Ceph in production across several datacenters, so this countdown lands on our own desk and we did the maths for ourselves before writing it down. Here is what came out: the real dates, the forced sequence and the order it runs in, two Tentacle changes that go unnoticed, and the specific order of commands. None of it is dramatic. What gets expensive is finding out at eleven on a Saturday night.
The three dates that call the shots
It all comes from the official release table. Future end-of-life dates are flagged as estimates, and they should be read that way: the project publishes an intention, and it has moved these dates before.
Read plainly: Squid got a maintenance release in mid-July and has seven weeks left. Tentacle has eight months of mileage and two maintenance releases behind it. Reef has been among the archived releases since March last year, meaning unmaintained; if your cluster is still there, that is a different and more urgent conversation.
On the Proxmox side things moved at their own pace. When Tentacle reached their repositories in January it lived only in test, clearly labelled as a preview. Not any more: Proxmox VE 9.2, released on 21 May, changed the default for fresh installations —pveceph install on a Ceph-free node and the wizard on a Ceph-free cluster now offer Tentacle 20.2.1— and a Proxmox developer confirmed in writing in July that it was marked stable with 9.2. Existing clusters do not move on their own, because the wizard keeps pinning new nodes to the release the cluster already runs. That part is still your job.
Why it is not one jump but three
Here is the knot. In a hyperconverged cluster Ceph does not upgrade on its own: it is tied to the Proxmox version underneath it. The official Squid-to-Tentacle guide requires Proxmox VE 9.1 or newer (with pve-manager 9.1.4 or later and Ceph packages 19.2.3-pve3 onwards). And the Proxmox VE 8-to-9 upgrade guide asks for the opposite at the other end: move Ceph to Squid before starting the hypervisor jump.
Put the two rules together and a sequence appears that nobody chooses: Ceph to Squid → Proxmox VE to 9 → Ceph to Tentacle. Three separate jobs, each with its own window and its own next-morning check. If you are on Reef and Proxmox VE 8, all three are ahead of you — and the hypervisor's 8 branch expires this August, which we covered two days ago in the article on the end of support for Proxmox VE 8. Two countdowns chained together —the 8 branch, which Proxmox dates only by month (2026-08), and Squid, which does have a day: 19 September— in an order that allows no shortcuts.
Upstream is slightly more permissive, incidentally: the Tentacle notes say you must be on Reef (18.2.z) or Squid (19.2.z) before jumping. But what Proxmox documents are two separate guides, Reef to Squid and Squid to Tentacle, and we go with the guides. In distributed storage, creativity is paid for in data.
Fifteen minutes of checks before deciding anything
Before putting dates on a calendar you need to know where you are starting from. This is done today, with the cluster idle and in broad daylight, not on the night of the window:
Those six outputs already tell you which step you are on, how many windows stand between you and Tentacle, and — this bit gets checked far too rarely — whether the jump will leave you without visibility. Let us get to it.
The module that disappears (and who is going to feel it)
Tentacle removes two manager modules: mgr/restful and mgr/zabbix. The release notes do not mince words: both had been deprecated since 2020, neither was actively maintained, and they were dragging vulnerabilities through their dependency chain. As a project decision we think it is the right one —ownerless code inside the component that sees everything ends up costing more than it gives— but if your Ceph monitoring goes through it, the day you upgrade the data stops and the alert you get is silence.
We monitor with Zabbix, and what we take from this is simple: monitoring belongs inside the upgrade plan, not in its aftermath. If ceph mgr module ls returns zabbix among the enabled modules, the replacement (the manager's own prometheus module, the agent route, or the integration Proxmox shipped this year, which we covered in this article) gets built and validated before the jump, not after. A cluster without metrics in the very week you just touched it is precisely when you need them most.
What actually changes in Tentacle
The list of new features is long; what actually moves the needle in a business cluster fits in four points, and three of them come with fine print:
- ✓Erasure coding optimisations (FastEC): partial reads and partial writes on erasure-coded pools, which is exactly where that kind of pool struggled most. The fine print: they do not switch themselves on. The
allow_ec_optimizationsflag has to be set per pool, and existing pools can only do so once OSDs and monitors have been upgraded. If you are unsure whether your pool should be replicated or erasure coded, we did that maths in replica 3 versus erasure coding. - ✓BlueStore gets better compression and a new, faster WAL. It is the kind of improvement you never see in a demo and do see in the write queue on a Tuesday morning. Nothing to do here: it comes with the jump.
- ✓The default erasure coding plugin moves from Jerasure to ISA-L, because Jerasure is no longer maintained. Note the nuance, which is what prevents surprises: it only affects clusters created on Tentacle or later. Clusters that upgrade keep their existing defaults and their pools are left alone.
- ✓mClock adds minimum IOPS thresholds when measuring each OSD's capacity (50 on spinning disk, 1,000 on SSD, both configurable). Translated: if a measurement comes out absurdly low, the scheduler stops believing it. It is one of those improvements you only appreciate if you have ever watched a cluster throttle itself because of a bad measurement.
And on that first point, a warning with a story behind it. In 20.2.0, setting allow_ec_optimizations on an existing erasure-coded pool brought down OSDs one after another on a real cluster —there is a public write-up of the incident, from January, with the crash in ECTransaction::WritePlanObj— and a wave of scrub errors showed up that turned out to be false positives: once optimisations are on, objects written earlier are no longer padded out to the stripe width and the scrub code got confused. Version 20.2.1, from April, ships fixes for that area (among them, refusing optimisations when the chunk size is not 4K-aligned) and the branch is already on 20.2.2. None of this is a reason to stay off Tentacle. It is a reason to set the flag on one pool, watch it for a week and carry on afterwards, rather than switching it on everywhere the same afternoon.
None of those four things alone justifies a maintenance window. The reason to jump is the same boring one as always: on the other side of September, Squid stops receiving fixes, and security fixes in the layer where your data lives are not optional.
The order of the jump, no mystery
The Squid-to-Tentacle sequence is in the official wiki and it is short. What is not in the wiki is the pacing: between steps you wait for the cluster to return to HEALTH_OK, and nobody is in a hurry.
Two warnings the wiki gives that are worth keeping in mind. If you use CephFS, the MDS daemons have their own choreography: disable standby replay, reduce the number of active ranks to one, stop the standby daemons, restart the one that is left, bring the standbys back up and finally restore max_mds and standby replay. And between steps 5 and 6 the cluster will tell you that all OSDs are running Tentacle but that require_osd_release is still behind: that warning is expected and clears with the command in step 6. Nothing is broken: the cluster is asking you to confirm you are not planning to go back.
That last point deserves one more sentence, because it is the uncomfortable part: in Ceph there is no real rollback once you have set the minimum OSD release. Your plan B is not "undo", it is restore. Which is why verified backups —and a restore somebody has actually timed— are part of the work this window involves.
Fifty days, laid out
Counting from today, 31 July, this is how we would lay out the work to reach 19 September without any drama:
- 1.This week: the six checks above. You know which branch you are on, which hypervisor version sits underneath and whether the
zabbixmodule is in play. Fifteen minutes, and you are no longer deciding blind. - 2.First half of August: the replacement monitoring, built and reporting in parallel. Plus a test restore against the clock, which is the plan B for everything else.
- 3.Second half of August: if you are still on Reef, Ceph to Squid. It is the precondition the Proxmox VE 8-to-9 upgrade wiki states in writing, not a friendly suggestion.
- 4.End of August: the hypervisor jump to 9, on its own and with Ceph already on Squid. With the caveat we argued two days ago: if you fall into any of the six cases where that jump is not for August, then Tentacle is not for September either. Arriving late to both in order beats arriving on time to one and breaking the other.
- 5.First two weeks of September: Squid to Tentacle, following the sequence above, with the cluster reviewed the next morning. Leave the last week free on purpose; that is what the margin is for.
And if you do not make it, nothing catastrophic happens on the 20th either: an end of life is not a time bomb: it marks the point from which nobody fixes the flaws that turn up. What does happen is that risk piles up without warning, and in distributed storage you tend to notice late and all at once.
The boring part is the part that saves the cluster
Ceph upgrades have a bad reputation they mostly do not deserve: there are few steps, they are documented, and the project has spent years deliberately making them boring. What does deserve respect is the planning, because the jump almost never comes alone. Our rule running these clusters is short: one thing per window, the cluster green before every step, monitoring alive from minute one, and a date on the calendar with somebody's name on it. Nothing glamorous, and it works: on Monday morning nobody notices there was work over the weekend.
Sources (verified): branch dates and estimated end of life (Squid 19.2 released 26-09-2024, latest 19.2.5 on 14-07-2026, estimated end of life 19-09-2026; Tentacle 20.2.0 on 18-11-2025, 20.2.2 on 16-06-2026, estimated end of life 18-11-2027; Reef 18.2 among the archived releases) — Ceph releases index. Removal of mgr/restful and mgr/zabbix ("deprecated since 2020", unmaintained and suffering from vulnerabilities in their dependency chain), default erasure coding plugin changing to ISA-L for new clusters only, the per-pool allow_ec_optimizations flag, mClock thresholds (50 IOPS on HDD, 1,000 on SSD) and the requirement to start from Reef or Squid — Tentacle release notes. FastEC and BlueStore (compression and WAL) — v20.2.0 Tentacle announcement. Requirements and jump sequence on Proxmox (PVE 9.1 or newer, pve-manager 9.1.4, Ceph 19.2.3-pve3, noout, order monitors → managers → OSDs → MDS, require-osd-release) — official Ceph Squid to Tentacle wiki. Status on Proxmox: the 09-01-2026 announcement with Tentacle in the test repository only and Squid "supported until September 2026 for the time being", plus a Proxmox developer confirming on 03-07-2026 that it was marked stable with Proxmox VE 9.2 — official Proxmox forum thread. Tentacle 20.2.1 as the default for fresh installations since Proxmox VE 9.2 (21-05-2026), with existing clusters pinned to the release they already run — official Proxmox VE roadmap. OSD crashes when enabling allow_ec_optimizations on an existing erasure-coded pool in 20.2.0, with the crash in ECTransaction::WritePlanObj, and the scrub errors caused by the change in object padding — public write-up of the incident (13-01-2026). Fixes in that area, and optimisations refused for non-4K-aligned chunk sizes, in 20.2.1 of 06-04-2026 — v20.2.1 release notes.
Do you have a Ceph cluster with a date on the calendar?
At everyWAN we design and operate distributed storage with Ceph in production, alongside Proxmox VE infrastructure spread across several datacenters. We look at your cluster, tell you how many windows stand between you and Tentacle and in what order they go — and if we see it will hold up perfectly well past September, we tell you that too.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN