Sometimes you might get into a situation where you added an IP Range to a Network Profile and then realised you have some IP in use on that VLAN – i.e. physical servers.
If you KNOW this is a possibility BEFORE you create the range, then this is easy (we’ll come to that).
But if you have imported the range and already used it – then it becomes a bit more complicated .. just a bit ..
Here you can see I have three machines in the range. Now imagine I want to reserve the following IPs for physical machines
- 172.1.0.201
- 172.1.0.203
Because they are right bang in the middle the already taken IPs, I can’t even attempt to split the range.
Unfortunately this requires a bit of digging through the database. VMware did release a Knowledge base Article, but it is based on vRA 6.2
But the good news are – it still works. So open up your SQL Management Studio
Note 1 : DON‘T FORGET TO BACKUP THE DB BEFORE DOING ANYTHING !!
Note 2 : Database Edits are not supported by VMware Support unless instructed by them directly
Connect to your vRA Database and expand the Tables
Navigate to
dbo.StaticIPv4Address
Right click the table and select Select Top 1000 Rows
When you now scroll to the right to
StaticIPv4AddressState
You can see a status of either ‘0’ or ‘1’.
- 0 = Allocated
- 1 = Unallocated
Here as example, 172.1.0.202 is taken up by VM IP-Range-2 – and therefore the status is ‘0’.
172.1.0.203 is currently not allocated – and therefore the status is ‘1’
As mentioned, I want to allocated two IPs, 172.1.0.201 and 172.1.0.203 – so for this we need to run two queries (one for each IP)
update StaticIPv4Address set StaticIPv4AddressState = 0 where IPv4Address = '172.1.0.201'
and
update StaticIPv4Address set StaticIPv4AddressState = 0 where IPv4Address = '172.1.0.203'
Now when you refresh the range inside the Network Profile, you can see those two IPs as allocated
Unfortunately there isn’t an easy way to put a description there, but at least you can avoid ‘automated’ IP Conflicts that way. To make them available again, simply change the query to ‘1’.
I did mention a way to do this BEFORE you deploy any VMs, right.
When creating a range, you have the option to import a CSV file rather than creating the range manually
See option Import from CSV
You can find the documentation in how to format the CSV HERE
You can see I have here a range of 172.1.0.200 – 172.1.0.249
I will now import three more. Two empty – unallocated ones, and one which I allocated to a VM (for example from inside the OS rather than through vRA)
My resulting CSV is
172.1.0.250,,Unallocated 172.1.0.251,IP-Range-01,Allocated 172.1.0.252,,Unallocated
You can see I have left the machine name empty for the Unallocated machines.
Let’s import that. So click Import form CSV
That should hopefully finish
When you click Apply and check the IP Addresses, you can see that those IPs have now been assigned / entered into the DB
Now why is that different ? Have a look at the above screenshot. You can see ‘X Delete’ is actually available.
Because you imported a CSV, vRA considers each IP an individual ‘range’ and can therefore be deleted !
Imagine I now changed my mind and want to remove 172.1.0.251 again
Click Delete
Gone .. The bottom line here is I guess – if you work in a Greenfield environment, import ranges via CSV rather than configuring the ranges through the UI.
Customers can easily change their mind and therefore gives you more freedom when it comes to Network Profiles
The End 🙂