We’ve just released SovLabs Plugin 2019.8.0. Here’s a quick summary, with all the details below, of what’s new in this latest release.
- The SovLabs Plug-In v2019.8.0 is Certified for vRealize Automation 7.6! VMware released this version of vRA last month.
- SovLabs EULA has been updated. Please read our updated end user agreement here.
- We added new tags, filters and improvements to the SovLabs Template Engine
- We added "2018.1" and "2019.1" into the Version dropdown list in Puppet Enterprise, previously supported in 2018.3.4 and 2019.2.0
- Support for ServiceNow "Madrid" for ServiceNow CMDB and ServiceNow Connector
- Backup as a Service for Veeam now supports Veeam 9.5, Update 4, and we improved performance for Backup Jobs with a large number of VMs
- We added a new Day2 Feature to Backup as a Service for Cohesity. Now you have the ability to Recover Virtual Disk that allows recovering an entire virtual disk
- We added 8 new improvements in our ServiceNow Connector
- We addressed one issue each in Ansible Tower, Snapshot Management, and IPAM Framework and three issues in Ansible Tower for CM Framework.
At SovLabs, we strive to release monthly updates in addition to updating within 45 days of any major VMware vRealize Automation software update. Please see below for the details of our latest software release.
vRA 7.3 Notice
If using vRA 7.3.0, please upgrade to VMware's vRA 7.3.1. On 12/17/2019, VMware is ending general support for vRA 7.3/7.3.1.
- If on vRA 7.3.0, please login to the vRA Appliance and verify Appliance Version is 22.214.171.1247 Build. If not on the 126.96.36.1997 Build, please upgrade to vRA 7.3.1. If on the 188.8.131.527 Build, the VMware vRA Hotfix has been applied that is required for SovLabs.
VMware fixed an issue with form field validations that affects all of SovLabs' provided XaaS forms. VMware also fixed a vRA 7.3.0 vRO CAFE bug related to VMware vRA plug-in for vRO.
vRA 7.4 Notice
The minimum SovLabs plug-in version compatible for VMware's vRA 7.4 is 2018.1.4.
vRA 7.5 Notice
The minimum SovLabs plug-in version compatible for VMware's vRA 7.5 is 2018.2.6.
vRA 7.6 Notice
The minimum SovLabs plug-in version compatible for VMware's vRA 7.6 is 2019.8.0.
Resource: VMware Product Lifecycle Matrix
*Customers currently on a previous version of the SovLabs Plug-in (e.g. 2018.x, 2017.x)
A new SovLabs 2019.x license key is needed in order to use the SovLabs 2019.x Plug-in.
If you are interested in upgrading to 2019.x, please GO HERE to request the new SovLabs 2019.x key.
Prior to performing a new install, please complete all of the pre-requisites via: docs.sovlabs.com - Getting Started
Please follow our Upgrade steps when performing an upgrade of our SovLabs Plug-in
Certified for vRA 7.6!
SovLabs EULA has been updated!
During install of the SovLabs Plug-in and running SovLabs Configuration, the EULA now refers to https://sovlabs.com/eula
SovLabs Template Engine
Added new tags, filters and improvements!
Tags: decrement, ifchanged, increment
Filters: abs, at_least, at_most, ceil, compact, concat, floor, lstrip, newline_to_br, reverse, round, rstrip, slice, sort_natural, strip, uniq, url_decode and url_encode
Allow "." in variables
Enhanced parser error messages
Allow Unicode forward and backward "fancy" quotes
Added "2018.1" and "2019.1" into the Version dropdown list. Previously verified on 2018.3.4 and 2019.2.0
Added "Madrid" into the Version dropdown list. Previously verified on 2019.2.0
Backup as a Service for Veeam
Support for Veeam 9.5, Update 4
Performance improvement for Backup Jobs with a large number of VMs
Backup as a Service for Cohesity
New Day2 Feature: Ability to Recover Virtual Disk that allows recovering an entire virtual disk - either by overwriting the existing disk or recovering to a new (unmounted) device
ServiceNow Connector 2019.8.0
- A 2019.x license key is needed in order to use the SovLabs ServiceNow Connector 2019.8.0
- Added ability to enable the vRA Business Group to be selected at request time by the end-user in ServiceNow when ordering the Catalog request
Import Catalog Item / Modify Catalog Item Mapping Page Enhancements
- New field for "Override vRA Business Group?"
- Updated "Constant" label to "Template"
- Error logs in ServiceNow and ServiceNow Mid Server
- ServiceNow request to show useful error when the request is unable to be generated in vRA
- Hid unnecessary fields during Import/Modify for a vRA Blueprint
- Ansible Tower
- Fixed issue for Static Inventory failing when no dynamic groups are defined.
- Ansible Tower for CM Framework
- Fixed error reporting to report back correct error when an IP address is not defined
- Fixed the error similar to the following: "[WARNING]: * Failed to parse /tmp/awx_inventory_rNDKxh/tmpqWOvv0 with script plugin: Inventory script"
- Fixed error when accidentally appending trailing "/" to vRO Hostname when creating the Ansible Tower Endpoint
- Snapshot Management
- Fixed issue for missing ID(s) from incomplete vRA CAFE/IaaS data that prevented successful mapping to managed VMs in vCenter. Added checking and additional logging.
- IPAM Framework
- Fixed Release IP to release the IP address correctly
|Type||Known Issue + Workaround|
|All||Failed to get latest version of the resource element module_1523032069834331
Version inconsistency between cache and db detected in repo for _______ cached version 0.0.__ db version 0.0.___
Workaround: If the issue occurs consistently, please notify SovLabs immediately. This is resolved 2019.8.0
|vRA/vRO Clustering for vRA 7.3 and vRA 7.4
||vRA does not consistently persist XaaS items to inventory (independent of SovLabs) even though the vRO workflow related to item creation completes successfully.
Workaround: None. SovLabs is pursuing this issue with VMware GSS at the highest priority.
SovLabs KB Article 6000197373
|Custom Naming||Unable to rename deployments in vRA 7.x due to vRA Platform limitation.
The deployment name defaults to the blueprint name appended by a dash and an auto-generated 8-digit number (e.g. blueprintName-12345678)
Workaround: The deployment name can be influenced by adding a vRA Custom Property at the composite blueprint level (versus at the machine component in the blueprint) with:
|Manage Credentials for Puppet Open Source with Foreman||Unable to update a credential that is tied to Puppet Open Source with Foreman
Workaround: Update the Foreman Master or Foreman Agent and create a new credential directly inline and submit.
|F5||Issue: A nested vRA blueprint with the F5 virtual component in the child vRA blueprint that defines the value for Pool Health Monitors field fails with a: Status Code 400 'The value for the 'poolHealthMonitors' field should be among the permitted value' for vRA 7.2. This issue does not occur for vRA 7.3 nor for a single (non-nested) blueprint.
Workaround: Do not define (pin) the value for Pool Health Monitors (or any field that is Array/String) on the F5 Virtual component in the child blueprint for a nested blueprint.
vRA 7.4, 2018.1.4
During provisioning for vRA 7.4, vRO server.log will log errors when the SovLabs RESTipe executes a vRO workflow. The error logs are benign and can be ignored. vRO workflows are executed successfully via SovLabs RESTipes.
Issue: When defining multiple F5 virtual components and different VIPs are tied to use the same Pool Name (often when manually defining the Pool Name), the VIPs and the Pool is not removed from F5 when destroying the deployment even though the Pool is empty.
Workaround: Please try to keep a 1:1 relationship between a VIP and Pool. A circular dependency exists when trying to remove the VIPs tied to the same Pool and proper disposal cannot take place.
Issue: Large concurrent builds using SovLabs Infoblox IPAM/DNS for F5 failing on IP Address in use
Workaround: Please open a support ticket if you experience this issue.
|Notifications||Updating a Notification Configuration's Configuration label will create a duplicate vRO Inventory item with the previous name. Not allowing the customer to create another Notification Configuration with the previous name.
Temporary Workaround: Please run the vRO Workflow: SovLabs > Notifications > vRA ASD > Notification > Delete Notification Configuration and choose the Notification Configuration with the previous name to delete.
|vSphere Snapshot Management||If using vSphere Snapshot Management with any of the Backup as a Service modules (Cohesity, Rubrik, Veeam) may result in an email notification of a Backup as a Service snapshot.
If the Backup as a Service snapshot lives beyond deletion time set in Snapshot Configuration, will get deleted.
|Property Toolkit||Day2 on vRA VM "Manage Properties (SovLabs Property Toolkit) does not have a correct reflection of the fields: Hidden, Encrypted, Show in Request for a Property when the Action field is Update Existing Property.
Workaround: Please check the checkbox during an Update of a Property on a VM for any of the applicable fields: Hidden, Encrypted, Show in Request and then Submit.
Property Toolkit vRA Catalog Item: Entity Property Assignment and Reporting has an issue when creating a new vRA Blueprint Custom Property and setting it to "Overridable = false" will create the vRA Blueprint Custom Property as "Overridable = true"
Workaround: Please manually set "Overridable = false" on the vRA Blueprint
Property Toolkit dynamically setting an Encrypted property via "SVL_" vRA Property Group will error out.
Workaround: Please set the Encrypted property on an appropriate vRA Entity. Currently, unable to set Encrypted properties dynamically on the machine.
|Puppet Open Source with Foreman (starting from release 2018.2.4)||The Host Parameters field is optional. When no Host Parameters are defined, an error stack trace for null pointer exception is in the vRO logs.
Workaround: None, the error stack trace is benign. The provisioning succeeds and the machine is added correctly into Foreman.