Back in January 2015 I wrote an article on how to modify the Java heap settings for the vCenter Orchestrator client when working with very large workflows. Since vRealize Orchestrator 7.x has been released, we no longer have an installable client, just a Java WebStart file (.jnlp) that you run, or a package that you can download - but nothing that installs. Note that none of this is official or supported by VMware as far as I know - it’s the results of my experimentation which has shown some performance improvement by increasing the configured memory pool.
Big thanks to Jose Luis Gomez for this solution, his response to my tweet was spot on and invaluable! I’ve been trying to configure vCloud Air as a vCloud Director host in vRealize Orchestrator in order to create some custom resource actions for Day 2 operations in vRealize Automation. What I found was that there’s *very* little information out there on how to do this, and I ended up writing my own custom resource mapping for the virtual machines to VCAC:VirtualMachine objects - at least that way I could add my resource action.
<img class=“alignright size-thumbnail wp-image-6186” src="/images/2015/07/vRA-Product-Icon-Mac_0.png" alt=“vRA” width=“150” height=“150” - a properties object. I wanted to create a workflow that I could enable to log all of the keys, values and types of the properties object for each stage of the vRA7 MachineProvisioning workflows, and create a reference for myself on the payload for each stage. To do this I created a new workflow “debugProperties” and added an input variable called “payload”, type Properties.
VMware KB2140539 where requesting an XaaS (vRealize Orchestrator) blueprint fails with: Failed to retrieve form from provider The KB describes it occuring when “more than one VMware vRealize Orchestrator instance is configured for different tenants”. The issue I faced is not the same - in my case, I had the system default tenant configured to use the embedded vRO, and the customer tenant configured to use the system default (which would be the embedded vRO!
The new Event Broker service in vRA7 is one of the most exciting features of this latest release, the possibilities for extensibility are huge. At this point it time you can still use the old method of using workflow stubs to customise machine lifecycle events, but at some point in the future this will be deprecated and the Event Broker will be the only way to extend. With this in mind, I wanted to use the Event Broker to do something that I am asked on almost every customer engagement - custom hostnames beyond what the Machine Prefixes mechanism can do.
If you use the in-built vRealize Orchestrator instance shipped with the vRealize Automation appliance then you might run into this issue when working with the REST client: Connection pool shut down (Workflow:Get-IdentityToken / Scripting (item3)#14) The vRA appliance version I have (6.2 - note to self, need to update lab!) includes the plugin version 1.0.4 for REST. According to the release notes, this was fixed in 1.0.5 - typical!
I tested vSphere 6 quite intensively when it was in beta, but I didn’t ever upgrade my lab – basically because I need a stable environment to work on and I wasn’t sure that I could maintain that with the beta. Now 6 has been GA a while and I have a little bit of time, I have begun the lab upgrade process. You can see a bit more about my lab hardware over on my lab page.
I tested vSphere 6 quite intensively when it was in beta, but I didn’t ever upgrade my lab - basically because I need a stable environment to work on and I wasn’t sure that I could maintain that with the beta. Now 6 has been GA a while and I have a little bit of time, I have begun the lab upgrade process. You can see a bit more about my lab hardware over on my lab page.
Recently, I’ve had a bit of a SOAP baptism of fire - the project I am working on makes hundreds of SOAP calls to multiple SOAP APIs on multiple hosts. During this time I’ve encountered some common and rare problems and troubleshooting them seems to be a bit of a black art, if the number of results in Google is any measure. To demonstrate some of these troubleshooting methods I will use a global weather SOAP service, http://www.
When you are using a VMware orchestration platform with an official VMware plugin to manage a VMware product, you don’t really expect to have to fix the out-of-the-box workflows. However, during some testing of some workflows with a client the other day we ran into a couple of issues with the vCloud Director plugin workflows. Software versions used vCloud Director 5.5.1 (appliance for development) and 5.5.2 (production deployment) vRealize Orchestrator Appliance 5.