The PVC browser
Each claim row carries what you need to judge it at a glance:inUse is computed from live pod specs, and it exists for one decision: a ReadWriteOnce claim that is in use cannot be attached elsewhere — the attach-volume picker disables exactly those rows. An idle RWO claim is fair game; an RWX claim is shareable regardless.
Volume snapshots
The snapshot list is namespace-scoped the same way: each snapshot with its source claim, restore size, snapshot class, and areadyToUse flag — only ready snapshots can be cloned into new claims (the attach-volume flow’s “from snapshot” source, and the file-level recovery path recommended in VM storage).
On a supervisor where the snapshot machinery has never been installed the list is an empty array, not an error — the snapshot resource type simply does not exist there yet. An empty list therefore means either “no snapshots” or “no snapshot support”; the snapshot controller’s status (below) tells you which.
The snapshot controller
Volume snapshots need their own controller — the upstream sig-storage one, which every CSI driver is written against. It is a prerequisite of storage, and Celum installs it with whichever storage backend you install first, as asnapshot-controller HelmRelease in kube-system:
no matches for kind, which reads as a broken backend rather than a missing prerequisite. Installing storage therefore brings the controller first, then the classes.
The snapshot classes come from whichever backend created them:
None is annotated as the cluster default. A supervisor can run two backends side by side, and two of them claiming the default snapshot class resolve by apply order rather than by intent — so a
VolumeSnapshot that names no class is a claim on whichever installed last. Name the class explicitly.
The controller is required for VM snapshot and restore and for snapshot-sourced volumes. It is not what makes VM cloning fast — clone speed is the clone strategy of the storage class, and the fast path works without any snapshot infrastructure.
This moved. The controller used to be installed from the wizard’s Virtualization step, two steps after Storage creates snapshot classes — so on a fresh supervisor the classes were written against CRDs that did not exist yet and the CSI driver retried against a resource the API server does not serve. If you are reading an older runbook that sends you to Virtualization for this, it is out of date: the panel is gone and the step no longer waits on it.
PVC Pending — the checklist
Pending means the provisioner has not produced a volume. The causes sort cleanly by layer:
1
Get the provisioner's own words
Run a test PVC against the same class with the same access mode and volume mode — on failure it returns the claim events verbatim. This one step names the cause for most Pending claims.
2
Provisioner present?
An event that says waiting for a volume to be created by the external provisioner — repeating forever — means no provisioner is answering for that class. Classic cases: the NFS driver was removed and left an orphan class; a fresh Rook install whose CSI driver resources have not landed yet — Ceph can be perfectly healthy while nothing provisions.
3
Request satisfiable?
Check the class’s profile: ReadWriteMany on a class whose property sets only claim ReadWriteOnce, or Block mode on a file-backed class, pends forever with no retry that will ever succeed.
4
Backend healthy?
Ceph health for capacity and OSD warnings; the NFS test PVC for reachability; the FC failure table for port-list and multipath faults.
5
Binding mode, as the last look
A class with
WaitForFirstConsumer binding holds claims Pending by design until a pod schedules — a Pending claim with no consumer yet is not a fault on such a class.The exception that is a fault: a claim that will never get a consumer. A golden image in the Image Library is exactly that — nothing mounts it, it exists to be cloned — so on a WaitForFirstConsumer class its DataVolume sits at PendingPopulation with no importer pod and no error. Celum stamps cdi.kubevirt.io/storage.bind.immediate.requested on every image DataVolume for this reason; an import that predates the fix needs it on the PVC, because CDI reads the annotation when it creates the claim and annotating the DataVolume afterwards does nothing.Permissions
Related
VM storage & disks
Attaching claims and snapshots to VMs — and the four removal operations.
Classes & profiles
The capability data behind steps 1 and 3 of the checklist.
VM lifecycle
VM-level snapshot and restore — the snapshot controller’s main consumer.
Storage overview
The short triage version, and the backend catalogue.