They used to be fierce competitors but now are good buddies. Who? vCloud Automation Center (vCAC) and vCloud Director. vCAC version 5.2 has just been released and it is the second release of what was before known as DynamicOps Cloud Automation Center but since the VMware acquisition of DynamicOps in July 2012 has been rebranded under the vCloud brand.
Why would you integrate these two products if they were competing with each other in the past and are perceived to do the same things?
This marchitecture slide below was used by Pat Gelsinger during his EMC World keynote and perfectly shows the relationship of the two.
vCAC is part of the Cloud Service Provisioning pillar and is a tool that can operate above heterogeneous set of infrastructure resources be it vSphere, other hypervisors, public or private clouds and physical servers. vCAC sits (among others) on top of vCloud Director which can be either private or public cloud and provides policy based (that’s the piece that controls What, Who, Where, Why, How much, How long, …) provisioning with nice, simple and extensible GUI.
The previous December 2012 vCAC 5.1 release had very little integration with vCloud Director, required vSphere access and therefore did not work with public clouds. That is not the case anymore and vCloud Director is treated as first class cloud citizen together with Amazon EC2.
Here follows brief description how to set up a vCloud Director based cloud as an endpoint and how to create a provisioning blue print.
- Create vCloud Director endpoint. vCAC Administrator > Endpoints > New Endpoint > Cloud > vApp (vCloud Director). In the public cloud scenario we would use Organization Administrator credentials, in private cloud we could use vCloud Administrator credentials.
- Perform Data Collection of the newly created endpoint. One of the Distributed Execution Manager (DEM) Workers will by using vCloud API connect to the cloud and collect available inventory.
- Once the data collection is finished we can create a new enterprise group which is basically a logical separation of the infrastructure resources. vCAC Administrator > Enterprise Group > New Enterprise Group. Name the group, add the account of the enterprise administrator and select the vCloud resources (OrgVDCs) that will belong here.
- Now we can log in as the Enterprise Administrator and start managing the group. We have to create a provisioning group which is basically a set of users that will be able to provision VMs. Enterprise Administrator > Provisioning Group > New Provisioning Group. I called my provisioning group TestDev
- Now we can create reservation of resources for the provisioning group. Enterprise Administrator > Reservations > New Reservation > Cloud > vApp (vCloud Director)
I have assigned 2606-Public OrgVDC to the TestDev provisioning group. In the Resources subtab we can select storage tiers and networks that will be available to this reservation and optionally limit memory and storage. Network profile (set of IP addresses) can be assigned to the networks as well.
- The Who and Where is ready. Now we need to prepare the What. We will create (global) blueprint which will define the VMs that the users can provision. vCloud vApp blueprint consists of component blueprint which defines the actual VMs and a vApp blueprint that specifies policies for the whole vApp.
So starting with the component blueprint: Enterprise Administrator > Global Blueprints > New Blueprint > Cloud > vApp Component (vCloud Director). In the Blueprint Information tab we assign provisioning groups that can use the blueprint, prefix for the naming of the VMs, optionally approval policy and costs.
In the Build Information tab we specify the VM template and maximums for its configuration.
- Now we can create vApp blueprint: Enterprise Administrator > Global Blueprints > New Blueprint > Cloud > vApp (vCloud Director)
In the Build Information tab we link the template to the component blueprint.
- Now we can log in as a user from the Provisioning Group, Go to Self-Service and Request a machine from the blueprint.
- After while the machine is ready to be consumed.
vCAC provisions and manages the vCloud Director vApps with the administrator account configured in the Cloud Endpoint. However as vApp is created it changes its ownership to the user who requested it. If the vCloud Organization does not contain user with an identical username as the vCAC VM requestor it will try to import the user from LDAP. This can obviously work only if LDAP is configured for the vCloud Organization which is realistic only in private vCloud Director deployments. In public vClouds you will therefore have to make sure that the user (either local or SAML imported) exists in the organization prior to vCAC provisioning.
There is one difference when licensing private or public clouds. For private clouds it is possible to use CPU socket based licensing of vCloud Suite Enterprise. That obviously does not work with public clouds and therefore per VM licensing is needed.
2 thoughts on “Integration of vCloud Automation Center with vCloud Director”