Connector for vRO
This section of the documentation contains technical information on the vFire Core connector to vRO (VMware vRealize Orchestrator), previously known as VMware vCenter Orchestrator (VCO. It describes the details of the connector including:
- The name of the .NET assembly file
- The connection methodology
- The resource and link types that can be discovered
- The actions that can be called under workflow control
For compatibility and version support details, refer to the Fire Connector Matrix.
You should familiarize yourself with the information in Installing Connectors before installing any connectors, and read the Integration topics for more information on how to configure them.
Connector Functionality and Management Processes
The vFire Core connector for vRO operation takes place and improves two main domains of actual IT environments; Data Federation and Data Center Control & Automation.
To achieve this improvement, the connector leverages on two vFire Core features:
- vFire Core Federated CMDB allows proper population of the vFire Core CMDB with external resources and their relationships as seen by vRO.
- vFire Core Outbound action that makes it possible for vFire Core to trigger vRO specific workflow. Once triggered, these workflows are then run by vRO.
Several management processes benefit from the enhancements offered by the connector. Amongst all of these processes, three examples are detailed later in this document:
- Incident Management improves classification, reporting, and routing.
- In Data Center Automation & Control , the Outbound actions function allows vFire Core to trigger actions into third-party applications while making sure that the required and appropriate information is transferred so that third-party actions can run smoothly.
- Release and Deployment Management automates deployment and ensures proper CMDB maintenance.
- Change Management enforces a control/approval dimension into RFC management process.
Licensing
The connector for vRO is not separately licensed and is available to any organization that is licensed for vFire Core.
Related Documentation
vFire Core Integration platform administration and configuration concepts and details are presented in the Integration documentation.
Connector Details
Information fields |
Description |
---|---|
Connector |
vRO <-> vFire Core |
vFire Core database version |
SQL (See the Prerequisites for details) |
Third-party application |
vRO |
vRO supported DB |
Any DB format as detailed in https://www.vmware.com/resources/compatibility/sim/interop_matrix.php |
Assembly |
Infra.Connector.vCO.connector |
Connector class |
vCO Connector |
Configuration file |
Infra.Connector.vCO-VC.xml |
Connection methodology |
Web Services |
Installing the vRO Connector
The steps below detail how to install the connector.
- Download the connector zip package, save it in a temporary directory then unzip it.
- Prepare the vFire Core Server, as described below.
- Create or configure a connection source, as described in Creating a Connection Source.
The unzipped folder should contain 2 sub-folders: bin and config.
Preparing the vFire Core Server
- Copy the contents of the bin and config directories to the following locations on the vFire Core server:
- In the vFire Core Server Console, execute the SQL script Infra.Connector.vCO.Install.scp against the target system.
- Restart the following Windows services:
- The World Wide Web Publishing Service
- The vFire Core Connector Service
File/Folder Name |
Target Location(s) |
---|---|
bin / Infra.Connector.vCO.dll |
<vFire Core Root> <Target System>/bin |
config / vco-plugin-sets/ |
<Target System>/config/vco-plugin-sets/ |
config / Infra.Connector.vCO.Install.scp |
<Target System>/config |
This example illustrates the folder structure once the vRO connector installation is completed (vFire Core system is PDMV9CONNECTORS).
Configure the Request Details screen in Designer to pass values as part of the integration. Add a custom 'Single Value QD field'. Give the new custom field a display to reflect the type of CMDB item you want to pass; and select the QD type as 'Configuration Item'. Create as many other custom fields as you require to pass.
Creating a Connection Source
When creating a new vRO source from the Source option of the Integration Platform, some specific parameters have to be entered as follows:
Parameter |
Description |
Host Name / IP Address |
Specify the vRO server e.g. “vco1.mydomain.com”, “192.168.0.14” |
Port No |
Specify the port used by vRO. The default for vRO is 8280. For SSL operation, specify the port number configured for the vRO web service, eg. 8281. Integrating with vCO 5.1 onwards and vRO requires SSL to be enabled and the port to be configured to 8281. |
Login ID / Password |
Credentials of a user with access to run workflows within vRO. If this is a domain user, the login ID must be qualified by the relevant domain e.g. “mydomain\mylogin1”. |
Plug-In Set |
Select from the drop down list of all the vRO plug-in sets installed on the vFire Core server. The plug-ins that constitute the selected set must also be installed on the vRO server for the integration to run successfully. |
Example of vRO source details screen:
Installing vRO Plug-ins onto the vFire Core Server
Alemba provides various plug-ins for the vRO. These plug-ins allow connection between the vRO and third party tools and applications. vRO plug-ins usually come with a .vmoapp file extension and need to be installed on the vFire Core server.
Once downloaded and copied onto a temporary folder of the vFire Core server, follow these steps to install the plug-in:
- Rename .vmoapp into .zip.
- Unzip it.
- Open the unzipped folder and find the .dar file.
- Change extension .dar into .zip.
- Unzip this file.
- Once unzipped, the unzipped folder is named o11nplugin-ad (for the MS Active Directory plug-in). Change the folder name to ad .dar at the end, i.e. rename to o11nplugin-ad.dar.
- Copy the o11nplugin-ad.dar folder into a new Custom X folder under <vFire Core Root>/<Target System>/Config, X being the targeted vCO/vRO version.
- In the vRO source detail screen of the vFire Core integration platform, use the drop-down list to select Custom X instead of Default X.
- Restart World Wide Web Publishing Service and vFire Core Connector Service.
Data Federation
Data Federation is concerned in reaching the highest consistency for physical and virtual data throughout entire operational ecosystems. This implies sub-processes like data collection, data feeding/transfer, and data maintenance, to mention only a few.
vFire Core positions itself in the Data Federation process by providing a CMDB that can be populated and updated in accordance with the environment. This CMDB then acts as a basis for numerous IT Management processes.
vFire Core CMDB Population Function
Ensuring physical and virtual environments are properly represented in a CMDB is paramount. The vFire Core CMDB possesses extended functionalities that allow proper maintenance and management. However, it needs to be populated and regularly updated so that it closely matches with the environments it is meant to reflect. The CMDB population and updating tasks are handled by the Federated CMDB and Integration Platform functionality of vFire Core.
Basically, mappings can be implemented between resource and link types of external resources as seen by vRO and vFire Core CMDB items. These mappings are the basis of an initial CMDB population. Following this initial population, and in conjunction with the scheduling functions of the Integration Platform, they then allow for regular updates of the data stored in the CMDB, thus improving the overall environment management.
The following section details the resource types handled by the connector for vRO.
Connector Resource Types
For purpose of usability, the vRO connector only exposes a sub-set of all the resource types managed by any vRO default installations. This filtering has been implemented so users can focus on the most common and representative vRO resource types without having to experience the profusion of resource types.
Conversely, when installing a new vRO plug-in (for VMware vCloud Director for instance), all the resource types managed by this plug-in would be visible from the vFire Core Integration Platform.
The types that are available for import in the vFire Core CMDB are listed in the table below.
To take advantage of Post Provision Actions, you must map CIs to the VC: Virtual Machine.
Resource Type Name |
SSH: RootFinder |
SSH: SshConnection |
SSH: RootFolder |
SSH: Folder |
SSH: File |
VC: VMware Distributed Virtual Switch |
VC: Virtual Machine Snapshot |
VC: Virtual Machine |
VC: Virtual App |
VC: Resource Pool |
VC: Network |
VC: Host System |
VC: Distributed Virtual Switch |
VC: Distributed Virtual Portgroup |
VC: Datacenter |
VC: Datastore |
VC: Compute Resource |
VC: Cluster Compute Resource |
Examples of Improved Management Process
Incident Management
Incident Management, encompassing incident classification, reporting, and routing, can be greatly improved by populating and maintaining an updated vFire Core CMDB. Population should be based on the items that require some sort of monitoring and/or against which Incidents are likely to be logged. In a virtual environment, it could be VMs, vApps. Networks, vDC, etc.
You should:
- Create a specific CMDB Item Type for each resource type you plan to import and design a screen for it.
- Create a specific CI template for each resource type by creating a configuration item and selecting Template in the Configuration Item details.
- Set up resource mapping in the Integration Platform to map each vRO resource type and attribute onto vFire Core specific configuration items. The key fields to consider vary from one resource type to the other.
The resource types and recommendations are specific to the vRO connector. However, maintaining your CMDB also implies scheduling regular scans and monitoring the changes that are implemented to the CMDB. These general aspects of vFire Core are detailed in the Integration Platform Configuration Guide.
Data Center Automation & Control
Data Center automation and Control looks at reducing the numbers of steps that require human intervention when implementing changes. These changes can be related to improving the environment by upgrading existing systems or creating new ones, but can also refer to actions taken to fix some issues or enforce configuration compliance.
vFire Core has specific functionality to assist in the field of Data Center automation and Control, namely the Outbound actions function. Basically, it allows vFire Core to trigger actions into third-party applications while making sure that the required and appropriate information is transferred so that third-party actions can run smoothly.
vFire Core Outbound Action Function
vFire Core Outbound action implementation mainly relies on the actions that are available for triggering into third party system. The list of these actions is defined by the connector.
From a user standpoint, vFire Core Outbound action breaks into 2 main parts:
- Mappings that establish relationships between available vFire Core fields and the data required for the third-party action to be run without issue.
- Configuration and settings that act as triggers for the outbound actions: either via a vFire Core workflow using an Outbound action workflow task, or via proper transfer of Service Desk calls.
Once an outbound action has been triggered, a dedicated communication protocol is established between vFire Core and the third party application so that some sort of monitoring is available inside vFire Core about the running of the third party action.
For detailed information on vFire Core Outbound action function, see Using Outbound Actions.
Connector Outbound Action Types
This connector enables vFire Core to harness the extensive Data Center Automation capabilities of vRO.
Each outbound action type published by this connector corresponds to a particular workflow defined within a vRO server. As such the set of outbound action types will vary depending on the installation and configuration within vRO.
When a new outbound action is created from one of these types (e.g. from an outbound action task in a workflow), a new instance of the corresponding workflow is created on the vRO server. The outbound action will remain open during the vRO workflow instance. The outbound action will terminate with a status of “Complete” or “Not Complete” depending on whether the vRO workflow terminates with a status of success or error.
Some of the actions performed as steps within the vRO workflow are performed asynchronously. As such, it is sometimes possible for a vRO workflow to terminate successfully while the operations it started are still in progress. The status of the corresponding outbound action in vFire Core will reflect that the workflow itself has finished; it will not reflect whether the underlying steps have finished or not. If this is a concern, it is recommended that users use outbound action types that correspond to vRO workflows that have been specifically designed to wait for these steps to complete.
vFire Core outbound action workflow task will reflect the status of the vRO workflow as a whole, and not of any specific “actions” contained in the vRO workflow.
For a complete list of available outbound action types available through an out-of-the-box install of vRO without additional plug-ins, click here. Each outbound action requires its own specific set of input data that can be identified using the vRO console.
Release and Deployment Management
Amongst all the available actions, several can be used in relation to Release and Deployment Management, such as Cloning Virtual Machine and can be triggered inside a vFire Core workflow. Ideally, this workflow also incorporates a CMDB update workflow task so that the CMDB is constantly aligned and synchronized with the virtual architecture as seen by vRO.
An up to date vFire Core CMDB is prerequisite to proper Provisioning Management. This can be achieved by:
- An initial scan of the virtual environment followed by incremental and regular scans.
- Proper matching rules implemented in any relevant mappings so that no duplicate CMDB items are created as a result of running regular scans.
Refer to the Integration platform Configuration Guide for details about vFire Core CMDB maintenance.
The outbound action task (such as Cloning VM) transfers the required parameters to vRO so that it can run its own internal workflow. These parameters are set up using the mapping field of the outbound action task, allowing the association of vFire Core related fields with vRO workflow input fields.
Workflow Template Configuration
As explained already, the outbound action task needs to pass specific parameters to the vRO, in this case the name of the VM that will be cloned and the name of the new VM.
This is achieved by adding the targeted VM as Linked CI in the request screen (see below). Specifying the VM can be done at the workflow template level or when creating a new request if the template does not specify any linked CIs. The later solution provides better flexibility and reusability.
Due to vRO workflow characteristics, it is not possible to specify several CIs in the Linked CIs request field.
Outbound Action Task Configuration
The configuration is to ensure the information about the VM to clone is properly passed to the vRO workflow. This is achieved by the mapping illustrated below in the outbound action task details screen.
Manage CMDB Task Configuration
Once the outbound action workflow task completed, the vFire Core CMDB needs to be updated to reflect this change. This is achieved by setting up a Manage CMDB workflow task that will create an appropriate CMDB item representing the VM that has just been created.
Matching Considerations
When creating a CMDB item using the Manage CMDB workflow task, ensure that future scans will not create a new CMDB item, but will link the newly discovered VM with the CMDB item that has been created by the Manage CMDB workflow task. This is achieved by setting up adequate Matching rules for the mapping related to the VM resource type:
Change Management
vFire Core allows you to enforce the validation of an RFC whenever a user attempts to roll out changes using vRO. This is achieved by the user creating a vFire Core workflow that contains an approval capability upstream to an outbound action task so that the latest, and its associate vRO workflow, is not implemented without appropriate control.
In vFire Core, Change management is mainly managed through flexible and configurable approval functionality already built in to the vFire Core workflow module. This functionality helps to monitor RFC and ensure only the approved ones are implemented.
Practically, it means including some approvals tasks upstream to the Outbound action task in the workflow. This approval step would allow for the Change administrator to validate that the RFC is in accordance with what have been previously agreed and/or, more importantly, to perform an Impact analysis using the vFire Core CMDB Linking Diagram (see recommendations below).
Resources and Links
In order to perform an Impact analysis, users would have to properly populate the vFire Core CMDB. Such population is achieved by regular scans to update the CMDB but also by setting up the proper mapping for the resource types and the proper relationships between these resource types, as well as adequate Matching Rules.
Link configuration
For purpose of usability, the vRO connector only exposes a sub-set of all the vRO links managed by any vRO default installations. This filtering has been implemented so users can focus on the most common and representative vRO links without having to experience the profusion of items.
Conversely, when installing a new vRO plug-in (for VMware vCloud Director for instance), all the vRO links managed by this plug-in would be visible from the vFire Core Integration Platform.
Click here for a complete list of the different links for the vRO connector.
Link configuration for the vRO integration is quite straightforward and regular vFire Core parent-child link type can be used to represent the relationships between entities.
Once the CMDB items and links are imported and maintained, performing an impact analysis is easily achieved by using the vFire Core CMDB linking diagram options, an example of which is illustrated below.
Outbound action configuration
Outbound action configuration is similar to Release and Deployment Management use case.
Conclusion
The use cases provided are closely related one to another. For instance, Release and Deployment Management scenario strongly relies on a proper CMDB population, which is the core of the Incident Management scenario. Similarly, the Change Management workflow can easily be seen as an early step in the Release and Deployment Management use case as implementation control via approvals is seen as best practice when it comes to modifying physical or virtual infrastructures.
From a broader standpoint, these use cases can also be part of the several other management processes that can benefit from the vFire Core CDMB and Outbound action functionalities.
Resource Type Details
SSH: RootFinder
Fields
(None)
SSH: SshConnection
Field Name |
Type |
---|---|
Host name |
string |
User name |
string |
SSH: RootFolder
Folder Name |
string |
SSH: Folder
Folder name |
string |
---|---|
Folder name |
string |
Path |
string |
Folder name |
string |
SSH: File
Folder name |
string |
---|---|
File name |
string |
Path |
string |
Folder name |
string |
VC: VMware Distributed Virtual Switch
The interface to the implementation of the switch. The functionality listed here is for VMware DistributedVirtualSwitch only.
Field name |
Type |
---|---|
description |
string |
id |
string |
Name |
string |
SDK Connection |
string |
VC: Virtual Machine Snapshot
The Snapshot managed object type specifies the interface to individual snapshots of a virtual machine. Although these are managed objects, they are subordinate to their virtual machine.
Field Name |
Type |
---|---|
id |
string |
Name |
string |
SDK Connection |
string |
VirtualMachine name |
string |
VC: Virtual Machine
VirtualMachine is the managed object type for manipulating virtual machines, including templates that can be deployed (repeatedly) as new virtual machines. This type provides methods for configuring and controlling a virtual machine.
VirtualMachine extends the ManagedEntity type because virtual machines are part of a virtual infrastructure inventory. The parent of a virtual machine must be a folder, and a virtual machine has no children.
Destroying a virtual machine disposes of all associated storage, including the virtual disks. To remove a virtual machine while retaining its virtual disk storage, a client must remove the virtual disks from the virtual machine before destroying it.
Field name | Type |
---|---|
connectionState |
pick-list, see VC: VirtualMachineConnectionState |
id |
string |
isTemplate |
string |
Name |
string |
state |
pick-list, see VC: VirtualMachinePowerState |
SDK Connection |
string |
VC: Virtual App
Represents a multi-tiered software solution. A vApp is a collection of virtual machines (and potentially other vApp containers) that are operated and monitored as a unit. From a manage perspective, a multi-tiered vApp acts a lot like a virtual machine object. It has power operations, networks, datastores, and its resource usage can be configured.
From a technical perspective, a vApp container is a specialized resource pool that has been extended with the following capabilities:
- Product information such as product name, vendor, properties, and licenses.
- A power-on/power-off sequence specification
- Support for import/export vApps as OVF packages
- An OVF environment that allows for application-level customization
Destroying a vApp
When a vApp is destroyed, all of its virtual machines are destroyed, as well as any child vApps.
The VApp.Delete privilege must be held on the vApp as well as the parent folder of the vApp. Also, the VApp.Delete privilege must be held on any child vApps that would be destroyed by the operation.
Field name |
Type |
---|---|
CPU reservation |
string |
id |
string |
Memory reservation |
string |
Name |
string |
SDK Connection |
string |
VC: Resource Pool
Represents a set of physical resources: a single host, a subset of a host's resources, or resources spanning multiple hosts. Resource pools can be subdivided by creating child resource pools. In order to run, a virtual machine must be associated as a child of a resource pool.
In a parent/child hierarchy of resource pools and virtual machines, the single resource pool that has no parent pool is known as the root resource pool.
A resource pool is configured with a set of CPU (in MHz) and memory (in MB) resources. These resources are specified in absolute terms with a resource reservation and a resource limit, along with a shares setting. The shares are used during resource contention, to ensure graceful degradation.
For the root resource pool, the values of the reservation and the limit are set by the system and are not configurable. The reservation and limit are set to the same value, indicating the total amount of resources the system has available to run virtual machines. This is computed as the aggregated CPU and memory resources provided by the set of current available hosts in the parent compute resource minus the overhead of the virtualization layer.
Since the resource pool configuration is absolute (in MHz or MB), the configuration can become invalid when resources are removed. This can happen if a host is removed from the cluster, if a host becomes unavailable, or if a host is placed in maintenance mode. When this happens, the system flags misconfigured resource pools and displays the reservations and limits that are in effect. Further, in a DRS enabled cluster, the tree can be misconfigured if the user bypasses VirtualCenter and powers on VMs directly on the host.
Resource Pool States and Admission Control
There are three states that the resource pool tree can be in: undercommited (green), overcommited (yellow), and inconsistent (red). Depending on the state, different resource pool configuration policies are enforced. The states are described in more detail below:
State | Resource Pool Configuration Policy |
---|---|
GREEN (aka undercommitted) | We have a tree that is in a good state. Every node has a reservation greater than the sum of the reservations for its children. We have enough capacity at the root to satisfy all the resources reserved by the children. All operations performed on the tree, such as powering on virtual machines, creating new resource pools, or reconfiguring resource settings, will ensure that the above constraints are maintained. |
RED (aka. inconsistent) |
In this state, the DRS algorithm is disabled until the resource pool tree's configuration has been brought back into a consistent state. We also restrict the resources that such invalid nodes request from their parents to the configured reservation/limit, in an attempt to isolate the problem to a small subtree. For the rest of the tree, we determine whether the cluster is undercommitted or overcommitted according to the existing rules and perform admission control accordingly. Since all changes to the resource settings are validated on the VirtualCenter server, the system cannot be brought into this state by simply manipulating a cluster resource pool tree through VirtualCenter. It can only happen if a virtual machine gets powered on directly on a host that is part of a DRS cluster. |
YELLOW (aka overcommitted) | In this state, the tree is consistent internally, but the root resource pool does not have the capacity at to meet the reservation of its children. We can only go from GREEN -> YELLOW if we lose resources at the root. For example, hosts becomes unavailable or is put into maintenance mode. We will always have enough capacity at the root to run all currently powered on VMs. However, we may not be able to satisfy all resource pool reservations in the tree. In this state, the reservation configured for a resource pool is no longer guaranteed, but the limits are still enforced. This provides additional flexibility for bringing the tree back into a consistent state, without risking bringing the tree into a RED state. In more detail:
|
Destroying a ResourcePool
When a ResourcePool is destroyed, all the virtual machines are reassigned to its parent pool. The root resource pool cannot be destroyed, and invoking destroy on it will throw an InvalidType fault.
Any vApps in the ResourcePool will be moved to the ResourcePool's parent before the pool is destroyed.
The Resource.DeletePool privilege must be held on the pool as well as the parent of the resource pool. Also, the Resource.AssignVMToPool privilege must be held on the resource pool's parent pool and any virtual machines that are reassigned.
Field name |
Type |
---|---|
CPU reservation |
string |
id |
string |
Memory reservation |
string |
Name |
string |
SDK Connection |
string |
VC: Network
Represents a network accessible by either hosts or virtual machines. This can be a physical network or a logical network, such as a VLAN.
Networks are created:
- explicitly when configuring a host.
- automatically when adding a host to VirtualCenter.
- automatically when adding a new virtual machine to a host or to VirtualCenter.
Field name |
Type |
---|---|
accessible |
string |
id |
string |
Name |
string |
SDK Connection |
string |
VC: Host System
The HostSystem managed object type provides access to a virtualization host platform.
Invoking destroy on a HostSystem of standalone type throws a NotSupported fault. A standalone HostSystem can be destroyed only by invoking destroy on its parent ComputeResource. Invoking destroy on a failover host throws a DisallowedOperationOnFailoverHost fault.
Field name | Type |
---|---|
id |
string |
Name |
string |
state |
pick-list, see VC: HostSystemConnectionState |
version |
string |
SDK Connection |
string |
VC: Distributed Virtual Switch
The interface to the distributed virtual switch objects.
Field name |
Type |
---|---|
description |
string |
id |
string |
Name |
string |
SDK Connection |
string |
VC: Distributed Virtual Portgroup
The interface to the distributed virtual portgroup objects. This type represents both a group of ports that share the common network setting and a Network entity in the datacenter.
Field name |
Type |
---|---|
accessible |
string |
id |
string |
Name |
string |
SDK Connection |
string |
VC: Datastore
Represents a storage location for virtual machine files. A storage location can be a VMFS volume, a directory on Network Attached Storage, or a local file system path.
A datastore is platform-independent and host-independent. Therefore, datastores do not change when the virtual machines they contain are moved between hosts. The scope of a datastore is a datacenter; the datastore is uniquely named within the datacenter.
Any reference to a virtual machine or file accessed by any host within the datacenter must use a datastore path. A datastore path has the form "[<datastore>] <path>", where <datastore> is the datastore name, and <path> is a slash-delimited path from the root of the datastore. An example datastore path is "[storage] path/to/config.vmx".
You may use the following characters in a path, but not in a datastore name: slash (/), backslash (\), and percent (%).
All references to files in the VIM API are implicitly done using datastore paths.
When a client creates a virtual machine, it may specify the name of the datastore, omitting the path; the system, meaning VirtualCenter or the host, automatically assigns filenames and creates directories on the given datastore. For example, specifying My_Datastore as a location for a virtual machine called MyVm results in a datastore location of My_Datastore\MyVm\MyVm.vmx.
Datastores are configured per host. As part of host configuration, a HostSystem can be configured to mount a set of network drives. Multiple hosts may be configured to point to the same storage location. There exists only one Datastore object per Datacenter, for each such shared location. Each Datastore object keeps a reference to the set of hosts that have mounted the datastore. A Datastore object can be removed only if no hosts currently have the datastore mounted.
Thus, managing datastores is done both at the host level and the datacenter level. Each host is configured explicitly with the set of datastores it can access. At the datacenter, a view of the datastores across the datacenter is shown.
Field name | Type |
---|---|
accessible |
string |
capacity (GB) |
string |
freeSpace (GB) |
string |
id |
string |
Name |
string |
url |
string |
SDK Connection |
string |
VC: Datacenter
The Datacenter managed object provides the interface to the common container object for hosts, virtual machines, networks, and datastores. These entities must be under a distinct datacenter in the inventory, and datacenters may not be nested under other datacenters.
Every Datacenter has the following set of dedicated folders, which are empty until you create entities for the Datacenter.
- A folder for VirtualMachine, template, and VirtualApp objects
- A folder for a ComputeResource hierarchy
- A folder for Network, DistributedVirtualSwitch, and DistributedVirtualPortgroup objects
- A folder for Datastore objects
For a visual representation of the organization of objects in a vCenter hierarchy, see the description of the ServiceInstance object.
Field name |
Type |
---|---|
id |
string |
Name |
string |
SDK Connection |
string |
VC: Compute Resource
Represents a set of physical compute resources for a set of virtual machines.
The base type ComputeResource, when instantiated by calling AddStandaloneHost_Task, represents a single host. The subclass ClusterComputeResource represents a cluster of hosts and adds distributed management features such as availability and resource scheduling.
A ComputeResource always has a root ResourcePool associated with it. Certain types of clusters such as those with VMware DRS enabled and standalone hosts (ESX Server 3) support the creation of ResourcePool hierarchies.
Field name |
Type |
---|---|
id |
string |
Name |
string |
SDK Connection |
string |
VC: Cluster Compute Resource
The ClusterComputeResource data object aggregates the compute resources of associated HostSystem objects into a single compute resource for use by virtual machines. The cluster services such as HA (High Availability), DRS (Distributed Resource Scheduling), and EVC (Enhanced vMotion Compatibility), enhance the utility of this single compute resource.
Use the Folder.CreateClusterEx method to create an instance of this object.
Field name |
Type |
---|---|
id |
string |
Name |
string |
SDK Connection |
string |
Link Type Details
Link type name |
Resource A |
Resource B |
---|---|---|
SSH: Folder->Files |
SSH: Folder |
SSH: File |
SSH: Folder->Folders |
SSH: Folder |
SSH: Folder |
SSH: RootFinder->SshConnections | SSH: RootFinder | SSH: SshConnection |
SSH: RootFolder->Files | SSH: RootFolder | SSH: File |
SSH: RootFolder->Folders | SSH: RootFolder | SSH: Folder |
SSH: SshConnection->RootFolders | SSH: SshConnection | SSH: RootFolder |
VC: ClusterComputeResource->(Network) DistributedVirtualPortgroup | VC: Cluster Compute Resource | VC: Distributed Virtual Portgroup |
VC: ClusterComputeResource->(Network) Network | VC: Cluster Compute Resource | VC: Network |
VC: ClusterComputeResource->(ResourcePool) ResourcePool | VC: Cluster Compute Resource | VC: Resource Pool |
VC: ClusterComputeResource->(ResourcePool) VirtualApp | VC: Cluster Compute Resource | VC: Virtual App |
VC: ClusterComputeResource->Datastore | VC: Cluster Compute Resource | VC: Datastore |
VC: ClusterComputeResource->Host | VC: Cluster Compute Resource | VC: Host System |
VC: ClusterComputeResource->Network | VC: Cluster Compute Resource | VC: Network |
VC: ClusterComputeResource->ResourcePool | VC: Cluster Compute Resource | VC: Resource Pool |
VC: ComputeResource->(Network) DistributedVirtualPortgroup | VC: Compute Resource | VC: Distributed Virtual Portgroup |
VC: ComputeResource->(Network) Network | VC: Compute Resource | VC: Network |
VC: ComputeResource->(ResourcePool) ResourcePool | VC: Compute Resource | VC: Resource Pool |
VC: ComputeResource->(ResourcePool) VirtualApp | VC: Compute Resource | VC: Virtual App |
VC: ComputeResource->Datastore | VC: Compute Resource | VC: Datastore |
VC: ComputeResource->Host | VC: Compute Resource | VC: Host System |
VC: ComputeResource->Network | VC: Compute Resource | VC: Network |
VC: ComputeResource->ResourcePool | VC: Compute Resource | VC: Resource Pool |
VC: Datacenter->Datastore | VC: Datacenter | VC: Datastore |
VC: Datacenter->Network | VC: Datacenter | VC: Network |
VC: Datastore->Vm | VC: Datastore | VC: Virtual Machine |
VC: DistributedVirtualPortgroup->Host | VC: Distributed Virtual Portgroup | VC: Host System |
VC: DistributedVirtualPortgroup->Vm | VC: Distributed Virtual Portgroup | VC: Virtual Machine |
VC: DistributedVirtualSwitch->Portgroup | VC: Distributed Virtual Switch | VC: Distributed Virtual Portgroup |
VC: HostSystem->(Network) DistributedVirtualPortgroup | VC: Host System | VC: Distributed Virtual Portgroup |
VC: HostSystem->(Network) Network | VC: Host System | VC: Network |
VC: HostSystem->(ResourcePool) ResourcePool | VC: Host System | VC: Resource Pool |
VC: HostSystem->(ResourcePool) VirtualApp | VC: Host System | VC: Virtual App |
VC: HostSystem->Datastore | VC: Host System | VC: Datastore |
VC: HostSystem->Network | VC: Host System | VC: Network |
VC: HostSystem->Vm | VC: Host System |
VC: Virtual Machine |
VC: Network->Host | VC: Network | VC: Host System |
VC: Network->Vm | VC: Network | VC: Virtual Machine |
VC: ResourcePool->(Network) DistributedVirtualPortgroup | VC: Resource Pool | VC: Distributed Virtual Portgroup |
VC: ResourcePool->(Network) Network | VC: Resource Pool | VC: Network |
VC: ResourcePool->(ResourcePool) ResourcePool | VC: Resource Pool | VC: Resource Pool |
VC: ResourcePool->(ResourcePool) VirtualApp | VC: Resource Pool | VC: Virtual App |
VC: ResourcePool->Owner | VC: Resource Pool | VC: Compute Resource |
VC: ResourcePool->ResourcePool | VC: Resource Pool | VC: Resource Pool |
VC: ResourcePool->Vm | VC: Resource Pool | VC: Virtual Machine |
VC: VirtualApp->(ResourcePool) ResourcePool | VC: Virtual App | VC: Resource Pool |
VC: VirtualApp->(ResourcePool) VirtualApp | VC: Virtual App | VC: Virtual App |
VC: VirtualApp->Datastore | VC: Virtual App | VC: Datastore |
VC: VirtualApp->Network | VC: Virtual App | VC: Network |
VC: VirtualApp->Owner | VC: Virtual App | VC: Compute Resource |
VC: VirtualApp->ResourcePool | VC: Virtual App | VC: Resource Pool |
VC: VirtualApp->Vm | VC: Virtual App | VC: Virtual Machine |
VC: VirtualMachine->Datastore | VC: Virtual Machine | VC: Datastore |
VC: VirtualMachine->Network | VC: Virtual Machine | VC: Network |
VC: VirtualMachine->ResourcePool | VC: Virtual Machine | VC: Resource Pool |
VC: VirtualMachine->RootSnapshot | VC: Virtual Machine | VC: Virtual Machine Snapshot |
VC: VirtualMachine->VmSnapshot | VC: Virtual Machine | VC: Virtual Machine Snapshot |
VC: VirtualMachineSnapshot->ChildSnapshot | VC: Virtual Machine Snapshot | VC: Virtual Machine Snapshot |
VC: VmwareDistributedVirtualSwitch->Portgroup | VC: VMware Distributed Virtual Switch | VC: Distributed Virtual Portgroup |
Available Outbound Action Types
Here is a complete list of available outbound action types available through an out-of-the-box install of vRO without additional plug-ins.
Action Type | Action |
---|---|
Add CD-ROM |
Adds a virtual CD-ROM to a virtual machine. If the virtual machine has no IDE controller, the workflow creates one. |
Add custom attribute to a virtual machine |
Adds a custom attribute for a virtual machine in vRealize Server |
Add custom attribute to multiple virtual machines | Adds a custom attribute to multiple virtual machines in vRealize Server |
Add disk | Adds a virtual disk to a virtual machine. |
Add host to cluster | Adds a host to the cluster. If the cluster supports nested resource pools and the user specifies the optional ResourcePool argument, then the host's root resource pool becomes the specified resource pool. The stand-alone host resource hierarchy is imported into the new nested resource pool. If the cluster does not support nested resource pools, then the standalone host resource hierarchy is discarded and all virtual machines on the host are put under the cluster's root resource pool. This workflow will fail if it cannot authenticate the SSL certificate of the host system. |
Add standalone host | Registers an ESX host as a standalone host, namely, as a ComputeResource. |
Append address book stylesheet information | Appends stylesheet information for the address book example. |
Change key pair passphrase | Changes a key pair pass-phrase |
Change RAM | Changes the amount of RAM of a virtual machine |
Clone thin provisioned, Windows with single NIC and credential | Clones a Windows virtual machine, performing the guest OS customization. Specifies virtual disk thin provisioning policy and configures one network card and a local administrator account. Sysprep tools must be available on vRealize server. |
Clone virtual machine from properties |
Clones virtual machines by using properties as input parameters. Properties of different types have the following prefixes: - VMware properties start with vm - Windows properties start with win - Linux properties with lin - Networks properties start with nic1, nic2, nic3 or nic4 - Other properties are ignored See the workflow attributes for the key name and object types. |
Clone virtual machine, no customization | Clones a virtual machine without changing anything except the virtual machine UUID |
Clone, Linux with multiple NICs |
Clones a Linux virtual machine, performs guest OS customization and configures up to four virtual network cards. |
Clone, Linux with single NIC | Clones a Linux virtual machine, performs guest OS customization and configures one virtual network card |
Clone, Windows Sysprep with single NIC and credential | Clones a Windows virtual machine performing the guest OS customization. Configures one virtual network card and a local administrator account. Sysprep tools must be available on vCenter server |
Clone, Windows with multiple NICs and credential | Clones a Windows virtual machine, performing guest OS customization. Configures the local administrator account and up to four virtual network cards. Sysprep tools must be available on vCenter server |
Clone, Windows with single NIC | Clones a Windows virtual machine, performs guest OS customization and configures one virtual network card. Sysprep tools must be available on vCenter server |
Clone, Windows with single NIC and credential | Clones a Windows virtual machine, performing guest OS customization. Configures one network card and a local administrator account. Sysprep tools must be available on vCenter server |
Convert disks to thin provisioning |
Converts thick-provisioned disks of virtual machines to thin-provisioned disks. Converting from thick to thin provisioning involves moving the virtual machine, as disks cannot change from thick to thin provisioning in situ. To perform the conversion, you must first choose the datastore from which to select virtual machines. When the workflow runs, you must choose a temporary datastore in which to host the virtual machines during the conversion process. You cannot convert virtual machines in the powered on state that have snapshots. However, you can convert powered on virtual machines that do not have snapshots, and you can convert virtual machines that have snapshots if they are powered off. If a virtual machine is in datastore1, and this virtual machine has one thick-provisioned disk on datastore1 and another thick-provisioned disk on datastore2, you must move the virtual machine to a third datastore, datastore3. If you do not move the virtual machine to datastore3, only one disk will convert. |
Convert independent disks | Converts all independent virtual machine disks to normal disks by removing the independent flag from the disks |
Create a simple XML document | Creates a simple XML document for testing purposes |
Create a snapshot | Creates a snapshot and returns it |
Create address book CSS | Creates CSS for the address book example |
Create address book DTD | Creates a DTD for the address book example |
Create address book XML | Creates XML for the address book example |
Create cluster | Creates a new cluster in a given host folder |
Create custom virtual machine | Creates a virtual machine with the specified configuration options and additional devices |
Create datacenter | Creates a new datacenter in a given datacenter folder. Returns the new datacenter. |
Create datacenter folder | Creates a new datacenter folder and returns it |
Create host folder | Creates a new host folder and returns it |
Create recurrent task | Creates a recurrent task. Returns the newly created task. Possible recurrenceCycle attribute values: - one-time: Task runs once only. - every-minutes: Task runs every minute - everyhours: Task runs hourly - every-days: Task runs daily - every-weeks: Task runs weekly - every-months: Task runs monthly Possible recurrencePattern attribute values depend on the recurrenceCycle attribute value: - one-time: Ignores the recurrencePattern attribute - everyminutes: Seconds into each minute at which the task starts, for example, "00" or "00, 30" - every-hours: Minutes and seconds into each hour at which the task starts, for example, "00:00" or "00:00, 30:00" - every-days: Time at which the task starts each day, for example, "18:30:00" or "12:00:00, 19:30:00" - every-weeks: Day and time at which the task starts each week, for example, "Mon 00:00:00" or "Mon 00:00:00, Wed 18:00:00" - every-months: Date and time at which the task starts each month, for example, "14 00:00:00" or "14 00:00:00, 28 18:00:00" |
Create resource pool | Creates a new resource pool with the default CPU and memory allocation values. To create a resource pool in a cluster, the cluster must be with VMware DRS enabled. |
Create resource pool with specified values | Creates a resource pool with the specified CPU and memory allocation values. To create a resource pool in a cluster, the cluster must be with VMware DRS enabled |
Create simple dvPortGroup virtual machine | Creates a simple virtual machine. The network used is a Distributed Virtual Port Group. |
Create simple virtual machine | Creates a virtual machine with the most common devices and configuration options |
Create snapshots of all virtual machines in a resource pool | Creates a snapshot of each virtual machine in a resource pool |
Create task | Schedules a workflow to run at a later time and date, as a task |
Create virtual machine folder | Creates a new virtual machine folder |
Create VMFS for all available disks | Creates a VMFS volume for all available disks of a given host |
Customize virtual machines from properties | Clones virtual machines by using properties as input parameters. Properties of different types have the following prefixes: - VMware properties start with vm - Windows properties start with win - Linux properties with lin - Networks properties start with nic1, nic2, nic3 or nic4 - Other properties are ignored See the workflow attributes for the key name and object types. |
Customize, Windows with single NIC and credential | Performs guest OS customization, configures one virtual network card and a local administrator account on a Windows virtual machine. |
Delete all files | Deletes a list of files |
Delete all unused datastore files | Introspects all datastores in the vCenter Server and deletes all unused files |
Delete cluster | Deletes a given cluster |
Delete datacenter | Deletes a given datacenter |
Delete datacenter folder | Deletes a datacenter folder and waits for the task to complete |
Delete host folder | Deletes a host folder and waits for the task to complete |
Delete resource pool | Deletes a resource pool and waits for the task to complete |
Delete virtual machine | Removes a virtual machine from the Inventory and Datastore |
Delete virtual machine folder | Deletes a virtual machine folder and waits for the task to complete |
Disable HA on cluster | Disables HA on a given cluster |
Disconnect all detachable devices from a running virtual machine | Disconnects all detachable devices, such as floppy disk and CD-ROM drives from a running virtual machine. The virtual machine must be running. |
Disconnect host | Disconnects an ESX host from vCenter Server |
Display all datastores and disks | Displays the existing datastores and available disks |
Display all locks | Shows all locks |
Do trivial operation | |
Enable HA on cluster | Enables HA on a given cluster |
Enter maintenance mode | Puts the host in maintenance mode. While this task is running and when the host is in maintenance mode, virtual machines cannot be powered on and provisioning operations cannot be performed on the host. Once the call completes, it is safe to turn off a host without disrupting any virtual machines. The task completes once there are no powered-on virtual machines on the host and no provisioning operations in progress on the host. The operation does not directly initiate any operations to evacuate or power-down virtual machines. However, if the host is part of a cluster with VMware DRS enabled, DRS provides migration recommendations to evacuate the virtual machines. If DRS is in fully-automatic mode, it automatically schedules virtual machine evacuation. The task is cancellable. |
Example interaction with email | Simple example to illustrate how to send an email to respond to a query, known as a user interaction. NOTE: This workflow uses the default mail server configuration that you can set in the Orchestrator configuration interface. For information about setting the mail server configuration, see 'Define the Default SMTP Connection' in the Orchestrator Installation and Configuration Guide. |
Exit maintenance mode | Exits maintenance mode. The task can be canceled. |
Export logs and application settings |
Generates a ZIP archive of troubleshooting information that contains the following files: - Configuration files - Server, configuration, wrapper and installation log files - Workflow, action, Web view, configuration element, resource element, policy template, policy, authorization element and task information |
Export unused datastore files | Introspects all datastores and lists all unused files in an XML descriptor file |
Extract virtual machine information |
Returns the virtual machine folder, host system, resource pool, compute resource, datastore, hard drives sizes, CPU and memory, network, and IP address for a given virtual machine. VMware Tools may need to be installed. |
Fill batch configuration elements |
Populates the configuration elements that the Run workflow on a selection of objects workflow uses. Performs the following tasks: - Resets the BatchObject and BatchAction configuration elements - Fills the BatchObject configuration element with all the workflows that have only one input parameter - Fills the BatchAction configuration element with all the actions that have only one parameter and have an array as the returnType |
Find element in document | Finds an element in an XML file and logs it |
Find orphaned virtual machines | Lists all virtual machines in an orphaned state in the Orchestrator inventory. Lists the VMDK and VMTX files for all datastores in the Orchestrator inventory that have no association with any virtual machines in the Orchestrator inventory. Sends the lists by email (optional). |
Find unused files in datastores | Searches vCenter Server for all unused disks (*.vmdk), virtual machines (*.vmx), and template (*.vmtx) files that are not associated to any vCenter Server instances that are registered with Orchestrator. |
Full address book test | Tests full address book cycle. Namely: - creates a directory - creates address book DTD, XML, and CSS - appends the stylesheet |
Full JDBC cycle example | Tests the full JDBC cycle, namely: - Tests the connection - Creates the table - Inserts and logs entries - Deletes and logs entries - Empties table - Drops table |
Generate key pair | Generates key pair to connect to an SSH host without a password |
Get a VirtualEthernetCard to change the network |
Returns a new ethernet card to update a virtual device. Contains only the device key of the given virtual device and the new network. |
Get all configuration, template, and disk files from virtual machines |
Returns a list of all virtual machine descriptor files and a list of all virtual machine disk files, for all datastores. |
Get custom attribute | Gets a custom attribute for a given virtual machine, in vCenter Server |
Get Linux customization | Returns the Linux customization preparation |
Get multiple VirtualEthernetCard device changes | Returns an array of VirtualDeviceConfigSpec objects for add and remove operations on VirtualEthernetCard objects |
Get NIC setting map | Returns the setting map for virtual network card by using VimAdapterMapping. Changes NIC information for workflows that clone and reconfigure virtual machines. Other clone workflows call this workflow. |
Get resource pool information | Returns CPU and memory allocation infromation about a given resource pool |
Get Windows customization, Sysprep with credentials | Returns the customization information for Microsoft Sysprep process, with credentials. The different workflows for cloning Windows virtual machines use this workflow |
Get Windows customization, Sysprep with Unattended.txt | Returns the customization information for the Microsoft Sysprep process using an Unattended.txt file. The different workflows for cloning Windows virtual machines use this workflow |
Get Windows customizations for Sysprep | Returns the customization information for the Microsoft Sysprep process. The different workflows for cloning Windows virtual machines use this workflow |
JDBC connection example | Tests JDBC connections |
JDBC create table example | Tests table creation using JDBC |
JDBC delete all from table example | Tests the deletion of all entries in a table |
JDBC delete entry from table example | Tests the deletion of an entry from a table |
JDBC drop table example | Tests dropping a table |
JDBC insert into table example | Tests insertion of rows into a JDBC table |
JDBC select from table example | Test JDBC table select rows |
JDBC URL generator | Solicits information to generate a connection URL for JDBC database connections. The workflow emits the connection string it generates as output via the system log, and confirms the string can create a connection to the specified database. |
Linked clone, Linux with multiple NICs | Creates a linked clone of a Linux virtual machine, performs the guest OS customization, and configures up to four virtual network cards |
Linked clone, Linux with single NIC | Creates a linked clone of a Linux virtual machine, performs the guest OS customization, and configures one virtual network card |
Linked clone, no customization | Creates a linked clone of a given virtual machine |
Linked clone, Windows with multiple NICs and credential | Creates a linked clone of a Windows virtual machine, performing the guest OS customization. Configures up to four virtual network cards and a local administrator account. Sysprep tools must be available on vCenter server |
Linked clone, Windows with single NIC and credential | Creates a linked clone of a Windows virtual machine performing the guest OS customization. Configures one virtual network card and a local administrator account. Sysprep tools must be available on vCenter server |
Locking test | Test workflow that creates a lock |
Locking test (x5) | Test workflow that creates 5 locks |
Log all datastores files |
Prints a log for every virtual machine configuration file and every virtual machine disk file found in all datastores. |
Log unused datastore files | Searches vCenter Server for all unused files that are registered on virtual machines and logs the files. Exports the files in a text file |
Mark as template | Converts an existing virtual machine to a template, not allowing it to start. Templates can be used to create new virtual machines. Warning: The workflow may finish before the virtual machine status is refreshed. |
Mark as virtual machine | Converts an existing template to a virtual machine, allowing it to start. Warning: The workflow may finish before the VM status is refreshed |
Migrate virtual machine | Migrates a virtual machine from one host to another. Uses MigrateVM_Task from the vSphere API |
Migrate virtual machines using vMotion/Storage vMotion | Uses vMotion, storage vMotion, or both vMotion and Storage vMotion to migrate a single virtual machine, a selection of virtual machines, or all available virtual machines. NOTE: vCenter Server does not allow storage vMotion and vMotion in the same pass for a powered on virtual machine. You must power off the virtual machine to use storage vMotion and vMotion in the same pass. |
Modify XML document | Modifies an XML file by writing a new XML document in a new file |
Mount floppy disk drive | Mounts a floppy disk drive FLP file from the ESX datastore |
Mount tools installer | Mounts the tools installer on the virtual CD-ROM |
Move host into cluster |
Moves an existing host into a cluster. The host must be part of the same datacenter, and if the host is part of a cluster, the host must be in maintenance mode. If the host is a stand-alone host, the stand-alone ComputeResource is removed as part of this operation. All virtual machines associated with the host, regardless of whether or not they are running, are moved with the host into the cluster. If there are virtual machines that should not be moved, then migrate those virtual machines off the host before initiating this operation. If the host is a stand-alone host, the cluster supports nested resource pools, and the user specifies the optional resourcePool argument, then the stand-alone host's root resource pool becomes the specified resource pool and the stand-alone host resource hierarchy is imported into the new nested resource pool. If the cluster does not support nested resource pools or the resourcePool argument is not specified, then the stand-alone host resource hierarchy is ignored. |
Move host to folder |
Moves a host into a folder as a standalone host (ComputeResource). The host must be part of a ClusterComputeResource in the same datacenter and the host must be in maintenance mode. Otherwise, the operation fails. |
Move virtual machine to folder | Moves a virutal machine to the specified virtual machine folder |
Move virtual machine to resource pool | Moves a virtual machine to a resource pool. If the target resource pool is not in the same cluster, use the Migrate/Relocate workflows. |
Move virtual machines to another vCenter Server | Moves a list of virtual machines to another vCenter Server |
Move virtual machines to folder | Moves several virtual machines to the specified virtual machine folder |
Move virtual machines to resource pool | Moves several virtual machines to a resource pool |
Power off virtual machine and wait | Powers off a Virtual Machine and waits for the process to complete |
Quick migrate multiple virtual machines | Migrates multiple virtual machines at the same time |
Quick virtual machine migration | Suspends a virtual machine and migrates it to another host |
Reboot guest OS | Reboots the virtual machines's guest OS. Does not reset non-peristent virtual machines. VMware Tools must be running. |
Reboot host | Reboots a host. If the Orchestrator client is connected directly to the host, it does not receive any indication of success in the returned task, but rather loses the connection to the host if the command succeeds. |
Reconfigure resource pool | Reconfigures CPU and memory allocation configuration for a given resource pool |
Reconnect host | Reconnects a disconnected host by providing only the host information |
Reconnect host with all information | Reconnects a host by providing all information about the ESX host |
Register vRO public key on host | Register the vRO public key (must be generated before) to a target host. |
Register virtual machine | Registers a virtual machine. The virtual machine files must be stored in an existing datastore and must not be already registered. |
Release all locks | Releases all locks |
Reload datacenter | Force vCenter Server to reload data from a datacenter |
Reload host | Forces vCenter Server to reload data from an ESX host |
Reload virtual machine | Forces vCenter Server reload a virtual machine |
Relocate virtual machine disks | Relocates a virtual machine's disks to another host or datastore while the virtual machine is in the powered off state. Uses the RelocateVM_Task from the vSphere API. |
Remove all snapshots | Removes all existing snapshots without reverting to a previous snapshot |
Remove excess snapshots | Finds virtual machines with more than a given number of snapshots and optionally deletes the oldest snapshots. Sends the results by email. |
Remove host |
Removes an ESX host and unregisters it from vCenter Server. If the ESX host is part of a cluster, you must put it in maintenance mode before attempting to remove it. |
Remove old snapshots |
Gets all snapshots that are older than a given number of days and prompts the user to select which ones to delete. |
Remove snapshots of a given size | Gets all snapshots that are larger than a given size and prompts the user to select which ones to delete |
Rename cluster | Renames a given cluster |
Rename datacenter | Renames a given datacenter and waits the process to complete |
Rename datacenter folder | Renames a datacenter folder and waits for the task to complete |
Rename host folder | Renames a host folder and waits for the task to complete |
Rename resource pool | Renames a resource pool and waits for the task to complete. |
Rename virtual machine | Renames an existing virtual machine on vCenter Server or ESX host and not on the datastore |
Rename virtual machine folder | Renames a virtual machine folder and waits for the task to complete |
Rescan datacenter HBAs |
Scans the hosts in a datacenter and initiates a re-scan on the hosts' HBAs to discover new storage |
Reset virtual machine and wait | Resets a virtual machine and waits for the process to complete |
Restore virtual machine from linked clone | emoves a virtual machine from a linked clone setup |
Resume virtual machine and wait |
Resumes a suspended virtual machine and waits for the process to complete |
Retrieve messages |
Retrieves the messages of a given email account, without deleting them, using the POP3 protocol |
Revert to current snapshot | Reverts to the current snapshot. If the snapshot to which to revert was taken while the virtual machine was powered on, and if you run the Revert to current snapshot workflow when the virtual machine is powered off, the workflow powers on the virtual machine so as to emulate state of the snapshot. Use the host optional input parameter to specify a host on which to power on the virtual machine. If you do not set the host parameter and vBalance is set, a host is automatically selected. Otherwise, the virtual machine keeps its existing host affiliation. |
Revert to snapshot and wait |
Reverts to a specific snapshot. Does not delete the snapshot |
Run a workflow on a selection of objects |
Runs a workflow on a selection of objects. You must have run the Fill batch configuration elements workflow before running this workflow. You can run this workflow in simulation mode, in which case the workflow will not modify any of the objects on which it runs. |
Run SSH command | Runs an SSH command |
SCP get command | Copies a file from a host to the vRO server using SSH/SCP |
SCP put command | Copies a file from the vRO server to a target host using SSH/SCP |
Send interaction | Sends an email to answer a user interaction. The email body contains both the direct answer URL, and an interaction URL to process this request. Uses the default settings from the Orchestrator Configuration interface for the following optional input parameters: SMTP host, SMTP port, username, password, from Address and from Name. You can override these values by providing input parameters. |
Send notification |
Sends an email with specified content to given email address. Uses the default settings from the Orchestrator Configuration interface for the following optional input parameters: SMTP host, SMTP port, username, password, from Address and from Name. You can override these values by providing input parameters. |
Send notification to mailing list | Sends an email with specified content to a given email address list, CC list, and BCC list. Uses the default settings from the Orchestrator Configuration interface for the following optional input parameters: SMTP host, SMTP port, username, password, from Address and from Name. You can override these values by providing input parameters. |
Set console screen resolution | Sets the console window's resolution. The virtual machine must be in the powered on state. |
Set guest OS to standby |
Sets the guest OS to standby. VMware tools must be running. |
Set up virtual machine for linked clone | Prepares the virtual machine to be link cloned. A linked clone is a copy of a virtual machine that shares virtual disks with the parent virtual machine. |
Set virtual machine performance | Changes performance settings such as shares, min/max values, shaping for network, and disks access of a virtual machine. |
Shut down and delete virtual machine | Shuts down a virtual machine and deletes it from the inventory and disk |
Shut down guest OS and wait | Shuts down a guest OS and waits for the process to complete |
Shut down host | Shuts down a host. If the Orchestrator client is connected directly to the host, it does not receive any indication of success in the returned task, but rather loses the connection to the host if the command succeeds. |
Start virtual machine and wait | Starts a virtual machine and waits for VMware Tools to start. |
Start workflows in a series | Runs a workflow multiple times in a series, one instance after the other. You provide workflow parameters in an array, providing a property list (with one property per workflow input) for each instance of the workflow that starts. |
Start workflows in parallel | Starts the provided workflow multiple times, with different parameters. You provide workflow parameters in an array, providing a property list (with one property per workflow input) for each instance of the workflow that starts. |
Storage vMotion | Perform storage vMotion for a virtual machine, all virtual machines that this plug-in knows, or a selection of virtual machines. To use "Select by action", you must run the 'Library > vCenter > Batch > Fill batch configuration elements' workflow before running this workflow. |
Suspend virtual machine and wait | Suspends a virtual machine and waits for the task to complete |
Turn on time synchronization | Turns on time synchronization between the virtual machine and the ESX server in VMware Tools |
Unmount tools installer | Unmounts the VMware Tools CD-ROM |
Unregister virtual machine | Removes an existing virtual machine from the Inventory |
Upgrade tools | Upgrades VMware Tools on a virtual machine |
Upgrade tools at next reboot | Upgrades VMware Tools on a virtual machine at the next reboot |
Upgrade virtual machine | Upgrades the virtual hardware to the latest revision that is supported by the virtual machine's current host. An input parameter allows a forced upgrade even if VMware Tools are out of date. |
Upgrade VM Hardware (force if required) | Upgrades this virtual machine's virtual hardware to the latest revision that is supported by the virtual machine's current host. This workflow forces the upgrade to continue, even if the VMware Tools are out of date. If the VMware Tools are out of date, forcing the upgrade to continue will revert the guest network settings to the default settings. To avoid this first upgrade the VMware Tools before running this workflow. |
Wait for task and answer virtual machine question | Waits for a vCenter task to complete or for the virtual machine to ask a question. If the virtual machine requires an answer, accepts user input and answers the question. |