Unsolved
This post is more than 5 years old
1 Rookie
•
23 Posts
0
2143
March 17th, 2015 00:00
RecoverPoint for VM - VMWare action support
Hi Guys,
I have a question regarding a limitation for RecoverPoint for VM that was pointed in the PDF "EMC RecoverPoint for Virtual Machines Product Guide". We run version 4.2P1.
The guide states the following 3 points:
1- Memory and CPU changes to protected VMs are allowed:
• These changes are not replicated.
• You can manually adjust resources on copy VMs.
2- VMDK source insertion:
• RecoverPoint for VMs auto-provisions VMDK at the copy VM and adds it to consistency group as a new replication set.
• The journal history is deleted and a volume sweep is performed.
3- Changing the configuration of virtual machines that are being replicated is not supported, except changing network connections, which is supported.
Point 3 above is confusing me... does this mean that the only supported action to change the configuration of the source VM is (1 and 2)?
Also, if a VMDK of a protected VM is "extended" what are the steps that I need to perform on the copy VMs in order to support that change? Do I "extend" the disk on the shadow VM manually? I think the same goes for CPU and Memory?
Also, in a different guide, it states that actions on shadow VMs are not supported? so what do I need to do? I hope that won't mean that I will have to unprotect the VM and then reprotect it!!
fadliz
153 Posts
0
March 17th, 2015 02:00
Hi, We will get point #3 clarified. In essence, points 1 and 2 are correct. Changes to CPU/Memory/Network of a protected VM will not be replicated in this version. If needed, the changes can be made manually to the Copy/replica VM (not shadow VM) while in image access. As far as the VMDK resize, at this point, the best approach is to unprotect and re-protect the VM. However, if you're simply adding additional VMDKs, as pointed out above in item#2, the RPVM system will auto-detect that and create a target VMDK.
Thanks, Z
maxsven
1 Rookie
•
23 Posts
0
March 17th, 2015 03:00
Thanks fadliz,
So what you are basically saying is that any configuration changes (apart for adding a new VMDK) require the VM to be unprotected and then re-protected in order for the changes to be replicated to the target?
Also, when you say "he changes can be made manually to the Copy/replica VM (not shadow VM) while in image access", that is basically FOLLOWING FAILOVER, correct?
one last question, if I extend a VMDK at the source and then unprotect and re-protect, I should be able to point the source VM during the "Protect VM" wizard to the destination VM folder so it does not have to do a full sync again (but instead a full sweep)?
fadliz
153 Posts
0
March 17th, 2015 03:00
Not exactly. You can make any changes you want to CPU/Memory resources w/o impacting replication/protection. It's only if you need those changes to also apply to the target/Copy VM, then you will have to perform them manually in this version at the target side.
The image access I was referring to is not during failover, rather you can do that during a Test Copy operation.
Yes on avoiding a full sync, just make sure the target VM has the appropriate VMDK sizes.
Thanks
maxsven
1 Rookie
•
23 Posts
0
March 17th, 2015 04:00
Ok,
In this case the process will be as follows (lets assume one VMDK has been extended at a source VM and 2GB RAM has been added)... are you able tonplease verify it?
1- In the recoverpoint for VM snapin in vSphere web client, select the consistency group that the VM belongs to and select "test a copy".
2- This brings up each VM in that CG on the target vCenter server (isolated network, no impact on prod).
3- Once the copy VMs have been regesitered at the target vCenter, select the VM in question and upgrade the RAM.
4- if the change was only for RAM and not disk expansion, you can disable image access at this point and it is all done.
5- Since a VMDK has been expanded, you need to extend the VMDK to the VM at the detination before you disable image access... then disable image access and unprotect the VM at the source.
6- reprotect the VM at the source and point it to the folder that it used before at the target when it was protected.