Harvester: Cloud-Native HCI on Bare Metal

June 3, 2026 11 min read Virtualization & Containers

private-cloudharvesterkuberneteskubevirtvirtualizationhomelab

Contents

The previous post covered OpenNebula, which wins by being small. Harvester is the opposite bet. Where OpenNebula folds cloud responsibilities into few moving parts, Harvester embraces the most elaborate substrate in modern infrastructure — Kubernetes — and builds an entire hyperconverged virtualization platform on top of it. The payoff is the most architecturally current design in this series: VMs and containers as first-class citizens on the same cluster, the Kubernetes scheduler placing your workloads, and a declarative API for everything. The cost is that you inherit Kubernetes’ operational weight whether you wanted it or not. This post is about when that trade is brilliant and when it is overkill.

Recall the series’ dividing line from the intro: does the platform have a placement scheduler? Harvester passes emphatically — but in an unusual way. It does not write its own scheduler; it borrows the most battle-tested one in existence, the Kubernetes scheduler, because under the hood your VMs are Kubernetes pods.

What Harvester actually is

Harvester is an open-source HCI platform from SUSE (recently rebranded SUSE Virtualization, though the project name Harvester persists), built entirely from cloud-native components:

Kubernetes (RKE2) is the foundation — the control plane, the API, the scheduler, the whole substrate. Harvester is a Kubernetes cluster with a specific purpose.
KubeVirt is the piece that makes this a virtualization platform: it is a Kubernetes add-on that runs full KVM virtual machines as Kubernetes resources. A VM becomes a custom resource; a running VM is a pod (a virt-launcher) wrapping a QEMU/KVM process. You kubectl get vms the same way you kubectl get pods.
Longhorn is the storage layer — a CNCF distributed block-storage system that replicates VM disks across nodes, providing the “software-defined storage” capability from the intro’s table.
Multus CNI provides multiple network interfaces per VM, with VLAN and (newer) VPC/overlay networking.

   ┌──────────────────────────────────────────────────────┐
   │                    Harvester node                      │
   │                                                        │
   │   Your VM  ─────► KubeVirt virt-launcher POD           │
   │                        └─► QEMU/KVM process            │
   │                                                        │
   │   Longhorn (replicated block storage for VM disks)     │
   │   Multus CNI (VLAN / VPC networking)                   │
   │                                                        │
   │   ───────────── all on top of ─────────────            │
   │              Kubernetes (RKE2)                          │
   └──────────────────────────────────────────────────────┘
            ×N nodes, fused compute + storage = HCI

The defining idea: everything is a Kubernetes object. A VM, its disk, its network, its boot image — all custom resources you can create with the UI, the API, or declaratively with Terraform/OpenTofu. If you already live in a GitOps, declarative-infrastructure world, this is intoxicating: your virtual machines become just more YAML in the same system that runs everything else.

The current release as of mid-2026 is Harvester v1.8.0, which added live storage migration of running VM disks between storage providers, explicit CPU-model selection (so live migration works cleanly across hosts with different CPU generations), a visual VPC network-topology view, tunable Longhorn resource reservations, and Pod Security Admission on system namespaces.

The scheduler: Kubernetes does the placing

Here is the elegant part. Because a Harvester VM is a pod, the Kubernetes scheduler places it — the same scheduler that has placed billions of containers in production. When you create a VM, you do not name a host; you submit the VM resource, and Kubernetes evaluates every node against resource requests, affinity/anti-affinity rules, taints and tolerations, and topology constraints, then binds the virt-launcher pod to the best node.

   You: create VM (4 vCPU, 8Gi, label: needs-gpu)
              │
              ▼
   KubeVirt creates a virt-launcher POD spec
              │
              ▼
   Kubernetes scheduler:
     filter:  which nodes have the CPU/memory/GPU? right taints?
     score:   which node is least loaded / best spread?
              │
              ▼
   Binds the VM's pod to the best node → KVM starts there

This means Harvester inherits, for free, the entire mature ecosystem of Kubernetes placement: pod affinity to co-locate related VMs, anti-affinity to spread replicas across failure domains, node selectors and taints to pin GPU workloads to GPU hosts, topology spread constraints across racks or zones. You are not learning a bespoke placement DSL; you are using the one your platform team may already know. For the series’ central question — “can it just pick the best machine for me?” — Harvester’s answer is “yes, using the best scheduler there is.”

The subtlety: this is placement at create and migrate time, like the others in this series. Harvester does not continuously rebalance running VMs the way VMware DRS does (though the Kubernetes ecosystem has descheduler projects that can approximate it). Live migration is supported and re-runs scheduling — and v1.8.0’s CPU-model selection specifically fixes the classic “can’t live-migrate to a host with a different CPU generation” problem.

Where Harvester is strong

The most modern architecture, and genuine VM/container convergence. This is the headline. Harvester natively runs Kubernetes workloads alongside VMs on the same hardware, because the substrate is already Kubernetes. You can run containerized apps and legacy VMs on one unified cluster, managed the same way. No other platform in this series makes that convergence so natural — on Proxmox you would run Kubernetes inside VMs as a separate layer; on Harvester the layers are one.

Tight Rancher integration. Harvester plugs directly into Rancher (SUSE’s Kubernetes management platform) through a Virtualization Management page, so a team already using Rancher to manage Kubernetes fleets manages its VMs in the same console. Better still, Harvester can act as a node driver for Rancher: it provisions guest Kubernetes clusters on Harvester VMs, so the platform that runs your VMs also births your Kubernetes clusters. For a cloud-native shop, this closes the loop beautifully.

A clean, declarative API and UI. Everything is a Kubernetes resource, so everything is scriptable and GitOps-able with the tools you already have — kubectl, the Harvester Terraform provider, Argo/Flux. The web UI is modern and pleasant. Infrastructure-as-code for VMs is not bolted on; it is the native mode.

Real distributed storage built in. Longhorn replicates VM disks across nodes, so a node failure does not lose data and VMs can restart elsewhere — the HA payoff of HCI, included by default. v1.8.0’s live storage migration even lets you move a running VM’s disks between Longhorn and external CSI backends without downtime.

The right call for the Kubernetes-everything bet. If your organization has decided Kubernetes is the universal substrate — that operators, CRDs, GitOps, and the CNCF ecosystem are how you do infrastructure — then Harvester is the virtualization platform that fits that worldview without compromise. Your VMs join the same declarative, API-driven world as everything else.

Where the weight shows

Harvester’s strengths and weaknesses are the same coin. Everything good comes from “it is Kubernetes”; everything hard comes from “it is Kubernetes.”

You inherit Kubernetes’ operational weight — all of it. This is the honest core of the trade. A Harvester cluster is a Kubernetes cluster, with all that implies: etcd to keep healthy, controllers and operators that can wedge, certificates that rotate, upgrades that touch a deep stack (RKE2 + KubeVirt + Longhorn + Harvester itself, each with its own version matrix), and failure modes that require Kubernetes fluency to debug. When a VM will not start, the answer may live in a pod event, a CRD status, a Longhorn volume condition, or a scheduler log. Compared to Proxmox — where a VM is a process and a config file you can reason about directly — Harvester asks you to be comfortable debugging Kubernetes to operate your hypervisor. If your team does not already run Kubernetes, Harvester means learning Kubernetes to get virtualization, which is a large hidden cost.

Real hardware and networking requirements. Harvester is not a “install on a spare laptop” platform. The Kubernetes control plane, Longhorn replication, and the system overhead want genuine resources — meaningful RAM and CPU per node before you run a single workload VM, multiple NICs for proper network separation, and ideally three or more nodes for Longhorn to replicate safely. The minimum viable Harvester is heftier than the minimum viable Proxmox or Incus.

Networking is capable but narrower than OpenStack. Harvester does NIC bonding and VLAN (bridge) networking via Multus, and newer releases add VPC and overlay networking with a topology visualizer — but it is not the deep, every-feature SDN that OpenStack’s Neutron offers. For exotic or highly specialized network topologies, OpenStack remains the more flexible choice. For most workloads Harvester’s networking is sufficient; for network-centric use cases it can be limiting.

Longhorn vs external Ceph is a real decision. Longhorn is excellent and integrated, but it does not guarantee data locality (a VM’s replicas may live on other nodes, so reads can cross the network), and at large scale or for the most demanding storage workloads, teams sometimes prefer to point Harvester at an external Ceph cluster via CSI instead. That is supported, but it reintroduces the disaggregation the HCI model was meant to avoid, and it is a genuine architectural fork to weigh — exactly the HCI-vs-disaggregated tension from the intro.

It is younger than the alternatives. Harvester is mature enough for production and backed by SUSE, but it is newer than OpenStack, oVirt, or Proxmox. The ecosystem, the body of community troubleshooting knowledge, and the long-tail of edge-case fixes are smaller. You are adopting the most modern option, with the modest risk that entails.

Who it is for

Harvester fits a specific and growing profile:

The cloud-native organization unifying VMs and containers. You have committed to Kubernetes, you run Rancher, and you want your remaining VMs to live in that same world rather than on a separate island. Harvester is arguably the best platform in this series for you, and the convergence is its whole reason to exist.
Teams that want declarative, GitOps-managed virtualization. If “VMs as YAML, reconciled by operators, deployed by Argo” sounds like the right way to run infrastructure, Harvester delivers it natively.
Edge and distributed deployments managed centrally. Rancher’s fleet management plus Harvester’s HCI model suits many small clusters at edge sites managed from one place.

It is a poor fit if you want the simplest possible VM platform (Proxmox or Incus win decisively on operational simplicity), if your team has no Kubernetes expertise and no desire to acquire it, or if you are running one or two nodes where Harvester’s overhead dwarfs the workload. The intro’s rule applies sharply here: do not adopt Kubernetes’ complexity to run a handful of VMs. Harvester earns its weight when the Kubernetes substrate is something you want anyway.

A realistic deployment

Harvester installs as an appliance OS — you boot nodes from the Harvester ISO (or PXE), and they form a cluster; you do not install it onto an existing OS the way you might layer software on Debian. A real cluster is three or more nodes:

   ┌───────────┐   ┌───────────┐   ┌───────────┐
   │  node-01   │   │  node-02   │   │  node-03   │   each: Harvester appliance OS
   │ RKE2 + KV  │   │ RKE2 + KV  │   │ RKE2 + KV  │   (control plane + workloads)
   │ Longhorn   │   │ Longhorn   │   │ Longhorn   │   storage replicated across all
   └─────┬─────┘   └─────┬─────┘   └─────┬─────┘
         └───────────────┴───────────────┘
                         │
                 ┌───────┴────────┐
                 │    Rancher      │  ← manages Harvester VMs AND provisions
                 │  (optional)     │     guest Kubernetes clusters on them
                 └────────────────┘

Once up, you manage it through the Harvester UI, kubectl against its API, or Terraform. Creating a VM declaratively looks like ordinary Kubernetes work:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# A VM is just a Kubernetes resource — kubectl apply this, or use the UI/Terraform
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: web-01
spec:
  running: true
  template:
    spec:
      domain:
        cpu: { cores: 4 }
        memory: { guest: 8Gi }
        # no node named — the Kubernetes scheduler places this VM
      networks:
        - name: default
          multus: { networkName: vlan100 }

The thing to notice, again: you described the VM and let the scheduler place it. That is the cloud experience from the intro — delivered, in Harvester’s case, by the most widely-deployed scheduler on earth, at the price of running that scheduler’s entire world.

Verdict

Harvester is the cloud-native HCI platform, and the most architecturally modern option in this series. Its genius is refusing to reinvent anything: it runs VMs as Kubernetes pods, places them with the Kubernetes scheduler, stores them on a CNCF storage system, and manages them with the same declarative tools you use for containers. For an organization that has already bet on Kubernetes, that coherence is hard to beat, and the VM/container convergence is unique here. But the bet cuts both ways: you operate a Kubernetes cluster to get virtualization, with all the depth and weight that entails. Choose Harvester when Kubernetes is the world you want to live in anyway — and choose almost anything else in this series when it is not.

Next up: the platform Harvester is most often measured against on the heavyweight end — OpenStack, the full reference cloud, and an honest accounting of the power it gives you and the operational price it extracts.

Sources: