VLSR - Updating global mapping in SRM does not update the already protected virtual machines to reflect the new mapping change

Products

• VMware Live Recovery

Issue/Introduction

Recoveries in general will fail with different errors when mappings are incorrect.  

Environment

VMware Live Site Recovery

Cause

In Site Recovery Manager 8.6 and below, if you change the site-wide inventory mappings for a site, SRM does not update the mappings (folder, resource pool, or network) in the existing protection groups consisting the already protected virtual machines to reflect the new mapping change. In this version and below, you are required to update the global mapping and the individual virtual machine mappings in the already protected virtual machines manually.  



Automatic VM protection updates per current global mapping settings on folder or resource pool relocation feature introduced in SRM 8.7 and higher fixes this issue. 

In Site Recovery Manager 8.7 and above, if you change the site-wide inventory mappings for a site, by default the changes affect virtual machines that Site Recovery Manager already protects in an existing protection group. Site Recovery Manager updates recovery target (folder, resource pool, or network) for all protected virtual machines to reflect the global (site-wide) mapping change. You can control this feature through the replication.updateVmProtectionOnInvMappingChange advance setting. The advanced setting is activated by default.

Resolution

If you are running SRM version 8.6 and below and have ran a recovery that has failed with errors because you edited changes in the global inventory mapping. The only way to resolve this issue is to delete and recreate the Protection Group & Recovery Plan and then upgrade to a higher version of SRM that supports this feature. 

Additional Information

Inventory Mappings for Array-Based Replication Protection Groups, Virtual Volumes Protection Groups, and vSphere Replication Protection Groups