Skip to main content
Claims and snapshots are browsed per namespace — the browser backs the VM detail page’s attach-volume flow, where an existing claim or a snapshot becomes a disk on a VM, and it is the quickest read on “what storage does this namespace actually hold”.

​
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 a readyToUse 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 — it is not part of any storage backend. Celum installs it from the wizard’s Virtualization step (its main consumer is VM snapshot/restore), as a snapshot-controller HelmRelease in kube-system:
The install asks for a source StorageClass and derives the rest: it resolves that class’s CSI driver and creates a matching VolumeSnapshotClass (default name ceph-block-snap), optionally marked as the default so snapshots that name no class still work. Leave the source class empty and only the controller installs — snapshot classes can be added later. Volume-group snapshot support is enabled by default.
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.

​
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.

​
Permissions

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 three-backend model.