Now that we have installed, configured, and integrated Orchestrator in our VMware vSphere infrastructure, we can finally have a look at how to use the product. We will learn how to use pre-created workflows that exist in the Orchestrator library. This includes running and stopping them, checking their outcome, and dealing with errors.
We will use the Orchestrator Client as well as the vSphere Web Client.
For this chapter, we need to have Orchestrator configured to use the vSphere vCenter. If you need help with this, have a look at Chapter 3, Integrating Orchestrator with vSphere. We will cover the following topics here:
- Workflow basics
- Starting workflows
- Workflow – renaming the virtual machine
- Handling errors
- Starting workflows from the vSphere Web Client
- Import and export workflows
- Scheduling workflows
Before we actually start working with the Orchestrator workflows, we should first have a look at how the Orchestrator Client works.
To open the Orchestrator Client, perform the following steps:
- Open a web browser such as Firefox, IE, or Chrome.
- Enter the IP or FQDN of the Orchestrator Appliance. The Orchestrator homepage opens.
- Click on Start Orchestrator Client.
- Your Java environment will now start. You may be required to acknowledge that you really want to start this application.
- You will now be greeted with the login to Orchestrator. If you have configured Orchestrator with SSO (see Chapter 2, Deploying and Configuring the Orchestrator Appliance), enter a user who is a member of the Orchestrator Admin group. If you are using an unconfigured Orchestrator, just enter
vcoadminas the username andvcoadminas the password. This is a preconfigured user that allows you to login and use Orchestrator directly. - Click on Login. The Orchestrator Client will load after a moment.
When you open the Orchestrator Client, it will be in the Run mode. There are three modes in total—Run, Design, and Administer.
Each of these modes is used for different phases of the workflow lifecycle. In the following image, you will see a collage of all the Orchestrator icons, which is followed by a table with a short description about what each icon is used for:
|
Icon |
What it does | |
|---|---|---|
|
My Orchestrator |
This gives an overview of all the active tasks and configures non-admin access. |
|
Scheduler |
This manages the scheduled workflows. We will schedule workflows later in this chapter. |
|
Policies |
A policy is a trigger that can be configured to trigger when certain events occur. |
|
Workflows |
This manages everything that has to do with workflows. |
|
Inventory |
This shows all the objects that each plugin has access to. |
|
Actions |
This manages everything that has to do with actions. Actions are like mini workflows. We will discuss Actions in detail in Chapter 6, Advanced vRO Scripting with JavaScript. |
|
Resources |
A resource is a file that can be used from workflows. |
|
Configurations |
Configurations are centrally defined attributes that are available to all workflows. |
|
Packages |
A package contains workflows, actions, as well as all the other elements that export and import the Orchestrator solutions. We will work with packages in Chapter 9, Packing It All Up. |
|
Policy templates |
These are the templates for policies. |
|
Authorizations |
This is deprecated and not used anymore. |
|
Web Views |
Web Views are HTTP-based web pages that interact with Orchestrator (deprecated and removed from Version 6). |
We do not have the page count to discuss all the other items in this list. Please refer to the vRealize Orchestrator Cookbook for an extended discussion on resources, non-admin access to the Orchestrator, configurations, and policies.
Let's get started with some very basic things about workflows. We will see what a workflow consists of as well as how we can handle it.
A workflow is made up of different elements. We will now look into each of these elements one after another. But first, we have to navigate to a workflow and have a look at it:
- Start the Orchestrator Client, as shown at the beginning of the chapter.
-
Click on the Workflow icon,
.
- Now, you are in the workflow library. Expand the Library tree and then scroll down to vCenter.
- Expand vCenter and then select Virtual Machine management.
- Now, expand Basic and then click on the workflow Create simple virtual machine.
We will now go through all the properties of a workflow, as this is the central part of Orchestrator.
The General tab consists of two main areas. The upper area shows all the properties of the workflow such as its name, ID, and so on. The lower area is where its attributes are shown (see the following figure). We will first have a closer look at the upper area:
- Name: The upper area contains the name of the workflow. The name can be changed, but it has to be unique in a folder.
- ID: The next item is the workflow ID. The workflow ID is automatically generated by Orchestrator and cannot be changed. It is unique for all Orchestrator installations. The ID is the overall identifier of a workflow. If you want to start a workflow via REST you would, use its ID, not its name.
- Version: This shows the current version of the workflow and also presents you with a link to see all the previous versions of a workflow. We will look at workflow versioning later in more detail in Chapter 5, Combining and Modifying Workflows.
- Workflow icon: You can change the workflow icon of a workflow to any icon that has been imported into Orchestrator. There are some predefined ones.
- Owner: The one who created this workflow is the owner. You can click on Check signature (the SSL certificate) to check whether the owner of the workflow is the current Orchestrator. The signature is the SSL certificate that we created in Chapter 2, Deploying and Configuring the Orchestrator Appliance.
- User permissions: This attribute defines the permissions that a given user has for this workflow. These settings are defined when exporting a workflow to determine if and how a workflow can be reused. We will have a look at this in Chapter 9, Packing It All Up.
- Server restart behavior: This defines what should happen if the Orchestrator server becomes unavailable and then available again (basically, Orchestrator is powered off) while the workflow is running.
- Resume from failed behavior: This determines what should happen if a workflow fails. The System Default option stops the workflow. The alternative is to have the workflow resume enabled. This means that in case the workflow fails, the workflow will stop and ask the user for alternative inputs for its attributes and inputs.
- Description: This attribute allows an editor to leave more information about a workflow.
The lower section contains all the attributes of this workflow. An attribute is like a global variable that is defined for all elements of this workflow. We will have a closer look at them in Chapter 5, Combining and Modifying Workflows.
The Inputs tab shows all the input parameters that exist for this workflow. An input parameter is a variable that needs to be filled with a value when the workflow is started. Have a look at the first input parameter. It will ask for the name of the new VM. We will have a closer look at these parameters in Chapter 5, Combining and Modifying Workflows.
The Outputs tab shows all the output parameters of the workflow. These values are filled when the workflow is finished. The values can then be used by another workflow as the input parameters. The only output parameter of this workflow is the internal vSphere ID of the newly created VM. We will have a closer look at these parameters in Chapter 5, Combining and Modifying Workflows.
The Schema tab shows how the workflow is constructed. It shows all the separate elements that the workflow is made up of. Every workflow will consist of one Start element (the green arrow icon) and at one or more End elements (the grey shield icon). Between these two elements, you can see two other elements—a scripting element (the scroll icon) and an action element (the gear icon). On the upper right-hand side, you have an option to zoom in and out. We will have a closer look at this in Chapter 5, Combining and Modifying Workflows.
The Presentation tab is where you define how the input parameters are presented and formatted for the user. You can create pages and sections and sort the input parameters. You can also define a set of rules for each input parameter. We will work with the Presentation tab more in Chapter 7, Improving Workflows with Presentation. Have a look at the highlighted vmFolder input parameter in the following figure.
You will see that it has two properties, the first one being Mandatory input, which means that this input parameter must have a value, or else the workflow will not start:
The Parameters References view shows all the parameters of the workflow and its properties in an alphabetical order. For example, you can see that the vmDiskSize input parameter is of type number (it expects a number to be entered) and has multiple properties, such as Minimum number value of 0.004. This is an information page; you cannot change anything here.
We will work with presentation properties in Chapter 7, Improving Workflows with Presentation.
A workflow token is created when a workflow is started. As a workflow can be started multiple times at the same time, each execution of the workflow creates a unique workflow token. This is an information page that shows all the workflow tokens and their status. Each workflow token contains its status as well as its start and end time. Sometimes, it is more important to know which user actually started a workflow.
Now that we have discussed what the different elements of a workflow are, let's run a workflow.
There are multiple methods that can be used to start a workflow. You can use the play button (the green arrow) that is located at the top of the workflow (Marker A), or you can right-click on the workflow in the library and then select Start workflow (Marker B). If you would like to start the workflow as a different user and not the one that you are currently logged on as, right-click on the workflow and select Start workflow as (Marker C).
After starting the workflow, a window will appear, displaying the input parameters that have to be provided in order to execute it. We will now perform the following steps to execute this workflow:
- Enter the name of the new VM. This is a text field and can contain any ASCII code. However, if you are using any language specific characters such as ä, ö, and ü, you might get into trouble.
- The virtual machine's folder is a vCenter type, therefore it requires the ID of an existing vCenter object. To assign a vCenter Object, click on Not Set to open the vCenter inventory.
- A second window opens and lets you browse thought the vCenter inventory. Look for a folder called
VM. This is the top VM folder when no other VM folder exists. - Try out the following: browse through the inventory and click on an object. Have a look at the Select button. Only if you click on an object that is compatible with the type that the input needs can you click on the button. This helps a lot if you are not sure where the object is located or what it should be.
- The next three fields are number fields where you can only fill in numbers. The third field (vCPU) is also a number. However, using the presentation, it is a drop-down menu with only a preselected value. We will have a quick look at presentation in Chapter 7, Improving Workflows with Presentation.
- The Virtual machine guest OS again has a vCenter type, but in this case, not one where you select something from the inventory, but from a list of predefined values. Click on Not set, and a new window will open up.
- The window is empty when it opens, and this is a confusing thing for novices. Simply click into Filter and then press Enter. This will activate an empty filter that displays all options. You can also enter text, such as
64, to filter for specific options. This kind of window is pretty common in Orchestrator. - Select one of the options and then click on Select.
- You can now choose to make the VM disk thin provisioned. This is a Boolean type, and Orchestrator displays Yes or No. However, in JavaScript, Orchestrator uses the correct Boolean values,
trueandfalse. - After filling everything out, you will see that you can select Next. Have a look at the red * symbol before each text. It indicates that this parameter is a mandatory input.
- On the second page, you are asked for the host. However, there is no red * symbol. So, it's not a mandatory input. We will leave it alone.
- The ResourcePool again is a vCenter object. Click on Not Set and then select Resources under the cluster or host where you want to create the VM. The Resources resource pool is not a real pool, it represents the resources of the cluster or the host as such.
- The next item is a vCenter network object. Browse and find your correct network.
- The last input is the vCenter datastore where you want to store the VM.
- After you are finished, click on Submit to start the workflow.
By clicking on Submit, you have started the workflow. Orchestrator now switches to the workflow token (execution). You will see how it runs through each step and the variables fill up.
After the workflow completes its run, it can be in three states—successful (a green tick), failed (a red bullet with a white cross), or it will ask for more information (the person icon). The following figure shows all the executions with their respective start time next to them. Each of these executions is a workflow token, as shown in the Workflow Tokens section of the workflow's properties.
When you click on a workflow execution, you get additional information about the workflow's run. There are three sections—the General, the Variables, and the Logs tab.
The General tab shows the name of the workflow and its token ID, which is a unique ID inside Orchestrator. Also, the status and execution time are shown:
The Variables tab shows all the parameters (the in- and out-parameters and attributes), each with its type and the value it has when the workflow is finished. Some of the values have a grey i icon before it. If you hover the mouse on it, you will be shown additional information.
Underneath the parameters is a window titled Exception. If an error occurred during the workflow run, the error will be displayed here in red text.
The Logs tab shows the logs that the workflow created while it was running in the Orchestrator Client. We will have a look at creating logs in Chapter 8, Errors, Logs, and Debug Mode.
When an error occurs in the workflow run, most of the time you can fix the underlying problem and then you can rerun the workflow. Entering all the information again is a bit annoying.
There are two ways to do this, but basically, all result in the same thing. Right-click either on the workflow and select Start last workflow run or on the workflow execution (workflow token) and select Run again.
When you choose to rerun a workflow, the workflow input window will open and all the values, except for the passwords, will already be filled with the values that you had selected the last time you ran it.
The difference between the two methods is that the first method, by using the workflow, will result in rerunning the last execution of the workflow, whereas in the second, you can select the execution of the workflow that you are rerunning.