# Harvester: Kubernetes-native HCI for bare metal, built on KubeVirt and Longhorn

> Harvester is an Apache-2.0 hyperconverged infrastructure platform that runs VMs and containers on the same Kubernetes API. It installs from a bootable ISO onto bare metal, and its hardware floors are high enough to rule out most lab setups.

**harvester/harvester** — Open source hyperconverged infrastructure (HCI) software

- Repository: https://github.com/harvester/harvester
- Website: https://harvesterhci.io/
- Stars: 5,189 · Forks: 448
- Language: Go
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/harvester-harvester

## What Harvester replaces, and for whom

Harvester targets the operator who wants virtualization without a SAN. The README describes it as an open-source alternative for operators seeking a cloud-native HCI solution, running on bare metal servers with integrated virtualization and distributed storage. The pitch is that local, direct attached storage substitutes for external SAN arrays, which removes a storage fabric from the bill of materials and from the failure domain.

The audience is narrower than "anyone with VMs". The README's own hardware table asks for x86_64 with hardware-assisted virtualization, 8 cores and 32 GB of memory for testing, 16 cores and 64 GB for production, plus 250 GB of disk for testing and 500 GB in production at 5,000+ random IOPS per disk. It explicitly says laptops and nested virtualization are not officially supported, and recommends server-class hardware. That sentence does more work than the feature list: it tells you the project is aimed at people who can dedicate physical machines, not at developers who want a VM on a laptop.

The second audience is the Rancher user. The README lists integration with Rancher as a feature, with Harvester reachable through Rancher's Virtualization Management page so VM workloads sit alongside Kubernetes clusters. If you are already operating Rancher, Harvester is an extension of a control plane you have; if you are not, you are adopting two systems at once.

## Kubernetes as the automation language: KubeVirt, Longhorn and Elemental

The architecture is assembled from three named components, and the README is direct about which. Longhorn supplies distributed block storage for Kubernetes. KubeVirt is the virtual machine management add-on for Kubernetes. Elemental for SLE-Micro 5.3 is an immutable Linux distribution meant to remove as much OS maintenance as possible in a Kubernetes cluster. Harvester's own contribution is the composition: a bootable appliance that turns those pieces into a cluster you install rather than assemble.

The consequence is that the Kubernetes API is the interface. The README calls it a unified automation language across container and VM workloads. That means a VM is an object you manage the way you manage any other cluster resource, and the storage behind it is a volume in Longhorn's model. The README's storage section says volumes represent storage and that you can create, edit, clone or export one. This is the real difference from a traditional hypervisor: the management surface is declarative and shared with containers, not a separate appliance UI with its own API.

Networking follows the same pattern. Harvester supports a virtual IP and multiple NICs, and VMs reach the external network through a VLAN or untagged network. The hardware table adds the physical precondition: trunking of ports is required for VLAN support. A switch that cannot trunk is a hard stop, not a configuration annoyance.

For workload mobility, the README lists VM live migration with zero downtime, and backup, snapshot and restore to NFS, S3 servers or NAS devices, with restores able to recreate a failed VM or seed a new VM on a different cluster. Those are the two features that decide whether an HCI platform is usable in production, and both are present in the feature list.

## Installing Harvester from the ISO and creating a cluster

Harvester ships as a bootable appliance image. The README says to download the ISO from the GitHub releases page. There is no package manager path and no container to pull: the installation target is the server itself.

Mount the ISO and boot the server, selecting the `Harvester Installer` option. The installer then runs a hardware check against the production minimums. If a check fails, installation stops and warnings print to the system console, and you choose whether to continue or exit. For iPXE installs, the README documents a kernel parameter to bypass the check for testing:

```bash
harvester.install.skipchecks=true
```

The next step is setting the password for the default user `rancher`. The README states this password is used to access the node over SSH, so it is not a UI-only credential.

After that you choose an installation mode. The default is that the first node becomes the management node of the cluster. The two modes are creating a new Harvester cluster, or joining an existing one. Joining requires the VIP and the cluster token of the target cluster, which the README names as the two inputs you need.

Additional compute nodes join the same way. The README notes the first three nodes are the management nodes and must be fast enough for etcd, which is the constraint that shapes cluster sizing more than CPU count does. For automated installs, the README points to iPXE scripts in the documentation rather than describing them in the repository README.

## Where Harvester is the wrong tool

The hardware check is the honest part of this project, and it is also the limitation. A three-node production cluster at the documented minimums means 48 cores, 192 GB of RAM and 1.5 TB of SSD across three machines, with 10 Gbps Ethernet and a trunking switch. That is a rack commitment. Anyone hoping to evaluate Harvester on two spare desktops is outside the supported configuration, and the README says so rather than leaving it implied.

The etcd requirement compounds this. The README requires management nodes to be fast enough for etcd and links to a SUSE knowledge base article on the subject. Disk performance is not a soft recommendation here: the table asks for 5,000+ random IOPS per disk, and management nodes carry the cluster's consistency state. A cluster built on slow disks degrades in ways that look like software bugs.

There is also a boundary around what the README does not cover. It does not document rollback, cluster downgrade, or what happens to running VMs during a version change. Upgrades are a normal part of HCI operation, and the README's silence on rollback means that question has to be answered from the documentation site, not from the repository. Treat that as an open item to resolve before you plan a production cutover, not as a defect.

Finally, the release list shows v1.9.1-rc1 dated 2026-09-17, one day after v1.9.0 on 2026-09-16. Release candidates are listed alongside stable releases on the same page, so picking the newest tag by date is not the same as picking the stable one.

## Harvester against Proxmox VE and plain KubeVirt

The closest conventional alternative is Proxmox VE. Both install from an ISO onto bare metal and both bundle virtualization with storage. The difference is the interface and the storage model. Proxmox presents its own cluster manager and API, with storage configured per node or via shared backends. Harvester presents the Kubernetes API, with Longhorn providing distributed block storage and KubeVirt providing the VM layer. If your team already writes controllers and manifests, Harvester's model is the one that fits; if your team runs a hypervisor as a hypervisor, Proxmox asks less of you.

The alternative inside the Kubernetes world is assembling KubeVirt and Longhorn yourself on a cluster you already operate. That gives you control over versions and node images. What you give up is the appliance: the hardware check, the installer, the immutable Elemental-based OS, and the Rancher integration that the README lists as a feature. Harvester's value is in that assembly, not in KubeVirt or Longhorn individually, both of which are separate projects with their own release cycles.

The choice between these two paths comes down to whether you want to own a distribution. Running KubeVirt and Longhorn directly means owning the upgrade path for both plus the OS. Harvester means owning one upgrade path, at the cost of accepting its defaults and its hardware floors.

## Licence, release cadence and upgrade cost

Harvester is Apache-2.0. That is a permissive licence, and it matters here because the platform bundles other components. Longhorn, KubeVirt and Elemental are separate projects with their own licences, and the ISO distributes them together. If your organisation has rules about which licences may ship in a product you redistribute, the bundled components are the ones to check, not just the Harvester repository licence. That is a factual observation about the architecture, not legal advice.

The repository is not archived and the last push was on 2026-09-22. The recent release list shows v1.9.0 on 2026-09-16 and v1.9.1-rc1 on 2026-09-17, with v1.9.0-rc7 on 2026-09-01 before it. Release candidates appear on the same list as stable releases, so a tag being newest does not make it the production pin.

Upgrade cost is where an HCI platform earns or loses its keep, and the README does not describe the upgrade procedure. What the repository does show is the build side: the Makefile pins `HARVESTER_ADDONS_VERSION` to `main` by default and documents overriding it to pin a branch or specific release candidate, and the Dockerfile pins Helm, kind and codecov by version and SHA256. Those pins describe how the project builds itself, not how a cluster upgrades. For cluster upgrades, the documentation site is the source, and the README does not summarise it.

## Conclusion

Adopt Harvester if you already run Rancher or Kubernetes and want VM workloads on the same API, and you have server-class x86_64 hardware with SSD or NVMe and 10 Gbps networking for production. Do not adopt it for laptops, nested virtualization or a three-node cluster of spinning disks: the README states laptops and nested virtualization are not officially supported, and management nodes must be fast enough for etcd. Before committing, verify your disks meet 5,000+ random IOPS, that your switch supports port trunking for VLANs, and whether the v1.9.1-rc1 release candidate is what you want in production or whether v1.9.0 is the safer pin.

## FAQ

### What is Harvester?

Harvester is an open source hyperconverged infrastructure solution built on Kubernetes, described in its README as an alternative for operators seeking a cloud-native HCI platform. It runs on bare metal and provides virtualization and distributed storage together.

### How do I install Harvester on a server?

Download the ISO from the GitHub releases page, mount it and boot the server with the `Harvester Installer` option. The installer runs a hardware check, you set the password for the default `rancher` user, then choose to create a new cluster or join an existing one using its VIP and cluster token.

### What hardware does Harvester require?

The README asks for x86_64 with hardware-assisted virtualization, 8 cores and 32 GB of memory for testing (16 cores and 64 GB for production), 250 GB of disk for testing (500 GB for production) at 5,000+ random IOPS per disk, and 1 Gbps Ethernet for testing or 10 Gbps for production. Laptops and nested virtualization are not officially supported.

### Can Harvester run on a laptop or in nested virtualization?

The README states that laptops and nested virtualization are not officially supported, and recommends server-class hardware. The installer's hardware check stops installation and prints warnings to the system console when minimum requirements are not met.

### What are the components behind Harvester?

The README names Longhorn for distributed block storage, KubeVirt as the virtual machine management add-on for Kubernetes, and Elemental for SLE-Micro 5.3 as an immutable Linux distribution for the cluster OS.

## Sources

- [harvester/harvester on GitHub](https://github.com/harvester/harvester)
- [License: Apache-2.0](https://github.com/harvester/harvester/blob/master/LICENSE)
- [Project website](https://harvesterhci.io/)
- [README](https://github.com/harvester/harvester/blob/master/README.md)
- [Releases](https://github.com/harvester/harvester/releases)

---

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