BACKUP YOUR SQL DB BEFORE PROCEEDING !
In a PREVIOUS POST I discussed how easy it is in vRA 7.1 to end up with orphaned Network Profiles.
After digging through the vPostgres Database of vRA, a colleague, Nathan Gaskill from the CTO Office in ANS came to my rescue and pointed out I was looking at the wrong database 🙂
Of course I shouldn’t look at the vPostgres, but rather the SQL DB. Thankfully he also pointed at the right tables so I was able to dig a bit deeper and delete the necessary bits.
Once again, backup your DB before doing this …. I would say that I’d rather get GSS (VMware Support) involved if this is happening in production, simply to back yourself up in case something goes poopoo 🙂
Just as a reminder, due to a mistake in the Blueprint configuration (missing Edge Reservation), I ended up with two Network Profiles I was unable to delete.
When creating for example Routed Networks, you end up with two profiles
- Transit Network
- Of Type External Network
- Routed Network
- Of Type Routed Network
Because of the way routing works, the External Network is attached to the Routed Network
Example:
As a result I wasn’t able to delete the External profile because it was in use by the Routed profile.
When trying to delete the Routed profile, I also got a message that said range is in use.
When I checked the range of the Routed profile, I noticed that the range itself is ALLOCATED
As shown in the above mentioned post, I already deleted all Edge Devices / VMs etc., so there is nothing where this range could be allocated to.
There also wasn’t anything in the Web Client to indicated that a Logical Switch has been created and subsequently attached to the DLR.
As Nathan mentioned to me, time to dig through the IaaS SQL database.
When you expand the database using the Management Studio, you need to look at these three tables
When you check the table dbo.StaticIPv4Address you’ll be able to see the IPs ‘assigned’ from the range (even though in my case they aren’t, or rather, weren’t)
First I tried to delete all those IPs – but that gave me an error about dependencies. So I went into the table StaticIPv4Range (Right Click > Edit Top 200 Rows)
Now you can use your mouse and drag / select the relevant rows
And hit Delete
Next we go into StaticIPv4NetworkProfile (Right Click > Edit Top 200 Rows)
Using the same principle, delete the affected profile(s)
While I was ‘there’, I also deleted the External Profile through the DB – technically I should have been able to do that once the Routed once was gone, but heh – easy way out, right 🙂
Once done, I was able to go back into vRA and refresh the Network Profile tab
Before:
After:
For testing purposes I deleted all but one profile – my Transit network which was ok. I wanted to ensure that i can re-create any DB-Deleted profile with the same details.
So .. all good …
NOTE AGAIN: BACKUP YOUR DB !!
I seriously don’t know much about SQL and the proof will be in the pudding, as they say, whether there are future problems etc. (upgrades come to mind).
Anyway, time for tea 🙂