Thursday, May 21, 2015

Provisioning Red Hat 7 with Application Director

This week’s tip is about deploying Red Hat 7 with Application Director (part of vRealize Automation)

I helped one of my clients to deploy a RHEL7 VM through Application Director, he told me that he looked everywhere and did not find anything about this issue and I should post this solution that might help others on the same situation as he. 
I could not agree more with him.

The environment where I was working on is composed of:
vCloud Automation Center 6.1  (now vRealize Automation)
Application Director 6.0  (now Application Services)

 He told me that the VM has been deployed successfully but communication with Application Director to stage/configure the application never occurs, something related with boostrap agent.

You will also see something on the logs like this: 
ExecStart=/etc/rc.d/init.d/vmware_appdirector_agent start (code=exited, status=203/EXEC)

The issue is related with the agent script not declaring the daemon which is required for RHEL7 and CentOS7 to run.

Before we dive into the solution, let’s see supportability statement:
As you can see on vRA's support Matrix, RHEL7 is only supported on vRA 6.2.
Also on Application Director’s 6.0 Manual RHEL is only supported up to 6.4 version.

Moving on, despite of supported statement, provisioning a RHEL7 VM works on vCAC 6.1 without any adjustment.
Let’s see how we can make Application Director works with RHEL7 though.

- deploy RHEL7 and configure it as you would normally do;
- install boostrap agent (do not shutdown the VM yet);
- edit vmware_appdirector_agent script (you can find it at /etc/init.d);
- add #!/bin/bash as the first line (before the copyright information);
- run /opt/vmware-appdirector/agent-boostrap/ to clean any relic files;
- shutdown the VM.

The VM is now ready to become your template.

As it’s not supported by VMware I recommend you test it very well and use at your own risk ; )

Wednesday, May 13, 2015

Changing vRealize Automation All Services Icon

******                                Update Information                               ******
******        Check the offical supported procedure for vRA 7.1      ****** ************************************************************

This post is a contribution of a good fellow that does not take no for an answer. 
For him, no challenge is big enough when it comes to achieve a client’s requirement.
I keep telling him to start a blog of his own to share all these amazing solutions, until there I’ll be glad to share his solutions with the community here, please, meet the Brazil VMware Sr. Consultant Henrique Navarro.

 The challenge this time was to change vRealize Automation’s All Services Icon.

That blue boring Lego block always pops up when the user has more than one service entitled, nothing more natural than the desired to change it.

Well it turns out there’s no easy way to change that, in fact VMware’s official answer is: 
It cannot be done and also it’s not supported !!!

Let me rephrase it before we move on.
- VMware does not support the procedure bellow.
- It should not be reproduced on a Production Environment.
- Take it at your own risk.

But if you are brave enough, Henrique figured out how accomplish that.

First it is not just a simple image file replacement, the vRA’s engineers made it encoded on the configuration files.

So we used a image converting tool to convert the default All Services Icon to a base64 code.
Also convert the new image into a base64 code, (have it 40x40 pixels)

Don’t forget to take a backup of the entirely directory before proceed:

Since we could not identify what configuration file is responsible for bringing the icon alive, we decided to change all references of that code on all files.

Run the following command, which will looks for any reference of the original base64 code and replace with the new image’s base64 code.

find /usr/lib/vcac/server/webapps/catalog-service/resources/selfservice -type f -exec sed -i 's|"Base64Original"|"Base64Nova|g' {} \;

And that’s it, you can log in and your new logo will show up

A few additioal comments:
If you have a high available implementation, perform the steps above on all your vRA appliances.
Any vRA upgrade might overwrite those files and bring the original All Services icon back

Here’s the default icon location:

Here’s the original base64 code in case you wanna give it a try.

Friday, May 8, 2015

vCloud Director could not inventory vCenter

Starting with version 5.6.3 vCloud Director is now available only through vCloud Air Network Program, you might already know that, right ?!?


If you are using this version on a mixed environment and with that I mean, the vCenter is providing resources to vCloud Director but also being used as a regular vCenter, it does not matter if the VMs are being provisioned on the same cluster or not, you will soon realize an issue with the communication between vCloud Director and vCenter.


The problem is, if one of those VMs has a RDM disk when vCloud will inventory vCenter it will find it and break the connection with the error:


com.vmware.vim.binding.impl.vim.vm.device.VirtualDiskImpl$RawDiskMappingVer1BackingInfoImpl cannot be cast to com.vmware.vim.binding.vim.vm.device.VirtualDisk$FlatVer2Backinginfo

Good news is it has been fixed on vCloud Director 5.6.4


What you are waiting for go upgrade them, Tiger !!!

Who am I

My photo
I’m an IT specialist with over 15 years of experience, working from IT infrastructure to management products, troubleshooting and project management skills from medium to large environments. Nowadays I'm working for VMware as a Consulting Architect, helping customers to embrace the Cloud Era and make them successfully on their journey. Despite the fact I'm a VMware employee these postings reflect my own opinion and do not represents VMware's position, strategies or opinions. Reach me at @dumeirell

Most Viewed Posts

Blog Archive