In this article, I'd like to elaborate on the ability to dynamically assign custom properties, reducing the number of blueprints. This is very similar in concept to my previous post: Applying a vCenter Customization Spec Dynamically in vRA / vRO, but focuses more dynamic sizing as a principle.

The Scenario

As an example, let's imagine we're a software company, and we have a Template for a Linux Distro, on vCenter. Currently, we're manually deploying each instance.
In our use case, the developers will be using this VM to write and test software configurations, including Apache, MySQL, Java applications and daemons, and PHP.

The Requirements

Now, as the team responsible for automation, we want to allow our developers to request Virtual Machines themselves, without killing our fabric resources.

So, the way we approach this is by introducing 5 sizes: Micro, Small, Medium, Large and Jumbo.

Each size has a corresponding resource assignment association as follows:

Micro: 1 CPU, 1 GB RAM, 16 GB HDD
Small: 2 CPU, 2 GB RAM, 40 GB HDD
Medium: 2 CPU, 4 GB RAM, 80 GB HDD
Large: 4 CPU, 8 GB RAM, 200 GB HDD
Jumbo: 12 CPU, 32 GB RAM, 1 TB HDD

We take this principle further by assigning approval policies to Large and Jumbo only.
This will encourage our developers not to use the largest configs unless really needed, in which case managerial approval will be required.

The Problem

By offering these sizes, the out-of-the-box approach would be to use one blueprint per configuration. In other words, I'll refer to our Linux Distro we are using for the Developers. Let's say it's RHEL 6, for example. We would typically have the following sized blueprints for RHEL 6:

RHEL 6 - Micro
RHEL 6 - Small
RHEL 6 - Medium
RHEL 6 - Large
RHEL 6 - Jumbo

If we wanted to add another Distro, the list of Blueprints would become rather large.

The Solution

We have a single RHEL 6 Blueprint, but we create a custom property on that Blueprint, allowing the relevant size (under the requirements section above) to be selected on request.

Size Selection on Request screen. Note: the CPU, Memory and Storage fields are read-only.

Then, we leverage a vRO workflow to read that property and then assign the relevant configuration on-the-fly.

The Implementation

Create the custom property in a Build Profile or on the Blueprint for our Size Selection.

The custom property on our Build Profile / Blueprint

Next, we create a Property Definition for the above property. This tells vRA to render the property as a specific type of control. In our case, we want a Dropdown List:

Note, above, that the Name of the property definition matches the name of our custom property in the previous step.

Next, we need to create the values for the Drop Down list. In the image above, the "Edit" link to the right (in the Property Attribute column) is how we create the values for this Definition. Click "Edit" and enter the following:

Now, we need to ensure that our Blueprint does not allow for entering values for CPU, RAM and HDD. We do this by removing the "Maximum" values for each, as follows:

Configuring no Maximums means the end user will not be able to enter values

Great, so now we have a blueprint that probably still works, but it will only assign a single CPU, 1 GB memory and a 16GB HDD no matter what option we select.

Now comes the part where we glue this all together.

Enter vRO

You need to have a BuildingMachine Stub Workflow of your own, already configured, and integrated with vRA. If you don't, no sweat, you can find you all you need to get this point by visiting one (or more) of my previous posts on this topic.

Right, so assuming we have our Building Stub WF, we simply need to fetch the property above, and then assign the other relevant properties (CPU, RAM, HDD) accordingly.

Let's go ahead and drag on a scriptable task. Then we'll edit this task and I'll show you how:

My Scriptable Task called "Determine Size" which sizes a VM.

First part of the "Determine Size" script

In the script above, we're looking for the property on the VM, set by the dropdown we created earlier. This value will be one of the following: Micro, Small, Medium, Large, Jumbo.
In line with this, we are checking to see if the value equals any of these, in which case we are setting a local variable for CPUs, RAM and Hard Disk Space accordingly.

Now, as you may have guessed, this is not yet doing anything to our VM.
This is merely groundwork so that we can determine the values to set.
Below is the other half of this script above:

Last part of the the "Determine Size" script

This is the part that does the juicy bits. Don't worry about all the code, most of this stuff is boiler plate - I simply used the scriptable portions of Actions that already exist in the vRA plugin.

This is the stuff that really does the work here. The System.getModule pieces are really just calling actions and passing in the required parameters.

And, yes, you will see that I have also called the Disk Size piece twice (two different properties).
Furthermore, we are updating custom properties as well as Entity Properties on the actual object itself so that the values trickle down to vCenter when the machine is actually built.

The result

So, it works. I went into vCenter and ensured the values were there and it all works.

Yes, I know the server names are different between this image and the one above - it's just a sample ;-)

We now only need: a single Blueprint allowing us to select sizes like cookie cutters.

The potential caveat

You guessed it. There's almost always a tradeoff.
The challenge here is that normally, vRA does resource / sizing / constraint checking on the reservations to ensure that we have enough space to provision. It's my understanding that this is even before the "BuildingMachine" phase / lifecycle state.

So, what does that mean?
Well, it means that one user may exceed the allotted reservation because at the time of checking, vRA thinks that this VM only has the default 1 CPU, 1 GB RAM and 16 GB HDD as defined in the Blueprint. However, we're modifying those values AFTER the check happened.

Now, there are two ways to overcome this. First, you could set the default values at an average of the most requested sizes, or, you could set the default values to the maximum (Jumbo) which will ensure you never run out. However, this also means that users requesting a Micro or Small will be told there's not enough space on the Reservation if that's the case for the Jumbo.

I hope it makes sense.

Feel free to ping me if you need clarity on
Twitter Handle: @T1gerShark

--Chris