{{ define "content" }}

What is this?

Clustvirt (work in progress name) aims to be the agnostic cluster controller for libvirtd. The server component is used to display both the WebUI and run the REST API used to control one to many libvirtd hosts to manage virual machines, LXC containers (through libvirtd), gather information about each host, and monitor each host.

Project Goals

What this project does not, but may someday do (future goals):

What this project will NEVER do, even if asked really nicely:

Why does this even exist?

I recently created a post on reddit announcing that I was building this, and while the majority of responses were supportive, even offering features that may enhance what I originally set out to do, many responded with "Why do we need another one??"

Besides the list above about why this exists, I wanted to clarify a few things those individuals did not seeem to get: This is not a rebuild of Proxmox, Cloudstack, VMWare, Harvester or any of the other "Hyper-converged Infrastructer Operating System" offerings out there. This will not take over your base operating system machine, just act as a cluster manager and interface to access the existing libvirtd instances on those machines, nor will it prescribe a set of requirements that make it hard to move your own infrastructure around.

At the heart of this project is that I hate the enshitifiation of Open Source that has been going on, where its just another way to make money and control the eco system. RedHat tried to do it by locking down their source code, Proxmox does it by making sure anything you do on Proxmox is tied to Proxmox (no offense to Proxmox), and even Hashicorp, who I loved so dearly, changed from a pure Open Source licensing model to one that protects the business over the community.

I will not let that happen here

This project will seek to use the Unix philosophy, of building off of existing standards, combining tools, and having one tool do one job well. This does not mean there will be one application for each aspect of the job, but that this application stack will manage Libvirtd well, and have individual and configurable paths to manage each sub aspect of the libvirt stack. This stack will not create a Ceph cluster for you, it leaves you to do that. It will not even talk to a ceph cluster. It will, however, let you add that cluster via configuration options to define it as a storage pool that libvirt can use.

If you want something that will allow you to use a single interface to create all sub aspects that can be used by libvirt (managing all firewall rules, creating a ceph cluster, etc.), use something like Proxmox which includes that builtin functionality. This isn't the stack for you.

{{ end }}