1. Proposed title of this feature request

Allow Configurable volumeBindingMode in LVM StorageClass (Enable Immediate or WaitForFirstConsumer)

2. What is the nature and description of the request?

The LVM Operator currently creates a StorageClass with the volumeBindingMode value hardcoded to WaitForFirstConsumer, with no supported mechanism to modify this behavior.

This feature request asks for:

• A configurable option within the LVM Operator or its custom resources (LVMCluster) that allows administrators to set the volumeBindingMode for the generated StorageClass to either:

• • WaitForFirstConsumer (current default), or

• • Immediate.

This would enable clusters to choose the appropriate binding strategy based on actual workload requirements, including scenarios where storage must be provisioned without an attached consumer.

3. Why does the customer need this? (List the business requirements here)

The customer operates OpenShift Virtualization on SNO and relies heavily on automated VM provisioning workflows. As part of VM creation, DataVolumes (DVs) are automatically generated.

When LVM is the backing storage, these DVs become stuck in PendingPrepopulation because WaitForFirstConsumer prevents provisioning until a consumer pod is scheduled—an event that does not occur during DV prepopulation, thereby blocking VM creation.

Although a workaround exists (creating a separate StorageClass with volumeBindingMode: Immediate), it introduces multiple issues:

• Additional operational complexity: Requires maintaining another StorageClass solely to bypass the LVMS limitation.

• Automation friction: Pipelines must selectively choose different StorageClasses depending on provisioning paths.

• Increased overhead and inconsistency: Splits the storage strategy across multiple StorageClasses, reducing operational uniformity.

• Reduced reliability and maintainability: Critical VM provisioning workflows depend on a workaround instead of supported functionality.

The customer needs official support for configurable volume binding in order to:

• Restore expected end-to-end VM provisioning behavior.

• Avoid parallel StorageClass configurations.

• Maintain a unified LVM-backed storage approach.

• Ensure predictable and automated virtualization operations at scale.

4. List any affected packages or components.

• LVM Storage (LVMS) Operator

• Potentially related CRDs (e.g., LVMCluster)