Creating data volumes

When you create a data volume, the Containerized Data Importer (CDI) creates a persistent volume claim (PVC) and populates the PVC with your data. You can create a data volume as either a standalone resource or by using a dataVolumeTemplate resource in a virtual machine specification. You create a data volume by using either the PVC API or storage APIs.

When using OKD Virtualization with OKD Container Storage, specify RBD block mode persistent volume claims (PVCs) when creating virtual machine disks. With virtual machine disks, RBD block mode volumes are more efficient and provide better performance than Ceph FS or RBD filesystem-mode PVCs.

To specify RBD block mode PVCs, use the ‘ocs-storagecluster-ceph-rbd’ storage class and VolumeMode: Block.

Whenever possible, use the storage API to optimize space allocation and maximize performance.

A storage profile is a custom resource that the CDI manages. It provides recommended storage settings based on the associated storage class. A storage profile is allocated for each storage class.

Storage profiles enable you to create data volumes quickly while reducing coding and minimizing potential errors.

For recognized storage types, the CDI provides values that optimize the creation of PVCs. However, you can configure automatic settings for a storage class if you customize the storage profile.

Creating data volumes using the storage API

When you create a data volume using the storage API, the Containerized Data Interface (CDI) optimizes your persistent volume claim (PVC) allocation based on the type of storage supported by your selected storage class. You only have to specify the data volume name, namespace, and the amount of storage that you want to allocate.

For example:

  • When using Ceph RBD, accessModes is automatically set to ReadWriteMany, which enables live migration. volumeMode is set to Block to maximize performance.

  • When you are using volumeMode: Filesystem, more space will automatically be requested by the CDI, if required to accommodate file system overhead.

In the following YAML, using the storage API requests a data volume with two gigabytes of usable space. The user does not need to know the volumeMode in order to correctly estimate the required persistent volume claim (PVC) size. The CDI chooses the optimal combination of accessModes and volumeMode attributes automatically. These optimal values are based on the type of storage or the defaults that you define in your storage profile. If you want to provide custom values, they override the system-calculated values.

Example DataVolume definition

  1. apiVersion: cdi.kubevirt.io/v1beta1
  2. kind: DataVolume
  3. metadata:
  4.   name: <datavolume> (1)
  5. spec:
  6.   source:
  7.     pvc: (2)
  8.       namespace: "<source_namespace>" (3)
  9.       name: "<my_vm_disk>" (4)
  10.   storage: (5)
  11.     resources:
  12.       requests:
  13.         storage: 2Gi (6)
  14.     storageClassName: <storage_class> (7)
1The name of the new data volume.
2Indicate that the source of the import is an existing persistent volume claim (PVC).
3The namespace where the source PVC exists.
4The name of the source PVC.
5Indicates allocation using the storage API.
6Specifies the amount of available space that you request for the PVC.
7Optional: The name of the storage class. If the storage class is not specified, the system default storage class is used.

Creating data volumes using the PVC API

When you create a data volume using the PVC API, the Containerized Data Interface (CDI) creates the data volume based on what you specify for the following fields:

  • accessModes (ReadWriteOnce, ReadWriteMany, or ReadOnlyMany)

  • volumeMode (Filesystem or Block)

  • capacity of storage (5Gi, for example)

In the following YAML, using the PVC API allocates a data volume with a storage capacity of two gigabytes. You specify an access mode of ReadWriteMany to enable live migration. Because you know the values your system can support, you specify Block storage instead of the default, Filesystem.

Example DataVolume definition

  1. apiVersion: cdi.kubevirt.io/v1beta1
  2. kind: DataVolume
  3. metadata:
  4.   name: <datavolume> (1)
  5. spec:
  6.   source:
  7.     pvc: (2)
  8.       namespace: "<source_namespace>" (3)
  9.       name: "<my_vm_disk>" (4)
  10.   pvc: (5)
  11.     accessModes: (6)
  12.       - ReadWriteMany
  13.     resources:
  14.       requests:
  15.         storage: 2Gi (7)
  16.     volumeMode: Block (8)
  17.     storageClassName: <storage_class> (9)
1The name of the new data volume.
2In the source section, pvc indicates that the source of the import is an existing persistent volume claim (PVC).
3The namespace where the source PVC exists.
4The name of the source PVC.
5Indicates allocation using the PVC API.
6accessModes is required when using the PVC API.
7Specifies the amount of space you are requesting for your data volume.
8Specifies that the destination is a block PVC.
9Optionally, specify the storage class. If the storage class is not specified, the system default storage class is used.

When you explicitly allocate a data volume by using the PVC API and you are not using volumeMode: Block, consider file system overhead.

File system overhead is the amount of space required by the file system to maintain its metadata. The amount of space required for file system metadata is file system dependent. Failing to account for file system overhead in your storage capacity request can result in an underlying persistent volume claim (PVC) that is not large enough to accommodate your virtual machine disk.

If you use the storage API, the CDI will factor in file system overhead and request a larger persistent volume claim (PVC) to ensure that your allocation request is successful.

Customizing the storage profile

You can specify default parameters by editing the StorageProfile object for the provisioner’s storage class. These default parameters only apply to the persistent volume claim (PVC) if they are not configured in the DataVolume object.

Prerequisites

  • Ensure that your planned configuration is supported by the storage class and its provider. Specifying an incompatible configuration in a storage profile causes volume provisioning to fail.

An empty status section in a storage profile indicates that a storage provisioner is not recognized by the Containerized Data Interface (CDI). Customizing a storage profile is necessary if you have a storage provisioner that is not recognized by the CDI. In this case, the administrator sets appropriate values in the storage profile to ensure successful allocations.

If you create a data volume and omit YAML attributes and these attributes are not defined in the storage profile, then the requested storage will not be allocated and the underlying persistent volume claim (PVC) will not be created.

Procedure

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

    1. $ oc edit -n openshift-cnv storageprofile <storage_class>

    Example storage profile

    1. apiVersion: cdi.kubevirt.io/v1beta1
    2. kind: StorageProfile
    3. metadata:
    4.   name: <unknown_provisioner_class>
    5. #   ...
    6. spec: {}
    7. status:
    8.   provisioner: <unknown_provisioner>
    9.   storageClass: <unknown_provisioner_class>

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

    Example storage profile

    1. apiVersion: cdi.kubevirt.io/v1beta1
    2. kind: StorageProfile
    3. metadata:
    4.   name: <unknown_provisioner_class>
    5. #   ...
    6. spec:
    7.   claimPropertySets:
    8.   - accessModes:
    9.     - ReadWriteOnce (1)
    10.     volumeMode:
    11.       Filesystem (2)
    12. status:
    13.   provisioner: <unknown_provisioner>
    14.   storageClass: <unknown_provisioner_class>
    1The accessModes that you select.
    2The volumeMode that you select.

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

Setting a default cloning strategy using a storage profile

You can use storage profiles to set a default cloning method for a storage class, creating a cloning strategy. Setting cloning strategies can be helpful, for example, if your storage vendor only supports certain cloning methods. It also allows you to select a method that limits resource usage or maximizes performance.

Cloning strategies can be specified by setting the cloneStrategy attribute in a storage profile to one of these values:

  • snapshot - This method is used by default when snapshots are configured. This cloning strategy uses a temporary volume snapshot to clone the volume. The storage provisioner must support CSI snapshots.

  • copy - This method uses a source pod and a target pod to copy data from the source volume to the target volume. Host-assisted cloning is the least efficient method of cloning.

  • csi-clone - This method uses the CSI clone API to efficiently clone an existing volume without using an interim volume snapshot. Unlike snapshot or copy, which are used by default if no storage profile is defined, CSI volume cloning is only used when you specify it in the StorageProfile object for the provisioner’s storage class.

You can also set clone strategies using the CLI without modifying the default claimPropertySets in your YAML spec section.

Example storage profile

  1. apiVersion: cdi.kubevirt.io/v1beta1
  2. kind: StorageProfile
  3. metadata:
  4.   name: <provisioner_class>
  5. #   ...
  6. spec:
  7.   claimPropertySets:
  8.   - accessModes:
  9.     - ReadWriteOnce (1)
  10.     volumeMode:
  11.       Filesystem (2)
  12.   cloneStrategy:
  13.   csi-clone (3)
  14. status:
  15.   provisioner: <provisioner>
  16.   storageClass: <provisioner_class>
1The accessModes that you select.
2The volumeMode that you select.
3The default cloning method of your choice. In this example, CSI volume cloning is specified.

Additional resources