Chapter 9. Storage

Procedure

1. Open the

   HyperConverged

   CR in your default editor by running the following command:

   $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

2. Define a new storage class by entering a value in the

   storageClassName

   field:

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: rhel8-image-cron
       spec:
         template:
           spec:
             storageClassName: <new_storage_class>
         schedule: "0 */12 * * *"
         managedDataSource: <data_source>
   # ...

   • spec.dataImportCronTemplates.spec.template.spec.storageClassName

     specifies the storage class.

   • spec.dataImportCronTemplates.spec.schedule

     is a required field that specifies the schedule for the job in cron format.

   • spec.dataImportCronTemplates.spec.managedDataSource

     is a required field that specifies the data source to use.
     Note

     For the custom image to be detected as an available boot source, the value of the

     spec.dataVolumeTemplates.spec.sourceRef.name

     parameter in the VM template must match this value.

3. Remove the

   storageclass.kubernetes.io/is-default-class

   annotation from the current default storage class.

   1. Retrieve the name of the current default storage class by running the following command:

      $ oc get storageclass

      Example output

      NAME                          PROVISIONER                      RECLAIMPOLICY  VOLUMEBINDINGMODE    ALLOWVOLUMEEXPANSION  AGE
      csi-manila-ceph               manila.csi.openstack.org         Delete         Immediate            false                 11d
      hostpath-csi-basic (default)  kubevirt.io.hostpath-provisioner Delete         WaitForFirstConsumer false                 11d

      In this example, the current default storage class is named

      hostpath-csi-basic

      .

   2. Remove the annotation from the current default storage class by running the following command:

      $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

      Replace

      <current_default_storage_class>

      with the

      storageClassName

      value of the default storage class.

4. Set the new storage class as the default by running the following command:

   $ oc patch storageclass <new_storage_class> -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

   Replace

   <new_storage_class>

   with the

   storageClassName

   value that you added to the

   HyperConverged

   CR.

Procedure

1. Open the

   HyperConverged

   CR in your default editor by running the following command:

   $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

2. Edit the

   HyperConverged

   CR, adding the appropriate template and boot source in the

   dataImportCronTemplates

   section. For example:

   Example custom resource

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: centos7-image-cron
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
       spec:
         schedule: "0 */12 * * *"
         template:
           spec:
             source:
               registry:
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 10Gi
         managedDataSource: centos7
         retentionPolicy: "None"

   • spec.dataImportCronTemplates.metadata.annotations

     specifies a required annotation for storage classes with

     volumeBindingMode

     set to

     WaitForFirstConsumer

     .

   • spec.dataImportCronTemplates.spec.schedule

     specifies the schedule for the job, specified in cron format.

   • spec.dataImportCronTemplates.spec.template.spec.source.registry

     specifies the registry source to use to create a data volume. Use the default

     pod

     pullMethod

     and not

     node

     pullMethod

     , which is based on the

     node

     docker cache. The

     node

     docker cache is useful when a registry image is available via

     Container.Image

     , but the CDI importer is not authorized to access it.

   • spec.dataImportCronTemplates.spec.managedDataSource

     specifies the name of the managed data source. For the custom image to be detected as an available boot source, the name of the image’s

     managedDataSource

     must match the name of the template’s

     DataSource

     , which is found under

     spec.dataVolumeTemplates.spec.sourceRef.name

     in the VM template YAML file.

   • spec.dataImportCronTemplates.spec.retentionPolicy

     specifies whether to retain data volumes and data sources after the cron job is deleted. Use

     All

     to retain data volumes and data sources. Use

     None

     to delete data volumes and data sources.
3. Save the file.

Procedure

1. Open the storage profile object that corresponds to the storage class used to provision boot sources by running the following command:

   $ oc edit storageprofile <storage_class>

2. Review the

   dataImportCronSourceFormat

   specification of the

   StorageProfile

   to confirm whether or not the VM is using PVC or volume snapshot by default.

3. Edit the storage profile, if needed, by updating the

   dataImportCronSourceFormat

   specification to

   snapshot

   .

   Example storage profile

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: StorageProfile
   metadata:
   # ...
   spec:
     dataImportCronSourceFormat: snapshot

Verification

1. Open the storage profile object that corresponds to the storage class used to provision boot sources.

   $ oc get storageprofile <storage_class>  -oyaml

2. Confirm that the

   dataImportCronSourceFormat

   specification of the

   StorageProfile

   is set to 'snapshot', and that any

   DataSource

   objects that the

   DataImportCron

   points to now reference volume snapshots.

Procedure

1. 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).
2. Save the file and exit.

3. Create the

   StorageClass

   object by running the following command:

   $ oc create -f storageclass_csi.yaml

Procedure

1. Create an

   hpp_pvc_template_pool.yaml

   file for the HPP CR that specifies a persistent volume (PVC) template in the

   storagePools

   stanza according to the following example:

   apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     storagePools: 

   1

   
     - name: my-storage-pool
       path: "/var/myvolumes" 

   2

   
       pvcTemplate:
         volumeMode: Block 

   3

   
         storageClassName: my-storage-class 

   4

   
         accessModes:
         - ReadWriteOnce
         resources:
           requests:
             storage: 5Gi 

   5

   
     workload:
       nodeSelector:
         kubernetes.io/os: linux

   1 1

   The storagePools stanza is an array that can contain both basic and PVC template storage pools.

   2 2

   Specify the storage pool directories under this node path.

   3 3

   Optional: The volumeMode parameter can be either Block or Filesystem as long as it matches the provisioned volume format. If no value is specified, the default is Filesystem. If the volumeMode is Block, the mounting pod creates an XFS file system on the block volume before mounting it.

   4

   If the storageClassName parameter is omitted, the default storage class is used to create PVCs. If you omit storageClassName, ensure that the HPP storage class is not the default storage class.

   5

   You can specify statically or dynamically provisioned storage. In either case, ensure the requested storage size is appropriate for the volume you want to virtually divide or the PVC cannot be bound to the large PV. If the storage class you are using uses dynamically provisioned storage, pick an allocation size that matches the size of a typical request.

2. Save the file and exit.

3. Create the HPP with a storage pool by running the following command:

   $ oc create -f hpp_pvc_template_pool.yaml