ZimaBoard ist ein kleiner x86/x64 Singleboard Computer. Ähnlich dem Raspberry Pi hat das ZimaBoard aber den Vorteil der entsprechenden Prozessorarchitektur und der Anschlüsse – zwei 1 Gbit/s Ethernet Ports, 2 USB 3.0, 2 SATA Ports und ein PCIe 2.0 4x Slot sind vorhanden.

Nachdem ich längere Zeit damit geliebäugelt habe, habe ich mir das ZimaBoard 832 bei einem Sale gekauft.

Aussehen / Aufbau

Als ich das ZimaBoard dann in meinen Händen halten konnte sah es erstmal sehr wertig und gut verarbeitet aus. Nachdem ich die ersten Leitungen und die PCIe Erweiterungskarte für NVMe angeschlossen hatte konnte ich mir das Grinsen nicht ganz verkneifen über das, dem Formfaktor geschuldetem, Guerilla/Harakiri-Design.

Kommt man an irgendetwas ran, kann man versichert sein, das es danach erstmal wieder zusammengebaut werden muss. Im Worst Case war das Gerät in Betrieb und ist jetzt kaputt.

Man kann den Kühlkörper und die Plastikschale entfernen und den SBC auch in ein Gehäuse einbauen. Allerdings sollte man schauen, dass wenigstens auf der CPU ein kleiner Kühlkörper aufgeklebt wird.

Ich habe mir von Printables ein kleines Gerüst für das ZimaBoard mit angesteckter NVMe Erweiterungskarte drucken lassen und diese dann entsprechend angeschraubt. So ist zumindest ein versehentliches Verrutschen nicht möglich.
Hier die Platte: https://www.printables.com/de/model/215289-zimaboard-wall-mount-for-generic-pcie-cards

Den Standort des Computers sollte man sich auch gut überlegen, die LEDs von dem Ding sind sehr hell – also besser nicht in das Schlafzimmer und selbst das Wohnzimmer würde ich als grenzwertig empfinden.

Die Frage ist natürlich, was man mit dem Gerät nun anstellen kann und ob es denn überhaupt etwas taugt. Als Beispiele werden auf der Webseite https://www.zimaboard.com/ NAS, Firewallrouter oder auch Cloudspeicher und Smart Home genannt. Alle genannten Möglichkeiten kann man über das auf der eMMC vorinstallierte CasaOS per Docker installieren.

CasaOS

CasaOS ist eine, ebenfalls vom Hersteller IceWhale Tech in China, programmierte Weboberfläche und ein Shell-Skript um auf Debian entsprechende Tools schnell und einfach zu installieren. Eine Demo ist auf der Webseite vorhanden und der Open Source Code ist auf Github zur Verfügung gestellt. Prinzipiell also eine gute Möglichkeit vordefinierte Container Apps zu installieren und in wenigen Schritten betriebsbereit zu haben, schwächelt es allerdings vor allem bei tiefergehenden Einstellungen und Docker-Compose Stacks. Zumindest im Moment – es wird aktiv daran entwickelt und in aller Regelmäßigkeit kommen neue Funktionen hinzu und werden Bugs behoben.

Ich habe CasaOS allerdings nicht in Verwendung, besonders wegen der Desktop Environment, welche natürlich einige Ressourcen von der CPU und dem RAM aufwendet. Installiert auf einem headless System kann ich mir die WebGUI allerdings sehr gut vorstellen.

Funktioniert denn der Desktop Betrieb allgemein?

Also jain, für normales arbeiten ist es durchaus ausreichend, aber ein wirklichen Rechnerersatz würde ich das nicht nennen. Der Härtetest 4K Streaming ist zumindest krachend fehlgeschlagen. Das Video hat geruckelt bzw. ist komplett stehen geblieben, während der Ton weiterlief. Updates dauerten ebenfalls länger als heute vielleicht gewohnt, was aber durchaus auch am eMMC-Speicher liegt.

Mein erster Gedanke danach war, installiert man Windows 10. Falls ich mit dem Gerät anschließend doch nichts anfangen kann, kann man vielleicht einen kleinen Windows Rechner draus machen. Ja, nein. Auch hier läuft das System fast ausschließlich am Anschlag bei der CPU bei kleinsten Tätigkeiten – Maus über den Desktop bewegen beispielsweise. Auch 4K Streaming liefen erst nicht, aber diesmal wenigstens nur ruckelnd ohne Standbild.

Nach einer Treiberinstallation von der Intel iGPU HD Graphics 500 lief das 4K Streaming sauber durch, aber weiterhin kam die hohe CPU Belastung zum Vorschein. Auch Updates dauerten auf Grund der limitierten CPU und des langsamen Speichers sehr lange. Also Windows ist auch nicht wirklich dafür geeignet. Ein headless Betrieb ist deutlich zu bevorzugen.

BIOS

Wenn notwendig kann man im BIOS einige Änderungen einstellen, wo ich auch gleich erstmal Intel-VT aktiviert habe um meine endgültige Entscheidung Proxmox zu realisieren. Zudem gibt es dort die Möglichkeit den RAM für die iGPU auf 512 MB hochzusetzen. Allerdings, nach meinen Erfahrungen, würde ich einen Multimedia-Ansatz eher nicht ins Auge fassen.

Nur scheint das BIOS nicht korrekt lizensiert zu sein und zeigt mir eine klare Info an, dass das eine Evaluierungsversion zu sein scheint. Ich konnte keine Information zur Lizensierung für American Megatrends BIOS finden. Normalerweise sind Evaluationslizenzen aber nicht für den Verkauf bzw. produktiven Einsatz gedacht, was zumindest einen negativen Beigeschmack hinterlässt. Ein BIOS Update konnte ich auf der aktuellen Seite auch nicht finden. Da heißt es zum momentan Zeitpunkt nur, dass eine neue BIOS Version getestet wird und bald erscheinen soll.
Na ich hoffe nicht, dass ich denen jetzt das Testgerät abgekauft habe… Falls das doch so ist – bitte melden.

OS installieren

Also eine Idee war vorhanden – Proxmox installieren und mal schauen, ob man mit Linux Containern und Docker einen “exposed Server” zur Verfügung stellen kann. Also alle ankommenden Internetanfragen werden über Portweiterleitungen nur noch an das ZimaBoard weitergeleitet und entweder direkt oder als Reverse Proxy verarbeitet. Also stand die Frage im Raum, welchen primären Speicher verwendet man.

eMMC Speicher ist erwartungsgemäß langsam, NVMe über eine Erweiterungskarte am PCIe Slot könnte allerdings zu überdimensioniert sein für die Leistung des Prozessors und der Version des PCIe 2.0 Slots. SSDs per SATA wäre also als primär anzusehen. SSDs sind aber mittlerweile teurer als NVMe Speicher. HDDs über den SATA Port sollte man nur mit zusätzlicher Stromversorgung realisieren. Also der Entschluss stand fest Proxmox doch auf dem eMMC zu installieren und den NVMe Speicher als VM Speicher zu verwenden.

Bei der Proxmox Installation gab es dabei zwei mögliche Wege, entweder direkt mit dem ISO Image – das funktionierte allerdings nicht. Die direkte Proxmox Installation von Version 7.3 scheint nämlich mit dem eMMC Probleme zu haben und schafft es nicht den Boot-Record korrekt zu schreiben.

Oder über eine Debian Installation aus den Paketquellen darüber installiert, dann auch auf dem eMMC. Ich habe mich da an die offizielle Anleitung gehalten und das funktionierte tatsächlich recht gut.

Achtung: Solltet ihr das ebenfalls probieren, achtet darauf unter /etc/hosts den Hostname der momentanen IP-Adresse – nicht der Loopback Adresse – zuzuweisen. Ansonsten kann die Konfiguration von Proxmox nicht gestartet werden.

Linux Container erstellen

Anschließend lief Proxmox direkt sehr gut. Noch die beiden Netzwerkanschlüsse in einen Active-Backup Bond gepackt und für diesen Bond eine Bridge erstellt, damit auch die Container und VMs mit dem Netzwerk kommunizieren können.

Der erste Container wurde ein Docker Linux Container. Aufgepasst jetzt wird es kompliziert, ich betreibe Docker-Container in einem Linux-Container – abgefahren. Funktionierte aber leider erst nicht. Das von Proxmox vorhandene Template für Debian scheint Probleme zu haben. Nach der Umstellung auf das Ubuntu Template für den Linux Container lief Docker dann im LXC.

Achtung: Es kann sein, dass beim Starten eines Docker Containers eine Fehlermeldung kommt. Die Lösung ist den Storage Driver vfx zu verwenden. Außerdem sollte bei dem Linux Container, in dem Docker installiert werden soll, Nesting und keyctl aktiviert sein. Damit kann der virtualisierte Container weitere Virtualisierungen durchführen.

Der nächste Gedanke war dann, zu prüfen, wie sich ein Gamingserver auf dem Teil verhält. Dazu einen weiteren LXC erstellt, diesmal mit der Debian Vorlage, und über die LinuxGSM Skripte einen TeamSpeak 3 und einen Minecraft Bedrock Server installiert. Läuft Problemlos. Ist natürlich nicht für 500 Benutzer vorgesehen, aber ein kleiner Freunde und Familien Server kann damit durchaus realisiert werden. Und auch ein OpenTTD Server mit einer Kartengröße von 2048×2048 läuft auf dem ZimaBoard.

VMs sollte man allerdings meiden, vor allem mit Desktop Umgebung. Es hat schon als Baremetal Installation nicht wirklich funktioniert und als VM ist die Leistungsfähigkeit des Betriebssystem noch geringer.

Fazit

Dann komme ich mal zum Ende. Würde ich das ZimaBoard weiterempfehlen? Kommt drauf an.

Der kleine Computer ist gut und besonders die Schnittstellen separieren ihn von anderen SBCs. Aber wenn ich das jetzt mit dem Raspberry Pi 4 Model B mit 8 GB vergleiche, welcher bei mir bereits gute Dienste leistet, dann ist der Einsatzzweck des ZimaBoards zumindest für mich fragwürdig. Das meiste kann auch der Rapsberry Pi mittlerweile sehr gut und performant. Natürlich hat das Zimaboard aber nochmal ein paar Prozente mehr, die es aufdrehen kann. Aber besonders bei x86 Anwendungen kann der Rapsberry Pi nicht mithalten, wenn es kein für ARM x86 emuliertes Docker Image gibt, wie beispielsweise für den Teamspeak 3 Server.

Wenn ich allerdings an die momentane Marktsituation denke und sehe wie es den Raspberry Pi 4 momentan entweder gar nicht oder nur zu Preisen gibt, welche nicht gerechtfertigt sind, dann ja ZimaBoard ahoi – auf jeden Fall!

Mal abgesehen von dem merkwürdigen BIOS.
Wie gesagt, schreibt mich an, wenn ihr das Gerät wieder zurück haben wollt. 😉

Nachtrag 2023-05-22

Ich habe nun nach und nach meine Netzwerkanwendungen auf das Zimaboard umgezogen. Die Leistung des Geräts macht es möglich. Zudem ist das Gerät auch noch ein wenig kühler als das Raspberry PI 4 mit Argon Gehäuse. Das bewirkt, dass das Zimaboard länger unter Volllast laufen kann.

Ich kann es nur wiederholen, nach dem momentanen Preis-/Leistungsverhältnis macht das Zimaboard am meisten Sinn. Auch wenn weiterhin das BIOS “Problem” nicht gelöst ist.

Wer ein Raspberry Pi 4 sein eigen nennt, und nur wenige Dienste laufen lässt, ist aber auch weiterhin mit dem Pi gut bedient.