Lee Dilworth wrote:
i've seen this once before on dell EQ and it was caused by a device on the array being in a weird state that was causing the SRA to report and incorrect results when discoverDevices was called. this basically meant the offending device state could never be changed and reprotect could never complete.
the "weird" device was caused because on the target array the same id was being used for a source and target device at the same time and the SRA couldn't handle that.
once the device id was correct the customer created a new recovery plan for that protection group, ran the reprotect again, this failed as expected, ran the reprotect again with "force cleanup" ticked, this then ran to completetion and got the protection group back into a normal state.
Lee,
If you're referring to the case you and I worked together on here, it was a Dell Compellent SAN, not EQL. I'm going to follow up on that discussion since in the end I was able to remove the protection group without reinstalling but I'm not sure that solution will do much good in the case in this thread. In that vein, it reinforces my opinion that within SRM there needs to be an ability to cut away the protection group & recovery plan without reinstalling the environment. SRM should not allow the SRA to interfere with the integrity & protection of the rest of the environment, particularly where there could be other array models involved. This is an Achilles Heel from an architecture standpoint.
Thank you,
Jas