Die Übernahme von VMware durch Broadcom brachte für vSphere-Kunden vor allem massiv höhere Kosten. Viele vSphere-Anwender suchen daher nach einer Alternative wie KubeVirt [1], das in Verbindung mit OpenShift oder Rancher Prime klassische VMs neben Containern verwaltet – jedoch bevorzugt in großen Installationen mit dutzenden Nodes. Wie KubeVirt funktioniert, haben wir bereits ausführlich im IT-Administrator [2] beschrieben.

Dass KubeVirt sich aber auch für kleine und mittelgroße Setups eignet, zeigt SUSEs "Harvester" [3]. Die Software ist Open Source und damit kostenfrei auf GitHub verfügbar, Support bietet die kommerzielle Harvester-Variante namens "SUSE Virtualization" [4]. Dieser Workshop wirft einen genauen Blick auf das Tool und dessen Funktionen und gibt Tipps, die den Umgang mit Harvester vereinfachen und dessen Funktionsumfang erweitern. Dergestalt arbeitet Harvester auch in KMU-Umgebungen tadellos.

Auf einem physischen Harvester-Knoten läuft die Linux-Distribution "SLE Micro". Dabei handelt es sich um ein stark abgespecktes Suse Linux. SLE Micro ist dabei Image-basiert und "immutable", sprich: Das Root-Dateisystem ist schreibgeschützt eingebunden und es lassen sich keine Änderungen am Basissystem vornehmen – auch der Paketmanager Zypper funktioniert hier nicht. Gibt es eine neue OS-Version, tauscht Harvester das komplette Image des Knotens aus. Eingebettet in das OS-Image läuft die Kubernetes-Distribution RKE2 (Rancher Kubernetes Engine 2). Alle weiteren Funktionen arbeiten in Kubernetes-Pods.

Die Vorgaben an die Hardware haben sich seit 2024 ein wenig geändert: Harvester möchte nun mindestens acht CPU-Kerne und 32 GByte RAM pro Knoten für ein Testsystem, für die Produktion empfiehlt der Hersteller 16 und mehr Kerne bei mindestens 64 GByte RAM. Zudem muss ein Knoten mindestens über zwei NICs verfügen, da Harvester stets das Management-LAN von der VM-Bridge trennt. Es gibt zwar die Option, hier mit nur einem physischen NIC und Separation der beiden Netzwerke via VLANs zu arbeiten, aber das sollten Sie nicht in der Produktion einsetzen. Besser sind hier vier NICs und zwei Failover-Bonds für Management und VMs.

Auch die Anforderungen an den Storage sind gestiegen und erfordern nun zwei Platten: Eine Disk für das OS und mindestens eine zweite für den VM-Speicher. Festplatten im klassisch rotierenden Sinn sollten Sie dabei aber meiden. Die IOPs-Anforderungen der Kubernetes-Konfigurationsdatenbank "etcd" sind recht üppig und nur von einer NVME als Systemlaufwerk zu meistern. Auch die Datendisks sollten nicht trödeln, denn zu den IO-Anforderungen der darauf laufenden VMs gesellen sich auch noch die Replikations-IOPs des Longhorn-Speichers.

Für diesen Workshop bauten wir zunächst ein Testsetup, das die Disk-IO-Anforderungen mit einem in die Jahre gekommenen HP-Rack-Server (DL360 Generation 7) deutlich unterschritt. Die Maschine beherbergte vier klassisch rotierende 2.5-Zoll-SAS-Festplatten und einen Hardware-Raid-Controller, dessen Pufferbatterie schon lange nicht mehr funktioniert und der daher ohne Schreibcache arbeitet. Dabei haben wir beobachten können, wie Harvester auf IO-Engpässe reagiert: Die gute Nachricht ist, dass wir wider Erwarten keine Daten verloren. Der Server hat sich sogar in den ersten Tests tapfer gehalten. Dann rollten wir jedoch via Ansible fünf Fedora-Knoten auf einmal aus und setzten darin einen Kubernetes-Cluster auf. Die I/O-Load der Rollouts und der etcd-Dienste waren dann zu viel. Harvester und Kubernetes selbst brachen jedoch nicht zusammen. Vielmehr hat KubeVirt die überladenen VMs pausiert (ohne Datenverlust) und damit die I/O-Last so weit reduziert, dass die Umgebung und einige Maschinen weiter laufen konnten.

Als zweites Testsystem kam eine DIY-AMD-Workstation mit acht Cores (16 virtuell), 64 GByte RAM und zwei NVMEs (256 GByte root, 1 TByte Daten) zum Einsatz. Auf diesem Knoten lief Harvester flott und stabil, auch mit mehreren darauf laufenden Kubernetes-Setups in VMs. Als Single-Node-Umgebung konnten wir damit aber weder die Longhorn-Replikation noch die VM-Live-Migration genauer unter die Lupe nehmen.

Für die Installation stellt SUSE ein kompaktes Image für DVD/USB oder PXE-Boot bereit. Nach einigen Abfragen erstellen Sie auf dem ersten System einen neuen Cluster und erzeugen dort auch einen "Member-Token". Dies ist ein Password, mit dem weitere Knoten später dem Verbund beitreten. Das Setup fragt nach dem Managementnetzwerk und der Installationsplatte. Der Management-NIC erhält eine Bridge und darauf eine separate IP-Adresse für das Managementfrontend. Diese Adresse kann später als Failover an andere Managementknoten übergeben werden, sollte der erste Verwaltungsknoten ausfallen. Im Disk-Dialog können Sie zunächst nur eine weitere Platte als Datendisk angeben. Sollte der Server über weitere Platten für den Datenspeicher verfügen, lassen sich diese später im laufenden Betrieb an Longhorn übergeben. Das Setup fragt noch nach einem Password für den administrativen User "rancher" und dann legt die Installation los.

Ab dem zweiten Knoten wählen Sie die Option, den Knoten einem bestehenden Cluster hinzuzufügen. Jetzt lässt sich wählen, ob der Knoten ein reiner "Worker"-Node ohne Verwaltungsaufgaben oder ein gemischter Knoten mit VMs und Managementtools wird. Über den zuvor vergebenen Token und die Management-IP-Adresse tritt der neue Knoten nach dem Installtionsvorgang dem Cluster bei.

Im Hintergrund richtet sich dabei erst einmal der Kubernetes-Cluster ein. Worker-Knoten erhalten dabei keine etcd-Kopien oder andere Management-Pods. Neben den Kubernetes-Basisdiensten verteilt die Installationsroutine zudem den CSI-Speicher Longhorn mit den passenden Pods. Longhorn stellt später die virtuellen Platten für die VMs bereit und repliziert diese zwischen den Knoten. Per Default-Setup arbeitet Longhorn stets mit einer Replikation über drei Hosts. Technisch legt Longhorn ein PV (Persistent Volume) als Sparse-Image-File im Dateisystem der Datenpartition an, und stellt dieses via iSCSI-Target dem lokalen und auch anderen Knoten zur Verfügung. Selbst, wenn Anwender zu Testzwecken Datenspeicher mit der Option "replica=1" anlegen, stehen diese via iSCSI allen Knoten zur Verfügung.

Nach dem Abschluss der Installation erhalten Sie Zugang zum Web-UI, auf dem Sie einige initiale Anpassungen vornehmen müssen. Zum jetzigen Zeitpunkt existiert kein Netzwerk für die virtuellen Maschinen. Dazu bedarf es eines VM- und eines Cluster-Netzwerks. Dem Cluster-Netz weisen Sie NICs der einzelnen Knoten als Uplink zu. Das ist praktisch, falls die LAN-Adapter auf den Knoten unterschiedliche Namen haben, also "enp39s0" auf dem einen und "enp4s1" auf einem anderen. Auf dieses Netz setzen Sie dann ein oder mehrere VM-Netze als "tagged" oder "untagged" VLAN auf.

Zu Beginn zeichnet Harvester noch keine Metriken der Hosts und VMs auf, zeigt diesen Missstand aber direkt im Dash-board an. Mit einem Klick aktivieren Sie diese Funktion, die im Hintergrund dann Dienste wie Prometheus und Grafana als Pods unter Kubernetes startet.

Die grundlegenden Funktionen des Longhorn-Speichers finden Sie unter "Advanced" und "Storage-Classes". Harvester legt hier eine Reihe von Standard-Speicherklassen für virtuelle Maschinen oder Kubernetes-Anwendungen fest. Da Harvester stets von mindestens drei Knoten ausgeht, stehen die Speicherklassen grundsätzlich auf "Replika 3", was sich auch nicht ändern lässt. Um das System mit einem Single-Node-Setup zu testen, müssen Sie eine neue "Replika-1"-Speicherklasse anlegen und als "Default" markieren.

Um eine VM anzulegen, bedarf es erst einmal eines Installations-Images, sofern Sie nicht PXE-Boot verwenden. Sie können sowohl ISO-Abbilder für interaktive Setups, als auch qcow2-Images für eine automatische Installation verwenden. Nutzen sie Cloud-Images als Vorlage, klont Harvester daraus eine virtuelle Disk in der gewünschten Größe und nutzt Cloud-Init für das initiale Systemsetup. Optional können Sie Disk-Abbilder bestehender KVM-Maschinen hochladen. In einem separaten Dialog verwaltet Harvester Cloud-Init-Templates, die Sie für automatische Installationen einsetzen können. Der Dialog zum Erstellen neuer Maschinen lässt Sie dann die Images, Netzwerke und Cloud-Init-Vorgaben anwählen. Harvester erlaubt dabei auch, dass Sie gleich mehrere Maschinen auf einmal aus einem Cloud-Image heraus erstellen.

Für viele Administratoren spielt das GUI mittlerweile eine untergeordnete Rolle. Wichtiger ist, dass sich der gewählte Hypervisor mit Automatisierungstools bedienen lässt und damit auch Infrastructure-as-Code-Szenarien unterstützt. Für Harvester gibt es beispielsweise einen passenden Terraform-Provider, der in unserer Umgebung – nach etwas Herumprobieren – auch funktionierte. Die Entwickler des Provider haben zwischen früheren und der aktuellen Version 1.6 offensichtlich ein paar Variablen umbenannt, was aus der Dokumentation nicht gleich hervorgeht. Aber nachdem wir diese Probleme gelöst hatten, konnte Terraform zügig Infrastrukturen ausrollen.

Für Ansible stand uns zwar keine aktuelle Harvester-Collection zur Verfügung, aber das ist nicht weiter tragisch, denn schließlich basiert Harvester auf Kubernetes und damit funktioniert die K8S-Collection. Damit Sie aber nicht im Dschungel der YAML-Spezifikationen in einer Datei für KubeVirt-Deklarationen untergehen, hier ein guter Tipp für eine sinnvolle KI-Nutzung: Um Harvester mit Ansible zu automatisieren, erstellen Sie zunächst eine Referenzmaschine via GUI und laden dann die von Harvester erzeugten YAML-Dateien für VM und PVC herunter – das bietet das UI bei allen Objekten an. Diese YAML-Dateien übergeben Sie einer KI wie "Claude Code" und lassen den Assistenten eine YAML-Datei für kubectl apply -f" erstellen, die eine VM samt Disk-Klon aus einem Template-Image gemäß der Vorlage erzeugt. Die von der KI generierte YAML-Datei funktionierte bei unseren Versuchen auf Anhieb, weswegen wir im nächsten Schritt die KI dazu aufforderten, aus dieser statischen YAML-Datei ein Jinja-2-Template (Listing 1) zu bauen, das statische Werte wie VM-Name, CPU-Zahl, Template-Image et cetera in Variablen überträgt. Und damit erzeugen Sie dann ein simples Playbook mit dem sich nun via Ansible zügig VMs auf dem Harvester ausrollen lassen.

Um etwas genauer sehen zu können, was Longhorn im Hintergrund macht, gibt es einen kleinen Trick. Neben dem vereinfachten Harvester-UI, das nur für das Management der VMs gedacht ist, versteckt SUSE zwei weitere UIs: Eines für Longhorn und ein Rancher-UI, über das sich der Kubernetes-Teil des Harvester verwalten lässt. Um Zugang zu diesen zu erhalten, müssen Sie im regulären Harvester-Interface zuerst auf das Benutzer-Icon oben rechts klicken und im folgenden Menü "Preferences" auswählen. Ganz unten auf dieser Seite findet sich eine Checkbox "Enable Extension developer features", die Sie einschalten und dann zum Dashboard zurückkehren. Klicken Sie unten links auf den Text "Support", gelangen Sie zur Support-Page. Dort tauchen nun zwei neue Links auf: "Access Embedded Rancher UI" und "Access Embedded Longhorn UI". Natürlich verweist der Hersteller darauf, dass diese UIs nur für Debugging-Zwecke da sind.

Im Longhorn-UI sehen Sie den Status der definierten Volumes und deren Replikation über mehrere Knoten. Bei einem Single-Node-Test-Setup wimmelt es hier vor Fehlern, da Longhorn keine zwei Kopien der Standard-Volumes erstellen kann. Um die Warnung abzuschalten, setzen Sie direkt in den individuellen Einstellungen pro Volume den "Replica Count" von "3" auf "1" zurück. Sollten Sie später dem Cluster weitere Knoten hinzufügen, stellen Sie hier den Replica-Count wieder auf "3" und Longhorn wird das Volume spiegeln. Diese interaktive Umstellung funktioniert aber nur im Longhorn- und nicht im Harvester-GUI.

In der Rancher-Oberfläche könnten Sie Kubernetes-Applikationen auf Ihren Harvester-Cluster installieren. Der Hersteller sieht Harvester jedoch nur als Kubernetes-basierte Plattform für virtuelle Maschinen und unterstützt nicht, dass Anwender parallel native Kubernetes-Anwendungen darauf betreiben. Die Idee dahinter ist, dass Sie in VMs auf Harvester einen oder mehrere getrennte Kubernetes-Cluster für Applikationen laufen lassen. Das ist aber wiederum mit einem großen Verwaltungsaufwand verbunden und eignet sich in erster Linie für produktive Umgebungen, die auch mehrere separate Kubernetes-Instanzen benötigen. In unserem Testsetup lassen wir beispielsweise eine Ansible "AWX"-Instanz auf dem Harvester-Kubernetes mitlaufen, die ohnehin nicht viele Ressourcen belegt.

Auf der Supportseite offeriert das Harvester-UI auch die "kubeconfig"-Datei zum Download. Mit deren Hilfe verwalten Sie den Kubernetes-Cluster auf dem CLI oder mit praktischen Tools wie Helm und K9s [5]. An die Kubernetes-Konfiguration kommen Sie natürlich auch heran, wenn Sie sich an einem der Harvester-Knoten per SSH mit dem Nutzerkonto "rancher" anmelden. Dort erlangen Sie mit sudo --i.  Root-Rechte und finden die Kubernetes-Konfiguration in "/etc/rancher /rke2/ rke2.yaml". Um diese auf einem externen Host mit dem Kubernetes-Clienttool "kubectl" zu nutzen, müssen Sie nur in der Zeile "server: https://127.0.0.1:6443" die IP-Adresse oder den DNS-Namen des Harvester-Managements statt "localhost" eintragen.

Mit unserem eingangs erwähnten Altrechner DL360 G7 stießen wir auf ein Problem, das ein immutable OS wie SLE Micro mit sich bringt: Um an die Konfiguration des betagten RAID-Controllers heranzukommen, ist ein proprietäres Tool von HP erforderlich, das der Hersteller als RPM-Paket zur Verfügung stellt. Das lässt sich auf SLE Micro eigentlich nicht installieren – zumindest nicht dauerhaft. Ein Trick erlaubt es aber, ein RPM temporär einzurichten und zu nutzen, ohne dabei das OS verändern zu müssen.

Mithilfe von OverlayFS, einigen Bind-Mounts (sys, proc, dev) und chroot, lässt sich ein (scheinbar) beschreibbares Root-Dateisystem erstellen, in dem Tools wie RPM und Zypper funktionieren. Deren Änderungen landen aber nur im Overlay-Dateisystem. Das existiert entweder im temporären Dateisystem und ist damit nach einem Neustart verloren. Alternativ speichern Sie den "upper"-Layer des OverlayFS in einem RW-Dateisystem wie "/var" oder "/opt" und binden es bei Bedarf ein. Von dort aus funktioniert das proprietäre HW-Management-Tool des RAID-Controllers problemlos.

Wer neben Harvester eine Rancher-Umgebung betreibt, kann deren Management-UI für die Verwaltung von Harvesters verwenden. Im Rancher-GUI gibt es einen eigenen Abschnitt für "Virtualisierung", wo Sie ein Objekt für Ihr Harvester-Setup anlegen. Rancher gibt Ihnen dann eine Kommandozeile, die Sie auf Harvester oder einem angeschlossenen Managementhost mit kubectl ausführen.

Der Aufruf startet einen Daemon-Pod in Harvester und meldet sich am zentralen Rancher-UI an. Jetzt können Sie im GUI erweiterte Funktionen nutzen, wie beispielsweise das automatische Ausrollen eines RKE2- oder K3S-Clusters. Rancher baut dann automatisch die VMs in Harvester, konfiguriert sie und bindet sie an das Rancher-Management an.

Longhorn ist ein guter, hyperkonvergenter Kubernetes-Storage in kleineren Umgebungen. Aber es skaliert nicht besonders gut in größeren Clustern und kann über die iSCSI-Replikation der Volumen viel Traffic auf dem Managementnetzwerk verursachen. Zudem verfügen viele Unternehmen bereits über Storage und wollen diesen weiter verwenden. Prinzipiell arbeiten alle Speichersysteme, für die es einen Kubernetes-CSI-Treiber gibt, auch mit Harvester. Darunter auch NetApp-Storages mit dem NetApp-Trident-Treiber. SUSE listet auf der Harvester-Seite auch den NFS- und den Rook-Ceph-Treiber auf. Der App-Katalog im Rancher-UI bietet zudem diverse CSI-Treiber von Dell, Nutanix und HP an.

Stellvertretend haben wir den NFS-CSI-Treiber ausprobiert. Die Installation erfolgt von einem Client mit kubectl via Helm in drei einfachen Schritten:

Sobald der NFS-Controller läuft, brauchen Sie nur noch eine Storage-Klasse, die auf eine bestehende NFS-Freigabe verweist. Die zugehörige Kubernetes-Konfiguration legen Sie via kubectl apply -f gefolgt von einer YAML-Datei mit diesem Inhalt an: 

Jetzt können Sie neue Disks auf der NFS-Freigabe anlegen. Was dabei leider nicht funktioniert, ist die Livemigration von Disks von Longhorn zu NFS. Diese Einschränkung stammt nicht von Harvester, sondern von Kubernetes. Disks lassen sich nur offline umziehen und dann oftmals auch nur mit Cloning und Snapshots oder dem klassischen "dd"-Kommando.

Während es keine Live-Disk-Migration gibt, beherrscht Harvester jedoch Volume-Snapshots und bietet auch eine grundlegende Backupfunktion. Hier geben Sie ein S3-Storage-Target für VM-Backups an. Harvester erstellt dann manuell oder über einen Scheduler Snapshots Ihrer VMs samt Disk und Konfigurationen und lädt diese Backups auf den S3-Storage. Das genügt für simple Sicherungen, wer es etwas komfortabler mag, kann Tools wie etwa "Veeam Kasten K10" (siehe Test auf Seite 14) einsetzen.

Harvester will mit seiner schicken Weboberfläche vSphere-Nutzer ansprechen, ohne dabei mit seitenweise Kubernetes-YAML-Code abzuschrecken. Das gelingt zumindest in Teilen für einfache Funktionen. Aber an sehr vielen Ecken schimmert einfach die Komplexität von Kubernetes durch. Seien es die Einschränkungen für Objektnamen, die nur aus Kleinbuchstaben, Zahlen und Bindestrichen bestehen dürfen oder die fehlende Option, Objektparameter zu ändern. Wer sich beim Erstellen einer VM bei der Eingabe des Namens vertippt und es erst später merkt, kann diesen nicht mehr ändern. Aber wie angesprochen spielt das GUI eine weniger wichtige Rolle: Automatisierungstools wie Ansible oder Terraform funktionieren sehr gut mit Harvester und erlauben, die Plattform ohne UI zu nutzen.

Zudem sind es gerade viele der offenen Plattform-Add-ons von Kubernetes, die Harvester interessant machen und ihm mehr Funktionsumfang verleihen. Ein Nachteil der "kleinen" Virt-Plattformen wie ovirt waren die fehlenden Tools, Treiber und Erweiterungen. Für Kubernetes gibt es fast alles und was bei hier funktioniert, läuft auch mit Harvester. Doch wer sich auf Harvester einlässt, kommt eben nicht um Kubernetes und seine YAML-Orgien herum. Längerfristig ist das auch der richtige Weg, um von VMs wegzukommen und sich mit Kubernetes als Container-Plattform zu beschäftigen.