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…