How Koroma Tech Tests ZimaBoard 2 With Proxmox and TrueNAS

Koroma Tech found that ZimaBoard 2 works best as a compact, silent home-lab platform for lightweight services, containers, storage, and focused virtualization. His tests show that the board can run its browser-managed default server environment, Proxmox with an Ubuntu LXC container, and TrueNAS with a mirrored two-drive pool—but its four-core Intel N150 should not be treated like a high-end virtualization host.

Thank you to Koroma Tech for documenting the complete setup and sharing where the hardware fits in a real home lab. His original video covers the hardware, two-drive assembly, initial server interface, NVMe expansion, Proxmox installation, Ubuntu LXC test, and TrueNAS storage configuration.

Collaboration disclosure: The ZimaBoard team supplied the board and accessories shown in Koroma Tech's video. The creator states that he is sharing his own experience and intended use. Software versions, interface details, hardware bundles, and compatibility may change after publication.

The result: ZimaBoard 2 is not a miniature replacement for a many-core rack server. Its strength is combining silent operation, dual 2.5GbE networking, direct SATA storage, and open PCIe expansion in a small x86 system that can be assigned one well-defined home-server role.

From the Original ZimaBoard to a New Home-Lab Node

Koroma Tech begins with useful long-term context. He already owns two original ZimaBoard 832 systems and has used them as a firewall, Docker server, and general home-lab hardware. He plans to reuse those older boards in a Proxmox cluster, so the ZimaBoard 2 review is grounded in actual experience rather than a first encounter with the product category.

The new board preserves the compact, fanless aluminum design while updating the processor, memory, networking, and expansion options. Koroma Tech's intended destination for the review unit is a dedicated NixOS development server inside his home lab—a role that matches the platform's strengths: quiet operation, continuous availability, Linux compatibility, and enough expansion for project-specific storage or interfaces.

That intended use also frames the rest of the test. Instead of asking whether the board wins synthetic desktop benchmarks, he asks whether it can serve as a practical application host, lightweight hypervisor, or compact NAS.

What the ZimaBoard 2 Hardware Is Designed to Handle

The ZimaBoard 2 Mini Home Server is built around an Intel N150 processor. Intel lists the N150 as a four-core, four-thread processor with a maximum turbo frequency of 3.6GHz and a 6W processor base power in its official specifications.

Koroma Tech reviews the 16GB memory and 64GB eMMC model. The smaller configuration uses 8GB of memory and 32GB of eMMC storage. The processor is the same, so the larger model does not turn into a higher-core compute server; instead, the extra memory gives containers, applications, and limited virtualization more breathing room.

Why the Dual 2.5GbE Intel Ports Matter

Koroma Tech highlights networking because it addresses two frustrations he encountered with an original ZimaBoard used as a firewall. That older setup used Realtek networking, and he experienced occasional connection drops and additional driver work in OPNsense. Its 1GbE ports also became a constraint when routing traffic between VLANs.

The two 2.5GbE Intel interfaces on ZimaBoard 2 increase the available network bandwidth and create a cleaner foundation for a router, firewall, segmented home network, or fast NAS link. The second port can separate traffic paths instead of forcing every workload through one interface.

Dual ports alone do not define the configuration. A firewall still requires deliberate interface assignment and security rules, while a storage server needs a 2.5GbE-capable switch and client before transfers can exceed gigabit speeds. The hardware removes an immediate port limitation; the network design determines whether that advantage is realized.

Building the Two-Drive and PCIe Expansion Stack

The review includes a two-bay HDD rack, PCIe riser, adapter card, and optional fan. Koroma Tech mounts the board on the drive dock, secures the riser assembly, installs two drives, and connects the SATA data-and-power cable. The drives also help stabilize the rack through the side mounting points.

He then adds an NVMe adapter through PCIe. This creates a useful three-layer storage plan: onboard eMMC for the original lightweight environment, NVMe for an alternative operating system or virtualization host, and two SATA drives for data.

The completed setup is larger than the bare board but remains open and accessible. That matters in a home lab, where replacing a drive, changing an adapter, or rerouting a cable should not require dismantling a tightly sealed appliance.

Exploring the Browser-Managed Server Environment

After assembly, Koroma Tech boots the supplied server environment and accesses it from a web browser. The interface provides a dashboard for storage, system status, Docker-based applications, and common self-hosting tasks. This route is the easiest starting point when the goal is to deploy services without first constructing a virtualization stack.

The default experience and the later bare-metal tests serve different users. A browser-managed application platform reduces setup friction for file services and containers. Proxmox provides greater control over isolated systems. TrueNAS focuses the machine more directly on storage pools, shares, data protection, and storage applications.

The important decision comes before installation: choose the operating environment based on the main job of the server. Installing multiple platforms merely because the hardware supports them can create unnecessary migrations and fragmented storage.

Why Koroma Tech Installs Alternative Systems on NVMe

Koroma Tech explains that Proxmox and TrueNAS can technically be installed on the onboard eMMC, but he chooses an NVMe drive. His concern is sustained disk activity: virtualization platforms, databases, logs, metadata, and system updates can generate more writes than a lightweight supplied environment.

Using NVMe separates the alternative operating system from the two SATA data drives and preserves the onboard eMMC environment. It also makes the storage roles easier to understand: NVMe handles the active system, while the HDDs hold the capacity-oriented pool.

This is a design decision rather than a universal requirement. A small test installation may function from eMMC, but long-term reliability depends on workload, free space, write volume, backups, and the endurance of the actual storage device. Koroma Tech chooses the more conservative route for the systems he intends to test.

Running Proxmox and an Ubuntu LXC Container

Koroma Tech enters the BIOS, boots from a Proxmox USB installer, and installs Proxmox on the NVMe drive. The installation completes normally, after which he deploys an Ubuntu LXC container to verify that the virtualization environment is functional.

The container runs successfully. This is significant because containers fit the available hardware better than a collection of full virtual machines. Proxmox explains that its platform integrates KVM virtual machines with Linux Containers, which isolate Linux environments while sharing the host kernel.

That shared-kernel model generally requires fewer resources than giving each workload an entire guest operating system. On a four-core, 16GB home server, LXC containers can therefore leave more CPU and memory available for the services themselves.

Where the Proxmox Workload Should Stop

A successful installation does not mean every virtualization plan is appropriate. Koroma Tech repeatedly notes that the Intel N150 has four cores. Several lightweight containers can be a sensible use of the system, but multiple resource-intensive virtual machines may compete for the same CPU time and memory.

A realistic Proxmox plan might include a small Linux container for a web service, another for network utilities, and a carefully sized test environment. The workload becomes less suitable when it requires multiple always-busy VMs, heavy compilation, large databases, intensive surveillance analysis, or other sustained CPU tasks.

For readers choosing between deployment models, the ZimaSpace guide to bare metal, Docker, and Proxmox home-lab tradeoffs helps separate isolation needs from unnecessary virtualization overhead.

Turning the Same Hardware Into a TrueNAS Server

Koroma Tech next replaces Proxmox with TrueNAS, again installing the operating system on NVMe. The installation completes without an unusual workaround, and the dashboard detects the onboard eMMC, NVMe system drive, and two SATA hard drives.

He creates a pool from the two HDDs and selects a mirrored layout. TrueNAS defines a mirror as a VDEV in which each disk stores an exact copy of the data. It requires at least two drives, and the available capacity equals the size of a single disk, according to the TrueNAS pool documentation.

The mirror protects availability against the failure of one member disk, but it is not an independent backup. Accidental deletion, malware, application errors, and damage to the complete system can affect both copies. Important data still needs a separate backup, ideally including a copy outside the server.

Proxmox or TrueNAS: Which Test Better Matches the Hardware?

Koroma Tech considers TrueNAS especially natural with the external two-drive rack because the storage hardware has an obvious role. Proxmox is also viable, but the value comes from lightweight containers and selective virtualization rather than maximizing the number of guests.

What the Review Proves—and What It Does Not

Who Should Consider This ZimaBoard 2 Setup?

This configuration makes sense for someone building a first or secondary home-lab node, a compact two-drive NAS, a dedicated development server, a Docker or LXC host, a network appliance, or a Home Assistant system. It is particularly attractive when fanless operation and open expansion matter more than raw multi-core performance.

The 8GB model can cover a focused light-duty role. The 16GB model gives more room for multiple containers, caching, file services, and experimentation, although the unchanged four-core processor still sets the compute boundary. Buyers should choose the configuration according to the number and behavior of workloads, not memory alone.

A larger server is the better choice when the plan depends on numerous full VMs, high concurrent compute, memory beyond the platform limit, many internal drives, or multiple PCIe devices. ZimaBoard 2 is strongest when its job can be stated clearly.

A Small Server Becomes Useful Through Role Clarity

Koroma Tech's review supports the title of his video: the ZimaBoard 2 is small, but it should not be underestimated. The hardware successfully moves between an accessible server interface, Proxmox with Ubuntu LXC, and TrueNAS with mirrored SATA storage.

The tests also establish the correct boundary. PCIe and NVMe can expand storage and functionality, but they do not transform a four-core N150 into a dense virtualization server. The best deployment gives the board a focused role and chooses containers, storage layouts, and operating systems that respect its resources.

Watch Koroma Tech's complete review for the physical assembly and full interface demonstrations. For more home-server experiments, deployment ideas, and practical feedback from other builders, join the ZimaSpace Discord community.