Compatibility

Orchestrator's vCenter 4.0 plug-in is fully supported for use with vCenter 4.0. However, using the vCenter Server 4.0 plug-in with vCenter Server 2.5 is not supported. To use Orchestrator 4.0 with vCenter Server 2.5, you must install Orchestrator's Virtual Infrastructure 3 plug-in.

Enable Support for Oracle Databases

To use an Oracle database, you must download the driver and copy it to the appropriate locations. The
Orchestrator installer does not install drivers for Oracle databases.

Orchestrator Discussion Forum

Known Issues

The following known issues have been discovered through rigorous testing and will help you understand some problems you might encounter in this release. The list of issues below pertains to this release of VMware vCenter Orchestrator only. Please test future releases of vCenter Orchestrator for possible improvements and fixes.

Loss of network connection to vCenter Server 4 can cause workflows to abort.

If Orchestrator loses the network connection to vCenter Server 4 while a workflow is running, and if the workflow attempts to access vCenter Server, that workflow will abort and will not attempt to restart. An intermittent connection to vCenter Server causes frequent workflow failure. Furthermore, the vCenter Server 4 plug-in flushes its cache if it loses the connection to vCenter Server. Consequently, when the Orchestrator server restarts, it fetches all running objects again from the vCenter Server rather than reloading them from the cache. Fetching the objects again can cause peaks in CPU usage and increases the load on vCenter Server. If the network connection to vCenter Server is intermittent, then constantly fetching the objects can consume vCenter Server memory, leading to drops in performance.

Workaround: Ensure that the network connection to vCenter Server is stable.

Configuration Issues

Orchestrator does not work with forest and external trusts in Active Directory

Multiple domains that are not in the same tree, but have a two-way trust, are not supported and do not work with Orchestrator. The only configuration supported for multi-domain Active Directory is domain tree. Forest and external trusts are unsupported.

Server restarts when performing swapping or when running with a heavy load.

If the Orchestrator server is running with a heavy load, for example if you have connected Orchestrator to
many vCenter Servers which are running many virtual machines, or if the server is performing swapping, you
might experience an unwanted server restart. The server restart is due to the default timeout that the Orchestrator watchdog service sets. In certain
circumstances, if a response time exceeds the watchdog timeout period, the watchdog can falsely detect a JVM
error, which leads to a server restart.

Workaround: If you experience this behavior, you can extend the watchdog timeout period by adding or modifying the
timeout parameter in the Orchestrator wrapper configuration file, wrapper.conf. The wrapper.conf file defines
the wrapping of the Orchestrator server in the host system. See the section "Set the Service Timeout Parameter" in the VMware vCenter Orchestrator Installation and Configuration Guide.

Microsoft plug-in configuration requires the LDAP host to be set to the Domain Controller name.

Calling the ActiveDirectory.getDC() method returns null if the IP address or DNS name is used in the LDAP configuration settings of the Microsoft plug-in.

Workaround: Configure the Microsoft plug-in as follows:

Log in to the Orchestrator configuration interface as vmware.

Click the Microsoft tab in the left pane.

Enter the Domain Controller name in the LDAP host text box.

Click Apply changes.

Debug screen appears if Orchestrator client runs out of memory.

If the Orchestrator client runs out of memory, for example if you are loading a workflow element that contains a very large array of objects, the debug screen appears and the client freezes.

Workaround: Close the client and allocate more memory to the Orchestrator client, as follows:

Navigate to the following directory:

install_directory\VMware\Orchestrator\apps if you installed the standalone version of Orchestrator

Possible loss of logs when using vmo.bat file to restart Orchestrator server.

If you start the Orchestrator server as a service and you then restart the Orchestrator server by running the vmo.bat file directly, you can experience a potential loss of logs. The loss of logs is due to the Orchestrator server potentially running with different permissions if you started it as a service and then restarted it using the vmo.bat file.

Workaround: Do not restart the server by using the vmo.bat file. Start the Orchestrator server as a service as follows:

The number of virtual CPUs you can add when you run the Create VM workflows is limited to 4.

When you create a virtual machine using the vSphere client, you can add up to 8 CPUs. With the Create VM workflows you can add up to 4 virtual CPUs. This is a limitation of vCenter Orchestrator 4.0.

Plug-in method behavior depends on exact Java signature.

For example, if you map a JavaScript method foo() to a Java method bar(), which takes an integer as a parameter and returns it, you can implement the Java code for foo() in two different ways:

int bar(int i) { return i; }
In this case, the call to foo() is the same as foo(null), which translates to bar(0), which returns 0 in Java, and then returns 0 in JavaScript, because null implicitly converts to 0 in an integral context

Integer bar(Integer i) { return i; }
In this case, the call to foo() is the same as foo(null), which translates to bar(null), which returns null in Java, and then returns null in JavaScript. Because this code uses objects instead of integral contexts, no conversion takes place.

Workaround: Plug-in developers must be aware of this implementation detail, since it can change the results of a function when omitting some arguments or using null explicitly.

No input parameters are displayed in the drop-down menu for the Decision workflow schema element.

You cannot define or edit the decision statement because the possible input parameters are not visible on the Decision schema element's properties tab.

Workaround: Use a Custom Decision schema element.

The Remove host workflow fails to remove a standalone ESX host from vCenter.

You can run the Remove host workflow on an ESX host which is inside a cluster and in maintenance mode.