OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

CSI automatic migration

In-tree storage drivers that are traditionally shipped with OpenShift Container Platform are being deprecated and replaced by their equivalent Container Storage Interface (CSI) drivers. OpenShift Container Platform provides automatic migration for in-tree volume plugins to their equivalent CSI drivers.

Overview

This feature automatically migrates volumes that were provisioned using in-tree storage plugins to their counterpart Container Storage Interface (CSI) drivers.

This process does not perform any data migration; OpenShift Container Platform only translates the persistent volume object in memory. As a result, the translated persistent volume object is not stored on disk, nor is its contents changed. CSI automatic migration should be seamless. This feature does not change how you use all existing API objects: for example, PersistentVolumes, PersistentVolumeClaims, and StorageClasses.

The following in-tree to CSI drivers are automatically migrated:

  • Azure Disk

  • OpenStack Cinder

  • Amazon Web Services (AWS) Elastic Block Storage (EBS)

  • Google Compute Engine Persistent Disk (GCP PD)

  • Azure File

  • VMware vSphere (see information below for specific migration behavior for vSphere)

CSI migration for these volume types is considered generally available (GA), and requires no manual intervention.

CSI automatic migration of in-tree persistent volumes (PVs) or persistent volume claims (PVCs) does not enable any new CSI driver features, such as snapshots or expansion, if the original in-tree storage plugin did not support it.

Storage class implications

For new OpenShift Container Platform 4.13, and later, installations, the default storage class is the CSI storage class. All volumes provisioned using this storage class are CSI persistent volumes (PVs).

For clusters upgraded from 4.12, and earlier, to 4.13, and later, the CSI storage class is created, and is set as the default if no default storage class was set prior to the upgrade. In the very unlikely case that there is a storage class with the same name, the existing storage class remains unchanged. Any existing in-tree storage classes remain, and might be necessary for certain features, such as volume expansion to work for existing in-tree PVs. While storage class referencing to the in-tree storage plugin will continue working, we recommend that you switch the default storage class to the CSI storage class.

To change the default storage class, see Changing the default storage class.

vSphere automatic migration

Migration includes significant consequences:

  • Enabling migration cannot be undone.

  • Migration can take a while to complete depending on how many nodes are on the cluster.

New installations of OpenShift Container Platform

For new installations of OpenShift Container Platform 4.13, or later, automatic migration is enabled by default.

Updating from OpenShift Container Platform 4.13 to 4.14

If you are using vSphere in-tree persistent volumes (PVs) and want to update from OpenShift Container Platform 4.13 to 4.14, first update vSphere vCenter and ESXI host to 7.0 Update 3L or 8.0 Update 2, otherwise the OpenShift Container Platform update is blocked. After updating vSphere, your OpenShift Container Platform update can occur and automatic Container Storage Interface (CSI) migration is enabled by default.

Alternatively, if you do not want to update vSphere, you can proceed with an OpenShift Container Platform update by performing an administrator acknowledgment:

oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.13-kube-127-vsphere-migration-in-4.14":"true"}}' --type=merge

If you do not update to vSphere 7.0 Update 3L or 8.0 Update 2 and use an administrator acknowledgment to update to OpenShift Container Platform 4.14, known issues can occur due to CSI migration being enabled by default in OpenShift Container Platform 4.14. Before proceeding with the administrator acknowledgement, carefully read this knowledge base article.

Updating from OpenShift Container Platform 4.12 to 4.13

If you are using vSphere in-tree persistent volumes (PVs) and want to update from OpenShift Container Platform 4.12 to 4.13, update vSphere vCenter and ESXI host to 7.0 Update 3L or 8.0 Update 2, otherwise the OpenShift Container Platform update is blocked. After updating vSphere, your OpenShift Container Platform update can occur and automatic Container Storage Interface (CSI) migration for vSphere only occurs if you opt in.

Alternatively, if you do not want to update vSphere, you can proceed with an OpenShift Container Platform update by running the following command to perform an administrator acknowledgment:

oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.12-kube-126-vsphere-migration-in-4.14":"true"}}' --type=merge

It is generally safe to provide the requested administrator acknowledgment for updates from OpenShift Container Platform 4.12 to 4.13 because CSI migration is not yet enabled for upgraded clusters from 4.12 to 4.13. However, Red Hat recommends that you start planning an update of your vSphere environment for a future update to 4.14, so that all the in-tree volumes can be managed by the CSI driver seamlessly.

If you do not update to OpenShift Container Platform 4.13.10, or later, and do not update vSphere, and then opt in to migration (see Using the web console to opt in to automatic CSI migration or Using the CLI to opt in to automatic CSI migration below), known issues can occur. Review the consequences listed above for migration before opting in and carefully read this knowledge base article.

Using the web console to opt in to automatic CSI migration

Prerequisites

  • Access to the OpenShift Container Platform web console.

  • Access to the cluster with cluster-admin privileges.

Procedure

To opt in to automatic CSI migration for vSphere:

  1. Log in to the web console.

  2. Click Administration → CustomResourceDefinitions.

  3. On the CustomResourceDefinitions page, type "Storage" to find the Storage custom resource (CR).

  4. Click the Storage CR.

  5. On the storages.operator.openshift.io page, click the Instances tab.

  6. Click the name of the desired instance, and then click the YAML tab.

  7. Set the spec.vsphereStorageDriver parameter to CSIWithMigrationDriver, as shown in the following example:

    ....
spec:
  logLevel: Normal
  managementState: Managed
  operatorLogLevel: Normal
  vsphereStorageDriver: CSIWithMigrationDriver (1)
...
    1 spec.vsphereStorageDriver parameter set to CSIWithMigrationDriver

  8. Click Save.

Using the CLI to opt in to automatic CSI migration

Prerequisites

  • Access to the cluster with cluster-admin privileges.

Procedure

To opt in to automatic CSI migration for vSphere, run the following command:

oc patch storage cluster --type=merge -p '{"spec":{"vsphereStorageDriver":"CSIWithMigrationDriver"}}'

You can determine when migration is complete by verifying that the VSphereMigrationControllerAvailable condition is set to "true" in the Storage object.