Azure VNETs appering as un-managed after CSM restart
search cancel

Azure VNETs appering as un-managed after CSM restart

book

Article ID: 336795

calendar_today

Updated On:

Products

VMware NSX

Issue/Introduction

Symptoms:
After CSM restarts, any existing Azure VNETs that are already managed (transit or compute), appear as un-managed (without any gateways) even though the gateway VMs exist on Azure cloud and are connected to NSX manager (Policy).

Environment

VMware NSX-T Data Center 3.x
VMware NSX-T Data Center

Resolution

Currently, there is no resolution.

Workaround:
On the Azure portal:
  1. Identify the Resource Group created by NSX for the transit VNET which shows as un-managed. It should be in this format nsx-gw-<vnet-id>-rg
  2. In the above Resource Group, identify the Azure disk Image created by NSX for the PCGs. It should be in this format nsx-gw-<vnet-id>-<hash>-image
  3. For the above image, get the VHD URL associated with it from the "Overview" page under "Source block URI". It should be in this format https://<storage-account>.blob.core.windows.net/<container>/<vhd>
  4. From Azure portal, create a new "Image" resource with the following properties,
Name - nsx-gw-<vnet-id>-image
Resource group - nsx-gw-<vnet-id>-rg from Step 1
OS type - Linux
Storage blob - https://<storage-account>.blob.core.windows.net/<container>/<vhd> from Step 3
  1. Repeat the steps from 1 to 4 for every transit VNET which is being shown as un-managed which actually have gateways deployed.
  2. Trigger inventory sync for the Azure account on CSM and now all the managed VNETs should be in the expected state.


Additional Information

Impact/Risks:
This issue occurs only in NSX version 3.0.1 and only VNETs where gateways were deployed at version 3.0.1 will be impacted. If gateways were deployed in previous releases and then CSM got upgraded to 3.0.1 and restarts, these VNETs which were managed from previous releases won't be impacted.