ApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 7. Known issues

This section describes the known issues in Red Hat OpenShift Data Foundation 4.22.

7.1. Disaster recovery
Copiar enlace

  • DRCluster validation can fail after upgrading to 4.22 when configured CIDRs are not detected by CSINodeAddons

    In 4.22, CIDR validation for MDR fencing has been enhanced. The CIDRs configured in DRCluster.Spec.CIDRs are now validated against the CIDRs reported by CSINodeAddons on the cluster. As a result, any CIDRs that are not detected by CSINodeAddons cause DRCluster validation to fail with the following condition: 

    DRClusterValidated: False — undetected CIDRs specified <cidr1>, <cidr2>

    CSINodeAddons reports the node IPs that are visible to the storage cluster. If DRCluster.Spec.CIDRs was configured by collecting CIDRs from all cluster nodes before upgrading, control plane node CIDRs might be present in the configuration. Because control plane nodes are typically not part of the storage network, their IPs are not reported by CSINodeAddons and can cause validation to fail after upgrading to 4.22.

    Workaround: Verify that the CIDRs configured in DRCluster.Spec.CIDRs match the CIDRs detected by the cluster, either before or after upgrading to 4.22. Post-upgrade verification is recommended because the detected CIDRs are available directly.

    Before upgrading to 4.22:

    • Verify the CIDRs configured in DRCluster.Spec.CIDRs against the schedulable nodes on the managed cluster.
    • Include worker nodes and any schedulable control plane nodes in the verification.
    • Correct any mismatches before upgrading.

    • Because CIDR detection is not available in 4.21, post-upgrade validation is still recommended.

      After upgrading to 4.22 (recommended):

    • Compare the detected CIDRs with the values configured in DRCluster.Spec.CIDRs and correct any mismatches.

    • Verify that the DRClusterValidated condition reports Status: True.

      For instructions on retrieving detected CIDRs and updating the DRCluster configuration, see Configure DRClusters for fencing automation.

      (DFBUGS-8068)

  • VolSync synchronization fails for applications that use PVC subPath mounts in a Regional Disaster Recovery configuration

    When an application resource, such as a Deployment or StatefulSet, mounts a persistent volume claim (PVC) using the subPath option, Security Context Constraints (SCC) permissions are applied only to the specified subdirectory and not to the root of the PVC.

    VolSync requires the appropriate SCC permissions at the PVC root directory when synchronizing CephFS data. As a result, VolSync can encounter permission-related errors during synchronization operations.

    When Disaster Recovery protection is enabled for affected applications, VolSync synchronization might fail and report errors similar to the following: 

    rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1327) [sender=3.2.5]

2026.05.13 18:26:36 Synchronization failed. Retrying in 16 seconds. Retry 4/5.

rsync: [sender] opendir "/data/." failed: Permission denied (13)

    Workaround: If VolSync synchronization fails because the application uses a PVC mounted with subPath, perform the following steps:

    1. Create a Job that mounts the affected PVC and wait for the Job to complete successfully. 

      apiVersion: batch/v1
kind: Job
metadata:
  name: pvc-1-job
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: relabel
        image: registry.access.redhat.com/ubi9/ubi-minimal:latest
        command:
        - /bin/sh
        - -c
        - sleep 30
        volumeMounts:
        - name: data-volume
          mountPath: /data
      volumes:
      - name: data-volume
        persistentVolumeClaim:
          claimName: pvc-1

    2. Delete the associated VolumeGroupSnapshot resource: 

      $ oc get -n <namespace> volumegroupsnapshots.groupsnapshot.storage.openshift.io
$ oc delete -n <namespace> volumegroupsnapshots.groupsnapshot.storage.openshift.io <volumegroupsnapshotName>

    3. Delete the VolumeSnapshot PVC, if present: 

      $ oc -n <namespace> delete pvc vs-pvc-1 --ignore-not-found --wait=false

    4. Delete the VolSync Job: 

      $ oc -n <namespace> delete job volsync-rsync-tls-src-pvc-1 --ignore-not-found

      Result: During the next scheduled synchronization interval, VolSync successfully synchronizes the PVCs and persistent volumes that match the configured labelSelector values.

      (DFBUGS-6889)

  • UI cleanup message identifies the wrong cluster after aborting a discovered application dryRun test failover

    When a dryRun test failover for a discovered application is aborted, the failoverCluster field is removed from the DRPlacementControl (DRPC) specification while the DRPC status.phase remains FailedOver. The UI derives the cleanup target cluster by finding the complement of the primary cluster, but since getPrimaryClusterName() returns undefined (due to missing spec.failoverCluster), the cluster lookup defaults to the first cluster in the DRPolicy - which may be the original primary cluster instead of the actual failover target.

    As a result, the UI cleanup message incorrectly directs the user to delete application resources from the original primary cluster instead of the failover target cluster where the dryRun workload was deployed. Acting on this incorrect guidance could result in deleting the production workload.

    Workaround: Ignore the cluster name displayed in the UI cleanup message. Instead, identify the failover target cluster to which the dryRun test failover was triggered and delete the application resources from that cluster.

    Result: After cleaning up the workload from the correct failover target cluster, the application will remain running only on the original primary managed cluster and data replication will resume, restoring the DR state for the application.

    (DFBUGS-7998)

  • UI does not reflect DRPC progression updates during ApplicationSet dryRun test failover abort

    When a dryRun test failover for an ApplicationSet workload is aborted, the DRPC progression correctly transitions through Cleaning Up and then Completed. However, the user interface does not recognize or display these progression updates during the abort workflow.

    As a result, the UI continues to display a stale state, such as TestingFailover or FailedOver, instead of the actual DRPC progression. This can give users an inaccurate view of the dryRun abort and cleanup status.

    Workaround: Verify the actual DRPC progression by using the command line instead of relying on the UI status. For example, run oc get drpc <name> -n <namespace> -o yaml and review the DRPC progression details to confirm that the abort and cleanup have completed successfully.

    Result: After the dryRun abort completes and the DRPC progression reaches Completed, the workload is removed from the failover cluster and normal disaster recovery protection resumes on the primary managed cluster.

    (DFBUGS-8070)

  • CephFS VolSync PVCs can get stuck during disable DR

    During disable DR for CephFS workloads protected by VolSync, Ramen deletes ReplicationSource (and related replication-group) objects without first removing their owner references from the PVCs, even when the disable-DR workflow requests that PVCs be preserved (do-not-delete-pvc). Kubernetes then marks the PVCs for deletion.

    As a result, PersistentVolumeClaims can remain stuck in a Terminating state instead of staying Bound. Disable DR does not complete cleanly for affected CephFS deployments, and workloads might continue running while storage is left in an inconsistent lifecycle state.

    Workaround: Do not disable DR for CephFS VolSync workloads until a fix is available.

    If PVCs are already stuck in a Terminating state, recovery requires manual intervention and is not suitable for customer self-service. One manual recovery method is to use kubectl patch to remove the ReplicationSource and ReplicationDestination owner references from the PVCs during the disable-DR operation.

    (DFBUGS-8196)

  • Ramen fails to detect updated SSL certificates for S3 connections

    After an SSL certificate rotation on the S3 service, Ramen might not automatically detect newly added SSL certificates in the hub cluster. The Ramen pod continues to use the certificates that were loaded during startup, which can cause S3 connections to newly added clusters to fail.

    This issue might surface as errors such as: 

    failed to list objects in bucket: code: RequestError, message: send request failed

    Note that this error can occur due to various connection or access issues and should not always be interpreted as an SSL certificate problem.

    Workaround: Manually restart the Ramen pod on the hub cluster to trigger reinitialization of the S3 connections. This process allows Ramen to load and use the updated SSL certificates.

    If you are using managed clusters:

  • Update the certificates in the managedClusters configuration.

  • Manually restart the Ramen pods in the managed clusters after the certificate rotation is complete.

    (DFBUGS-2520)

  • CephBlockPoolRadosNamespace remains in Progressing state for custom CephBlockPools in an RDR configuration

    When a custom CephBlockPool is created on a cluster configured for Regional Disaster Recovery (RDR), the automatically created CephBlockPoolRadosNamespace resource (<pool-name>-builtin-implicit) can remain in the Progressing state indefinitely. This occurs because the MirroringController in the ocs-operator cannot enable mirroring on the CephBlockPool when the peer cluster bootstrap token is not yet available.

    As a result, mirroring is not enabled on the CephBlockPool and the associated CephBlockPoolRadosNamespace does not transition to a healthy state.

    Workaround: If the CephBlockPoolRadosNamespace remains in the Progressing state and mirroring is not enabled on the CephBlockPool, restart the ocs-operator pod.

    Result: After the ocs-operator restarts, mirroring is enabled successfully on the CephBlockPool and the CephBlockPoolRadosNamespace transitions out of the Progressing state.

    (DFBUGS-7981)

  • DRPCs protect all persistent volume claims created on the same namespace

    The namespaces that host multiple disaster recovery (DR) protected workloads protect all the persistent volume claims (PVCs) within the namespace for each DRPlacementControl resource in the same namespace on the hub cluster that does not specify and isolate PVCs based on the workload using its spec.pvcSelector field.

    This results in PVCs that match the DRPlacementControl spec.pvcSelector across multiple workloads. Or, if the selector is missing across all workloads, replication management to potentially manage each PVC multiple times and cause data corruption or invalid operations based on individual DRPlacementControl actions.

    Workaround: Label PVCs that belong to a workload uniquely, and use the selected label as the DRPlacementControl spec.pvcSelector to disambiguate which DRPlacementControl protects and manages which subset of PVCs within a namespace. It is not possible to specify the spec.pvcSelector field for the DRPlacementControl using the user interface, hence the DRPlacementControl for such applications must be deleted and created using the command line.

    Result: PVCs are no longer managed by multiple DRPlacementControl resources and do not cause any operation and data inconsistencies.

    (DFBUGS-1749)

  • Disabled PeerReady flag prevents changing the action to Failover

    The DR controller executes full reconciliation as and when needed. When a cluster becomes inaccessible, the DR controller performs a sanity check. If the workload is already relocated, this sanity check causes the PeerReady flag associated with the workload to be disabled, and the sanity check does not complete due to the cluster being offline. As a result, the disabled PeerReady flag prevents you from changing the action to Failover.

    Workaround: Use the command-line interface to change the DR action to Failover despite the disabled PeerReady flag.

    (DFBUGS-665)

  • For discovered apps with CephFS, sync stop after failover

    For CephFS-based workloads, synchronization of discovered applications may stop at some point after a failover or relocation. This can occur with a Permission Denied error reported in the ReplicationSource status.

    Workaround:

    • For Non-Discovered Applications

      • Delete the VolumeSnapshot: 

        $ oc delete volumesnapshot -n <vrg-namespace> <volumesnapshot-name>

        The snapshot name usually starts with the PVC name followed by a timestamp.

      • Delete the VolSync Job: 

        $ oc delete job -n <vrg-namespace> <pvc-name>

        The job name matches the PVC name.

    • For Discovered Applications

      Use the same steps as above, except <namespace> refers to the application workload namespace, not the VRG namespace.

    • For Workloads Using Consistency Groups

      • Delete the ReplicationGroupSource: 

        $ oc delete replicationgroupsource -n <namespace> <name>

      • Delete All VolSync Jobs in that Namespace: 

        $ oc delete jobs --all -n <namespace>

        In this case, <namespace> refers to the namespace of the workload (either discovered or not), and <name> refers to the name of the ReplicationGroupSource resource.

        (DFBUGS-2883)

  • DRPC progression completes without workload cleanup when aborting a CephFS dryRun test failover

    For a CephFS discovered application that is in the Deployed state before a dryRun test failover is triggered, aborting the dryRun can cause the DRPlacementControl (DRPC) progression to transition from TestingFailover to Completed even though the workload has not been cleaned up from the failover cluster (test cluster).

    This results in the CephFS discovered application continuing to run on both managed clusters simultaneously, which is not a desirable state and can leave the application’s disaster recovery state inconsistent.

    Workaround: Delete the application from the failover cluster (test cluster) where the dryRun test failover was triggered.

    Result: After the application is successfully removed from the failover cluster, the workload continues running only on the primary managed cluster. Data replication resumes after the cleanup is completed, and the application’s disaster recovery state is restored.

    (DFBUGS-8115)

  • Submariner enters a Degraded state in Regional DR deployments with ACM 2.16 or 2.17

    In Regional Disaster Recovery (RDR) deployments using Red Hat Advanced Cluster Management (ACM) 2.16 or 2.17 with Submariner 0.23 or 0.24, Submariner enters a Degraded state after deployment. This prevents cross-cluster communication required for RDR and makes failover and relocate operations non-functional. Both CephFS and RBD workload types are affected.

    Workaround: There is currently no workaround. Wait for the fix to be delivered in upcoming ACM 2.17.z and 2.16.z releases. Do not deploy new RDR setups with the affected component versions until the fix is available. If you are planning an RDR deployment, verify that your ACM version includes the fix for ACM-40464 before proceeding.

    (ACM-40464)

7.2. Multicloud Object Gateway
Copiar enlace

  • Unable to create new OBCs using Multicloud Object Gateway

    When provisioning an NSFS bucket via ObjectBucketClaim (OBC), the default filesystem path is expected to use the bucket name. However, if path is set in OBC.Spec.AdditionalConfig, it should take precedence. This behavior is currently inconsistent, resulting in failures when creating new OBCs.

    (DFBUGS-3817)

7.3. Ceph
Copiar enlace

  • RHCS 9.1z1 is not compatible with ODF 4.22.0

    Customers running ODF 4.22.0 in external mode should not deploy or upgrade to RHCS 9.1z1 due to an incompatibility issue. A fix will be provided in ODF 4.22.z.

  • OSD pods restart during add capacity

    OSD pods restart after performing cluster expansion by adding capacity to the cluster. However, no impact to the cluster is observed apart from pod restarting.

    (DFBUGS-1426)

  • SELinux relabelling issue with a very high number of files

    When attaching volumes to pods in Red Hat OpenShift Container Platform, the pods sometimes do not start or take an excessive amount of time to start. This behavior is generic and it is tied to how SELinux relabelling is handled by Kubelet. This issue is observed with any filesystem based volumes having very high file counts. In OpenShift Data Foundation, the issue is seen when using CephFS based volumes with a very high number of files. There are multiple ways to work around this issue. Depending on your business needs you can choose one of the workarounds from the knowledgebase solution https://access.redhat.com/solutions/6221251.

    (RFE-3327)

7.4. OpenShift Data Foundation console
Copiar enlace

  • UI shows WaitOnUserCleanUp even when automatic cleanup is enabled

    The UI incorrectly displays the WaitOnUserCleanUp status even when automatic cleanup is enabled for VMs. This occurs because the UI relies only on the phase and progression fields of the DRPlacementControl to determine cleanup behavior and does not evaluate the more granular AutoCleanup condition that explicitly indicates automatic cleanup.

    Workaround: There is no manual workaround required. This state is transient and clears automatically once the progression field advances to Completed. Manual cleanup should be avoided unless the AutoCleanup condition and its corresponding reason in the DRPlacementControl or VRG status indicate otherwise.

    During automatic cleanup, the UI may briefly present a misleading status, which can cause temporary confusion until the cleanup completes.

    (DFBUGS-5824)

  • DRPlacementControl shows ProtectionError even after successful relocation

    When a relocation completes, the DRPlacementControl may continue to display a ProtectionError status. This occurs because the Protected condition in the DRPlacementControl status incorrectly reports an Error state, even though the relocation has finished (phase: Relocated, progression: Completed).

    Workaround: No direct workaround is available. Wait until retrying the NoClusterDataConflict condition is met.

    The DR status in the UI remains in the ProtectionError state until the data conflict is resolved.

    (DFBUGS-5823)

7.5. Upgrade
Copiar enlace

  • Upgrade failures to 4.22.z

    When upgrading from OpenShift Data Foundation version 4.21.z to 4.22, you must upgrade to OpenShift Data Foundation 4.22.2 or later versions. Upgrades to OpenShift Data Foundation 4.22.0 or 4.22.1 are not supported and will fail.

Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Legal Notice

Theme

© 2026 Red HatVolver arriba