Will Site Recovery Manager update your protected VMs upon inventory mapping changes?
The short answer is ‘Yes, since SRM 8.6’. Of course, there is a longer and more complicated answer, and this is what this post is all about.
Up to SRM 8.5, inventory mappings changes did not affect in any way already protected VMs. This changed with SRM 8.6. Two new advanced settings were introduced in the ‘Replication’:
- updateVmProtectionOnInvMappingChange
- keepOverridesOnInvMappingChange
The first is set to ‘true’, and the second – to ‘false’ for fresh installs and upgrades, so the users will have the new functionality enabled by default. Both settings can be easily changed from the SRM UI.
It is worth noting that the settings are present for both SRM servers in the pair, and you can change them independently. The settings for an SRM Server relate to the inventory mappings and protection groups with protection direction from that server to its peer one. So, you can configure your pair in a way to update the protection when the direction is from ‘Site A’ -> ‘Site B’, and to not update the protection when the direction is from ‘Site B’ -> ‘Site A’.
Now let’s take a closer look…
Update VM setting
When ‘updateVmProtectionOnInvMappingChange‘ is set to ‘true’ and you edit an inventory mapping to point to a new recovery location/device, the SRM server will automatically reconfigure your protected VMs that use this inventory mapping, and the protected VMs will now use the new recovery location/device.
When set to ‘false’ and you edit an inventory mapping, the protected VMs that use this inventory mapping will not be updated. They will continue to use the recovery location/devices with which they were initially protected.
Keep overrides setting
‘keepOverridesOnInvMappingChange’ setting comes to play only when ‘updateVmProtectionOnInvMappingChange’ is true. When ‘updateVmProtectionOnInvMappingChange’ is false, nothing is being updated, so the value of this setting doesn’t matter.
It affects the VMs that were protected by using explicit recovery location/devices, rather than the inventory mappings. Regarding the UI, this is when the user checks the “Override site mappings” checkbox and specify a recovery location/device in the ‘Configure Protection’ dialog.
When ‘keepOverridesOnInvMappingChange’ is set to ‘true’, the SRM server will not update the protection for protected VMs with explicit recovery location/devices. They will remain unchanged upon inventory mapping changes. When set to ‘false’, the SRM server will update such protected VMs along with the ones protected with inventory mappings meaning that the explicit recovery location/device will be lost, and the new way the VM will be protected is by using inventory mappings.
| updateVmProtectionOnInvMappingChange | keepOverridesOnInvMappingChange | Update protection for VM protected with Inventory mappings | Update protection for VM protected with Explicit recovery location or device |
| False | True/False | No | No |
| True | False | Yes | Yes |
| True | True | Yes | No |
How does it look in the UI?
The most noticeable change in the SRM UI is that you will see info pop-ups when creating/editing inventory mappings letting you know that protected VMs might be affected by your action. These pop-ups will only be shown when ‘updateVmProtectionOnInvMappingChange’ is true for the protected site SRM server, and will look like this:
In addition, in SRM 8.7 we have added helper text in the ‘Configure Protection’ dialog explaining the SRM behavior according to the current values of both settings. It will tell you whether protected VMs will be updated, and overrides kept. In case ‘updateVmProtectionOnInvMappingChange’ is false and nothing will be updated, there will be no helper text.
After mappings creation/editing you might notice protected VMs related tasks in the ‘Recent Tasks’ panel. These are the tasks SRM starts to update the protection of the affected protected VMs.
Finally, it is important to know that SRM takes no action when an inventory mapping is deleted. It will not update, nor remove the protection for any of your protected VMs.
Don’t forget to follow the VMware DR Community Team on Twitter @VMware_DR_team and send us any feedback.
