vRA 7.3 Notice
If using vRA 7.3.0, please upgrade to VMware's vRA 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.
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
New License Key provided?
Please perform the following:
SovLabs 2018.3.x Plug-in Details
|SovLabs Plug-in Version||Details|
Released January 8, 2019
Released December 20, 2018
Released December 4, 2018
Released November 26, 2018
SovLabs OVF/OVA support for vRA 7.5
Released November 13, 2018
BlueCat Selective Deployment for BlueCat version 8.3.2 and above "to selectively deploy specific DNS resource records to managed DNS/DHCP Servers, enabling users to deploy records in real time based on a specific change via API" - DNS Integrity: The Need for Speed BlueCat Blog
ServiceNow Connector Features/Enhancements and Resolved Issues
|Release Date||Released From||Release Version||Purpose|
|January 16, 2019||2018.3.4||2018.3.5||Ansible Tower
|January 18, 2019||2018.3.0||2018.3.6||BlueCat DNS
|Type||Known Issue + Workaround|
|Single node vRO||Failed to get latest version of the resource element SovLabs Plug-in 2018.3.x Release Notes
Workaround: None. This Please re-submit the request of interest. SovLabs is pursuing this issue at the highest priority.
|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.
|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
|SovLabs vCenter Endpoint||Version "6.7x" does not show in the dropdown list.
Workaround: Please select "6.5x" from the Version dropdown list. We have certified vCenter 6.7 in 2018.1.5.
Resolved in 2019.6.0
|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.