Get Datastore with Most Free Space & Check Datastore Meets Capacity Reservation

I do a lot of work that involves either creating new virtual hard disks or attaching existing ones to virtual machines in VMware vSphere. I do all of this through vRealize Orchestrator, written in JavaScript (yum).

As part of this task, I always ensure that the datastores that I am creating disks on have sufficient capacity for these new disks. I use two simple functions that I have written which perform these checks for me, which is ‘getDatastoreWithMostFreeSpace’ and ‘DoesDSMeetCapcityReserve’. An additional function ‘convertToGB’, which is used by these functions is also provided at the end.

Function : getDatastoreWithMostFreeSpace

Description
Return a single VcDatastore object that has the most free space from an Array of provided VcDatastore objects. The function will always return a VcDatastore, regardless of how much free space is found.

Parameters
– VcDatastores (Array of VcDatastore)

Return Type : VcDatastore

Function : DoesDSMeetCapcityReserve

Description
Checks that a given VcDatastore has enough free space in which to place the virtual disk, taking into account current usage and a defined reservation value (in percent) that should be guaranteed. Returns true if the Datastore passes the capacity checks.

Parameters
– datastore (VcDatastore)
– reservation (Number)
– totalSizeRequired (Number)

Return Type : Boolean

Function : convertToGB

Description
Converts a value in Bytes to GB.

Parameters
– size (Number)

Return Type : Number

Example Output

[2017-09-18 15:09:37.459] [I] Selecting the datastore with the most free space:
[2017-09-18 15:09:37.714] [I] Datastore 1 information:
[2017-09-18 15:09:37.715] [I] name: DATASTORE1
[2017-09-18 15:09:37.717] [I] ID: datastore-99999
[2017-09-18 15:09:37.718] [I] Capacity: 2048 GB
[2017-09-18 15:09:37.719] [I] Free Space: 1762 GB
[2017-09-18 15:09:37.721] [I] Used Space: 286 GB
[2017-09-18 15:09:37.725] [I] MaxVMDKSize: 63488 GB
[2017-09-18 15:09:37.726] [I] Selected Candidate Datastore: DATASTORE1
[2017-09-18 15:09:37.728] [I] Performing capacity validation checks on the datastore.
[2017-09-18 15:09:37.729] [I] Datastore reservation is set to 10%
[2017-09-18 15:09:37.730] [I] Datastore has: 87% free space
[2017-09-18 15:09:37.733] [I] Datastore meets 10% reservation threshold.
[2017-09-18 15:09:37.735] [I] Checking that enough storage is available for the virtual disk(s)
[2017-09-18 15:09:37.737] [I] The reserved size at 10% is: 205 GB
[2017-09-18 15:09:37.738] [I] Free space available taking into account the reservation: 1557 GB
[2017-09-18 15:09:37.740] [I] The datastore will have 1556 GB of usable space remaining after the commit
[2017-09-18 15:09:37.741] [I] Datastore meets capacity requirements
[2017-09-18 15:09:37.744] [I] The Virtual Disk(s) will be located on: DATASTORE1

vRA 7 – Getting more information in workflows from the vRO ExecutionContext object

When a vRO workflow or action is called from vRA, additional input parameters (in addition to those specified as the workflow/action inputs) are provided in the Execution Context object. These can be very useful as they contain additional data that can be used inside the workflows. A couple of good examples would be the user that requested the resource or the name of the tenant.

Here is a list of parameters provided inside the Execution Context (those without a description I’m still trying to figure out):

 Parameter Name  Description
__asd_catalogRequestId
__asd_correlationId  The Request ID
__asd_requestInstanceId
__asd_requestInstanceTimestamp Request Date & Time
__asd_requestInstanceTypeId The lifecycle ID
__asd_requestTraceId
__asd_requestedBy The UPN of the user who made the request
__asd_requestedFor The UPN of the user the request was on behalf of
__asd_targetResourceId
__asd_targetResourceProviderId
__asd_targetResourceProviderTypeId com.vmware.csp.iaas.blueprint.service
__asd_targetResourceTypeId Type ID, i.e. ‘machine’
__asd_tenantRef The friendly name of the tenant (i.e. vsphere.local)

Wait, where is ‘__asd_subtenantRef’? More on that in my post here (soon).

You can also see these in the variables tab for the workflow run:

List all parameters

The parameters and their values in the execution context object can be retrieved using the System scripting class. There is a method called ‘getContext()‘, which returns an object called ‘ExecutionContext‘. The ExecutionContext object has the following methods:

boolean contains(String name)
Object getParameter(String name)
Array parameterNames(String name)

Insert the following code into a scripting task in your workflow to list all the parameters and their values:

Retrieve the value for a specific parameter

To retrieve a value for a specified parameter the following example can be used:

Retrieves the tenant name and sets it to a variable/attribute.

If anyone can shed some light on what the other parameters do then please comment and I’ll update the page.

Extend vRA UI Login Timeout

Nothing frustrates me more than returning to the vRA UI, clicking something and then have it immediately log me out. This appears to be quite random a lot of the time and whilst I can appreciate that this is in the interest of security, I find it a little too aggressive. This can be changed by extending the life of the authentication cookie using the following procedure.

Log in to the vRA appliance using SSH (SSH will need to be enabled via the vRA Appliance VAMI interface if it is not already). Edit the following file:

Add the following line to the end of the file:

Where ‘28800’ is the number of seconds (8 hours) until the authentication cookie expires. Set this based on your own requirements.

Save the file and then restart the vcac-server service

It will take the usual 5 minutes or so for the server to fully start up and once complete the new settings will be applied.

Repeat this process for any remaining appliances in the cluster.

vRealize Orchestrator cluster nodes not in sync with embedded vRA Appliance

I have come across this issue a number of times where the secondary vRO cluster node is not in sync with the primary node (one thing to note is that the synchronisation status is relative to the node you are logged on to).

The option to synchronise the nodes is not available because I am using vRO that comes embedded with the vRA appliance. The reason this option is not available is because vRA “should” be managing the state of the cluster nodes, which is does from a vRO client prospective but not when you make changes via the Control Center (such as changing the Admins group).

To workaround this issue and unlock the hidden options you will need to append “?advanced” to the end of the URL. For example, if you are on the Orchestrator Cluster Management page add ?advanced to the end of the URL, which should look like this:

https://vro_server:8283/vco-controlcenter/#/control-app/ha?advanced

When the page refreshes you will notice that a new button has appeared on the bottom.

Clicking on this button will reveal two new options:

  • Push Configuration
  • Push Configuration and restart nodes

Select “Push Configuration and restart nodes”, which will push the configuration and automatically restart the vRO service on the secondary node.

A message will be displayed if this is successful.

It will take approx 10 minutes for the secondary node to start up completely so grab a coffee at this point.

Refresh and both nodes should now show as “Synchronized”.

Remove ‘Default Machine Prefix’ for a Business Group

When I was building vRA 7 and figuring everything out, at some point I set the ‘Default machine prefix‘ for the Business Groups. When you first create a Business Group, setting the default machine prefix is optional; However, if you do set this value then there is no way to unset it, which I find extremely annoying. As I don’t currently use specific prefixes for business groups, I was feeling a little OCD having to set this to some other prefix value.

defaultprefix

I was able to ignore this for a while until I installed the Custom Hostnaming Extension for vRA7 by Dailyypervisor. This extension is really awesome and has helped me massively overcome my requirement to create dynamically generated hostnames. The hostnames are based on our internal naming convention and I make good use of Custom Properties for this. For testing, I simply created a very basic custom hostname scheme ‘{LOC}-GSTEST{##}’, with {LOC} being set on one of the vSphere endpoints.

hostnamescheme

At first this appeared to work just fine, until randomly some machines would be provisioned using a different hostname. The other hostname was based on another machine prefix that I had created previously and was configured as the default for the Business Group, which was ‘ES-VWOI-MANA##’. The image below shows the results of 7 machines provisioned using the custom hostname extension.

machines

Clearly what is happening here is that on each provisioning attempt, it is randomly selecting a different machine prefix. What is also interesting is that both prefixes get incremented. In fact, that’s another issue with having a default one set for the business group (or even within the Blueprint), is that they are ‘allocated’ and incremented even before the EBS is used (which is when the custom hostnaming extension kicks in, at the requested stage, which is still AFTER the allocation). I have had a small look at the code for the workflow and can see that it’s identifying that the custom hostname scheme already exists, but I haven’t yet looked into why it’s setting the wrong one.

I figured the easiest workaround for now would be to simply remove the default machine prefix from the business group and make sure no one accidently sets it. But this is when I realised you can’t do that by simply editing the group via the IaaS interface. To cut a long story short, you have to manually remove this on the database, both the SQL database used by IaaS and the PostGres database used by vRA.

Continue reading