As a systems engineer with more than a few years under my belt, one of my concerns -- aside from unattended workstations with no screen lock -- is an admin doing tedious operations by mousing around and typing instructions interactively at a keyboard. What's wrong with this picture, you say? Well, there's a lot wrong with it, and I'll tell you why. But first, here are some givens when it comes to VMware administration:
- our jobs are very detail-oriented;
- repetition induces human error; and
- no matter how fast you can provide input, the computer is faster.
I think you will all agree that the above statements hold true in every situation that a computer operator faces, no matter the task, right? Let's get back to my scenario and why it should bother you. The key is automation, or the lack thereof.
Humans make computers to solve our problems. Generally speaking, you start with a developer (who is sometimes the cause of problems—but don't let me get off topic), and that developer aims to solve problems by giving low-level instructions to the computer to produce a tool that others can use at a higher level to interface
A popular assumption is that system administrators require only the highest level of interfaces, and all of the guts are hidden away behind pretty graphical user interfaces (GUIs). Let's take the vSphere client, for example. I love the application; it works well and gets the job done. But what if you need to change the port group assignments on a dozen virtual machines? I'll do the math for you. It takes six mouse clicks per virtual machine, for a total of 72 mind-numbingly tedious clicks of the mouse. That kind of repetition can and often will introduce human error. And no matter how fast you can click, it takes time for your eyes to track a GUI control and to tell your brain to move your hand to direct the mouse to the appropriate location. All it takes is for one of those clicks to miss by a few pixels, and you have selected the wrong network.
I think you can see where I'm going here. There has got to be a better way! There is, of course; and it's called PowerCLI.
What is PowerCLI?
Let's assume, for the moment, that you aren't some Perl-loving hippie. (Kidding!) Anyway, if you use Perl today to manage your vSphere environment, you won't be impressed by the concept of automating repeatable processes using a scripting language, and that's fine. What you will be impressed by, however, is the brevity and simplicity of what I am about to show you, so read on.
Before getting into PowerCLI, you must first know a thing or two about PowerShell. PowerShell is an object-oriented scripting language and command shell designed by Microsoft to succeed VBScript and the old CMD.EXE shell. It's object-oriented (which I'll define in a minute), which is a great way to interact with other object-oriented systems such as a virtual infrastructure. (A virtual machine is an object, as is a host server.) Unlike VBScript, PowerShell is a shell, which means you can run it and issue commands interactively.
But most important, PowerShell is a scripting language. A scripting language is similar to a programming language --you provide instructions in the form of text, and the computer goes off and does things for you. Unlike a programming language, a scripting language is intended to be a relatively high-level interface with a computer, so programmers can worry less about theoretical concepts. In other words, scripting fits between programming and a GUI. As such, it's ideal to be the glue between the two, or between different components in a complex IT environment. (PowerShell is also a tasty dessert topping—and a floor wax.)
OK, enough back story! PowerCLI is an extension of PowerShell. The PowerCLI "snap in" comes with 165 cmdlets (pronounced command-lets) as of this writing, each one encompasses a single vSphere administrative task into a bite-sized chunk. Cmdlets use a logical verb-dash-noun naming convention which is very easy to learn and discover. Let me show you what I mean.
Show me the money
Let's briefly explore the decidedly programmer-centric phrase, "object oriented". Objects are things like cars, houses, and virtual machines. Objects have members which consist of (among other things), methods and properties. Some examples of methods are "accelerate the car," "open the door of the house" and "start the VM." Some properties: "320 horsepower," "five bedrooms", and "two gigs of RAM." With me so far?
One of the simplest PowerCLI examples, and something which is actually extremely useful on its own, is the Get-VM cmdlet. Here's what it looks like in action:
As you might've guessed, you cannot interact with your vSphere environment without first connecting to it and authenticating. That is taken care of by the Connect-VIServer cmdlet. What you don't see in this transcript is that once executed, this cmdlet will prompt you for credentials.
After a connection is established, I typed Get-VM by itself with no parameters. "Get" in this case is the verb portion of the cmdlet name, and it means to retrieve objects from somewhere. "VM" is the noun portion of the cmdlet name, and that of course refers to a virtual machine. The output is pretty simple to understand, and that, too, is a hallmark of PowerShell. You can see a table header with the property names going across the screen. If you've ever worked with a virtual machine, I think these properties are all self-explanatory, so I won't go into further detail.
Each line of text that follows isn't just a line of text. It's also representative of an object. In this case, we're talking about virtual machine objects, but this principle applies to everything in PowerShell, whether we are talking about FileInfo objects from your file system, or virtual machines, or host servers, or whatever.
That last bit about everything being an object is a pretty big topic, so I'll stop there. In the meantime, I hope that you've learned enough about PowerCLI to be intrigued and to continue learning. I also hope that you agree that automation is the only way to go and that if you or your team is not on already on this bandwagon, now is a great time to hop aboard. My upcoming columns will build on this one, so watch out for those.
Hal Rottenberg is a Microsoft PowerShell MVP and VMware vExpert living in Woodstock, Georgia. He is well-known in system administrator circles for co-hosting the PowerScripting Podcast and heading up the PowerShellCommunity organization. He is also the author of a book titled Managing VMware Infrastructure with PowerShell: TFM published by SAPIEN Press in 2009.
This was first published in October 2009