VMware vMA features

The vMA is an appliance based on SUSE Linux. It is designed to consolidate vSphere administrative tasks. Here is a brief introduction of vMA features:

• vSphere SDK and CLI: You can use CLI to add vCenter Server and vSphere hosts as vMA targets to perform different kinds of operations by running scripts and programs. Adding a target can authenticate you, so you do not require to authenticate against vCenter Server or vSphere hosts when you run an agent or a vSphere CLI command on any of the targets. Do not confuse CLI with PowerCLI, the vSphere PowerShell implementation.
• Using vSphere SDK API: You can use the vSphere APIs shipped with vMA to program and to connect to vMA targets programmatically. VMware vMA provides the VmaTargetLib library that supports utilization of the API using Perl and Java. You can run agent code using vMA on different software modules and on different hardware supported by VMware ESX. At the time of writing this book, the code can be run only in the CLI of existing vSphere hosts. This agent code can be modified and can be utilized in the vMA appliance by calling the vSphere API.
• Authentication with vi-admin and vi-user: The vMA appliance can run agents or scripts that otherwise interact with vCenter and ESX(i) servers without repeated authentication. You can reutilize vMA service console scripts that are presently used for the vSphere host's administration. However, slight changes to the scripts are usually required. vMA comes with two users by default, named vi-admin and vi-user. To perform all the administrative tasks, for example, addition or removal of hosts, running vSphere CLI commands, agents on the added targets, you will require the user vi-admin. To run vSphere CLI commands and agents with read-only privileges on the added targets, you will use vi-user.
• Active directory single-sign-on: vMA is also capable of joining the MS Active Directory (AD) domain, and you can use AD user to log in to vMA. This allows you to assign consistent and fine granular privileges to users on the vCenter Server system or the vSphere host, thus enabling users to run the commands accordingly.
• Vi-logger: The vMA can collect logs from each of these server types for analysis. This is through a component on the vMA called vi-logger.

The vMA consists of the following components:

• SUSE Linux Enterprise Server 11 SP1 64-bit: vMA has recently moved to SUSE Linux. Previous versions of vMA were all built on top of Red Hat—either Red Hat Enterprise Linux or CentOS—but with the release of vSphere 5, all virtual appliances have been migrated to SUSE Linux Enterprise Server 11.
• VMware Tools
• vSphere CLI
• vSphere SDK for Perl
• Java JRE 1.6
• vi-fastpass: This refers to the authentication component of vMA.

Powering-on vMA

You must configure vMA when it boots for the very first time. To do so, power on the virtual appliance. Right-click on the vMA appliance and click on Open Console.

You will be presented with a screen prompting for network configuration. To configure network options, you must answer the prompts.

You can also specify the host name for your vMA appliance using one of the prompts. vMA allows you to have 64 alphanumeric characters in the host name.

You must configure a password for vi-admin. Answering the password prompt, you must enter your old password first; it will then prompt you to type in a new password. The new password must be able to comply with the vMA password policy, that is, password should be at least eight characters long. It must contain one upper case character, one lower case character, one numeric character, and one symbol.

Note

The default password of vi-admin for VMware vMA is vmware.

AD integration

By default, a vMA appliance comes with PowerBroker Identity Services – Open Edition, formerly known as Likewise Open, to support Active Directory integration. PowerBroker Identity Services uses Pluggable Authentication Modules (PAM) and Name Service Switch (NSS). It supports Kerberos, NTLM, and SPNEGO authentication. You can type the following to join your vMA with an AD domain controller:

sudo domainjoin-cli join FQDN domain-admin-user
sudo domainjoin-cli join linxsol.com zeeshan

The preceding command uses the Likewise Open's domainjoin-cli script using the join flag, followed by the MS AD controller FQDN and the user name of the user who has administrative rights to join computers to AD. Once you enter this, it will prompt you for a password. Enter the password, and you will see a success message appearing in your console. You can also check the status of your server to see if it has integrated with a domain controller by running the following script:

./lw-get-status

The script can be found in the /opt/likewise/bin directory. You can also check the status of your vMA appliance and AD integration by typing the following command in the console:

sudo domainjoin-cli query

Either you can append the full path before running the script or you can go to the preceding directory and run the script. The likewise identity service ships up with a lot of different scripts to manage AD integration. You can remove vMA from the domain by running the following command in the console:

sudo domainjoin-cli leave

The vMA console displays a message stating whether vMA has left the AD domain.

The BeyondTrust website maintains excellent documentation and a community wiki about PowerBroker Identity Services. For more information, please visit http://www.beyondtrust.com/Resources/OpenSourceDocumentation/.

Tip

The vMA host name can be changed anytime. Changing the host name is similar changing it in a Linux host: you only need to modify the /etc/HOSTNAME and /etc/hosts files. You can also change it from the vMA console by typing the command 'sudo hostname new-name'.

AD unattended access

We will use the ktpass tool to configure the principal name of the vMA appliance for the service in Active Directory Domain Services (AD DS). The process will create a .keytab file containing the shared secret key of the service. The .keytab file that is generated by the ktpass tool is based on the Massachusetts Institute of Technology (MIT) implementation of the Kerberos authentication protocol. The Ktpass command-line tool authorizes Linux- or UNIX-based services that support Kerberos authentication to use the interoperability features provided by the Kerberos Key Distribution Center (KDC) service.

In the subsequent example, you will learn to create a Kerberos .keytab file called machine.keytab in your current working directory for the user Sample1. (You will merge this file with the Krb5.keytab file on a host computer that is not running the Windows operating system.) The Kerberos .keytab file will be created for all supported encryption types for the general principal type.

To generate a .keytab file for a vMA appliance, use the following steps to map the principal to the account and set the host principal password:

1. Use the Active Directory Users and Computers snap-in to create a user account for a service on a computer that is not running the Windows operating system. For example, create an account with the name User1.
2. Use Ktpass to set up an identity map for the user account by typing the following in the command prompt:

   ktpass /princ host/[e-mail] /mapuser User1 /pass MyPas$w0rd /out User1.keytab /crypto all /ptype KRB5_NT_PRINCIPAL /mapop set 
   

   Here, linxsol.com is the name of the domain and User1 is the user who has permissions for the vCenter administration. Now you have a file called User1.keytab file. Copy the file to /home/local/linxsol.com/User1. You can use WinSCP and log in as user linxsol.com\User1 to move the file.

3. You can type the following in console to make sure that the user linxsol.com\User1 on vMA has the ownership of the User1.keytab file:

   ls -l /home/local/linxsol.com/User1/User1.keytab
   
   chown 'linxsol.com\User1' /home/local/linxsol.com/User1/User1.keytab
   

   You should mind the quotes around linxsol.com\User1 so that bash interprets them as a string.

4. Create a cron job for the .keytab file so that it can renew the ticket every hour for [e-mail]. On vMA, create a script in /etc/cron.hourly/kticket-renew with the following contents:

   #!/bin/sh
   
   su – 'linxsol.com\User1' -c '/usr/bin/kinit -k -t /home/local/linxsol.com/User1/User1.keytab User'
   

5. You can also add the preceding script to a service in /etc/init.d to refresh the tickets when vMA is booted.

vMA web UI

The web UI allows you to manage the vMA appliance. It does not enable you to manage the vCenter and vSphere hosts from the web interface. You can access the web UI by pointing your browser to https://<vma_address_or_hostname:5480 and logging in as vi-admin. The web interface enables you to perform a system reboot or shutdown. You can check the status of the vMA appliance, set its time zone, and update it to the latest version. In previous versions, you were able to use vma-update, but now this functionality has been migrated to the web interface. You can also use the web interface to update the network address setting (IP address, HTTP Proxy) of the vMA appliance.

vi-user

The vMA appliance comes with a built-in user called vi-user. This user cannot be used until you reset its password. By default, it does not have any password. The vi-user user has read-only privileges on the target systems. It also exists on all the target systems by default, regardless of whether you enable it in your vMA appliance or not. You can log in to your vMA appliance by using vi-user, but you will only be able to run the commands on target systems that do not need administrative permissions. The vi-user user is limited to run commands only against the vSphere hosts that set up with vi-fastpass authentication (we will discuss fpauth and adauth later in the chapter). The vi-user user cannot be used to run commands against systems authenticated against AD. It is also unable to run any commands as sudo. You can change its password as you change it in Linux normally, by typing the following command in vMA console:

sudo passwd vi-user

Type the new password for vi-user and confirm it once prompted.

Configuring vMA as a syslog server

A centralized syslog server can save you a lot of troubleshooting efforts. For example, if a remote system crashes, you might lose all the important logs within that remote system, which could help you to troubleshoot issues with the remote system. If you log into a centralized logging system, it can provide you with the most recent logs of that remote system before the system crashed.

We will now walk through how to configure the vMA appliance as a syslog server to centralize logging for vSphere hosts. When vMA collects the logs from your vSphere host, sometimes the logs have the vSphere host timestamp, and sometimes they will have the vMA Localtime timestamp.vSphere host, which uses UTC as its time zone while time stamping the logs. You can avoid the issue of timestamp difference in the logs by changing the local time on the vMA to UTC, with the following command:

sudo rm /etc/localtime

sudo ln -s /usr/share/zoneinfo/UTC /etc/localtime

You can also set up NTP servers in your vMA appliance to sync your environment's time. To do so, run the following commands in the shell:

sudo zypper in ntp yast2-ntp-client  #It will install ntp client

sudo vi /etc/ntp.conf 

Add in your NTP servers under the heading # Use public servers from the pool.ntp.org project. Configure ntpd to start on reboot:

sudo /sbin/chkconfig ntpd on

Now you can start the ntpd service:

sudo /sbin/service ntpd restart

Make sure your NTP servers are reachable:

sudo ntpq -p

Log files usually grow large in size; you should always consider well your disk space requirements. It is always recommended that you place all of your logs on a separate disk drive.

You should add an additional disk to the vMA appliance where the logs will be stored. If your VMware infrastructure consists of a large number of servers, you should allocate a big enough disk for that.

After hot-adding the disk to the VM, rescan the SCSI bus of the OS in the usual GNU/Linux way to see the disk. You need to become root to perform this action; otherwise you will get Permission Denied error:

vma:/home/vi-admin # echo "- - -" > /sys/class/scsi_host/host0/scan
 vma:/home/vi-admin # fdisk /dev/sdb
 Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
 Building a new DOS disklabel with disk identifier 0x03e0767d.
 Changes will remain in memory only, until you decide to write them.
 After that, of course, the previous content won't be recoverable.
 
 Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
 
 Command (m for help): n
 Command action
    e   extended
    p   primary partition (1-4)
 p
 Partition number (1-4, default 1): 1
 First sector (2048-209715199, default 2048):
 Using default value 2048
 Last sector, +sectors or +size{K,M,G} (2048-209715199, default 209715199):
 Using default value 209715199
 
 Command (m for help): p
 
 Disk /dev/sdb: 107.4 GB, 107374182400 bytes
 255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x03e0767d
 
    Device Boot      Start         End      Blocks   Id  System
 /dev/sdb1            2048   209715199   104856576   83  Linux
 
 Command (m for help): w
 The partition table has been altered!
 
 Calling ioctl() to re-read partition table.
 Syncing disks.
 vma:/home/vi-admin # mkfs.
 mkfs.bfs     mkfs.cramfs  mkfs.ext2    mkfs.ext3    mkfs.ext4    mkfs.minix
 vma:/home/vi-admin # mkfs.ext4 /dev/sdb1
 mke2fs 1.41.9 (22-Aug-2009)
 Filesystem label=
 OS type: Linux
 Block size=4096 (log=2)
 Fragment size=4096 (log=2)
 6553600 inodes, 26214144 blocks
 1310707 blocks (5.00%) reserved for the super user
 First data block=0
 Maximum filesystem blocks=4294967296
 800 block groups
 32768 blocks per group, 32768 fragments per group
 8192 inodes per group
 Superblock backups stored on blocks:
         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
         4096000, 7962624, 11239424, 20480000, 23887872
 
 Writing inode tables: done
 Creating journal (32768 blocks): done
 Writing superblocks and filesystem accounting information: done
 
 This filesystem will be automatically checked every 28 mounts or
 180 days, whichever comes first.  Use tune2fs -c or -i to override.

Create a directory where the logs will be stored. I used /var/log/esxi-syslog/ and mounted the fresh partition to this location: vma:/home/vi-admin # mkdir /var/log/esxi-syslogvma:/home/vi-admin # mount /dev/sdb1 /var/log/esxi-syslog. To automatically remount the partition at boot time, add the following line to /etc/fstab: vma:/home/vi-admin # echo "/dev/sdb1 /var/log/esxi-syslog ext4 acl,user_xattr,noatime 1 1" >> /etc/fstab.

If you do not configure the preceding line in your fstab file, you will always need to mount your drive manually after rebooting your host.

The vMA syslog configuration file can be found at /etc/syslog-ng/syslog-ng.conf. The default options usually satisfy most of the requirements for logging. The file is self-explanatory, and you can read it to tune your log server configuration.

sudo service syslog restart

Creating a logrotate file

It is a common practice to rotate logs on Linux systems. You can create a logrotate file to compress and rotate the log files. Use vi or a text editor of your choice to create a file in /etc/logrotate.d to rotate and compress logs from /var/log/esxi.

vma:/home/vi-admin# vi /etc/logrotate.d/esxi-log.conf
var/log/esxi/*.log {         weekly         missingok         rotate 6         compress                 delaycompress         notifempty         nocreate         sharedscripts         postrotate                 /etc/init.d/syslog reload         endscript }

The configuration file is self-explanatory: the first line tells logrotate utility to rotate the log weekly. The second line tells it to keep the six log files. The compression will be for all files except the last rotated log.

The vMA authentication mechanism

The policy found in vMA is a credentials caching mechanism that allows us to connect to ESX(i) or vCenter servers. The mechanisms are of the following two types:

• Fast Pass Authentication (fpauth)
• Active Directory Authentication (adauth)

The fpauth essentially allows us to manage a vSphere host or vCenter Server under vMA by using a vi-admin and vi-user account. The vMA appliance uses a XOR cipher to obfuscate the passwords of both accounts. Once you are authenticated against target vSphere hosts or vCenter, you can start managing targets and execute either vCLI or vSphere SDK for Perl scripts without specifying credentials every time. That is why it becomes much easier to run a single command against a large number of hosts. In previous releases of vMA, adauth was used. You can authenticate against vSphere hosts and vCenter using your Windows AD credentials. I have previously described how we can join vMA with an AD attended or unattended. It requires your vSphere target hosts and vCenter to be already members of AD domain.

As we have already configured it, we only need to add target hosts to our vMA appliance to execute vCLI cmdlets or the perl scripts provided by vSphere SDK. These credentials remain saved within vMA until you log out or reboot your vMA appliance. Using adauth is much more secure than using fpauth and I would recommend you to use adauth whenever it is possible for you.

We are ready to start adding hosts in our newly installed vMA appliance. I will describe instructions for setting up and verifying both standard fpauth and adauth.

Accessing systems from vMA

Let's add our first vSphere host to our vMA appliance. We will use adauth to add a vCenter Server system as a vMA target.

Log in to vMA as vi‑admin. Add a server as a vMA target by running the following command:

vifp addserver crimv1vcs001.linxsol.com --authpolicy adauth --username linxsol\\zeeshan

The command is self-explanatory here. The addserver directive requires the vSphere host or vCenter name to be added, and the authpolicy directive requires the authentication mechanism to be used. In this case, I have used AD Authentication. I will show you later how to use fastpass to add target servers. If you do not use authpolicy directive in the command, vMA appliance uses the fastpass authentication by default. The username directive is optional that takes an authorized AD user name to authenticate. If you do not specify it, vMA will prompt you for the AD authorized user name for the vCenter.

We can verify whether the vCenter system has been correctly added to the vMA appliance by running the following command:

vifp listservers --long
crimv1vcs001.linxsol.com                vCenter     adauth

Let's add one of the vSphere hosts using fpauth to the vMA appliance:

vifp addserver crimv3esxi002.linxsol.com --authpolicy fpauth

It will prompt you for the root user password of that vSphere host. Let's verify our hosts in the vMA appliance:

vifp listservers --long
crimv1vcs001.linxsol.com              vCenter   adauth
crimv1esxi001.linxsol.com             ESXi       adauth
crimv1esx002.linxsol.com              ESXi       fpauth
crimv1esx003.linxsol.com              ESXi       adauth

Before we can run the vCLI commands against any of the hosts, we need to set it up as a target. Run the following command to set the target server (vifptarget --set | -s <server>):

vifptarget --set crimv1esx001.linxsol.com

Verify that you can run a vSphere CLI command without authentication by running a command on one of the vSphere hosts. The following command will not ask you for the credentials; instead, it will use the authentication mechanism to verify against the AD Domain:

esxcli --server <VC_server> --vihost <esx_host> network nic list

You can easily remove the target by using the following command:

vifp removeserver crimv1esx001.linxsol.com

Now you are ready to use the vMA appliance to manage VMware infrastructure. I will cover more practical examples in the coming chapters.

vMA scripts samples

You can find different scripts written in Perl and Java in your vMA appliance. These scripts are easy-to-use examples that show you how you can modify VmaTarget.login() method according to your target host. You can find these scripts in /opt/vmware/vma/samples. For code samples in Java, you can browse /opt/vmware/vma/samples/java, and for Perl, you can browse /opt/vmware/vma/samples/perl. In the perl directory, you can find three scripts and a README file: bulkAddServers.pl, listTargets.pl, and mcli.pl. The README file contains all the information you are required to run these scripts. I will walk you through a brief description of what these scripts can do for you. The bulkAddServers.pl can add multiple vSphere hosts to your vMA appliance in bulk. The script can read the host names from a text file provided by you or you can pass the vCenter Server host name in the arguments when executing the script. The listTagets.pl script can collect different information about your targets, for example, versioning. The last script mcli.pl can be used to run a single command on different vMA target hosts. You can provide a text file or pass the host name to the script in an argument.