-
Bug
-
Resolution: Unresolved
-
Major
-
2.10.0, 2.11.0
-
Quality / Stability / Reliability
-
False
-
-
True
-
-
Problem
The copy offload code in ontap.go cannot resolve LUNs from PVCs created with the ontap-san-economy storage class due to incorrect LUN path construction.
Steps to Reproduce# Create a PVC using the ontap-san-economy storage class on a NetApp ONTAP backend
- Attempt to use copy offload with this PVC as a target
- The ResolvePVToLUN function in ontap.go:96-113 will fail to locate the LUN
Expected: The LUN should be resolved correctly and copy offload should proceed
Actual: The LunGetByName API call fails because it's looking for the wrong LUN path
Root Cause
In ontap.go:102, the ResolvePVToLUN function constructs the LUN path as:
l, err := c.api.LunGetByName\(context.Background\(\), fmt.Sprintf\("/vol/%s/lun0", internalName\)\)
This assumes:
* Each PVC has a dedicated FlexVol
* The LUN is always named lun0
Why ontap-san-economy is Different
ontap-san (works):
* Creates a dedicated FlexVol per PVC
* LUN path: {{/vol/
* PV has internalName attribute only
* Example: /vol/copy_offload_cluster_pvc_6fa1af01_7204_4f09_9f8f_25b8a013273f/lun0
ontap-san-economy (fails):
* Uses shared FlexVol pools for cost efficiency (e.g., trident_lun_pool_copy_offload_cluster_ASVRVZBSPB)
* Multiple LUNs per FlexVol (qtree-based)
* LUN path: /vol/{pool\_name}/lun/{lun\_name}
* PV has both internalName AND internalID attributes
* The internalID contains the actual full path:
/svm/vserver-ecosystem-mtv/flexvol/trident_lun_pool_copy_offload_cluster_ASVRVZBSPB/lun/copy_offload_cluster_pvc_5c9d270a_11c8_4c36_9f12_f0d5f69870cf
h2. Solution
The code needs to:
1. Check if internalID attribute exists (indicates economy storage class)
2. Parse internalID to extract the correct LUN path (everything after /flexvol/ becomes /vol/...)
3. Fall back to current {{/vol/{internalName}
/lun0}} logic for non-economy storage classes
Example fix:
func \(c \*NetappClonner\) ResolvePVToLUN\(pv populator.PersistentVolume\) \(populator.LUN, error\) {
var lunPath string
// Check for economy storage class (has internalID)
if internalID, ok := pv.VolumeAttributes["internalID"]; ok {
// Parse: /svm/
/flexvol/
{vol}/lun/{lun} -> /vol/{vol}/lun/
{lun} lunPath = parseInternalIDToLunPath(internalID)
} else {
// Standard storage class
internalName, ok := pv.VolumeAttributes["internalName"]
if !ok {
return populator.LUN{}, fmt.Errorf("neither internalID nor internalName found")
}
lunPath = fmt.Sprintf("/vol/%s/lun0", internalName)
}
l, err := c.api.LunGetByName(context.Background(), lunPath)
// ... rest of function
}
Impact
Copy offload currently does not work with ontap-san-economy storage class, which:
* Limits storage efficiency options for users
* Forces users to use ontap-san which is less cost-effective (dedicated FlexVol per PVC)
* Prevents adoption of recommended NetApp best practices for multi-tenant environments
