GlusterFS Was Supposed to Be Dead, Then It Came Back to Proxmox 9

The feature that disappeared and the people who refused to move on

Some removals feel less like cleanup and more like a door being slammed on a whole class of users. Proxmox 9 dropped GlusterFS as a storage type, and for anyone still running it, that was more than a line item in a changelog. It was a clear message that this is no longer where the platform wants to spend energy. The official path was obvious enough: move on, use Ceph or something else, and stop clinging to a storage stack the wider ecosystem has already started treating like old furniture in the basement.

Open-source communities don't always accept the official mood, though. One user created a custom storage plugin to restore GlusterFS functionality in Proxmox 9, with extra patches to bring back pieces like pvesm scan and GUI support. It's the sort of thing that makes people cheer and wince at the same time. On one side, it's exactly why people love this world: a feature gets cut, and someone with enough irritation and skill says, "Fine, I'll put it back myself." On the other, it raises an uncomfortable question nobody can dodge forever: if a platform removed support because the upstream story is shaky, does restoring it solve the problem or just buy time?

That tension ran through the whole conversation. Some people were grateful, some were skeptical, and some were almost mourning GlusterFS like an old friend that had become too hard to defend in public. The plugin was the occasion, but the thread was really about what happens when a storage technology still works for some people, still has emotional loyalty and still fills a niche, yet no longer fits the enterprise-first roadmap of the hypervisor around it.

That's what stings. GlusterFS didn't vanish because every user hated it. It vanished because support burden, upstream momentum, QEMU changes, and enterprise expectations all started pointing in the wrong direction.

"Maintained" is doing a lot of work here

The sharpest argument was over one word: maintained. It sounds simple until a storage system depends on it. One camp pointed to GlusterFS being end-of-life, or at least no longer maintained in any way they considered meaningful. The warning was blunt: it was pulled from Proxmox for a reason, and people should be careful before building anything important on a revived plugin. Someone basically said that a handful of people keeping code limping along after major corporate backing disappears is a different thing from a healthy, supportable project.

That view is harsh, but it's not irrational. Enterprise platforms need boring dependencies, meaning projects with active upstreams, predictable fixes, clear release paths, and enough usage to justify support effort. A storage plugin is more than a menu option. It touches VM disks, migrations, backups, scans, provisioning, and all the horrible edge cases that only show up when a customer is already angry. From that angle, Proxmox cutting GlusterFS was risk management rather than betrayal.

The other side pushed back. The creator argued that GlusterFS is still maintained, just slowly, especially after Red Hat stepped away. More importantly, they argued that Proxmox's removal was misguided because the QEMU block driver was only one piece of what the storage plugin did. Even if QEMU dropped its native Gluster driver, VMs could still run over GlusterFS through FUSE, roughly the same pattern as directory storage. For users already invested in Gluster, that matters. They weren't asking Proxmox to fork the world forever. They wanted the existing storage integration to stay useful where it still could.

So the disagreement came down to trust more than to whether the code exists. Is a project "maintained" if a few people are still fixing breakage? Is it "dead" if large vendors have shifted attention elsewhere but users can still run it? Is slow maintenance fine for a homelab but unacceptable for enterprise? The answer depends on who has to answer the phone when something breaks, which is why the same plugin can look heroic to one person and reckless to another.

GlusterFS now sits in a kind of open-source purgatory, not dead enough to disappear and not alive enough to inspire confidence. Loyal users can keep it moving, but every upgrade feels like checking whether the floor is still there.

The enterprise case against nostalgia

The enterprise argument came through cleanly. Proxmox is an enterprise-first platform, even if it has a huge non-enterprise following because of its open-source roots, so the project can't keep every feature alive just because a subset of users still likes it. If upstream QEMU drops behavior, if the Gluster ecosystem no longer looks healthy, and if enterprise support tickets don't show enough demand, keeping GlusterFS inside the official platform becomes hard to justify.

That's not emotionally satisfying, but it's how products survive. Supporting storage is nothing like supporting a forgotten theme option, because storage bugs are career-ending bugs. A flaky plugin can corrupt trust faster than almost anything else in a virtualization stack. Enterprise users want features vendors can stand behind without mumbling about patches, FUSE layers, and "well, technically it still works." When you're selling support, "technically" is not enough.

One commenter pointed to Proxmox's own stated view that enterprise support evaluations didn't show enough GlusterFS usage to justify the effort. That may sound cold, but it explains a lot. Software projects make choices based on where users are, where upstream is going, and where support costs are likely to explode. In that math GlusterFS became a bad bet. Ceph, object storage, and OpenStack-adjacent priorities won the room, and GlusterFS became yesterday's answer.

There was also blame for Red Hat and IBM, delivered with the bitter tone of people who remember when GlusterFS felt more central. One person said IBM left users out in the cold when it pulled the plug. Another said Red Hat had simply changed direction toward object storage and OpenStack. However you frame it, the feeling is the same: a technology people used and trusted lost institutional momentum, and downstream projects reacted accordingly.

Users hate that part most. A thing can still be useful and still get abandoned by the companies that once gave it legitimacy. The people running it are then left holding scripts, plugins, forum threads, and a choice between migrating before the ground shifts again and patching on because the current setup still does the job.

Why people still miss GlusterFS

The affection for GlusterFS wasn't imaginary. One person said they preferred it to Ceph because Ceph carries more overhead, while GlusterFS could be pointed at almost anything and just say, "alright." That line captures the appeal. GlusterFS felt approachable. It didn't demand the carefully sized cluster, fast network, drive planning, and operational discipline that Ceph often does. For smaller setups, labs, odd hardware, and people who wanted distributed storage without building a whole cathedral around it, GlusterFS had charm.

Ceph can be brilliant, but it's not casual. It wants a real design, with enough nodes, disks, network, and knowledge. GlusterFS, at least in its friendliest form, felt more forgiving. People still reach for it because it made certain messy setups possible without asking them to become storage architects overnight, even though it doesn't win every benchmark or check every modern enterprise box.

The nostalgia came with scars. Someone who once loved GlusterFS said that love ended at node failure, because rebuilds were the problem. Another user said they tried it with a dedicated 10Gbps network for inter-node communication and still found performance below expectations, and they also dropped it because it lacked native snapshots. Those are serious complaints. Performance, rebuild behavior, and snapshots are not decorative features when VM storage is involved; they are the difference between "this is clever" and "this is going to ruin a weekend."

That's why the conversation didn't turn into a simple celebration. GlusterFS has fans, but even the fans know where the bruises are. The plugin restores a path for people who still want it, but it doesn't rewrite history, make rebuilds pleasant, or magically add the operational confidence that disappeared with major vendor support. It gives users control, which is powerful, but control alone doesn't make it safe.

Still, there's something relatable about people refusing to abandon a tool because it no longer sits in the blessed lane. Infrastructure is full of these loyalties. People keep using what they understand, what fits their budget, what survived previous disasters, or what simply works well enough on hardware Ceph would sneer at. Sometimes that's bad engineering and sometimes it's practical wisdom. Usually it's both.

A plugin can revive a feature, but not an ecosystem

The custom plugin is useful and impressive, but it's no time machine. It can restore GlusterFS storage support inside Proxmox 9, patch scans, and bring back GUI behavior. It can make life easier for people who upgraded, or want to, without ripping out their storage stack first. For community users that's a genuine gift, turning "you can't" into "you can, with caveats," and in open-source land that matters.

The caveats are the whole story, though. Once support moves outside the main platform, users become part of the support model whether they like it or not. Every Proxmox update, QEMU change, GlusterFS quirk, FUSE behavior, and odd storage edge case becomes something to watch. The plugin may be solid today and annoying tomorrow through no fault of the person who wrote it. That's the tax you pay for restoring a feature the platform decided to leave behind.

There are really three sides here. The first says Proxmox was right: GlusterFS is too weak upstream, too low in enterprise demand, and too risky to keep carrying officially. The second says the removal was too blunt, since GlusterFS over FUSE still works without the QEMU driver and the storage plugin does more than one narrow block-driver job. The third says all of this misses the practical point: some people already have GlusterFS, already know its tradeoffs, and need a bridge rather than a sermon.

That third side may be the most honest. A plugin like this is a lifeboat or a pressure valve more than a revolution, one skilled user saying, "I know this isn't the future, but it's still my present."

The danger is pretending the lifeboat is a cruise ship. Running GlusterFS in Proxmox 9 through community patches may be fine for labs, migrations, niche setups, and people who fully understand the blast radius. It's harder to defend for fresh enterprise deployments without a very specific reason and a very sober support plan. The plugin brings back choice, but it doesn't bring back official confidence.

The episode feels raw because it shows the messy afterlife of useful software. A project fades, a vendor moves on, a platform cuts support, users protest, and someone writes code. The feature returns in a different form, carrying a label whether anyone prints it or not: community-resurrected, proceed with eyes open.

GlusterFS isn't quite dead, and it's not alive in the old way either. Somewhere in that uncomfortable middle, a custom Proxmox plugin is doing what open source has always done best, refusing to let the official ending be the only ending.