I am aware that that’s not a catchy blog post title. In fact, it doesn’t even really describe the problem or solution very well – for that I need to go into a little bit more depth!
Suppose I have configured a Reservation with two Networks ticked (“192.168.1.0-VLAN1” and “192.168.10.0-VLAN10”). As you can see in the screenshot below, each of the networks has a Network Profile created and assigned with a network pool to provide IP addressing for the VMs.
When I deploy the Blueprint without any custom properties, the network selection is round-robin and so the VM gets it’s virtual NIC assigned to “192.168.1.0-VLAN1” or “192.168.10.0-VLAN10” alternately – this is the expected behaviour. The Virtual Machines are assigned an IP address based on the Network Profile of the assigned network.
All good so far. Still with me?
What if during deployment I want to specify the Network via the Request form? This is a fairly standard request, so I add a new Property in the Property Dictionary which maps to the Virtual Machine’s first network adaptor:
Then I edit the Property Attributes to create a value list of the networks selected earlier, this will populate our dropdown box:
Now I will create a Build Profile to be able to assign the dropdown to my Blueprints. The custom property matches the Property Dictionary definition we created before, which is linked to the Virtual Machine’s first network adaptor. The property is set to prompt the user.
Finally, I apply the Build Profile to the build by editing the Blueprint and ticking the box under properties:
Now when I request a machine with that Build Profile assigned, you see the dropdown:
Excellent! BUT, if I deploy the blueprint and and set VirtualMachine.Network0.Name = 192.168.10.0-VLAN10 the virtual machine is deployed and assigns the correct Network to the VM but it does not use the correct Network Profile. This means that no IP address is assigned from the Network Profile pool (IPv6 auto instead) and the VM is inaccessible:
Next I tried another property as part of the VirtualMachine.Network0 object that I can use to select the Network Profile – ProfileName.
When I set VirtualMachine.Network0.ProfileName to the Network Profile for 192.168.10.0-VLAN10 (i.e. the profile I mapped in the reservation, “DefinIT Lab 192.168.10.0”), the virtual machine deploys with a round-robin selection of the Network, and is assigned an IP address from the specified Network Profile. This is a problem because only 50% of the time will the VM be on the correct network for the IP address assigned by the network profile – and the more networks in the reservation the greater the chance that it will be incorrect! In the image below the Network Profile has applied and assigned an IP from the pool in the .10.x range, which is correct, but the actual connected network is wrong.
When I set both VirtualMachine.Network0.ProfileName and VirtualMachine.Network0.Name the virtual machine will deploy with the correct Network assigned to the VM, but the Network Profile does not not take effect and the VM is not assigned an IP address.
So, how do I correctly select a Network and have the Network Profile apply correctly?
Well, it turns out that in 6.1 there’s an as-yet undocumented property called VirtualMachine.Network0.NetworkProfileName which will indeed do what I want it to do. So, I can now create a new Property Definition dropdown list:
And add a comma separated list of my Network Profiles to a ValueList in the Property Attributes.
The keen-eyed will notice that I’ve changed the name of my Network Profiles – this was because I found that I needed to remove the spaces and “.” in the name. It does not work when you have those characters, and before you ask, the previous methods tried did not work in my lab or a customer site, even with the Network Profile name changed!
Now when I modify my Build Profile to use the NetworkProfileName property and assign to a blueprint I can build the virtual machines on the correct network, using the correct Network Profile:
*Notice that I’m building 2 VMs here to test that I’ve not got lucky with round-robin!
The two VMs produced are (finally) on the correct Network with the correct Network Profile applied!
I know that was a long setup for a short solution, but I think that the process and context is sometimes just as important as the answer! I hope that was helpful!