Friday, 25 May 2018

vRealize Automation - More VM Expiration Notifications

I have been working with a customer who have mentioned concern around VMs suddenly turning themselves off if users forget the VM has a lease or don't regularly use vRA.  This to me is a question of good operating procedures and user education - but Rome wasn't built in a day, so what can we do to help...

The first article I came across was from VMware which seems to provide an out of the box method of notifying users, which is great...
but my problem is that if we want to provide more than one notification (i.e., "You have 5 days to go" and then "Last warning - your VM's going to be shut down if you don't extend the lease" type approach)... 

What I did was write a vRO workflow to find the expiration date from the vCAC:VirtualMachine and check whether it was * number of days ahead of the current date in order to trigger an email to send a custom warning.  My main issue was that the vCAC:VirtualMachine date object is in a format of string like 2018-05-25T10:15:11:254 - which I needed to convert into a vRO Date Object.

I first created an action to take the string of the vCAC Date Object and convert it to a date object.  I couldn't find a better way to do it other than splitting the string, so it looks like this:

//Input  dateString - String
//Output Date
var tempSplit = new Array();
tempSplit = dateString.split("-");
var year = tempSplit[0];
var month = tempSplit[1];
month = month -1;
var dayTime = tempSplit[2];
tempSplit = dayTime.split("T");
var day = tempSplit[0];
tempSplit = tempSplit[1].split(":");
var hour = tempSplit[0];
var minute = tempSplit[1];
tempSplit = tempSplit[2].split(".");
var second = tempSplit[0];
//Return Date Object
return (new Date(year,month,day,hour,minute,second));

From which, I can use the action to convert the date string to a vRO date and use an 'if' statement to filter VMs with a relevant date into the three separate arrays

var vcacVms = Server.findAllForType("vCAC:VirtualMachine");

//Get future dates
var now = new Date();
var dayPlus1 = new Date();
dayPlus1.setDate(dayPlus1.getDate() + 1); 
var dayPlus3 = new Date();
dayPlus3.setDate(dayPlus3.getDate() + 3); 
var dayPlus5 = new Date();
dayPlus5.setDate(dayPlus5.getDate() + 5); 

//Define arrays
var vms5Day = new Array();
var vms3Day = new Array();
var vms1Day = new Array();

//Loop all VMs to idenfity expiration times
for each (var vcacVm in vcacVms) {
System.log (vcacVm.displayName);
var vmExpires =  vcacVm.expires
System.log (vmExpires)
if (vmExpires != null) {
vmExpires = vmExpires.toString();
var dateObj = System.getModule("com.vmware.sjw").convertVraDateStringToDateObject(vmExpires);
if ((dateObj < dayPlus5) && (dateObj > dayPlus3)) {
System.log (vcacVm.displayName + " has 5 days until expiration");
if ((dateObj < dayPlus3) && (dateObj >dayPlus1)) {
System.log (vcacVm.displayName + " has 3 days until expiration");
if ((dateObj < dayPlus1) && (dateObj > now)) {
System.log (vcacVm.displayName + " has 1 days until expiration");

From the three separate arrays, I had three separate tasks for each array (mainly to be able to separate out other actions should we need them in the future)...   This was done using the new EmailMessage(); functionality with HTLM content stored in the WF attributes (mailBody)...  An example is below:

for each (var vm3Day in vms3Day) 
{ var displayName = vm3Day.displayName;
  var expiration = vm3Day.expires;
  var notes = vm3Day.notes;
if (notes == null) {
notes = "No details supplied at provisioning time"}
var messageContent = mailBody
messageContent = messageContent.replace ("{{vmName}}",displayName)
messageContent = messageContent.replace ("{{expirationDate}}",expiration)
messageContent = messageContent.replace ("{{details}}",notes)

//Get Catalog Resource from vCAC VM and get mail address from user reference
var cafeVm = System.getModule("com.vmware.sjw").getCatalogResourceOfVM(vm3Day,"arm")
var owners = new Array();
owners = cafeVm.owners;
var mailAddress = owners[0].getRef();

//Send email 
var message = new EmailMessage() ; 
message.subject = "Warning - less than 3 day on VM " + displayName  + " lease." ; 
message.toAddress = mailAddress ; 

N.B., the action referred in the above 'getCatalogResourceOfVM' info can be found here:

I don't think it's ideal, but it works!

Friday, 16 February 2018

vRealize Business for Cloud Introduction

I've spent a little time recently familiarising myself with vRealize Business for Cloud (vRBC as it's a VMware product so must have an acronym!) in particular version 7.3.  As a one-liner, it's the product customers use for cloud cost operations for private and public cloud, plus private vs public cost comparison and cost reporting.

So what does it do?:
  • Metering - collect data on resource consumption
  • Costing - identifying how much things cost in terms if hardware, licensing, power, staffing, etc.
  • Pricing -  giving the ability to add a margin.
  • Chargeback - the ability to bill for operational costs
  • Showback - the estimated costs, but no billing takes place
It uses industry averages to automatically work out what a server, rack, network port, KW of power, etc. cost and based on all of that, by identifying what hardware you've got, it makes a calculation on what a VM actually costs.  Something which I think most of my customers would like to know (and would like to tell their IT consumers).  This is dynamic and updates via the internet.

The product is a result of an acquisition of Digital Fuel back in 2011.  A product called ITBM (IT Business Management) was created which eventually turned into three versions of vRealize Business; Standard, Advanced and Enterprise.  Standard provided business management for cloud, advanced included IT financial management and enterprise added service quality features.   In 2016, vRealize Business Standard became vRealize Business for Cloud (vRBC), the feature set of vRealize Business Advanced features were moved into vRBC and vRealize Business Enterprise was sold as a company under the original Digital Fuel name.  So we now have:
  • vRBC Standard:  Private cloud metering, consumption analysis, cloud comparison and vRA Service catalogue pricing
  • vRBC Advanced:  The above + Public Cloud (AWS & Azure) metering, role-based showback, datacenter optimization, reclamation and more advanced reporting 
History lesson over, what does it look & how does it drive!?

First and foremost, deploy the appliance, all the usual stuff applies; use DNS & NTP, but you must also use UTC as a timezone.  When you deploy the appliance, you get the choice to decide what currency the platform will use:

The appliance out of the box (or ova) is 4 vCPU, 8 GB RAM, 50 GB which will support 20k VMs.  This can be manually extended to support 30k VMs.

Once the appliance is deployed, it needs to be paired to vRA.  To do this, connect to the VAMI (https://appliance:5480) and connect:

N.B., there is a way of using a standalone vIDM deployment, or even local accounts using a CLI, but I've only covered the vRA method here.  I think most of the power with the tool comes for vRA customers, although there is a use case for customers who have vCD and public clouds who want the cost features.  But the way it integrates into vRA so well shows where it's best placed (in my opinion!)  For non-vRA access, the url is https://appliance/itfm-cloud.

After the vRA connection is registered, you will notice absolutely nothing new from within vRA...  That is because in order to use the new service, you need to create a custom group, or add the newly added vRBC roles to an existing group:

Now, when you login as a user who has the vRA group assigned, you'll see the Business Management tab.  The first time you click on it, you'll be prompted for a license key.  Depending on the key you supply, you will either see the standard or advanced features.  It's worth noting that vRBC is licensed either per VM or host (covered in a vRealize Suite license for example) and you can add multiple licenses, but not mix and match VM and host licenses

Put the license in and you'll be on to the vRBC GUI... 

One thing which is historical from the old versions of vRB and which I seem to always forget is this;  although you've now tied vRA and vRBC together, you must also add the vSphere resource.  This is how vRBC calculates what hardware, network, etc. the server is using to give you the cost calculation, otherwise the VM will appear in vRBC, but it will appear as $0.00. 

To do so, from the vRA 'Administration' tab, select 'Business Management' and add the vCenter Server.  This is also where you can add vCloud Director, AWS, Azure, NSX, EMC Storage.  When adding the vCenter server, you might get a note about having to run a data collection.

One thing to do which I did not; create an account with the required permissions on whatever clusters, datastores, etc. runs your cloud infrastructure.  You do not want to include non-cloud resource in cost calculations for the platform.

Back to the Business Management tab,  you will see in the top right hand corner a 'Status' link and symbol.  This probably has a yellow warning as we've just added the vCenter server and not performed a data collection. 

This shows when the last data collection was for the cost calculations (figures provided by VMware so vRBC can make a calculation on how much things cost), vRA and vCenter (not in the above screenshot).  Once all is good, vRBC will start to make calculations about what things cost:

I mentioned here that I didn't use an account that has access to only the areas of vCenter that are used for the vRA compute workload, so everything registered against the vCenter here is registered.  All menus are interactive so by clicking on, for example, the '22 VMs' above, I can look at costs on a per-VM basis:

These figures are slightly skewed as I'm using a lot of nested ESXi, but still, this tells me for my two nested Compute ESXi hosts, how much they're costing me...  You can see above how the figures are made up, but in order to modify them, you can click on 'Cost Drivers' down the left-hand side and, for example below, modify how much each tier of storage costs.

One other thing that I quite like in vRBC is the ability to see an overall figure of what the datacenter is costing you, broken down into hardware, storage, etc... As I mentioned, I used an administrator account which had more rights than I'd ideally have if this was in production and not my lab - so I can see both my physical datacenter and my virtual datacenter costs:

So for customers who trying to move to a proper private cloud model (i.e, using chargeback or showback), how all this looks from vRA is very user-friendly.  Costs are displayed at the time of VM provisioning, and 'View Price Details' will give a breakdown in terms of CPU, RAM, Storage, etc:

And the view from the deployed items tab gives a month-to-date view of what the VM has cost:

There are a few other tools that I really like in vRBC...  As well as the ability to manage costs associated with AWS and Azure subscriptions (with the advanced license), what vRBC can also do is compare a deployment scenario across private and public cloud platforms:

This can be customised based on what actual resource you think you might use.
I'm impressed with vRBC.  I had a play with vRB a while back and felt that it took quite a bit of work to make work for most customers, where as this can be deployed and put to work with relative ease.  Consultant disclaimer:  This still needs design work and a good understanding of business requirements - quick and easy don't mean one size fits all!!

Thanks for reading.

Saturday, 13 January 2018

vRealize Automation 7.x Event Broker Subscription timeout

I have recently been working with a customer who want to use existing PXE boot mechanisms from within vRealize Automation to keep parity between physical and virtual deployments...

How this was engineered was using Event Broker Subscriptions to monitor for the Pre VMPSMasterWorkflow32.MachineProvisioned state, so vRA will create the vSphere VM and before marking the machine as 'provisioned', we execute a vRealize Orchestrator workflow to API call the build server, add the server to DNS, add to a CMDB, etc...

The issue that I faced was that the default timer on an EBS is 30 minutes; so I noticed that when this blocking subscription wasn't completing within 30 minutes, the event would fail and I'd see the below error:

"Error in state VMPSMasterWorkflow32.MachineProvisioned phase PRE event (queue=*****): Timed out waiting for Event Broker response"

On the actual Event Broker Subscription, there is a timeout setting which I had a more than 30 minutes, but the EBS was still failing after 30 minutes.  I modified the below setting, but the workflow was still not running beyond 30 minutes.

The answer was on the IaaS server in the C:\Program Files (x86)\VMware\vCAC\Server\ManagerService.exe.config file.  In here, I had to modify the section <workflowTimeoutConfigurationSection>...

After restarting the vRA Manager Service, the workflows ran for more than the 30 minutes that they were previously timing out on.  Although customers want to provision VMs at the speed at which they can within AWS, and this is something vRA is perfectly capable of, an EBS workflow that takes more than 30 minutes is something that should be rare...  but a lot of the time, we meet customers business requirements which often include using existing systems and processes, so unfortunately, more than 30 minutes to provision a VM is not uncommon.