Files
home-network-k3s-impl/platform/longhorn/storageclasses.yaml
T
jakman85andClaude Opus 4.8 3586769460 feat(storage): CSI snapshots + smart-clone + migratable RWX for KubeVirt live-migration
Adds the VM/CDI storage tier approved by the PM (RWX for live-migration):

- platform/external-snapshotter (NEW, controllers pass): the cluster-singleton
  snapshot.storage.k8s.io control plane (CRDs + snapshot-controller in
  kube-system), pinned v8.2.0 (Kubernetes deps aligned to 1.31 since v8.1.0;
  this cluster is k3s v1.31.5). These CRDs were absent — only snapshots.longhorn.io
  and kubevirt.io snapshot CRDs existed.
- platform/longhorn/volumesnapshotclass.yaml (NEW, platform-config): the
  driver.longhorn.io VolumeSnapshotClass (type: snap, in-cluster).
- platform/kubevirt/cdi-storageprofiles.yaml (NEW, platform-config): StorageProfile
  longhorn -> cloneStrategy: snapshot; StorageProfile longhorn-vm -> snapshot clone
  + claimPropertySets RWX/Block. Non-degraded default virt class clears
  CDIDefaultStorageClassDegraded.
- platform/longhorn/storageclasses.yaml: NEW longhorn-vm StorageClass —
  migratable: "true" (Longhorn's KubeVirt-live-migration knob; RWX/Block-only on
  1.7.3), is-default-virt-class (NOT the k8s default; longhorn stays RWO default).
- platform/kubevirt/kubevirt-cr.yaml: comment only — LiveMigration is GA on v1.9
  (no feature gate); no cluster-wide evictionStrategy (would wedge RWO-disk drains);
  live-migration stays per-VM opt-in on a longhorn-vm disk.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-08-26 12:06:15 -05:00

104 lines
6.0 KiB
YAML

---
# Default replicated StorageClass — 3 replicas (ADR-0003, R-STATE-02). The durable home for
# app/config state, databases, and KubeVirt VM disks (via CDI). Destroying a pod/VM leaves the PVC
# and its data intact; rebuilding re-attaches it (R-STATE-01).
#
# This is the cluster's ONLY default StorageClass (the chart's built-in default is disabled in
# helmrelease.yaml), so PVCs without an explicit storageClassName land here.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete # dev: reclaim space when the PVC is deleted
volumeBindingMode: Immediate
parameters:
# 3 replicas across 3 nodes (topology-LOCKED). HARD node anti-affinity in helmrelease.yaml
# (replicaSoftAntiAffinity=false) guarantees these land on distinct nodes, so any single node
# loss keeps the volume available.
# HARDCODED, not ${LONGHORN_DEFAULT_REPLICA_COUNT}: StorageClass.parameters is map[string]string,
# but kustomize strips the quotes around a bare "${VAR}" placeholder, so Flux postBuild substitution
# yields an unquoted numeric (3) that server-side apply rejects (int, not string). A quoted numeric
# literal like "3"/"30" IS preserved by kustomize. The replica knob still drives the GLOBAL default
# via defaultSettings.defaultReplicaCount in helmrelease.yaml (a Helm int value, unaffected).
numberOfReplicas: "3"
staleReplicaTimeout: "30" # minutes before a down replica is considered stale and rebuilt
dataLocality: "disabled" # keep replicas spread for durability, not co-located with the pod
fsType: "ext4"
---
# KubeVirt VM-disk tier — RWX + migratable, for LIVE-MIGRATABLE VM disks (ADR-0005, docs/06).
#
# WHY a second Longhorn class: the default `longhorn` class is ReadWriteOnce (a Longhorn volume
# attaches to ONE node). KubeVirt live migration needs the SOURCE and TARGET virt-launcher pods to
# hold the SAME disk on TWO nodes for the migration window, which requires ReadWriteMany. Longhorn
# provides this via the StorageClass parameter `migratable: "true"`.
#
# migratable RWX on Longhorn 1.7.3 is BLOCK-mode only (verified against Longhorn 1.7 docs + the live
# cluster: longhornio/longhorn-manager:v1.7.3). Longhorn's ORDINARY RWX (migratable=false) is an
# NFS/share-manager-backed *Filesystem* export; the MIGRATABLE RWX path is different — it is a raw
# block device that Longhorn allows attached to two nodes ONLY during a live migration (concurrent
# writers are not permitted, so a mounted filesystem could be corrupted). Therefore:
# * StorageClass parameter migratable: "true"
# * PVC/DataVolume accessModes ReadWriteMany
# * PVC/DataVolume volumeMode Block (Filesystem is NOT supported with migratable)
# The volumeMode/accessMode live on the PVC/DataVolume; CDI stamps them automatically for disks on
# this class via the matching StorageProfile claimPropertySets (../kubevirt/cdi-storageprofiles.yaml).
#
# is-default-virt-class: CDI treats THIS as the default *virtualization* StorageClass (precedence over
# the k8s default `longhorn` for VM disks when storageClassName is omitted). Because it supports smart
# clone (snapshot) AND ReadWriteMany, its StorageProfile is non-degraded — which is what clears the
# CDIDefaultStorageClassDegraded alert. It is NOT the cluster (k8s) default: `longhorn` keeps the
# storageclass.kubernetes.io/is-default-class annotation, so ordinary PVCs still land on RWO longhorn.
# Exactly one SC may carry is-default-virt-class (else CDIMultipleDefaultVirtStorageClasses fires).
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: longhorn-vm
annotations:
storageclass.kubevirt.io/is-default-virt-class: "true"
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete # dev: reclaim space when the PVC is deleted
volumeBindingMode: Immediate
parameters:
# Same 3-replica durability as the default class (HARD node anti-affinity in helmrelease.yaml).
# Quoted string literals — see the numberOfReplicas note on the `longhorn` class above.
numberOfReplicas: "3"
staleReplicaTimeout: "30"
dataLocality: "disabled"
# THE knob that makes this class usable for KubeVirt live migration: mark volumes migratable so a
# RWX Longhorn volume can be attached to two nodes during a live migration. (Block-mode only.)
migratable: "true"
# No fsType: migratable RWX volumes are Block-mode (raw device); a filesystem is never laid down
# by Longhorn here — the guest owns the block device.
---
# Bulk media tier — large, NON-replicated data (Plex library, download staging, arr handoff).
# docs/04 / R-STATE-04: 3x replicating multi-TB media across 3 mini-PCs is impractical, so bulk
# media lives OUTSIDE the cluster and is consumed as an external NFS/SMB mount via this thin
# indirection. Services reference storageClassName: bulk; the concrete backing is filled in later
# WITHOUT touching service definitions.
#
# ⚠️ STUB — OQ-2 UNRESOLVED (human operator decision). The provisioner + parameters below are
# PLACEHOLDERS: they name the standard external NFS CSI driver but the server/share are REPLACE-ME.
# This class will NOT provision until OQ-2 is answered and the NFS CSI driver is installed. That is
# intentional — per docs/04 the bulk backing does not block the core platform.
#
# Plex's config/metadata DB is small and MUST stay on the 3-replica `longhorn` class regardless
# (docs/04, ADR-0003) — only the large media files use `bulk`.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: bulk
provisioner: nfs.csi.k8s.io # TODO(OQ-2): external NFS/SMB backing — driver + endpoint TBD
allowVolumeExpansion: true
reclaimPolicy: Retain # bulk media is precious/reacquirable — never auto-delete on PVC removal
volumeBindingMode: Immediate
parameters:
server: REPLACE-ME # TODO(OQ-2): NAS/NFS host holding the bulk media share
share: REPLACE-ME # TODO(OQ-2): exported path (e.g. /export/media)
mountOptions:
- nfsvers=4.1