Install Trident on a Red Hat OpenShift cluster and create storage objects

07/13/2026 Contributors

Install Trident with the Red Hat Certified Trident Operator and create storage objects for ONTAP and Amazon FSx for NetApp ONTAP to enable dynamic volume provisioning for containers and VMs. Prepare worker nodes for block access when required.

Before you begin

Complete the procedures on this page before you install OpenShift Virtualization. OpenShift Virtualization requires a default Trident-backed StorageClass and VolumeSnapshotClass to create golden images for VM templates.
If you already installed OpenShift Virtualization before configuring Trident, delete any golden images created with a different storage class. After you set Trident as the default, OpenShift Virtualization recreates the golden images using Trident storage.
```
oc delete dv,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
```

Step 1: Install Trident

The Red Hat Certified Trident Operator is supported by NetApp for OpenShift on-premises, in public clouds, and in managed services such as ROSA. Starting with Trident 25.02, the operator can also prepare worker nodes for iSCSI when you use Amazon FSx for NetApp ONTAP and plan to run OpenShift Virtualization VM workloads.

For other installation options, see the Trident documentation.

Steps

In OperatorHub, select Certified NetApp Trident.

Show example
On the Install page, keep the latest version and select Install.

Show example
After the operator installs, select View operator and create an instance of the Trident Orchestrator.

If you want to prepare worker nodes for iSCSI, switch to YAML view and add iscsi to nodePrep.

Show example
Confirm that all Trident pods are running in the cluster.

Show example
If you enabled iSCSI node preparation, log in to worker nodes and verify that iscsid and multipathd are active and that multipath.conf has entries.

Show example

Show example

Show example

Video Demonstration

The following video shows a demonstration of installing Trident using the Red Hat Certified Trident Operator.

Installing Trident 25.02.1 using the certified Trident Operator in OpenShift

Step 2: Prepare storage backend and StorageClass configuration files for your environment

Create TridentBackendConfig and StorageClass definitions for your environment. You can configure multiple storage protocols within your environment. Create YAML files for each protocol you want to use, and replace the placeholder values with your specific configuration details.

Complete either the on-premises or ROSA section below based on your environment, then proceed to Step 3.

On-premises OpenShift clusters

Create YAML files for each protocol you want to configure. You can configure one or more of the following protocols: NAS for NFS-based file storage, iSCSI for iSCSI block storage, NVMe/TCP for high-performance NVMe over TCP block storage, or FC for Fibre Channel block storage.

Create a TridentBackendConfig and StorageClass for each protocol. The backend configuration includes credentials stored in a Kubernetes Secret.

Essential guidelines for backend configuration basic options

The backend configuration files reference your ONTAP SVM and management LIF. +
You can use username and password to authenticate with ONTAP. It can be cluster admin or vserver admin username and password. +
You can also use a client certificate for authentication with ONTAP. For details about how to generate the client certificate, private key and CA certificate, please review Trident documentation here.

Essential guidelines for backend configuration options for NAS economy driver

The following parameters can be included for NAS economy driver configuration:

qtreesPerFlexvol The value must be in range 50-300, default value is 200. +
limitVolumePoolSize The value is the maximum FlexVol size that you request when using qtrees in ontap-nas-economy backend. No default value is set, and this parameter is not enforced by default. If you set this parameter, the Trident operator creates a new FlexVol when the current FlexVol reaches the specified size. This parameter can help you control capacity utilization in your cluster by restricting the size of FlexVols used for provisioning PVs. +
denyNewVolumePools This parameter restricts ontap-nas-economy backends from creating new FlexVol volumes to contain their qtrees. Only preexisting Flexvols are used for provisioning new PVs.

Essential guidelines for backend configuration options for SAN driver

The following parameters can be included for SAN driver configuration:

limitVolumeSize The value is the maximum volume size that you request when using SAN backend. No default value is set, and this parameter is not enforced by default. If you set this parameter, the Trident operator fails provisioning if requested volume size is above this value. You can use this parameter to restrict the maximum size of volumes it manages for LUNs. +
lunsPerFlexvol Maximum LUNs per Flexvol, must be in range [50, 200], default is 100. If you set this parameter, the Trident operator creates a new FlexVol when the current FlexVol reaches the specified number of LUNs. This parameter can help you control capacity utilization in your cluster by restricting the number of LUNs per FlexVol used for provisioning PVs.

Essential guidelines for backend configuration options for SAN economy driver

The following parameters can be included for SAN economy driver configuration:

limitVolumePoolSize The value is the maximum FlexVol size that you request when using SAN economy backend. No default value is set, and this parameter is not enforced by default. If you set this parameter, the Trident operator limits the maximum flexvol size that can be created for creating LUNs in the flexvol. This parameter can help you control capacity utilization in your cluster by restricting the size of FlexVols used for provisioning PVs. +
denyNewVolumePools This parameter restricts SAN economy backends from creating new FlexVol volumes to contain their LUNs. Only preexisting Flexvols are used for provisioning new PVs.

Essential guidelines for backend configuration options for provisioning volumes

In the sample yaml files provided for each protocol, if storagePrefix is not provided, the default prefix “trident” is used. When using ontap-nas-economy and a storagePrefix that is 24 or more characters, the qtrees will not have the storage prefix embedded, though it will be in the volume name.

When you create a volume in ONTAP directly from system manager or from CLI, without providing values for all the optional parameters, there are some default values set automatically during provisioning of a volume as shown below.

Create volume in ONTAP

default values for volume parameters

Here is an example of a volume created using Trident backend configuration. It does not have any options set explicitly in the defaults section except the name template.

oc describe tbc -n trident tbc-nas
### output truncated for brevity
Spec:
  Backend Name:  tbc-nas
  Credentials:
    Name:  tbc-nas-secret
  Defaults: # There are no defaults set except for the volume name template.
    Name Template:      {{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}
  Management LIF:       10.192.102.50
  Storage Driver Name:  ontap-nas
  Storage Prefix:       testautomation
  Svm:                  oc-test-automation

When the volume is created using this backend configuration, the options that are not set in the backend configuration file are set to the default values as shown below.

Volume created using Trident backend configuration

However, when you set values in the default section in the trident backend configuration, you can create volumes that can have specific values for those parameters.
In the following example, snapshotPolicy is set to default policy (it is none if you do not set anything explicitly) and snapshotDir is set to true in the default section of the backend configuration yaml. With these settings, you can see that the backend volume gets those values. (snapdir-access is true and snapshot-policy is default)

default section with explicit values

explicitly set snapshotDir and snapshotPolicy values in backend configuration

explicitly set snapshotDir and snapshotPolicy values in volume

For all other additional parameters, please review Trident documentation:

NAS

Create a TridentBackendConfig and StorageClass for ONTAP NAS to enable NFS-based persistent storage provisioning. The backend configuration includes credentials stored in a Kubernetes Secret and references your ONTAP SVM and management LIF.

Sample backend secret and backend configuration file using username and password authentication (save as tbc-nas.yaml):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-secret

Sample backend secret and backend configuration file using client certificate authentication (save as tbc-nas.yaml):

# tbc-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: ontap-nas-secret
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas
  svm: zoneb #<replace with your SVM name>
  storagePrefix: testzoneb #<replace with your prefix>
  credentials:
    name: ontap-nas-secret
  clientCertificate: <client certificate>

StorageClass definition (save as sc-nas.yaml):

# sc-nas.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true

NAS economy

Create a TridentBackendConfig and StorageClass for ONTAP NAS economy driver to enable NFS-based persistent storage provisioning using qtrees. The backend configuration includes credentials stored in a Kubernetes Secret and references your ONTAP SVM and management LIF.

Sample backend secret and backend configuration file using username and password authentication (save as tbc-nas-economy.yaml):

# tbc-nas-economy.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-nas-economy-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-nas-economy
spec:
  version: 1
  storageDriverName: ontap-nas-economy
  managementLIF: <ONTAP management LIF>
  backendName: tbc-nas-eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-nas-economy-secret

StorageClass definition (save as sc-nas-economy.yaml):

# sc-nas-economy.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nas-economy
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas-economy"
  media: "ssd"
  provisioningType: "thin"
  snapshots: "true"
allowVolumeExpansion: true

Please see the Essential guidelines for backend configuration options for NAS economy driver section above for details about additional parameters that can be included in the backend configuration file for ontap-nas-economy driver.

iSCSI SAN

Create a TridentBackendConfig and StorageClass for ONTAP SAN with iSCSI to enable iSCSI-based block storage provisioning. The backend configuration uses the ontap-san driver and includes credentials stored in a Kubernetes Secret. The sanType parameter defaults to iSCSI protocol if omitted.

Backend secret and backend configuration file using username password authentication (save as tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret

Backend secret and backend configuration file using client certificate authentication (save as tbc-iscsi.yaml):

# tbc-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-iscsi-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: ontap-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <management LIF>
  backendName: ontap-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-iscsi-secret
  clientCertificate: <client certificate>

StorageClass definition (save as sc-iscsi.yaml):

# sc-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

NVMe/TCP SAN

Create a TridentBackendConfig and StorageClass for ONTAP SAN with NVMe over TCP to enable high-performance block storage provisioning. The backend configuration uses the ontap-san driver optimized for NVMe/TCP transport and includes credentials stored in a Kubernetes Secret.

Backend secret and backend configuration file using username password authentication (save as tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret

Backend secret and backend configuration file using client certificate authentication (save as tbc-nvme.yaml):

# tbc-nvme.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-ontap-nvme-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-tbc-ontap-nvme
spec:
  version: 1
  storageDriverName: ontap-san
  sanType: nvme
  managementLIF: <ONTAP management LIF>
  backendName: backend-tbc-ontap-nvme
  svm: <SVM name>
  credentials:
    name: backend-tbc-ontap-nvme-secret
  clientCertificate: <client certificate>

StorageClass definition (save as sc-nvme.yaml):

# sc-nvme.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-nvme
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

If you plan to use ReadWriteMany (RWX) volumes with the NVMe protocol, a single RWX NVMe volume cannot be mounted by more than 64 nodes in a Kubernetes cluster.
For more information about this limitation and information about the Super-subsystem model introduced in Trident 26.02 and the Per-volume subsystem model prior to Trident 26.02, see the Trident documentation: https://docs.netapp.com/us-en/trident/trident-use/ontap-san-prep.html#nvme-tcp-considerations.

FC SAN

Create a TridentBackendConfig and StorageClass for ONTAP SAN with Fibre Channel to enable FC-based block storage provisioning. The backend configuration uses the ontap-san driver with the FCP protocol specified and includes credentials stored in a Kubernetes Secret.

Use the username/password authentication method or client certificate authentication method to authenticate with ONTAP. For details about how to generate the client certificate, private key and CA certificate, please review Trident documentation here. Examples for both methods are provided below.

Show example

Backend secret and backend configuration file using ONTAP username and password authentication (save as tbc-fc.yaml):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  username: <cluster admin username>
  password: <cluster admin password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret

Backend secret and backend configuration file using client certificate authentication
(save as tbc-fc.yaml):

# tbc-fc.yaml
apiVersion: v1
kind: Secret
metadata:
  name: tbc-fc-secret
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-fc
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <ONTAP management LIF>
  backendName: tbc-fc
  svm: openshift-fc #<replace with your SVM name>
  sanType: fcp
  storagePrefix: demofc #<replace with your prefix>
  defaults:
    nameTemplate: "{{ .config.StoragePrefix }}_{{ .volume.Namespace }}_{{ .volume.RequestName }}"
  credentials:
    name: tbc-fc-secret
  clientCertificate: <client certificate>

# sc-fc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fc
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

iSCSI SAN economy

Create a TridentBackendConfig and StorageClass for ONTAP SAN economy with iSCSI to enable iSCSI-based block storage provisioning. The backend configuration uses the ontap-san-economy driver with the iSCSI protocol and includes credentials stored in a Kubernetes Secret.

Backend secret and backend configuration file using client certificate authentication (save as tbc-san-eco.yaml):

# tbc-san-eco.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: ontap-san-cert-auth
  namespace: trident
type: Opaque
stringData:
  clientPrivateKey: <client private key>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: tbc-san-eco-cert
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san-economy
  managementLIF: "<ONTAP management LIF>"
  backendName: tbc_san_eco
  svm: <replace with your SVM name>
  storagePrefix: <replace with your prefix>
  credentials:
    name: ontap-san-cert-auth
  clientCertificate: <client certificate>

# sc-san-eco.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-san-eco
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san-economy"
  provisioningType: "thin"
  snapshots: "true"

Review the Trident documentation for additional samples of yaml files, and information on access modes and volume modes supported by SAN drivers and NAS drivers.

ROSA clusters with Amazon FSx for NetApp ONTAP

Create YAML files for each protocol you want to configure. You can configure one or both of the following protocols: NAS for NFS-based file storage or iSCSI for block storage.

NAS

Create a TridentBackendConfig and StorageClass for Amazon FSx for NetApp ONTAP with ONTAP NAS to enable NFS-based persistent storage provisioning on ROSA clusters. The backend configuration uses Amazon FSx for NetApp ONTAP DNS names for management and data LIFs, and includes credentials stored in a Kubernetes Secret in the trident namespace.

Backend secret and backend configuration file (save as tbc-fsx-nas.yaml):

# tbc-fsx-nas.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-fsx-ontap-nas-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: backend-fsx-ontap-nas
spec:
  version: 1
  backendName: fsx-ontap
  storageDriverName: ontap-nas
  managementLIF: <Management DNS name>
  dataLIF: <NFS DNS name>
  svm: <SVM NAME>
  credentials:
    name: backend-fsx-ontap-nas-secret

StorageClass definition (save as sc-fsx-nas.yaml):

# sc-fsx-nas.yaml (storage class name is trident-csi)
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: trident-csi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-nas"
  fsType: "ext4"
allowVolumeExpansion: true
reclaimPolicy: Retain

iSCSI

Create a TridentBackendConfig and StorageClass for Amazon FSx for NetApp ONTAP with ONTAP SAN to enable iSCSI-based block storage provisioning on ROSA clusters. The backend configuration uses the ontap-san driver and includes credentials stored in a Kubernetes Secret. Ensure that worker nodes are prepared for iSCSI access.

Backend secret and backend configuration file (save as tbc-fsx-iscsi.yaml):

# tbc-fsx-iscsi.yaml
apiVersion: v1
kind: Secret
metadata:
  name: backend-tbc-fsx-iscsi-secret
type: Opaque
stringData:
  username: <FSx for ONTAP, for example fsxadmin>
  password: <FSx for ONTAP password>
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: fsx-iscsi
spec:
  version: 1
  storageDriverName: ontap-san
  managementLIF: <Management DNS name>
  backendName: fsx-iscsi
  svm: <SVM name>
  credentials:
    name: backend-tbc-fsx-iscsi-secret

StorageClass definition (save as sc-fsx-iscsi.yaml):

# sc-fsx-iscsi.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: sc-fsx-iscsi
provisioner: csi.trident.netapp.io
parameters:
  backendType: "ontap-san"
  media: "ssd"
  provisioningType: "thin"
  fsType: ext4
  snapshots: "true"
allowVolumeExpansion: true

Step 3: Create a VolumeSnapshotClass configuration file

Create a VolumeSnapshotClass definition for both on-premises and ROSA deployments. This configuration enables snapshot-based operations for persistent volumes.

VolumeSnapshotClass definition (save as snapshot-class.yaml):

# snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: trident-snapshotclass
driver: csi.trident.netapp.io
deletionPolicy: Retain

Step 4: Apply the configuration files to your cluster

Apply the configuration files you created in the previous steps to your OpenShift cluster.

Steps

Apply the TridentBackendConfig and StorageClass files for each protocol you configured.

For on-premises clusters:

oc create -f tbc-nas.yaml -n trident
oc create -f sc-nas.yaml

oc create -f tbc-nas-economy.yaml -n trident
oc create -f sc-nas-economy.yaml

oc create -f tbc-iscsi.yaml -n trident
oc create -f sc-iscsi.yaml

oc create -f tbc-nvme.yaml -n trident
oc create -f sc-nvme.yaml

oc create -f tbc-fc.yaml -n trident
oc create -f sc-fc.yaml

For ROSA clusters:

oc create -f tbc-fsx-nas.yaml -n trident
oc create -f sc-fsx-nas.yaml

oc create -f tbc-fsx-iscsi.yaml -n trident
oc create -f sc-fsx-iscsi.yaml

Apply the VolumeSnapshotClass configuration.
```
oc create -f snapshot-class.yaml
```
Verify that the resources were created successfully.

Check TridentBackendConfig objects:
```
oc get tbc -n trident
```
Check StorageClass objects:
```
oc get storageclass
```
Check VolumeSnapshotClass:
```
oc get volumesnapshotclass
```

Step 5: Set the default Trident storage and snapshot classes

Set the Trident StorageClass and VolumeSnapshotClass as the defaults in the OpenShift cluster. This is required for OpenShift Virtualization to create golden image sources for VM templates.

Steps

Set the default Trident StorageClass.

Set a Trident-backed StorageClass as the cluster default so that PersistentVolumeClaims automatically use it when no storage class is specified. You need to configure two annotations: one for the cluster-wide default and one specific to OpenShift Virtualization.
1. Set the cluster-wide default StorageClass annotation.
  
  Ensure that only one StorageClass is set as default. If another StorageClass is already set to default, set its annotation to false.
  
  In the console, edit the annotation:
  storageclass.kubernetes.io/is-default-class: "true"
  From the CLI:
  kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
2. Set the OpenShift Virtualization-specific default annotation.
  
  OpenShift Virtualization uses a specific annotation that takes precedence over the cluster's general is-default-class annotation. If another StorageClass is already set to default, set its annotation to false.
  
  In the console, edit the annotation:
  storageclass.kubevirt.io/is-default-virt-class: "true"
  From the CLI:
  kubectl patch storageclass <storage class name> -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
Set the default Trident VolumeSnapshotClass.

Set a Trident-backed VolumeSnapshotClass as the cluster default to enable snapshot-based operations for persistent volumes. This ensures that VolumeSnapshots automatically use the Trident CSI driver when no snapshot class is specified and allows OpenShift Virtualization to create snapshots of golden images.

Ensure that only one VolumeSnapshotClass is set as default. If another VolumeSnapshotClass is already set to default, set its annotation to false.

In the console, edit the annotation:
```
snapshot.storage.kubernetes.io/is-default-class: "true"
```
From the CLI:
```
oc patch volumesnapshotclass <snapshot class name> --type=merge -p '{"metadata":{"annotations":{"snapshot.storage.kubernetes.io/is-default-class":"true"}}}'
```

Install Trident on a Red Hat OpenShift cluster and create storage objects

Creating your file...

Step 1: Install Trident

Step 2: Prepare storage backend and StorageClass configuration files for your environment

On-premises OpenShift clusters

ROSA clusters with Amazon FSx for NetApp ONTAP

Step 3: Create a VolumeSnapshotClass configuration file

Step 4: Apply the configuration files to your cluster

Step 5: Set the default Trident storage and snapshot classes