VRA

Written by Sam McGeown on 14/8/2015
Published under VMware and vRealize Automation
Now that the prerequisites for the IaaS layer have been completed, it’s time to move on to the actual installation of the IaaS components, starting with the database. We then move onto the first Web server, which also imports the ModelManagerData configuration to the database, populating the database with all of the info the IaaS layer needs out of the box. We then install the second Web server before moving on to the active Manager server.
Written by Sam McGeown on 14/8/2015
Published under VMware and vRealize Automation
One of the trickiest parts of deploying vRealize Automation is the IaaS layer - people sometimes look at me like I’m a crazy person when I say that, normally because they’ve deployed a PoC or small deployment with just a single IaaS server. Add in 5 more servers, some load balancers, certificates, a distributed setup and MSDTC to the mix and you have a huge potential for pain! If you’ve followed my previous posts, you’ll see know that I’ve got a HA Platform Services Controller configured, and a HA vRealize Appliance cluster configured with Postgres replication - all good so far.
Written by Sam McGeown on 24/7/2015
Published under VMware and vRealize Automation
Having just completed a particularly problem-prone distributed IaaS install, this was almost the straw that broke the camel’s back. Logging into vRealize Automation for the first time as an Infrastructure Admin displayed the infrastructure tab and all menu labels as big ugly references, and no functionality: <{com.cmware.cap.component.iaas.proxy.provider@csp.places.iaas.label>} Rebooting the IaaS web servers restored the functionality of the IaaS layer but still did not fix the label issue, it took a further reboot of both vRealize Automation appliances, then the IaaS web servers to finally view the correct labels.
Written by Sam McGeown on 8/7/2015
Published under VMware and vRealize Automation
The recommendations for the vRealize Appliance have changed with 6.2, the published reference architecture now does not recommend using an external Postgres database (either vPostgres appliance, a 3rd party Postgres deployment or using a third vRealize Appliance as a stand-alone database installation). Instead the recommended layout is shown in the diagram below. One instance of postgres on the primary node becomes an active instance, replicating to the second node which is passive.
Written by Sam McGeown on 7/7/2015
vSphere 6 HA SSO (PSC) with NetScaler VPX Load Balancer for vRealize Automation Deploying vRealize Automation 6.2 Appliance Cluster with Postgres Replication Deploying fully distributed vRealize Automation IaaS components - Part 1: Pre-requisites Deploying fully distributed vRealize Automation IaaS components - Part 2: Database, Web and Manager services Deploying fully distributed vRealize Automation instance - Configuring NetScaler Monitors Providing a highly available single sign on for vRealize Automation is a fundamental part of ensuring the availability of the platform.
Written by Simon Eady on 14/1/2015
Published under vRealize Automation
Recently when do a fresh install of vRealize Automation (vRA) 6.2 I came across the following error after configuring the first end point.   Error log example         DataBaseStatsService: ignoring exception: Error executing query usp_SelectAgent Inner Exception: Error executing query usp_SelectAgentCapabilities and Error processing ping response Error executing query usp_SelectAgent Inner Exception: Error executing query usp_SelectAgentCapabilities First of all I checked to see if the end points were working which in this case they appeared to be, but I wanted to clear the error before continuing the install.