JamesMW
Enthusiast
Enthusiast

Resource Actions / mapToVCVM Bug !

All,

I've been working through a bug lately with this action.

- Create Resource Action through the vRA ASD Resource Actions tab

- Execute actions against items in your vRA Inventory

- Action doesnt execute on the resource you selected in the inventory

What is happening is before the form loads, vRA runs a orchestrator action (com.vmware.vcac.asd.mappings.addToVCVM) to find the Vc:VirtualMachine object you've initiated an action against so it's properties are available to the form....well that code looks like this:

var type = 'VC:VirtualMachine';

var vmMoRefId = vmProperties.get('EXTERNAL_REFERENCE_ID');

var foundVms = System.getModule("com.vmware.vcac.asd").findVcObjectsByMoRefId(type,vmMoRefId);

if (!foundVms || foundVms.length == 0) {

  System.warn('No VMs with MoRefId ' + vmMoRefId + ' were found');

  return null;

} else {

  if (foundVms.length > 1) {

       System.warn('More than one VM with MoRefId ' + vmMoRefId + ' was found');

  }

  return foundVms[0];

}

This code

System.getModule("com.vmware.vcac.asd").findVcObjectsByMoRefId

Loops through all vCenter connections you have in vRO, looking for VM's that match the moid of the item in vRA you ran the action against.

The problem occurs in the last block of code when if more than one VM is found with the morefid, it simply warns the console, then returns the first one in the array!!!!! Consider the example where you multiple vCenters added to vRO, there is potentially overlap of morefid's (in fact i ran some queries i have over 300 overlaps). What this means is when you run an action and a morefid is shared with another VM in your vCenter world, this code doesn't actually check that the item you searched for, was the correct one. It is running the action on a random VM that matches the vmoid which may or may not be the one that you selected in the items list.

I've modified this code to actually check the VM we select is the one we searched for:

var type = 'VC:VirtualMachine';

var vmMoRefId = vmProperties.get('EXTERNAL_REFERENCE_ID');

var foundVms = System.getModule("com.vmware.vcac.asd").findVcObjectsByMoRefId(type,vmMoRefId);

if (!foundVms || foundVms.length == 0) {

  System.warn('No VMs with MoRefId ' + vmMoRefId + ' were found');

  return null;

} else {

  if (foundVms.length > 1) {

  System.warn('More than one VM with MoRefId ' + vmMoRefId + ' was found');

  }

  var MachineName = vmProperties.get("MachineName").toLowerCase();

  var ret = null;

  for each(var item in foundVms)

  {

       System.log("\tChecking: " + item.name);

       if(MachineName.indexOf(item.name.toLowerCase()) > -1)

       {

            System.log("\t\tMatch VM Name: " + item.name);

            ret = item;

            break;

       }

  }

  if(ret == null)

       throw("Couldn't find the VM in vCenter");

  return ret;

}

Any word on if this a known bug? Or if its resolved in a later release of the workflows that I may not be running?

Thanks,

James

2 Replies
BenNeise
Contributor
Contributor

Hi James,

Did you ever get a resolution for this?

We found this same issue in 6.01, and raised an SR. We were given a workaround, which looked like this:-


Configure the Orchestrator workflow with a VC:VirtualMachine object as input, but also set it to require the machine name as a string input. In the workflow, discard the VC:VirtualMachine object (as it may have matched against the wrong object) and instead use the machine name string input to get the correct VC:VirtualMachine (or vCAC:Entity / vCAC:VirtualMachine) object.


Set up the vRA Resource Action to pass the machine name to the Orchestrator workflow and set it's default value to be the name property of the VM object. This input field can then be hidden from the user.

Recently, I started on a workflow which I wanted to use as a Resource Action to present the user with a list of available ISOs from a folder on a datastore in the same cluster as the virtual machine. This uses the cluster property of the VC:VirtualMachine input to run an Orchestrator Action which lists the available ISO files. Using the above workaround means that the presentation takes a very long time to render (getting the VC:VirtualMachine object by name is quite slow).

Seeing as - since we had raised the original issue, we'd since upgraded from 6.01 to 6.2, I was hoping that the issue had been fixed, but it looks like my mapToVCVM action is identical to the "unfixed" one you posted above. I was hoping that this issue had been fixed.

If not - is there any way to edit the mapToVCVM action (overriding the lack of rights to Edit contents)?

0 Kudos
jnagle17
Contributor
Contributor

In vRA on Advanced Services we created a new Resource Mapping.  The Catalog Resource Type= Virtual Machine and Orchestrator Type= VC:VirtualMachine, we chose mapping script action and pointed to our Action in vRO (see code below)

Then whenever we called an action we just refereneced that resource type.  This has resolved the issue for us, hope it works for you too.


cheers
-Joe

=====================================================================================================================

Action Name: vCACVM to VCVM

Action Description:  Action used by ASD to map vCAC resource of type IaaS VC Virtual Machine to vCO VC Virtual Machine. This has been corrected to use the VMUniqueID instead of the MoRef which can cause issues when using multiple vCenters


input: vmProperties, Type: Properties
output: VC:VirtualMachine

Code:

//Need to get to the vCAC VM to get the VMUniqueId to get Unique VM from VC
var machineId = vmProperties.get("machineId");
var vcacVm = Server.findForType("vCAC:VirtualMachine", machineId);
var uuid = vcacVm.vmUniqueID

var vmMoRefId = vmProperties.get('EXTERNAL_REFERENCE_ID');
var foundVms = System.getModule("com.vmware.vcac.asd").findVcObjectsByMoRefId('VC:VirtualMachine',vmMoRefId);
for each (vm in foundVms){
if (vm.config.instanceUuid == uuid){
  var vcVm = vm;
  break;
}
}

if (!vcVm){throw "No VM found!"}
return vcVm;