In my last previous two posts on vCloud Automation Center (VC-AC or vCake if you prefer) I looked at ensuring you had the pre-requisites and doing the installation itself – suitable for PoC or HomeLab. Now I want to turn my focus to how you configure vCAC to speak to vCenter – vCAC has the ability to provision to whole host of resources – virtual, physical and cloud. But I imagine in the first instance it will be to vSphere that you might first turn.

With a clean installation there’s a couple of admin constructs to put together before you can deploy your first VM. These are:

• Credentials – These are the usernames/passwords used to authenticate to the resource. Interesting they held separately from the actual adding of the resource itself. 
• Endpoints – These are where the URLs or FQDNs of the resources are held, and once you’ve typed in the URL for the vCenter, you select the credentials you established earlier. That’s an interesting separation – because if your provisioning resources – vSphere, HyperV, Xen – use the same domain username/password to gain access – the credentials could be re-used. I bet in the real world were people have a hybrid sources for provisioning they have different username/password for additional security. Rather than one ring to rule them all.
• Install an Agent – Dependent on the resource in question – you will need to install an agent on the vCAC server to communicate through to the resource. vCAC has one single agent setup.exe – from within which you use radio buttons to select which resource you’re connecting to.
• Enterprize Group – This is system wide container that you can use to pull in existing VMs, vApps, Templates – and then advertise them to business units within the vCAC instance. If you know your way around vCloud Director I guess its akin to having an Org that just contains catalog which is then published to all other Orgs. I think the way vCAC does this is neater – because to do this in vCD you need to create an Org and a OrgvDC just to make collection of vApps available to every other Org in the same vCD instance – which seems somewhat contrived configuration – a workaround rather than by design. Just sayin’
• Machine Pre-fixes – This is one of the methods vCAC has for naming VMs, and it kinda reminds me a little like VMware Horizon View method of naming VMs in a virtual desktop pool – it allows prefix piece of text followed by a numbering mechanism to create machines with a naming convention like corphq001, corphq002 and so on which is fine for quick provisioning tests.
• Provisioning Group – Are method of controlling who has access to which resources by assigning AD groups to vCAC roles such as Manager, Support or User roles. Using these provisioning groups you can assign the Machine Prefixes and AD DSN Values to control users/groups can be added. Once created you assign allocations of number of VMs, CPU%, Memory% and Storage allocations using reservations.
• Reservations – As you would expect you can create reservations in vCAC and assign them to provisioning groups – the important thing here is unlike with say vCloud Director – tis doesn’t create resource pools on the VMware HA/DRS clusters. These reservations/allocations are monitored and tracked by vCAC – so if they are meet its vCAC that prevents them from being exceeded. If you like vCAC becomes the source of admission control to the tenants – although fundamentally it’s where those resources come from vSphere, vCloud Director, HyperV, Xen that decided if they are granted.
• BluePrints – Are VMs, collections of VMs or physical definitions that actually give the tenant something to select when they need a new compute resource – they are akin to vCloud Director vApp Templates or vSphere Templates. These blueprints also have security settings so you can control if someone can connect to the compute resource with SSH, RDP and so on – as well as many other privileges and rights. BluePrints can be defined by the Enteprize Admin and made Globally Available to every provisioning group, or they can be created by the Provisioning Group Manger and made available just to its members.
• Self-Service Portal – The core vCAC is portal in its own right which only displays the right content to the right context based on the user credentials – however, there is a much simpler self-service portal which offers a UI which might be a bit more easier on the eye.

As you can see there’s quite a bit of work to do in first setup – the savings in time come once you have consumers onboard and using the system itself. As the post title suggests my focus is on vCenter/vSphere in this instance, but I will be walking through all the other compute resource endpoints as my learning progresses…

Step 1: Add vCenter Credentials

1. After logging you need to select the vCAC Administrator panel and select Credentials

2. Select the New Credentials link, and complete the form with usual suspects. The friendly name here will be used elsewhere – so you may want to use something like the vCenter FQDN rather than “vCenter for New York” as I have done. I think its likely that in most production environment the “administrator” account would not be used, but hey, this is a lab environment right?

Once the task is completed click the green tick to save the entry.

Step 2: Add vCenter as an Endpoint

Once the credentials are added we can include a vCenter as compute resource “endpoint”. There term endpoint is used to describe the relationship between vCAC and management system its communicating too. Once instructions have been sent to vCenter (or what the endpoint is) the tasks becomes that endpoints responsibility – what vCAC will do will monitor that process and feedback responses when the endpoints work is done.

1. Under vCAC Administrator, select Endpoints

2. Select New Endpoint

3. Again, type in the usual suspects into form – notice the https and the reference to the SDK path to the vCenter, not the raw FQDN to the vCenter server:

Step 3: Install the vCAC Agent for vCenter

Now that vCAC has both credentials and knows of the vCenter as an endpoint – we need to install the DEM Agent to the vCAC instance to it communicate to vCenter/vSphere. The Agent ships as single setup .exe but is used to enable vCAC for many, many endpoints…

1. The agent can be found in the main /setups directory of the core vCAC 5.1 installation files currently called “DCAC-Agent-Setup.exe”

2. During the installation of the agent, you will need set a name – and the FQDN and port number of the vCAC server – in my case I was installing the agent to the same Windows instance.

3. Next you need to select type of agent you want to install. In our case its the agent for vSphere. The Agent can be installed as many times you like for different targets…

4. Finally, you need to specify the name of the endpoint as defined in vCAC in Step2. In hindsight I wish I’d used the FQDN such as “vcnyc.corp.com” rather than “vCenter for New York” as I think it unlikely that I would change the hostname of my vCenter – and another admin looking at my configuration would be able to locate that more efficient.

Agents like this when the are added to the Services that get started, and can be stopped and restarted like another service. vCAC install appends this friendly endpoint name to each agent:

You can check the status of the agent by browsing to C:\Program Files (x86) \DynamicOPs \DCAC Agents \<NameOfAgent> and logs. The log file can tell you if the service started correctly and if it connected to the endpoint successfully:

Step 4: Create an Enterprize Group

1. The next stage is to create an Enterprize Group.  Again this appears in the vCAC Administrator pane, under Enterprize Groups – where you can click (surprise, surprise) the New Enterprize Groups.

2. Type in a friendly name for the Group together with the Enterprize Admin that will manage this group – and then select the compute resources it will expose. In my case the connection to vCenter enumerated my two clusters called “Gold and Silver”. When I recreate provisioning groups – I can control if the group can see all the clusters or just some. For me an Enterprize Group is little (but not massively so) like a Provider vDC in vCloud Director which can contain just one cluster or many (sometimes referred to as an ‘elastic vDC’ in the literature on vCD)

Step 5: Set Machine Prefixes

One method of naming new machines that are provisioned by vCAC is with a prefix. It can be quite handy in your lab environment if you just want to spin out a bunch of VMs quickly, and you’re not to bothered about allowing the tenant to name the VMs as they wish, or meeting some global corporate standard for naming machines.

1. You will find the option to set machine prefixes under the Enterprize Administrator node:

2. And yes. Guess what. There’s a link green link called “New Machine Prefix“

The first part of the prefix is in my case corphq and 3 digits will be added to the end 000, with the starting number being 0. As new VMs are provisioned you will see this number increment here (1,2,3,4 and so on). It can be reset down to a lower number if you so wish.

Step 6: Create a Provisioning Group

Next we need to create at least one provision group.

1. Provisioning Groups can be created under the Enterprize  Manager node, and  Provision Groups

2. Under there you will see a New Provisioning Group link, which will open up page for creating the group itself:

This particular provisioning group will be allowed to provision new VMs to the Gold Cluster – so I called it CorpHQ Production. The group manager email is used if enable any “approval” process. So if a user in the “CorpHQ – Organization Admins” creates a new VM, its rmoorcroft@corp.com that would receive an email for such requests. By default the approval process is not switched on. Notice I how I set the “Default Machine Prefix” to be the one I defined earlier called “CorpHQ”. The AD Container value controls where VMs added to the domain and in the world of Windows and Group Policy – what policy settings they would acquire as a consequence. Finally, some delegation – in my case I reused some users and groups I’d made previously when delegating responsibility for vCloud Director. So Reggie Moorcroft (RMoorcroft) who was the Organization Admin in my vCloud Director environment was used as the Group Manager role, and Luke Maverick (LMaverick) was used as the support role, and for the users I added my group “CorpHQ – Organization Admins”. The main thing to mention is despite the fact that vCAC is in the CORP domain, these assignments are typed manually, there’s no browse option to search or add people from the AD Domain…

Once the provisioning group is created – you will see that there are no limits or reservations assigned to the group. Although these reservations currently show 0% that means there nothing is being consumed – and they could create as many VMs and use as much memory, cpu, disk as they wished. Imposing some constraints on the group is our next step

Step 7: Set and Assign Reservations

1. Reservations can be defined under Enterprize Administrator and Reservations, and select Virtual

2.  The first page of the Reservation – allows you to set the compute resource (gathered from the Enterprize Group created earlier) – it populates the “Name” field with this text, but you can change it as you wish. Additionally, this reservation is then assigned to the Provisioning Groups – as well as quota of VMs they are allowed to create.

Priorities control a situation where multiple provisioning groups are fighting over the same compute resource (in this case the Gold Cluster). So you can give one provisioning group priority over another.

I’ve yet to investigate Reservation Policies – but given the name – I assume the idea is rather setting these parameters on each and every Provisioning Group you create – you create a policy object to store those settings – and then apply them to the Provisioning Group instead. Thus gaining consistency, and reducing per-Provisioning Group administration.

Where things get interesting is the “resource tab”

3. Under the Resources Tab you can control access to Memory, Storage, and Networks. Here I was VERY NAUGHTY. I actually reused many of the components that had actually been created by vCloud Director earlier this year. So I allocated access to 20GB of memory, and to Teir1/Tier2 storage from within the cluster – and made the default network to be used the DvS Portgroup created by vCloud Director. I reckon this probably really bad practise. If you have vCloud Director I think you should be using it alone. What I’m doing is giving vCAC access to both vSphere AND later vCloud Director methods of presenting VMware compute resources. That stems from a lack of resources in my lab more than anything else!

4. Alerts – by default alerts are turned off, but seems sensible if you are going to impose limits and reservations – that some should be informed about them if they are coming close to being exceeded. Once enabled you can control the thesholds for when they are triggered, who gets the email, and how frequently. I recommend filling people inboxes with so much email they generate rules to send it to trash [ironic joke zone]

Step 8: Create a BluePrint

The simplest type of BluePrint is one that just re-uses your existing vSphere Templates and Guest Customization from vCenter.

1. Under Enterprize Administrator and Global BluePrints, you can select the link to create a New BluePrint for Virtual

2. This should open the BluePrints form like so:

 

I think most of this is self-explanatory, but there are some options that worthy of note.

Firstly, “Global Blueprints” allow you to make this blue print available across ALL provisioning groups. For me that’s similar to the “Gold Master” that can be made available in vCloud Director by publishing the catalog and making it available to all Organizations. In order to remove this setting and make it available just to the Provisioning Group called “CorpHQ Production” you do have to be on the “Group Manager” permissions list of a Provisioning Group. Previously, I only had the RMoorcroft account listed, so I went back to the Provisioning Groups and added CORP\Administrator so I would have rights as well. T

The Prefix option – just means to use the default machine prefix that was attached to the Provisioning Group in Step 6.

In my case I didn’t enable the “Approval Policy” but if I did – all the group manager email address specified on the Provisioning Group would receive an email when new provisioning attempts were made.

Max # Per User allows you to limit the number of VMs per user out from the quota that was assigned to the group.

3.  Under Build Information we can indicate what process will be used to actually generate the new VM. In this case I had to change – Platform Type to be vSphere (vCenter), BluePrint Type to be Server, and Action to be Clone using the CloneWorkFlow as the Provision Workflow type…

This updates the webpage to allow the “Clone From:” option and to browse the list of templates in vCenter.

The Customization Spec has to be manual typed in (there’s no capacity to browse the Guest Customizations in vCenter).

After a wee while, vCAC enumerates the default “Machine Resources” (I gave my Windows 2008 R2 Enterprize Template just 1vCPU and 1GB of memory). When you done here, the “Security” tab is worth looking at – as it has some controls over what the owner of the VM can do…

Step 9: Install the Self-Service Portal (Option)

Were almost ready to deploy our first VM via vCAC on to the vSphere infrastructure. In fact you could do that right away using the “Self-Service” node in vCAC. What’s a little bit neater is to use the self-service portal which is a little friendlier from a UI perspective. The portal installer can be found in the “Extensibility” Zip file under the /setups directory and its called “DCAC-Self-Service-Setup.exe”. Be sure to have your vCAC license file handy because it will ask for it just like the main installer did for vCAC itself.

As with vCAC the self-service portal will need access to the Microsoft SQL Database:

Together with the FQDN and Port Numbers for the Manager and Model Manager Service

With the management credentials for the self-service portal as well.

 

Once the installation has completed you should be able to access the self-service portal from this URL on the vCAC server:

https://ubervcac.corp.com/DCACselfservice

Step 10: Create VM from vCAC Self-Service Portal

You can make a new request for a VM from the self-service portal by clicking the “New Request” button at the top of the page. This should show the blue prints available to your logon – via that login group  membership of the Provisioning Group.

 

A simple pop form appears to allow the end-consumer to specify a limited number of options:

Under “My Resources” and “My Machines” a consumer can track and trace the progress of their requests

From this menu system the user can connect via Microsoft RDP. Remember the right to do this controlled by the OS ACL, not by vCAC…