You can use VMware Site Recovery Manager™ (SRM) with NSX Federation for disaster recovery use cases.

Site Recovery Manager supports the following workflows with NSX Federation:

  • NSX Federation Global Manager (GM) VMs support full and test recovery of GM VMs (supported with or without NSX Federation management cluster VIP).
  • Compute VMs support full and test recovery of compute VMs. Recovered VMs in the disaster recovery site have their NSX tags and firewall rules based on these NSX tags or not such as IP addresses and VM names.

To ensure that groups and firewall rules replicate at the disaster recovery location during recovery, the NSX Local Manager managing the disaster recovery location must have the NSX tags present at recovery time.

Prior to NSX Federation 3.2, SRM had no support for replication of VM tags between Local Managers. As a result, NSX did not replicate any security based on VM tags to recovered VMs. Security not based on VM tags, for instance, IP addresses or VM names, could be applied to recovered VMs.

In NSX Federation release 4.1.1, two fields support storage array replication: replication _type and tag_delay_delete_time. If you use storage array replication from your primary site to your recovery site in SRM, then create or update the tag replication policy replication type as STORAGE_ARRAY_REPLICATION.

Running a protection plan on SRM to migrate virtual machines using disaster recovery or planned migration options from your primary site to your recovery site will move the virtual machines to the recovery site and delete the virtual machines from primary site. When the concerned virtual machines are deleted from primary site and appear on recovery site within the tag_delay_delete_time setting, then tags from primary site get replicated on the virtual machines on recovery site. For storage array replication, the time for VMs to appear on the recovery site after they are deleted from the primary site depends on the VM count configured to failover, storage array performance, and ESXi host.

If vSphere replication is being used to replicate VMs from primary site to recovery site in SRM, then the virtual machine is not deleted from primary site. Therefore, there is no need to specify replication_type or tag_delay_delete_time in the tag replication policy.

Note: For Global Manager 4.1.1, if replication types VSPHERE_REPLICATION or OTHER options are used, then the tag_delay_time value gets set to 0. The replication_type is set to default value of enum (invalid) and the tag_delay_delete_time is set to 0 minutes.

Configure VM Tag Replication across LMs using GM API

In NSX Federation 4.1.1, to configure VM tag replication across Local Managers, run the following Global ManagerAPI: 
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
    "display_name":"vm tag replication policy Paris to London",
    "description":"vm tag replication policy1",
    "protected_site": "/global-infra/sites/LM_Paris",
    "replication_type": "STORAGE_ARRAY_REPLICATION", 
    "tag_delay_delete_time": 30,
    "recovery_sites": [
        "/global-infra/sites/LM_London"
    ],
    "groups":[
        "/global-infra/domains/default/groups/Web-VM-Group",
        "/global-infra/domains/default/groups/DB-VM-Group"
    ],
    "vm_match_criteria": "MATCH_BIOS_UUID_NAME"
For NSX Federation releases prior to 3.2.3 and 4.1.1, to configure VM tag replication across Local Managers, run the following Global Manager API: 
PUT https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies/policy1
{
    "display_name":"vm tag replication policy Paris to London",
    "description":"vm tag replication policy1",
    "protected_site": "/global-infra/sites/LM_Paris",
    "recovery_sites": [
        "/global-infra/sites/LM_London"
    ],
    "groups":[
        "/global-infra/domains/default/groups/Web-VM-Group",
        "/global-infra/domains/default/groups/DB-VM-Group"
    ],
    "vm_match_criteria": "MATCH_BIOS_UUID_NAME"
LM_Paris sends the tag information of the VMs for the BIOS UUID of the VMs in the groups Web-VM-Group + DB-VM-Group to LM_London. Before the recovery of the London VMs by SRM, LM_London does not have the VMs with the BIOS UUID and the VMs are not visible in LM_London yet. However, when SRM recovers the VMs in London, LM_London sees those VMs with the BIOS UUID and applies their NSX tags on them. The VMs get their security based on NSX tags.
Note: vm_match_criteria has two possible values MATCH_BIOS_UUID_NAME or MATCH_NSX_ATTACHMENT_ID. At the recovery, SRM copies both so any configuration is valid with SRM. However, if another product completes VM replication and copies one, but not the other value, then configure GM with the appropriate vm_match_criteria value.

To estimate how much time it might take for the VM to disappear from the primary site and appear on the protected site, you can perform a test on the protection plan and measure the time interval between the end of the Synchronize storage and completion of the Power on priority X VMs steps. Set your tag_delay_delete_time to be more than this estimated time. Another tip is to run the protection plan in Site Recovery Manager and set the tag_delay_delete_time to always be more than time it takes between the step Shut Down VMs at the protected site and to complete the step to Power on priority X VMs while doing run on protection plan in SRM.

Check VM Tag Replication across LMs using GM API

To get details on VM tag replication across Local Managers run the following Global Manager API : 
GET https://{{gm}}/global-manager/api/v1/global-infra/vm-tag-replication-policies
The output returns something similar to: 
{
  "protected_site": "/global-infra/sites/LM_Paris",
  "recovery_sites": [
    "/global-infra/sites/LM_London"
  ],
  "vm_match_criteria": "MATCH_BIOS_UUID_NAME",
  "groups": [
    "/global-infra/domains/default/groups/Web-VM-Group",
    "/global-infra/domains/default/groups/DB-VM-Group"
  ],
  "resource_type": "VMTagReplicationPolicy",
  "id": "policy1",
  "display_name": "vm tag replication policy Paris to London",
  "description": "vm tag replication policy1",
  "path": "/global-infra/vm-tag-replication-policies/policy1",
  "relative_path": "policy1",
  "parent_path": "/global-infra",
  "unique_id": "9ee18586-5480-41d9-8223-690c9226d763",
  "marked_for_delete": false,
  "overridden": false,
  "_create_time": 1638413861377,
  "_create_user": "admin",
  "_last_modified_time": 1638413861377,
  "_last_modified_user": "admin",
  "_system_owned": false,
  "_protection": "NOT_PROTECTED",
  "_revision": 0
}

NSX supports only one entry from recovery sites. For details, see the vm-tag-replication-policies/policy-name API in the NSX Global Manager REST API Guide.