WilliamLam.com

Automating vCAC (vCloud Automation Center) 6.0 Identity & Appliance configurations

by // 9 Comments

vCloud Automation Center (vCAC) 6.0 was released a couple of weeks ago and I have been wanting to give it a spin in my lab, especially given the new architecture and distribution form factors (Virtual Appliances + Windows). vCAC 6.0 is now comprised of three core components: Identity VA (standalone Single-Sign On Server), vCAC VA and IaaS which is still based on Microsoft .NET and will still require a Windows Server. Given the first two components are Virtual Appliances, my first intuition was to automate the configuration so I would not have to manually go through the various configuration screens using the VAMI interface.

Note: For new users of vCAC that want to get up running and fast, I highly recommend checking out Kendrick Coleman's fantastic vCAC 6.0 installation blog article series which includes step-by-step instructions and screenshots. Jad El-Zien, a Principal Engineer for VMware also has a nice collection of vCAC 6.0 installation videos but is based off of an earlier vCAC 6.0 beta (there are some things that have changed) that you can also check out if you prefer watching a video.

I initially started out with the VAMI since I have never worked with vCAC before. While the Virtual Appliances were getting configured I was also paying close attention to the logs that were being generated and the contents gave me an idea this was possible. I would also like to thank some of the folks from the vCAC Engineering team who helped answered a couple of my questions that had me stuck for a couple of days. Reverse engineering can only take you so far ... at least if you want an answer relatively quickly 😉

To that, I have created two shell scripts which will fully automate the configuration of both the vCAC Identity VA as well as the vCAC VA without any additional user interaction. The first script that we will take a look at is called configureVCACIdentity.sh and it there are a couple of variables you will need to edit before running the script. The script makes primarily make uses of the following CLI commands within the vCAC VA:

  • /opt/vmware/share/vami/custom-services/bin/vami
  • /opt/vmware/share/vami/vami_set_timezone_cmd
  • /usr/lib/vmware-identity-va-mgmt/firstboot/vmware-identity-va-firstboot.sh
  • /opt/likewise/bin/domainjoin-cli

Here are the variables and their corresponding descriptions:

VCAC_SSO_PASSWORD - Password for SSO Administrator account
VCAC_SSO_HOSTNAME - Hostname of Identity VA (FQDN)
TIMEZONE - Timezone to configure the VA (complete list in /usr/share/zoneinfo)
NTP_SERVERS - NTP Servers (comma separated list)
JOIN_AD - 1 or 0 which determines if you want to join Active Director Domain
AD_DOMAIN - AD Domain Name
AD_USERNAME - AD Username
AD_PASSWORD - AD Password

Here is an example of running the configureVCACIdentity.sh script:

To reduce the amount of output on the screen, there is a detailed log file called vghetto-vcac-id.log that is generated by the script and can be found in the home directory of the root account when logging in via SSH.

You can verify everything was successfully configured by logging into the vCAC Identity VA by going to the VAMI URL: https://[VCAC-IDENTITY-VA-HOSTNAME]:5480

The second script is called configureVCACVA.sh which will configure and setup the vCAC VA. It performs a number of operations including generating a Self-Signed SSL Certificate and connecting to the vCAC Identity VA and licensing the vCAC VA which is required before moving onto the installation of the IaaS component. The vCAC service takes a couple of minutes to fully initialize and you will notice the script will sleep for 5 minutes which is approximately how long it takes before performing the final task of licensing vCAC. The script makes primarly make uses of the following CLI commands within the vCAC VA:

  • /opt/vmware/share/vami/vami_set_timezone_cmd
  • /usr/bin/openssl
  • /usr/java/jre-vmware/bin/keytool
  • /usr/sbin/vcac-config
  • /usr/sbin/vcac-vami

Here are all the variables you will need to edit before running the script. 

VCAC_SSO_SERVER - Hostname of Identity VA (FQDN)
VCAC_SSO_PASSWORD - Password for SSO Administrator account
VCAC_VA_HOSTNAME - Hostname of vCAC VA (FQDN)
NTP_SERVERS - NTP Servers (comma separated list)
TIMEZONE - Timezone to configure the VA (complete list in /usr/share/zoneinfo)
SSL_CERT_ORGANIZATION - Self-Sign SSL Cert organization name
SSL_CERT_ORGANIZATION_UNIT - Self-Sign SSL Cert organization unit name
SSL_CERT_COUNTRY - Self-Sign SSL Cert country
SSL_CERT_STATE - Self-Sign SSL Cert state
SSl_CERT_CITY - Self-Sign SSL Cert city
SSL_CERT_EMAIL - Self-Sign SSL Cert email address
VCAC_LICENSE_KEY - vCAC license key

Here is an example of running the configureVCACVA.sh script:

To reduce the amount of output on the screen, there is a detailed log file called vghetto-vcac-va.log that is generated by the script and can be found in the home directory of the root account when logging in via SSH.

You can verify everything was successfully configured by logging into the vCAC Identity VA by going to the VAMI URL: https://[VCAC-VA-HOSTNAME]:5480

Once you have finished configuring both vCAC Identity VA and vCAC VA you will now be able to login to the vCAC VA portal by going to the following URL: https://[VCAC-VA-HOSTNAME]/shell-ui-app/

In just under 10 minutes you can have a fully configured a vCAC Identity VA and vCAC VA without having to go through multiple configuration screens using the VAMI interface. This is also great for unattended deployments or POC (Proof of Concepts) to quickly standup two out of the three core components for vCAC. I am sure for folks that are more familiar with Windows can probably even automate the IaaS component installation of vCAC, however be aware that also has some additional dependencies such as installing a particular version of .NET and SQL Server. I will leave that automation as a task for the reader 😉

UPDATE (12/23/13) - Take a look at this article for automating vCAC IaaS + SQL Server installation.

Early Xmas gift from VMware - pyVmomi (vSphere SDK for Python)

by // 13 Comments

For vSphere customers and partners who use the Python programming/scripting language, Christmas may have just arrived early. I just found today, VMware has published an initial release of their vSphere SDK for Python called pyVmomi on Github this past weekend. A Python-based SDK has always been a very popular feature request among customers and partners that I have spoken with in the past. It looks like VMware Engineering has heard you loud and clear and have been working hard to get this released.

pyVmomi Github Repository:
https://github.com/vmware/pyvmomi

pyVmomi Pypi package:
https://pypi.python.org/pypi/pyvmomi

One of the nice things about releasing pyVmomi on Github versus trying to package it with a particular vSphere release is that the larger VMware community can contribute to the project as well as more frequent updates from VMware. This has also been quite successful for another popular VMware SDK called rbvmomi (vSphere SDK for Ruby) which is seeing a huge uptick with RVC (Ruby vSphere Console) which is built on top of rbvmomi and is a great tool for managing and troubleshooting VMware VSAN.

In this first release, you will notice there is a limited amount documentation and samples exercising the various capabilities of vSphere and you will see further enhancements in these areas with future updates. If there are specific things you would like to see or samples that you think would be useful to have or that you have built, feel free to file an issue or send pull requests to the pyVmomi Github.

If you wish to quickly get started, you can install pyVmomi using a variety of methods including pip, easy_install and pypi package. Below are the steps I took to install pyVmomi on my Mac OS X system using pip and git.

Step 1 - Install pyVmomi using pip by running the following command:

sudo pip install pyvmomi

Step 2 - Clone the pyVmomi Github repo to your system using Git by running the following command:

git clone https://github.com/vmware/pyvmomi.git

After the above command, you will have a folder called pyVmomi which contains the source code as well as the two sample scripts. You can contribute back if you create additional samples or enhancements to pyVmomi by simply sending a pull requests.

Try the getallvms.py sample run the following command:

python sample/getallvms.py --host mini.primp-industries.com --password [PASS]

To try the poweronvm.py sample run the following command:

python sample/poweronvm.py --host mini.primp-industries.com --password [PASS] --vmname [VM]

Hopefully we will see many more samples from VMware as well as from our customers who will be using the new SDK. If there is anything that is missing or things you would like to see, feel free to file an issue on pyVmomi Github repository.

How to verify SSO Multi-Master Replication is properly configured & working?

by // Leave a Comment

I wrote an article yesterday demonstrating a hybrid configuration using the new SSO Multi-Master Replication in vSphere 5.5 between a vCenter Server for Windows & a VCSA (vCenter Server Appliance). The process itself is pretty straight forward and I even created a script which will automate the entire configuration. However, other than some text being shown at the end of the script stating that MMR (Multi-Master Replication) being successfully setup; how do you actually confirm MMR is properly configured & working when adding additional SSO instances?

This was something I was actually pondering about since the process was just too "easy" and pretty much seamless as it should be from a users perspective. In speaking with engineering, I came to learn that vmdird (VMware Directory Service) just leverages the LDAP standard for MMR. This means we can use any LDAP browser to connect to vmdird and view its current configuration.

Disclaimer: Please take extreme caution when viewing the vmdird database, this is primary for educational purposes. You should not be making any changes while in the database else you can negatively impact your environment.

In this example, we will be leveraging the free open source LDAP browser JXexplorer which can be run from variety of operating systems including Windows and Mac OS X. We will use JXexplorer to verify replication between our source (vCenter Server on Windows) is properly configured with our target (VCSA), you can also do this for a Windows to Windows vCenter Server deployment. We will also verify that replication itself is working by going through an example of creating an object in the source system and then verifying it has been successfully replicated to the target system.

Step 1 - Download and install JXplorer on your desktop, it does not have to run on the vCenter Server itself as we can remotely connect to the vmdird.

Step 2 - Create a new LDAP connection for your source vCenter Server on Windows using the following configuration below:

Protocol: LDAPv3
Port: 11711
Base DN: dc=vsphere,dc=local
Level: User + Password
User DN: cn=Administrator,cn=Users,dc=vsphere,dc=local

If everything was entered correctly, you should now be able to connect to the vmdird database.

Step 3 - To confirm MMR has been successfully configured between your source and target SSO Servers, you can expand the inventory to local->vsphere->Configuration->Sites->Servers. Here you should see the list of SSO Servers participating in a specific site. If you expand each server, you should see a replication agreement between the source and target of each server, this means everything is configured correctly.

In the example I had in my last blog post vcenter55-3.primp-industries.com is my vCenter Server for Windows and vcenter55-2.primp-industries.com is my VCSA. We can clearly see the replication agreements between our two systems and everything looks good.

Step 4 - To check whether MMR is working, a simple test is to create a user in vsphere.local domain using the vSphere Web Client and then compare the Users database between our source and target vmdird databases. To do so, you can open up two JXexplorer sessions, one connecting to the source vmdird and the other connecting to the destination vmdird.

MMR takes ~30sec to perform the replication and in the example above, I created a user called "wlam" on my source site and then I was able to refresh my destination system and the new user has automatically been replicated.

I really like the new SSO architecture and has really simplified SSO installation and configuration by a factor of 1000x. The built-in multi-master replication is completely transparent to the end user and this is the type of user experience our customers have come to expect of VMware. Big kudos to the SSO Engineering/Product team for all their hard work! There is still a lot of work being done to further enhance the overall install/upgrade experience and hopefully we will get to see some of these benefits in the very near future.