---
title: Using OpenShift Virtualization with IBM Fusion Access for SAN
---

# Using OpenShift Virtualization with IBM Fusion Access for SAN {#install-configure-fusion-access-san}

You configure SAN-based storage for virtual machines by using IBM Fusion Access for SAN with OpenShift Virtualization. You must install the Fusion Access for SAN Operator (Fusion Access for SAN) and set up the storage cluster and file systems.

## About IBM Fusion Access for SAN {#about-fusion-access-san_install-configure-fusion-access-san}

IBM Fusion Access for SAN provides a scalable clustered file system for enterprise storage, primarily designed to offer access to consolidated, block-level data storage. It presents storage devices, such as disk arrays, to the operating system as if they were direct-attached storage.

IBM Fusion Access for SAN uses existing Storage Area Network (SAN) infrastructure to provide enterprise storage for OpenShift Virtualization. A SAN is a dedicated network of storage devices that is typically not accessible through the local area network (LAN).

To use OpenShift Virtualization with IBM Fusion Access for SAN, you must first install the Fusion Access for SAN Operator.

Then you must create a Kubernetes pull secret and create the `FusionAccess` custom resource (CR).

Finally, follow the OpenShift Container Platform web console wizard to configure the storage cluster, local disk, and file systems.

### Why use Fusion Access for SAN {#why-use-fusion-san_install-configure-fusion-access-san}

Easy user experience
:   Fusion Access for SAN features a wizard-driven user interface (UI) for installing and configuring storage clusters, file systems, and storage classes, to simplify the setup process.

Use existing infrastructure
:   Organizations can use their existing SAN investments, including Fibre Channel (FC) and iSCSI technologies, as they migrate to or expand with OpenShift Virtualization.

Scalability
:   The storage cluster is designed to scale with OpenShift Container Platform clusters and virtual machine (VM) workloads. It can support up to approximately 3000 VMs on 6 bare-metal hosts, with possibilities for further scaling by adding more file systems or using specific storage class parameters.

Consolidated and shared storage
:   SANs enable multiple servers to access a large, shared data storage capacity. This architecture facilitates automatic data backup and continuous monitoring of the storage and backup processes.

High-speed data transfer
:   By using a dedicated high-speed network for storage, Fusion Access for SAN overcomes the data transfer bottlenecks that can occur over a traditional LAN, especially for large volumes of data.

File-level access
:   Although a SAN primarily operates at the block level, file systems built on top of SAN storage can provide file-level access through shared-disk file systems.

Centralized management
:   The underlying SAN software manages servers, storage devices, and the network to ensure that data moves directly between storage devices with minimal server intervention. It also supports centralized management and configuration of SAN components such as Logical Unit Numbers (LUNs).

## Prerequisites and Limitations for Fusion Access for SAN {#fusion-access-san-prereqs_install-configure-fusion-access-san}

Prerequisites and limitations are provided for installing and configuring Fusion Access for SAN.

### Prerequisites {#_prerequisites}

Installing and configuring Fusion Access for SAN require the following prerequisites:

- Bare-metal worker nodes with attached SAN storage.
- A working container registry enabled.
- All worker nodes must connect to the same LUNs.

  A shared LUN is a shared disk that is accessed by all worker nodes simultaneously.
- A Kubernetes pull secret.

### Limitations {#_limitations}

- Limitations for Fusion Access for SAN rely on the IBM Storage Scale container native limitations and can be found in the documentation for [IBM Storage Scale container native](https://www.ibm.com/docs/en/scalecontainernative/5.2.3?topic=overview-limitations).
- Hosted control planes (HCP) clusters are not supported.

## Installing the Fusion Access for SAN Operator {#installing-fusion-access-operator_install-configure-fusion-access-san}

You can install the Fusion Access for SAN Operator from the software catalog in the OpenShift Container Platform web console.

**Prerequisites**

- You have access to the cluster as a user with the `cluster-admin` role.
- You have a working container registry enabled.

**Procedure**

1. In the OpenShift Container Platform web console, navigate to **Ecosystem** → **Software Catalog**.
2. In the **Filter by keyword** field, type `Fusion Access for SAN`.
3. Select the **Fusion Access for SAN** tile and click **Install**.
4. On the **Install Operator** page, keep the default selections for **Update Channel**, **Version**, and **Installation mode**.
5. Verify that **Operator recommended Namespace** is selected for **Installed Namespace**.

   This installs the Operator in the `ibm-fusion-access` namespace. If this namespace does not yet exist, it is automatically created.

   > [!WARNING]
   > You must install the Fusion Access for SAN Operator in the `ibm-fusion-access` namespace. Installation in any other namespace is not supported.
6. Verify that the **Automatic** default is selected for **Update Approval**.

   This enables automatic updates when a new z-stream release is available.
7. Click **Install**.

   This installs the Operator.

**Verification**

1. Navigate to **Ecosystem** → **Installed Operators**.
2. Verify that the Fusion Access for SAN Operator is displayed.

## Creating a Kubernetes pull secret {#creating-pull-secret-fusion-san_install-configure-fusion-access-san}

After installing the Fusion Access for SAN Operator, you must create a Kubernetes secret object to hold the IBM entitlement key for pulling the required container images from the IBM container registry.

**Prerequisites**

- You installed the `oc` CLI.
- You have access to the cluster as a user with the `cluster-admin` role.
- You installed the Fusion Access for SAN Operator and created the `ibm-fusion-access` namespace in the process.

**Procedure**

1. Log in to the [**IBM Container software library**](https://myibm.ibm.com/products-services/containerlibrary) with your Fusion Access for SAN **IBMid** and **password**.
2. In the **IBM Container software library**, get the entitlement key:

   1. If you do not have an entitlement key yet, click **Get entitlement key** or **Add new key**, and then click **Copy**.
   2. If you already have an entitlement key, click **Copy**.
3. Save the entitlement key in a safe place.
4. Create the secret object by running the `oc create` command, replacing `<ibm-entitlement-key>` with the entitlement key that you copied in step 2.

   ```terminal
   $ oc create secret -n ibm-fusion-access generic fusion-pullsecret \
   --from-literal=ibm-entitlement-key=<ibm-entitlement-key>
   ```

**Verification**

1. In the OpenShift Container Platform web console, navigate to **Workloads** → **Secrets**.
2. Find the `fusion-pullsecret` in the list.

## Creating the FusionAccess CR {#creating-fusionaccess-cr_install-configure-fusion-access-san}

After installing the Fusion Access for SAN Operator and creating a Kubernetes pull secret, you must create the `FusionAccess` custom resource (CR).

Creating the `FusionAccess` CR triggers the installation of the correct version of IBM Storage Scale and detects worker nodes with shared LUNs.

**Prerequisites**

- You have access to the cluster as a user with the `cluster-admin` role.
- You installed the Fusion Access for SAN Operator.
- You created a Kubernetes pull secret.

**Procedure**

1. In the OpenShift Container Platform web console, navigate to **Ecosystem** → **Installed Operators**.
2. Click the Fusion Access for SAN Operator you installed.
3. In the **Fusion Access for SAN** page, select the **Fusion Access** tab.
4. Click **Create FusionAccess**.
5. On the **Create FusionAccess** page, enter the object **Name**.
6. Optional: You can choose to add **Labels** if they are relevant.
7. Select the **IBM Storage Scale Version** from the drop-down list.
8. Click **Create**.

**Verification**

- In the **Fusion Access for SAN** Operator page, in the **Fusion Access** tab, verify that the created `FusionAccess` CR is displayed with the status **Ready**.

## Creating a storage cluster with Fusion Access for SAN {#creating-storage-cluster-fusion-access-san_install-configure-fusion-access-san}

Once you have installed the Fusion Access for SAN Operator, you can create a storage cluster with shared storage nodes.

The wizard for creating the storage cluster in the OpenShift Container Platform web console provides easy-to-follow steps and lists the relevant worker nodes with shared disks.

**Prerequisites**

- You have bare-metal worker nodes with visible and attached shared LUNs.

  A shared LUN is a shared disk that is accessed by all workers simultaneously.
- You installed the Fusion Access for SAN Operator.
- You created the `FusionAccess` custom resource (CR) in the `ibm-fusion-access` namespace.

**Procedure**

1. In the OpenShift Container Platform web console, navigate to **Storage** → **Fusion Access for SAN**.
2. Click **Create storage cluster**.
3. Select the worker nodes that have shared LUNs.

   > [!NOTE]
   > You can only select worker nodes with a minimum of 20 GB of RAM from the list.
4. Click **Create storage cluster**.

   The page reloads, opening the Fusion Access for SAN page for the new storage cluster.

## Creating a file system with Fusion Access for SAN {#creating-filesystem-fusion-access-san_install-configure-fusion-access-san}

You need to create a file system to represent your required storage.

The file system is based on the storage available in the worker nodes you selected when creating the storage cluster.

**Prerequisites**

- You created a Fusion Access for SAN storage cluster.

**Procedure**

1. In the OpenShift Container Platform web console, navigate to **Storage** → **Fusion Access for SAN**.
2. In the **File systems** tab, click **Create file system**.
3. Enter a **Name** for the new file system.
4. Select the LUNs that you want to use as the storage volumes for your file system.
5. Click **Create file system**.

   The **Fusion Access for SAN** page reloads, and the new file system is displayed in the **File systems** tab.

**Next steps**

Repeat this procedure for each file system that you want to create.

**Verification**

1. Watch the **Status** of the file system in the **File systems** tab until it is marked as **Healthy**. This might take several minutes.
2. Click the **StorageClass** for the file system.
3. In the **YAML** tab, verify the following:

   1. The value in the `name` field is the name of the file system you created.
   2. The value in the `provisioner` field is `spectrumscale.csi.ibm.com`.
   3. The value in the `volBackendFs` field matches the name of the file system you created.

      ```yaml
      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: filesystem1
        uid: eb410309-a043-a89b-9bb05483872a
        resourceVersion: '87746'
        creationTimestamp: '2025-05-14T12:30:08Z'
        managedFields:
      provisioner: spectrumscale.csi.ibm.com
      parameters:
        volBackendFs: filesystem1
      reclaimPolicy: Delete
      allowVolumeExpansion: true
      volumeBindingMode: Immediate
      ```

## Troubleshooting IBM Fusion Access for SAN {#troubleshoot-fusion-access-san_install-configure-fusion-access-san}

If you encounter issues with IBM Fusion Access for SAN, provide the must-gather image to Red Hat support. This image contains critical data about your cluster and project resources, logs, and events from your deployment.

**Procedure**

1. To obtain the deployed version of IBM Fusion Access for SAN, run the following command:

   ```terminal
   $ oc get fusionaccesses.fusion.storage.openshift.io  -n ibm-fusion-access fusionaccess-sample -o jsonpath='{.spec.storageScaleVersion}'
   ```

   > [!NOTE]
   > This command returns the numeric value of the deployed version of IBM Fusion Access for SAN such as `2.11.0`.
2. To create the `must-gather` image, run the following command:

   ```terminal
   $ oc adm must-gather --image=icr.io/cpopen/ibm-spectrum-scale-must-gather:v<software_version>
   ```

   - Replace `<software_version>` with the IBM Fusion Access for SAN version value.

## IBM Fusion Access for SAN release updates {#virt-fusion-access-san-release-updates_install-configure-fusion-access-san}

Release updates for IBM Fusion Access for SAN, including new features, bug fixes, and known issues.

### New and changed features {#virt-fusion-access-san-new-changes_install-configure-fusion-access-san}

IBM Fusion Access for SAN 1.1.0 includes Spectrum Scale 5.2.3.5
:   IBM Fusion Access for SAN 1.1.0 uses Spectrum Scale version 5.2.3.5. When you upgrade to IBM Fusion Access for SAN 1.1.0, Spectrum Scale is automatically upgraded to version 5.2.3.5.

    [OCPNAS-294](https://issues.redhat.com/browse/OCPNAS-294)

    [OCPNAS-279](https://issues.redhat.com/browse/OCPNAS-279)

Backend redesign for `FileSystemClaim` resources
:   IBM Fusion Access for SAN updates the backend to use `FileSystemClaim` resources for managing filesystem related objects. Previously, filesystem creation could fail if the process was interrupted. With this update, backend handling improves reliability while keeping the user interface flow and appearance unchanged.

    After you upgrade to IBM Fusion Access for SAN 1.1.0, resources that were created by using the 1.0 user interface are automatically migrated and associated with a `FileSystemClaim` resource.

    [OCPNAS-241](https://issues.redhat.com/browse/OCPNAS-241)

Automatic creation of `VolumeSnapshotClass` resources for filesystems
:   IBM Fusion Access for SAN now creates a `VolumeSnapshotClass` resource alongside the `StorageClass` resource for each filesystem. This ensures that snapshot support is consistently available for newly created filesystems.

    After upgrading from IBM Fusion Access for SAN 1.0 to 1.1.0, a `VolumeSnapshotClass` resource is automatically created for existing filesystems that did not previously have one.

    [OCPNAS-293](https://issues.redhat.com/browse/OCPNAS-293)

Image registry requirements for kernel module management
:   IBM Fusion Access for SAN uses the OpenShift Container Platform image registry to manage the kernel module. Do not configure the registry to use `emptyDir` storage because it provides only temporary storage and is not suitable for production use. Configure IBM Fusion Access for SAN to use a different image registry by creating a config map and secret after installing the Operator and before creating the `FusionAccess` CR.

    [OCPNAS-213](https://issues.redhat.com/browse/OCPNAS-213)

### Bug fixes {#virt-fusion-access-san-bug-fixes_install-configure-fusion-access-san}

Filesystem creation button stays disabled until daemons are ready
:   The IBM Fusion Access for SAN Operator was updated to check the readiness of filesystem daemons before allowing a filesystem to be created. The **Create file system** button in the web console now stays disabled with a tooltip explaining the condition until the environment is ready. This change prevents filesystems from appearing stuck during creation.

    [OCPNAS-184](https://issues.redhat.com/browse/OCPNAS-184)

Filesystems cannot be deleted from the user interface
:   The OpenShift Container Platform web console does not support deleting filesystems. To delete a filesystem, use the OpenShift CLI (`oc`).

    [OCPNAS-217](https://issues.redhat.com/browse/OCPNAS-217)

### Known issues {#virt-fusion-access-san-known-issues_install-configure-fusion-access-san}

Filesystem creation might fail during core pod deletion
:   Filesystem creation might fail if core pods are deleted at the same time. The filesystem might be partially created on the LUN, which results in the following persistent error:

    ```terminal
    Disk <ID> may still belong to an active file system
    ```

    No workaround is available. Contact IBM Support for assistance.

    [OCPNAS-233](https://issues.redhat.com/browse/OCPNAS-233)

**Additional resources**
{._additional-resources}

- [Creating virtual machines from instance types](/openshift-docs-markdown/virt/creating_vm/virt-creating-vms-from-instance-types#virt-creating-vms-from-instance-types)
- [Creating virtual machines from templates](/openshift-docs-markdown/virt/creating_vm/virt-creating-vms-from-templates#virt-creating-vms-from-templates)