Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 13. Configure storage

Configure storage for OpenShift Dev Spaces workspaces, including storage classes, strategies, and sizes.

13.1. Workspace storage requirements
リンクのコピー

OpenShift Dev Spaces workspaces store project files in a hierarchical directory structure and require specific storage capabilities depending on the selected strategy.

All workspace storage must use volumeMode: FileSystem.

The per-user storage strategy shares a single Persistent Volume Claim (PVC) across all of a user’s workspaces. This requires ReadWriteMany (RWX) access mode so that multiple workspace pods can mount the same volume simultaneously.

13.1.1. Choosing a storage backend for the Per-User strategy
リンクのコピー

Generic NFS provisioning supports RWX access but has two operational limitations:

  • Quota enforcement: Kubernetes PVCs cannot reliably enforce storage quotas on generic NFS volumes. A single workspace can exceed its allocation and consume the entire shared volume, causing instability for all users on that node.
  • Data integrity: Generic NFS implementations often lack the locking and cache coherency required when multiple cluster nodes access the same volume concurrently.

To avoid these issues, use a certified clustered or managed storage solution with a CSI driver that enforces quota limits and provides high-performance RWX file access. Most cloud providers offer suitable CSI drivers, and community-supported distributed storage projects are also available.

13.2. Configure storage classes
リンクのコピー

To configure OpenShift Dev Spaces to use a configured infrastructure storage, install OpenShift Dev Spaces using storage classes. This is especially useful when you want to bind a persistent volume provided by a non-default provisioner.

OpenShift Dev Spaces has one component that requires persistent volumes to store data:

  • A OpenShift Dev Spaces workspace. OpenShift Dev Spaces workspaces store source code using volumes, for example /projects volume.
Note

OpenShift Dev Spaces workspaces source code is stored in the persistent volume only if a workspace is not ephemeral.

Persistent volume claims facts:

  • OpenShift Dev Spaces does not create persistent volumes in the infrastructure.
  • OpenShift Dev Spaces uses persistent volume claims (PVC) to mount persistent volumes.
  • The Dev Workspace operator creates persistent volume claims.

Define a storage class name in the OpenShift Dev Spaces configuration to use the storage classes feature in the OpenShift Dev Spaces PVC.

Use CheCluster Custom Resource definition to define storage classes:

Prerequisites

Procedure

  1. Define storage class names: configure the CheCluster Custom Resource, and install OpenShift Dev Spaces. See Section 5.2, “Use dsc to configure the CheCluster Custom Resource during installation”. 

    spec:
  devEnvironments:
    storage:
      perUserStrategyPvcConfig:
        claimSize: <claim_size>
        storageClass: <storage_class_name>
      perWorkspaceStrategyPvcConfig:
        claimSize: <claim_size>
        storageClass: <storage_class_name>
      pvcStrategy: <pvc_strategy>

    where:

    claimSize
    Persistent Volume Claim size.
    storageClass
    Storage class for the Persistent Volume Claim. When omitted or left blank, a default storage class is used.
    pvcStrategy

    Persistent volume claim strategy. The supported strategies are:

    • per-user: All workspaces Persistent Volume Claims share one volume.
    • per-workspace: Each workspace gets its own individual Persistent Volume Claim.
    • ephemeral: Non-persistent storage. Local changes are lost when the workspace stops.

Verification

  • Start a workspace and verify that the PersistentVolumeClaim uses the configured storage class: 

    oc get pvc -n <user_namespace> -o jsonpath='{.items[*].spec.storageClassName}'

13.3. Configure the storage strategy
リンクのコピー

Configure OpenShift Dev Spaces to provide persistent or non-persistent storage to workspaces by selecting a storage strategy. The selected strategy applies to all newly created workspaces by default.

Available storage strategies:

  • per-user: Use a single PVC for all workspaces created by a user.
  • per-workspace: Each workspace gets its own PVC.
  • ephemeral: Non-persistent storage; any local changes are lost when the workspace is stopped.

The default storage strategy used in OpenShift Dev Spaces is per-user.

Prerequisites

Procedure

  1. Set the pvcStrategy field in the CheCluster Custom Resource to per-user, per-workspace, or ephemeral: 

    spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: 'per-user'

    where:

    pvcStrategy

    The available storage strategies are per-user, per-workspace, and ephemeral.

    Note

Verification

  • Verify the pvcStrategy value in the CheCluster Custom Resource: 

    oc get checluster devspaces -n openshift-devspaces -o jsonpath='{.spec.devEnvironments.storage.pvc.pvcStrategy}'

13.4. Configure storage sizes
リンクのコピー

Configure the persistent volume claim (PVC) size for the per-user or per-workspace storage strategy by setting the claimSize field in the CheCluster Custom Resource. Specify PVC sizes as a Kubernetes resource quantity.

Default persistent volume claim sizes: 

  • per-user: 10Gi
     

  • per-workspace: 5Gi

Prerequisites

Procedure

  1. Set the appropriate claimSize field for the desired storage strategy in the CheCluster Custom Resource.

    Note
    spec:
  devEnvironments:
    storage:
      pvc:
        pvcStrategy: '<strategy_name>'
        perUserStrategyPvcConfig:
          claimSize: <resource_quantity>
        perWorkspaceStrategyPvcConfig:
          claimSize: <resource_quantity>

    where:

    <strategy_name>
    Select the storage strategy: per-user or per-workspace or ephemeral. Note: the ephemeral storage strategy does not use persistent storage, therefore you cannot configure its storage size or other PVC-related attributes.
    perUserStrategyPvcConfig, perWorkspaceStrategyPvcConfig
    Specify a claim size on the next line or omit the next line to set the default claim size value. The specified claim size is only used when you select this storage strategy.
    <resource_quantity>

    The claim size must be specified as a Kubernetes resource quantity. The available quantity units include: Ei, Pi, Ti, Gi, Mi and Ki.

    Important

    Manually modifying a PVC on the cluster that was provisioned by OpenShift Dev Spaces is not officially supported and may result in unexpected consequences.

    If you want to resize a PVC that is in use by a workspace, you must restart the workspace for the PVC change to occur.

Verification

  • Start a workspace and verify that the PersistentVolumeClaim has the configured size: 

    oc get pvc -n <user_namespace> -o jsonpath='{.items[*].spec.resources.requests.storage}'

13.5. Persistent user home
リンクのコピー

Red Hat OpenShift Dev Spaces provides a persistent home directory feature that preserves the /home/user directory across workspace restarts. User settings, shell history, and tooling configurations persist between sessions.

You can enable this feature in the CheCluster by setting spec.devEnvironments.persistUserHome.enabled to true.

For newly started workspaces, this feature creates a PVC mounted to the /home/user path of the tools container. In this documentation, a "tools container" refers to the first container in the devfile. This container is the container that includes the project source code by default.

When the PVC is mounted for the first time, the persistent volume’s contents are empty and therefore must be populated with the /home/user directory content.

By default, the persistUserHome feature creates an init container for each new workspace pod named init-persistent-home. This init container is created with the tools container image. It runs a stow command to create symbolic links in the persistent volume to populate the /home/user directory.

Note

For files that cannot be symbolically linked to the /home/user directory such as the .viminfo and .bashrc file, cp is used instead of stow.

The primary function of the stow command is to run: 

stow -t /home/user/ -d /home/tooling/ --no-folding

The stow command creates symbolic links in /home/user for files and directories located in /home/tooling. This populates the persistent volume with symbolic links to the content in /home/tooling. As a result, the persistUserHome feature expects the tooling image to have its /home/user/ content within /home/tooling.

For example, the tools container image might contain files in the home/tooling directory such as .config and .config-folder/another-file. In this case, stow creates symbolic links in the persistent volume as shown in the following diagram:

Figure 13.1. Tools container with persistUserHome enabled

Persistent user home example scenario

The init container writes the output of the stow command to /home/user/.stow.log and only runs stow the first time the persistent volume is mounted to the workspace.

Using the stow command to populate /home/user content in the persistent volume provides two main advantages:

  1. Creating symbolic links is faster and consumes less storage than creating copies of the /home/user directory content in the persistent volume. To put it differently, the persistent volume in this case contains symbolic links and not the actual files themselves.
  2. If the tools image is updated with newer versions of existing binaries, configs, and files, the init container does not need to stow the new versions. The existing symbolic links already point to the updated content in /home/tooling.
Note

If the tooling image is updated with additional binaries or files, they are not symbolically linked to the /home/user directory since the stow command does not run again. In this case, the user must delete the /home/user/.stow_completed file and restart the workspace to rerun stow.

13.5.1. persistUserHome tools image requirements
リンクのコピー

The persistUserHome feature depends on the tools image used for the workspace. By default OpenShift Dev Spaces uses the Universal Developer Image (UDI) for sample workspaces, which supports persistUserHome out of the box.

If you are using a custom image, it must meet three requirements to support the persistUserHome feature.

  1. The tools image should contain stow version >= 2.4.0.
  2. The $HOME environment variable is set to /home/user.
  3. In the tools image, the directory that is intended to contain the /home/user content is /home/tooling.

Because the /home/user content must be in /home/tooling, the default UDI image adds the /home/user content to /home/tooling instead, and runs: 

RUN stow -t /home/user/ -d /home/tooling/ --no-folding

in the Dockerfile so that files in /home/tooling are accessible from /home/user even when not using the persistUserHome feature.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る