How I Built a 3-Node Proxmox Cluster Around the ZimaCube 2 as the Shared Storage Backend

Three Proxmox nodes. One ZimaCube 2. Ten gigabit Ethernet. All of it sitting inside an Ikea Kallax shelf, running 24/7, quieter than the refrigerator in the next room.

This is not a hypothetical build. This is my homelab — a fully 3D-printed 10-inch rack that fits cleanly into a standard Kallax cube, with the ZimaCube 2 at the bottom acting as the shared storage brain for the entire cluster. Here is why I chose the ZimaCube 2 for this role, how I integrated it, and what I learned along the way.

The Architecture

My cluster has three compute nodes running Proxmox with eMMC boot storage and ZFS replication between them. The goal is full high-availability HCI — if one node goes down, workloads migrate automatically and storage stays consistent.

But ZFS replication between three nodes only gets you so far. You still need a shared storage backend — something with enough capacity, enough bandwidth, and enough reliability to serve as the single source of truth for the entire cluster. That is where the ZimaCube 2 comes in.

Why the ZimaCube 2 as a SAN/NAS Backend

I looked at a lot of options before landing on the ZimaCube 2. Here is what made it the right choice:

What I Needed

• 6+ drive bays for mixed HDD/NVMe pools

• 10GbE to serve the cluster without bottlenecking

• PCIe expansion for future GPU/NIC upgrades

• Docker-native for running infrastructure services alongside storage

• Quiet enough for a living space (not a basement)

• Compact enough to fit in a Kallax cube

What the ZimaCube 2 Delivers

• 6× SATA3 bays + 4× M.2 NVMe in the 7th Bay

• 10GbE (Marvell AQC113) + 2× 2.5GbE (Intel i226)

• PCIe x16 Gen4 + PCIe x8 Gen3 slots

• Pre-installed ZimaOS with Docker support

• 240 × 221 × 220 mm — exactly Kallax-compatible

• Metal chassis with active cooling, near-silent at idle

The 10GbE port was the deciding factor. If you are serving storage to three hypervisor nodes simultaneously, a single gigabit link becomes the bottleneck on day one. The ZimaCube 2 10GbE means I can saturate the cluster network before I saturate the storage backend.

Storage Configuration

Here is how I laid out the storage pools on the ZimaCube 2:

The cluster accesses the ZimaCube 2 over a dedicated 10GbE link. Each Proxmox node connects via 2.5GbE to a managed switch, with the ZimaCube 2 on the 10GbE uplink port. VM live migrations happen over NFS from the NVMe pool. Media and backups live on the HDD pool. Everything is ZFS-backed with snapshots.
RAM upgrade note: The ZimaCube 2 ships with 8GB DDR5 (Standard) or 16GB (Pro). For a ZFS-based storage backend, more RAM is better — ZFS uses ARC (Adaptive Replacement Cache) in memory, and every gigabyte of ARC is a gigabyte of storage that does not touch disk. I added a 32GB DDR5 SODIMM stick to bring the total to 40GB, which gives ZFS plenty of ARC headroom without starving the Docker containers.

The Physical Build: 3D-Printed Everything

The entire setup lives in a 10-inch rack format, 3D-printed on an Elegoo Centauri Carbon and designed to fit exactly inside a standard Ikea Kallax shelf cube.

The ZimaCube 2 sits at the bottom of the rack — its weight and cooling requirements make it the natural base. Above it: three compute nodes, a dedicated firewall appliance, and a patch panel. Everything is mounted with custom 3D-printed brackets and vent panels.

All STL files and remixes are available on MakerWorld and Printables. I designed custom mounts for the ZimaCube 2, the ZimaBlade units, and the firewall appliance.

Why Not TrueNAS or Unraid?

I kept ZimaOS on the ZimaCube 2 instead of wiping it for TrueNAS or Unraid. Here is my reasoning:

1.Docker-native from day one. No plugin system to fight with. docker-compose up and you are done.

2.ZFS support built in. The ZimaOS storage manager handles ZFS pool creation and snapshot scheduling without requiring terminal time.

3.IceWhale is actively developing it. I am testing a ZimaOS Beta build directly from their team — the responsiveness to community feedback has been genuinely good.

4.I wanted to test the platform as designed. You can always wipe and install something else later. But if ZimaOS handles the workload, that is one less operating system to configure and maintain.

For a cluster storage backend, stability matters more than features. So far, ZimaOS has delivered.

What is Running on the Cluster

The three Proxmox nodes currently host:

• Home Assistant with Zigbee2MQTT — smart home automation
• Frigate NVR on a dedicated ZimaBlade with Coral TPU — 4 outdoor cameras, object detection offloaded to the TPU
• Paperless-ngx — document management
• Vaultwarden — password management
• Nginx Proxy Manager — reverse proxy and SSL
• Pi-hole — network-wide DNS filtering
• Gitea — self-hosted Git for personal projects
• Several development VMs for testing and learning

The ZimaCube 2 also runs a few infrastructure containers directly: Uptime Kuma for monitoring, a backup orchestrator, and the ZFS snapshot scheduler.

Build your own cluster storage backend with ZimaCube 2 →

Frequently Asked Questions

Why use a ZimaCube 2 instead of a traditional NAS for a Proxmox cluster?

Three reasons: 10GbE, PCIe expansion, and ZFS-native architecture. Most consumer NAS devices ship with 1GbE, which bottlenecks immediately when serving multiple hypervisors. The ZimaCube 2 10GbE port plus dual 2.5GbE gives you the bandwidth to serve storage without contention. And the PCIe slot means you can add a GPU or faster NIC later without replacing the entire device.

Can ZimaOS handle ZFS well enough for cluster storage?

Yes. ZimaOS includes ZFS pool creation, snapshot scheduling, and health monitoring in its storage manager. For a cluster backend, the key features — pool creation, NFS/SMB sharing, snapshot automation — are all there without requiring terminal configuration.

How much RAM does the ZimaCube 2 need for ZFS?

ZFS uses RAM for ARC (cache), and more RAM means faster read performance. The stock 8GB or 16GB is workable for light workloads, but for serving multiple VMs or containers with a large dataset, upgrading to 32GB or 64GB is recommended. SODIMM DDR5 slots are user-accessible — the upgrade takes minutes.

What is the advantage of keeping the Coral TPU on a separate ZimaBlade instead of the ZimaCube 2?

Offloading Frigate object detection to a dedicated ZimaBlade with Coral TPU keeps inference load entirely off the ZimaCube 2 CPU and GPU. The ZimaCube 2 handles storage and Docker services; the ZimaBlade handles real-time video analysis. Separating those workloads prevents camera processing from competing with VM I/O or AI inference on the main system.