VMware vCloud Automation Center is the center piece of VMware’s Software-Defined Enterprise vision. It is also the primary user and admin interface for enterprise and application services, and therefore it makes a lot of sense for vCAC to be the core integration point for the SDDC.

Rawlinson Rivera (@PunchingClouds) recently posted a blog post titled “VMware Virtual SAN Interoperability: vCloud Automation Center“, where he highlights the use of vCloud Automation Center (vCAC) 6.0 to deploy applications directly to a VSAN Datastore while also leveraging a VM Storage Policy. In short, the desired storage policy is applied to the template backing the vCAC Blueprint. Once provisioned, the resulting machine adopts the associated storage policy and the rest is glorious, app-centric VSAN storage consumption. I recommend reviewing that post to get a better idea of what we’re doing here.

So now that we have a basic understanding of the interoperability between vCAC and VSAN, let’s dive into some more advanced concepts for a glimpse into the art of the possible by expanding on Rawlinson’s example and using some of vCAC’s extensibility features to deliver greater functionality.The integration between vCAC and VSAN can greatly enhance how applications are provisioned.  Since storage policies can be configured per-application or VM, you can specify varying policies based on the use case, tier, application criticality, SLA, etc…all backed by a common VSAN Datastore. If you are not familiar with VM Storage Policies, I highly recommend gaining an understanding of when/why/how to use them before continuing.

vCAC + VSAN,  VMware vSphere Blog

Overview

vCAC provides some pretty awesome extensibility in the form of the Property Dictionary, Custom Properties, and the ability to invoke vCenter Orchestrator workflows during pre-, active-, or post-provisioning states. Using some of the out-of-the-box capabilities of vCAC, we can allow users to actually select the storage policy when an application is being requested — and that is what this post is all about! But first, let’s review the different options for accomplishing this task:

  1. Wait for VMware to add native visibility into Software Policy-Based Management (SPBM). In the spirit of tighter integration, you can assume that this is something VMware is working on.
    Pro: should be pretty obvious.
    Con: wait.
  2. Use vCAC’s Property Dictionary and Custom Properties to provide a drop-down selection during provision. Once requested, vCAC uses a vm template that is pre-configured with the corresponding VM Storage Policy.
    Pro: this method provides a fairly straightforward means of accomplishing the task at hand by utilizing the Property Dictionary and Custom Properties with minimal learning curve.Con: a template has to be created and preconfigured per each storage policy option.
  3. Use more complex extensibility options to dynamically allocate a user-selected VM Storage Policy during or after a machine is provisioned.
    Pro: although the most complex of these options, this will provide the greatest flexibility and automation.
    Con: more complex, requires a solid understanding of vCAC’s extensibility and vCO to build associated workflows and API integration.
For this post, I will walk you through #2: Use vCAC’s Property Dictionary and Custom Properties to provide a drop-down selection during provision. For those who think option #3 sounds pretty cool, I do plan on [eventually] putting together a “how-to” for that as well.

Tasks Summary

This use case will involve utilizing vCAC’s Property Dictionary and the “CloneFrom” Custom Property to allow a user to specify the desired storage policy during application provisioning. The goal is to accomplish this without using any advanced extensibility or even leaving the vCAC or vCenter UI’s. The process looks something like this:
  1. Create a VM Storage Policy based on your use cases (I will use “HighIO” and “LowIO” examples)
  2. Create a vm template for each machine + desired storage policy
  3. Apply appropriate storage policy to each vm (template)
  4. Create a Property Dictionary definition in vCAC using the “CloneFrom” reserved custom property
  5. Apply the Property Definition to a vCAC Blueprint
  6. Go!
In true virtualjad form, I have provided very detailed step-by-step instructions for building this out. Do not be intimidated by the number of steps / screenshots…this should only take a few minutes to complete.

1.) Create your VM Storage Policies

 

Steps
 

Screenshot

Log in to the vSphere Web Client.From the Home screen, select “VM Storage Policies”

 

Click the ” + ” icon to Create a new VM storage policy
 

Name the Storage Policy (in this example, i named it “HighIO Apps”)Provide a detailed description of the policy.

Click “Next”…

 

From the “Rules based on vendor-specific capabilities” drop-down, select “VSAN”  

Use the drop down to add each of the desired storage capabilities to the list.For the sake of this exercise, I will add all 5 VSAN rules…

Add the first rule…

– Number of disk stripes per object

 

Add the remaining rules…- Flash read cache reservation (%)

– Number of failures to tolerate

– Force provisioning

– Object space reservation

 

Once added, customize each rule to reflect your end objective for this Storage Policy.Make changes to reflect what your objectives are for this policy.

 

For this “HighIO” policy, I want to make make changes that will help guarantee IO to the associated applications. Enter the options that best suit your applications.Note: Storage Policies can back-fire if configured improperly — BE SURE YOU KNOW WHAT YOU’RE DOING!



Click “Next”…

 

A list of compatible storage devices will be displayed — select the appropriate VSAN Datastore.Here I have a single VSAN Datastore using the default “vsanDatastore” name.

Click “Next”…

 

Review your configurationClick “Finish” to apply the policy

 

Now we will repeat these steps to create another VM Storage Policy.Name the policy and provide a detailed description. In this example, I’m creating a policy called “LowIO Apps”

Click “Next”…

 

Add each VSAN rule and enter the desired options.For my “LowIO” policy, I’m using all the default VSAN settings, although this doesn’t necessarily reflect a Low IO option by any means!



Note: the default policy is configured optimally for the majority of all VSAN workloads…we’ll use defaults.

Click “Next”…

 

A list of compatible storage devices will be displayed — select the appropriate VSAN Datastore.Here I have a single VSAN Datastore using the default “vsanDatastore” name.

Click “Next”…

 

Review your configurationClick “Finish” to apply the policy

 

You should now have two defined storage policies…
 

2.) Create a VM template per Storage Policy

As a prerequisite to the proceeding steps, you need to create at least two templates in vCenter that will each receive a unique VM Storage Policy. But first, we’ll need to create the VM’s and apply the storage policy to them before converting to templates (VM Storage Policies can only be applied to VM’s).  My example is built on an Ubuntu guest, so I created two identical Ubuntu VM’s named “ubuntu_v12-04_HighIO” and “ubuntu_v12-04_LowIO“. The names are important as they will be exposed to vCAC and users in later steps and should represent the storage policy one way or another.  You should also avoid spaces in the names to prevent problems in vCAC later.

3.) Apply Storage Policies to each VM

Steps

 

Screenshot
Navigate to and select the first VM that was created in Step 2. In this example, I’m selecting the “ubuntu_v12-04_HighIO” VM.

Right click on the VM and select “All vCenter Actions” -> “VM Storage Policies” -> “Manage VM Storage Policies…”

From the storage policy drop-down menu, select the appropriate storage policy for this VM (in this case, I’m selecting “HighIO Apps”)

Once the policy is selected, click “Apply to disks” to apply the policy to the VM’s disks.Click “OK” to apply…

Now we will repeat these steps for the other VM.In this example, I’m selecting the “ubuntu_v12-04_LowIO” VM.

From the storage policy drop-down menu, select the appropriate storage policy for this VM (in this case, I’m selecting “LowIO Apps”)

Once the policy is selected, click “Apply to disks” to apply the policy to the VM’s disks. Click “OK” to apply…

To check the status of the Storage Policy, select the VM on the left, navigate to the “Manage” tab, then select “VM Storage Policies”. Here you can see the “LowIO” policy has already be applied to the VM and is in a Compliant state.

While the policy is still being applied you will see a “Not Compliant” status. For the HighIO policy this can take a few minutes while all the back-end work is completed to enforce the policy. Since I selected higher host failure to tolerate and 3 disk stripes per object, lots of data movement is required before this becomes compliant.

Once policies have been applied and are in a compliant state, it’s time to convert the VMs to templates. This is required before vCAC can uses these in a “clone”-based Blueprint.

Both templates are now ready to be consumed by vCAC…

4.) Create a new Property Definition in vCAC

 

Steps
 

Screenshot

Log in to vCAC and navigate to the “Infrastructure” tab and select “Blueprints” from the left menu pane. In the Blueprints section, select “Property Dictionary”

Click the ” + ” to add a new Property Definition…

Name: CloneFrom (this is the reserved custom property that we will be overriding)

Display Name: Select App Tier

Description:

Control Type: DropDownList

Required: yes (checked)

Click the green check to save…

Once saved, select “Edit” in the “Property Attributes” column…

Click the ” + ” to create a New Property Attribute

Type: ValueList

Name: CloneFrom

Value: Enter the template names EXACTLY as they appear in vCenter. Use a comma to separate each name.

Click the green check to save…

Click “OK” to apply

5.) Apply the Property Definition to your vCAC Blueprint

 

Steps
 

Screenshot

Navigate to “Blueprints” in the Infrastructure tabFind the Blueprint that you want to add the policy selection option to. In this example, I’m using an Ubuntu blueprint

Select “Edit” or simply click on the Blueprint to edit it’s properties…

Navigate to “Properties” tab. Select ” + ” to add a New Property

Name: CloneFrom

Value: leave blank

Prompt User: Yes (checked)

Click the green check to save…

Click “OK” to apply

6.) Go! – Test Your Blueprint

 

Steps
 

Screenshot

From the “Catalog” tab, request the catalog item that contains the custom property (previous step).

Note: there is an assumption that you have already published and entitled this catalog item. If not, you need to go back and do that before it is visible in the Catalog.

You should see the new field titled “Select App Tier” in the request form. Use the drop-down to select one of the preconfigured options. In this example, I select “ubuntu_v12-04_LowIO”, which corresponds to a template with the exact name in vCenter.

Submit the request…

Once provisioned, use vSphere Web Client to check the VM Storage Policy applied to the new machine.

Here you can see “ops-5024” is configured with the “LowIO Apps” policy and is compliant



Success!! (if not, leave a comment or take it to twitter)

 

Final Thoughts

There are many tweaks that can be done to this guide to deliver a result that works better for your environment. For example, “HighIO” and “LowIO” policies aren’t really the best example of how to use VM Storage Policies (in hindsight). I used these options purely as an example and representation. Also, since the drop-down menu in vCAC must match the VM template name, you should be able to come up with something a little more descriptive of the storage policy – just as long as the template name matches the property definition values where it is noted.

The ultimate goal for this post is to get you thinking about the art of the possible with vCAC and VSAN (individually or combined). Please feel free to leave a comment or start a discussion on twitter!

Enjoy!
++++

@virtualjad

1 Comment

  1. This procedure looks doesn’t work with vRA 7.x. The VM clones the correct template but put the VM using the first storage defined on the reservation not the Storage Profile associated with the template.

Comments are closed.