SuzanneZurich Respected Contributor.
Respected Contributor.
191 views

(OO) Support Tip: Content pack Virtualization version 1.9.1 Get Virtual Machine operation behavior

Content back Virtualization version 1.9.1 Get Virtual Machine operation (Virtualization [1.9.1]/Library/Integrations/VMware/VMware Virtual Infrastructure/Virtual Machines) has a behavior change from previous versions (1.7.0 and 1.8.0).  This operation has an input vmIdentifierType which can have valid values inventorypath, name, ip, hostname, uuid, or vmid.  Retrieve each object one at a time from an initial search query as the one used in the SQL Query operation.  Customer has a flow that can call this operation with a valid vmid in some cases or with a blank value in others looking for multiple VMs in the data center.  In the case where the customer provides a valid vmid, it should return information for this virtual machine on the first call then a "no more" result on subsequent calls.  This is the behavior expected and this it what happens in previous versions of the content pack (1.8.0, 1.7.0).  However in version 1.9.1, the operation results in an infinite loop returning the same virtual machine over and over.  Is this an expected change?  This is not indicated in the 1.9.1 release notes.  If this behavior change is purposeful, what is the reason for the change?

There was a design change in the Get Virtual Machine operation (Virtualization [1.9.1]/Library/Integrations/VMware/VMware Virtual Infrastructure/Virtual Machines) to fix a product defect (Defect QCCR8C30565 Get Virtual Machine - Operation doesn't return the same result in consecutive calls). The values vimid, hostname, etc should be unique. It was considered bad design to treat the result as a list when this is only one element. A list will be returned only when you do not know the value for the vmType you provide.

Regarding QCCR8C30565 Get Virtual Machine - Operation doesn't return the same result in consecutive calls…

Technical problem description:
Design issue:
1. The list of virtual machines retrieved by underlying code was cached and stored in the session. The session key is a combination of the input values - each instance of the operation in the same flow and used the same inputs = uses the same list on each iteration an element is removed from the list until it is empty.
2. When providing vm specific inputs (vm identifiers) then a list containing exactly 1 element is returned and stored in the session which gets removed after the first iteration and an empty list is returned on subsequent iterations which causes the defect.

Technical solution description:
Disabled the caching mechanism (prevented the resulting vm list from being stored in the session) when the vm identifiers are provided. The search is retriggered for each subsequent call to the operation when vm identifiers are provided.

Documentation defect QCCR8C33434 Content Pack Virtualization [1.9.1] behavior change for Get Virtual Machine operation has been created to add the following information into the release notes:
Target Section: Enhancements
Text to add: "The Get Virtual Machine operation has been enhanced to retrieve the questions that are pending the execution of a virtual machine. The operation contains two new outputs which will return the question as well as the possible answer choices. Check the description of the operation for more details."

Please contact Technical Support if you have any questions.

Please see the knowledge document at https://softwaresupport.hpe.com/km/KM02888515

Labels (1)
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.