Eine Nachricht von Zima
Vielen Dank, Bob, dass du deine Zeit mit dem ZimaCube in etwas verwandelt hast, das weitaus nützlicher ist als ein herkömmlicher Testbericht. Dein fortlaufendes Journal begleitet die Maschine, während sie ihre Aufgaben verändert — von ersten Eindrücken und dem Hardware-Teardown über ZimaOS, Windows Server, Proxmox, Backups, Monitoring und KI-Agenten bis hin zu einem virtualisierten Router — und hält dabei sowohl die Aspekte fest, die dir gefallen, als auch jene, die dich frustrieren. Solche langfristigen und ehrlichen Experimente helfen uns zu verstehen, nicht nur, was der ZimaCube leisten kann, sondern auch, was passiert, nachdem er Teil eines echten Homelabs geworden ist.
— Zima
Bob Loves Tech kennenlernen
Bob Loves Tech ist ein Homelab-Betreiber und Technik-Creator, dessen Arbeit sich über Windows, Linux, Virtualisierung, Netzwerke, Self-Hosting und die Hardware darunter erstreckt.
Seine Beziehung zur Zima-Hardware begann bereits vor diesem Projekt. Bob hatte schon vor seinem Beitritt zum Zima Pioneer Programme Zeit mit früheren Zima-Produkten wie ZimaBoard und ZimaBlade verbracht. Als der ZimaCube eintraf, beschloss er, keinen einzelnen ausgefeilten Testbericht zu produzieren und dann weiterzuziehen. Stattdessen erstellte er den ZimaCube Experience Blog, ein öffentliches Repository, das weiter wächst, während sich die Maschine gemeinsam mit seinem Homelab verändert.
Bob beschreibt das Projekt als fortlaufendes Journal und nicht als formellen Testbericht. Dieser Unterschied erklärt das Projekt sehr gut. Es umfasst die erste Reaktion auf die Hardware, die Dinge, die er nach dem Öffnen entdeckt hat, die von ihm getesteten Betriebssysteme, die Infrastruktur, die er darum herum aufgebaut hat, und die Schlussfolgerungen, die sich nach wochenlanger Nutzung verändert haben.
Die ZimaCube-Erfahrung über den ersten Eindruck hinaus dokumentieren
Die frühesten Beiträge in Bobs Projekt beginnen dort, wo die meisten Hardwaregeschichten beginnen: beim Auspacken der Maschine, der Begutachtung der Verarbeitungsqualität, der Überprüfung der Anschlüsse und Laufwerksschächte und der Frage, was sich anders anfühlt, sobald die Hardware physisch auf dem Schreibtisch steht.
Doch damit endet das Journal nicht. Bob kehrt zur Hardware zurück, nachdem er einige Zeit mit ihr gelebt hat. Sein Repository umfasst einen eigenen Hardware-Überblick, einen vollständigen Teardown, eine Nachbetrachtung nach sechs Wochen, eine genauere Untersuchung, warum der Arbeitsspeicher statt der CPU-Kerne zum praktischen Engpass wurde, sowie einen separaten Beitrag mit der Frage, die für jeden Reviewer irgendwann entscheidend wird: würde er tatsächlich sein eigenes Geld dafür ausgeben?
Diese Entwicklung macht das Projekt wertvoll. Ein erster Eindruck zeigt dir, wie ein Produkt ankommt. Ein fortlaufendes Journal zeigt dir, was bleibt, nachdem der erste Reiz verflogen ist.
Die Hardware öffnen und auf die Details achten
Eines der Hardwarekapitel trägt schlicht den Titel Das Gerät auseinandernehmen – das sagt viel über Bobs Vorgehensweise aus.
Statt den ZimaCube als geschlossenes NAS-Gerät zu behandeln, öffnete er das Gehäuse und dokumentierte das Innenleben, einschließlich des Kühlsystems und der kleinen Hardwaredetails, die erst sichtbar werden, wenn jemand beschließt, dass das Gerät wartbar und modifizierbar sein soll.
Dieser Teardown führt später zu einem weiteren Teil des Journals: Was sich nach sechs Wochen verändert hatte – und was nicht. Einige Beobachtungen werden mit der Zeit weniger wichtig. Andere – darunter Kühlung, Lüfterverhalten, Speicherkapazität, Aufrüstbarkeit und die Frage, wie gut die Hardware in eine ständig laufende Umgebung passt – gewinnen an Bedeutung.
Für Leser, die tiefer in dieselben Hardwarefragen einsteigen möchten, bietet unser Teardown-Leitfaden zum ZimaCube weitere Informationen zum internen Aufbau und zu den Aufrüstpfaden, während 7 clevere Designdetails im ZimaCube genauer auf Details eingeht, die sichtbar werden, wenn man das System öffnet, statt es nur anhand einer Spezifikationstabelle zu betrachten.
Entdecken, dass RAM wichtiger ist als zusätzliche CPU-Kerne
Einer der späteren Hardware-Einträge kommt zu einer weitaus nützlicheren Schlussfolgerung als ein weiteres Benchmark-Diagramm: Für Bobs Arbeitslast benötigte der ZimaCube nicht mehr CPU-Kerne. Er benötigte mehr Speicher.
Sein Journal beschreibt ein System mit zehn laufenden Gast-Systemen, während die CPU-Auslastung bei etwa vier Prozent blieb, der Speicherverbrauch jedoch auf ungefähr 27 GB gestiegen war. Das verändert die Bewertung der Hardware. Der Prozessor war nicht die erste praktische Grenze. Es war die mitgelieferte Speicherkonfiguration.
Bei einem Gerät, das sich allmählich zu einem Virtualisierungshost, Backup-Server, Überwachungsknoten, Host für Router-VMs und KI-Spielplatz entwickelt, wird die Speicherkapazität von einer Spezifikation zur Infrastruktur.
Genau solche Schlussfolgerungen kann eine lang laufende Anwendergeschichte zutage fördern. Sie entstehen nicht durch die Frage, was die CPU theoretisch leisten kann, sondern indem man beobachtet, wie sich das System verhält, nachdem sich immer mehr reale Arbeitslasten angesammelt haben.
ZimaOS löschen und Windows Server 2025 installieren
Das herausragende Experiment in Bobs Repository begann, als er ZimaOS entfernte und Windows Server 2025 direkt auf dem ZimaCube installierte.
Bob beschreibt die Kombination als ungewöhnlich – genau deshalb hat er sie ausprobiert. Das Projekt wurde zu einer Möglichkeit, die Hardware zu testen, ohne sich auf die mitgelieferte Softwareumgebung zu verlassen: Installationsverhalten, Treibersuche, Netzwerk, Speicher und die Frage, ob eine kompakte NAS-Plattform noch sinnvoll ist, wenn man sie wie einen universellen Windows-Server behandelt.
Das Experiment zeigt außerdem einen wichtigen Aspekt der Zima-Hardwarephilosophie. Die Entfernung von ZimaOS beendet die Nutzungsdauer des Geräts nicht. Die x86-Hardware bleibt eine Plattform, die mit einem anderen Betriebssystem neu aufgebaut werden kann.
Wir haben dieses Experiment in einen strukturierteren Leitfaden zur Einrichtung von Windows Server 2025 auf dem ZimaCube überführt. Er behandelt den Installationsweg, die Einrichtung des Intel-Netzwerktreibers und die Speicherkonfiguration für Nutzer, die denselben Ansatz ausprobieren möchten.
ZimaOS gründlich testen, bevor es weitergeht
Windows Server ist nur ein Teil der Geschichte rund um das Betriebssystem. Bob hat im Homelab-Journal außerdem einen eigenen ZimaOS-Testbericht verfasst.
Seine Schlussfolgerung ist bewusst nuancierter als „gut“ oder „schlecht“. Das Repository beschreibt ZimaOS als eine gute Lösung für kleinere Geräte, stellt jedoch infrage, ob die vereinfachte Bedienung zu dem passt, was Bob von einem ZimaCube erwartet, der immer stärker für Virtualisierung und Homelab-Infrastruktur eingesetzt wird.
Diese Kritik ist hilfreich, da Bob ZimaOS nicht als jemand bewertet, der Self-Hosting zum ersten Mal ausprobiert. Er betrachtet es aus der Perspektive eines Nutzers, der bereits ein Homelab mit mehreren Systemen betreibt und mit der Verwaltung der darunterliegenden Ebenen vertraut ist.
Für einen anderen Nutzer kann die Einfachheit ein Grund sein, dabei zu bleiben. Für Bob wurde die zunehmende Komplexität der Infrastruktur schließlich zum Grund zu wechseln.
Derselbe Zielkonflikt wird in unserem Vergleich von ZimaOS, Proxmox und Windows Server untersucht, der aus derselben umfassenderen Reihe von Experimenten hervorgegangen ist.
Proxmox ins Zentrum des Homelabs rücken
Nach einigen anderen Ansätzen kam Bob schließlich zu einer deutlich klareren Schlussfolgerung darüber, welches Betriebssystem er auf dem ZimaCube verwenden wollte: Proxmox war die Umgebung, die für sein Homelab am meisten Sinn ergab.
Das Journal beschreibt einen ZimaCube, der zusammen mit NFS-Speicher von Synology betrieben wird und Teil eines Clusters aus drei Hosts wird. Zu diesem Zeitpunkt wird das Gerät nicht mehr primär als NAS bewertet. Es ist zu einer Infrastrukturkomponente geworden.
Diese Änderung ebnet den Weg für mehrere spätere Tagebucheinträge, da Proxmox die Grundlage für die nächsten Experimente bildet: Backup-Infrastruktur, Überwachung, KI-Dienste und Netzwerkvirtualisierung.
Für Nutzer, die dieselbe Grundlage schaffen möchten, beschreibt unser Setup-Leitfaden für ZimaCube + Proxmox den Weg von der BIOS-Vorbereitung über VMs, LXC-Container, Speicher und Netzwerk bis hin zu Passthrough.
Backups rund um die Infrastruktur aufbauen
Sobald eine Maschine zur Infrastruktur wird, lautet die nächste Frage nicht mehr, ob sie weitere Dienste ausführen kann. Es geht darum, was passiert, wenn einer dieser Dienste verschwindet.
Bobs Tagebuch Backups dokumentiert diesen Übergang. Der Proxmox Backup Server kommt ins Spiel, ebenso wie die etwas umständliche, zirkuläre Frage, wie man Infrastruktur mit einer Infrastruktur sichert, die selbst Teil des zu schützenden Systems ist.
Das Ergebnis besteht weniger darin, ein einziges perfektes Backup-Ziel zu finden, sondern vielmehr darin, Schichten zu schaffen, die eine vorhersehbare Wiederherstellung ermöglichen, sodass Bob nicht ständig über Backups nachdenken muss.
Diese Erfahrung bildete die Grundlage für unseren Leitfaden zum Proxmox Backup Server. Er führt die Idee mit inkrementellen Backups von VMs und Containern, Aufbewahrung, Überprüfung und zusätzlichen Schutzschichten weiter aus.
Den Verbund überwachen, statt ihn ständig zu überprüfen
Bobs nächste Frage ist jedem vertraut, dessen Homelab über ein paar Dienste hinausgewachsen ist: Wie viel Überwachung braucht eine einzelne Person wirklich?
Sein Eintrag Watching the Fleet stellt unter anderem Pulse und Proxmox Data Center Manager vor. Das eigentlich interessante Ziel besteht jedoch darin, den manuellen Betreuungsaufwand der Infrastruktur zu reduzieren.
Ein nützliches Überwachungssystem sollte nicht noch ein Dashboard schaffen, das den ganzen Tag beobachtet werden muss. Es sollte den Normalbetrieb ruhig und Ausfälle sichtbar machen, wenn tatsächlich Aufmerksamkeit erforderlich ist.
Diesen Teil von Bobs Erfahrung haben wir in unserem Leitfaden zur Überwachung von Heimservern weiter ausgearbeitet. Darin geht es um Pulse, Uptime Kuma, Proxmox Data Center Manager und den Punkt, an dem Überwachung den Wartungsaufwand verringern statt erhöhen sollte.
Einem KI-Agenten ein dauerhaftes Zuhause geben
Das Journal geht schließlich in eine weitere Ebene des Self-Hostings über: den Betrieb eines dauerhaft laufenden KI-Agenten auf dem ZimaCube.
In Warum Hermes Agent auf deinem ZimaCube zu Hause ist betrachtet Bob das Gerät nicht einfach als Speicher- oder Virtualisierungsinfrastruktur, sondern als dauerhaft verfügbaren Ort für den Betrieb eines selbst gehosteten Agenten.
Die Kombination ergibt im Kontext all dessen Sinn, was zuvor kam. Sobald der ZimaCube rund um die Uhr online, mit dem Homelab verbunden, gesichert und überwacht ist, kann ein Agent zu einem weiteren dauerhaft laufenden Dienst werden, statt an eine Laptop-Sitzung gebunden zu sein.
Wenn du diesen Workflow direkt unter ZimaOS erkunden möchtest, behandelt unser Einrichtungsleitfaden für Hermes Agent unter ZimaOS die Installation, die Modellkonfiguration, die Integration von Messaging-Diensten und den Zugriff auf das Hermes-Dashboard.
Den ZimaCube in einen OPNsense-Router verwandeln
Eines der interessantesten späteren Experimente versetzt das Gerät erneut in eine völlig andere Rolle: Netzwerkinfrastruktur.
Bobs OPNsense-Journal untersucht die beiden 2,5-GbE-Schnittstellen des ZimaCube zusammen mit Proxmox und fragt, ob eine Router-VM bisher eine der überzeugendsten Einsatzmöglichkeiten für die Hardware sein könnte.
Hier beginnt sich die frühere Betriebssystementscheidung auszuzahlen. Proxmox ermöglicht es, dasselbe physische Gerät für Workloads zu nutzen, die traditionell mehrere separate Systeme erfordern würden, während die beiden Ethernet-Schnittstellen eine natürliche Möglichkeit schaffen, WAN und LAN innerhalb eines virtualisierten Firewall-Setups zu trennen.
Unser Proxmox-Leitfaden behandelt ebenfalls den Betrieb von OPNsense als Software-Router-VM auf dem ZimaCube, einschließlich der Möglichkeit, separate 2,5-GbE-Schnittstellen an die Netzwerk-Appliance durchzureichen.
Der Wert liegt im Journal, nicht in einem abschließenden Urteil
Als Ganzes betrachtet ist Bobs Projekt weitaus interessanter als ein Testbericht mit einem feststehenden Fazit.
Der gleiche ZimaCube erscheint im Laufe der Repository-Historie in mehreren unterschiedlichen Formen.
Es beginnt als neues Stück Hardware. Bob packt es aus, prüft die Verarbeitung, öffnet das Gehäuse, hinterfragt die Kühlung und beginnt über Upgrades nachzudenken.
Es wird zu einem Windows-Server-Experiment. Durch das Entfernen von ZimaOS wird getestet, ob die zugrunde liegende Hardware auch ohne die mitgelieferte Software noch nützlich ist.
Es führt zurück zur Betriebssystemfrage. Bob bewertet ZimaOS zunächst eigenständig, bevor er zu dem Schluss kommt, dass seine zunehmend komplexe Umgebung etwas anderes benötigt.
Er wird zu einem Proxmox-Host. Von dort aus wird das Gerät Teil einer größeren Flotte und übernimmt zunehmend Infrastrukturaufgaben.
Er wird Teil des Backup- und Überwachungssystems. Proxmox Backup Server, Pulse und die Flottenverwaltung verlagern das Ziel von „immer mehr Dienste hinzufügen“ zu „die Dienste so zuverlässig machen, dass man nicht mehr über sie nachdenken muss“.
Dann wird er zu einem KI-Host und einer Netzwerk-Appliance. Hermes Agent und OPNsense sind keine isolierten Experimente; sie sind möglich, weil die früheren Infrastrukturebenen bereits vorhanden sind.
Das Ergebnis entspricht genau dem, was Bob ursprünglich versprochen hat: keine formelle Bewertung, sondern Notizen, Experimente, Meinungen, die sich mit zunehmender Erfahrung verändern, und ein immer ambitionierteres Homelab-Projekt.
Aus einer Anwendergeschichte wurde eine Bibliothek von ZimaCube-Anleitungen
Bobs Projekt zeigt außerdem, warum langfristige Community-Tests über das Homelab einer einzelnen Person hinaus wertvoll sind.
Mehrere im ZimaCube-Erfahrungsblog dokumentierte Experimente haben sich inzwischen zu ausführlicheren Zima-Ressourcen entwickelt: Installation von Windows Server, Proxmox-Bereitstellung, Auswahl des Betriebssystems, Backup-Architektur und Homelab-Überwachung.
So entsteht eine nützliche Verbindung zwischen Community-Erfahrungen und Dokumentation. Bob probiert etwas aus, weil er neugierig ist. Das Journal hält fest, was passiert ist. Die nützlichen Teile lassen sich für die nächste Person leichter nachstellen.
Die Geschichte wird noch geschrieben
Die Geschichte von Bob Loves Tech und Zima wird noch geschrieben. Sein ZimaCube-Erfahrungsblog hat sich bereits vom Auspacken und Zerlegen der Hardware über ZimaOS, Windows Server, Proxmox, Backups, Flottenüberwachung, Hermes Agent und OPNsense weiterentwickelt – und der eigentliche Sinn eines laufenden Journals besteht darin, dass es keine endgültige Konfiguration geben muss.
Wenn sich das Homelab verändert, kann sich auch die Rolle des ZimaCube verändern. Wenn Sie sehen möchten, womit Bob als Nächstes experimentiert, folgen Sie dem fortlaufenden ZimaCube-Erfahrungsblog auf GitHub.
