In the following sections, we are going to cover a brief background of PowerShell and PowerCLI and the latest changes in both of them. First, I am going to talk about PowerShell and then PowerCLI.
The need for computers came into existence for two purposes: the first purpose was to do number crunching fast and accurately, and the second and most important purpose was to automate tasks. In this age of cloud computing, automation is the most used word and one of the basic characteristics of cloud. From the beginning of the data center age, system administrators started automating their daily repetitive tasks so that they would not have to do the same tedious tasks again and again. Also, the purpose of automation was to avoid human errors that may creep in while writing long instructions or repetitive commands.
Now, the question that comes to mind is how can we automate? There are so many ways in which we can automate a task (ask any developer). For a general system administrator, who is not a developer, there are some basic weapons from which they can choose. But the most basic and widely used method for any system administrator is to use Shell scripts. For any operating system, a Shell is the interface through which you can interact with the operating system. Traditionally, we have used Shell scripts to automate mundane work of daily life and tasks that do not require very extensive programming. Unix and Linux operating systems provide many Shells, such as Bash Shell, C Shell, KORN Shell, and so on. For the Windows environment, we have command.com (in MS-DOS-based installations) and cmd.exe (in Windows NT-based installations). Before we start talking about more advanced ones, let's take a look at scripting and its history.
In general, a scripting language is a high-level programming language that is interpreted by another program at runtime rather than being compiled by the computer's processor as other programming languages are. The first interactive shells were developed in the 1960s and these used Shell Scripts that controlled the running of computer programs in a computer program, the shell. It started with Job Control Language (JCL), moving to Unix shells, REXX, Perl, Tcl, Visual Basic, Python, JavaScript, and so on. For more details, refer to https://en.wikipedia.org/wiki/Scripting_language.
Traditional shell commands and scripts are best suited for command-line-based tasks or console-based environments, but with the advent of more GUI-based servers and operating systems, there is a greater need for a tool that can work with the more sophisticated GUI environment. This particular requirement has become more prominent for the Windows environment since Windows shifted its core from MS-DOS implementations to the NT-based core. Also, traditionally, Windows provided batch scripts in terms of basic scripting functionality, which was not enough for its GUI-based environment.
To solve the situation and comply with the updated environment, Microsoft came up with a novel solution in the form of PowerShell. It is more of a natural progression of the traditional shell in the advanced operating system environment. It is the one of the best and most powerful shell environments I have worked with. Now, more and more serious development is going on in this tool. Today, this has become so important and mainstream that all the major virtualized environments support their general operations being automated through this environment.
The major difference between the traditional Shell and PowerShell is that traditional Shells are inherently text-based; that is, they work on texts (inputs/outputs), but PowerShell works inherently on objects. So, PowerShell is far more modern and powerful than other Shells. Since it also supports and works on objects rather than texts, let's perform tasks, which were not possible with the earlier Shell Scripts.
Windows PowerShell supports running four types of commands:
Cmdlets that are native commands in PowerShell (basically, .NET programs designed to interact with PowerShell)
PowerShell functions
PowerShell scripts
Other standalone executable programs
At the time of writing this book, the latest stable version of PowerShell is 4.0 and Microsoft released a preview version of PowerShell 5.0 (Windows Management Framework 5.0 Preview November 2014). A few of the new features in this preview version are as follows:
The most important addition from the programming perspective is the added support for classes. Like any other object-oriented programming language, you can now use typical keywords, such as
Classes,Enum, and so on.A new
ConvertFrom-Stringcmdlet has been added that extracts and parses the structured objects from the content of text strings.A new
Microsoft.PowerShell.Archivemodule has been added that will allow you to work on the ZIP files from the command line.A new OneGet module has been added that will allow you to discover and install software packages from the Internet.
Note
For details of a list of the enhancements, you can check the documentation from Microsoft at https://technet.microsoft.com/en-us/library/hh857339.aspx.
VMware PowerCLI is a tool from VMware that is used to automate and manage vSphere, vCloud Director, vCloud Air, and Site Recovery Manager environments. It is based on PowerShell and provides modules and snap-ins of cmdlets for PowerShell.
Since it is based on PowerShell, it provides all the benefits of PowerShell scripting, along with the capability to manage and automate the entire VMware environment. It also provides C# and PowerShell interfaces to VMware vSphere, vCloud, and vCenter Site Recovery Manager APIs.
Generally, PowerCLI has the following features:
It is aimed toward system administrators.
It is installed on a Windows machine (client or server) as PowerShell snap-ins and modules.
It is supported at a low level (1:1 mappings of API) and high level (API abstracted) cmdlets.
No licenses are required to use it. It comes free.
At the time of writing of this book, VMware released PowerCLI 6.0 R1. The major new features of this release, among others, are as follows:
PowerCLI 6.0 R1 is backward compatible with vSphere 5.0 and the versions are up to 6.0.
Now, in this version, support for vCloud Air has been added. We can now manage the vCloud Air environment from the same single console.
User guides and 'getting started' PDFs are included as part of the PowerCLI installation.
PowerShell V3 and V4 are supported.
The VSAN support has been added.
The vCloud Suite SDK access has been added.
IO Filter Management can be done.
Hardware Version 11 management has been added.
Traditionally, PowerCLI provided two different components: One for managing the vSphere environment and another for the vCloud Director environment. With this release, there is no separate module for tenants. Now, a single installation package is provided, and at the time of installation, you have the option to install both the components (vSphere PowerCLI and vCloud PowerCLI) and only vSphere PowerCLI (vCloud PowerCLI is an optional component).
Earlier, PowerCLI had two main snap-ins to provide major functionalities, namely, VMware.VimAutomation.Core and VMware.VimAutomation.Cloud. These two will provide the core cmdlets to manage the vSphere environment and vCloud Director environment. In this release, to keep up with the best practices of PowerShell, most of the cmdlets are available as "modules" instead of "snap-ins". So, now in order to use the cmdlets, you need to import the modules into your script or into the Shell. For example, run the following code:
Import-Module 'C:\Program Files(x86)\VMware\Infrastructure\vSphere PowerCLI\Modules\VMware.VimAutomation.Cloud'
This code will import the module into the current running scope and these cmdlets will be available for you to use.
Another big change, especially if you are working with both the vCloud Director and vSphere environment is the RelatedObject parameter of vSphere PowerCLI cmdlets. With this, now you can directly retrieve vSphere inventory objects from cloud resources. This interoperability between the vSphere PowerCLI and vCloud Director PowerCLI components makes life easier for system admins. Since any VM created in vCloud Director will have an UUID attached to the name of their respective VMs in the vCenter server, so extra steps are necessary to correlate a VM in the vCenter environment to its equivalent vApp—VM in vCloud Director. With this parameter, these extra steps are no longer required.
Here is a list of snap-ins and modules that are part of the vSphere PowerCLI package:
