WilliamLam.com

Automating VMware ITBM (IT Business Management) configuration

by // 3 Comments

Over the years I have had the privilege to install the majority of VMware products in either my production environment when I was a customer or in my personal home lab for testing. While in the process of learning about the vCloud Automation Center 6.0 to automate the installation and configuration, I came across a VMware product that I was not very familiar with called VMware ITBM (IT Business Management Suite). ITBM integrates with vCloud Automation Center and provides your business with insights into various cost analysis and metrics for both your public and private clouds.

VMware ITBM is provided as a Virtual Appliance and given that it integrates with vCloud Automation Center which I just been deployed in my home lab, I thought I take a look to see how one could automate the initial configuration setup. After manually deploying ITBM, I found the setup through the VAMI to be pretty straight forward and one could easily automate this. There is a command-line utility called /usr/sbin/itfm-config that we will be using to register our ITBM instance to vCloud Automation Center. To help simplify the setup, I have created a simple shell script called configureITBM.sh that will automatically configure ITBM given three simple variable input:

  • VCAC_VA_SERVER - Hostname/IP of your vCAC VA Server
  • VCAC_SSO_PASSWORD - The SSO password
  • TIMEZONE  - Timezone

Here is a screenshot of executing the script on the ITBM Virtual Appliance:

To verify that the configuration was successful, we can login to the VAMI interface of ITBM by opening a browser to the hostname/IP Address:5480 and we should see under the Status section we are now connected to our vCloud Automation Center Server.

Once we have confirmed that ITBM has been successfully configured we can now head over to our vCloud Automation Center Server and we should see a new tab called Business Management.

As mentioned earlier, I have not used the ITBM product before but I do recall a demo that was given during an Alpha of vCloud Automation Center 6.0 and I was quite impressed with the amount of information and customization this tool provides for cost and operational analysis.

Automating vCloud Application Director (AppD) configuration

by // 1 Comment

After publishing my two-part series on automating vCAC 6.0 installation and configuration here and here, I received an interesting inquiry on how to automate vCloud Application Director (AppD) deployment and configuration. Given that I had a couple of days before winding down for the holidays and for my upcoming trip, I took my final challenge of 2013. The challenge with trying to automate AppD deployment, even though it is distributed as a Virtual Appliance is that it requires user interaction during the first bootup. A user must provide a valid AppD license key which then allows AppD service to start up and the user must also change both the root and admin account as part of the bootup process.

This is not ideal from an automation standpoint as it prevents anyone from automating the deployment and configuration of AppD. In my opinion, these configurations should have been part of the OVF properties which can then be specified during the deployment and allow for automated/unattended deployment of AppD. Since the setup was happening during the boot process, I opted for more of an out-of-the-box solution after spending a couple of minutes looking for a workaround.

The solution that I came up would require a "slight" modification to the startup scripts which is accomplished by initially mounting the VMDK of a newly deployed AppD Virtual Machine that has not been powered on. This can be done in one of two ways by either using a live-CD such as KNOPPIX or programmatically using the vSphere APIs. Once the VMDK has been mounted, you will need to rescan the guestOS to ensure the virtual disk is visible and then mount the 3rd partition of AppD Virtual Machine as seen in the screenshot below.

The following script /opt/vmware/etc/isv/firstboot is responsible for prompting for the license key as well as changing the passwords for the two user accounts. To allow the script to continue, we will need to comment out the following lines in the script 75-102 and 287-289 as seen in the screenshot below.

In addition to the change above, we will also need to the create the license file /home/darwin/tcserver/darwin/appd-license.properties that is normally generated by going through the regular process which must also contain a valid license key. This is required as it will prevent the AppD service from starting up properly. To help simplify the changes, I have created a simple shell script called prepvCloudAppD.sh which will automatically comment out the appropriate lines in the firstboot script as well as create the AppD license file. There are two variables you will need to specify before running the script:

  • APPD_LICENSE - The license key
  • APPD_VMDK_MOUNT_HOME - The mount home of the AppD filesystem (Default: /mnt)

Here is a screenshot of executing the script:

At this point we are now ready to power up our AppD Virtual Machine and you will notice that AppD no longer prompts the users for input.

Once AppD is up and running, you should change the default password for both the root and admin account as they are not very secure by default. The default password for the root account is "vmware" and the defualt password for admin account is "password". The admin password is not an OS account but an application account and this will need to be changed by using the darwin-cli. You can do this inside of a simple shell script or right on the command line by running the following command (be sure to replace it with the password of your choice):

APPD_ADMIN_PASS=VMware123
cat > /tmp/password << __APPD_PASSWORD__
${APPD_ADMIN_PASS}
${APPD_ADMIN_PASS}
__APPD_PASSWORD__

/usr/java/jre-vmware/bin/java -jar /home/darwin/tools/darwin-cli.jar login --serverUrl https://localhost:8443/darwin --username admin --password password\;change-user-password --username admin --currentUserPassword password\;logout < /tmp/password

The above commands will create a new file in /tmp/password which contains the password you wish to change the admin account to.

Then using the darwin-cli, we can now re-direct the file we just created and change the password without any user intervention which is great for automated configuration of AppD.

Finally, we can confirm everything was setup correctly by logging into the AppD interface by opening a browser to the following URL: https://[APPD-HOSTNAME]:8443/darwin and logging in using the admin account and password we changed earlier.

Automating vCAC (vCloud Automation Center) 6.0 IaaS & SQL Server installation

by // 14 Comments

Apparently I decided to take on my own challenge of trying to figure out how to automate the installation of the vCAC 6.0 Windows component called IaaS after finishing up my automating vCAC (vCloud Automation Center) 6.0 identity & appliance configuration blog article. Perhaps I am a glutton for punishment as my friend Steve Kaplan would say 🙂

Note: One thing I would like to point out is that before attempting any type of automation is to make sure you thoroughly understand the process that you are trying to automate. This means you should go through the manual process at least once, if not a couple mores times to figure out what exactly is happening. In my particular case, I had to gone through several dozen snapshot reverts to test various things before getting to this end state and this was only made possible with the use of VMware Snapshots.

The vCAC IaaS installer is provided by the vCACVA (vCAC Virtual Appliance) at the end of its configuration an installer is made available for download which contains the IP Address of the vCAC Identity VA (SSO) in the file name. vCAC IaaS is actually made up of several components and the diagram below will help illustrate what is being installed on the Windows Server.

After going through the initial installation, I noticed some interesting logs being generated on the UI console as well as configuration files being referenced. This is where I began the somewhat painful (spent close to 14+hrs) process of figuring out how to automate the installation of vCAC IaaS which also includes a SQL Server component as that is not part of the default installation if one does not already exists. My ultimate goal was to be able to automate the entire installation of vCAC (Virtual Appliances which I have shown in my previous blog article) as well as the Windows components for IaaS so that a customer can quickly and easily stand up an environment for testing and proof of concepts.

To automate the vCAC IaaS component I have created a shell script called createVCACIaaSInstallerScripts.sh that you can run inside the vCAC VA appliance. The script generates a new Windows batch script along with a couple of configuration files that will be executed on the Windows system that will be running IaaS. You can think of this as script inception 🙂 and the generated batch script will contain all the necessary information to install SQL Server Express as well as IaaS components without any user intervention.

Before getting started, you should manually go through the prerequisites below and though these can be automated, depending on your Windows setup, you may need to make some additional tweaks and that is why I have left this portion out of my script. In my environment I am using a Windows Server 2008 R2 64-bit system and this is what tested the script in. YMMV if you are using something different.

Prerequisites:

Step 1 - Download the createVCACIaaSInstallerScripts.sh onto your vCAC VA appliance. Before executing the script, you will need to edit a couple of variables which are listed below with their descriptions.

VCAC_HOME_DIRECTORY - This is the directory on the vCAC IaaS server in which all the configuration and executables will be located in (default: C:\Users\\Administrator\Desktop\VCAC). You will need to escape the forward slash by using double slashes as noted in script.
VCAC_IAAS_SHORT_HOSTNAME - The short hostname of the vCAC IaaS system
VCAC_SSO_HOSTNAME - The FQDN hostname of your vCAC Identity system
VCAC_SSO_PASSWORD - The SSO Administrator password for *protected email*
VCAC_VA_HOSTNAME - The FQDN hostname of your vCAC VA system
VCAC_SERVICE_USER - The Windows account used to install vCAC IaaS (e.g. system\username)
VCAC_SERVICE_PASSWORD - The password to the above account
VCAC_SECURITY_PASSPHRASE - The security passphrase for the IaaS components
VCAC_DATABASE_INSTANCE_NAME - The name of the SQL Server Instance (default: VCACSQLEXPRESS)
VCAC_DATABASE_NAME - The name of the vCAC Database (default: vCAC)
EMAIL_SERVER - The hostname of an email server if you have one
EMAIL_PASSWORD - The password to the email server if you have one

Step 2 -  Once you have finished editing the script you can then execute the script on the vCAC VA. The script will NOT perform any changes but will actually generate the following four files:

  • vGhetto-SQLServerConfigFile.ini - SQL Server silent install config
  • vGhetto-VCAC-ServerConfigFile.xml
    - vCAC Core silent install config
  • vGhetto-VCAC-WAPIConfigFile.xml
    -  vCAC WAPI silent install config
  • installVCACIaaS.bat - Script that performs both SQL Server install & vCAC IaaS

Note: This article came in handy while creating the SQL Server silent install configuration file, however it did not mention the odd/stupid quirks one had to go through to generate the config file by using some additional install flags.

Here is a screenshot of what the output looks like when running the script:

Step 3 - You will need to transfer these four files via SCP to your Windows Server that will be running IaaS. In addition, there also four Windows executables that are stored on the vCACVA that you will also need to transfer to your IaaS system. The following files are all stored in /opt/vmware/share/htdocs/service/iaas/download

  • vCAC-Server-Setup.exe
  • WorkflowManagerInstaller.msi
  • VrmAgentInstaller.msi
  • vCAC-Wapi-Setup.exe

Step 4 - You will need to download the SQL Server Express installer onto your IaaS system. In my environment I used SQL Server 2008 R2 Express and the expected file name is SQLEXPR_x64_ENU.exe which is stored as a variable within the script. If you choose to use a different version, this may or may not work.

Step 5 - We are almost there! To make things easier, we had you defined a directory in which all the configuration and executables will be stored in and by default this is C:\Users\\Administrator\Desktop\VCAC You should have the following nine files within this directory:

  1. installVCACIaaS.bat
  2. SQLEXPR_x64_ENU.exe
  3. vCAC-Server-Setup.exe
  4. vCAC-Wapi-Setup.exe
  5. vGhetto-SQLServerConfigFile.ini
  6. vGhetto-VCAC-ServerConfigFile.xml
  7. vGhetto-VCAC-WAPIConfigFile.xml
  8. VrmAgentInstaller.msi 
  9. WorkflowManagerInstaller.msi

Step 6 - Finally, the hardest part 🙂 either double click onto the installVCACIaaS.bat file or what I would recommend is to run it from the cmd prompt. There are no additional configuration or tweaks required as the original shell script has done all the heavy lifting unless you provided the wrong information. The script will start off by installing SQL Server Express and then moving onto the various vCAC components. In total it takes about 20minutes and there are timestamps on when each component has finished installing, so you can get a cup of coffee, tea or beer and check out other cool articles on virtuallyGhetto.com 😉

Here is a screenshot of executing the bat script:

So there you have it! A complete automated installation of vCAC IaaS including a SQL Server database as part of the install. You can now combined this with my earlier article for automating both the vCAC Identity VA as well as the vCACVA to fully standup a vCAC environment in a little under 30 minutes. The scripts provided are very rudimentary as you can see I went a bit old school using bat scripting and I am sure there are a variety of enhancements that can be made to the script such as validating the files exists before starting and also waiting on each process before moving onto the next.

I also want to point out though the end solution looks like a trivial single script that a user executes, it took MANY MANY hours to figure out all the intricacies of the vCAC silent install process by looking at the various log files, configuration files and lots of snapshot reverts. In my opinion, this tells me we have more work to do on our installers not only making it easy and trivial to install from a UI point of view but also for automated silent installations. One should not have to reverse engineer various log and configuration files to be able to easily deploy 5, 10, 50 additional instances of vCAC or any other product for that matter. The user experience should be exactly the same and I hope this an area where we will continue to improve upon.

Lastly, this will probably be my last blog post for 2013. I am looking forward to some downtime in next couple of days before heading off to our much belated honeymoon in Asia for 3 weeks. I wish everyone Happy Holidays and a Happy New Years and see you in 2014!