WaitForFirstConsumer (StorageClass binding mode)
A PVC stays deliberately 'Pending' until a pod/VM actually uses it — not an error!
Every StorageClass has a volumeBindingMode: either 'Immediate' (the volume is created as soon as the PVC is created) or 'WaitForFirstConsumer' (the volume is created only when a pod wants to mount the PVC). LVM Storage uses WaitForFirstConsumer by default so the volume is created on the node where it is needed — important on multi-node clusters, less relevant on SNO but still active.
✓ ADVANTAGES
- Prevents volumes from landing on the wrong node (on multi-node clusters)
- Saves storage when PVCs are created but never used
⚠ LIMITATIONS
- PVC stays 'Pending' without a pod — looks like an error, but is normal
- virtctl image-upload and DataVolume clones stall without a consumer pod
- Sometimes requires an explicit consumer pod just to force binding
COMPARISON
WaitForFirstConsumer: Volume is created only when the first pod mounts the PVC. Default for local storage (LVM, hostpath).
📍 WHY IT MATTERS HERE
Explains why test PVCs in PRE-06 and clone operations in TC-STG-001 initially show 'Pending', and why ISO uploads in TC-VM-002 need a dedicated StorageClass with Immediate binding.