# Ganeti: cluster management for Xen and KVM without the hyperscaler

> Ganeti is a virtual machine cluster management tool built on top of existing virtualisation technologies such as Xen or KVM rather than replacing them, and its stated ambition is deliberately modest: a mid-range solution for three to a hundred nodes that just works, is self-contained and stays purely open source. It suits an organisation running its own virtualisation stack and wanting cluster operations, instance migration and capacity management without adopting a full cloud platform, and the packaging story is distributions first with source builds as the fallback.

**ganeti/ganeti** — Ganeti is a virtual machine cluster management tool built on top of existing virtualization technologies such as Xen or KVM and other open source software.

- Repository: https://github.com/ganeti/ganeti
- Website: http://www.ganeti.org
- Stars: 588 · Forks: 129
- Language: Python
- License: BSD-2-Clause
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ganeti-ganeti

## A layer on top of your hypervisor, not a replacement for it

Ganeti is described as a virtual machine cluster management tool built on top of existing virtualisation technologies such as Xen or KVM and other open source software. The README puts it more concretely as a virtualisation solution that Just Works, and that phrase is doing the real work, because it sets the expectation about what the project is for.

What Ganeti is, concretely, is the operational layer. You already have a hypervisor and a storage stack; Ganeti gives you a way to treat a group of machines as a cluster in which virtual machine instances are placed, moved, backed up and monitored as resources rather than as configuration files scattered across servers. The instance, the node and the cluster are the objects, and the tool is what makes them behave as a unit.

The alternative in this space is a full cloud platform, and the distinction between the two is what decides whether you want Ganeti at all. Ganeti is the infrastructure half. It assumes the virtualisation stack exists, it manages it, and it does not attempt to be a platform with its own API-first resource model and its own opinion about how applications should consume infrastructure.

That is a large part of why it survives. The virtualisation stack underneath is the part that changes, and the cluster management layer above it is the part that has to keep working as those stacks move. A tool that is deliberately downstream of the hypervisor can absorb those changes in one place, and the fact that Ganeti supports both Xen and KVM is the practical expression of that.

The licence is BSD 2-clause, the project is written in Python with a Haskell component in the topic tags, and the last push was on 2026-10-19 with a release of Ganeti 3.1.1 from 2026-04-27.

## The vision list, which is a statement of what the project refuses to be

The Our Vision section is short, and it is the clearest statement of the project's identity you will find anywhere.

The list reads: a virtualisation solution that Just Works, self-contained, aim for high-availability and reliability, mid-range virtualisation solution of three to 100 nodes, purely open source, low complexity, and available in major Linux distributions.

Two of those lines are constraints that rule whole categories of product out, and that is the point of writing them down.

The node count of three to 100 is the sharpest. A tool for three to a hundred nodes is not competing with the large-scale schedulers that allocate across thousands of machines, and it is not competing with the single-machine hypervisors either. It is aimed at a specific size of installation, the one where a person or a small team is running the cluster and needs the operations to be manageable without a platform team.

Purely open source is the other line that does work. It means the project is not built on a proprietary hypervisor and does not need one, which in turn is what makes the Debian, Ubuntu and Red Hat packaging paths viable at all. The repository itself carries a `COPYING` file and a `ganeti.cabal`, and the topic tags include haskell, so there is a Haskell component alongside the Python code.

Low complexity and self-contained are the goals that follow from the node count. A cluster manager for a hundred nodes that a two-person team runs has to be something you can hold in your head, which is a much harder design constraint than it sounds and which explains a lot about the shape of the tool.

The availability in major Linux distributions line is a consequence of the rest. If the project wants to be self-contained and low complexity for its users, it should not require the user to build a dependency stack, and the distribution packages are how that is achieved.

## Installation is a distribution package, and the source build is the fallback

The Getting Started section is organised by distribution, and the order of the list is the guidance.

Debian provides packages out of the box, and more recent packages can usually be found through Debian Backports. On Ubuntu, the README asks you to use a specific PPA if you would like to run Ganeti on Ubuntu. For Red Hat and CentOS based systems it points at a separate repository. Other distributions and source builds are covered by building Ganeti directly from source, with a link to the INSTALL instructions and a request to read them carefully.

Nightly and developer builds come last, and they carry a warning worth repeating: they are provided for Debian and Ubuntu off the project's master branch, they are only for testing purposes, they should not be used in production, and there is no upgrade path between nightly builds.

That last clause is the important one. A nightly build is a moving target built from a branch that changes continuously, so a node that was flashed with yesterday's build may not accept today's. For a cluster where the nodes are not all updated at once, that is a genuine operational hazard, which is why the wording is as blunt as it is.

The source build path is real rather than theoretical. The repository layout shows the Autotools machinery, with `configure.ac`, `autogen.sh`, `Makefile.am`, `autotools/` and `Setup.lhs`, alongside a `ganeti.cabal` for the Haskell side. The `autogen.sh` script is the entry point that generates the build system before the first configure, which is the standard arrangement for a project distributed as a tarball from a git repository rather than as a release tarball with the build system pre-generated.

The upstream guide covers further information about dependencies and cluster initialisation, and the repository also carries an `UPGRADE` file and a `NEWS` file, which are where you look to find out what a version bump actually changes for you.

## The repository layout shows a cluster tool, not a library

The top level of the repository describes the shape of the product more clearly than any documentation file does.

There is an `app/` directory, which is the user-facing command line, a `daemons/` directory for the long-running processes, and `src/` for the bulk of the implementation. `lib/` holds shared code, `tools/` holds the programs beyond the main one, and `man/` holds the manual pages. `doc/` is the documentation, `qa/` is the quality assurance tooling, `test/` is the test suite, and `devel/` holds the developer support files.

The daemon split is the interesting part. A cluster manager is not a single program. It has something that runs on every node, something that arbitrates between them, and something that stores the shared state, and a tool like Ganeti has to reconcile the state across machines that may be briefly partitioned. The `daemons/` directory is where that reconciliation lives, and the `app/` directory is the client that talks to it.

The `qa/` directory indicates that the project treats continuous checking as part of the product rather than as a nicety, and the `pydoctor.ini` file alongside `pylintrc` and `pylintrc-test` shows the documentation and lint configuration is checked in, with a separate configuration for the test code, which is the usual pattern when the tests deliberately do things the production code should not.

The `.devcontainer/` directory at the root is a more recent addition, and it is worth a mention because it reflects a change in how the project expects contributors to work. A development container means a contributor can get a working environment with the right dependency versions without assembling it, which matters for a project whose build crosses Python, Haskell and Autotools.

The `COPYING` file at the root is the BSD licence, and `CONTRIBUTING.md` is the contribution guide, which the README links along with the development guidelines in the wiki.

## The community channels, and what a yearly conference tells you

The community section is short, and the four channels it lists are worth reading as a picture of the project's size.

There are two mailing lists, ganeti-users and ganeti-devel, on Google Groups, so the split between using the tool and changing it is made explicitly. There is an IRC channel on the OFTC network, which is the network that most free software infrastructure projects use, and a yearly developer and users meeting called GanetiCon organised by the community, with its own site.

The existence of a yearly conference is a useful signal about a project in this category. Most cluster management tools are used by a handful of organisations and have no public gathering. A project that runs an annual meeting has a user base large enough to fill a room, and it has the kind of continuity where the same people come back year after year.

The mailing list split also tells you where the questions land. The users list is where the operational questions go, and a list with sustained traffic on it is an archive of real problems and real answers, which is often more useful than the documentation.

The contributing invitation is brief, which is unusual for a project of this age. It says to feel free to open GitHub issues, submit pull requests and check the development guidelines in the wiki. There is no CLA to sign and no elaborate onboarding, which is a low-friction way in and also an indication that the project is small enough that a contribution is reviewed by the people who wrote the surrounding code.

The homepage is ganeti.org, and the project is distributed under the BSD 2-clause licence, which is the same permissive terms the wider virtualisation infrastructure tends to use.

## Conclusion

Adopt Ganeti if you already run Xen or KVM and want cluster-level instance management, migration and capacity visibility without taking on a full cloud platform, and if you are comfortable with a tool that manages an existing stack rather than supplying one. Do not adopt it if you need a modern cloud platform, a hypervisor of its own or an API-first model, because Ganeti is explicitly a layer on top of what you already run, and check first whether a distribution still packages your target version, since the primary installation path is a distribution package rather than a self-built install.

## FAQ

### What is Ganeti?

It is a virtual machine cluster management tool built on top of existing virtualisation technologies such as Xen or KVM and other open source software. It provides cluster-level operations for instances, nodes and the cluster itself, and the licence is BSD 2-clause.

### What size of cluster does Ganeti target?

The project describes itself as a mid-range virtualisation solution of three to 100 nodes, alongside the goals of it Just Works, being self-contained, aiming for high availability and reliability, being purely open source and being of low complexity.

### How do I install Ganeti on Debian, Ubuntu and Red Hat?

Debian provides packages out of the box, with more recent ones usually in Debian Backports. On Ubuntu the README points to a specific PPA. For Red Hat and CentOS based systems it points at a separate repository. Other distributions and source builds are covered by the INSTALL instructions, and the project also publishes nightly packages for Debian and Ubuntu off the master branch.

### Can I use Ganeti nightly builds in production?

No. The README says the nightly packages are only for testing purposes, that you should not use them in production, and that there is no upgrade path between nightly builds, because they are built from a branch that changes continuously.

### What is in the Ganeti source tree?

The top level holds an app/ directory for the command line, daemons/ for the long-running processes, src/ and lib/ for the implementation, tools/ for the other programs, man/ for manual pages, qa/ for quality assurance tooling, test/ for the tests, and the Autotools build files with configure.ac, autogen.sh, Makefile.am and Setup.lhs alongside a ganeti.cabal for the Haskell component.

### Is Ganeti still being maintained?

The repository is not archived and the last push was on 2026-10-19. Recent releases are Ganeti 3.1.1 from 2026-04-27, Ganeti 3.1.0 from 2025-08-23 and a 3.1.0rc2 release candidate from 2025-03-14, and the project has a users and a devel mailing list plus a yearly GanetiCon meeting.

## Sources

- [ganeti/ganeti on GitHub](https://github.com/ganeti/ganeti)
- [License: BSD-2-Clause](https://github.com/ganeti/ganeti/blob/master/LICENSE)
- [Project website](http://www.ganeti.org)
- [README](https://github.com/ganeti/ganeti/blob/master/README.md)
- [Releases](https://github.com/ganeti/ganeti/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ganeti-ganeti