clustvirt/view/static/home.gohtml

{{ define "content" }}
  <h3>What is this?</h3>
  <p>
    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.
  </p>
  <p>
    The aims of this project are:
    <ul>
      <li>Base OS Agnostic. If it can run libvirtd, this should be able to control it on some level</li>
      <li>Open source, always</li>
      <li class="notimpl">Control the Virtual Machine life cycle on one or more libvirtd hosts</li>
      <li class="notimpl">Add clusting capabilities to libvirtd host, including;</li>
      <li class="notimpl">Migration of VMs</li>
      <li class="notimpl">Syncronizing secrets</li>
      <li class="notimpl">Syncronizing VLANs, bridges, host only networking</li>
      <li class="notimpl">Sharing HA storage availability</li>
      <li class="notimpl">Locking shared resources like disks</li>
      <li class="notimpl">Starting VMs marked for HA on another host when one goes down</li>
      <li class="notimpl">Manage a library of Cloud-init resources and templates to build new VMs quickly</li>
      <li class="notimpl">Local Storage management, including local directory, lvm, zfs (if installed)</li>
      <li class="notimpl">Advanced Storage management, such as Ceph, glusterfs, drbd, iscsi, nfs</li>
      <li class="notimpl">Storage syncronization of local disks between hosts (zfs snapshots, lvm snapshots, rsync)</li>
      <li class="notimpl">Backup scheduling, creation, restoration</li>
    </ul>
  </p>
  <p>
    What this project does not, but may someday do (future goals):
    <ul>
      <li>Install the OS which libvirtd is running on</li>
      <li>Install/provision libvirtd on a host that does not have it installed</li>
      <li>Tools to move from one vendor to clustvirt/libvirtd</li>
      <li>VM templates for common aspects of VM creation and management, like appliances</li>
      <li>External tool access that can be used to manage things that are not managed here (cephadm dashboard, for instance)</li>
    </ul>
  </p>
  <p>
    What this project will NEVER do, even if asked really nicely:
    <ul>
      <li>Kubernetes</li>
      <li>Application container management (docker, podman, etc)</li>
      <li>Become an OS</li>
      <li>Have a paywall</li>
      <li>Vendor lock-in</li>
      <li>Become a commercial entity (even indirectly)</li>
      <li>Anything that does not have an Open Source standard behind it</li>
      <li>Directly control a guest Operating System</li>
    </ul>
  </p>
  <p>
    Why does this even exist?
    <ul>
      <li>Broadcom buying VMWare, and VMWare losing a free teir for homelabbers pissed me off</li>
      <li>Vendor lock-in pisses me off</li>
      <li>Even good open source Hyperconverged systems (Proxmox, as an example) exhibit a form of vendor lock-in</li>
      <li>Libvirt is terrific, has the functionality for everything those other providers do, but there really is not a
      great option for those dipping their toes into Open Source</li>
      <li>Its fun to build things that solve a need</li>
      <li>I really want to do it</li>
    </ul>
  </p>
  <p>I recently created a <a href="http://redd.it/1bct15z">post</a> 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??"</p>
  <p>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.</p>
  <p>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.</p>
  <p>I will not let that happen here</p>
  <p>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.</p>
  <p>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.<p>
{{ end }}