Cannot import Puppet Learning OVA in ESX: 47:7:VALUE_ILLEGAL

A couple of weeks ago I was asked to import a Puppet learning OVA in ESX. Sounded pretty easy… But it wasn’t…

When I started the import I got an error:

Issues detected with selected template. Details: – 47:7:VALUE_ILLEGAL: Value “PIIX4” of ResourceSubType element not found in []. -56:7:VALUE_ILLEGAL: Value “PIIX4” of ResourceSubType
element not found in [].  -65:7:VALUE_ILLEGAL: Value “3” of Parent element does not refer to a ref of type DiskControllerReference

Hmm, something went wrong. But what?

The first step I took was opening the OVA (with 7Zip) and have a closer look at the OVF that was inside. Details about what you see inside an OVF is explained here:

The error was that value 3 is not a valid reference to a disk controller. And indeed, the blog revealed that 6 was the resource type for a SCSI controller. With this information I editted the OVF file:

<rasd:Description>SCSI Controller</rasd:Description><rasd:ElementName>scsiController0</rasd:ElementName><rasd:InstanceID>3</rasd:InstanceID><rasd:ResourceSubType>lsilogicsas</rasd:ResourceSubType><rasd:ResourceType>6</rasd:ResourceType>

<rasd:Description>SCSI Controller</rasd:Description><rasd:ElementName>scsiController1</rasd:ElementName><rasd:InstanceID>4</rasd:InstanceID><rasd:ResourceSubType>lsilogicsas</rasd:ResourceSubType><rasd:ResourceType>6</rasd:ResourceType>

And after saving the file I could import the OVF.

The reason for this “error” is that the OVA is not meant for ESX but for VMware Workstation

New accounts cannot log in to vRealize Automation

In my current position I manage a vRealize Automation environment which is also connected to a vRealize Orchestrator server.

The vRO server is using vRA as the Identity Provider.

For some reason new accounts were not able to log in to the vRO client.

So the first thing we checked was the synchronization with Active Directory in the vRA. Everything looked fine (green checkmark).

But the problem was not in the synchronization in the tenant I was working in. It was in the default tenant.

This synchronization was running every week but stopped working. The reason had to do with the Safeguards.

Sync Safeguards limits the number of changes that can be made to the User and Groups when the directory syncs.

Synchronization fails if the changes are more than the percentage that is set.

After manually starting the sync and overwriting the safeguard the new users were added and were able to log in.