Help

Consistency Group status
The Operational status column in the Consistency Groups view shows the overall status of the consistency group at both
clusters. If the status is the same at both clusters, that status displays in the Operational status column. If the status is not the
same at both clusters, the less than optimal status will display.
The following table lists and defines the consistency group operational states.
Operational status Definition
OK The consistency group is servicing I/O normally at both clusters.
Suspended I/O is suspended on the volumes in the group at one or both clusters.
Degraded I/O is continuing to the volumes, but there are problems at one or both clusters.
Unknown The status is unknown, likely because management connectivity is lost at one or
both clusters.
The following table lists and describes the status details that may appear when you click one of the status links in the previous
table.
Status detail Description
requires-resolve-conflicting-detach After the inter-cluster link is restored, two clusters have
discovered that they have detached one another and resumed
I/O independently. The clusters are continuing to service I/O
on their independent versions of the data. You must issue the
consistency-group resolve-conflicting-detach command in the CLI
to make the view of data consistent again at the clusters.
rebuilding-across-clusters One or more distributed member volumes is being rebuilt.
rebuilding-within-cluster One or more local rebuilds is in progress at this cluster.
requires-resume-after-data-loss-failure There have been at least two concurrent failures, and data has
been lost. This can happen when, for example, a director fails
shortly after the inter-cluster link fails, or when two directors fail
at almost the same time. You must issue the consistency-group
resume-after data-loss command in the CLI to select a winning
cluster and allow I/O to resume.
requires-resume-after-rollback A cluster has detached its peer cluster and rolled back the view
of data, but is waiting for you to issue the consistency-group
resume-after-rollback command in the CLI before resuming I/O.
cluster-departure Not all the visible clusters are in communication.
requires-resume-at-loser After the inter-cluster link is restored, a cluster that suspended
I/O during the outage has discovered that its peer was declared
the winner and resumed I/O. You must issue the consistency-
group resume-at-loser command to make the view of the data
consistent with the winner cluster, and to resume I/O at the loser
cluster.
unhealthy-devices I/O has stopped in this consistency group because one or more
volumes is unhealthy and cannot perform I/O.
will-rollback-on-link-down If a link failure occurs, the winner cluster will roll back the view of
the data in order to resume I/O. This status detail appears when
the static detach rule configured in detach-rule makes one of the
clusters in active-clusters a loser during a link failure.
104 Provisioning storage