SUSE Harvester Storage Architecture: Replacing Longhorn with Disaggregated NVMe/TCP

SUSE Harvester is an open-source hyperconverged infrastructure platform built on KubeVirt and a bundled Kubernetes distribution, positioned as an open-source VM platform for teams exiting VMware. Every Harvester cluster ships with Longhorn as its default storage engine: each VM disk becomes a Longhorn volume with its own replication engine and replica pods spread across cluster nodes. That default has been effectively the only option, until now.

SUSE published “Storage Virtualization Solutions: A Kubernetes-Native Approach” on July 13, 2026, introducing SUSE Certified Storage for Virtualization, described as a validated framework for integrating third-party storage with SUSE Virtualization (Harvester’s enterprise distribution). It is the first time SUSE has formally opened the storage layer under its VMware-exit platform to vendors beyond the bundled Longhorn engine.

This guide covers Harvester’s default storage architecture, the operational ceiling it hits at production VM density, what the certified storage framework changes, and how disaggregated NVMe/TCP (or NVMe/RoCE) fits as a replacement backend for VM disks.

Why Harvester’s Default Storage Hits a Ceiling at Scale

Harvester provisions every VM disk as a DataVolume backed by a standard Kubernetes PersistentVolumeClaim, the same abstraction any CSI driver can satisfy. By default, that PVC is served by Longhorn, which creates a dedicated volume engine process on the node running the VM and spawns replica pods on other nodes. Every write goes through the engine, which synchronously replicates it to each replica before acknowledging the guest operating system.

For small clusters or development environments, this design is genuinely convenient: no external storage system to deploy, a built-in UI, and snapshot and backup scheduling out of the box. The costs show up at production VM density, and they are the same costs documented for Longhorn generally, made sharper by VM-specific I/O patterns:

• User-space replication overhead. Longhorn’s engine runs in user space rather than the kernel block-I/O path, adding CPU cost and latency to every write. A VM’s guest filesystem journal, and any database running inside that VM, both depend on fsync latency that this overhead directly inflates.
• Full-volume replica rebuild. When a node fails, Longhorn rebuilds the lost replica by copying the entire volume’s data over the network to a healthy node. For a 500 GB VM disk, that rebuild window can run from minutes to hours, during which the volume runs with reduced redundancy and the rebuild traffic competes with other VMs’ I/O on the same network.
• Storage capacity coupled to compute nodes. Because Longhorn is hyperconverged, usable capacity is bounded by what is physically attached to the nodes running VMs. Adding storage capacity means adding or resizing compute nodes, even when the actual bottleneck is disk space rather than CPU or memory.

At small scale, these are manageable trade-offs. At the density Harvester is being asked to support as a VMware-exit destination, hundreds of VMs across a handful of nodes, they become the operational bottleneck that determines whether the platform holds up under production load.

SUSE’s Certified Storage for Virtualization: A New Door for Third-Party CSI

The July 13 SUSE post is a meaningful shift in framing. Previous Harvester storage guidance treated Longhorn as the only supported path; SUSE’s Certified Storage for Virtualization framework instead validates external storage vendors to serve as the primary StorageClass provisioner for VM disks, not merely as a bolt-on secondary tier for non-VM workloads.

Mechanically, this changes less than it sounds like at first. Harvester’s VM disk provisioning already runs through the standard Kubernetes CSI interface: a DataVolume results in a PVC, and any CSI driver that implements the CreateVolume/ControllerPublishVolume interface can satisfy it. SUSE’s certification does not require a new integration surface; it validates that a given third-party driver meets the operational bar (snapshot support, volume expansion, multi-attach behavior for live migration) needed to safely replace Longhorn as the default.

What actually changes is buyer confidence and competitive positioning. At least one storage vendor already holds a certified integration with SUSE Virtualization and has published partnership content naming the relationship directly, meaning the storage layer under Harvester is no longer assumed to be Longhorn-only in the market. Teams evaluating Harvester for a VMware exit now have an explicit, SUSE-endorsed signal that swapping the storage backend is a supported, not experimental, decision.

Evaluating Harvester as a VMware exit destination and weighing storage options? Simplyblock’s disaggregated NVMe/TCP storage integrates through the same CSI path Harvester already uses, replacing Longhorn’s per-node replica engine with a pooled backend. Talk to a storage architect

Disaggregated NVMe/TCP Architecture for Harvester VM Storage

Simplyblock’s storage layer runs disaggregated from Harvester’s compute nodes: a pool of NVMe capacity, thin-provisioned and QoS-managed per volume, exposed to VM disks through the CSI driver exactly where Longhorn sits today. The architectural difference from Longhorn’s model is what happens at each stage of the VM disk lifecycle.

Table 1: Harvester default storage versus disaggregated NVMe/TCP for VM disk workloads.

The node-failure row is the one that matters most for production HCI density. A Longhorn replica rebuild after node failure is proportional to volume size and competes with production traffic on the same fabric. With a disaggregated NVMe/TCP backend, the VM disk’s data was never actually on the failed node’s local storage; it reattaches to a replacement node in seconds because the pool, not the compute node, holds the data.

Compression and replication factor are set at the StorageClass level, the same way any Harvester DataVolume provisioner is configured:

1
apiVersion: storage.k8s.io/v1
2
kind: StorageClass
3
metadata:
4
  name: harvester-vm-nvme
5
provisioner: csi.simplyblock.io
6
parameters:
7
  replication: "2"
8
  compression: "false"
9
  qos_iops_per_gb: "40"
10
reclaimPolicy: Retain
11
volumeBindingMode: WaitForFirstConsumer
12
allowVolumeExpansion: true

compression is generally left off for VM disk images, since guest filesystems and database engines running inside the VM frequently apply their own compression, and a second pass adds CPU cost without a meaningful capacity gain.

Live Migration and Multi-Tenant VM Density

Harvester’s live migration, inherited from KubeVirt, follows the same pattern covered for OpenShift Virtualization: the guest OS keeps running while memory state copies to the destination node, and the VM’s disk must remain accessible from both nodes for the duration of the migration window. That requirement is independent of which CSI driver provisions the disk, but it constrains what that driver can be. A storage backend that pins a volume to the node holding its physical disk, as Longhorn’s hyperconverged model effectively does for the replica currently serving reads, adds friction to the migration path that a disaggregated backend does not have, since the volume is never physically attached to a single compute node in the first place.

The same disaggregation matters for VM density. Because disaggregated storage capacity scales independently of Harvester’s compute node count, adding more VMs to a cluster does not require also adding local disk to every node just to keep pace with storage demand. This mirrors the pattern already covered for KubeVirt persistent storage: the storage layer that supports comfortable VM density on one virtualization platform tends to support it the same way on another, because the underlying constraint (compute and storage capacity scaling together versus independently) is a property of the storage architecture, not the specific hypervisor.

Table 2: Live migration and density considerations by storage architecture on Harvester.

For teams that have already read the comparisons between Harvester and other virtualization platforms, the storage layer is the piece those comparisons generally do not cover in depth. Harvester’s virtualization model competes well on its own terms; whether its default storage keeps pace with a production VMware-exit migration depends on the same replica-rebuild and capacity-coupling trade-offs that apply to Longhorn everywhere else it runs.

Questions and Answers

Does Harvester require Longhorn, or can it use a different storage backend?

Harvester ships with Longhorn as the default and only pre-configured storage engine, but VM disks provision through the standard Kubernetes CSI interface underneath. SUSE’s Certified Storage for Virtualization framework formally validates third-party CSI drivers as a supported replacement for Longhorn, not just an experimental option, which is new as of the July 2026 announcement.

What happens when a Harvester node fails under Longhorn’s default storage?

Longhorn rebuilds the lost replica by copying the volume’s entire current data over the network to a healthy node, a process proportional to volume size that can take minutes to hours for large VM disks. During that window, the volume runs at reduced redundancy and the rebuild traffic competes with other VMs’ I/O on the same network fabric.

How does disaggregated NVMe/TCP change VM disk recovery on Harvester node failure?

With a disaggregated NVMe/TCP backend, VM disk data lives in a pooled backend rather than on the failed node’s local storage, so a replacement pod reattaches the existing volume to any node in the pool within seconds. There is no full-volume copy to wait for, because the data was never tied to the compute node that failed.

Does swapping Harvester’s storage backend affect VM live migration?

No, live migration itself is a KubeVirt capability independent of the CSI driver underneath. What changes is how much friction the storage layer adds: a hyperconverged backend where the active replica is physically attached to one node adds reattach overhead during migration that a disaggregated backend, which is never pinned to a single compute node, does not have.

Is simplyblock certified under SUSE’s Certified Storage for Virtualization framework?

SUSE’s framework is newly announced as of July 2026, and simplyblock integrates through the same standard CSI interface Harvester already uses for VM disk provisioning today. Teams evaluating Harvester for a VMware exit can talk to a storage architect to plan a NVMe/TCP integration path for their specific deployment timeline.

When does Harvester’s default Longhorn storage remain a reasonable choice?

Longhorn works well for smaller Harvester clusters, development environments, and deployments where ease of setup and a built-in UI matter more than replica-rebuild time or independent capacity scaling. Production VMware-exit migrations running hundreds of VMs with maintenance-window live migration and predictable node-failure recovery are the point where a disaggregated backend becomes the more relevant architecture decision.