Do You Really Need the vMA?
This post was triggered by a very informative conversation I had with William Lam this week. Thanks William!
vMA - vSphere Management Assistant, is a virtual machine that includes prepackaged software such as a Linux distribution, the vSphere command‐line interface, and the vSphere SDK for Perl. Basically it is the missing service console for ESXi. But it’s more than that too.
This allows administrators to run scripts or agents that interact with ESX/ESXi and vCenter Server systems without having to explicitly authenticate each time. vMA can also collect ESX/ESXi and vCenter Server logs and store the information for analysis.
Ever since VMware announced that ESXi will be be the de-facto platform going forward for the hypervisor starting from 4.1 - a large amount of speculation was raised about how to continue forward, and how we will continue to perform what we were doing up until now on the service console - with the console that is gone.
VMware is pushing all of us to move to the vMA to do all this administration.
Now let me share a trail of thought with you. (I would like to stress, these are my thoughts - and are based on my speculation)
Does the vMA have a future? Will there be a need for it down the road? Up until now one of the two limiting factors that were not available in was esxcli and esxtop. Since PowerCLI 4.1.1 this is no longer a limitation.
ESXCLI now available through PowerCLI and ESXTOP Available Through PowerCLI
So my question to you is, what do we need to keep the vMA for? If someone would tell me because of the built-in syslog server which is available - that does not sell me.
The amount of API objects that are currently available for use in PowerCLI - that are not available or exposed through the Perl SDK, has continuously been rising with each new version released.
What is the reason to keep the vMA around in the future? What (if anything) is the necessity for you to have a vMA? Is there anything that you cannot do today with PowerCLI that can only be done with the vMA?
And if that is case - why go down that route and add another VM that has to be managed, has to be patched and will use up resources on your vSphere infrastructure?
I look forward to your comments and your thoughts.