vRealize Orchestrator Connector
This section of the documentation contains technical information on the ASM 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 ASM 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 ASM Core vRO Connector 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 ASM Core features:
ASM Core Federated CMDB allows proper population of the ASM Core CMDB with external resources and their relationships as seen by vRO.
ASM Core Outbound action that makes it possible for ASM 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 ASM 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.
Related Documentation
ASM Core Integration platform administration and configuration concepts and details are presented in the Integration documentation.
Connector Details
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.
The unzipped folder should contain 2 sub-folders: bin and config.
2. Prepare the ASM Core Server, as described below.
3. Create or configure a connection source, as described in Creating a Connection Source.
Preparing the ASM Core Server
Copy the contents of the bin and config directories to the following locations on the ASM Core server:
2. In the ASM Core Server Console, execute the SQL script Infra.Connector.vCO.Install.scp against the target system.
3. Restart the following Windows services:
The World Wide Web Publishing Service
The ASM Core Connector Service
This example illustrates the folder structure once the vRO connector installation is completed (ASM System is PDMV9CONNECTORS).
Configure the Request Details screen in ASM Designer to pass values as part of the integration. Add a custom field to reflect the type of CMDB item you want to pass'. 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:
Example of vRO source details screen:
Installing vRO Plug-ins onto the ASM 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 ASM Core server.
Once downloaded and copied onto a temporary folder of the ASM 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 <ASM Core Root>/<Target System>/Config, X being the targeted vCO/vRO version.
8. In the vRO source detail screen of the ASM Core integration platform, use the drop-down list to select Custom X instead of Default X.
9. Restart World Wide Web Publishing Service and ASM 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.
ASM 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.
ASM Core CMDB Population Function
Ensuring physical and virtual environments are properly represented in a CMDB is paramount. The ASM 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 ASM Core.
Basically, mappings can be implemented between resource and link types of external resources as seen by vRO and ASM 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 vRO Connector.
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 ASM Core Integration Platform.
The types that are available for import in the ASM Core CMDB are listed in the table below.
To take advantage of Post Provision Actions, you must map CIs to the VC: Virtual Machine.
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 ASM 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 ASM 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 ASM 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.
ASM Core has specific functionality to assist in the field of Data Center automation and Control, namely the Outbound actions function. Basically, it allows ASM 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.
ASM Core Outbound Action Function
ASM 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, ASM Core Outbound action breaks into 2 main parts:
Mappings that establish relationships between available ASM 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 ASM 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 ASM Core and the third party application so that some sort of monitoring is available inside ASM Core about the running of the third party action.
For detailed information on ASM Core Outbound action function, see Using Outbound Actions.
Connector Outbound Action Types
This connector enables ASM 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 ASM 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.
ASM 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 ASM 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 ASM 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 ASM 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 ASM 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. 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 ASM 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
ASM 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 ASM 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 ASM Core, Change management is mainly managed through flexible and configurable approval functionality already built in to the ASM 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 ASM Core CMDB Linking Diagram (see recommendations below).
Resources and Links
In order to perform an Impact analysis, users would have to properly populate the ASM 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 ASM Core Integration Platform.
Link configuration for the vRO integration is quite straightforward and regular ASM 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 ASM 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 ASM Core CDMB and Outbound action functionalities.
Resource Type Details
SSH: RootFinder
Fields
(None)
SSH: SshConnection
SSH: RootFolder
SSH: Folder
SSH: File
VC: VMware Distributed Virtual Switch
The interface to the implementation of the switch. The functionality listed here is for VMware DistributedVirtualSwitch only.
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.
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.
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.
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:
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.
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.
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.
VC: Distributed Virtual Switch
The interface to the distributed virtual switch objects.
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.
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.
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.
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.
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.
Link Type Details
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.
Last updated