NSX Tags disappear when migrating VM from one DC to another DC in an NSX Federation Environment

Products

• VMware vDefend Firewall
• VMware vDefend Firewall with Advanced Threat Prevention

Issue/Introduction

Issue:

NSX Tags are not retained following a powered-off VM vMotion from one DC to another DC in an NSX Federation environment.

NSX Tags are replicated successfully from one LM to another LM upon live-vMotion, however, if the VM needs to be powered off prior to migration, additional configuration is needed. See cause and resolution sections. 

Environment

NSX 3.x, 4.x

NSX Federation

Cause

A tag replication policy needs to be configured in order for NSX tags to be replicated from LM to LM during a powered-off vmotion of the VM. 

Resolution

Per Working with NSX Federation documentation, you need to configure VM Tag Replication across LMs using GM API:

*Please note that while the documentation specifically mentions SRM, it is not needed for this to function.

 

Example config:

In NSX Federation 4.1.1 and later, 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",

    "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"

 

 

 

Additional Notes:

• To get the site names, issue the API call - GET https://{{gm}}/global-manager/api/v1/global-infra/sites
• After configuring the above, VM's must be members of the defined groups (ex. Web-VM-Group and/or DB-VM-Group) for the VM tags to replicate. 
• In this example, if VM's are going to be migrated from London to Paris, a second policy is needed in which LM_London would be the protected site, and LM_Paris would be the recovery site. 

 

Explanation of Tag replication:

Given the above example:

• 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.