Incus - After canonicals takeover of LXD a fork of it called Incus was created. Supporting both virtual machines and linux containers. Free open-source with paid support. https://github.com/lxc/incus
virt-manager - For home usage without clusters and the like a simple Linux host with kvm/qemu/libvirt/virt-manager usually works just fine. https://github.com/virt-manager/virt-manager
Proxmox - KVM/LXC Hypervisor based on Debian. Supports clustering and High-Availability. Free open-source with paid support.
https://github.com/proxmox
Harvester is a modern, open, interoperable, hyperconverged infrastructure (HCI) solution built on Kubernetes.
It is an open-source alternative designed for operators seeking a cloud-native HCI solution. https://github.com/harvester/harvester
What’s the background of the lxd-incus fork? On the project page they just state that it was forked after Canonical took over lxd - but what does that mean, exactly? How did they take over an open project? Was there a technical reason for a fork?
I’d say from a business perspective this is the major thing: Real license of LXD
Per the commit message performing the re-licensing, all further contributions will be under the AGPLv3 license and all contributions from Canonical employees have been re-licensed to AGPLv3.
However, Canonical does not own the copyright on any contribution from non-employees, such as the many changes they have imported from Incus over the past few months. Those therefore remain under the Apache 2.0 license that they were contributed under.
As a result, LXD is now under a weird mix of Apache 2.0 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other.
This is likely to make it very “fun” for anyone performing licensing reviews to evaluate LXD for adoption in their environment.
Some alternatives:
Incus - After canonicals takeover of LXD a fork of it called Incus was created. Supporting both virtual machines and linux containers. Free open-source with paid support.
https://github.com/lxc/incus
virt-manager - For home usage without clusters and the like a simple Linux host with kvm/qemu/libvirt/virt-manager usually works just fine.
https://github.com/virt-manager/virt-manager
Cockpit Project - Cockpit can be used to manage both virtual machines and podman. Personally I use it in tandem with virt-manager.
https://github.com/cockpit-project/cockpit https://github.com/cockpit-project/cockpit-machines https://github.com/cockpit-project/cockpit-podman https://github.com/oVirt/cockpit-ovirt
Proxmox - KVM/LXC Hypervisor based on Debian. Supports clustering and High-Availability. Free open-source with paid support. https://github.com/proxmox
There’s also harvester. The spec requirements are pretty heavy compared to some of the other options though.
Harvester is a modern, open, interoperable, hyperconverged infrastructure (HCI) solution built on Kubernetes.
It is an open-source alternative designed for operators seeking a cloud-native HCI solution.
https://github.com/harvester/harvester
Nutanix has its community edition which is free.
I find mentions on their homepage that they love open source but I can’t find any repository for the hypervisor itself.
Nutanix AHV is based upon CentOS KVM.
https://www.nutanixbible.com/5a-book-of-ahv-architecture.html
I’m not sure if it’s open source, but it’s free.
What’s the background of the lxd-incus fork? On the project page they just state that it was forked after Canonical took over lxd - but what does that mean, exactly? How did they take over an open project? Was there a technical reason for a fork?
I’d say from a business perspective this is the major thing:
Real license of LXD
Per the commit message performing the re-licensing, all further contributions will be under the AGPLv3 license and all contributions from Canonical employees have been re-licensed to AGPLv3.
However, Canonical does not own the copyright on any contribution from non-employees, such as the many changes they have imported from Incus over the past few months. Those therefore remain under the Apache 2.0 license that they were contributed under.
As a result, LXD is now under a weird mix of Apache 2.0 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other.
This is likely to make it very “fun” for anyone performing licensing reviews to evaluate LXD for adoption in their environment.
Grabbed from this blog https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/