PowerMaxOS: How to Set SRDF Metro Preference for Witness Protected Groups

Summary: How to set SRDF or Metro preference for Witness protected groups.

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

You can change the indicated preference site when using a witness for an SRDF/Metro Group that is Active and has a Configured Type of Witness. The preference, or "winning" side is represented as R1 and the nonpreference, or "loser" side is represented as R2. The symrdfcommand provides a set preference R1 | R2 option that changes the preference site to be used as part of the decision made by the witness when determining the site which remains host accessible on a failure. The preference is set at the SRDF or Metro group level.

The following is required to use this feature:

  • Both Arrays are PowerMaxOS 5978.711 (and later)
  • Management control is Solutions Enabler 10.x and or Unisphere for PowerMax 10.x (and later)

SYMCLI example:

symrdf -sid 001 -sg rdfg1_SG -rdfg 1 set preference R2

Unisphere for PowerMax example:

Array SID > Storage > Storage Groups > rdfg1_SG > Set Metro Preference
Or 
Array SID > Dashboard > Replication Dashboard > SRDF/Metro Storage Groups > rdfg1_SG > Set Metro Preference

Additional Information

NOTE: When Metro is configured to use a witness, the role of the witness is to determine which side of the Metro session is the best choice to remain accessible to the host if there is a failure. The devices on the side which is chosen to remain accessible to the host, are reported as R1 devices and the other side devices are reported as R2 devices. The choice which the witness makes may not align with the preference the user chooses. The reason the choice may not align is that when both sides run PowerMaxOS (5978 and later), SRDF/Metro considers extra factors to determine and select the preferred winner.
 
NOTE: The extra factors are Enginuity code dependent, see the "Determining the preferred winner" section from the relevant "Dell SRDF/Metro vWitness Configuration Guide" available on Dell Support.
 

The two Array sides regularly repeat this selection process for each SRDF/Metro group to ensure that the winning side remains the side that is most preferable. The winning side may change during the SRDF/Metro session. SRDF/Metro always reports the winning side as the R1 device and the losing side as R2. So each switch in the winning side causes an apparent swap of the R1 and R2 personalities in the session.

The assessment of the winning side and the losing side occurs separately for each SRDF/Metro group that exists between two arrays. On a particular array, some devices could be R1 devices while others are R2 devices. Which are R1 and which are R2 depends on the outcome of assessing their respective SRDF/Metro groups.

In summary, after setting the preference of a SRDF/Metro group to one side (Array A), if the other side (Array B) has one of the factors that determine preference that Array A does not, then preference is assigned to Array B.

To explain this further, consider the following example:

  • Array A has RDFG 100 devices as R1, Array B has RDFG 100 devices as R2.
  • Array A has RDFG 100 devices in a Masking View whose frontend ports are Online and Fabric Switch attached.
  • Array B has RDFG 100 devices unassigned, meaning not in any Masking View so not available on any Front-End Port.

The below command returns "The device is already in the requested state."

symrdf -sid Array A -sg <sg> set preference R2

And in the symapi.log, the command returns "The device is already in the requested state."

sg <sg>: Set type Preference R2

Since Array A has host connectivity for RDFG 100 devices, and Array B does not have host connectivity for RDFG 100 devices, then Array A remains as the preferred winner (R1) as the two arrays for RDFG 100 differ on the "host connectivity" factor.

The set preference option is only allowed for an Active SRDF/Metro group that has a Configured Type of Witness. An Active SRDF/Metro group can have different Pairstate and Witness Status combinations. Using a naming convention of <Pairstate>, <Configured Type>, <Effective Type>, and <Witness Status> to represent the combinations:

  • Pairstate AA is ActiveActive, and AB is ActiveBias
  • Configured Type W is Witness
  • Effective Type W is Witness, and B is Bias
  • Witness Status N is Normal, D is Degraded, and F is Failed
The following table informs the combination status after a preference change:
 
 Current Status
 Status after set preference change
 AA - W - W - N AA - W - W - N
 AA - W - W - D
AB - W - B - F
 AB - W - B - F
AB - W - B - F

Affected Products

PowerMaxOS 10
Article Properties
Article Number: 000209777
Article Type: How To
Last Modified: 16 مايو 2026
Version:  8
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.