vSphere Management Assistant (vMA) Review

After my last post, I decided to hang out in the vMA for a while to get acclimated with it. I’ve been using it off and on for quite a while now, but over the last few days I have been living in it. I found a few things that I think are pertinent to anyone who uses this.

First off, I should start with the basics. The vSphere Management Assistant comes from VMware in an OVF format for easy insertion to your virtual infrastructure. The management stations supports any version of ESX or ESXi from version 3.5 update 2 to present. It also consumes 512mb of memory from the host(s) and has a standard 5GB vDisk attached to it. It has two users that are already setup, one is the vi-admin account for administrative operations and the other the vi-user account with read-only rights to execute vCLI commands with. You can even join the vMA to an AD domain if you want to.

I’ve deployed about 5 of them so far and here are a few things that I do to these appliances:

1) Give it a static address and a proper DNS name so it is easy to get to and available when you need it. This can be done during the setup phase or you can run a pre-built script located in /opt/vmware/vma/bin/vmware-vma-netconf.pl – you will notice that you need to become root in order to run this, so see below to reset the password.

2) Change the root password of the appliance (since it is necessary to ‘su’ to run certain scripts on it). You can do this by running the following command: # sudo passwd root

Here are some handy commands and capabilities that you can use for the vMA:

  • Scan for updates to the vMA: # vma-update scan
  • Update the vMA (after you’ve scanned for updates): # vma-update update

Neat capabilities:

  • You can run custom code that force proprietary software or hardware components to work with ESXi.
  • Developers can you the integrated API’s within the VmaTargetLib (library) to connect to vMA targets via Java or Perl.
  • Administrators can add vCenter servers as well as ESX/ESXi nodes as potential “targets” to run scripts. This allows for a single sign on type of mechanism.
  • You can even re-use your old service console scripts that you may have used on older ESX systems.

 

Leave a Reply