Important Notes

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 Build. If not on the Build, please upgrade to vRA 7.3.1.  If on the 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.


*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.


SovLabs Documentation

New Install

Prior to performing a new install, please complete all of the pre-requisites via: – Getting Started



Please follow our Upgrade steps when performing an upgrade of our SovLabs Plug-in


What’s New?

  • SovLabs Licenses
    • A new SovLabs 2019.x license key is needed in order to use the SovLabs 2019.x Plug-in
    • ServiceNow Connector
      • ServiceNow Connector will need a 2018.x license key


Resolved Issues

  • Ansible Tower
    • Added an additional check and WARNING log for when Ansible Tower returns a conflict when trying to remove a host that occurs due to a database lock Ansible Tower has on the Inventory due to running jobs.
    • Added logic to disable and mark hosts that should be removed by SovLabs upon disposing when Ansible Tower’s database locked the inventory (409 error)
      • Added logic to remove the marked/disabled hosts during AnsibleTowerMachineProvisioned and AnsibleTowerMachineDisposing
      • Added a vRO scheduler to run every 10 minutes to attempt to remove any disabled/marked hosts
    • Incremented the default lock timeout setting from 180 minutes to 2 hours to reduce “Unable to obtain lock ANSIBLETOWER_GROUP <<environment name>> in 180” errors for Static Inventory (hotfix 2018.3.12 and 2018.3.13)
  • Custom Naming
    • Added enhanced locking and logic to help alleviate contention when requesting multiple/concurrent deployments for Custom Naming to reduce “Failed to get version of Resource Element” errors.
    • Resolved issue with Custom Naming going into an approximately 2 hour loop when unable to derive a unique hostname.  Custom Naming now compares the previous hostname with the current hostname generated to verify that the same hostname is not generated twice.
  • F5 (hotfix 2018.3.9)
    • Added enhanced locking and logic to help alleviate contention when requesting multiple/concurrent deployments for Custom Naming to reduce “Failed to get version of Resource Element” errors.
    • The lock is enabled by default.  To disable locking, set a vRA Property “SovLabs_F5EnableLocking” to “false“, without quotes
  • ServiceNow Connector
    • Resolved issue with the Modify Catalog Item Mapping form not rendering as expected in Update Set 2018.3.0.2 that affects all customers installing new from 2018.3.0.1.
  • ServiceNow CMDB
    • Resolved issue with the JSON Template field not honoring the user’s template on Update ServiceNow CMDB Configuration vRA Catalog Item.
  • Snapshot Management (hotfix 2018.3.15)
    • Added an additional check for verifying completion time before running another instance of Manage Snapshots in the event of a previous long running Manage Snapshot scheduler.
    • Added logic which handles unexpected server faults from vCenter which occur when attempting to delete a snapshot that has already been deleted.  Often seen when multiple snapshots with the same name exists for the VM
    • Fixed hash vmStub constructors/readers so that keys without a value will not cause a null pointer exception error


Known Issues

Known Issue + Workaround
Failed to get latest version of the resource element {{ name }}
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 will be resolved in the upcoming GA release of the SovLabs Plug-in, expected May 2019.

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:

  • Name: _deploymentName
  • Value: Unique value utilizing the SovLabs Template Engine

*Note: Using the same property value will result in deployments with the same name

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.

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.

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.

Recommended Reading