Why Proxmox VE Needs Totally Disaggregated Storage Architecture

The hypervisor migration to Proxmox VE is the easy part. The storage architecture underneath it determines whether the environment scales on budget or stalls at the first capacity gap. Most IT teams treating Proxmox as a VMware replacement install it on whatever hardware their old licensing budget frees up. Then the storage requirements diverge — database VMs need IOPS, file servers need capacity, backup repositories need both — and the hardware that worked for the first workload fails the second one at a cost that did not show up in the migration TCO model.

That divergence hits hardest in environments where compute and storage are forced to scale together. Hyperconverged infrastructure, which packages compute, storage, and networking into a single node type, works well when workloads are uniform. Proxmox VE environments are not uniform. A single cluster running OLTP databases alongside file servers and long-retention backup repositories generates storage demand that grows faster and differently from compute demand. Scaling that by adding HCI nodes means buying CPUs, memory, and licensing that the database workload does not need, just to get the disk bays the file workload requires.

Totally disaggregated architecture eliminates that coupling entirely. Instead of one node type that scales everything together, the architecture separates storage into three distinct hardware layers: an HCI controller that runs the Proxmox VE virtualization layer with active-active RAID, a dedicated RAID controller that handles storage processing independently, and an EBOD (Expansion Box of Drives) that provides raw capacity that scales without touching either controller. Each layer scales on its own axis. This blog covers how that architecture works, what each component contributes, and why it is the right storage foundation for enterprise Proxmox VE deployments.

What Total Disaggregation Means for Proxmox VE Storage Infrastructure

Total disaggregation takes the separation of compute and storage further than standard disaggregated or hyperconverged architectures. Standard disaggregation separates compute nodes from storage nodes, but typically leaves the storage processing and capacity coupled inside each storage node. Total disaggregation splits the storage layer itself into processing and capacity, creating three independent scaling planes instead of two.

How the Three-Node Architecture Splits Compute, Storage Processing, and Capacity

The three components in a totally disaggregated Proxmox VE appliance serve distinct functions. The HCI controller runs the Proxmox VE hypervisor and provides active-active RAID access to storage, handling all VM I/O and virtualization operations. The RAID controller is a dedicated hardware appliance that manages all parity calculations, disk rebuild operations, and drive-level redundancy independent of the HCI controller. The EBOD provides raw disk capacity — drives in a shelf connected to the RAID controller — with no compute or processing of its own.

This three-way split means no component is asked to do double duty. The HCI controller dedicates its CPU cycles to running VMs rather than managing storage RAID operations. The RAID controller processes storage at the hardware level without competing for compute resources. The EBOD provides capacity that can expand, contract, or be replaced without affecting either controller.

Totally Disaggregated Versus Conventional HCI in a Proxmox VE Environment

The difference compounds as the environment grows. At a 50 TB storage footprint, the three approaches may be cost-competitive. At 500 TB and beyond, the cost per usable terabyte diverges sharply because totally disaggregated architecture does not require buying compute or RAID processing that the workload does not need.

Why Three Axes of Scaling Matter for Mixed Proxmox VE Workloads

Proxmox VE’s flexibility as a hypervisor means the workloads running on a single cluster often have incompatible scaling profiles. A database tier needs IOPS and low latency; a file server needs capacity; a backup target needs sequential throughput and retention space. In an HCI cluster, all three workloads compete for the same node resources, and expanding for one means overprovisioning for the others.

Totally disaggregated architecture handles each workload’s growth independently. The backup repository needs more capacity? Add an EBOD shelf — the HCI controller and RAID controller keep running unchanged. The database tier needs more RAID processing throughput? Upgrade the RAID controller — the EBOD shelves and HCI controller remain in place. The Proxmox cluster needs more VM compute density? Expand the HCI controller — storage capacity and RAID processing are unaffected. Each decision is independent because each resource type has its own hardware.

How the HCI Controller Delivers Active-Active RAID for Proxmox Workloads

The HCI controller in a totally disaggregated architecture is the node that runs the Proxmox VE hypervisor and presents storage to VMs. Its defining characteristic is active-active RAID — both RAID controller paths are operational simultaneously, serving I/O, rather than the active-passive model where one controller sits idle waiting for a failover event.

Active-Active Versus Active-Passive: What Changes for Proxmox I/O Performance

In an active-passive RAID configuration, all I/O passes through the active controller. The passive controller monitors the active controller’s health but processes no data until a failure triggers failover. That means half the available RAID processing capacity is unused during normal operation, and any failure triggers a controller restart that interrupts I/O in flight.

Active-active RAID keeps both controllers processing I/O simultaneously. In a Proxmox VE environment, this means VMs can access LUNs through either controller path, and the aggregate I/O throughput available to VM disk operations is the sum of both controllers rather than the capacity of one. The published benchmarks that vendors cite for local or HCI-attached storage are typically measured against a single controller path; active-active architecture effectively doubles the available storage throughput for the same hardware footprint.

How Dual Active Controllers Maintain VM I/O During Component Failures

The more significant advantage is failover behavior. In an active-passive system, when the active controller fails, I/O must pause while the passive controller takes over, detects the state of in-flight operations, and resumes. That pause — typically measured in seconds — is long enough for application timeouts in latency-sensitive workloads.

In an active-active configuration, when one controller fails, the surviving controller is already processing I/O. The failover is a load redistribution rather than a service restart: the surviving controller picks up the failed controller’s LUNs while continuing to serve its own, without an I/O interruption gap. For Proxmox VE VMs running databases or transaction processing, that difference eliminates the timeout scenarios that active-passive architectures introduce.

How LUN Presentation Differs from the Standard Proxmox Storage Model

Proxmox VE natively supports iSCSI and Fibre Channel as storage backends, and the HCI controller presents LUNs through one or both protocols depending on the appliance configuration. What differs from a standard iSCSI target deployment is that each LUN is reachable through both controller paths simultaneously. Proxmox VE’s multipath configuration sees both paths and load-balances I/O across them automatically, treating the active-active RAID controller as a single storage target with two equal routes.

This is transparent to the hypervisor. Proxmox VE configures the storage as a standard block backend — ZFS over iSCSI or LVM over iSCSI — and the multipath layer handles path selection and failover. The operational result is that VM disk I/O benefits from both controllers’ throughput during normal operation and experiences zero path-change latency during a controller failure.

Why a Dedicated RAID Controller Changes the Proxmox Storage Equation

In a totally disaggregated architecture, the RAID controller is a physically separate appliance from the HCI controller. It contains its own CPU, memory, and cache, dedicated entirely to storage operations. This separation has consequences for performance, rebuild behavior, and workload isolation that matter specifically in Proxmox VE environments.

What Offloading RAID Processing Means for Proxmox VM Performance

RAID processing is computationally inexpensive in small arrays and becomes a measurable overhead at scale. Parity calculations for RAID 5 or RAID 6, checksum verification during reads, background scrub operations, and disk rebuilds after a drive failure all consume CPU cycles and memory bandwidth. In an HCI node where the same CPU runs Proxmox VE and all its VMs, those storage operations compete directly with VM workloads for processor time.

A dedicated RAID controller eliminates that competition entirely. The HCI controller’s CPU runs VMs, the Proxmox VE management stack, and the hypervisor overhead. The RAID controller’s CPU handles every storage operation — parity, scrubs, rebuilds, cache management — without touching the resources that VMs depend on. In practice, this means VM performance does not degrade during a disk rebuild, scrub, or sequential read scan, because the RAID controller absorbs the entire storage processing load.

How Hardware RAID Protects ZFS Integrity in a Proxmox VE Environment

Proxmox VE uses ZFS as its default storage stack, and ZFS has an established compatibility consideration with RAID controllers. ZFS expects direct access to drives — it manages its own data integrity through checksums and assumes it controls when and how data reaches the disk platter. RAID controllers with write-back caching can bypass ZFS’s integrity guarantees if the controller acknowledges a write before the data is actually committed to stable storage.

The dedicated RAID controller in a totally disaggregated architecture addresses this correctly by supporting controller-level battery-backed or flash-backed write cache that is consistent with ZFS’s expectations. ZFS sends a write, the RAID controller stores it in non-volatile cache, confirms completion to ZFS, and destages to disk asynchronously — all within ZFS’s transactional integrity model. The controller does not reorder or modify the data, and it does not present a virtualized geometry that obscures what ZFS expects to see. The result is that ZFS on the HCI controller treats the RAID controller’s LUNs as reliable block devices, with the RAID layer providing drive-level redundancy and ZFS providing volume-level checksumming.

Rebuild Performance Isolation During Drive Failure Events

When a drive fails in a traditional HCI node, the rebuild draws CPU and I/O resources from the same pool that running VMs depend on. In a small cluster with spare I/O headroom, the performance impact may be imperceptible. In a cluster running near capacity — which is where production Proxmox VE environments typically operate — a rebuild can degrade VM I/O latency measurably.

In a totally disaggregated architecture, the dedicated RAID controller handles rebuilds entirely within its own hardware. The rebuild reads data from surviving drives, calculates parity, and writes to the replacement drive — all through the RAID controller’s CPU, cache, and dedicated backplane. The HCI controller and its VMs see no change in available I/O throughput. For Proxmox VE clusters running workloads with tight I/O latency requirements, this isolation is the difference between a rebuild that goes unnoticed and one that triggers application performance alerts.

EBOD and the Economics of Granular Storage Scaling for Proxmox VE

The EBOD is the third node in a totally disaggregated architecture and the simplest component operationally. It is a drive shelf — a chassis containing drives, power supplies, and SAS or SATA expander backplanes, with no compute, no RAID processing, and no hypervisor. Its only function is to provide raw storage capacity to the RAID controller.

How EBOD Scaling Changes the Cost Structure of Proxmox Storage

The cost implications are straightforward and significant. Adding storage capacity in an HCI cluster requires adding a full node: server chassis, CPU, RAM, drives, networking, and the licensing that goes with each component. Adding storage capacity in a totally disaggregated architecture requires adding an EBOD shelf or populating empty drive bays in an existing one.

The difference is not marginal — it is structural. An HCI node added to a Proxmox cluster to gain 120 TB of storage comes with a CPU that may not be needed, RAM that may go underutilized, and a full Proxmox VE subscription or license cost. An EBOD shelf providing the same 120 TB of capacity comes with drives and a chassis, and nothing else. The cost per usable terabyte in the EBOD model approaches the raw cost of the drives themselves, while the cost per usable terabyte in the HCI model includes the full node hardware and software stack that capacity expansion should not require.

Matching EBOD Configurations to Proxmox Workload Profiles

EBOD shelves are available in different drive densities and form factors, and the choice affects both the cost per terabyte and the I/O characteristics available to Proxmox storage. High-density EBOD configurations — 60-bay or 90-bay shelves using 3.5-inch drives — maximize capacity per rack unit and deliver the lowest cost per terabyte, making them the right choice for backup repositories, archive storage, and file server capacity. Lower-density configurations using 2.5-inch drives or all-NVMe shelves provide higher IOPS density per shelf, suited for database VM storage or latency-sensitive workloads.

Because the EBOD is a separate node, mixing EBOD types behind a single RAID controller is straightforward. A Proxmox cluster can have one EBOD shelf provisioned with high-capacity SATA drives for backup retention and a second shelf provisioned with NVMe drives for database VMs, both connected to the same RAID controller and presented to the same HCI controller as separate LUN pools. The architecture does not constrain the storage mix.

Capacity Expansion Without Compute Overprovisioning

The operational consequence of EBOD-based scaling is that storage expansion stops requiring compute procurement lead times. An HCI cluster approaching its capacity ceiling triggers a node purchase cycle: specification review, procurement approval, delivery lead time, racking and cabling, cluster expansion configuration, and data rebalancing. That process takes weeks in a well-run organization and longer in most.

An EBOD expansion requires procurement of drives and a shelf, with no specification review for compute components, no lead time for CPUs or memory, and no licensing reconciliation. The shelf is racked, cabled to the RAID controller, and the new capacity is available to the Proxmox cluster within the same maintenance window. For Proxmox VE environments where storage consumption grows in unpredictable bursts — backup retention expansion, new file server deployments, compliance-driven data retention — the difference between a weeks-long procurement cycle and a same-day expansion has a direct impact on whether storage becomes a constraint on business operations.

Why Proxmox VE Environments Benefit Most from Independent Resource Scaling

Proxmox VE’s architecture creates a specific combination of conditions that make totally disaggregated storage a better fit than HCI or standard disaggregated models. Three characteristics of Proxmox VE deployments drive this.

Workload Diversity Under a Single Proxmox VE Management Domain

Proxmox VE’s zero-license-cost model encourages consolidation. IT teams that previously split workloads across multiple hypervisor environments — one for production, one for dev/test, one for backup infrastructure — find it economically feasible to run all three on a single Proxmox cluster. That consolidation is cost-efficient on the compute side, but it creates storage requirements that are in conflict.

Production databases need low latency and high IOPS. Dev/test environments need capacity with moderate performance. Backup repositories need sequential throughput and retention capacity measured in tens or hundreds of terabytes. An HCI cluster serving all three will either overprovision compute to meet the database’s I/O requirements or underprovision storage to avoid buying compute capacity the dev/test and backup workloads do not need. Totally disaggregated architecture resolves the conflict by letting each workload class draw from the storage tier that fits its requirements without forcing a compromise on any workload type.

The Cost of Per-Node Licensing in Coupled Scaling Models

The economics of HCI scaling include not just hardware but software. Every node added to a Proxmox VE cluster — even one added primarily for storage capacity — carries its own CPU, memory, and storage controller overhead, and while Proxmox VE itself has no per-socket or per-core licensing cost, the hardware cost of compute components that are not needed for capacity is real and compounds with each expansion cycle.

Storage-only expansion through EBOD avoids this entirely. Adding 240 TB to an HCI cluster might require two HCI nodes — two chassis, two CPUs, two sets of RAM, two sets of networking, and the storage infrastructure licensing that accompanies each. Adding the same capacity through an EBOD shelf requires drives and a shelf, and nothing else, because the compute resources already exist on the HCI controller and RAID controller and do not need to be duplicated to support more disk bays.

The Operational Reality of Multi-Year Proxmox Storage Growth

Storage consumption in enterprise environments does not grow in a straight line. Compliance mandates add retention requirements that multiply storage consumption overnight. Backup policy changes extend retention windows. New application deployments bring datasets that the capacity plan did not forecast. In each case, the organization needs storage capacity delivered before the business constraint becomes a business problem.

HCI’s coupled scaling model makes fast capacity expansion expensive because it requires adding compute resources that the organization did not budget for. Totally disaggregated architecture makes fast capacity expansion economical because it requires only what the capacity shortage demands — drives and a shelf. For IT teams that manage Proxmox VE environments as cost centers rather than revenue generators, the ability to respond to storage growth without a budget variance approval cycle for compute hardware is a measurable operational advantage.

How the StoneFly Proxmox VE Appliance Delivers Totally Disaggregated Architecture

StoneFly built the totally disaggregated architecture into its Proxmox VE appliance to address the specific scaling problem that standard HCI and conventional disaggregated architectures leave unsolved: storage capacity should scale independently of storage processing, which should scale independently of compute.

The StoneFly Proxmox VE appliance ships as three integrated nodes. The HCI controller runs Proxmox VE with active-active RAID access to storage — both controller paths operational simultaneously, presenting the full aggregate I/O throughput to VM workloads. The dedicated hardware RAID controller provides RAID 0, 5, 6, 10, 30, 50, and 60 processing on its own CPU and cache, offloading every parity calculation, scrub, and rebuild from the HCI controller so VM performance remains consistent during storage maintenance events. The EBOD provides raw capacity in densities ranging from 12-bay to 60-bay shelves, with each shelf scaling capacity independently of both controllers.

The three nodes are validated together and ship as a single appliance, so the compatibility and configuration work that would otherwise fall to the IT team is eliminated at the factory. Proxmox VE is pre-installed on the HCI controller, the RAID controller is pre-configured with the EBOD topology, and the storage pool is presented as LUNs ready for Proxmox VM storage configuration.

For Proxmox VE environments where storage growth is expected but the rate and type of that growth are not yet known, the totally disaggregated architecture provides the operational flexibility to add capacity on the terms the workload dictates rather than on the terms the hardware architecture imposes. Contact StoneFly to discuss Totally Disaggregated Proxmox VE appliance sizing for your environment.

Conclusion: Proxmox VE Storage That Scales on Its Own Terms

Hyperconverged infrastructure couples compute and storage into a single scaling decision. Standard disaggregated architecture separates compute nodes from storage nodes but leaves RAID processing and capacity coupled inside the storage node. Totally disaggregated architecture goes the final step: HCI controller, RAID controller, and EBOD each scale independently, each on hardware optimized for its function, each without demanding that the other two change.

For Proxmox VE environments, this independence is not an architectural preference. It is the answer to a concrete problem that every growing Proxmox cluster encounters: the database VMs, file servers, and backup repositories on the same cluster do not consume resources at the same rate, and they should not be forced to share the same scaling path. Totally disaggregated architecture lets each workload type’s storage grow on its own trajectory, at its own cost structure, without requiring the IT team to budget for compute components that storage expansion should not require.

Contact StoneFly to evaluate a totally disaggregated Proxmox VE appliance configuration sized for your current and projected workload requirements.