Over the past 4 years, I have been in a constant battle to move all workloads to NSX-T. And I say “battle” because it certainly felt like it. A larger entity acquired the company I work for. Although we completed the NSX-V>T project for our vSphere environments, the larger entity still had a small NSX-V workload for me to take on.
But happy to announce that the wait is over, all NSX-V bits have been uninstalled and removed.
One of the last errors during NSX-V uninstall was cleaning up in Cloud Director. Many of the logical switches were becoming stranded items due to issues Cloud Director encountered during cleanup. Usually, we can remove the stranded items, but here they were stuck. This was a blocking issue preventing the removal of the NSX-V manager from Cloud Director.
Before proceeding, take a backup with the cell tool, and a VM snapshot on the cells wouldn’t hurt either. If you are not sure about messing around with your vCloud database, I strongly recommend that you create a Broadcom support case and let them assist.
1. Finding the Network pool id
vcloud=# select * from network_pool where name = 'VXLAN-NP';
-[ RECORD 1 ]-----+-------------------------------------
id | 39a4461a-0b90-435f-84d4-6388fc8830cd
name | dc1compute01-VXLAN-NP
description |
dvswitch_id |
network_pool_type | 3
vdn_scope_id | vdnscope-6
vlan_id | 0
promiscuous_mode | f
vc_id | d0b752ac-be4c-4939-9245-d5e191806430
version_number | 4
creation_status | READY
universal_id |
nsxt_manager_id |2. Listing networks backed by the NSX-V network pool
Use the network pool id from the query above
vcloud=# select
real_network.id as real_network_id,
real_network.name as real_network_name,
real_network_backing.id as real_network_backing_id,
logical_network.id as logical_network_id,
logical_network.scope_type as logical_network_scope,
logical_network.name as logical_network_name
from network_pool
left join real_network on real_network.pool_id = network_pool.id
left join real_network_backing on real_network_backing.rnet_id = real_network.id
left join logical_network on logical_network.rnet_id = real_network.id
where real_network.pool_id = '39a4461a....'
real_network_id | real_network_name | real_network_backing_id | logical_network_id | logical_network_scope | logical_network_name
---------------------------+--------------------------------------------------------+--------------------------------+--------------------+-----------------------+----------------------
9e2459ec-1013-4a85-b0b7- | dvs.193a-4fa4-90ba-327429e479b3 | 598522d5-da6d-4fd2-b1fc- | | |
cfa130cd-7d95-46b5-a994- | dvs.e83ba4a6-ad0e-4d6f-a07b-b4874156883b | ffd658bb-e9a0-4120-b847- | | |
9096c757-d42c-43a6-9a8d- | dvs.a2554d6f-dd83-4073-8200-425914618b00 | 492561e3-e116-477b-b9db- | | |
81c4962c-bd44-4fc9-aaa8- | dvs.e2142ca8-a5c7-48ab-9c87-6fbb9c8d41f8 | 18538223-f184-4990-831c- | | |
(4 rows)
3. Review each of the networks
To confirm, it will not be listed twice to provide a before-and-after view.
vcloud=# select * from real_network_backing where rnet_id = '9e2459ec-1013-4a85-b0b7'
id | rnet_id | vc_id | dvpg_moref
--------------------------------------+--------------------------------------+--------------------------------------+--------------------
ffd658bb-e9a0-4120-b847-c230890b89fd | 9e2459ec-1013-4a85-b0b7- | ef4e323d-fdc2-4a0d-87e2-fefed1b281e1 | dvportgroup-121351
(1 row)4. Removing the network from the Network Pool
vcloud=# delete from real_network_backing where rnet_id = '9e2459ec-1013-4a85-b0b7-';
DELETE 1After deleting all networks, rerun step 2 and verify that there are no longer any network dependencies on the network pool. If it returns an empty response, you are good to go and can delete the network pool in Cloud Director.
Conslusion
After 200+ customers have been migrated to NSX-T, I’m happy and hope to never be in the crossfire of VMware changing its network virtualisation product again in a way that would require us to migrate all of the customers’ networks.
























