There are different ways to do this. But first, I want to do this without the use of vRO. So I rely on Custom Properties (which isn’t always as pretty unfortunately).
A reference can be found HERE
I will go through two options here.
Option 1 – IPs being managed outside of vRA (has gotchas)
What that means is, the Virtual Machine will get an IP address but vRA will keep no record of it. Essentially similar to deploying a VM from a template outside of vRA just by using vCenter templates and customizations.
First, the Blueprint itself does not have any networks attached. We do this via Custom Properties.
First custom property is called Hostname. Once set in a Blueprint, it will ask for a hostname and also overwrites the prefix.
This is essentially useful if your have a specific naming convention where prefixes just won’t work.
So here I create a custom property definition called Hostname and provide a textbox to enter the details.
The second property we add is VirtualMachine.Network0.Address.
If you only set those two properties, it will look nice and probably ‘just the way you like it’. BUT .. and there is a ‘but’ unfortunately
If you deploy a VM like that, you will be greeted with the error ‘Cannot complete customization’
The reason is simple – you cannot customise a virtual machine with an IP only. You require also a Gateway, Subnet etc.
You therefore need to add some more custom properties to allow an IP configuration during the deployment
- VirtualMachine.Network0.SubnetMask
- VirtualMachine.Network0.Gateway
- VirtualMachine.Network0.PrimaryDns
- VirtualMachine.Network0.DnsSuffix
These seem to be the minimum required (pretty much what vCenter Customizations require).
You can of course add additional ones (secondary DNS, WINS etc.)
Add these properties the same way you added the IP Address, example:
The only difference here is for the VLAN / Port Group.
As you can see I allow two port groups here. One is called External – which does not have a VLAN associated with it and IP range 192.168.1.0/24 and one which is called Internal.
This is backed by VLAN 10 and IP range 10.10.0.0/24
The custom property therefore is not a simple textbox (could be if you can be sure to spell them right every time you deploy a VM), but a drop down.
Name can be anything – as you can see I named just specific to the VLAN, and not port group.
Value is the actual port group vRA can see (see above screenshot).
Next step is to create a group and add these properties to it. A group can be added to a Blueprint so any additional custom properties added to the group will automatically show in the blueprint
If you followed the above guide you should now have 7 Custom Property Definitions
- Hostname
- VirtualMachine.Network0.Name
- VirtualMachine.Network0.Address
- VirtualMachine.Network0.Gateway
- VirtualMachine.Network0.SubnetMask
- VirtualMachine.Network0.PrimaryDns
- VirtualMachine.Network0.DnsSuffix
Make sure you tick Show in Request for each property
Now add the group to the Blueprint
Let’s deploy the blueprint.
So the above group of properties should now ask for
- VLAN / Portgroup
- Hostname
- IP Address
- Gateway
- Subnet Mask
- Primary DNS
- DNS Suffix
Here I add some valid details and click Submit
Once deployed, the VM has its custom hostname – without prefix – and its static IP set during the deployment
As mentioned – this approach has some gotchas … some could be significant (depending on your environment). Why is that ?
For starters, imagine you have multiple NICs. The amount of custom properties you don’t just have to create, but to maintain, can be crazy. vRA is supposed to make things easier, not harder.
Another issue is IPAM .. Unless you use Orchestrator workflows to add each IP to an IPAM solution, you have no view of what IPs are in use. At least not from within vRA. Another issue is human error.
You can of course add subnetmask / Gateway etc. to a drop down or fix the value hidden away. But as soon as you add a different network / vlan / port group into the mix, you will need to add custom property relationships to ensure VLAN X gets the Gateway for VLAN X and not VLAN Y.
It quickly gets complicated and harder to manage. One solution here is to use Network Profiles and let vRA manage IPs
Option 2 – IPs being managed by vRA
Here I got two profiles
- External mapped to 192.168.1.0/24
- Internal mapped to 10.10.0.0/24
The profiles are attached to its respective VLAN / Port group (Sorry, I call either External / Internal so not always easy to catch what is what)
Again I want to be able to specify Hostname. IP Address, VLAN
I will now use only three properties (this time you specify the ProfileName attached to the VLAN in question)
- Hostname
- VirtualMachine.Network0.ProfileName
- VirtualMachine.Network0.Address
The ProfileName property is configured similar to the port group name
Again, Name can be anything (VLAN / IP Range etc.) , whereas Value is the Network Profile Name.
This time I mix things up and just name them based on IP range, rather than the VLAN itself…
Because the Network Profiles now provide the details such as Gateway, DNS etc., we don’t need to specify them unless we really want to overwrite.
The LITTLE gotcha here : The IP you want to set manually must be part of the Network Profile Range.
For example, my Internal Range is quite empty .. So I select 10.10.0.100, which is free
For my external test I will be using 192.168.1.80, which is also unallocated
The advantage of this approach: It looks cleaner.
Internal Test:
External Test:
Once deployed, you can see that the VMs got their custom hostname and IP Address
You can of course make it even simpler – don’t use custom IPs 🙂 But I have seen requests to do this, so there we go.
Another reason to keep things simple, in some areas of vRA you cannot add PROPERTY GROUPS when needed.
Example – Approval Policies. You could create an approval policy where the approver has to enter an IP, and the requestor only sets the VLAN.
But approval policies don’t allow pre-configured property definitions or even groups
So you’d have to enter all the IP properties in there as well and it gets easily cluttered ..
Using above example – I created an approval policy where the approver has to enter an IP before the VM is being deployed
The requestor just selects a hostname and VLAN / Network
Which will require approvals
The approver can then enter the IP
Annoyingly the approver has to click the View request link to see which VLAN has actually been requested
So the approver enters an IP, hits Approve
And VM is now deployed with an approved IP.
Why would you do this ? Well there are actually requirements like that – where for example vRO is no option due to internal processes / skills and therefore certain steps in external systems (DNS, IPAM etc.) need to be done manually, still.
Using the approval process, a developer can request a VM in a VLAN, but the IT department dictates which IP etc., so there aren’t any conflicts. Especially useful if you use Option 1 and manage IPs outside of vRA.
Custom properties are great to some extent .. you can even give requestors the option to select NSX Security Groups etc.
Example:
But let’s leave that for another time 🙂