vCAC

vCloud Automation Center / vRealize Automation

New VMware Product Availabilities – Now available to download

Chan Leave a comment

Update

VMware have just made a number of new product versions (mostly maintenance releases on few different products, including that of the much hyped VSAN 6.2) so a quick post to summarise the content that was released last night (15.03.2016)

  • VMware VSAN 6.2 – VMware VSAN 6.2 was officially announced in early February with a number of cool new features such as Erasure coding but unless you were a techie trying to download the software, you may have not known that it was not available for download despite being announced. That was until yesterday and the product is now available to download for every customer.

 

  • VMware vRealize Automation 7.0.1 now released and available for download
    • Release notes here
    • Product binaries here
    • Documentation here

 

  • VMware vRealize Orchestrator 7.0.1 is released and available to download
    • Release notes here
    • Product binaries here
    • Documentation here

 

  • vRealize Business for Cloud (Old ITBMS offering) is also released and available for grabs now
    • Release notes here
    • Product binaries here
    • Documentation here

 

  • vRealize Log Insight 3.3.1 is released and available to download
    • Release notes here
    • Product binaries here
    • Documentation here

 

  • vCloud Suite 7.0 is also released and available to download (here) – This includes all of the above new versions of products plus the exiting versions for vSphere Replication 6.1 + vSphere Data Protection 6.1.2 + vROPS 6.2.0a + vRealize Infrastructure Navigator 5.8.5

VMware vRealize Automation Part 10 – IaaS Extensibility – Using vRO for Blueprint Customization

Chan Leave a comment

Now the fun part of this series of articles begins where we look at truly leveraging the extensibility capabilities.

First of all, its important to understand what this word “extensibility” means in the context of vRA.

Extensibility

Machine Extensibility usually means the ability to customise the default IaaS workflows available within vRA through 2 key methods

  1. Old way: Using commandline tools (cloudutil) and vCAC Designer
  2. New (recommended) way:  Using the built in vRO workflows

This customisation lets you achieve various tasks during various stages of a machine life cycle that you cannot achieve using the default, built in IaaS workflows available within the vRA database. You do this by injecting custom logic to the built in IaaS workflows, to be executed at various stages of the machine lifecycle. Lets take a look at the details of the components involved in little more detail.

vRA database has 10, built in IaaS workflows that define the logic of how and what happens during an IaaS machine life cycle. These workflows are fully customisable. Out of these 10, 4 are for menu extensibility while the other 6 are state change workflows, , known as workflow stubs which define the actions that take place when a vRA machine reaches its various stages of its lifecycle. Given below is a list of those 10 default workflows

1 - workflows

The 6 state change workflows (a.k.a. workflow stubs) directly correspond to the 6 stages a machine can go through, which are as follows

  • State=BuildingMachine, corresponding workflow name = WFStubBuildingMachine 
  • State=RegisterMachine, corresponding workflow name = WFStubMachineRegistered 
  • State=MachineProvisioned, corresponding workflow name = WFStubMachineProvisioned 
  • State=Expired, corresponding workflow name = WFStubMachineExpired 
  • State=UnprovisionMachine, corresponding workflow name = WFStubUnprovisionMachine 
  • State=Disposing, corresponding workflow name = WFStubMachineDisposing 

You can customise these workflow stubs so that they can call out a vRO workflow for bi-directional integration with external systems. Usually, the vRO workflow is triggered before the IaaS master workflow enters a specific stage. Given below are the key states of the master workflow, with the customisable states highlighted in yellow.

2. States

Note that the difference between the machine building and machine provisioning is such that during the BuldinMachine state, VM’s created or the physical server is being built but OS Is not deployed where as the MachineProvisioned state, the OS is already deployed and may be going through customisation / sysprep or any other post deployment tasks. I have not seen these states and what each state mean being clearly documented by VMware anywhere unfortunately. Closest I’ve seen is this article at Dailyhypervisor from Sid Smith who was an ex Dynamic Ops employee. I’m quoting the below from his article which explains when the customisation work actually kicks in for 2 of the most common sub states found within the provisioning master workflow state.

  • Provisioning state – Order of execution of sub states
    • Building Machine – WFStubBuildingMachine workflow can be used to customise. Executes pre-building machine state
    • Customise Machine – Things like cpu & memory & disks are adjusted. No need to customise as the default workflow can address most requirements
    • Customize OS – Customisation spec applied – Again, not need to customise the default workflow which is good enough
    • Customize Guest – Guest agent performs guest level tasks such as disk partitioning, scripts…etc.
    • Machine Provisioned – WFStubMachineProvisioned workflow can be used to customise. Executes during pre-machine provisioned state.

Ok, now that we have a little understanding of what the default workflows are and what’s meant by stub workflows, next step is to look at how to customise some of these stub workflows.

As mentioned earlier, the old school way of doing his would have meant we would have had to use a command line tool called cloudutil and a separate installable program called vCAC Designer (downloadable from the vRA server IaaS component page). This is quite a cumbersome process and involve lot of understanding of things inside the IaaS model manager. If you fancy having a go, all the instructions are available here.

What I prefer and will use in the example below is the use of the vRO workflows that are included as a part of the vRA plugin for vRO, to achieve this customization instead (you simply run the workflows on vRO and it will automatically customise the default vRA workflow stubs within the model manager database). The vRO team has kindly made the above tedious task a lot simpler by making a number of vRO workflows that you can use to customise the stub workflows within vRA IaaS model manager DB. Once the stub workflows are customised, you can run another workflow called, “Assign a state change workflow to a Blueprint and its virtual machines” and effectively bind any vRO workflow to a blueprint so that this workflow can be automatically called during any of those customisable machine states. For example, you can create a vRO workflow to create the description of a computer account and use the state change workflow to assign that to a machine provisioning blueprint so that every time a machine is provisioned from that blueprint (assuming that you select the MachineProvisioned state to trigger the workflow), vRA will call the vRO workflow to change the description of the computer account on the AD. Any input parameters to the vRO workflow will be added automatically as custom properties to the blueprint which needs to be manually filled out with values before the blueprint can be published to the users (in the above example of setting the computer account description, you’d have to specify the description string on the blueprint’s custom properties)

The whole process of using vRO state change workflow with vRA at a high level goes something like this

  1. Install the vRA plugin to vRO – We’ve already covered this in step 9.3.3 under the heading vRO configuration, mentioned in the previous article here.
  2. Register the vRA server and the IaaS component of the vRA server with vRO – We’ve already covered this in step 10.4.1 & 10.4.2 under the heading vRO configuration, mentioned in the previous article here
  3. Install vCO customization – You do this by running the “Install vCO customization” workflow found within “Library->vCloud Automation Center->Infrastructure Administration->Extensibility->Installation” folder within vRO – We’ve already covered this in step 10.4.3 under the heading vRO configuration, mentioned in the previous article here   3. vCO customization
    1. Note that once this workflow has been run successfully, if you look at the vRA Model manager database using the vCAC designer, you’ll see the default Workflows have been modified (now appear with an increased version number) as shown below IaaS 8
  4. Assign a state change workflow to a blueprint (effectively bind a vRO workflow to a blueprint and specify which state of the machine lifecycle should trigger the call out to that vRO workflow) – We will look at this in detail below
  5. Fill out any input parameter values using the custom properties of the blueprint – We will look at this in detail below

This is quite powerful and let you associate any vRO workflow with a blueprint to be called out for numerous extensibility tasks, to be triggered at any of the following machine states

  • State=BuildingMachine, using the corresponding workflow name = WFStubBuildingMachine 
  • State=RegisterMachine, using the corresponding workflow name = WFStubMachineRegistered 
  • State=MachineProvisioned, using the corresponding workflow name = WFStubMachineProvisioned 
  • State=Expired, using the corresponding workflow name = WFStubMachineExpired 
  • State=UnprovisionMachine, using the corresponding workflow name = WFStubUnprovisionMachine 
  • State=Disposing, using the corresponding workflow name = WFStubMachineDisposing 

Lets take a practical example and see how we can assign a state change workflow to a blueprint (in other words, how to bind a vRO workflow to a machine blueprint such that when the machine state changes to a chosen state, that vRO workflow is executed) – Step 4 & 5 mentioned above. As mentioned earlier, lets assume that you have a requirement to add a description to the computer’s AD account, each time a vSphere VM is provisioned from a blueprint and joint to the domain. Given below are the steps involved

  1. Create a normal vRO workflow to change the computer account name
    1. Within the vRO client, create a simple workflow to change the description of an AD computer account. – Note that you cannot do this with the built in workflows or action elements and you need to create your own workflow with a scripted task.
      1. The workflow will have 2 input parameters as follows
        1. Input Parameter – description (type: string) – Computer account description
        2. Input Parameter – vCACVM (type: vCAC:VirtualMachine) – vRA VM object
        3. Attribute – ComputerAD (type: AD:ComputerAD) – Computer AD account 1.1.1
      2. The scripting part would look like the below   1.1.2
      3. If its easier, I’ve uploaded the whole workflow which you can just download using below link and import in to your vRO library without having to manually created the workflow from the scratch.  ChanakaE-Set Compputer Account Description in AD.workflow (make sure to change the extension from .txt to .workflow once downloaded, before importing to vRO)
    2. Run this workflow manually against a computer account to ensure the vRO workflow is working as expected.
  2. Use the built in workflow “Assign a state change workflow to a blueprint and its virtual machines” to bind the above workflow to a vRA blueprint
    1. Note the pre-reqs below
      1. I’m assuming that you have a VM / physical machine blueprint that creates a Windows VM / Server that is joint to the domain as a part of the provisioning.
      2. If you don’t have one, simply login as tenant administrator to the vRA portal and create, publish and entitle a new vSphere VM type blueprint to create one. Given below is a screenshot of the build information for you to get an idea. 2.2
    2. Run the built in vRO workflow “Assign a state change workflow to a blueprint and its virtual machines” found within the “Library->vCloud Automation Center->Infrastructure Administration->Extensibility” folder within vRO
      1. Start the workflow and select,
        1. The appropriate vRA workflow stub to enable (What you select here will decide when the vRO workflow will get executed based on the various states of the machine). We are selecting the MachineProvisioned stub as that means the workflow will get executed during the machine provisioned state, after the guest level customizations are completed (i.e. AD account for the machine has been created as a part of the customization).   2.2.1.1
        2. Also select the vRA host where the blueprint’s are located.    2.2.1.2
        3. Click Next
      2. Now browse to the blueprint you want to bind the vRO workflow & click Next 2.2.2
      3. Now select the vRO workflow to bind to the blueprint
        1. Click on the Workflow template link and type the name of the vRO workflow in the filter box 2.2.3.1
        2. Select Yes checkbox to the option “Add vCO workflow inputs as a blueprint properties” – This is the step you add the vRO workflows’ input parameters to the blueprint via custom properties. 2.2.3.2
        3. Now click submit and ensure its run successfully within the vRO client.   2.2.3.3
        4. Verify that its successfully modified the blueprint by navigating to the vRA portal (as the tenant administrator) and looking at the custom properties for the blueprint. Note that you’ll see the following custom properties automatically being added.
          1. vRO workflow ID for the workflow you’ve bound to the blueprint. 2.2.3.4
          2. The 2 input parameters required by the blueprint.
    3. Set up the AD computer account description on the blueprint properties.
      1. You can pre-specify the computer account description on the blueprint or force the user provide a description. Im going to use the latter approach.
      2. Login to the vRA portal as tenant-administrator and go the custom properties page of the blueprint.
      3. Edit the  “ExternalWFStubs.MachineProvisioned.description” property and select the checkbox “Prompt User”. 2.3.3
      4. Click the green tick to complete and OK to commit the changes to the blueprint.
    4. That’s it. You’ve now customised the vRA model manager workflow stubs to invoke vRO workflows at various stages of a machine lifecycle and have also used that customisation capability to execute a specific workflow during a machine provisioning from a blueprint.
  3. Verify the customization by provisioning a machine using the blueprint.
    1. Lets now verify our customisation is working by provisioning a VM from the blueprint.
    2. Login to the vRA portal as a business group user (in this case, its bg-user@froot.domain if you’ve correctly been following all of the vRA deployment articles I’ve published in the correct sequence) who has the correct entitlement to this blueprint.   3.2
    3. Request a machine to be provisioned using this blueprint. You’ll note that the computer account description also need to be provided.   3.3
    4. Wait for the VM to be provisioned and the request to be complete on the vRA portal.
    5. Once complete, login to the Active Directory and verify that the customised description has been added to computer account.    3.5
    6. You can further verify that the workflow has been run automatically by looking at the execution history for the workflow on the vRO client. 3.6

There you have it. A simple customisation of the vRA model manager database logic through the execution of vRO workflows makes the extensibility more fun by allowing us to call various different vRO workflows to be executed during various different lifecycle stages of a machine, through the integration of vRA with vRO.

Hope this was useful…!!

Cheers

Chan

 

 

 

 

 

 

VMware vRealize Automation Part 9 – Extensibility – Custom Properties & Build Profiles & Property Dictionary

Chan 1 Comment

vRA Custom Properties

Custom properties can be used to modify a machine throughout all stages of its lifecycle such as,

  • Request,
  • Provisioning
  • Manage
  • Retire

Custom properties can be used to achieve various objectives such as,

  • Defining the number of cores per socket on a VM blueprint
  • Customising the operating system (hostname, Sysprep information…etc.)
  • Specifying the OU for the machine account to be placed in, on AD
  • Specifying the VM disk type, determine the network placement for a machine
  • Integrating machines with external systems such as Citrix Desktop delivery controller
  • Update external systems once the machine is retired such as cleaning up AD of the stale computer account, clean up DNS, clean up DHCP…etc.

Custom properties can be added to the following sections within vRA (if same property is defined in multiple layers, the order of precedence is as shown below)

  1. Business group
  2. Blueprint
  3. Build profile
  4. Endpoint
  5. Reservation
  6. Compute Resource
  7. Storage

There are 4 main types of custom properties available

  1. Read-Only
    1. Specified value is implemented on the machine and maintained in the vRA database but cannot be changed within vRA
    2. Examples include:
      1. VirtualMachine.Admin.UUID – Specifies the UUID of the machine which cannot be changed
      2. VirtualMachine.Admin.Name
      3. VirtualMachine.Admin.AgentID
  2. Internal
    1. Specified value is maintained only in the vRA database and used purely for information purposes within vRA and has no impact on the machine itself or the virtualisation platform.
    2. Examples include:
      1. VirtualMachine.Admin.Owner
      2. VirtualMachine.Admin.Approver
      3. VirtualMachine.Admin.Description
      4. VirtualMachine.Admin.AdministratorEmail
      5. VirtualMachine.Admin.ConnectionAddress
  3. External
    1. This value is implemented on the machine and maintained in the vRA db. However its not updated in the vRA db when it changes on the machine.
    2. Examples include:
      1. VirtualMachine.Admin.AddOwnerToAdmins – if set to True, owner of the VM added automatically to the local admins group but when revoked, not updated on the vRA db to False (therefore if reprovisioned, the user will be added to the Admins group again)
      2. Hostname (clone)
      3. VirtualMachine.Admin.ClusterName
      4. VirtualMachine.Admin.ThinProvision
      5. VMware.Memory.Reservation
      6. VMware.VirtualCenter.Folder
      7. VMware.VirtualCenter.OperatingSystem
  4. Update
    1. The specified valye is omplemen ted on the machne and is maintained in the vRA db thoughout via data collection when it changes on the machine / virtualisation platform / outside of the vRA. This update is performed by the proxy agent.
    2. Examples include:
      1. VirtualMachine.Admin.Hostname (clone)
      2. VirtualMachine.Admin.TotalDiskUsage
      3. VirtualMachine.Memory.Size
      4. VirtualMachine.Admin.CPU.Count

There are many built in custom properties that belong to these categories and additional custom properties should NOT be created with the same names. The full list of built in custom properties available within vRA 6.2.x are available here.

Build Profiles

Build profile is a collection of properties to be applied to a machine when its provisioned. Built profiles are always read during the machine building process. Build profile provides the ability to group a set of properties so that rather than adding a multiple set of properties to each blueprint, a single build profile can be associated saving time & effort. Build profiles can be created from using default property sets of custom properties (mentioned above). There a number of default property sets that vRA 6.2.1 ships with such as ActiveDirectoryCleanupPlugin. (When you login to vRA portal as the Fabric Administrator and go to Infrastructure->Blueprints->Build profiles, you can see the full list when trying to add a new build profile). Note that build profiles are only applied to blueprints.

Creating a Build profile

  1. Login as Fabric Administrator and go to Infrastructure->Blueprints->Build profiles
  2. Create a new build profile and provide a name. I’m creating a build profile to peform AD cleanup tasks when a computer is retired / destroyed.
  3. Select from the default property set if applicable. Since we already have a default property set for AD cleanup (called ActiveDirectoryCleanupPlugin), im going to be using that here. Select the property set and click load to load the relevant custom properties
  4. Provide the information required for each custom property including the AD user account & passwords with rights to remove computer accounts Build Profiles
  5. Login as Tenant Admin and edit an appropriate blueprint for provisioning a Windows VM that is joined to the domain during the provisioning process and apply the build profile. Associate build profile with BP

That’s it. Every time a VM created using this blueprint is removed / destroyed via vRA (by the user or an administrator), the computer account would now be removed from the AD too. (note that this won’t happen if the VM is removed outside of the vRA management platform, such as directly on the vSphere client.

 Property Dictionary

Property dictionary within vRA is used in tandem with the custom properties and is typically used to achieve the followings.

  • Define characteristics of properties that are used to tailor the behavior of the request user interface
  • Associate a property name with a particular user control, such as a check box, a calendar control, or a drop-down menu
  • Specify constraints such as minimum and maximum values or validation against a regular expression
  • Provide descriptive display names for properties or specify text (for a tool tip or text label) with additional information
  • Designate a property as optional rather than required

Note that property names and values are case sensitive…..!!

Here are different types of property dictionary types available within vRA.

  • Checkbox – Check box for specifying true or false values
    • Example Configuration
      • Create a property dictionary as the fabric admin as follows  CheckBox 1
      • Now attach the property dictionary as a custom property to the blueprint as follows CheckBox 2
      • When you now attempt to provision a machine using the above blueprint, you can see that the defined property dictionary is available (checkbox in this instance)   CheckBox 3
      • Obviously the above example is practically meaningless as the intention was to show how to add a checkbox, not to actually use it for a meaningful purpose. But additional logic can be built in to this checkbox such that if selected, it could perform some additional action during the machine provisioning.
  • DateTimeEdit
    • Can add a date & time edit field to the blueprint
  • DropDown
    • Can add a drop down menu. As an example use case, you can define multiple tiers of storage (Gold, Silver & Bronze) within a drop down list and upon a user selecting the appropriate value from this drop down list during the machine provisioning, the VM can files can be placed automatically on the correct storage tier
  • Integer
    • Defines an integer value
  • Label
    • Provide a label value
  • Link
    • Provide a link. An example would be to direct the user to a 3rd party page where corporate IT policy details are specified which each user requesting a machine provisioning must first read and accept prior to continuing with requesting a machine being provisioned from a blueprint.
  • Notes
    • Notes filed
  • Password
    • Password field
  • TextBox
    • Text box

Now lets take a look at using some of the property dictionary types in a real world scenario.

  • Requirement:
    • You need to enable the business group users who request machine provisioning (using a blueprint) to select the type of the server they are provisioning (Web, App or DB) and depending on the type of the server selected, automatically list all the compatible VM networks available for that server (App-Network-1, App-Network-2 for App VMs, Web-Network-1, Web-Network-2 for Web VMs & DB-Network-1, DB-Network-2 for DB VMs) so that the appropriate network can be selected during the machine provisioning.
  • How to implement using property dictionaries
    1. Login as Fabric-Admin and go to Infrastructure-Blueprint->Property Dictionary and create a property definition called Custom.VM.Category (this could be any name you wish as long as it doesn’t conflict with any of the default custom properties). Select the control type for this property as DropDownList and select required. EX-1
    2. Once created (and the green tic is clicked to complete), click on the edit link under property attribute and create a new property attribute as type ValueList and type the values as Web,App,DB (no spaces in between. Note that these values are case sensitive)   EX-2
    3. Now create another property definition called Custom.VM.Network0 (again, can be any name here as long as there are no conflicts) and select the type as a DropDownList EX-3
    4. Now create an XML file using an XML editor (such as the free XML copy editor) similar to the below, defining the relationship between the 2 property definitions. I’ve attached a link to the file I’ve  created here which you can download. Ensure that you always edit this in an XML editor and not the notepad as due to line breaks & whitespace issues, it will just not work if you copy / paste content within the notepad). Pay attention to the details such as <FilterName> tag which defines the parent property definition name, <FileValue> which defines the parent value (App, Web or DB) and the <Value> which defines the appropriate child value (App/Web/DB-Network-1/2. This XML definition fully defines the relationship between the parent and child properties.  EX-3.5
    5. Now copy the content of this XML definition (from the XML editor, NOT the notepad), go to the property attribute created in the step 3 above (Custom.VM.Network0) and click on the edit button under the property attributes. Create a new property attribute and select type as value expression and paste the XML definition here. Once complete, click the green tic and click ok.         EX-4
    6. Now, create another property attribute here as type relationship and set the value as Custom.VM.Category (Name of the parent property definition created above in step 1) EX-5
    7. Now, add both property definitions as custom properties to a blueprint as follows. EX-6
    8. When you now attempt to provision a machine from this blueprint as a user, you can see that you are bing prompted to select a VM category first (where you have 3 options, Web, App or DB) and depending on which one you choose, the next VM Networks field presents you with the relevant network names to select from. EX-7 EX-8
    9. It should be noted that by selecting the appropriate VM network in above example, it will not automatically connect the machine / VM to that network you select (if that is required, additional work is required including a vRO workflow type of customisation to take the value selected here and match that to a network label available and map the VM’s primary vNIC to it. That is obviously not show in the example here).

 

There you have it. Custom properties, property dictionaries can be used together to achieve various level of customisation work when defining blueprints and build profiles can be used to group multiple custom properties all together as one, to be attached to blueprints.

Hope this was useful

Cheers

Chan

Next: (Optional) – vRA Part 10 – IaaS Extensibility – Using vRO for Blueprint Customization –>

VMware vRealize Automation – (Optional Fix) Missing Catalog / Entitlement Actions on vRA 6.2.x

Chan Leave a comment

 

I came across this weird issue on vRA 6.2.1 where, during the IaaS blueprint creation, most of the actions that should be available (such as “power on”, “Reboot”, “Suspend”…etc.) were not available to be allocated to catalog items (blueprints & services). All of these actions are supposed to be IaaS catalog actions that are available by default once the IaaS components have been deployed, that you can assign to business groups / users when blueprints / catalog items are entitled to users, so that once a vm / server has been provisioned from the said blueprints, those actions are available to the users to interact with the vm / server, through the vRA web portal. If you had this issue, when you login to the vRA portal with tenant administrator privileges, all the actions shown below where the source is listed as IaaS were missing (Everything outside of the highlighted actions below were missing)

Capture

This has always been a known issue with previous versions of vCAC where the recommended fix was to run the following command on the IaaS web server, as an administrator.

C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe registercatalogtypes -v

However, with vRA 6.2.x platform (specifically, version 6.2.1), I found that this command alone wouldn’t fix the problem. In my environment, running the above command comes back as succeeded but the actions were still not available. Having raised a VMware support ticket, it turned out that the SAML Token Validation Check (enforced through a configuration line item in C:\Program Files (x86)\VMware\vCAC\Web API\Web.Config file on the IaaS server) is also failing which needs to be fixed as well. If you have the same issue of missing actions in your vRA setup and running the above command doesn’t fix the issue on the vRA 6.2 platform, check the C:\Program Files (x86)\VMware\vCAC\Web API\Logs\Elmah directory on the IaaS server and check if you can see a number of XML files as follows

Elmah XMl

If you see them, open the most recent one up and check for the lines highlighted below

XML content

If this is the case, this is a known issue with regards to the vRA 6.2 platform, internally within VMware and currently there is no specific KB article related to this. From what I found out through VMware support, the issue is caused by vRA sending a signature that is using an algorithm not compatible wit the .Net code on the IaaS server and the error is seen in the Elmah XML file (above), that states “System.Security.Cryptography.CryptographicException: SignatureDescription could not be created for the signature algorithm supplied“.  While a formal fix is likely going to be included in a future release, currently there’s only a workaround available which is to amend the web.Config file to disable SAML Token validation Check. Heres what you need to do.

  1. Go to the IaaS web server as an Administrator and backup the current C:\Program Files (x86)\VMware\vCAC\Web API\Web.Config file (I’d cope & rename this as Web.Config.Backup
  2. Open notepad as Administrator and open the original Web.Config and replace the <!– add key=”DisableSAMLTokenSignatureCheck” value=”false”–> with <add key=”DisableSAMLTokenSignatureCheck” value=”true”/>
  3. Once replaced, the new Web.Config file should be as follows. Web.Conf
  4. Now run iisreset to restart IIS and ensure all the vRA services are started back up correctly
  5. Now (re) run the following command, as an administrator
    1. C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Cafe\Vcac-Config.exe registercatalogtypes -v
  6. You will now see the missing actions being available on the vRA to be assigned to the catalog items.

Hope this was useful

Cheers

Chan

Next: (Optional) vRA Part 8 – Adding a VMware vCloud Air Endpoint & Publishing a Cloud VM Blueprint –>

VMware vRealize Automation Part 8 – Adding a VMware vCloud Air Endpoint & Publishing a Cloud VM Blueprint

Chan Leave a comment

 

So now we have a fully functioning vRA 6.2.1 deployment, fully integrated to the on-premise vCenter instance, the vRO appliance for workflow orchestration and NSx for network orchestration (via vRO). Now lets look at how to set up a cloud endpoint so that you (or the users) can request VM’s to be provisioned on the cloud rather than their local vSphere cluster. We are looking at adding VMware’s own vCloud Air platform in this article (if I managed to gain access to an Amazon AWS instance, I’d publish a future post on that too as each cloud platform integration is different to one another.

VMware vCloud Air (formally known as vCHS) is VMware’s own managed and operated cloud platform, that runs on the same vSphere technology as your on-premise environment. They have a vCloud Director instance in front, which manages the multi tenancy aspect of a collection of vSphere clusters which you can either buy a subscription as an on demand basis (similar to AWS) or monthly / annual subscription basis (with no usage charges which is real handy). vCloud Air has been around a while now and is quite popular given that you don’t have to change the architecture of your on-premise applications or servers (VMs) that they are installed on to move them to the cloud (which is the case with both Amazon and Azure and could be painful and expensive). With vCloud Air, you just move the whole VM as is with the application already deployed on it and it will work fine on vCloud Air platform just like it did on your own vSphere cluster (You also have the option to do a “Stretched deployment” which is a way of  moving the VM to the cloud but establishing a Layer 2 network between your vSphere cluster and vCloud platform over a VPN so no IP’s need changing which is awesome).

Just like AWS, vCloud Air (as well as any other 3rd party cloud provider who runs their cloud platform behind vCloud Director basically) can be integrated to your on-premise vRA instance as an endpoint. Imaging that you have a number of developers who, as a part of an application development cycle, would require multiple copies of your production environment (System Integration Testing, User Acceptance Testing…etc.) can easily be offloaded on to a vCloud Air platform without having to buy expensive kit locally to host multiple copies of your prod environment (we are talking additional SAN, Compute, Hypervisor & Networking costs here). Lets also imaging that they want to be able to use vRA so that they can self provision clones / copies of the production environment using pre-defined blueprints defined & published on the vRA IaaS catalog portal? You can quite easily make this happen and attach a vCloud Air endpoint, create a resource reservation on that endpoint and associate that with the business group that the developers belong to and create vCloud (vApp) type blueprints on vRA so that everytime a developer want to create a copy of that SQL server with 2 x App and 2 x Web servers to test a new application, they go to the vRA catalog, request those be provisioned and the servers will automatically be created on the mapped vCloud Air platform. (You can create a single Multi-Machine blueprint to group all of those individual server blueprints too which we’ll cover later)

Ok, enough of what we can do with vRA and vCloud Air and how cool that is… Lets look at what it takes to integrate the vCloud Air subscription you have to vRA and create and publish a vCloud blueprint & provision a VM on cloud that way.

Given below are the steps involved

  1. Create a vCloud Air (vCloud Director) endpoint
    1. Note: If you can remember what we covered in a previous post here, Infrastructure Admins usually create the endpoints within vRA. So login to the vRA portal using as the infrastructure admin (if you are using the default tenant, the URL is “https://<FQDN of the vRA Appliance>/shell-ui-app”. If you have a tenant specified, it’ll be https://<FQDN of the vRA Appliance>/shell-ui-app/org/<TenantName>”. I’m using a tenant called Tenant1 in my example within vRA)
    2. Go to Infrastructure->Endpoints->Credentials and set up credentials to access the vCloud Air endpoint – this is the same username & password you use to login to the vCloud Air online portal that you should have been given / created during the vCloud Air onboarding process (first thing that happens once you’ve signed up)  01
    3. Go to Infrastructure->Endpoints-> and create a new vApp (vCloud) type endpoint (this is the same as if you were creating an endpoint to a local vCloud Director instance)   02
    4. Once the endpoint is created, hover the mouse over the endpoint name and select the data collection and start the collection. You need to wait for this to complete first.
  2. Create a new Fabric group (Infrastructure Admin)
    1. Go to Infrastructure->Groups->Fabric groups and create a new Fabric Group (or you can use an existing fabric group and map the vCloud Air endpoint to it. 1
  3. Create a reservation for the vCloud Air endpoint (Fabric Admin)
    1. Note: Creating a reservation maps a logical portion of the vCloud Air endpoint to the business groups you have. I’m using an existing business group but if you need to create a new business group, do that first and select that business group during the reservation creation here.
    2. Go to Infrastructure->Reservation and create a new cloud reservation of type vApp (vCloud), as Fabric Admin user, selecting the mapped endpoint and the business group 2.1
    3. Go to the Resources tab and select a memory portion and storage portion to be used for this reservation 2.2Reservation-Resources
    4. Go to the Network tab and select the network you want to map to the reservation. Networks available here depends on the networks you’ve created within your vCloud Air portal. By default, you’ll have 2 networks, the default-isolated (private network) and default-routed (network with external connectivity) – Note here that at some point in the future, VMware will roll out NSX on the vCloud Air platform and once that’s complete, you’d also be able to create the logical networking via the same vRA / vCO blueprint too. This is going to be really cool and I don’t think any other public cloud vendor will have this capability for a while. If you have a network profile with static IP’s configured, select that network profile here which will allocate an IP to the VM from the network profile (which we covered in a previous post of the series). I’m not using a one here. 2.3
  4. Create & Publish vApp Component Blueprint (Tenant Admin)
    1. Note: When creating vCloud Air blueprints, its a 2 step process whereby you need to create a vApp Component blueprint first for each VM and then create a higher level master (group) vApp blueprint which will contain 1 or more of the lower level vApp Component blueprints. This is because on vCD (vCloud Director), every VM is placed inside a vApp so you need to create both through the vRA. But when you ultimately create the service & publish it with entitlements to the users, you only need to publish the master vApp blueprint.
    2. Login as tenant admin & go to Infrastructure->Blueprints and create a new cloud blueprint of type vApp Component (vCloud). Provide a name and select the Machine prefix 3.1vApp Component blueprint - info
    3. Go to build information tab and select the cloning action and select the template (you can select from a list of VM templates available within vCloud Air here provided that the data collection from the endpoint has been successful. You have a default set of global templates VMware provides (include CentOS, Ubuntu, Major Windows flavours with SQL) or if you’ve migrated some of your local templates you’ve created, that is specific to your environment (i.e. a Standard server build template from your local vSphere cluster which you can do using vCloud Connector to the vCloud Air portal), they too would appear here. And select the machine resources appropriate. 3.2vApp Component blueprint - Build info
    4. Add any custom properties in the next tab  and click OK.  3.3 vApp Component Blueprint - Properties
    5. Once the vApp Component blueprint is created, don’t forget to publish it (hover the mouse over the blueprint and click publish).  3.4vApp Component blueprint - Publish
  5. Create & Publish a vApp Blueprint (Tenant Admin)
    1. Note: now its the time to create the master vApp blueprint (which, as I explained above, is going to include the component blueprint and which will be published to users)
    2. Create a new cloud blueprint of type vApp (vCloud) and provide the information. Select the same reservation as used for the vApp component blueprint. 4.1vApp blueprint - Build info
    3. Go to the build information tab and select the clone action, and the clone from template should be the same as what you’ve chosen for the component blueprint. Then, nder the components, select the previously created component blueprint to link the child to the parent. 4.2vApp blueprint - Build info
    4. Once completed, don’t forget to publish this one too. 4.3vApp blueprint - Publish
    5. Create a Service to list the blueprint within the catalog (Tenant Admin)
      1. Go to Administration->Catalog Management->Services and add a service and provide all the information required including an icon, owner & support group details. 5.1 Service
      2. Select the service create and click on manage Catalog Items and add the vApp blueprint. Make sure you don’t add the vApp component blueprint here. 5.2 Service Catalog items
    6. Create Entitlements (Tenant Admin)
      1. Go to Entitlements and add a new entitlement and set the status to active. Also select the users / groups (from the business group) that this blueprint is entitled to. 6.1 Entitlements
      2. Go to the Items & Approvals tab and select the created service under entitled services & the same vApp blueprint under the catalog items and all relevant user actions. 6.2 Entitlements - items & Approvals

 

That’s it. You’ve now successfully created a public cloud endpoint within your on-premise vRA, and created and published a VM blueprint that can be used to deploy VM’s on the cloud automatically by your users.

If you now login to the same vRA URL as a valid user who were given the appropriate entitlements above, you’ll see the new blueprint item being available.

7. Catalog items

If you go ahead and request a VM using this cloud blueprint, the request status would be shown under the requests tab 8 Provisioning request on vCloud Air

If you now look directly at the vCloud Air online management portal, you’ll see the VM is being provisioned automatically. Once its complete, you’ll notice the owners name changes.9. Being provisioned in vCloud Air portal automatically 10 Provisoning complete

Once the VM is successfully provisioned in the cloud, the user will also see the status of that within the on-premise vRA portal which they can either access through vRA (console access) or though the vCloud Air online management portal directly (provided that they have a valid user account to login with – note that this account is separate. 11 Item now available on vRA

There you have it. VMware vRA can be a single point of automation and orchestration engine to automate and orchestrate various tasks, machine / VM provisioning on-premise as well as VM provisioning on the cloud. And this shows how vRA can be a key part of what I believe to be the true hybrid cloud infrastructure where you can place workloads on-premise or off premise based on your needs.

If your on-premise vRO is integrated with vCloud Air also, you can create further customisation workflows within vRO and publish them on vRA as an advanced service blueprint too (I will cover that in a future post)

Cheers

Chan

Next: (Optional) – vRA Part 9 – Extensibility – Custom Properties & Build Profiles & Property Dictionary –>

VMware vRealize Automation Part 7 – Tenant Administrator & Basic Blueprints

Chan 1 Comment

 

Now that we’ve got all the system-wide roles (System / Infrastructure & Fabric Admin) fully configured and each user has done their configuration tasks, next in the to-do-list is the configuration items to be performed by the Tenant Administrator. We wont be looking at everything a Tenant Admin can do here, but only focus on key items relating to blueprints.

First of all, lets briefly look at the Tenant Administrator role (note that the System Administrator assigned the Tenant Administrator role during a previous stage mentioned here)

Tenant Administrator is a key user that is typically a business manager or an IT administrator who is responsible for a tenant who configure vRA according to the needs of the company. He / She is responsible for the followings primarily,

  • Manages and configures the tenant
  • Manages the users and groups (within the tenant)
  • Manages catalog services
  • Creates approval policies & entitlements
  • Manage tenant brandings
  • Manage business groups within the tenant
  • Tracking resource usage by all tenant users
  • Create & manage global (shared) blueprints

Key Tenant Admin tasks

  1. Tenant Configuration Tasks
    1. Configure Identity Stores – This should have already been done at an earlier stage by the System Admin
    2. Configure custom groups
      1. Configure Custom groups (approval Administrator / Release Dashboard user / Release engineer / Release manager & Service architect roles
        and map them to AD users / groups   121
    3. Configure Identity store users such as business group admins, business group users and support users and configure additional privileges to these users (Administration->Users&Groups->Identity Store Users & Groups)
    4. Configure Tenant branding if this is required (Administration->Branding)
    5. Configure notification providers such as email servers to be used within the Tenant for the approval notifications via Administration->Notification->Email servers (I’m not doing this here)
    6. Create Business groups (We’ve already created a business group earlier as Tenant Admin user)
  2. Create & Publish IaaS blueprints
    1. Create an IaaS blueprint
      1. Notes:
        1. We’ll create a simple VM provisioning blueprint here using a CentOS 6.6 template & a customization specification (both need to have been pre-created and be registered in the compute / production cluster vCenter server)
        2. We will be using a basic cloning as the provisioning method (linked cloning and NetApp FlexClone options are also available)
      2. Go to Infrastructure->Blueprints and use new blueprint button to create a new virtual vSphere blueprint and fill out the basic Blueprint information 212
      3. Go to the build information tab and select the appropriate options (as below) 213
        1. You can use custom properties to achieve various functions. A full list of available all custom properties are available here and a list of specific custom properties applicable for a cloning blueprint (similar to what we are creating here) are available here.
        2. Some key, useful custom properties are as follows
          1.  Snapshot.Policy.Limit = <Depth of Snapshot limit. Default is 1, max is 31>
          2. Snapshot.Policy.AgeLimit = <Snapshot age limit in days. Default is no limit>
          3. VirtualMachine.Admin.ThinProvision = True/False (Applicable for VMware & Hyper-V using local or iSCSI storage)
          4. VMware.VirtualCenter.Folder = <Folder to place the VMs within vCenter>
          5. VirtualMachine.Admin.Owner=
          6. VirtualMachine.Admin.AddOwnerToAdmins=True
          7. VirtualMachine.Admin.AllowLogin=True
          8. VirtualMachine.Network0.Address=<IP address for Network 0>
          9. VirtualMachine.NetworkN.MacAddressType=generated/static
          10. VirtualMachine.NetworkN.MacAddress=<MAC Address>
          11. VirtualMachine.NetworkN.Name=<VMNetworkName>
          12. Machine.SSH=True
      4. We will cover the Build profiles and custom properties section separately 214
      5. Select the Actions that would be made available within the Blueprint definition (so they’d be available as entitlement actions to assigned users)   215
      6. Now we have the first basic blueprint definition created successfully.
    2. Publish the IaaS blueprint
      1. Hover the mouse over the created blueprint and select publish & click Ok to confirm. 221
    3. Create a service
      1. In order for a published blueprint to be made available on a catalog to the users, a service need to be created and the blueprint must be associated with that service
      2. Go to Administration->Catalog management -> Services and add a new service, populate the information required and add.   232
      3. Associate the blueprint with the service by selecting the service created and click on “manage catalog items” 233
      4. Add a catalog item and select the previously created blueprint 234
    4. You can create approval policies if required next(Administration->Approval Policies). I’m opting to not create approval policies and instead opt for no approvals.
    5. Create Entitlements
      1. Once a blueprint is created, and has been associated within a service, it (the service) need to be given entitlements. In other words, the service needs to be mapped to a user / group to be given access so that they can request a VM to be provisioned from this service / blueprint.
      2. Go to Administration->Catalog management->Entitlements and add a new entitlement. Provide a name for the entitlement (note: To avoid confusion, if the relationship between a blueprint:service:entilement is a 1:1:1, I keep the name identical for all 3 to keep thins simple and related) and select the AD groups / users that this blueprint / service is made available for within the online catalog. Click next 252
      3. Add the entitled services (created above), Catalog item (blueprint created above) and the appropriate entitled actions.
        1. Note: if the VM actions are not fully populated within the entitlements section, on the IaaS server host, navigate to “C:\Program Files (x86)\VMware\vCAC\Server\Model Manager Data\Café” folder from command line and run “Vcac-Config.exe” registercatalogtypes –v”253
      4. Once added, the entitlements are complete 254
  3. User request through the catalog
    1. All tasks required to make the blueprint listed on an IaaS catalog are now complete and the entitled users can now request a machine provisioning based on this blueprint through the portal
    2. Login to the vRA portal (URL “https://<FQDN of the vRA Appliance>/shell-ui-app” if using the default tenant) using the appropriate business group user (bg-user in our example based on the entitlements we set above) and you’ll see the CentOS 6.6 server is now available in the users catalog.    32
    3. Request a VM to be provisioned off of this catalog item.    33
    4. All submitted requests can be tracked within the requests tab. 34
    5. You can see the cloning task initiated by the vRA service account within vSphere client / web client. Note that there may be a slight delay before this is executed on the vCenter after being submitted via vRA. Note that the default custom properties set for the business group (explained in the previous post of this series) dictated where the VM is created within the vCenter folder hierarchy & the name of the VM is automatically based on the default machine prefix attached to the business group (also created earlier) 35
    6. Once successfully created, the item will appear under the “Items” tab within the vRA IaaS portal for the user to access based on the entitled actions previously defined.   36

That’s basically it. This effectively now concludes the basic deployment tasks I’ve intended to cover as the typical deployment & configuration tasks you’d have to do in the field to deploy vRA 6.2.1 along with vRO 6.0.1 and NSX 6.1.x all fully integrated for extensibility. Hopefully this series of posts gave you a summarized view of all the initial tasks that you’d need to do, in the exact order they need to be done, including any undocumented little quarks I’ve come across that potentially could have cost you some troubleshooting time in the field. Hope this was of use to some. I know I will refer back to this in the future for my own benefit.

I would appreciate any feedback

Cheers

Chan

 

P.S. While this post concludes the series of posts formally, I will continue to provide additional vRA articles for further extensibility where we will look at more extensibility options to leverage vCO workflows during the provisioning stage to achieve various results and creating custom actions, advanced service blueprints, using vRA for publishing non IaaS functions such as AD password resets…etc. However they are not really mandatory for a typical vRA deployment and would only be required depending on the end user’s needs.

 

Next: (Optional Fix) Missing Catalog / Entitlement Actions on vRA 6.2.x –>

VMware vRealize Automation Part 4 – IaaS Server Deployment

Chan Leave a comment

Next: vRA Part 5 – vRO Deployment & Configuration & Integration –>

IaaS server is installed separately on a Windows server and is a key part of a vRealize Automation deployment. IaaS is the part within vRA that enables the rapid modelling and provisioning of servers & desktops across virtual and physical, private and public or Hybrid cloud infrastructures. Without the IaaS components, a vRA deployment is pretty none existent and in my view, pretty useless.

IaaS Component Architecture

IaaS components included within the vRA are as follows

  • IaaS Web site:
    • The IaaS Web site component provides the infrastructure administration and service authoring capabilities to the vCloud Automation Center console
    • Gets the updates from the Model manager for DEM, Proxy agents and the SQL database
  • Model Manager:
    • Provides updates from the DEM, proxy agents, and database to the IaaS web site.
    • The Model Manager holds the core of the business logic for vRA.
    • This business logic contains all the information required for connecting to external systems like VMware vSphere, Microsoft System Center Virtual Machine Manager, and Cisco UCS Manager…etc.
    • The Model Manager Web service component can have multiple instances and communicates with a Microsoft SQL database.
  • Manager Service
    • The Manager service coordinates communication between DEMS, agents, and the database.
    • The Manager Service communicates with the console Web site through the Model Manager. This service requires administrative privileges to run on the IaaS server
  • Distributed Execution Managers (DEMs)
    • DEMs execute the business logic of a vCloud Automation Center model, interacts with external systems, and manages virtual, cloud, and physical machine resources
    • DEMs are used for provisioning and managing machines on vCloud Director, vCloud Air Service, Red Hat Enterprise Virtualization Manager, Microsoft System Center Virtual Machine Manager, Amazon Web Services, Physical Server Management Interfaces for Dell, HP, and Cisco.
    • Runs as a Windows Service (1 service for DEM Orchestrator and another for DEM Worker
  • SQL Database
    • The IaaS component of vRealize Automation uses a Microsoft SQL Server database to maintain information about the machines it manages and its own elements and policies
    • A system administrator need to manually create the database during installation
  • Agents
    • Hypervisor proxy agents: Provisioning and managing machines and services on vSphere, Citrix, XenServer, Hyper-V. They send commands to and collect data from vSphere ESX Server, XenServer, and Hyper-V virtualization hosts and the virtual machines provisioned on them
    • EPI Agents: External provisioning infrastructure PowerShell agents
    • VDI Agents: Virtual Desktop Infrastructures PowerShell agents for XenDesktop Delivery Controller and VMware View Horizon enabling the XenDesktop web interface access through vRA
    • WMI Agents: Windows Management Instrumentation agents enhances the ability to monitor and control system information and allows you to manage remote servers from a central location. It enables the collection of data from Windows machines that vRealize Automation manages.
    • Management Agents: Management Agents collect support and telemetry information and registers IaaS nodes. A Management Agent is installed automatically on each IaaS node.
    • Each agent runs as a Windows service

One thing I’ve noticed on most of the VMware documentation is a lack of clarity in the form of a diagram of how these components interact. I’ve therefore attempted to document this as below.

1. Components

 

IaaS Server Deployment

The deployment of the IaaS component is not the easiest of the tasks and is somewhat unlike the typical user friendly deployment style we are used to with other VMware products (guessing this was because it came from the Dynamic Ops acquisition rather than being developed in house by VMware). It could be a quite a tedious task to ensure that all the various pre-requisites are in place on the IaaS Windows server manually and then having to run the setup (which is also a little cumbersome). Fortunately, a VMware TME (Brian Graf) has put together a really handy PowerShell script to automate the pre-requisite setup which I’ve used few times in the past and it has saved me lots of time. We’d be using that here.

Here are the steps involved in deploying the IaaS server components, starting from the Pre-requisites

  1. Ensure the Pre-requisites are in place on the IaaS server
    1. Build a Windows 2008 R2 / Windows 2012 / Windows 2012 R2 server
    2. Create a Domain account as the vRA service account. Lets call it <DomainName>\svc_vRA.
    3. Login to the Windows server (VM) and ensure that the vRA service account is a member of the local Administrators group 1.3
    4. Download the vRA 6.2 pre-req checker PowerShell script from GitHub and copy locally.
    5. Login as the vRA service account Run the “vRA 6.2 PreReq Automation Script.PS1” and follow the guided install wizard to add / download the additional components as required and install them automatically.   1.5
  2. Ensure the pre-requisites are in place on the SQL server
    1. Grant the vRA service account (svc_vRA) sysadmin rights on the SQL server instance (This is only temporary and is required during the installation period only for the installer to automatically create the database required which can later be revoked.2.1
  3. Verify the Pre-Requisites are correctly installed & configured on the IaaS server
    1. login to the IaaS server as the vRA service account.
    2. Download the IaaS installer specific to your vRA deployment by logging in to the https://<FQDN of the vRA Appliance>:5480 (login using root) 3.2
    3. Login to the installer using root and password specified during the deployment of the vRA appliance 3.3
    4. As this is the first IaaS server, I will be installing all the roles on this server (Will add a secondary DEM Orchestrator and DEM worker to another server later). Therefore select Complete Install and click next 3.4
    5. The built-in Pre-Requisite checker will now verify that you’ve got all the pre-requisites and confirm. 3.5
    6. If there are warnings against the Windows Firewall (even if its disabled), ensure that the Distributed Transaction Coordinator is allowed through the firewall and once verified, select the Firewall related warnings and click bypass. 3.6
    7. Move on to the next step
  4. Install the IaaS components
    1. From the Step 3.7 above, click next to proceed with the installation
    2. Provide the followings to the installer
      1. vRA service account username
      2. vRA service account password
      3. Passphrase (is a series of words that generates the encryption key used to secure database data and would required if the DB is to be restored)
      4. SQL server name (DO NOT type the instance name if there’s only a singly instance on the server. Just use the SQL server FQDN)
      5. vRA Database name & Click Next 4.2
    3. Provide the DEM and Agent names and click next 4.3
    4. Under the Component Registry,
      1. Provide the FQDN of the vRA appliance
      2. Load the default Tenant
      3. Download the certificate using the button & accept using the check box
      4. Provide the default SSO Administrator credentials (Administrator@sphere.local if using the vCenter SSO) & click test to verify. Verify the IaaS server name & Click next 4.4
    5. Click Install to begin the installation. Install log would be at “C:\Program Files (x86)\VMware\vCAC\InstallLogs\” folder.    4.5
    6. Once the installation complete (can take around 20 mins), click next & finish
  5. Verify the IaaS installation & Service registration
    1. Now login to the https://<FQDN of the vRA Appliance>:5480 as root and ensure the IaaS-service has a status as REGISTERED5.1
    2. Also verify that you can see the Infrastructure Administrators section being enabled within the Login to vRA UI for the default tenant (URL “https://<FQDN of the vRA Appliance>/shell-ui-app) when you login with the default SSO administrator credentials (Administrator@vsphere.local). Note that this was previously disabled pending the installation of the IaaS components. 5.2
  6. Revoke the temporary SQL permissions
    1. SysAdmin privileges assigned to the vRA service account on the SQL server instance is no longer required, (verify that the account has automatically been given the DBO permission to the vRA database) so you can now revoke this permission on the SQL server.6

 

That is it. The vRA IaaS server components have now been set up successfully. Next, we’ll look at deploying & configuring the latest version of vRO (vRealize Orchestrator – 6.0.1) which is a critical part of a useable vRA deployment.

Cheers

Chan

Next: vRA Part 5 – vRO Deployment & Configuration & Integration –>

VMware vRealize Automation Part 3 – vRA Appliance Deployment

Chan Leave a comment

Next: vRA Part 4 – IaaS Server Deployment –>

Ok, now that we’ve established the need for a dedicated management cluster to host the vRA management components, lets look at the deployement highlights of the vRA components within the management cluster.

  1. vRA Identity Appliance:
    1. If you want to use the vRA’s own identity management appliance, that should be the first component to be deployed. Deployment of this appliance is pretty straight forward and is self explanatory, hence I will not be covering here. However I will instead be using the vSphere SSO as the identity management source for vRA environment also, in order to keep all authentication for the my virtual infrastructure centralised (and simple).
    2. But if you are NOT planning on using vSphere SSO, make sure you download the vRA identity appliance from VMware and deploy on to the management cluster.
    3. Once deployed, ensure to configure the time zone and the NTP server settings using the management IP (specified during the Appliance deployment)
  2. vRA Appliance deployment
    1. Download the vRA appliance from VMware. Documentation for the latest release can be found here
    2. Deploy the appliance on to the Management Cluster using the vCenter server that manages it. You would need the following information during the deployment 1
  3. Configure the vRA Appliance
    1. Once the appliance deployment is complete, use the URL https://<FQDN/IP of the vRA appliance>:5480 to access the management interface
    2. Login with username root and password as specified during the deployment
    3. Set up the Time Zone (System->Time Zone)
    4. Set up the Host name (Network->Address) & Proxy server (Network->Proxy) if applicable
    5. Set up NTP to sync time (Admin->Time Settings)
    6. Set up the vRA specific settings
      1. Setup SSL (vRA Settings->Host Settings) – You can either self generate a Certificate or import a certificate obtained from a CA    2. SSL
      2. Set up SSO (vRA Settings->SSO) – You can connect to default vRA identity appliance or the vSphere SSO (>5.5 1b) as below using default SSO admin account. Note the following key points regarding the SSO host name
        1. Important Note: If you have an existing vRA / vCAC deployment already that is using a vSphere SSO server, note that you CANNOT use the same SSO server for another vRA server. I had number of issues when I attempted this, and the most notable one 1 where the non of the group / roles created within the default tenant (such as infrastructure admin & tenant Admin) would work and may come up with “401 – Unauthorized: Access is denied due to invalid credentials” error when logged in. This doesn’t appear to be correctly documented so watch out, but shouldn’t apply to most as its unlikely that you’d have multiple vRA deployments in the same organisation. the only way around this (if you have to use the same SSO source for multiple vRA’s) is to create a tenant rather than using the default tenant. Note the tenant name should be unique within the whole SSO too (if you have Tenant-A in vRA-A, you cannot add another Tenant-A on vRA-B using the same SSO)
        2. Host Name: When using the vSphere SSO server, host name should have the same case as what’s been registered in the vCenter SSO (if unsure, browse to https://ssoserver:7444/websso/SAML2/Metadata/vsphere.local and save the vsphere.download file when prompted.  Open the vsphere.download file in notepad or some text editor.  Locate the entityID attribute of the EntityDescriptor element.  Use the SSO server name in the way its specified here paying attention to the case)
        3. Port: 7444 in the host name for the vCenter SSO is NOT required with the vRA6.2.1 (this was required to be specifically specified in the host name field with the earlier versions of vCAC)
          3. SSO
      3. Add the appropriate license.(vRA Settings->License). It should be noted here that the license key added here should be the vRA standard or vRA Adavnced and not the vCloud suite license.
      4. Database connectivity (vRA Settings->Database) can be ignored in most cases unless you want to connect to an external Postgre SQL server / cluster
      5. Messaging (vRA Settings->Messaging) can also be ignored as this should have been automatically configured.
      6. Cluster configuration (vRA Settings->Cluster) can be bypassed unless you are creating a vRA appliance cluster in which case you can join an existing cluster here.
      7. Once all above are configured, allow couple of minutes and ensure all vRA services are now registered within the “Services” tab. 4. Services
    7. Configure the Identity stores
      1. Here, you can create new tenants (for a multi tenant deployment) or use the default tenant (automatically created). I’m going to use the default tenant here.
      2. Login to vRA UI using the URL “https://<FQDN of the vRA Appliance>/shell-ui-app” with the default SSO administrator credentials (Administrator@vsphere.local). The default vSphere.local tenant should be available. 5. Login
      3. Click on the vSphere.local, go to Identity stores and verify the default domain name listed (by default, the native ad domain would have been added here)
      4. If you need a separate identity / authentication realm (AD or open LDAP supported), you add it here
    8. Setup Tenant Administrators for the tenants
      1. Login with the SSO Administrator account and click on the tenant and then go to Administrators (using the default tenant in the example below)
      2. Add the AD user account or group to be used as the Tenant Administrator 7. Tenant admin 2
    9. Add the inbound and outbound email servers within the Email Servers tab on the left
    10. (Optional) Set up branding for the vRA user interface if required using the Branding tab

     

That’s it, the vRA appliance is not set up and the Tenant Admin account is also setup. Next up would be the IAAS server installation.

 

Next: vRA Part 4 – IaaS Server Deployment –>

VMware vRealize Automation part 2 – Deployment Architecture – Dedicated Management Cluster

Chan Leave a comment

Next: vRA Part 3 – vRA Appliance Deployment –>

Having had a look at the vRA support matrix, next point to consider in a typical vRA deployment is the deployment architecture which I’ll briefly explain below

vRA is part of the VMware product set that recommends the use of a dedicated management cluster (along with vCD and NSX). This is important because the concept behind this is that a dedicated management cluster will isolate all the VM’s that make up the management infrastructure such as Active Directory VMs, vCenter & SQL server VMs, Monitoring VMs…etc. This separation provides a separate execution context from those virtual machines that provides end user accessible resources, in other words, compute VM’s / production VMs that actually run the business critical workloads. Such a separation inherently provide a number of benefits to an enterprise.

  • Security & isolation of management workloads
  • Elimination of resource (and otherwise) contention between management & production workloads.
  • DR and Business Continuity without replicating un-necessary management components

An example would look like below

1.0 Mgmt cluster

Within a typical vRA deployment, the management cluster would host the following vRA components

  • vRA UI appliance (if using a distributed high availability deployment model, the vRA appliance cluster, Postgre SQL cluster & load balancers)
  • vRA Identity appliance (of is using the vSphere SSO, vSphere SSO server/s)
  • IAAS windows VMs (if using a distributed high availability deployment model, IAAS web servers, Model Manager web servers, MS SQL DB cluster, DEM Orchestrators, DEM Workers & Agents and the required load balancers)
  • vRO appliance (if using a distributed high availability deployment model, vRO cluster and the backend SQL DB cluster with relevant load balancers)

During the configuration of IAAS components, vRA will connect to various end points (such as a vCenter server instance that manages a number of resource clusters) and once an endpoint such as a vCenter instance is connected, a Fabric Administrator would create resource reservations for each cluster managed by that vCenter instance. Once these reservations are created, vRA typically assumes complete control over those clusters (resource reservations within the clusters) to be able to use those resource reservations as how it sees fit. This could present problems if you run your management infrastructure VMs (such as vCenter server and vRA appliances..etc.) in one of those same clusters as vRA will not take in to account the existence of other VMs in the same cluster, that was not created by itself. This could result in vRA deploying VM’s (based on IAAS request from users) which will affect the resources available for the management VMs with a  potential to affect performance of both the management VMs and production VMs (created by the vRA based on blueprints). It is therefore typically recommended that you keep all resource / compute clusters separate from the vRA management VMs and under the full control of vRA itself (no manual creation of VM’s in the resource clusters).

If you have an existing vCloud Director deployment or an NSX deployment, you may already have a dedicated management ESXi cluster in place as these products makes it a mandatory requirement to have one. However even if you don’t and are considering a vRA deployment, I would highly encourage you to have a dedicated management cluster to host the vRA infrastructure components.

An example high level design where vRA along with VMware NSX is deployed using a Management cluster could look like below.

2.0 HLD arhcitecture

 

Next: vRA Part 3 – vRA Appliance Deployment –>

VMware vRealize Automation Part 1 – vRA Support Matrix

Chan Leave a comment

Next: vRA part 2 – Deployment Architecture – Dedicated Management Cluster –>

The first step that should be involved in deploying vRealize Automation in any one’s book is to refer to the support matrix PDF on VMware web site. There are a strict number of support limitations which you must be aware of, and all the key information you need can be found within this document.

I’d encourage you to read the document for complete support details (and stay up to date with newer versions too) but given below is a high level summary of some key contents (based on the current vRA release of 6.2.1).

  • vRA IAAS server
    • Host OS (for IAAS components) – W2k8R2, W2k12 & W2k12R2 only (note that Windows 2008 is NOT supported)
    • IAAS DB: SQL 2008 R2 SP3 or higher (up to SQL 2014)
    • Web Server (for IAAS model manager…etc.): IIS 2008 R2 & IIS 2012 only

 

  • vRA Appliance
    • DB Support: vPostgres Appliance 9.2.4 / 9.2.9.x / 9.3.5.x, PostgreSQL 9.2.4 / 9.2.6 / 9.3.4
    • SSO / Authentication sources: vRA Identity Appliance v6.2, vSpere SSO 5.5 1b or above (up to PSC 1.0 with vSphere 6.0)

 

  • Hypervisor Support (for the vRA Hypervisor proxy agent):
    • VMware: ESX 4.1 to U2, ESX 4.1 to U2, ESXi 5.0 onwards (including ESXi 6.0) – note that Application Director only works with vSphere and NOT other hypervisors
    • Red Hat: KVM RHEN 3.1 only
    • Microsoft: Hyper-V 2008 R2 SP1 onwards (inc 2012 R2)
    • Citrix: XenServer 5.6 through to SP2, 6.0.2 & 6.2 through to SP1

 

  • Hypervisor management platform support (for vRA proxy agent and DEM worker compatibility)
    • VMware: vCenter 4.1 through to U2, vCenter 5.0 U3 onwards (till vCenter 6.0)
    • Microsoft: SCVMM 2012 (Hyper-V) only
    • Red Hat: RHEV-Manager 3.1 / 3.3

 

  • Network Virtualisation support
    • VMware vCNS 5.5.3 only, NSX 6.1 and above (up to 6.1.3)

 

  • Cloud Support (IAAS Endpoint compatibility)
    • VMware: vCD 5.1.x & 5.5.x, vCloud Air
    • Amazon: AWS
    • (Note that Azure is NOT support as a cloud endpoint)

 

  • Image Deployment Methods (IAAS)
    • Microsoft: SCCM 2012 & SCVMM 2012 only, Windows WinPE & WIM imaging
    • NetApp: FlexClone on Data OnTap 7.3.1.1, 8.0.1 & 8.1 (Note that this doesn’t state whether its cDOT or 7Mode. Also, the most latest OnTap version 8.3 is NOT supported yet)
    • BMC: Blade Logic Operations Manager 7.6 & 8.2
    • HP: Software Server Automation 7.7
    • Citrix: Provisioning Server 6.0 & 6.1
    • Linux: Red Hat Linux kickstart, SUSE AutoYaST
    • PXE boot

 

  • Guest OS
    • Microsoft: Windows 7, 8, 8.1, W2K8R2, W2K12 & W2K12R2
    • Red Hat: RHEL 5.9, 5.10, 6.1, 6.4, 6.5, 7.0
    • SUZE: SLES 11 SP2 & SP3
    • CentOS: CentOS 5.10, 6.4. 6.5, 7.0
    • Debian: 6 & 7.0
    • Ubuntu: 12.04 LTS & 13.10
    • Oracle: Oracle Enterprise Linux
    • VMware: ESX/i 4.1 U2, ESXi 5.1 and above (up to ESXi 6.0)

 

  • VDI Connection Broker support
    • Citrix: XenDesktop 5.5 and above (up to 7.6.x)
    • VMware: Horizon View 6.x only

 

  • Task Automation Engines / Scripting support
    • VMware: vCO 5.5.1 and above (up to vRO 6.0)
    • Microsoft: PowerShell 2.0

 

Next: vRA part 2 – Deployment Architecture – Dedicated Management Cluster –>