This mistake can be made VERY easily – but the fallout could be significant – depending on the environment.
Let me explain.
Any blueprint which requires an Edge Gateway – like an On Demand Load Balancer or On Demand NAT Network , will deploy an NSX Edge.
Here an example – On Demand Router
Then I tried to deploy said blueprint.
The deployment failed pretty much instantly. Then I checked why
I had another look at the Blueprint – and sure enough :
I quickly fixed it and tried again – but got an error regarding no available network reservations (or something like that – don’t have a screenshot)
Then I checked vCenter – nothing, no Edge .. Then I checked the Managed Machines
(Please excuse the funky crop – fat fingers)
These three UnprovisionMachine machines are essentially three Edges out of three attempts which have taken all those precious IPs (I only allocated a /29).
The fact they are at the UnprovisionMachine state is because I tried to delete them from that view – but they don’t go away even if you try to ‘destroy’ them.
Not a problem I thought – I have done this before. I even wrote an article about it;
So with Cloud Client I was able to remove those Edge devices.
BUT – and there gotta be a but – otherwise this post wouldn’t exist – The Network Profile STILL thinks it is in use.
How did I notice ? Because I tried to delete it.
Here you can see the Network Profile in question:
You can see that I don’t even have a Range – for Routed Networks, your External Profile doesn’t even have to have a range.
So when I tried to delete said Network Profile, I got this error
And the plot thickens .. so for some reason the profile is still in use somewhere .. As the above was a routed network – the profile is used by such .. so I checked the Routed Network this External Network is part of and sure enough – I can’t delete that either
Ever so slightly different but still no cigar .. Now when I checked the range of the Routed Network:
ALLOCATED. So fair enough – that is why, because the External Profile is part of the Routed Profile – it cannot be deleted – that is because the Routed Profile still thinks it is allocated to .. well something ..
So .. if this range is still allocated – then I should see the above range as Logical Switch and attached to my DLR (ok, I call it here LDR) with 184.108.40.206 as gateway
It isn’t …
So the bottom line here really is – don’t make mistakes 😉
As you have seen in some of my other articles, like THIS ONE – it is really easy to end up in a situation where you will require VMware Support to clean up the vPostgres or IaaS database.
In this instance I am not sure I bother as I intend to reinstall the environment as soon as vRA 7.2 drops, but if I got a few hours I might dig into the DB again to see if this can be removed.
In this instance I even went so far and deleted everything I could – even the Fabric Group .. Rebooted the lot, and re-created everything ..
As soon as I created the Fabric Group – those two profiles popped back in 🙁
If every release, vRealize Automation surely gets more resilient – but I think there is still work to be done as certain mistakes can be done too easily – and orphaned objects shouldn’t really resist.
Anyway – so – you want to play with Edges – make sure you got that Reservation !!