VMware Orchestrator Tips: Stopping a Second Execution of a Workflow

Kinney Group’s own Troy Wiegand hosts this blog series, which will outline some simple tips for success with VMware vRealize Orchestrator. Join Troy as he applies his automation engineering expertise to shed some light on VMware! 

When you have a really important workflow to run in VMware vRealize Orchestrator, you don’t want another one running at the same time. As of right now, vRO doesn’t have an option for stopping that second workflow execution from happening simultaneously. Never fear, though—Kinney Group has you covered. 

The One and Only Workflow

Some workflows are just more impactful than others. They have the power to do serious damage to your environment—they could tear down your infrastructure, or they could build it up. Depending on what you’re orchestrating, running another workflow simultaneously to this crucial one could be problematic. Luckily, we can use a workaround to prevent any potential damage. When implemented, the workaround will look like this: 

Figure 1 – The workaround functions to stop a second execution while the first one is running

Configuring the Field

The ideal result of this workaround is that when you try to run a workflow for a second time while it’s already running, vRO will send an error message to prevent that redundancy. Let’s investigate how that alert happens by going to the Input Form. The text field that contains the error message is populated with some placeholder text to identify the error. Under “Constraints,” note that “This field cannot be empty!” is marked as “Yes” from the dropdown menu. This ensures that a user cannot submit the form unless the field has something in it. However, that’s only possible if the field itself is visible. Set the “Read-only” menu to “Yes” under the Appearance tab so it can’t be edited. 

Figure 2 – The configuration of the workaround, as seen through “Input Form”

The External source action is set to “/isWorkflowRunning,” and it’s configured from the variable “this_workflow.” You can add this as a new variable and assign the same value as the name of the workflow you wish to run without concurrencies.  

New call-to-action
Figure 3 – The form to edit a new variable

By examining the script, we can see that we’ve inputted our workflow ID. We’ve also configured the server to get executions. (Alternatively, you could skip to tokens = executions for a simpler function.) The flag below that function should be set to “false.” We can then check the state of every token, and if it’s “running,” “waiting,” or “waiting-signal,” set the flag to “true.” Those are the three states for a workflow that indicate being in motion or in progress, so it’s essential to identify them as triggers for our error message. 

Figure 4 – The workaround script

The Result: Your Workflow Runs Alone

This combination of settings allows the field to appear when you try to run a workflow while another execution of it is currently running. This way, when you try to run an interrupting workflow, it’ll be stopped.  

We hope this tutorial has been helpful in streamlining your workflows and making the most of VMware Orchestrator! We’ve got more tips for vRO here. Fill out the form below to get in touch with automation experts like Troy:

New call-to-action

VMware Orchestrator Tips: Dynamically Viewing Snapshots Based on Selected VMs

Kinney Group’s own Troy Wiegand hosts this video blog series, which will outline some helpful VMware Orchestrator tips. Join Troy as he applies his automation engineering expertise to shed some light on VMware! 

One of the impressive capabilities of VMware vRealize Orchestrator (vRO), a tool that creates workflows to automate IT operations, is the snapshot feature. Have you ever had to manipulate or manage multiple snapshots on different Virtual Machines (VMs), all at the same time? It may seem like the only option is to revert or delete multiple snapshots. Maybe this has led you to revert VMs to snapshots with the same name, or to delete more than you intended. Kinney Group engineers use this simple method to view various snapshots using selected VMs. 

The Secret Menu

Begin with an array input by clicking “Run.” Populate the array with your selected VMs using the dropdown list and click “apply.” When the window closes, hover your cursor over the field just below the list of VMs, and you’ll see a gray dropdown bar appear. This subtle menu feature identifies snapshots attached to each VM! Select one from the dropdown and click “Run.”  

Figure 1 – The gray menu appears as a dropdown when the user hovers over it

The resulting schema populates with a script that reveals the snapshots. From this script, users can delete or revert all snapshots.  

Return to the Input Form to see how we populated these VM names. The “Appearance” tab on the left indicates that the display type we used is a DropDown. Our value options came from an external source, the action specifying “get all snapshots of all VMs.” 

Figure 2 – select “DropDown” as the Display type in the Appearance tab and “external source” in the Values tab
New call-to-action

Branching off with Trees

Snapshots are done through trees. For example, you could perform x, y, and z action, then take a snapshot to preserve the state of that VM. This will be saved in a tree structure, with the snapshot containing x, y, and z actions taken. The snapshot you take after performing another action will capture the updated workflow. Working with multiple snapshots allows you to track various changes in the environment, and presents the opportunity to revert to a previous state.

Figure 3 – The action exhausts all snapshot trees

Let’s revisit the action. We’ve fed in the VM array as an input. For all VMs, we ask, “Do we have any snapshots?” If so, we can go through the snapshot tree and run the function on all trees. To get all of our snapshots by name, we must go recursively through the tree structure. A function to do just that is included in the array. This function will loop through the array until it exhausts all trees, after which the resultant snapshots will be captured within the array. A string array will return the snapshots back to our workflow execution input form.

What’s in a Name?

You may be asking: why are we looking at the name rather than the actual snapshot object? The reason for this is that despite the items sharing a name, there will be many different objects. The only way to perform mass operations on our selected VM based off of one snapshot name would be to feed it a singular snapshot. This workaround also allows you to have different behavior based on the names. For instance, if all VMs and questions have a specified baseline snapshot, and you wanted to revert all snapshots to that standard, you could invoke different behavior. You could specify whether you wanted the first snapshot that fit the baseline or the last one. In the scheme of the workflow, the snapshots could go either way.

If your aim is to delete snapshots, you could ask the same question: why look at the name rather than the snapshot object? This method allows you to specify if you want to keep or delete multiple snapshots or only ones with certain properties. You may be in a situation where you’ve given multiple snapshots the same name, and you may only want the first few or most recent few snapshots. Pruning like this will save more space in the data store. (Note: This utility can also be combined with a dual list picker to select the VMs differently than in a standard array.)

A Snapshot is Worth a Thousand Data Points

Applying this KGI utility for VMware Orchestrator in your own workflows makes snapshot management and manipulation a breeze!

We hope you got some inspiration for your own workflows. Stay tuned for more VMware Orchestrator tips! There’s plenty more to come from the blog and on our YouTube channel. In the meantime, fill out the form below to get in touch with automation experts like Troy:

New call-to-action

VMware Orchestrator Tips: Using Dual List Input Fields to Select VMs

Kinney Group’s own Troy Wiegand hosts this video blog series, which will outline some simple tips for success with VMware vRealize Orchestrator. Join Troy as he applies his automation engineering expertise to shed some light on VMware! 

An exciting upcoming feature for VMware is the capability to link lists to variables in VMware vRealize Orchestrator (VRO), a solution that creates workflows to simplify IT operations through automation. As we wait eagerly for that tool to be made available, we have a Kinney Group workaround that I’d like to share. This solution provides a user-friendly interface for running multiple operations on our Virtual Machines (VMs) at the same time. 

Utilizing Dual Lists

Today, we’ll be using dual list input fields to select VMs in VMware. Starting within the workflow, go to “Edit” mode along the top banner and click “Run. This will open the dual list field. Similarly to other selecting platforms, use “Shift” to select a range or “Control” or “Command” to select nonconsecutive items. The VRO interface considers anything on the right to be selected. Anything remaining on the left won’t be selected. By viewing the “Virtual Machines” page, you can then see that modifying the contents of each list in turn modifies the value for the input shown below. 

Figure 1 – All VMs are selected (on the right) except the two in the left box

Reviewing Your Script

Viewing the details of the script can help illuminate what exactly you’re inputting into the form. This view can be found within the source value; you can then click “Edit” on a value to get a bigger view. For all VMs in an array, take the name and insert it into a sorted array at the end of the script. Make sure the field includes return result to ensure the input populates correctly in the dual list.  

Top KGI Tip: enter your commands in a while loop to keep track of work within asynchronous tasks! 

Figure 2 – The script, including while loop and array

Input Form

Open the “Input Form” viewer. You’ll see we have one input. Instead of feeding a virtual machine array into this dual list, we’ll be feeding in a string of several VMs. To populate the Dual List pickers, go to “Values” on the right-hand side of the screen and select a source. I’ll be using the “External Source” field (shown here as the Default Value). Using a text field to view the input string, make sure your Value source is set to Compute a value and your operator is set to Concatenate in the “All VMs” field.  

Figure 3 – the “Values” field for in_vm_csv with desired settings
New call-to-action

View your Script in Schema

Once the source is inputted, we can view the script in the Schema tab to undo the array formatting. Here you can choose either to use “allVms” or to select only certain VMs. Generally, we turn the visibility “off” for this field to ensure a cleaner visual experience. Save your changes before navigating to the “Run” tab.  

Figure 4 – a view of the script within the “Schema” tab

The Moment of Truth

In the “Run” tab, click on “Virtual Machines” and select which inputs to use—then run the script! Use the “Logs” tab to see how the script is populating. As a result, we can see that VRO found an object for the selected fields. This solution has many applications, but we most often use it when running multiple operations on our virtual machines at the same time.

Figure 5 – the resultant log, with the “Found” object highlighted

We hope you picked up some expertise for your VRO toolkit. Stay tuned for more VMware Orchestrator tips! In addition to handy automation workarounds like this one, you can expect posts on workflow execution and snapshot viewing in the future. In the meantime, fill out the form below to get in touch with automation experts like Troy:  

Contact us!

New call-to-action