VDP OVF Deployment error — Web Client

If you come across the following connection error while VDP OVF deployment. For that matter any OVF..

• The issue is specific to web client connections. As a work-around you may have to use vSphere client(Thick client) for deploying the OVF (See this KB for more details – http://kb.vmware.com/kb/2053229)

SRM (ABR/VR) & VDP ——– @ vSphere 5.5- Do they conflict ?

SRM (ABR – Array Based Replication)

SRM (VR – vSphere Replication) formerly referred as (HBR- Host Based Replication)

SRM & VDP as we know are product offerings from VMware for Business Continuity & Disaster Recovery. SRM provides CDP(Continuous Data Protection) by replicating blocks of data/VMs-marked-for-protection from  primary to a secondary site,and on the other hand VDP though do not offer CDP(Continuous Data Protection), it can very well protect Virtual Machines at a site by backing up VMs and maintain recovery  points for PIT(Point-In-Time) recovery of Virtual Machines

Question ???

 Do SRM & VDP work together in the same vSphere environment without any conflict ?

I started with an experiment to find out the answers. Identified 2 primary Use Cases

Use Case-1:

1. SRM(ABR) configured ‘Synchronous’ replication at storage array level, replicating blocks of data from Site-A(storage array)/Primary Site to Site-B(Storage array)/Recovery Site and VDP inturn  protecting/recovering VMs at Site-A/Primary

My Experiment & Results:

 – Deployed the complete test environment with SRM(ABR) & VDP running in the same vSphere environment

-SRM(ABR) is configured ‘Synchronous’ replication for testing purpose and running Initial full sync. As I see the progress from Storage Array, kick-started VDP backup of VMs at Site-A(Storage  Array)/Primary – [SRM(ABR) full sync & VDP Backup completed successfully without any issues]

-Dumped 3 GB of data onto a Test-VM sitting at Site-A(Storage Array)/Primary and the delta sync is started.As I see the progress from Storage Array, manually started backup from VDP to backup up the  Test-VM – [SRM(ABR) delta sync & VDP Backup completed successfully without any issues ]

– Powered OFF the Test-VM and started a VDP Overwrite restore (Overwriting the existing VM) at Site-A(Storage Array)/Primary. As the VM is powered-OFF no writes are going in -[VDP restored the VM successfully and no issues observed]

– Dumped 2 GB of data onto a Prod-VM at Site-A(Storage Array)/Primary and the delta sync is started. As I see the progress from Storage Array,kick-started VDP Restore(Create new VM) from Prod-VM – [SRM(ABR) delta sync on Prod-VM & VDP Restore as a new VM completed successfully without any issues]

Conclusion –

• As SRM(ABR) operates at Storage Array LUN level & VDP operates at VM level, no issues observed wrt to backup/restore & replication.
• No failure of any operations observed that may impact backup/restore & replication.
• My test concludes that SRM(ABR) & VDP can co-exist

Use Case-2:

2. SRM(VR) is configured replication with RPO value set to 30 minutes & VDP running in the same vSphere environment

My Experiment & Results:

 -SRM(VR) is configured RPO of 30 mintues for testing purpose and running Initial full sync of the VMs.As I see the progress of the Full-Sync,kick-started VDP backup of the same VMs at Site-A/Primary – [SRM(VR)  full sync & VDP Backup completed successfully without any issues . However during delta sync there were backup failures on some VMs during snapshot operation. I re-ran backup on the failed VMs and it succeeded. This looks like a timing issue of snapshot call from both VR & VDP. I adjusted my backup window to start the backup at a time different than the replication sync time.Let me be clear with an example..]

Example– Say if replication is set to occur for every 4 hrs starting from 8 AM. Then the next sync time will be at 12 PM, 4PM, 8PM, 12AM and 4AM respectively. I initially had issues wrt to backup failures as mentioned above because my backup was scheduled to occur at 8PM. Two snapshots calls at the same time and only one will succeed. I adjusted my backup to start at 8:15 PM instead of 8 PM and then everything worked fine. VR mostly completes snapshot operations even before my backup. It does not mean that VDP backup should be avoided while VR replication is in progress, but it the snapshot race condition that should be avoided by manually adjusting the schedule time of backup or the replication time.

-Dumped 3 GB of data onto a Test-VM at Site-A/Primary and the delta sync is started as per schedule. As I see the progress of delta-sync, manually started backup from VDP to backup up the Test-VM at Site-A/Primary – [SRM(VR) delta  sync & VDP Backup completed successfully without any issues. However the scheduling is taken care already as mentioned in the above example ]

– Powered OFF the Test-VM which inturn automatically disabled replication on the VM and is expected. Started a VDP Overwrite restore (Overwriting the existing VM)- [VDP restored the VM successfully and no issues observed] . Note – The Test-VM once powered-ON will start with a Full-Sync which is expected.

– Dumped 2 GB of data onto the Prod-VM at Site-A/Primary and the delta sync is started as per schedule. As I see the progress of delta-sync, manually kick-stared VDP Restore-Create New VM (Creating a new VM from restore). Was expecting that replication would start on the VM being restored by VDP. Interestingly, replication on the restoring VM is disabled automatically. A good sign ! – [SRM(VR) delta sync on Prod-VM & VDP Restore as a new VM completed successfully without any issues]

-Backup/Restore from VDP has no impact on VMs with replication ‘Paused’ / ‘Disabled’

Conclusion – 

• As SRM(VR) & VDP both operate at VM Level, there are chances of failures especially while snapshot call. However it can be avoided by adjusting the schedule time of backup/replication as mentioned in the above example
• No failure of any operations(Hot-add, CBT) observed that may impact backup/restore.
• My test concludes that SRM(ABR) & VDP can co-exist provided schedule is taken care

Note – The above conclusion is made based on testing carried out on vSphere 5.5 environment & SRM, VDP running 5.5 versions.