SRM with stretched storage problems: Reprotect warning - missing initiators

[yatigammanabnd]

So we have had partial success with testing out a stretched storage SRM pair, but never full success. We are at a loss for ideas now, so I'm hoping someone here in the community might recognise one or many of these problems we've seen and may know how to resolve them.

I've split our problems into 3 posts so not to end up with crossed wires! I'll link to the others at the bottom.

Problem:

Reprotect will output warnings on an otherwise successful Reprotect

> "Warning: Stretched device group 'xxx-yyy-zzz' may not be accessible on one or more recovery site ESX hosts due to missing initiators. Please verify that the datastore is available on all intended ESX hosts."

we can independantly confirm that the device is on the one ESX host available. So we are not sure what this warning is trying to tell us.

Environment:

I'll state our environment and what steps we've taken to create the setup too as additional information that might help:

• We were guided by this document which states
  > "Stretched storage is supported only on vCenter Single Sign-On Enhanced Linked Mode environments"
  • And so converted our pair into such an environment, and tested by manually live migrating VMs between vCenters via vSphere GUI - which works fine.
• We tried on two different pairs (vCenter 6.7.0.4 + SRM 8.5.0.3) & (vCenter 7.0U3c + SRM 8.5.0.3).

Other Issues we've had:

SRM with stretched storage problems: vMotion - can... - VMware Technology Network VMTN
SRM with stretched storage problems: recovery hang... - VMware Technology Network VMTN

[yatigammanabnd]

@depping , as you mentioned in one of the other posts, that you guessed that this initiator issue is what is causing these challenges. Can you help me see how?

The other issues are at failover, but this one occurs after during reprotect?

Also, just for clarification, what even are "initiators"? It might help if I knew what that meant - as the datastore is definitely available on the intended ESXi host. Might that imply all is actually fine, but that the SRM gets confused somewhere in what should be available (potentially from the devices returned by the SRA?).