Command line management has always been a big part of a vSphere management. Back in the earlier days of ESX, many used the service console for running scripts, typing commands, or using third party management tools. The introduction of ESXi killed the service console, and attempted to lock down command line management (many remember typing unsupported to gain access in the early days of ESXi), but eventually command line management also became a huge part of ESXi environments as well. Let’s take a look at some of our options within ESXi in version 5.5 and above, and ideas on how and when to use them.
ESXi Shell Access with SSH
Your first option for vSphere host command line management is to connect directly to an ESXi host using SSH. In Windows environments, the tool of choice is usually PuTTY. You may hear a VMware administrator say they are PuTTY-ing to a host, but they probably mean they are connecting with SSH. You can also use your server
So, once you’ve connected to the host, what can you do with it? You can run any of the esxcli and vicfg- commands (esxcfg- commands will work too) to troubleshoot and configure a host. You can also take advantage of utilities like esxtop and vscsiStats.
While this works for occasional use, it may not be the be all end all in your environment, especially if your environment is a large one. You are required to connect to each host individually, and while you can store sessions for re-use, it may not be the best choice if you have to preform the same task on 60 hosts (yeah, been there, done that, it wasn’t fun).
vSphere Management Assistant (vMA)
I like to think of this as ESXi shell access on steroids. Instead of having to connect to each host via SSH, you can ssh to the vSphere Management Assistant, often referred to as the vMA.
The vMA has a couple of options for authentication, allowing you to connect to hosts and vCenters using AD authentication or its own integrated fast pass authentication. Once you’ve used the
vifp addserver command to connect to your hosts of choice, it is as simple as setting your target with the
vifptarget command, and using the same types of commands you would use if you were connecting to the host via SSH from your management workstation. One important difference is that here, esxtop is run as resxtop.
The vMA can make it much easier if you need to do something like use esxcli commands to modify host settings. Since the vMA runs on a linux virtual machine, you have scripting options here that you don’t necessarily have directly connected to the host with SSH. You can use scripts to connect to multiple servers, as well as issue commands on multiple hosts, while you’re still limited to the host you have connected to when you are connected directly to the host.
While you can do a lot with esxcli and other commands at this level, there is one major component of a vSphere environment you can’t manage, and that’s distributed virtual switches. While you can edit uplinks, you won’t be able to create a new one, since the switch itself exists on the vCenter control plane, not the host one.
VMware vSphere Command Line Interface (vSphere CLI)
Think of the VMware vSphere Command Line Interface (vSphere CLI) as an installable vMA. You can install it on a Windows or Linux system. It can be a good choice if you are trying to create a system with management tools installed locally for your administrators. It provides the same features and functionality in a slightly different package. Personally I think I used the vSphere CLI once or twice, but it can be a key management tool for some environments.
These management tools use many of the same commands, with the esxcli commands being a key part of administration via these methods. There is one more command line tool that can be used with vSphere, and it is extremely powerful.
vSphere PowerCLI is a PowerShell add in with a vast number of commands to manage your vSphere environment. Besides using PowerCLI to check and set basic settings, you can write some pretty advanced and powerful scripts to configure your environment for you. For example, I could write a script to configure host networking every time I add a new host to my environment to ensure things are always configured consistently. I can take things one step further and use PowerCLI to apply a host profile to my new host as well. The beauty of a PowerCLI script is you can write it once, and use it over and over again. It can be an extremely useful tool in any environment, large or small. If you plan on using AutoDeploy in your environment, PowerCLI is an absolute must for creating and editing your images.
PowerCLI can take some getting used to, especially if you aren’t already familiar with PowerShell in a Windows environment. The good news is after PowerCLI’s quick installation, its relatively easy to get started, and there are lots of resources built right into PowerCLI to help you. If you’re looking to teach yourself some PowerCLI using some common tasks in a vSphere environment, check out the blog series I’ve started called Fumbling Through PowerCLI.
Since PowerCLI is based on PowerShell, it requires a Windows workstation for installation and use. While many usually connect to PowerCLI via vCenter, you can also connect directly to a host in the event your vCenter is not functioning. This makes PowerCLI one of the most versatile tools in the vSphere administrative arsenal.
The tools used to manage a vSphere environment will depend on a number of factors. First and foremost, is the skill set of the administrative staff. Those from a Linux background may choose to leverage something like the vMA, while those with a Windows background may choose to use PowerCLI. Whatever the task, there’s a vSphere command line tool that is up for the job.