Hi all,
Is there someone encounter the same error below. Co'z when i perform planned migration i received this error .
i'm using SRM 5.1.2, SRA 3.2.0, IBM v7000 storage 7.2 microcode by checking to vmware compatibility matrix this is supported for vshpere version 5.1 update 2. I can successfully perform test migration and disaster recovery without error. thanks in advance for the help..
Did you find a resolution to this?... We are experiencing the same issue using SRM 5.1, SRA 2.3, and V7000 7.1 (soon to be 7.3).
The auxiliary volume on the remote V7000 are already mapped to the host before the failover ?
Nope ... the volume on the recovery side was not mapped to any hosts within the V7000, nor could the ESX hosts see this volume. During the failed recovery, the SRA did map the volume to the hosts within the V7000, but the error as noted above showed up.
Hi Robert, I know this, but as message suggest, seems like the remote copy target are already mapped, because of this I asked if they are 🙂
Just another question, after the test migration, did you run the clean procedure ?
As a test ... we even unmapped everything, tried it again, and again the SRA mapped the volume to the hosts within the V7000, but still got the same error.
We did run a successful test migration and a successful cleanup of that test migration prior to attempting a recovery. We also confirmed the Flashcopies were removed on the V7000 side. We do have a case open with both IBM and VMware, but no smoking gun as of yet.
Ok Robert, and let us informed if IBM/VMware provide the solution.
we resolve the issue together with the storage team much better to contact your local vendor for the IBM storage and let them do the IBMSVCSRA configuration also for the LUN/datastore mapping for the recovery site.
We ended up working with both VMware and IBM ... and ultimately the fix was pointing the SRA/Array manager to the block IP management address rather than the Unified IP address ... this environment is an IBM V7000 Unified solution.