Do you remember when the vSphere Management Assistant (vMA) was introduced? If you do then I’m sure you also remember the reason!
Let’s go back to the days when ESXi was not around, remember ESX? ESX had a much larger service console and managing this service console was sometimes harder than it needed to be, you would need to log into the service console and run various commands to administer it, change configuration aspects or restart agents etc but as we know in ESXi the service console was stripped down to the bare minimum and at the time to help with this migration from ESX to ESXi VMware introduced vMA, this was a separate appliance you could load into your environment and it contained a mix of the tools you would use on the service console and therefore enable some of the same use cases that were needed in the full-fat ESX.
Let’s fast forward to more recent times, vCenter and ESXi are both much more mature products and most of the functionality available as part of vMA has been moved to the APIs allowing multiple new clients to be able to configure or work with ESXi, things like PowerCLI or some of our SDKs or vCLI, the use for many of the original commands in vMA are no longer valid and have been moved elsewhere. Another key factor is the change in the way people expect to work with these tools as the evolution of the admin has progressed to more automation focused or devops type roles, they often want to expand the use cases of these CLI access points or SDKs to combine the scripts with other installed applications or later operating system versions. We saw customers wanting to take vMA and install their own tools, add corporate monitoring tools or 3rd party applications or patch the OS used in vMA, clearly this caused an issue with the appliance model when upgrading as we needed a known good configuration to guarantee things wouldn’t break, we needed to provide a better way for customers to work in this kind of environment and not restrict them.
With this in mind, and with the availability of other tools and more modern ways to run and work with vSphere and ESXi we have decided to deprecate vMA, you may have noticed this warning now in the “What’s New” section of the vMA 6.0.0.1 release notes back in May 2016:
And more recently that we have now deprecated vMA and the last release was the vMA 6.5 release.The most recent version of the
Alternatives to vMA
vCLI
You may already know that vMA was mainly vSphere Command Line Interface (vCLI) wrapped in a Linux OS and distributed in an OVA format, vCLI is still available and features a lot of the base command-line utilities which are available within vMA. The biggest benefit is that these are all available by way of a standalone installer. This means you can now have all the familiar commands on a system with an OS of your choosing. Those commands would be like vicfg-, esxcli and resxtop. vCLI also adds in the new Datacenter CLIs (DCLI), which is used to interact with new vCenter services, you can read more about DCLI here. Since you can choose your own OS, that means you can manage, update, and secure the system at your own discretion!
However, don’t get too comfortable with esxcfg- or vicfg- as both of those are being deprecated too. If those are still in use in your environment, check out the Reference to Replacements for Service Console Commands Guide for conversion tips.
Using vCLI
There are a couple of nice features vMA brought to the table, so let’s cover how to provide an alternative for those in vCLI.
vMA contained a couple built in user accounts. You’ll recall these to be vi-admin and vi-user. These are just user accounts, and really only come into play when vi-fastpass authentication is in use. They can be substituted with any user available on the local system.
While on the topic of vi-fastpass, vCLI substitutes that functionality with that of a credential store. The credential store locally stores passwords in an obfuscated method in order to streamline the authentication process.
An example to setup vMA’s vi-fastpass, we would do something like this to add a server’s credentials for later use: vifp addserver kresx01.sddc.local --authpolicy fpauth
Enter username for kresx01.sddc.local: root
root’s password: VMware1!
Comparing the above with vCLI’s credential store, we would do the following along with an example of how authentication is no longer needed and passed automatically:
Since we’re talking about authentication, we should talk about utilizing Active Directory authentication. On Windows systems, vCLI functions in a similar way to how vMA did. Once the system running vCLI has been joined to the Active Directory domain, it can make use of the passthrough functionality. This is available when using the –passthroughauth option.
Example command using passthrough authentication: esxcli -s vcsa01.sddc.local --passthroughauth --passthroughauthpackage “Kerberos” -h 'kresx01.sddc.local' hardware clock get
A great new feature with vCLI is the new ability to authenticate against a vCenter Single Sign-On service (PSC). It also works if you authenticate against the vCenter Service itself, but it’s recommended to use the PSC.
The last thing most customers use vMA for is log collection. We highly recommend switching over to using Log Insight. If you have a supported vCenter Standard license, you can make use of a 25 OSI pack of Log Insight licenses for free. If Log Insight isn’t a possibility, vCenter comes with the capability to serve as a syslog server.
PowerCLI and PowerCLI Core Fling
PowerCLI is a popular command line alternative here and more recently with PowerCLI Core being available it brings a lot of the functionality to the Mac and Linux, you can check out the PowerCLI Core fling here.
Docker Container with VMware Tools
Another great alternative is a Docker image with all the command line tools you need for a specific task, like for example this one here which was created by William Lam and Alan Renouf and can be built and deployed very easily.
Conclusion
While the vMA is going away, vCLI and other options take the offerings of vMA and improve on it in many areas whilst meeting the demand of modern automation tasks. vCLI allows administrators to choose their preferred OS, whereas vMA was a pre-packaged appliance that could not be altered. This allows administrators the ability to keep that OS up-to-date and patched in accordance to the IT policies within the environment. vCLI also allows for streamlined authentication by way of the local credential store or passthrough based authentication. Several other log collection methods are available in lieu of vMA’s syslog collector by way of Log Insight for vCenter or vCenter’s syslog server. vCLI also adds the ability to use the new DCLI to interact directly with the new vCenter services.
If you still have vMA in use within your environment, I highly suggest starting a plan to replace it with a system containing vCLI or one of the other alternatives listed above.
