VMware vRealize Automation 8.6.1 was released on November 19, 2021. With this release, VMware has provided several enhancements and new features including significant Onboarding and Deployment enhancements, Extensibility and TKG improvements and new SaltStack and Carbon Black integration.
What’s New
Updates included in vRealize Automation 8.6.1
- Assign icons to onboarded deployments - To give end user more information about deployments, vRA updates the deployment Edit action to support assigning custom icons to onboarded deployments.
- SaltStack and Carbon Black integration - Carbon Black and SaltStack SecOps are now integrated to pass information from Security Teams to Infrastructure Teams.
- Scale out migrated deployments - After the Cloud admin migrates deployments, you can scale out existing resources within that migrated deployment.
- Migrate property groups with external values - The Migration assistant tool now supports the migration of property groups with external values.
- Create Extensibility Subscription for lease expire - Cloud admins can extend the machine management process and trigger specific actions when a machine lease is expiring.
- Deployment Limit Policy to define Deployment and Deployment Resource Limits - The Deployment Limit Policy allows Cloud Admins to define Deployment limits to restrict CPU count, Memory, and VM count. These policies also allow Cloud Admins to define Deployment Resource limits to restrict CPU count and Memory of specific resources within a larger deployment.
- Assign VCT to onboarded deployments - You can assign a VMware Cloud Template (VCT) to onboarded deployments.
- Ability for devops project users create a TKGs cluster - DevOps project Users can now create TKG clusters.
- SaltStack SecOps support for Tenable import scans of Windows systems - Users who leverage Tenable now have the ability to import scans for Windows systems as well as Linux systems.
Updates included in vRealize Orchestrator 8.6.1
- vRealize Orchestrator now supports the following versions of the Node.js and PowerCLI runtimes:
- Node.js version 14
- PowerCLI version 12.3.0 for PowerShell 7.1
API Changes
The following API changes are included in vRealize Automation 8.6.1:
- CMX API
- New APIs to create and manage Cluster plans and to retrieve storage classes for vSphere instance
- [GET] /cmx/api/resources/cluster-plans - searching cluster plans by name and cloud account self link id two optional parameters: 1. cloudAccountSelfLinkId: cloud account self link id (only self link id, not the entire selfLink string) 2. name: cluster plan name
- [POST] /cmx/api/resources/cluster-plans - creating a cluster plan, the body of the request shall contains a valid cluster plan entity sample cluster plan entity: { “cloudAccountSelfLinkId”: “self-link-id”, “definition”: { “spec”: { “distribution”: { “version”: “v1.20” }, “topology”: { “controlPlane”: { “count”: 1, “class”: “best-effort-xsmall”, “storageClass”: “vsan-default-storage-policy” }, “workers”: { “count”: 1, “class”: “best-effort-xsmall”, “storageClass”: “vsan-default-storage-policy” } } } }, “name”: “small”, “type”: “TANZU_CLUSTER_PLAN” }
- [GET] /cmx/api/resources/cluster-plans/{id} - find a cluster plan by id string
- [PUT] /cmx/api/resources/cluster-plans/{id} - update an existing cluster plan item
- [DELETE] /cmx/api/resources/cluster-plans/{id} - remove an cluster plan item
- [GET] /cmx/api/resources/vsphere/endpoints/{endpointSelfLinkId}/storage-classes - get all storage classes identifiers for a vSphere endpoint
- Relocation (Onboarding) API
- New restrictions added to PATCH action on onboardingBlueprintState
- Onboarding Blueprints
- (/relocation/onboarding/blueprint/) now enforces the following restrictions on the PATCH action:
- name must be provided if either autogenerate == true OR autogenerate == false and templateLink is provided
- if autogenerate == true templateLink provided in PATCH request will be ignored
- if autogenerate == false and templateLink is not provided, then name will be ignored in PATCH requestThe following new restriction is now enforced on the POST action:
- A request to create a new onboardingBlueprintState now requires the name field to be populated unless autogenerate == true. A name will no longer be automatically generated unless autogenerate is set to true.
- Saltstack: RaaS API
- The vman.import_scan_via_api is enhanced to accept “carbonblack” as an additional vendor to import a vulnerability scan from. Apart from that, the API usage remains the same as previous releases.
Resolved Issues
The following issues have been resolved in vRealize Automation 8.6.1:
- Administrator Role missing permissions - When SaltStack Config is integrated with vIDM and has a role of Administrator will not be able to view minions, minion keys or accept minion keys.
- vRealize Automation Network Profiles created for AWS & Azure cloud accounts that contain discovered Networks and Security Groups can have missing items - vRA Network Profiles created for AWS & Azure cloud accounts and containing discovered Networks and Security Groups can have missing items (i.e. Networks and/or Security Groups).
- Exceptions for READ operation are not properly processed - If a back-end error happens for deployment iterative updates, only a generic error message is shown.
- Request tracker is not working for resource views - On the All resources page, after selecting a machine and performing any day 2 action, the request tracker does not appear unless a manual refresh is initiated.
The following issues have been resolved in vRealize Orchestrator 8.6.1:
- The following error message is displayed above the workflow input form when using the RUN AGAIN functionality to start a new workflow run: Some data cannot be retrieved. If the problem persists, contact your system administrator - The value of an input field consisting of simple types of non-object arrays, such as Array/number or Array/string, is incorrectly evaluated and passed to an external source action that is used to populate the value of another input form field.
- HTTP-REST plug-in must handle HTTP header names in a case-insensitive way - Based on RFC 2616, header field names must be treated as case-insensitive. Prior versions of the HTTP-REST plug-in made a distinction between headers with the same name, but with different casings and this can lead to unwanted results.
- After migrating from vRealize Orchestrator 7.6 to vRealize Orchestrator 8.6, the vco-app pod fails to start because of a SQL script failure - The vco-app pod fails to start because the install_rpms init container exits with a non zero status.
- After upgrading from vRealize Orchestrator 8.4.0 to vRealize Orchestrator 8.5.1, you are unable to load the vRealize Orchestrator Client when you are logged in as a non-default tenant but you can log in as as a default tenant - A subtenant is unable to use the embedded vRealize Orchestrator Cient in vRealize Automation even if the client is registered as an integration for that particular vRealize Automation tenant.
- You encounter workflow regressions - The default RequestConfig object used after refactoring was unintentionally changed and this introduced compression by default, which, for example, causes the Apache HTTP Client to remove the Content-Length header from the response. Such differences might cause regressions in workflows.
Additional information on vRealize Automation 8.6.1 can be found at the following links: