# external-snapshotter (CSI snapshot control plane) Installs the cluster-singleton [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter): - the `snapshot.storage.k8s.io` CRDs — `VolumeSnapshot`, `VolumeSnapshotContent`, `VolumeSnapshotClass` (v1, GA); - the **snapshot-controller** Deployment (into `kube-system`, the upstream default) that reconciles those objects against any CSI driver's `CreateSnapshot`/`DeleteSnapshot`. Neither k3s nor the Longhorn chart ships this. It is a prerequisite for: 1. **`VolumeSnapshotClass` (driver.longhorn.io)** — see `../longhorn/volumesnapshotclass.yaml` (applied by `platform-config`). 2. **CDI snapshot smart-clone** — the CDI `StorageProfile`s set `cloneStrategy: snapshot` (see `../kubevirt/cdi-storageprofiles.yaml`); CDI clones VM disks by taking a CSI `VolumeSnapshot` instead of a slow host-assisted byte copy. 3. Clearing the **`CDIDefaultStorageClassDegraded`** alert — a default virtualization StorageClass must support *both* smart-clone *and* ReadWriteMany. ## Wiring - **Pass:** `platform` (controllers). Registers the CRDs. - The `VolumeSnapshotClass` CR that consumes the CRDs lives in the `platform-config` pass (`dependsOn: platform`), per the controllers/configs split. - The CDI `StorageProfile`s live one pass further out, in `platform-config-cdi` (`dependsOn: platform-config`) — `storageprofiles.cdi.kubevirt.io` is created by cdi-operator only after it reconciles the `CDI` CR, so they cannot share a pass with it. See `clusters/base/platform-config-cdi.yaml`. ## Version Pinned to **v8.2.0** (Renovate-maintained). The v8.x line aligned to Kubernetes 1.31 at v8.1.0; this cluster is now k3s v1.36.4, so the pin should be **re-checked for 1.36** (a newer external-snapshotter line may be the version-matched choice) — do not treat v8.2.0 as verified against 1.36 yet. The snapshot-controller image is re-pinned to the same tag via the kustomization `images` transformer (the upstream setup manifest lags on the image tag).