Latest posts by Jim Jones (see all)
- Removing a corrupted Canon print driver - Fri, Apr 8 2016
- VMware vSphere licensing update 2016 - No love for the little guy - Fri, Mar 25 2016
- Veeam releases free Endpoint Backup 1.5 - Fri, Mar 18 2016
For many older VMware admins who were used to having the ESX console available prior to vSphere 4.1, the loss of the Service Console was traumatic. In the SC, you maintain scripts, install custom software packages for security, storage, or other things, and execute just about any command you wanted to automate your host operations. While you could turn on Tech Support Mode in ESXi (which many do), it has never been something that was advised; in fact, your hosts will nag you by default as long as you have it on. The vSphere Management Assistant sprung from this CLI need, essentially serving as a remote, centralized Service Console for your ESXi hosts.
For followers of the idea of “Automate All the Things” (HT vBrownbag), you now have a single location from which you execute commands on multiple hosts at a time. As an example, imagine that you’ve recently added a new LUN to your existing iSCSI storage array. With the GUI Client, you would have to go to the configuration of each host, find your iSCSI adapter and rescan, and then move to the next host and repeat. With vMA, you can easily write a small script to connect to a host, issue the “esxcli storage core adapter rescan –a” command, and then move to the next host in line—DONE. Not a big deal with a couple of hosts, but a very big deal as you scale your infrastructure. There is very little you cannot access via the CLI in configuring and monitoring your ESXi hosts.
Basic deployment ^
Deployment of the vMA is like any other Virtual Appliance. In the VI Client (or in the Web Client, if you are into S&M), go to File > Deploy OVF Template. You’ll need to supply the name of the downloaded and extracted OVA file and then follow the prompts supplying the necessary storage and network information as you go.
Deploy OVF Template
Once your VA is deployed, you will have to do a few tasks when you first log in. These include setting up the basic network settings and setting a password for the vi-admin account. While the vMA is a Suse Linux box at heart, there are really only two accounts you need to deal with. Vi-admin is the read-write account to the system that allows you to manage hosts and servers and execute commands, whereas the vi-user account (disabled by default) is read-only, just allowing you to access and execute commands on hosts and servers already added to the vMA.
Domain join ^
The exception to the two-user rule is if you next add your vMA VM to your existing Windows Domain. In this case, the vi-admin role remains the same once it’s added, but you can now log in with your Windows credentials and have equivalent access to that of vi-user, but with better logging.
Setting up Domain Join is relatively painless. From the vi-admin prompt, you simply enter:
sudo domainjoin-cli join [domain] [user with domain add rights]
sudo domainjoin-cli join domain.local administrator
You will then be prompted for your domain password, and you will need to reboot the VM after getting a success message.
Adding fpauth servers ^
Now that you’ve got all the basics set up, let’s get some hosts set up so you can start interacting with them. There are two methods of providing authentication for your hosts as you add them. Fastpass, the default, uses local authentication that is cached to the vMA VM upon adding. The second is authenticating against Active Directory; however, this will only work when adding vCenter or hosts that are joined to the domain. For the most part, you’ll want to start with fastpass; it really is very simple. To add a server with IP 192.168.1.100 this way, you simply need to enter this command:
vifp addserver 192.168.1.100
You will be prompted to enter the root password for the host. Those credentials will then be stored for you locally.
Adding adauth servers ^
Fastpass authenticated servers are great, but the drawback is that the credentials are stored and can, in theory, represent a security hole because you may be granting access to too much. The better way forward is to use an Active Directory authentication policy as you add your servers, as long as the host or vCenter you add is a member computer of AD. This is a little more work but still very doable. The command is:
vifp addserver 192.168.1.100 –authpolicy adauth –username DOMAIN\\user
Again, you’ll be prompted for a password, but in this case it will be the credentials assigned to the supplied AD user. On the upside, these are not stored locally and will be checked against AD each time. I recommend picking one of the authentication methods and using it throughout. Some of the automation type stuff gets weird when you use hosts of both types in the same script.
Setting target and executing CLI commands ^
Now that you have added some hosts, you’ll want to start using them. If it’s been a while, you can start by seeing what hosts you’ve already added by using the vifp listservers –l command. This will return all the servers and their authentication policies. In a one-off scenario where you just want to issue a command on a single server, you will need to make a connection first. Connections to hosts are done by using the vifptarget command. For example:
vifptarget –s 192.168.1.100
Once connected, you can use any command available in the vSphere 5.5 CLI Reference guide. For example, to get a list of all available NICs on our test host, the full method would look like the image below. For more advanced tasks, take a look at the sample mcli.pl script provided in the /opt/vmware/vma/samples/perl directory. This script allows you to issue any command to a list of hosts supplied in a file.