GlusterFS Was Supposed to Be Dead. Then Someone Dragged It Back Into Proxmox.

# GlusterFS Was Supposed to Be Dead. Then Someone Dragged It Back Into Proxmox. ## The Feature That Disappeared and the People Who Refused to Move On There’s a certain kind of removal that feels 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 wasn’t just a line item in a changelog. It was a very clear message: this is no longer where the platform wants to spend energy. The official path was obvious enough. Move on. Use Ceph. Use something else. Stop clinging to the storage stack that the wider ecosystem has already started treating like old furniture in the basement. But open-source communities don’t always accept the official mood. 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. That’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, someone with enough irritation and skill says, “Fine, I’ll put it back myself.” On the other side, it raises the 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. Some were almost mourning GlusterFS like an old friend that had become too hard to defend in public. The post wasn’t just about a plugin. It was about what happens when a storage technology still works for some people, still has emotional loyalty, still fills a niche, but no longer fits neatly into the enterprise-first roadmap of the hypervisor around it. And that’s the real sting. 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. That word 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 the 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 top of a revived plugin. Someone basically said that a handful of people keeping code limping along after major corporate backing disappears is not the same thing as a healthy, supportable project. That view is harsh, but it’s not irrational. Enterprise platforms need boring dependencies. They need projects with active upstreams, predictable fixes, clear release paths, and enough usage to justify support effort. A storage plugin isn’t just 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 wasn’t betrayal. It was risk management. 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, the same rough pattern as using 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. The disagreement wasn’t really about whether code exists. It was about trust. 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 acceptable for a homelab but unacceptable for enterprise? The answer depends on who has to answer the phone when something breaks. That’s why the same plugin can look heroic to one person and reckless to another. There’s a kind of open-source purgatory here. Not dead enough to disappear. Not alive enough to inspire confidence. GlusterFS now lives in that weird middle space where loyal users can keep it moving, but every upgrade feels like asking 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. That means 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, if enterprise support tickets don’t show enough demand, then keeping GlusterFS inside the official platform becomes hard to justify. That’s not emotionally satisfying, but it’s how products survive. Supporting storage is not like supporting a forgotten theme option. 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 that 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 line 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. GlusterFS became yesterday’s answer. There was also blame thrown toward Red Hat and IBM, and it landed 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. That’s the part users hate most. A thing can still be useful and still get abandoned by the companies that once gave it legitimacy. Then the people running it are left holding scripts, plugins, forum threads, and a choice: migrate before the ground shifts again, or keep patching 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 perfectly. GlusterFS felt approachable. It didn’t demand the same kind of 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. It wants enough nodes, enough disks, enough network, and enough knowledge. GlusterFS, at least in its friendliest form, felt more forgiving. That’s why people still reach for it. Not because it wins every benchmark or checks every modern enterprise box, but because it made certain messy setups possible without asking users to become storage architects overnight. But the nostalgia came with scars. Someone who once loved GlusterFS said that love ended at node failure. 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. They also dropped it because it lacked native snapshots. Those aren’t minor 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. It doesn’t make rebuilds pleasant. It doesn’t magically add the operational confidence that disappeared with major vendor support. It gives users control, which is powerful, but control is not the same as safety. Still, there’s something deeply 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 that Ceph would sneer at. Sometimes that’s bad engineering. Sometimes it’s practical wisdom. Usually it’s both. ## A Plugin Can Revive a Feature, Not an Ecosystem The custom plugin is useful. It’s impressive. It’s also not a 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 upgrade without ripping out their storage stack first. For community users, that’s a genuine gift. It turns “you can’t” into “you can, with caveats.” In open-source land, that matters. But the caveats are the whole story. Once support moves outside the main platform, users become part of the support model whether they like it or not. Every Proxmox update, every QEMU change, every GlusterFS quirk, every FUSE behavior, every 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 when you restore 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: even without the QEMU driver, GlusterFS over FUSE still works, 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, not a sermon. That third side may be the most honest. Not every plugin is a revolution. Sometimes it’s a lifeboat. Sometimes it’s a pressure valve. Sometimes it’s 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 unless there’s a very specific reason and a very sober support plan. The plugin brings back choice. It doesn’t bring back official confidence. That’s what makes this whole episode feel so raw. It’s not just about storage. It’s about the messy afterlife of useful software. A project fades. A vendor moves on. A platform cuts support. Users protest. Someone writes code. The feature returns, but not in the same way. Now it carries a label, visible or not: community-resurrected, proceed with eyes open. GlusterFS isn’t quite dead. It’s not exactly alive in the old way either. And 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.