[Question] Best practices for using manually created FlexVols as storage pools for ontap-nas-economy to achieve overcommitment

[XiuChen-Liu]

Hi Trident team and community,

I’m currently working on a Trident deployment (v25.06.0) on RKE2 and could use some advice on a specific storage strategy.

Background: We are aiming to achieve storage overcommitment at the Kubernetes level. Due to company policy, our storage team manages strict Quotas at the SVM level. However, we want to allow users to declare large numbers of PVCs (Qtrees) as long as the actual physical data usage does not exceed the SVM limit.

Issue Description:
Environment:

Trident Version: 25.06.0

Storage Driver: ontap-nas-economy

Backend Config:

• denyNewVolumePools: "true"
• storagePrefix: "(SVM NAEM)_VolumePools"

FlexVol created by manually:

• trident_qtree_pool_storagePrefix_(10 random characters)

Orchestrator: Kubernetes / RKE2

Our Proposed Strategy:

1. Manually create a large FlexVol (with no specific size limit or very large limit) on the ONTAP SVM.

2. Set denyNewVolumePools: "true" in the Trident backend to prevent Trident from automatically creating new FlexVols.

3. Force Trident to use this manually created FlexVol as the primary "Storage Pool" for all subsequent Qtree (PVC) provisioning.

Questions:

1. Discovery Logic: Besides matching the storagePrefix (e.g., trident_), what specific attributes (Export Policy, Snapshot Policy, Security Style) must the manual FlexVol have for Trident to recognize and "adopt" it as a valid pool?

2. Overcommitment: In an ontap-nas-economy setup, if the underlying FlexVol is thin-provisioned, will Trident allow provisioning of Qtrees whose aggregate "logical" size exceeds the FlexVol's size, provided the physical space is available?

3. Stability: Are there any known side effects when using denyNewVolumePools: "true" with a single, manually managed large FlexVol? Specifically regarding how Trident calculates "available" space for the backend.

We would greatly appreciate any insights or experiences sharing. Thank you!

[YvosOnTheHub]

Hi @XiuChen-Liu,

when working with the DNVP parameter, I usually recommend the following:

• create a NAS-ECO TBC without DNVP
• enable debug mode in that TBC with the parameter debugTraceFlag:{"api":true, "method":true}
• create your first PVC, which then will create a FlexVol
• since debug is enabled, you will see all the API calls (POST/PATCH) in the Trident logs, which will help you find the right set of commands you need to create a FlexVol on your own
• delete the PVC, disable debug mode, enable DNVP
• create a FlexVol
• next PVC you create, Trident should pick the right FlexVol for you

Next, even if you create a large FlexVol, when the first PVC is created, Trident will resize the FlexVol to match the first PVC size (+/- snapshot reserve).

Note that you can also set 2 extra TBC parameters in this context:

• limitVolumeSize: maximum size of a PVC/Qtree
• limitVolumePoolSize: maximum size of the FlexVol containing the PVC/Qtree

[XiuChen-Liu]

Hi @YvosOnTheHub,

Thanks a lot for the practical and detailed advice!

Regarding the FlexVol resizing, we confirmed this behavior in our testing.

• Question 1: Does this imply Trident relies on this resizing mechanism to sync its internal quota management with actual usage?

We will proceed with the debugTraceFlag to trace the API commands as suggested.

On a separate note, I have a follow-up regarding Overcommitment:

I’ve configured both the backend and StorageClass (SC) to use thin provisioning. However, it seems impossible to achieve overcommitment once a quota limit is set at the SVM level (regardless of using ontap-nas or ontap-nas-economy).

• Observation: Unlike standard NFS solutions, Trident seems to ensure there is sufficient space for the sum of all PVC declarations, rather than actual usage.
• Question 2: Is my understanding correct that the SVM-level quota acts as a "hard ceiling"? Does this force Trident to block PVC creation if the total declarations exceed the quota, effectively disabling overcommitment?

Thanks again for your help.