vRA is great at deploying servers in an automated fashion, but to really use the built in functionality for an organization some additional information should be requested to properly place the workloads in the environment. This post covers how to ask users for the correct information to properly determine the placement location of new server workloads.

Cluster Placement

The first placement decision that needs to be made is which cluster the workload should be placed on. This can be done with reservations and reservation policies but often comes with some blueprint sprawl. We’d like to be able to ask the requester which environment the workload should be placed on. To specify a cluster (which could include a cluster on a different vCenter or datacenter) we’ll modify an xml document stored in the IaaS Server(s) which will describe our datacenters. In my example I’ve got two clusters in a single vCenter named “Management” and “Workload”. My clusters are shown below.

Before you begin the next section stop the VMware vCloud Automation Center Service on the IaaS Server when there are no deployments being executed.

Go to the C:\program files (x86)\VMware\vCAC\Server\Website\XMLData folder and modify the “DataCenterLocations.xml” document stored there. Change the name and descriptions to match your naming. Save the file and when you’re done start the VMware vCloud Automation Center Service up again.

Once you’ve modified your XML file, you’ll want to go and tag your compute resources with the information in that xml file. Go to the Compute Resource for that cluster and change the “Location:” field to match to the correct tag. The example below shows my “Management” cluster being tagged with the “Management” location.

Once you’ve tagged your resources you can modify your blueprints to show the location on request if you’d like. We’ll use a different method but if this is all the further you’d like to go, you can do this here.

If you select that check box you’ll see the following on the request form. Again, this is an option but not used for the rest of this post.

Dynamic Requests for Network and Storage Locations

Create vRealize Orchestrator Actions

So we can now pick a cluster which is a great first step, but we’ll also want to pick the network and datastore to place the machine. This isn’t that difficult, we can use custom properties to do this, but what if the network or datastore selection depend upon the cluster we’ve selected previously? Well we can use vRO actions to help modify the list of resources in which can be used.

To make this selection we need to create a new action in vRealize Orchestrator. Login to your orchestrator instance and create a new module to house some placement actions.

Inside the new module create a new action that will help filter based on a location input. The example below takes a Location variable (which will come from vRA) and based on that information returns an Array\string with the appropriate portgroups. The script below uses an array and each Cluster will have it’s own portgroup list specified and returned. If not a string should be returned asking for a location to be specified.

The same sort of script can be used in another action to specify the name of the datastore to be selected.

It should be noted that the script I’ve used is very basic and hard codes the datastore names and portgroup names for the clusters into the script. You can get fancier and dynamically grab this information if you’d like and return that data as well. This is meant as a quick way to specify information.

Create Property Definitions

Now that we’ve got some scripts that will filter our portgroups and datastores, we need some property definitions in vRA. The first will be the cluster selection. Create a new vRA Property Definition named “Vrm.DataCenter.Location” and give it a label like Cluster. The display order should be 1 or at least very low since it should be selected first. The Data type is “String” and probably should be displayed as a “Dropdown” list. I’ve specified a static list for the values and updated the list with a name and a value for each of the clusters. The “values” listed in this list will be passed to vRO as the inputs for the scripts created earlier so name the appropriately.

Now we will create two additional property definitions for the portgroup and the datastore selections.The portgroup definition should be named “VirtualMachine.Network0.Name” and your own label. Data type is string again and displayed as a dropdown list. The important part is to select “External values” and then click the button to use a script action. Navigate to the vRO script you created earlier in this post and then click edit in the input parameters. Bind the input parameter to the Location property that you specified in the last step. Then click OK.

Repeat the process for datastores by specifying the “VirtualMachine.Disk0.Storage” property for the name and the script action should match your datastore action in vRO. It can also be bound to the location property previously created.

Create a Property Group

Now that we’ve got three different property definitions we can group them together into a property group to easily assign them to our blueprints later on. Create a new property group with your own naming methodology and add the following custom properties:

• VirtualMachine.Disk0.Storage
• VirtualMachine.Network0.Name
• Vrm.DataCenterLocation.Location

Each of the properties should have the “Show in Request” option selected and the “Vrm.DataCenter.Location” property should have the values of your Clusters listed as a comma separated list.

When you’re done, you can go to one of your blueprints and add the property group to it’s list of properties.

Results

Now if we go to request our blueprint we’ll be prompted for several different options. Cluster which will have our statically assigned options listed in the drop down. But then we’ll have PortGroup and Datastore which will also have dropdowns but their values will depend on the selection made in the cluster field. For example, here you can see that I’ve selected the “Management” cluster and my datastore has a single option listed.

While if I select the “Workload” cluster I have different options listed for the datastore.

Summary

Placement decisions are a big part of providing flexibility for your automated deployments. Without them you’ll have to manage extra blueprints, reservations and policies to ensure that workloads are placed in the right spot and this can be an administrative nightmare. Hopefully this post shows you some easy ways to manage placement decisions for your environment.