vRO PowerShell Host vs. JavaScript APIs

vRO's scripting engine is Mozilla Rhino 1.7R4 — a Java-based JavaScript runtime frozen at roughly ECMAScript 5.1. It runs entirely inside the JVM on the vRO appliance and has no OS-level access of any kind: no shell execution, no process spawning, no Win32 API surface, no PowerShell runtime.

This is not a limitation that can be worked around from within a scriptable task or action. Rhino can parse JSON, call REST endpoints via the REST plugin, and manipulate vCenter objects through the vSphere API wrapper — but it cannot natively run a .ps1 script or invoke a PowerShell cmdlet.

A PowerShell host is a registered Windows machine (or the vRO appliance via SSH) running the vmware-vro-powershell-host service. vRO connects to it over a TCP socket and ships PowerShell commands for execution there, returning results as structured objects.

The "inline PowerShell" exposed by the PowerShell scripting plugin is transparently proxied to this host — it is not local execution. If no host is registered, all such calls fail.

JavaScript// This looks inline but executes on the remote PS host
var host = PowerShellHostManager.getHost("MyPSHost");
var result = host.invokeScript("Get-Date");
System.log(result.invocationResult);

The performance difference between a native REST call and a PowerShell-proxied one is significant — not just in speed, but in failure surface.

JavaScript REST Call (Native)

PowerShell Host Call

Use a PowerShell host when the data source or operation is fundamentally cmdlet-native and has no REST equivalent — or when the available REST API is significantly less capable than the corresponding PowerShell module.

Example — AD Group Membership Check

JavaScriptvar host = PowerShellHostManager.getHost("AD-PS-Host");
var script = "Get-ADGroupMember -Identity 'Server-Admins' | Select-Object -ExpandProperty SamAccountName";
var result = host.invokeScript(script);
System.log("[ADCheck] Members: " + result.invocationResult);

If the operation has a REST API or a native vRO plugin, keep it in JavaScript. The REST plugin is purpose-built for this work, lives inside the JVM, and eliminates the PS host dependency entirely.

Example — What Not to Do

JavaScript — Anti-Pattern// DON'T: spin up a PS host just to make an API call
// vRO → PS host → REST call → results → back to vRO
// Every hop is waste — and a potential failure point

// DO: use the REST plugin directly — faster, no host dependency
var host = RESTHostManager.getHost("AzureREST");
var req = host.createRequest("GET", "/subscriptions/" + subId + "/resourceGroups", "");
req.setHeader("Authorization", "Bearer " + token);
var resp = req.execute();
var parsed = JSON.parse(resp.contentAsString);

A common question: if a PS host makes an API call that returns 6,000 objects, should PS manipulate the data before returning it to vRO? The answer depends entirely on who owns the data source.

Rule: Who Owns the Data Source?

If the data comes from a REST API that vRO can call directly, the PS host should never be in the picture at all. vRO's REST plugin fetches the data, JSON.parse() deserializes it, and a standard for loop filters it — all inside the JVM, with no external host dependency.

JavaScript — Correct Pattern// REST call → parse → filter — all in JS, no PS host needed
var req = restHost.createRequest("GET", "/api/v2/vms", "");
var resp = req.execute();
var allVms = JSON.parse(resp.contentAsString).value;

var filtered = [];
for (var i = 0; i < allVms.length; i++) {
    if (allVms[i].powerState === "poweredOn") {
        filtered.push(allVms[i].name);
    }
}

If the data comes from a cmdlet-native source (Active Directory, Exchange, WMI), PS should own the entire operation — including filtering. Return only what vRO needs. Don't hand back raw collections of thousands of objects when a Where-Object or Select-Object can trim it first.

Quick Decision Test

vRO has no native UI, no direct database access, and no agent on managed systems. It is a pure orchestration engine. This means everything vRO does to the outside world, it does through an API.

Even VcPlugin — which feels like native vCenter access — is a strongly-typed SDK wrapper over the vSphere SOAP/REST API. vRO did not receive special OS-level access to ESXi. It received a well-structured client over the same API that any other integration tool uses.

Why This Architecture Scales

Because everything is API-driven, vRO's orchestration capability scales directly with how many APIs have been integrated. A vRO instance with REST hosts for Azure, Infoblox, Aria, and an ITSM platform can orchestrate an entire provisioning lifecycle — compute, DNS, IPAM, and ticketing — in a single workflow, with no agents, no PS hosts, and no remote sessions.

The PS Host Exception, Restated

PS hosts exist because some platforms lack REST APIs — or their REST APIs are incomplete relative to their PowerShell modules. Active Directory is the canonical example. Microsoft's Graph API covers some AD operations, but cmdlet coverage with full pipeline support still outpaces what Graph exposes for many common infrastructure tasks.

When a vendor provides a strong REST API, use it from JavaScript. When they provide a strong PS module and a limited REST API, use the PS host — but only for that specific gap. It should not become the default integration pattern.