linstor-server: replicated block storage managed as a software-defined layer

A storage orchestration layer above DRBD

LINSTOR, developed by LINBIT, is open source software that manages replicated volumes across a group of machines. It natively integrates with Kubernetes and other platforms, and it is designed to manage block storage devices for large Linux server clusters, typically to provide persistent and highly available Linux block storage for cloud native and hypervisor environments.

The repository `linstor-server` is the source for that system, and the primary language is Java. The project description calls it high performance software-defined block storage for container, cloud and virtualisation, fully integrated with Docker, Kubernetes, Openstack and Proxmox.

The history explains the architecture. LINSTOR started as a DRBD resource file generator which conveniently also created LVM or ZFS volumes. Over time it grew, and the growth went in two directions. South-bound features include snapshots, LUKS, dm-cache, dm-writecache and NVMe storage layers. North-bound drivers integrate directly with platforms including CloudStack, Kubernetes, OpenNebula, OpenShift, OpenStack, Proxmox VE and VMware.

That two-direction framing is the clearest description of the project. The south-bound side is about what a volume is made of, and the north-bound side is about who is allowed to ask for one. A storage system that is good at both is what makes it a platform rather than a script, and it is also what makes it more than the DRBD resource generator it started as.

The licence is GPL-3.0, with the `COPYING` file at the repository root, and the documentation home is `docs.linbit.com/docs/linstor-guide/`.

Controller and satellite, with a split data and control plane

The component model is simple enough to hold in your head, and it is the thing to understand before anything else.

A LINSTOR system consists of multiple server and client components. The LINSTOR controller service manages the configuration of the LINSTOR cluster and of all of its managed storage resources. The LINSTOR satellite service manages the creation, modification and deletion of storage resources on each node that provides or uses LINSTOR-managed storage resources.

So one service holds the state, and the other does the work on the machines. The features list calls this out as separate data and control planes for maximum data availability, and it is worth taking seriously, because the split is what lets a cluster keep serving storage when a controller node is being restarted or replaced. You can make the controller service highly available by installing it on multiple nodes.

Management happens two ways. You can drive the system directly with a command line client utility that talks to the active LINSTOR controller. Or you integrate LINSTOR into the storage architecture of another system such as Kubernetes, CloudStack, OpenNebula or Proxmox VE, and that system drives it instead.

All communication between LINSTOR components uses LINSTOR's own network protocol, based on TCP/IP network connections. The two diagrams the README links, one of the components and one of the software stack, exist because this arrangement has more moving parts than a single daemon and a config file, and a picture communicates the topology faster than prose.

Three nodes, one of which can be a Raspberry Pi

The deployment constraints are stated clearly, and this is the part to read before anything else.

If you want the entirety of the feature set, such as quorum, DRBD replication and others, you need at least three nodes. A third node used for quorum purposes can be diskless, and something as basic as a low-powered single-board computer such as a Raspberry Pi could serve.

At least one node in the cluster should have the LINSTOR controller service and the LINSTOR client software installed, while all nodes should have the LINSTOR satellite service installed.

That is a real operational constraint and it shapes who can use this. A two-node cluster, which is the smallest thing most people think of as high availability, cannot provide the full feature set. The three-node requirement exists because quorum needs an odd number of voters to avoid split brain, and the diskless witness is what lets you have three without paying for three sets of disks.

The DRBD dependency is a separate decision. LINSTOR can also perform disk operations without using DRBD. However, if you need data replication with DRBD, LINSTOR requires DRBD version 9 installed on the LINSTOR satellite nodes.

The full installation guide is the LINSTOR User's Guide, and the README links a section of it on making the controller highly available. The documentation also links the DRBD User's Guide for the DRBD 9 installation itself.

For a team evaluating this, the practical sequence is: decide whether you need quorum and DRBD replication, count your nodes, and if you are short, add the diskless witness rather than giving up on the feature set.

The plugin table is the real integration surface

The plugin table is the most practically useful part of the README, because it is the answer to the question every adopter has first, which is whether it talks to my platform.

Nine integrations are listed. CloudStack. iSCSI, with its own repository at `LINBIT/linstor-iscsi`. Kubernetes. OpenNebula. OpenShift. OpenStack. Oracle Linux Virtualization Manager. Proxmox VE. And VSAN, the VMware integration.

Each row links to the relevant section of the LINSTOR User's Guide, with the iSCSI plugin pointing at its own repository instead. The shape of the table tells you something about the architecture: the north-bound drivers are where LINSTOR meets an existing orchestrator, and the orchestrator's own model of storage is what LINSTOR has to fit into. A Kubernetes PersistentVolume, an OpenStack Cinder volume and a Proxmox disk are different requests for the same underlying replicated block device, and the plugin is the translation layer.

The features list also names a REST API for integrating or customising to your needs, which is the escape hatch when no plugin fits. LDAP authentication is supported for the control plane.

On the storage side the list is broad. Network replication through DRBD integration. LVM snapshot support. LVM thin provisioning. RDMA. Management of persistent memory. ZFS support including thin provisioning. And NVMe over fabrics.

The key architectural claim is the file system independence. You choose your own Linux file system and LINSTOR is agnostic to the layers above it. That is what makes the tiered storage support work, where multiple storage pools hold different tiers of disk, and what makes online live migration of back-end storage possible, moving a volume from one pool to another without taking the workload down.

Building the server from a multi-module Gradle tree

The repository is a large Java project with a build that reflects its history.

The Gradle build is at the root with `build.gradle`, `settings.gradle`, `gradlew` and `gradlew.bat`, and there is a `gradle.lockfile` for dependency locking. There is also an Ant `build.xml` and a `build.gradle` alongside it, which is a sign of a project that has migrated build systems over time without discarding the old one. There is a `linstor.spec` for RPM packaging and a `debian/` directory for Debian packaging, so the project ships native packages for both ecosystems.

The module layout is extensive. There are `controller/`, `satellite/` and `server/` directories, `linstor-common`, and a `jclcrypto/` directory, which is a vendored cryptography library. The `src/` directory is at the root alongside the modules, and `test-support/` and `virter/` are the test infrastructure. The `virter/` name refers to a virtualisation-based test environment, and `test-support/` is where shared test fixtures live.

The Makefile at the root is for packaging rather than compilation. It builds container images, with `Dockerfile.controller` and `Dockerfile.satellite` as the two inputs, and it publishes to a registry at `drbd.io` with the architecture appended when `ARCH` is set, so the same Makefile produces multi-arch images. The image paths are `linstor-controller` and `linstor-satellite`, with a `DOCKER_TAG` that defaults to `latest`.

The version handling is worth noting because it explains the release tags. The version defaults to `git describe --tags` output with the leading `v` stripped and the git hash suffix rewritten, so a build carries the tag it was made from, and the Debian version replaces hyphens with tildes because that is what the Debian version scheme requires.

Continuous integration is visible in the repository, with a `Jenkinsfile`, a `.gitlab-ci.yml` and a `.gitlab/` directory, so the project is built on both Jenkins and GitLab CI. The `CHANGELOG.md` and a separate `CHANGELOG-OPENAPI.md` exist, the latter tracking changes to the REST API surface.

Version 1.35 and the two support routes

The release history is steady and the project is clearly alive.

The three listed releases are v1.35.0 on 2026-08-27, v1.35.1 on 2026-09-09 and v1.35.2 on 2026-09-14. The last push to the repository was on 2026-10-14 and the repository is not archived. The 1.35.x line, with three releases inside three weeks, shows a regular release train and an active user base.

The README also carries a status badge marking LINSTOR as Active, and links to an enterprise support offering from LINBIT alongside a community forum. That dual arrangement is the standard shape for an infrastructure project that a company both sponsors and supports commercially, and it is worth understanding before you rely on it: the community forum is where support happens, and the paid support is a separate arrangement with the vendor.

For a procurement or platform decision, the relevant point is that the code is GPL-3.0 and the documentation is public, while the operational support is not. A team that wants to run this without a commercial relationship with LINBIT is entirely able to do so, and the constraint is your own time and the three-node architecture, not a licensing lock.

The README's support section says that for individual or development use, you can use the LINSTOR forum topic within the LINBIT community forums to get support, which confirms the split between community and commercial paths.

Editorial conclusion

linstor-server fits a storage team running Linux clusters that need replicated block volumes with live migration between back-end tiers, and that already have DRBD in mind or are prepared to adopt it. It does not fit a small deployment, because the documentation is explicit that at least three nodes are needed for the full feature set, and it does not fit a shop that wants storage replication without the DRBD dependency, even though the project can perform disk operations without it. Verify first that your node count and layout satisfy the three-node quorum requirement including the diskless witness node, that DRBD 9 is installed on the satellite nodes if you want replication, and that the north-bound plugin for your platform is on the list, since the plugin set is what actually connects LINSTOR to Kubernetes, OpenStack, Proxmox, OpenNebula or VMware.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. LINBIT/linstor-server on GitHub
3. Project website
4. README
5. Releases