I was going through the Planet V12n blog posts and noticed one by Maish. His question was “Do You Really Need the vMA?” and I guess that is a valid question… I guess. The main theme in his article is PowerCLI good, vMA bad. Well that might be a bit overdone on my account, but when reading this quote you get my drift:
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?
As Maish points out the things you can do with the vMA can also “easily” be done through the use of PowerCLI. Now if you are a PowerCLI expert like Alan Renouf or Luc Dekens that is certainly true as they know how to deal with all the API objects as not all features are exposed through standard cmdlets. I guess I just touched the major pain point of any scripting language out there, you need to be an expert for quick results… So let’s line up a couple of things here to make my point clear:
- First and foremost, VMware is moving away from the Service Console, direct console access is not what an appliance type of hypervisor (ESXi) is about!
- People use the console primarily for troubleshooting, agents and bash scripts
I guess that says enough. Who of you troubleshoots their environment by using a scripting language? Yes, maybe William Lam or again Luc / Alan, but “normal” people who don’t think in PowerCLI statements or Perl code will not. No, we will grab resxtop/esxtop to do performance troubleshooting. Yes, I know you can do more or less the same with PowerCLI but lets be honest nothing beats flicking through those metrics after typing “resxtop”. (even with powerCLI you can’t beat that!)
Or even better having access to the whole suite of “esxcfg-” commands. I don’t know about you, but when I want to troubleshoot my environment I need the “esxcfg-” to my disposal and I might not always get direct console access in an ESXi environment.
On top of that as a Consultant/Architect there is much value in having a single appliance running in an environment where you can store your scripts (just look at the huge archive that William Lam has created over the years) and run when ever you please to. I even used to have a vMA all set up in VMware Workstation and carried it around with all sorts of scripts, this way I didn’t need to access the customers “backbone”.
You can guess by now that I believe that the vMA has value and that this value not only lies in the fact that you have the commandline tools to your disposal which you have become accustomed to over the years but also that you have the option to “convert” your bash scripts to run within the vMA.
Don’t get me wrong, I am certainly not trying to dismiss PowerCLI here. PowerCLI has proven itself over and over again and is probably the scripting language with the least steepest learning curve. However it is by no-means a tool to do in-depth troubleshooting as it simply requires too much hands-on experience to be able to extract the details you need when your (internal) customer is breathing down your neck.
Yes the vMA is here to stay indeed,