Document snapshotClass volume policy parameter

Add documentation for the new snapshotClass parameter in the volume
policy snapshot action. Update the CSI docs to include volume policy
as a tier in the VolumeSnapshotClass selection priority, and add
Example 6 to resource-filtering.md showing multi-array usage.

Ref: #8807

Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>

site/content/docs/main/csi.md

@@ -86,8 +86,23 @@ This section documents some of the choices made during implementing the CSI snap
         ```
         Note: Please ensure all your annotations are in lowercase. And follow the following format: `velero.io/csi-volumesnapshot-class_<driver name> = <VolumeSnapshotClass Name>`
 
-    3. **Choosing VolumeSnapshotClass for a particular PVC:**
-    If you want to use a particular VolumeSnapshotClass for a particular PVC, you can add a annotation to the PVC to indicate which VolumeSnapshotClass to use. This overrides any annotation added to backup or schedule. For example, if you want to use the VolumeSnapshotClass `test-snapclass` for a particular PVC, you can create a PVC like this:
+    3. **Choosing VolumeSnapshotClass via Volume Policy:**
+    If you want to use a particular VolumeSnapshotClass based on conditions like StorageClass, you can specify the `snapshotClass` parameter in a volume policy's `snapshot` action. This is useful when multiple storage arrays share the same CSI driver but require different VolumeSnapshotClasses. For example:
+        ```yaml
+        version: v1
+        volumePolicies:
+        - conditions:
+            storageClass:
+            - nutanix-files
+          action:
+            type: snapshot
+            parameters:
+              snapshotClass: nutanix-files-snapclass
+        ```
+        This overrides backup/schedule annotations and VolumeSnapshotClass labels, but is overridden by PVC-level annotations. See the [resource filtering documentation](resource-filtering.md) for more volume policy examples.
+
+    4. **Choosing VolumeSnapshotClass for a particular PVC:**
+    If you want to use a particular VolumeSnapshotClass for a particular PVC, you can add a annotation to the PVC to indicate which VolumeSnapshotClass to use. This overrides any other method of selecting a VolumeSnapshotClass. For example, if you want to use the VolumeSnapshotClass `test-snapclass` for a particular PVC, you can create a PVC like this:
         ```yaml
         apiVersion: v1
         kind: PersistentVolumeClaim

site/content/docs/main/resource-filtering.md

@@ -617,6 +617,7 @@ a volume policy but for a particular volume included in the backup there are no
 in such a scenario the legacy approach will be used for backing up the particular volume. Considering everything, the recommendation would be to use only one
 of the approaches to backup volumes - volume policy approach or the opt-in/opt-out legacy approach, and not mix them for clarity.
 - Snapshot action can either be a native snapshot or a csi snapshot or csi snapshot datamover, as is the case with the current flow where velero itself makes the decision based on the backup CR's existing options.
+- The `snapshot` action supports an optional `snapshotClass` parameter that specifies which VolumeSnapshotClass to use for CSI snapshots. This is useful when multiple storage arrays share the same CSI driver but require different VolumeSnapshotClasses. When specified, this takes priority over backup annotations and VolumeSnapshotClass labels, but is overridden by PVC-level annotations. See the [CSI documentation](csi.md) for the full VolumeSnapshotClass selection priority order.
 - The `snapshot` action via Volume Policy has higher priority if there is a `snapshot` action matching for a particular volume, this volume would be backed up via snapshot irrespective of the value of `backup.Spec.SnapshotVolumes`.
 - If for a particular volume there is no `snapshot` matching action then the volume will be backed up via snapshot given that `backup.Spec.SnapshotVolumes` is not explicitly set to false.
 - Let's see some examples on how to use the volume policy feature for `fs-backup` and `snapshot` action purposes:
@@ -705,6 +706,29 @@ volumePolicies:
    - `fs-backup` on `Volume 1` because `Volume 1` satisfies the criteria for `fs-backup` action. 
    - Also, for Volume 2 as no matching action was found so legacy approach will be used as a fallback option for this volume (`fs-backup` operation will be done as `defaultVolumesToFSBackup: true` is specified by the user).
 
+***Example 6: User has two storage arrays using the same CSI driver and needs different VolumeSnapshotClasses for each***
+1. User specifies the volume policy as follows:
+```yaml
+version: v1
+volumePolicies:
+- conditions:
+    storageClass:
+    - array-1-sc
+  action:
+    type: snapshot
+    parameters:
+      snapshotClass: vsc-array-1
+- conditions:
+    storageClass:
+    - array-2-sc
+  action:
+    type: snapshot
+    parameters:
+      snapshotClass: vsc-array-2
+```
+2. User creates a backup using this volume policy
+3. The outcome would be that velero would use `vsc-array-1` VolumeSnapshotClass for volumes on storage class `array-1-sc` and `vsc-array-2` VolumeSnapshotClass for volumes on storage class `array-2-sc`, even though both storage classes use the same CSI driver.
+
 ### Global backup volume policies
 
 Resource policies (volume policies) are normally opt-in per backup via `--resource-policies-configmap`. An administrator can instead configure a cluster-wide baseline that applies to **every** backup by starting the Velero server with the `--global-backup-volume-policies-configmap` flag, pointing at a ConfigMap in the Velero install namespace: