- 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. -
+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.
- 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.
+
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/Single-solution/turnkey/Operating System" + offerings out there. This will not take over your base operating system + on your 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.
+