Storage configuration - Postinstallation configuration | Virtualization

Configuring local storage by using the HPP
- Creating a storage class for the CSI driver with the storagePools stanza

The following storage configuration tasks are mandatory:

You must configure a default storage class for your cluster. Otherwise, the cluster cannot receive automated boot source updates.
You must configure storage profiles if your storage provider is not recognized by the Containerized Data Importer (CDI). A storage profile provides recommended storage settings based on the associated storage class.

Optional: You can configure local storage by using the hostpath provisioner (HPP).

See the storage configuration overview for more options, including configuring the CDI, data volumes, and automatic boot source updates.

Configuring local storage by using the HPP

When you install the OKD Virtualization Operator, the Hostpath Provisioner (HPP) Operator is automatically installed. The HPP Operator creates the HPP provisioner.

The HPP is a local storage provisioner designed for OKD Virtualization. To use the HPP, you must create an HPP custom resource (CR).

HPP storage pools must not be in the same partition as the operating system. Otherwise, the storage pools might fill the operating system partition. If the operating system partition is full, this might negatively impact performance, or the node can become unstable or unusable.

Creating a storage class for the CSI driver with the storagePools stanza

To use the hostpath provisioner (HPP) you must create an associated storage class for the Container Storage Interface (CSI) driver.

When you create a storage class, you set parameters that affect the dynamic provisioning of persistent volumes (PVs) that belong to that storage class. You cannot update a StorageClass object’s parameters after you create it.

Virtual machines use data volumes that are based on local PVs. Local PVs are bound to specific nodes. While a disk image is prepared for consumption by the virtual machine, it is possible that the virtual machine cannot be scheduled to the node where the local storage PV was previously pinned.

To solve this problem, use the Kubernetes pod scheduler to bind the persistent volume claim (PVC) to a PV on the correct node. By using the StorageClass value with volumeBindingMode parameter set to WaitForFirstConsumer, the binding and provisioning of the PV is delayed until a pod is created using the PVC.

Procedure

Create a storageclass_csi.yaml file to define the storage class:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: hostpath-csi
provisioner: kubevirt.io.hostpath-provisioner
reclaimPolicy: Delete (1)
volumeBindingMode: WaitForFirstConsumer (2)
parameters:
  storagePool: my-storage-pool (3)
```
- reclaimPolicy specifies whether the underlying storage is deleted or retained when a user deletes a PVC. The two possible reclaimPolicy values are Delete and Retain. If you do not specify a value, the default value is Delete.
- volumeBindingMode specifies the timing of PV creation. The WaitForFirstConsumer configuration in this example means that PV creation is delayed until a pod is scheduled to a specific node.
- parameters.storagePool specifies the name of the storage pool defined in the HPP custom resource (CR).
Save the file and exit.
Create the StorageClass object by running the following command:
```
$ oc create -f storageclass_csi.yaml
```

Postinstallation storage configuration

Configuring local storage by using the HPP

Creating a storage class for the CSI driver with the storagePools stanza