Category Archives: vRA

vCAC Posts

vRA 7.x Remote Console Connection Fails

I recently experienced some strange behaviour at a customer, we had a newly deployed vRA 7.2 platform, and we also built a test 7.3 and had the issue on both versions.

I should point out here that this particular customer runs on a G-Cloud site, so it’s a secure platform heavily firewalled and there is no internet access to the infrastructure.

What was happening was that when a user connected to a VM using the Remote Console they would hit the below error:

“Cannot establish a remote console connection , verify that the machine is powered on if the server has self-signed certificate, you might need to accept certificate, then close and retry the connection”

A quick google of that error will lead you to the following KB Article I followed the steps but alas no joy, also where my issue was different was that if you hit refresh on the browser the console would load, which was even stranger.

In the end I had to log a ticket with VMware Support, after the ticket was escalated to the software team, we were given the solution.

There is a default timeout when initiating the Remote Console connection, unfortunately the setting isn’t documented, and I am not sure what the default timeout setting is, I do know that to replicate our issue VMware support had to drop their timeout to 500ms.

So you need to find the file to edit, which is:

“/etc/vcac/security.properties”

Go to the end of the file and add the below setting:

“consoleproxy.timeout.connectionInitMs=20000”

You can fine tune the setting to what ever your environment needs, 20000ms seemed to be the sweet spot for us.

Hope this helps someone else out there, the only thing we can think is that some kind of CRL lookup, or other checks are happening when the connection is being created and due to our environment having no internet access these fail and increase the initiation time.

Facebooktwittergoogle_pluslinkedinby feather

vRA 7 Create a Folder Selection Dropdown

Another quick post, I needed to create a dropdown box that would give a user the ability to select which vCenter folder a newly provisioned VM should be placed in. The custom property we need to set here is VMware.Virtualcenter.Folder, if you don’t want to give your users access to choose which folder to place a new VM in, but you want to ensure all of their VMs go in a specific folder you can set this property in a number of places.

Anyway for this example I want users to be offered a dropdown box on the request form, that will list all of the child folders in a folder called “Management Servers”.

In order to do this I need to create a vRO action and then a Property Definition to enable this.

vRO Action

The code for the vRO action is as follows:

var parentFolder = “Management Servers”;

var vmFolders = VcPlugin.getAllVmFolders();

var arrFolders = [];

 

for(var i in vmFolders){

if (vmFolders[i].parent.name == parentFolder)

{

arrFolders.push(vmFolders[i].name);

}}

return arrFolders;

 

You will need to specify a return type of Array/String

If you want to test the code copy it to a new workflow and sciptable task and change the return arrFolders; line to System.log (arrFolders); and ensure you are getting back the folders you expect to see

Property Definition

Setup you Property Definition as follows:

You need to select your newly created action from vRO:

Attach the property definition to the Blueprint:

Now you have a dropdown to select the vCenter Folder:

Hope someone finds this useful

Facebooktwittergoogle_pluslinkedinby feather

Synchronise Embedded vRO

Just a quick note that had me confused for probably a little longer than it should have. I am using the vRA 7.2 embedded instances of vRO in a 2 node cluster, I recently imported a plugin using the vRO control centre, once the plugin was imported I noticed that when looking at the “Orchestrator Cluster Management” page the nodes were out of sync. I thought that as the instances were embedded then maybe vRA did something clever in the background to force the sync, however I left this for a long weekend and the nodes still hadn’t synced sync’d.

What I noticed was when looking at the Orchestrator Cluster Management page on the embedded cluster, you do not get the “Synchronize” option that you normally get when using an external appliance in a cluster, this is what had me stumped for a short while, after I found the solution I thought I’d best blog it just so can find the solution for my next deployment.

In order to view the Synchronize option I needed to append ?advanced to the URL

You’ll then have the Synchronize option available to force the sync.

 

Facebooktwittergoogle_pluslinkedinby feather

Upgrading vRA 7 to vRA 7.2

Upgrading vRA 7 to vRA 7.2

 

 

So I thought I would update my vRA 7.0.1 installation to the newly released 7.2.

I found the VMware upgrade document here and noticed there are some pre-requisites that must be in place before you perform the upgrade:

VMware Requirement

Minimum Required

My Appliance

Minimum RAM requirement

18GB

18GB

Minimum COU requirement

4 vCPUs

4 vCPUs

Minimum Disk 1 size

50GB

18GB

Minimum Disk 3 size

25GB

25GB

Minimum Disk 4 size

50GB

50GB

IaaS Web Server/Model Manager - Java version

Java 8 update 91 or higher

7 Update 67

MS SQL Server - Java version

Java 8 update 91 or higher

8 Update 111

IaaS Web Server/Model Manager - .Net version

4.5.2

4.5.1

MS SQL Server - .Net version

4.5.2

4.6.1

IaaS Web Server/Model Manager – Free disk space

5GB Available

20GB

MS SQL Server – Free disk space

5GB Available

30GB

 

The good thing is if your platform meets the minimum requirements you can go ahead and perform an in place upgrade. If like me you need to perform some remediation work most of the tasks are pretty straight forward.

On my lab installation, I am only using a single appliance and all of the IaaS components are installed on a single server, so it should go without saying that on a distributed environment there will be further steps to take.

Prerequisite Configuration

Java Upgrade 

Make sure when you are upgrading your Java version you are installing the x64 bit version, the version that automatically downloads from the java website appears to be 32bit, so I had to grab the offline x64 version. When I ran through the Java upgrade the installer prompted me to uninstall the older version of Java that was installed which was handy.

Make sure there is an environment variable for JAVA_HOME:

.Net Upgrade

I hadn’t run Windows Updates for a while on the IaaS server, I let that run through and the .Net updates were downloaded and then installed.

Resizing Disk 1 on the vRA appliance

OK so the most involved piece of the remediation work was actually resizing Hard Disk 1. There is a step by step guide on the VMware site here I thought I would run through it and point out any gotcha’s I find.

First off we need a spare Linux virtual machine, I am using a CentOS 7 machine, which also has the desktop GUI installed.

It should go without saying that in a production environment you need to backup all of your servers before you begin this, as I don’t currently have a backup solution in my lab I took a clone of the vRA7 appliance, and I took a snapshot of the IaaS Server and a backup of the SQL Server.

OK, so power off your vRA appliance, and increase the size of Hard Disk 1 to 50GB:

Then you need to add the vRA appliance primary disk to the spare Linux machine:

Log in to the CentOS machine and check the disk utility:

We can see that the vRA disk that has been added to the Linux is device “sdb”, so we need to use the disk partition management for the device:

Now to list the existing partitions type “p”:

You’ll need to take note of the partition table, as we’ll need the information a little later on.

Now we delete the existing partitions note: nothing is committed here until we write the changes
Type “d” and select partition 1 then do the same for partition 2:

Create Primary Partition

We need to create the new partitions now, type “n” and then “p” and choose partition 1. OK so this is where we need to check back with the partition table we printed off before.

Looking at the existing partition table above, we can see that the primary partition starts at block 2048, so select that as the first sector. For the last sector we need to do a quick calculation as you can see the default option would use up all available space, but we need to make sure we leave enough space for the swap partition, so what we do is work out the amount we need to reserve:

Swap Partition

End Block – 37748735
Start Block – 31438848

37748735 – 31438848 = 6309887

Available size – 104857599
Swap size – 6309887

104857599 – 6309887 = 98547712 (I rounded down to 98547711)

So the last sector figure we need is 98547711:

Now we make the partition bootable by typing “a” and selecting partition 1:

Create Swap Partition

Type “n” and “p” and choose partition 2, you can select the default starting and ending sectors here also:

Complete the process

Now we need to assign the partition code ID to each partition, again we get this from the original partition table:

Type “t” and then select the ID relevant for each partition (83 for the primary partition, 82 for the swap partition)

Before we commit the changes we should check the new partition table:

Providing you are happy with the new configuration write the changes and exit the partition tool by type “w”

Let’s format the swap partition by typing “mkswap /dev/sdb2”: