14.1 Disks and node-disk-manager¶

node-disk-manager (NDM) discovers block devices on each host and represents them as BlockDevice objects. Adding a disk to Harvester means:

1. NDM detects it.
2. You (or auto-disk-provision-paths, e.g. /dev/nvme*n1) mark it for provisioning.
3. NDM formats it (ext4 for Longhorn V1) or hands the raw block device to Longhorn V2 / LVM.
4. Longhorn adds it as a disk on that node with optional disk tags (e.g. nvme, ssd).

kubectl -n longhorn-system get blockdevices.harvesterhci.io
kubectl -n longhorn-system get nodes.longhorn.io -o yaml   # disks per node

14.2 StorageClasses¶

• harvester-longhorn — the default; replicas 3, migratable.
• Image StorageClasses — each VM image has an associated StorageClass (longhorn-<image-name>) that uses the image as a backing image, so all VMs from that image share the base data and only store deltas.
• Custom StorageClasses — define replica counts, disk/node selectors, data locality, V2 engine, encryption:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nvme-2rep
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "2"
  staleReplicaTimeout: "30"
  diskSelector: "nvme"
  dataLocality: "best-effort"
  migratable: "true"

migratable: "true" matters: live migration requires volumes that can be attached to two nodes briefly during handover. Harvester's default and image StorageClasses set this.

14.3 Third-party / external storage¶

Harvester supports external CSI drivers for VM disks (data volumes and, in recent versions, boot volumes), such as NetApp Trident, Pure, Dell, Ceph RBD/Rook, or others meeting the requirements:

• CSI driver must support block volume mode and ideally RWX block (for live migration).
• Snapshot support (VolumeSnapshotClass) for VM snapshot/backup features.
• Configure the CSI driver → Harvester mapping in the csi-driver-config setting.

This is the path for organizations with existing SAN/NAS investment.

14.4 Local storage add-on (LVM)¶

The harvester-csi-driver-lvm add-on exposes local disks as LVM-backed volumes:

• Near-native performance (no network replication).
• No HA — data lives on one node; VMs pinned to that node; no live migration.
• Ideal for databases with application-level replication, scratch, caches, CI runners.

14.5 Longhorn V2 in Harvester¶

• Requires dedicated block devices for V2, hugepages, and CPU reserved for SPDK.
• Enabled via Harvester/Longhorn settings and dedicated StorageClasses.
• Read the version's limitations carefully (backing-image/images handling, snapshot/backup feature parity, migration support) — the V2 feature set has been expanding release by release.

14.6 Encryption¶

Volume encryption uses LUKS via Longhorn with a Kubernetes Secret holding the passphrase, referenced from an encrypted StorageClass. Recent releases support both data and boot volume encryption. Losing the secret = losing the data; back the secret up separately (e.g. into your vault/pass store).

14.7 Overcommit¶

Harvester setting overcommit-config (defaults vary by version; historically CPU 1600%, memory 150%, storage 200%):

{"cpu":1600,"memory":150,"storage":200}

• CPU overcommit is generally safe for typical server workloads.
• Memory overcommit sets VM requests below limits; if VMs actually use their memory, the node can OOM and kill virt-launcher pods (= hard VM crash). Many operators set memory to 100% for production.
• Storage overcommit applies to Longhorn scheduling; watch real disk usage.

14.8 Memory overhead¶

KubeVirt adds per-VM overhead (QEMU process, page tables, virtio buffers). Harvester's reserved memory per VM (and settings like additional-guest-memory-overhead-ratio in newer releases) control how much headroom is subtracted from the guest-visible memory or added to the pod. If guests OOM-kill or show less memory than expected, this is where to look.

← Harvester networking in depth · Index · Virtual machines: images, templates, cloud-init →