VMware vCAC IaaS Optimization Guide

Update 04/22/15: After further investigation around the effectiveness of these optimization tips on a vRA 6.2.1 environment, I am convinced that several of the tweaks do in fact provide some level of perceived IaaS UI performance improvements. I’m very interested in hearing your feedback on these findings (i.e. give it a try and let me know!).


Update 12/10/14: I have been advised that the optimization tweaks highlighted in this article will not provide any added benefits to vCAC/vRA 6.1 or 6.2. This is due to the way the IaaS interface is now presented back to the user (via the vCAC appliance vs. directly to the user session). The good news is VMware dev’s are hard at work at baking optimization right into the products, starting with a significant boost in the recently released vRA 6.2.

VMware’s vCloud Automation Center (vCAC) can transform how an enterprise delivers IT. It’s out-of-the-box functionality will help IT deliver Infrastructure-as-a-Service (IaaS) along with X-as-a-Service (XaaS / Everything-a-a-S) in a matter of clicks. Once extended into the datacenter’s ecosystem with vCAC’s extensibility engine, it will help integrate, orchestrate, and automate native and 3rd-party tools, services, and infrastructure, thrusting the enterprise into a new level of self-serviced IT efficiency.…

Using VSAN Storage Policies in vCloud Automation Center

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.…

vCAC Property Dictionary: Customize Service Requests with Dynamic Menus

//Update// – this procedure works with vCAC 6.2 (not in 6.1). The UI will look different, but same concepts apply. The property dictionary in vCAC 6 is located at Infrastructure (tab) –> Blueprints…

In a previous post I discussed the benefits of utilizing vCloud Automation Center’s Property Dictionary to add input options during the application request process. This is one of the quickest ways to add some flare (and serious functionality) to the application request and allows users to have a little more granularity in the service selection process. The Property Dictionary – and custom properties in general – also help drive down the number of Blueprints thanks to the logic that can be baked right into the process.

Let’s review (from previous post)
In addition to creating a custom property, which can trigger external actions (workflows), you can create property definitions that utilize vCAC’s built-in reserved custom properties, which can be used take a user’s input and apply it to an existing custom property – think of it as an answer file of sorts. For example, a drop-down list that presents the networks available to a given Provisioning Group and allowing users to select a preferred network. The property dictionary can also be used to build relationships between parent and child definitions to provide a more dynamic and nested functionality – the user selects a location (“Datacenter A”, parent) and, based on that selection, only appropriate networks (“NetA”, “NetB”, “NetC”, children) dynamically become available.

Use vCloud Automation Center’s Property Dictionary to Customize ServiceRequests

As I’ve alluded to on more than one occasion, VMware’s vCloud Automation Center (vCAC) is more than just a cloud portal. It is a solution designed to take defined business policy and requirements and apply them to the underlying IT systems, providing a governance model that delivers infrastructure-as-a-service (IaaS) with business agility in mind. Once defined, those policies are applied to vCAC’s individual policy definitions to build a “mesh policy” that provide the governance and controls for self-service, automation, and lifecycle management. The result is a finely-tuned service deployment model that defines the applications (blueprints), where they can be deployed, who can deploy them, and under which circumstances they are (or aren’t) allowed to be deployed. More than just a cloud portal.
vCAC 5.1 provides a ton of this capability “out of the box”, but the solution can also add a tremendous amount of additional capability using built-in control concepts, custom properties, and native integration with external tools such as PowerShell, vCenter Orchestrator (vCO), and others. The possibilities are immense. Those of you who are familiar with vCO will immediately realize the power of that last statement. If you’re not familiar with vCO you should stop reading this, download/deploy the vCO appliance, and make it your best friend…then come back and finish reading.