Hi Keith,

What XtremIO and RP versions are you running ?

Migrating the XMS (given same IP and credentials) should be transparent to RP, there are cases where the XMS registration would need to be edited.

Note that deregistering the XMS in RP is only possible when there aren't any copies with volumes managed by that XMS so the second option is a disruptive one.

Regards,

Idan Kentor

RecoverPoint Corporate Systems Engineering

Twitter: @IdanKentor

Hi Idan,

The more I think through this, after pausing the CG's in RP, the XtremIO cluster will need to be removed from the vXMS in order to be added to the physical one once it is online - will RP be able to handle that transparently? Would it act as if the vXMS was just shutdown? Or is there cleanup needed in this case.

Thanks!

-Keith

Hi Keith,

Yes - RP should be able to handle that change. Pausing Transfer is a good precaution although XMS inaccessibility should not affect replication (new configuration cannot take place during that time though). Take into consideration that after the XtremIO cluster is added to the vXMS, the array registration in RP must be updated.

Regards,

Idan

Thanks Idan. If I am adding it to a physical XMS witht eh same IP and same rp_user/passwd....do I still need to update the registration?

So what I have for a process is this:

1. Pause CG's

2. Remove cluster from vXMS

3. Install and IP the new physical XMS

4. Add cluster to physical XMS

5. Update RP registration (guessing I will just redo the user/IP/passwd here?)

6. Resume CG transfer

Sound good?

thanks!

You can remove and re-add without affecting replication.

Regards,

Rich Forshaw

Consultant Corporate Systems Engineer - RecoverPoint & VPLEX (EMEA)

Data Protection and Availability Solutions

EMC Europe Limited

Mobile: 44 (0) 7730 781169 44%20(0)%207730%20781169>

E-mail: richard.forshaw@emc.com

Twitter: @rw4shaw

Right, in order to deregister, you'll need to remove all relevant CG copies.

Regards,

Idan

Hi Keith,

I would actually deregister and re-register as it will be full test of XMS connectivity. However, as a secondary test I would perform a configuration action to test XIOS SYM connectivity.

Regards,

Rich

Sounds good, updating registration is key here in order to perform a connectivity test.

Regards,

Idan

OK...thanks guys. So if I go that route then I will have to disable and remove the CG's as the removal will force that correct?

I don't think I will be able to pause the CG's if I want to deregister it, will I?

thanks!

OK...so it sounds like it does impact replication? If there is a less disruptive process, I'm down for that one

sweet...I like that. I will update you when I do it this week...thanks a ton guys. As usual...you guys rock!

Here's what I would do.

1.     Pause CGs (optional).

2.     Remove vXMS from cluster.

3.     Install and IP the pXMS with the same IP address as used for the vXMS.

4.     Add cluster to pXMS.

5.     Resume CGs (optional).

6.     Perform configuration test to verify XMS/SYM connectivity is OK.

Regards,

Rich

Hi Rich,

No, there won't be any XMS recovery as the plan is to remove the cluster from the vXMS and add it to the pXMS - similar to what would be done in a multi-cluster management setup versus the replacement of an XMS which is what I think would require the XMS recovery script because the cluster wouldn't have been properly removed from it - correct me if I am wrong though here. In prior discussions, the recovery didn't seem to be required. So here is the procedure:

1.     Pause CGs (optional).

2.     Remove vXMS from cluster - "remove-cluster cluster-id=X"

3.     Install and IP the pXMS with the same IP address as used for the vXMS.

4.     Add cluster to pXMS - "add-cluster sc-mgr-host= "

5.     Resume CGs (optional).

6.     Perform configuration test to verify XMS/SYM connectivity is OK.

thanks!

-Keith

Forgot to ask, re step 4 does this include the recovery step for the new pXMS?