Configuring Global Cluster Membership (GCM)

Last published : Aug 26, 2026
With Global Cluster Membership (GCM), you can define membership of clusters for disaster recovery. The GCM CR must be configured and applied on all clusters. When configured, the Global Cluster Membership forms a logical notion called 'Global Cluster' with all underlying clusters as 'Member Clusters'. Member clusters are OpenShift clusters providing disaster recovery capabilities to application components.
To provide DR, these member clusters:
  • Send heartbeats with each other periodically.
  • Exchange information like state, configuration, operation.
  • Perform/participate in operation like migration.
Complete the following steps:
  1. Edit /infoscale-yamls-v9.2.1/DR/SampleGlobalClusterMembership.yaml as under:
    apiVersion: infoscale.veritas.com/v1
    kind: GlobalClusterMembership
    metadata:
      name: global-cluster-membership
    spec:
      \# Local cluster name in the global membership
      localClusterName: <Local cluster
                               where you want to apply this YAML>
      globalMemberClusters:
          \# Cluster ID of each member of global cluster membership
        -  clusterID: <A unique ID of the primary cluster>
          \# Address Used For Communicating With Peer Cluster's DR Controller
          drControllerAddress: "<Load balancer IP address or haproxy
                                                 of the local cluster>"
          \# Port used for DR controller
          drControllerPort: "<Load balancer port number>"
        -  clusterID: <A unique ID of the secondary cluster>
          drControllerAddress: "<Load balancer IP address or haproxy
                                                  of the DR site>"
          drControllerPort: "<Load balancer port number>"
      \# If heartbeat with peer cluster missed more than CounterMissTolerance
             times,then cluster will be moved to FAULTED state
      counterMissTolerance: 5
      globalClusterOperation: "none"
      \# Application metadata backup sync frequency to DR site(s) in minutes
      metadataBackupInterval: 15
      \# Refresh data replication status after specified minutes
      datarepRefreshStatusFrequency: 10
      \# Include cluster-scoped Custom Resource Definitions (CRDs)
      \#                          in disaster recovery plan backup
      backupClusterScopeCRD: true
      \# Maximum metadata backup copies stored per DR plan
      maximumMetadataCopies: 5
    Note: Do not enclose the parameter values in angle brackets(< >) . For example, if 8334 is the Load balancer port number; enter drControllerPort: "8334" for drControllerPort: <Load balancer port number>. localClusterName and clusterID can have maximum 20 characters.
  2. Run the following command on the bastion node of the source cluster:
    oc apply -f /infoscale-yamls-v9.2.1/DR/SampleGlobalClusterMembership.yaml
  3. Edit another instance of /infoscale-yamls-v9.2.1/DR/SampleGlobalClusterMembership.yaml to add DR site as under:
    apiVersion: infoscale.veritas.com/v1
    kind: GlobalClusterMembership
    metadata:
      name: global-cluster-membership
    spec:
      \# Local cluster name in the global membership
    localClusterName: <DR site cluster name
                          where you want to apply this YAML>

      globalMemberClusters:
      \# Cluster ID of each member of global cluster membership
      -  clusterID: <A unique ID of the primary cluster>
      \# Address Used For Communicating With Peer Cluster's DR Controller
        drControllerAddress: "<Load balancer IP address or haproxy
                                      of the local cluster>"

      \# Port used for DR controller
        drControllerPort: "\<Load balancer port number\>"
          -  clusterID: <A unique ID of the secondary cluster>
        drControllerAddress: "<Load balancer IP address or haproxy
        of the DR site>"
          drControllerPort: "\<Load balancer port number\>"
      \# If heartbeat with peer cluster missed more than CounterMissTolerance
      \# times, then cluster will be moved to FAULTED state
      counterMissTolerance: 5
      globalClusterOperation: "none"
      \# Application metadata backup sync frequency to DR site(s) in minutes
      metadataBackupInterval: 15
      \# Refresh data replication status after specified minutes
      datarepRefreshStatusFrequency: 10
      \# Include cluster-scoped Custom Resource Definitions (CRDs) in
      \# disaster recovery plan backup
      backupClusterScopeCRD: true
      \# Maximum metadata backup copies stored per DR plan
      maximumMetadataCopies: 5
  4. Copy this file to the DR site and Run the following command again on the bastion node of the DR site:
    oc apply -f /infoscale-yamls-v9.2.1/DR/SampleGlobalClusterMembership.yaml
  5. Manually verify on all clusters whether the GLOBALCLUSTERSTATE is DISCOVER_WAIT by running oc get gcm.
    Various states are as follows:
    State Description
    UNKNOWN A transient default Global-Cluster state. After initial configuration/setup, cluster state must transition to DISCOVER_WAIT. Prolonged UNKNOWN state indicates errors in initial configuration/setup. Review DR Controller log for the ongoing activities.
    DISCOVER_WAIT Although local cluster has a copy of GCM and member cluster details, it is not certain whether local copy of GCM and member cluster is up-to-date. If GCM and member cluster details are identical on all peer clusters then all clusters automatically transition to RUNNING state. If the details are not identical, waits till you seed the cluster by updating GlobalClusterOperation to localbuild . When a member cluster transitions to RUNNING state, all peer clusters with identical membership transition to RUNNING state.
    ADMIN_WAIT If local membership definition does not match with peer cluster's membership definition, clusters transition to this state. Update membership on peer clusters and ensure that it is identical. Peer clusters then transition to RUNNING state.
    RUNNING Cluster transitions to RUNNING state if you seed cluster membership by updating GlobalClusterOperation to localbuild . Cluster transitions to RUNNING state even when local copy of membership matches with peer clusters.
    EXITING You have initiated DR Controller stop.
    EXITED DR Controller stopped.
  6. To verify whether the Global Cluster is successfully created, run the following command on the bastion node:
    oc get gcm
  7. Review the cluster names, GlobalClusterState, and PeerLinkState in the output similar to the following. GlobalClusterState must be Running and PeerLinkState must be Connected.
    NAME                      CLUSTER NAME   CLUSTER STATE   PROTOCOL
    global-cluster-membership Clus1          RUNNING         10

    PEER LINK STATE
    {"Clus1":"CONNECTED","Clus2":"CONNECTED"}
    Here, NAME is the Name of GlobalClusterMembership custom resource, CLUSTER NAME is the Local Cluster ID, and Clus1, Clus2 are the Cluster IDs that you defined for global membership.

Viewing and validating DR cluster annotations from GCM

To retrieve all DR cluster-info annotations, run the following command:
oc describe gcm -A

Compatibility warnings on mismatch

When you create a DataReplication, the operator compares the machine type and persistentReservation feature gate between the primary and peer clusters (from the GCM annotations above). If either differs, the DataReplication is still created, but a warning reports the mismatch, each cluster's value, and where to fix it.
$ oc create -f sample_datarep.yaml
 Warning: DataReplication compatibility warning: machineType differs between clusters
  (Clus1="pc-q35-rhel9.6.0", Clus2="pc-q35-rhel9.4.0"); VM migration may fail if machine
  types are incompatible. Check KubeVirt machine type settings on both clusters
  (KubeVirt CR / kubevirt-config ConfigMap). Creation is allowed.
 Warning: DataReplication compatibility warning: persistentReservation feature gate differs
  between clusters (Clus1="false", Clus2="true"); storage behavior may differ during
  failover/takeover. Check the HyperConverged CR feature gate "persistentReservation" on
  both clusters. Creation is allowed.
Note: The name datareplication-vmpool is an example; your output will show the name specified in your DataReplication YAML.
  • machineType mismatch: The VM may fail to start after migrating to a cluster using a different machine type. Fix: Align the machine type on both clusters via the KubeVirt CR or kubevirt-config ConfigMap. A stale machine type usually indicates the cluster needs an upgrade; upgrade the OpenShift version or OCP-V operator as required, then restart the affected VMs.
  • persistentReservation mismatch: Storage may behave differently during failover or takeover. Fix: Set the persistentReservation feature gate to the same value on both clusters.
Important: Warnings are advisory only; they do not block resource creation and appear regardless of which cluster runs the creation command. Resolve any mismatches before relying on VM migration or takeover.
How to read the annotations
  • Local key format: dr.infoscale/local.<clusterID>.<field>
  • Peer key format: dr.infoscale/peer.<clusterID>.<field>
Key fields tracked by GCM
  • ocpVersion
  • ikeVersion
  • kubevirtCR
  • kubevirtMachineType
  • persistentReservation
    Understanding values for Machine Type and Persistent Reservation.
    The system determines these values based on the presence of KubeVirt:
KubeVirt is not present
  • kubevirtCR=absent
  • kubevirtMachineType=absent
  • persistentReservation=absent
KubeVirt is present and values are detected
  • kubevirtMachineType displays a concrete value.
  • persistentReservation is explicitly set (for example, true or false).
KubeVirt is present but values cannot be fully detected
kubevirtMachineType=unknown and/or persistentReservation=unknown. The unknown status means the platform could not fully validate the field yet. It is not a hard failure, but it should be reviewed before production DR operations.

Consistency guidelines

Matching your environment configurations between local and peer sites ensures reliable failovers and migrations.
  • Matching kubevirtMachineType across sites reduces VM migration risk.
  • Matching persistentReservation settings reduces failover/takeover behavior differences.
  • If values do not match, operations may still proceed, but with compatibility risk.
  • If values are unknown or missing, validation is incomplete and should be reviewed before production DR operations.
Use the checklist below to assess your readiness:
Status Conditions
Recommended - Local and peer kubevirtMachineType values match exactly.- Local and peer persistentReservation values match exactly.
Needs attention - Any mismatch between local and peer kubevirtMachineType values.- Any mismatch between local and peer persistentReservation values.- Any values listed as missing or unknown.
Example:
oc get gcm global-cluster-membership -o json | jq -r '.metadata.annotations | to_entries[] | select(.key | test("kubevirtMachineType|persistentReservation")) | "\(.key) = \(.value)"'
Output
dr.infoscale/local.Clus2.kubevirtMachineType = pc-q35-rhel9.6.0
dr.infoscale/local.Clus2.persistentReservation = true
dr.infoscale/peer.Clus1.kubevirtMachineType = pc-q35-rhel9.4.0
dr.infoscale/peer.Clus1.persistentReservation = false
Warning: This warning may persist temporarily even after PersistentReservation gate values and machineType values are set correctly, because GCM annotations are not updated immediately — they refresh periodically. Use the following OpenShift commands to independently verify the values before proceeding with migration.

Configuring DR manager log verbosity

Starting with IKE 9.2, the InfoScale DR Manager Velero SDK log level defaults to warn instead of info. This significantly reduces log volume in environments with multiple DR plans.
To temporarily enable debug logging for troubleshooting:
oc annotate gcm <gcm-name> infoscale.veritas.com/log-level=debug --overwrite
To revert back to the default warn level:
oc annotate gcm <gcm-name> infoscale.veritas.com/log-level=warn --overwrite
The DR Manager applies the annotation change within seconds during the next GCM reconciliation.
When to use debug logging
  • Backup or restore operations are failing without clear error messages.
  • Technical Support requests verbose Velero SDK logs for a case.