Chapter 9. Storage

Procedure

1. Edit the storage profile. In this example, the provisioner is not recognized by CDI.

   $ oc edit storageprofile <storage_class>

   Example storage profile

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: StorageProfile
   metadata:
     name: <unknown_provisioner_class>
   # ...
   spec: {}
   status:
     provisioner: <unknown_provisioner>
     storageClass: <unknown_provisioner_class>

2. Provide the needed attribute values in the storage profile:

   Example storage profile

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: StorageProfile
   metadata:
     name: <unknown_provisioner_class>
   # ...
   spec:
     claimPropertySets:
     - accessModes:
       - ReadWriteOnce 1
       volumeMode:
         Filesystem 2
   status:
     provisioner: <unknown_provisioner>
     storageClass: <unknown_provisioner_class>

   1

   The accessModes that you select.

   2

   The volumeMode that you select.

   After you save your changes, the selected values appear in the storage profile status element.

Procedure

1. Open the HyperConverged CR in your default editor by running the following command:

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

2. Disable automatic updates for an individual boot source by editing the spec.dataImportCronTemplates field.

   Custom boot source

   • Remove the boot source from the spec.dataImportCronTemplates field. Automatic updates are disabled for custom boot sources by default.

   System-defined boot source

   1. Add the boot source to spec.dataImportCronTemplates.

      Note

      Automatic updates are enabled by default for system-defined boot sources, but these boot sources are not listed in the CR unless you add them.

   2. Set the value of the dataimportcrontemplate.kubevirt.io/enable annotation to 'false'.

      For example:

      apiVersion: hco.kubevirt.io/v1beta1
      kind: HyperConverged
      metadata:
        name: kubevirt-hyperconverged
      spec:
        dataImportCronTemplates:
        - metadata:
            annotations:
              dataimportcrontemplate.kubevirt.io/enable: 'false'
            name: rhel8-image-cron
      # ...

3. Save the file.

Procedure

1. View the contents of the HyperConverged CR by running the following command:

   $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o yaml

   Example output

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
   # ...
   status:
   # ...
     dataImportCronTemplates:
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: centos-9-image-cron
       spec:
         garbageCollect: Outdated
         managedDataSource: centos-stream9
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 url: docker://quay.io/containerdisks/centos-stream:9
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status:
         commonTemplate: true 1
   # ...
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: user-defined-dic
       spec:
         garbageCollect: Outdated
         managedDataSource: user-defined-centos-stream9
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 pullMethod: node
                 url: docker://quay.io/containerdisks/centos-stream:9
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status: {} 2
   # ...

   1

   Indicates a system-defined boot source.

   2

   Indicates a custom boot source.

2. Verify the status of the boot source by reviewing the status.dataImportCronTemplates.status field.

   • If the field contains commonTemplate: true, it is a system-defined boot source.
   • If the status.dataImportCronTemplates.status field has the value {}, it is a custom boot source.

Procedure

1. Open the HCO object for editing by running the following command:

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

2. Edit the spec.filesystemOverhead fields, populating them with your chosen values:

   # ...
   spec:
     filesystemOverhead:
       global: "<new_global_value>" 1
       storageClass:
         <storage_class_name>: "<new_value_for_this_storage_class>" 2

   1

   The default file system overhead percentage used for any storage classes that do not already have a set value. For example, global: "0.07" reserves 7% of the PVC for file system overhead.

   2

   The file system overhead percentage for the specified storage class. For example, mystorageclass: "0.04" changes the default overhead value for PVCs in the mystorageclass storage class to 4%.

3. Save and exit the editor to update the HCO object.

Procedure

1. Create an hpp_cr.yaml file with a storagePools stanza as in the following example:

   apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     storagePools: 1
     - name: any_name
       path: "/var/myvolumes" 2
   workload:
     nodeSelector:
       kubernetes.io/os: linux

   1

   The storagePools stanza is an array to which you can add multiple entries.

   2

   Specify the storage pool directories under this node path.

2. Save the file and exit.

3. Create the HPP by running the following command:

   $ oc create -f hpp_cr.yaml

Procedure

1. Create a ClusterRole manifest:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: <datavolume-cloner> 1
   rules:
   - apiGroups: ["cdi.kubevirt.io"]
     resources: ["datavolumes/source"]
     verbs: ["*"]

   1

   Unique name for the cluster role.

2. Create the cluster role in the cluster:

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   The file name of the ClusterRole manifest created in the previous step.

3. Create a RoleBinding manifest that applies to both the source and destination namespaces and references the cluster role created in the previous step.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: <allow-clone-to-user> 1
     namespace: <Source namespace> 2
   subjects:
   - kind: ServiceAccount
     name: default
     namespace: <Destination namespace> 3
   roleRef:
     kind: ClusterRole
     name: datavolume-cloner 4
     apiGroup: rbac.authorization.k8s.io

   1

   Unique name for the role binding.

   2

   The namespace for the source data volume.

   3

   The namespace to which the data volume is cloned.

   4

   The name of the cluster role created in the previous step.

4. Create the role binding in the cluster:

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   The file name of the RoleBinding manifest created in the previous step.

Procedure

1. Edit the HyperConverged CR by running the following command:

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

2. Add the spec.resourceRequirements.storageWorkloads stanza to the CR, setting the values based on your use case. For example:

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     resourceRequirements:
       storageWorkloads:
         limits:
           cpu: "500m"
           memory: "2Gi"
         requests:
           cpu: "250m"
           memory: "1Gi"

3. Save and exit the editor to update the HyperConverged CR.

Procedure

1. Edit the HyperConverged CR by running the following command:

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

2. Add the spec.scratchSpaceStorageClass field to the CR, setting the value to the name of a storage class that exists in the cluster:

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     scratchSpaceStorageClass: "<storage_class>" 1

   1

   If you do not specify a storage class, CDI uses the storage class of the persistent volume claim that is being populated.

3. Save and exit your default editor to update the HyperConverged CR.