Containers have ephemeral storage by default. When Kubernetes destroys a pod, it deletes all the files and data that are associated with that pod. You need a mechanism to preserve the application data, because Kubernetes destroys and re-creates pods when you scale down your application, deploy a new version, or when a node is drained for maintenance.

The administrator configures a connection between the Kubernetes cluster and the back-end storage by using Container Storage Interface (CSI) plug-ins, and then creates storage classes to represent the available storage types in the back-end storage controller.

Kubernetes uses persistent volumes to preserve data across container executions. Inside the container, you mount a persistent volume in a directory where the application stores its data. For example, MariaDB Server stores its database data under the /var/lib/mysql/data directory. By mounting a volume in that directory, you preserve the database data across container executions.

Kubernetes supports two ways of provisioning storage: static and dynamic.

Applications can request a persistent storage file system to mount a directory, or a raw block device for the fastest possible low-level operations. The application developer specifies the intended volume mode in the persistent volume claim (PVC).

Each storage back-end has different characteristics, and the provided volumes can be mounted by one or more containers in read-only or read/write mode. The application developer specifies the intended access mode in the PVC.

The persistent volume claims may contain a field to specify the storage class that is requested from the cluster. The default storage class is used for the new PVCs that do not specify a storage class requirement.

The OpenShift storage classes might contain annotations to identify the default storage class in the cluster, or to indicate that the storage class is specialized for use with virtual machine disks.

For each storage class, OpenShift Virtualization creates a storage profile. Storage profiles have the same name as their associated storage classes. A storage profile defines the PVC default values that are best suited for VM disks.

The following example shows that the ocs-external-storagecluster-ceph-rbd-​virtualization storage profile provides default values for the PVCs that are created through the storage class with the same name:

[user@host ~]$ oc get storageclass \
  ocs-external-storagecluster-ceph-rbd-​virtualization
NAME                                                  PROVISIONER
ocs-external-storagecluster-ceph-rbd-​virtualization   openshift-storage.rbd.csi…

[user@host ~]$ oc describe storageprofile \
  ocs-external-storagecluster-ceph-rbd-​virtualization
Name:         ocs-external-storagecluster-ceph-rbd-​virtualization	
Namespace:    ​	
Labels:       ...output omitted...
...output omitted...
Annotations:  <none>
API Version:  cdi.kubevirt.io/v1beta1
Kind:         StorageProfile
...output omitted...
Spec:
Status:
  Claim Property Sets:
    Access Modes:
      ReadWriteMany	
    Volume Mode:  Block	
    Access Modes:
      ReadWriteOnce	
    Volume Mode:  Block
    Access Modes:
      ReadWriteOnce
    Volume Mode:  Filesystem	
...output omitted...
  Provisioner:           openshift-storage.rbd.csi.ceph.com
  Storage Class:         ocs-external-storagecluster-ceph-rbd-​virtualization	
Events:                  <none>
...output omitted...

The default settings for a storage profile are determined by the order in which the access mode and volume modes are declared. The preceding storage profile declares the ReadWriteMany access mode as the default, which enables VM live migrations, and declares the Block volume mode as the default, which provides better performance for VM disks than the Filesystem mode.

As a developer, when you use a storage profile to prepare a VM disk, the only parameter that you must provide is the disk size. The storage profile ensures that all the other parameters have an optimal value for VM disk usage.

The data volume resources define properties for the associated PVC, and the location of the source image to initialize the volume.

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: vm1	
  namespace: storage-intro	
  ...output omitted...
spec:
  pvc:
    accessModes:
    - ReadWriteMany	
    resources:
      requests:
        storage: 10Gi	
    storageClassName: ocs-external-storagecluster-ceph-rbd-​virtualization	
    volumeMode: Block	
  source:
    http:
      url: http://images.example.com/openshift4/images/mariadb-server.qcow2	

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
...output omitted...
spec:
...output omitted...
  source:
    blank: {}	

When the PVC to create is in Filesystem mode, the data volume automatically instructs Kubernetes to create the PVC 5.5% larger than requested to account for file system overhead. By doing so, Kubernetes ensures that it can create the disk image file, disk.img, with the requested size.

Use the OpenShift web console to create a data volume and attach it to a VM as an additional disk.

Figure 5.2: Add a disk to a virtual machine

Some virtualization features, such as live migration or VM snapshots, rely on your back-end storage. For example, using Red Hat Ceph Storage RBD volumes enables live migration, snapshots, and disk cloning.

For single-node clusters or clusters without a dedicated storage solution, the administrator can configure the cluster to use the local disk space of each node as persistent storage by using any of the following solutions: