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,
Gernot Nusshall says
Hi Duncan,
thanks for the great “reminder” that we actually do not want to access the console at the hypervisor for various reasons. I made the experience for myself that every vendor agent/script and so on is a potential host of an issue and if you got an real problem with crashes etc. you, and especially the vmware support, never can eliminate those processes as root cause.
Second, i love the PowerCLI, but to integrate Alan´s awesome collection of scripts and one liners into various monitoring systems i would need the cmd-lets be available on linux boxes, actually i did not check if something like that is already available, do you might know(i know that has nothing to do with your article)?
thanks
Gernot
Wil van Antwerpen says
Seems like you read my mind. I completely agree.
One other thing you might add is that PowerCLI has a dependency on the Windows OS.
—
Wil
Duncan Epping says
Indeed, Windows requirements is another good argument.
Maish says
Thanks for joining in on the conversation Duncan.
If the impression you got was that PowerCLI good – vMa is bad – that was not the intention.
The intention was to ask. Do you have to use vMA to remotely manage your hosts – and I think the answer to that is no – this can be done another way.
Will VMware retire the vMA somewhere down the road – I doubt it, for a number of reasons.
1. There are too many people who will need the functionality of running their bash scripts – as you said.
2. Flipping through the statistics in esxtop is the BOMB!
3. VMware should not rely totally on one platform for their management tools.
Someone who is starting out their infrastructure today – with a new ESXi environment, will most probably find it much easier to manage remotely – with PowerCLI, and perform their day to day task.
The cli commands will still be there on the host itself if needed.
True ESXi is moving away from Console – but even they understood that you should not block out the remote shell completely, up until the not so distant past it was not supported (and now is) and can be turned on/off very simply with the vSphere Client, the DCUI or even with PowerCLI 😉
The purpose of my post was to cause people to think – and not just to follow “just because everyone else is doing it..”
If it fits your environment – then use it.
If you can do it differently (and perhaps it might even be easier) then why not?
Thanks for the interesting discussion.
Duncan Epping says
I guess I completely misinterpreted your article Maish, but the way you phrased your question “what do we need the vMA for?” has been answered in this post.
Again, PowerCLI is cool and has its place but troubleshooting and environment will not work with PowerCLI. On top of that many customers will not allow direct console access for obvious reasons, hence the vMA.
Maish says
As always is is a pleasure to discuss things with you…
Thanks!
Sean says
I agree that the vMA doesn’t have much use. As a regular linux user, I find the way VMware has convoluted the login process, etc on vMA to be too great of a pain. Instead I much prefer just putting vSphere CLI on a linux box (or windows box if you prefer) and letting folks use it from there. AFAIK, vSphere CLI has everything vMA has, minus ‘vifs’ and the syslog server. Syslog server’s are a dime a dozen. So, all VMware has to do is add vifs to vSphere CLI and we’re golden.
LucD says
Great article, food for thought.
First, let’s make it clear that I don’t want to enter into a discussion of Windows=bad, Linux=good (nice try Wil, but no cigar).
The point you make about the esxcfg- commands is absolutely true.
But in my opinion this shows something else, the fact that there are still a number of ‘private’ APIs required to fully manage your vSphere environment. And as long as those are around, then yes, you will still need a vMA, even for those that think in Perl or PowerCLI 🙂
Duncan Epping says
Even without, typing code will always be more complicated than just firing off commands based on behavior of the problem.
But I agree there is a place for both, and it would be good if everything is exposed at some point and there would be cmdlets for every command out there.
Maish says
Ah Utopia!!!!!
Wil van Antwerpen says
Luc,
LOL, I’m not even trying to start that discussion. For the majority of my day to day work I’m a windows developer myself, so I don’t think that black and white.
For the record, I am platform agnostic, run most of the time on OS X. But I am on the opinion that every platform has its use and pros and cons, no OS is perfect.
Back on topic.
It would be nice if the esxcfg-* gap would be closed for powerCLI as well. It should be availabe in any scripting environment so that the person who wants to script it, can do so with ease without having to learn a new scripting language.
I think that vMA is a very useful tool for many. Having the choice on what to use is a good thing.
—
Wil
Brandon says
I see these conversations as some what religious, because people are going to use what they’re comfortable with. Multiple ways to do x thing is a staple of most enterprise products. Windows, linux, or ESX(i) or what have you. I always challenge people to get out of their comfort zone (learning something new is almost always good), and if you did have a major DR event and your local PC is shot to hell… maybe you’ll thank your lucky stars you had the vMA appliance in the VMware environment if you needed it? It’s tiny, why not be (overly?) prepared.
I usually save my vicfg-cfgbackup’s on there too :>.
Mattias Sundling says
Disclaimer: Quest employee behind the keys…
I have always preferred PowerGUI which combines the power of PowerShell scripting but with a GUI in front. Makes it very easy to use even though you have no PowerShell/PowerCLI knowledge at all.
Built-in PowerPack for VMware and you can extend it with additional PowerPacks such as: VMware Community PowerPack (amazing collection of scripts put together by the VMware Community, mainly Alan Renouf), AD, Exchange, SQL or any PowerShell enabled application/device.
I am not trying to sell you anything, it´s free to download and use!
Probably many on this thread using it, maybe you can chime in with some non biased thoughts?
/Mattias
William says
Here’s my 2cents … might turn out to be half dollar 😉
The comment that caught my attention was the following:
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.
@Maish, I had replied back on twitter but perhaps you missed it. I could have miss-understood this comment, but the way I read it is that there are more API objects exposed through PowerCLI and that is not 100% correct. The vSphere SDK for Perl which also includes vCLI (it’s just a marketing name, at the end of the day, it is Perl scripts created using the vSphere SDK for Perl), PowerCLI, VI Java, etc. all use and talk to the vSphere API which is the core API that is exposed as a webService. If you can speak SOAP and convert the vSphere API WSDL to a client side stub, you have access to _ALL_ exposed API properties/objects by VMware, end of story. Now, back to your statement, PowerCLI may “expose” more API objects than the default set of Perl scripts found in vCLI and the vSphere SDK for Perl, but that is not a limitation of vSphere SDK for Perl, but it’s a limitation on how much time VMware spent on these two scripting platforms. It’s not trivial, but anything you can do in PowerCLI, can be accomplished using vSphere SDK for Perl and vice-a-versa, they talk to the common API. Yes, you’ll need to understand the vSphere API to do so and be able to script/program based on the various SDK’s available today, but it’s not that one has more features than the other. As mentioned by Duncan, I have my vGhetto Script Repository which has scripts that utilizes functionality that is not exposed by default, just Luc/Alan has theirs WRT to PowerCLI.
One easy example which I believe still holds true today (please correct me if I’m wrong) is there is no PowerCLI cmdlet to enable Fault Tolerance for a VM, neither was there for vSphere SDK for Perl. Would you say PowerCLI is limited now? No, VMware just didn’t bother to create a cmdlet and I believe I was the first to write a script to automate this process using vSphere SDK for Perl (http://communities.vmware.com/docs/DOC-10279) I’m most certain this is a trivial task for Luc/Alan, but you need to understand the underlying APIs and that is not a trivial task by any means.
What’s being discussed here is sort of what we all had discussed about on the VMTN Community podcast this week and I think it’s some great discussion with various points of views. I want to start off and say, let’s not turn this into a Windows vs. Linux thing or who has a better scripting language/toolkit. Neither does, that’s the bottom line …. use the tool that fits the job/requirement or use with what you’re comfortable with.
I potentially see 3 types’ of categories:
1) Users that have worked on the Service Console since the early days of 2.x, 3.x, etc. who are extensively familiar with the esxcfg-* output and have either a strong Windows or UNIX/Linux background.
a) If you’re more comfortable with UNIX/Linux, then using vCLI/vMA may make more sense. Taking the transition from Classic ESX -> ESXi is not an easy task. By leveraging these familiar commands and familiar output, as Duncan mentioned, it’s _easier_ to migrate any bash scripts you may have already created. esxtop/resxtop is another valid point … yes with the release of the new 4.1 cmdlet, you now have esxcli/esxtop functionality, but you’ll need to learn it/etc. What if you’re not using 4.1? Well vCLI/vMA is still needed for things like resxtop
b) If you’re more comfortable with Windows, then you may use Powershell and PowerCLI and you’ll learn the in/outs to get the equivalence you once had with the Service Console, you can leverage both cmdlets and custom scripts/powerpacks written by both Luc/Alan to automate and manage your VI/vSphere environment. With the latest 4.1 cmdlets, esxcli/resxtop are no longer limited to only vCLI/vMA
2) Users that are completely brand new to managing vSphere, with a clean slate, you may go based completely on comfortable level of OS platform (Windows or Linux). If we’re just talking about administrators, you know there is a task that needs to get done and they want it done right away, no time to learn how it actually works. If you look at the VMTN posts, they’re filled with “How do I do X”, not many people will spend the time that we do to really understand the underlying implementation, nor should they. PowerCLI may provide that abstraction that is needed or vCLI may provide just enough to get a user started.
3) Enterprise development, this is not directly related to the current discussion, but here is where I would draw the line between scripting and writing an application. PowerCLI in my mind was not designed for this, it’s a scripting language and so is Perl. Both can do OOP, but what we’re really talking about is using things like vSphere SDK for C#/.NET or VI java/vSphere SDK for Java and the target audience is Developers, not Administrators or Operators.
Again, work with what you know and what you’re comfortable with. There is no right answer, but to answer Maish’s question, I would say it’s not “necessary” to have vMA to be able to manage your vSphere infrastructure, but it would be a nice to have, especially for those just starting out. Since vMA is distributed as a virtual appliance, you can import and start using it right away. It’s also great for consultants who can carry it with them on their laptop, certain places may have a “No Windows” policy, would you say I only know PowerCLI?
IMHO, VMware has not done a good job of educating the community on these topics and does sway more towards PowerCLI because of the user base and I think some of these notions that one language/toolkit is better than the other is partially VMware’s fault. I also think VMware has not put in the amount time in R&D to really have a solid platform agnostic automation framework and hopefully that’ll change as we move forward.
@Sean, “vifs” is actually part of vCLI installation which can be found in both the Windows/Linux vCLI installation and in vMA. The only difference is vCLI for Windows does not include resxtop, else vCLI is literally cross platform including Mac OSX
@Lucd, All vCLI esxcfg-* commands use public exposed APIs, you can see the souce if you open up the Perl scripts. I agree there are number of Private APIs (e.g. Enable EVC anyone? Been hidden since the early days of VI 3.5 and its still hidden), though this is really another topic all together 🙂
Maish says
Great comment William (and a lot more than $0.02)
I must have missed your comment from last night about the API.
Doug says
Not to hijack this topic any more than necessary, but when I worked in the VMworld scripting labs a few years ago, we offered a choice of Perl vs. PowerShell to the attendees. The team wrote all exercises in BOTH languages. No doubt, the PowerShell exercises were shorter and more easily understood if there were cmdlets explain the required functionality. If not, I quickly discovered that the scripts ended up looking awfully similar because direct API work was required.
As William points out, it all depends on what you are comfortable using. For me, PowerCLI is more interactive — due to the way it is implemented. I can write Perl that way, too, but I find it a lot easier to browse the API using PowerCLI.
Most people in the lab that year chose PowerShell, and we guided beginners that way due to the more in-depth understanding of the API required to use the Perl SDK. I still use both.
YP Chien says
Hi Duncan, you comment:
“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 command line 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.”, I fully agree.
But, I just want to point out that vMA is not “officially” supported by VMware. Last time, I had problems concerning the AD integration with vMA and filed a technical support, just to find out that vMA is not officially supported!
Gregory Perry says
The decision to implement one management method over the other is largely “user preference”.
With the release of vSphere 4.1, ESXi Support Mode is now an “officially supported” method of direct console or remote SSH (port 22) interaction with the “Mini Console Operating System” running on ESXi (a statically linked Busybox environment instead of the RHEL/CentOS COS environment inherent to ESX). The Mini COS, which is enabled under the support options on the ESXi console, provides almost the exact same functionality as traditional ESX, including the esxcfg- family of commands, expert tools such as vmkfstools and vScsistats, the ability to traverse through VMFS and NFS datastores under /vmfs, etc.
However, there are certain use cases where the vMA is required and no other management modality will suffice, namely the use of third party and proprietary software suites that require access to the host hardware and/or CIM providers for network management and hardware host management. One example of that would be hardware host management products along the lines of Dell OpenManage, which traditionally were developed to run on the legacy Service Console yet are unable to be retrofit into the ESXi Support Mode Mini COS or other management methods such as PowerCLI. Dell, like most other hardware vendors, have released those same management suites into vMA-based installs and are unlikely to do the same into the Mini COS based on the reduced development resources inherent to the Busybox environment.
So:
1) If you need quick and dirty access to the same functionality you are accustomed to using with the traditional ESX-based Service Console, the Mini COS abstracted through Support Mode on ESXi will likely provide everything you need including the esxcfg- family of commands and the /vmfs hierarchy.
2) If you need more advanced features and capabilities such as centralized logfile analysis and you are more comfortable with Unix/Linux-based CLI environments, or if your hardware vendor has redistributed a hardware management suite that needs access to CIM providers then the vMA is likely your only choice.
3) If you come from a largely Windows-centric administrative background, you will likely feel more comfortable using the PowerCLI or vSphere CLI on a Windows box, which has a comparable (if not more robust) feature set than the COS although one that requires the use of a mixed-mode Windows and Linux-based management environment.
My humble .02 pence.
Gregory Perry
http://www.GoVirtual.tv
Alan Renouf says
Lets make love not war – There is a use for both and as such VMware does the correct thing and provides users what they need – Both Perl and PowerShell access, even some support for them Java guys !
The more options the better, let people use what they are used to, just because I find PowerCLI easier it doesn’t mean that the next man will.
Preetham Gopalaswamy says
Seems like the discussions on this post are all happening on this site. So let me jump in for a bit. vMA is just a convenience provided by VMware. It is vCLI pre-installed in a Linux VM with a couple of additional advantages like an agent (Likewise) to connect it to an AD domain. We also threw in fastpass since we have some partners/customers asking for a way to cache their passwords on the client-side (since they were used to logging into the COS and running scripts there without a password). As people have already pointed out, there are lots of syslogd options out there and it is not necessarily a big draw. All the above (except fastpass) can be installed by customers in any environment they choose. So VMware is not forcing customers to use vMA at all.
Use it if it meets your needs. So the answer to the question – do we really need vMA is “No, you don’t NEED it. But it sure is nice to have for some users.”
People like William have leveraged it to great advantage. And hopefully others have and will as well.
Ernie Oporto says
Bravo. I for one am not eager to see VMware get rid of the service console’s UNIXy goodness in favor of PowerCLI.
Gregory Perry says
Hello again Duncan,
I posted a somewhat lengthy treatise on this subject last week which was verified as posted pending moderation.
It would appear the posting in question, which went into several new topics of discussion including the new support mode architecture and other areas of discussion were then censored from publication on your site, which is interesting.
Upon what guidelines do you make decision to censor posts to your weblog, and what type of companies are able to advertise on your site without the worry of blatant censorship in the same vein?
In each of our training classes we deliver and promote your new DRS/HA book and even sometimes bundle your book with our courseware kits as extra value ad. we would also be interested in talking with you about purchasing advertising space on your site, although it may appear that there is some silly conflict with TrainSignal or whomever else out there that is prompting you and your staff to censor post and/or comments on your site.
Anyway, please let me know if this type of behaviour is par for the course and what wen need to do to have technical articles that are submitted given the same credence and credibility as your other authors, as well as more information and a press kit for your advertising services. I belive we could end up providing twice the economical model of revenue for courseware sales from your weblog including up to 40% of the book value (our kit retails at 700 for the books and labs, with 600 for the hardware rental).
Or in the alternate, simply tell us that you would rather censor our posts and we would be happy to go our separate ways and no longer promote your books in the classes that we run, although I don’t don’t how much sense that would make really.
Cheers
[email protected]
Chief Executive Officer
GoVirtual Press LLC
Duncan Epping says
Before you start the accusing game did it ever occur to you that for what ever reason your comment might have been marked as spam by my spam plugin Akismet? I have over 600 spam entries every day and as Akismet is right in 99.999% of all cases I only scan these messages once every two weeks. Reason for this being of course the amount of work it requires and the fact that this is all done in my own time.
I do not censor any replies, that is if people reply in a respectful manner, and yellow-bricks.com is not abused to trash a competitor.
I can assure you that in no way or form Trainsignal has any influence on the comments or articles on this blog. I run this blog and a sponsor is a sponsor and not more than that, although I am of course thankful people are willing to help fund the costs associated with running yellow-bricks.
I hope you continue to keep promoting our book and if a situation like this occurs again you can contact me directly on [email protected].
Thanks,
Duncan Epping
Andrew Mitchell says
@Gregory Perry
I have worked with Duncan for a number of years now and can quite categorically state that Duncan is not one to censor his blog. I’ve even seen comments quite critical of Duncan’s view making it through, so to claim that Duncan is somehow showing bias is completely without basis.
The thing that you (and everyone reading this blog) need to keep in mind is that Duncan maintains the blog *IN HIS OWN TIME*. This is not something he is paid to do and, despite appearances, he does require the occasional time away from his PC to take care of other ‘little’ details, like his family.
Also – There is no ‘staff’. What you read here is all produced by Duncan. He’s not a company – just a single person maintaining a very professional blog.
Maintaining the blog and moderating the comments (which is unfortunately necessary due the amount of spam that appears) sometimes takes time – Please accept that fact.