This chapter is dedicated to working with vSphere—or, to put it bluntly, the vCenter itself. We will be looking at the following recipes:
- Working with the vCenter API (to change a VM's HA settings)
- Standard vSwitch and Distributed Switch ports
- Getting started with vAPI
- Custom Attributes and Tags (vAPI)
- Executing a program inside a VM
- An approval process for VM provisioning
Here we will have a look into the vSphere plugin and what we can do with it.
The interaction between Orchestrator and vCenter is done using the vCenter API. Let's have a closer look at the interaction, and how it works, in more detail.
A user starts an Orchestrator workflow (1) either in an interactive way through the vSphere Web Client or the Orchestrator Client, or through the API. The workflow in Orchestrator will then send a job (2) to vCenter and receive a task ID back (type VC:Task). vCenter will then start enacting the job (3). Using the vim3WaitTaskEnd action (4), Orchestrator pauses until the task has been completed. If we do not use the wait task, we can't be certain whether the task has ended, was successful, or has failed. It is extremely important to use the vim3WaitTaskEnd action whenever we send a job to vCenter. When the wait task reports that the job has finished, the workflow will be marked as finished, as shown in the following diagram:
The Managed Object Reference (MoRef) is a unique ID inside vCenter for every object. MoRefs are basically strings. The following table shows some examples of different MoRefs:
|
VM |
Network |
Datastore |
ESXi host |
Data center |
Cluster |
|
vm-301 |
network-312
dvportgroup-242
|
datastore-101 |
host-44 |
datacenter-21 |
domain-c41 |
The MoRefs are typically stored in the attribute .id or .key of the Orchestrator API object. For example, the MoRef of a vSwitch network is VC:Network.id. We will make use of them in the Standard vSwitch and Distributed Switch Ports recipe of this chapter.
The MoRefs that are defined in vCenter are shown as ID in Orchestrator. This can either be in the Orchestrator inventory or as an attribute of an API class such as VM.id. To browse for MoRefs, you can use the Managed Object Browser (MOB), documented at
http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.wssdk.pg.doc/PG_Appx_Using_MOB.20.1.html
, or the Orchestrator inventory and looking for the field ID.
As previously mentioned, vim3WaitTaskEnd is one of the most central actions while interacting with vCenter. The action has the following variables:
|
Category |
Name |
Type |
Usage |
|
IN |
|
VC:Task |
This will carry the reconfiguration task from the script to the wait task. |
|
IN |
|
Boolean |
Write the progress of a task to the logs as a percentage. |
|
IN |
|
Number |
How often the action should be checked for task completion in vCenter. |
|
OUT |
|
Any |
Returns the task's result. |
The waiting task will check (pollRate) the status of a task that has been submitted to vCenter at regular intervals. The task can have the following states:
|
State |
Meaning |
|
Queued |
The task is queued and will be executed as soon as possible. |
|
Running |
The task is currently running. If the progress is set to |
|
Success |
The task has finished successfully. |
|
Error |
The task has failed and an error will be thrown. |
The function behind this is the scripting class Task based on type VC:Task, which has quite a lot of functions:
There are actually five waiting tasks that come with the vCenter server plugin. The following table gives an overview of the other four:
|
Task |
Description |
|
|
This task waits until the VMware tools are started on a VM or until a timeout is reached. |
|
|
This task waits until the VMware tools report the primary IP of a VM or until a timeout is reached. This typically indicates that the operating system is ready to receive network traffic. The action will return the primary IP. |
|
|
This task waits until the VMware tools report a given DNS name of a VM or until a timeout is reached. The in-parameter |
|
|
This task waits until a task is finished or a VM develops a question. A vCenter question is related to user interactions. |
With the release of vSphere 6, a few new features have been added for Orchestrator to consume.
From vSphere 6, the vAPI is a new way to automate vCenter. Have a look at the Getting started with vAPI and Custom Attributes and Tags (vAPI) recipes in this chapter for more details.
Linked Cloning allows you to create new VMs quickly and with minimal storage use. All the workflows you could ask for exist and I would highly recommend giving it a try, especially as this vCenter function is only available (at this stage) through the API. This feature has been available since vCO 5.5:
Several new workflows for vSAN have been added since vRO 6.
The workflow Library | vCenter | Host management | Basic | Enter Maintenance mode has a vSAN option.
There is also the new workflow Library | vCenter | Networking | VSAN, which allows for VSAN network settings.
In Library | vCenter | VSAN you will find a new workflow to manage day-to-day operations.