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:
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
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
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>
From Azure portal, create a new "Image" resource with the following properties,
Name - nsx-gw-<vnet-id>-image Resource group - nsx-gw-<vnet-id>-rgfrom Step 1 OS type - Linux Storage blob - https://<storage-account>.blob.core.windows.net/<container>/<vhd>from Step 3
Repeat the steps from 1 to 4 for every transit VNET which is being shown as un-managed which actually have gateways deployed.
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.