SmartCloudMonitoring Trial 7.2 FP2

IBM SmartCloud Monitoring 7.
2 FP2 Trial
Instructions
Ben Stern
Executive IT Specialist, Best Practices for Cloud and Virtualization Monitoring
bstern@us.ibm.com
Copyright International Business Machines Corporation 2014. All rights reserved.

US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
The most recent version of this documentation is maintained on the following website. In
addition, you will find additional information including videos, product documentation
and more:
https://ardent.rtp.raleigh.ibm.com/developerworks/downloads/tiv/smartcloudmonito
ring/index.html
The IBM Smart Cloud Monitoring Trial is a virtual appliance that can be setup quickly in a
virtualized environment. This image includes IBM Smart Cloud Monitoring version 7.2
FP2. The image is provided as an OVF image that can be used with VMware and other
hypervisors that support the OVF format or provide conversion utilities. The image is
based on a 64 bit version of SuSE Enterprise Linux that may only be used for trials and
proof of concepts. This image may not be put into a production environment. At the
end of 90 days, the trial will end and the software will be disabled. At any point during
the trial, you may contact a business partner or your IBM sales representative to purchase
IBM SmartCloud Monitoring.
Note: When possible, use Download Director when downloading the files. Some
browsers are unable to download files larger than 4 Gig.
Demo Options
If you are not looking for a POC or Trial image, but are simply looking to demonstrate the
capabilities of the product, you have a few options.
There is a Demo virtual image that can be downloaded from the following URLs
https://www.ibm.com/services/forms/preLogin.do?source=swg-scmdvi,
https://www-304.ibm.com/partnerworld/wps/pub/benefit/B7007PW/SELPW, or
internally at http://depot.tivlab.raleigh.ibm.com. This image contains a prepopulated Tivoli Data Warehouse as well as a combination of real and demo ITM
Agents. This image allows you to exercise all of the capabilities of the IBM
SmartCloud Monitoring solution without having access to any hypervisors. This
image will run on a laptop with 8 Gig of memory and VMware Workstation
installed.
Hosted virtual images are available for use in a few different locations and can be
provisioned as needed. The locations are listed below. Some environments are
only available to IBM employees or Business Partners as indicated below. These
images are based on the SmartCloud Monitoring Demo and Trial virtual machines.
Typically, the images are provided here first and then deployed to these hosted
environments, so for a period of time they will be running a slightly older version
of the code.
o https://starthere.hatsize.com/ibm/
If you need access to hatsize, send an E-mail to

conrad@toplinerev.com
o http://demoworks.democentral.ibm.com/demoworks/index.php (IBM and

Business Partners only). If you need access, contact Mike Lee at
melee@us.ibm.com
o CSIDE (formerly TIDE-AG) website (IBM Intranet ID required):

https://cloud.skytap.com/login?logoutmsg=1&redirect_url=%2F
o IBM TEC centers have IBM SmartCloud Monitoring demo environments
available.
Key Enhancements in SmartCloud Monitoring 7.2 FP2

The SmartCloud Monitoring version 7.2 FP2 Trial image has several key improvements
over SmartCloud Monitoring 7.1. We highly recommend downloading and using this
version instead of the previous version. Key improvements are:
Inclusion of ITM 6.3 FP2 which has several key enhancements including:
o OS Dashboards
o Support for OSLC for linked data which allows for easier product
integration and richer customer experience.
o 64-bit TEPS on Linux which doubles the number of concurrent users and
allows a single HUB environment to scale to 20,000 managed systems.
o Security enhancements
o Improved Warehouse performance via the use of Range Partitioning
Completely rewritten VMware Health Dashboard

o Lighter weight/Faster Response Time
o More intuitive and easy to navigate
o Fewer clicks to drill down to root cause
New DASH (IBM Dashboard Application Server Hub) user interface

o DASH is a major enhancement from the IBM Dashboard Application
Services Hub (DASH)
o Includes Tivoli Common Reporting (TCR) 3.1 which includes Active
Reporting
o Sample Active Report is Attached Here so that you understand the benefits
of an Active Report and decide whether your company wants to build
reports with this feature. Just open the report with a browser:
Linux+Top+Utilization.
mht
o Self-Service dashboards. Build custom dashboards using any IBM Tivoli

Monitoring (ITM) data and data using Tivoli Directory Integrator
o Support for tablet devices
Improved VMware Capacity Planning:
o You can save existing customization. In the 7.1 release, all customization
was overwritten during the Load step.
o Can do partial loads of the VMware environment. This allows you to
selectively load portions of the VMware environment which speeds up the
load process. For example, if only 1 cluster has changed since you
previously loaded the configuration data, only load the VSphere servers in
that cluster.
o New VMware Expense Reduction Report and other reports
o Improved benchmark matching. In the 7.1 version, the product only
matched on the Processor model and number of cores. Now, the capacity
planning tool attempts to match on vendor, machine model, processor
model, and number of cores. If it cant find an exact match on the
machine model, then it uses the previous behavior from the 7.1 version
and matches on the process model and number of cores.
o Use of Storage and Networking as part of the capacity planning analysis.
o InfoSphere Federation Server included for federation to Oracle and
MSSQL. This feature is not demonstrated in the Trial because the Trial has
everything self-contained and running on DB2.
Power Systems :
o Capacity Planning: What-if scenarios, server sizing, etc. for Power Systems
o Enhanced Power Systems Agents including:
consolidation of UNIX OS Agent and Premium AIX Agent
Enhancements to the HMC Agent which now includes CPU

utilization for each of the CECs and LPARs being managed by the
HMC. This includes LPARs running i5/OS and Linux on PowerVM.
Enhancements to other hypervisors

o Other hypervisors such as Citrix and Cisco UCS have been enhanced
o Significant enhancements have been made to the Citrix XenApp Agent to
include support for both XenApp 5 and 6.x in the same agent and
additional metrics.
Additional Content:
o The Trial image also includes the Hyper-V Agent and Tivoli Directory
Integrator
Key Enhancements to the SmartCloud Monitoring 7.2 FP2 Trial
Upgraded to use ITM 6.3 FP2 and the SmartCloud Monitoring 7.2 FP2 monitoring
agents including the PowerVM Agents
Dashboard has been upgraded from TIP to the IBM Dashboard Application
Services Hub (DASH). The following components are installed into DASH:
o SmartCloud Monitoring 7.2 FP2 VMware Dashboard
o SmartCloud Monitoring 7.2 FP2 VMware Capacity Planning and
optimization tool
o Power Systems Capacity Planning tool
o OS Dashboards
o Custom Dashboard created using Tivoli Directory Integrator
Automatically runs a cron job once a night to populate the shared resources
dimension table. This allows new servers to appear in Cognos reports.
Provides a SynthesizeHistory script that allows you to synthesize historical data

based on a small sample of existing historical data. The tool takes 2 or more
hours of historical data and generates a user specified number of days of historical
data. In the previous Trial version, this tool was specific to VMware historical
data. It has now been generalized so that it can work with data from any ITM
Agent. This is very useful if you want to exercise the tools like Performance
Analyzer, Capacity Planning, and Reporting that require a reasonable number of
days of historical data.
Many of the historical reports are scheduled to run once a day. This allows you to
demonstrate the reports much faster.
Faster boot time for the OS and IBM SmartCloud Monitoring product components.
All passwords on the system are initially configured to smartway
If you encounter any problems with this virtual image, post a comment or question on the
SmartCloud Monitoring demo forum.
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=2757
Or, you can send an E-mail to Ben Stern at bstern@us.ibm.com
If you are interested in purchasing the software, you can purchase online at the following
website: http://www.ibm.com/software/info/app/ecatalog/index.html
Contents
Demo Options ..................................................................................................................................... 2
Key Enhancements in SmartCloud Monitoring 7.2 FP2 ...................................................................... 2
Key Enhancements to the SmartCloud Monitoring 7.2 FP2 Trial ....................................................... 5
The IBM SmartCloud Monitoring Trial image contains the following software: .............................. 14
Installation Summary ........................................................................................................................ 17
Detailed Installation Steps: ............................................................................................................... 20
Initial Steps ....................................................................................................................................... 21
Booting the Virtual Machine............................................................................................................. 22
Environment Configuration .............................................................................................................. 38
Common Configuration Steps ........................................................................................................... 41
Running the Trial Image .................................................................................................................... 44
Launching the Tivoli Enterprise Portal .............................................................................................. 44
Exploring IBM SmartCloud Monitoring ............................................................................................. 47
Configuring
VMware Environments: .................................................................................................................... 48
VMware VI Agent Prerequisites:....................................................................................................... 49
Configuring the VMware VI Agent .................................................................................................... 50
IBM Systems Director Integration ....................................................................................... 51
NetApp Agent Integration ................................................................................................... 52
Requirements for Historical Data ........................................................................................ 54
VMware Exercises ............................................................................................................................. 56
Exercise 1: VMware Dashboard .......................................................................................... 56
Identifying a Problem .......................................................................................................... 60
Exercise 2: TCR Reports................................................................................................................... 64
Exercise 3: Capacity Planning ............................................................................................. 69
View Virtual Machines ......................................................................................................... 75
Exercise 4: Additional Virtualization Agents ...................................................................... 85

Exercise 5: VMware Expense Reduction Report ................................................................ 89
Interpreting the Report Results ........................................................................................................ 96
Recommend Optimizations and Potential Savings ......................................................................... 103
Optimizations:.................................................................................................................... 104
Return on Investment (ROI)............................................................................................... 107
PowerVM Environments ................................................................................................................. 111
HMC Agent......................................................................................................................... 112
VIOS Agent ......................................................................................................................... 112
CEC Agent .......................................................................................................................... 112
UNIX OS Agent ................................................................................................................... 112
Linux OS Agent ................................................................................................................... 112
i5/OS Agent ........................................................................................................................ 113
Agentless OS Agents .......................................................................................................... 113
Configuring the PowerVM Agents: ................................................................................................. 113
PowerVM Monitoring exercises ........................................................................................ 114
VIOS Agent ......................................................................................................................... 114
HMC Agent......................................................................................................................... 115
CEC Agent .......................................................................................................................... 118
UNIX OS Agent ................................................................................................................... 118
Linux OS Agent ................................................................................................................... 121
PowerVM Capacity Planning ........................................................................................................... 122
Citrix XenDesktop Agent ................................................................................................................. 135
Installation for Citrix XenDesktop Agent ........................................................................... 137
Broker Controller Configuration: ....................................................................................... 138
Agent Configuration: ......................................................................................................... 139

Some information about the agent: .................................................................................. 141
Troubleshooting key log entries and debugging: .............................................................. 142
Citrix XenApp Agent ........................................................................................................................ 142
Citrix XenServer Agent .................................................................................................................... 143
Prerequisites for the Citrix XenServer Agent ..................................................................... 143
Configure the Citrix XenServer Agent ................................................................................ 144
Citrix Exercises ................................................................................................................................ 148
Citrix XenServer Exercises .................................................................................................. 148
Citrix XenApp Agent Exercises ........................................................................................... 151
Cisco UCS Environments: ................................................................................................................ 153
KVM Environments ......................................................................................................................... 155
Gathering KVM Agent Requirements: ............................................................................................ 155
Configuring the KVM Monitoring Agent: ........................................................................................ 155
Remote Transport Configuration:...................................................................................... 158
Hardware, Storage, and Networking Agents .................................................................................. 159
NetApp Monitoring Agent .............................................................................................................. 159
Gathering Netapp Agent Requirements: ........................................................................... 159
Configuring the Netapp Monitoring Agent:....................................................................... 160
Tivoli Storage Productivity Center (TPC) Agent .............................................................................. 163
Network Device Agent: ................................................................................................................... 164
Agentless OS Monitoring Agents .................................................................................................... 164
Agentless OS Monitoring Requirements ........................................................................................ 164
Configuring the Agentless OS Monitoring Agents .......................................................................... 166
Agent Based OS Monitoring............................................................................................................ 173
Other Agents:.................................................................................................................................. 173

Appendix A: Remotely Deploying Agents ..................................................................................... 175
tacmd exportBundle: ......................................................................................................... 175
tacmd createNode: ............................................................................................................ 176
Remotely Deploying the Hypervisor Agents ................................................................................... 180
Network Ports ................................................................................................................................. 180
Netapp Agent:................................................................................................................................. 181
Remotely Deploying the NetApp Agent via the Tivoli Enterprise Portal ........................... 181
Remotely Deploying the NetApp Agent via the Command Line Interface ........................ 184
VMware VI Agent: ........................................................................................................................... 185
Remotely Deploying the VMware VI Agent via the Tivoli Enterprise Portal ..................... 186
Remotely Deploying the VMware VI Agent via the CLI ..................................................... 190
Network Device Agent: ................................................................................................................... 192
Remotely Deploying the Network Devices Agent via the TEP ........................................... 193
Remotely Deploying the Network Devices Agent via the CLI ............................................ 194
VIOS Agent ...................................................................................................................................... 195
HMC Agent ...................................................................................................................................... 196
Installing and Configuring the HMC Agent via the TEP...................................................... 196
Installing and Configuring the HMC Agent via the CLI ....................................................... 199
CEC Agent........................................................................................................................................ 201
CEC Agent pre-installed in the VIOS .................................................................................. 202
Installing and Configuring the CEC Agent via the TEP ....................................................... 204
Installing and Configuring the CEC Agent via the CLI......................................................... 206
Citrix XenServer Agent .................................................................................................................... 208
........................................................................................................................................... 210
Remotely Deploying the Citrix XenServer Agent via the CLI ............................................. 212
Citrix XenDesktop Agent: ................................................................................................................ 213
Installation for Citrix XenDesktop Agent ........................................................................... 215
Broker Controller Configuration: ....................................................................................... 216
Remotely Deploying the Citrix XenDesktop Agent via the CLI........................................... 217
Some information about the agent: .................................................................................. 219
Troubleshooting key log entries and debugging: .............................................................. 220
Remotely Deploying the Citrix XenDesktop Agent via the CLI........................................... 220
Citrix XenApp Agent: ....................................................................................................................... 221
Remotely Deploying the Citrix XenApp Agent via the TEP ................................................ 221
Remotely Deploying the Citrix XenApp Agent via the CLI ................................................. 223
Cisco USC Agent: ............................................................................................................................. 223
Remotely Deploying the Cisco UCS Agent via the CLI ....................................................... 225
KVM Agent ...................................................................................................................................... 226
Remotely Deploying the KVM Agent via the Tivoli Enterprise Portal................................ 227
Remotely Deploying the KVM Agent via the Command Line Interface............................. 230
Tivoli Storage Productivity Center (TPC) Agent .............................................................................. 231
IBM Systems Director Integration ..................................................................................... 235
Agentless OS Monitoring Agent...................................................................................................... 235
Remotely Deploying the Agentless OS Monitoring Agents via the TEP ............................ 237
Appendix B: Problem Determination ............................................................................................. 243
DB2 wont start: .............................................................................................................................. 243
TEPS is not available: ...................................................................................................................... 243
DB2 is not running: ............................................................................................................ 243
TEPS is not running ............................................................................................................ 243
Unable to launch TEPS Login ............................................................................................. 244
HUB TEMS is not running: ............................................................................................................... 244
Summarization & Pruning Problems: ............................................................................................. 244
IBM Dashboard Application Services Hub (DASH) (TIP) is Unavailable: ......................................... 244
Processes are running, but DASH unavailable: .................................................................. 244
DASH Processes are not running: ...................................................................................... 245
Agents are not available in TEP: ..................................................................................................... 245
No Data is Available in the Health Dashboard................................................................................ 245
Capacity Planning is not returning data.......................................................................................... 246
Capacity Planning or TCR reports fail with a Cognos Error ............................................................. 246
Previous Workarounds Fail to Resolve the Problem ...................................................................... 247
TEMS ............................................................................................................................................... 248
Connection: ITMfVE Capacity Planning Datamart for VMware ..................................................... 249
Connection: ITMfVE Capacity Planning Datamart for PowerVM................................................... 250
Connection: TDI ............................................................................................................................. 251
Connection: VMware Dashboard .................................................................................................. 251

Trademarks ..................................................................................................................................... 255
The IBM SmartCloud Monitoring Trial image contains the following software:
ITM 6.3 environment including:

o TEMS
o TEPS
o Warehouse (Warehouse Proxy Agent and Summarization & Pruning Agent)
o IBM Tivoli Performance Analyzer
Pre-installed base Agents for the ITM 6.3 product and all IBM SmartCloud
Monitoring Agents except for Citrix XenApp and the PowerVM Agents. The Citrix
XenApp Agent must be installed on the Citrix XenApp server and the PowerVM
Agents must be installed on the VIOS or an AIX LPAR. Pre-installed Agents
include:
o OS Agent
o UNIX Log Agent
o All of the agentless OS Agents
o Warehouse Proxy Agent
o Summarization & Pruning Agent
o VMware VI Agent
o KVM Agent
o Cisco UCS Agent
o Citrix XenServer Agent
o Citrix XenApp Agent (Only the application support is installed)
o Citrix XenDesktop Agent

o NetApp Agent
o Tivoli Storage Productivity Center (TPC) Agent
o Network Device Agent
o Tivoli Log File Agent
With the exception of the Linux OS Agent, Tivoli Log File Agent, and the
warehouse agents, none of the agents are configured. During the setup process,
you will need to configure the agents to work with each of the monitored
hypervisors and storage devices. Detailed configuration steps are included in this
document for each of the agents.
IBM Dashboard Application Services Hub (DASH) with the following applications
installed and configured:
o Tivoli Common Reporting (TCR) 3.1 including reports for :
VMware
PowerVM
Hyper-V
Citrix XenApp
Citrix XenServer
Cisco UCS
Linux KVM
OS Agents
Capacity Planning reports for VMware
Capacity Planning reports for PowerVM
o Dashboards for VMware Clusters and VMware ESX Servers

o Capacity Planning for VMware
o Capacity Planning for PowerVM
o Sample Custom Dashboard using Tivoli Directory Integrator to gather data
Installation Summary
The following section provides a summary of the installation steps that are documented
in detail throughout this document. By following these procedures, you will have a fully
functioning IBM SmartCloud Monitoring environment that can be used to try out the
product features. These instructions describe how to setup and deploy the OVF
formatted image into a VMware environment. However, the OVF standard is supported
by multiple hypervisors. Follow the instructions for the hypervisor that you are using.
This section gives a summary of the installation instructions. Subsequent sections provide
detailed setup instructions.
1. Download the Trial Virtual Image files.
When downloading the files, download the two large virtual disk files at
the same time to save time. Please use Download Director when
downloading the files. Some browsers are unable to download files
larger than 4 Gig.
2. Import the OVF image into a VSphere 4.x or 5.x environment or VMware
Workstation version 7 or above. The VMware environment must support a 64-bit
guest OS. When using the VCenter Client, select File -> Deploy OVF Template.
Then, in the dialog, browse for the SCM_Trial_7.2.ovf file and click Next and
complete the remaining steps to import the image.
3. Before starting the VMware Trial image, double check the network settings. Edit
the virtual machine settings. For example, select VM Network for Network
Adapter 1. Confirm that the Network label matches your VMware environment.
4. Start the VMware Trial image.
5. You will be prompted to login to the Virtual Machine. Login as root with
password smartway
6. When prompted, accept the trial licenses and configure the network settings and
system passwords. Note: the hostname must be set to scmtrial, but the
domain name may be set to anything you desire. When the system boots, the
hostname will automatically reset to scmtrial
7. After the image has booted for the first time, reboot the server to ensure that the
required processes start properly.
8. After logging into the system, you will see the following icons on the desktop
which will allow you to start the Tivoli Enterprise Portal, DASH server, and run
some other utilities.
9. Once the Image has booted, you may launch the Tivoli Enterprise Portal (TEP) and
use the ITM product. A few Agents will be available, but none of the hypervisor
Agents will be running until you configure those agents to monitor the storage or
hypervisor servers.
10. The next step is to configure the Agents that you wish to utilize in your
environment. Some customers may choose to only configure 1 or 2 Agents. The
Agent that provides the most functionality, including a Dashboard and Capacity
Planning, is the VMware Agent.
11. Start the Agents that you have configured. After a couple of minutes, the new
Agents will be available in the Tivoli Enterprise Portal. There is an icon on the
desktop to launch the Tivoli Enterprise Portal. Or, you can point a browser at the
machine http://scmtrial:1920///cnp/kdh/lib/tep.jnlp. Make sure that you can
ping the scmtrial hostname from any machine where you plan to run the Tivoli
Enterprise Portal user interface. Login as sysadmin with password smartway.
12. After the Agents are started, the trial image will automatically begin to gather
historical. The Capacity Planning tools require a minimum of 2 days of historical
data. If you wish to accelerate the use of Capacity Planning and reporting, there
is a set of scripts available in the /history_tool directory. There is a script available
for each of the Agents. Only run the script for the Agents that you have
configured and have at least 2 hours of historical data in the Warehous database.
This tool will take 2 or more hours of historical data and synthesize a realistic set
of historical data based on the existing historical data. The data is based on the
actual historical data and the tool creates some variation in the data including
allowing the synthesized data to be slightly larger than the largest data in the
Warehous and slightly smaller than the smallest data in the Warehous.
Before executing the Synthesize History tool, confirm that you have
Summarization Data in your Warehouse database. For more details see the
subsequent sections in the document.
The scripts are setup to synthesize 7 days of historical data. If you want, you can
modify the scripts and generate more historical data.
If desired, execute Synthesize History scripts for any agents that you have
configured and generate enough historical data to utilize all of the key IBM
SmartCloud Monitoring capabilities such as Capacity Planning, Performance
Analyzer, and Tivoli Common Reporting.
When you run the script, you will receive some errors. By default, the script
attempts to synthesize history for ALL of the possible tables in the Warehous.
However, ITM is not configured to collect historical data for all of the attribute
groups. View the log file and make sure that data is getting inserted for the
expected tables.
The Synthesize History tool does have some additional options. Instead of
running the scripts, you can run the command manually and specify some
different options. One option is to generate a set of jython files, which can then
be edited. The jython files will specify which attribute groups you want to
synthesize. This allows you to synthesize data for a specific set of tables. View
the readme file that is included in the /history_tool directory for information on
how to generate and use the jython files to synthesize the historical data.
13. At this point, you may launch the DASH user interface and use the Reports,
VMware Dashboard, and Capacity Planning tools. There is an icon on the desktop
to launch the DASH user interface. If you want to run the tool from a browser on
another machine, first check that you can ping scmtrial using the hostname.
Then, use the following URL to launch the IBM Dashboard Application Service Hub
(DASH): https://scmtrial:16311/ibm/console/logon.jsp. Login as smadmin with

password smartway.
Detailed Installation Steps:

Download all of the files in the directory. There are 15 files in the directory and a total of
about 36 GBytes to download.
Once the image is downloaded, you will see the following files:
Filename
md5sum
scmtrial.ovf
b8b9760968750d32594dfcb7c9e117df
scmtrial.mf
45f771d912b8c69cb5d14db9311ea97f
scmtrial-disk1.vmdk
4e459ca7891149c94b7d11b04906bb36
scmtrial-disk2.vmdk
89e99bdf431bf6bdce613c799f760ada
scmtrial-disk3.vmdk
2455828c4920f4deae603cf912d3c898
scmtrial-disk4.vmdk
ce1d75e4adca695821f5251170b298f0
scmtrial-disk5.vmdk
5488433cfc4b16dcd157eeb6400f0e11
scmtrial-disk6.vmdk
558b4fe4105b1c0013266af40d52457f
scmtrial-disk7.vmdk
9fbacd90c08ea8061286f47d5f458519
scmtrial-disk8.vmdk
84bc506f6568f4f282cb58667fec65e5
scmtrial-disk9.vmdk
29f5219fb24e117558d81165e5eb0356
scmtrial-disk10.vmdk
03f232889016fcbcf0d846d36ca374ef
c045854c23e04fb22663b5d438504eaa
0dc532c28f5e0712030f3207a3bb08d7
SmartCloudMonitoring_Trial_v3.pdf
For a VSphere Infrastructure Environments (ESX/ESXi), use the VSphere Client to import
the OVF image. Open the VSphere Client and select File -> Deploy OVF Template. You
will be prompted to browse for the OVF file or URL. Click the Browse button and select
the OVF file.
Click Next and follow the instructions for importing the OVF image.
If you encounter any problems related to zlib1.dll, see the following VMware information:
http://communities.vmware.com/message/1866764
Initial Steps
There are some steps that you should take to ensure that the software trial will go
smoothly.
The initial step of downloading and importing the VMware OVF image was
described in the introductory section of this document.
The trial image has the TEMS configured for both IP.PIPE and IP.SPIPE
communications. IP.PIPE uses port 1918 and IP.SPIPE uses port 3660 to
communicate between the Agents and the TEMS (Tivoli Enterprise Management
Server). If you are using the Agents that are locally installed on the VMware
image, you will not need to open port 1918/3660 in the firewall. However, if you
remotely deploy an agent to another machine, you must ensure that either port
1918 or port 3660 is open between the Agent and the virtual image.
Confirm that you have an appropriate VMware VSphere or VMware Workstation

system where the image can be installed.
o The image supports VSphere 4 and above and VMware Workstation
version 7 and above.
o The image will require approximately 5 to 6 GBytes of memory depending
on how many agents are running locally on the appliance. The size of the
monitored virtualized environments will also affect memory requirements.
We suggest configuring the VMware image with 6 GBytes of memory.
o The image will require a minimum of 2 virtual processors to get adequate
performance, but we recommend configuring 4 virtual processors.
o The image will require approximately 60 Gig of disk space on the VMware
server. However, if limited space is available, you may thin provision the
disks during the import.
o The VMware system must be cable of hosting 64-bit virtual machines.
An IP address must be assigned to the VMware Virtual Machine. The hostname

of the Virtual Machine is scmtrial and should not be changed. Request an IP
address and fully qualified domain name for scmtrial. Also request the subnet
mask, default gateway, and DNS server(s) for your environment.
Booting the Virtual Machine

Here are the steps you will follow after you boot the virtual machine:
First, you will be prompted for the username and password to login to the virtual
machine. Use root as the username and smartway as the password
Next, select the language that you desire for the operating system. To select a
language other than English, select the down arrow on your keyboard and a list of
languages will appear. Once you have selected the language, click tab until the
OK button is highlighted and press Enter or press F10
Next, you will be prompted to accept a series of license agreements for SUSE Linux
Enterprise Server, VMware, and IBM SmartCloud Monitoring trial. If you decline
any of the license agreements, the system will shut down and you will need to
start the initialization process over again.
On the next dialog, you will be reminded that the hostname of the system is hard
coded to scmtrial. You may enter any hostname in the network configuration
dialogs, but the hostname will be reset to scmtrial. You may set the fully qualified
domain name to anything you want.
Next, you will begin the process of configuring the network. The first dialog asks
whether you want a STATIC or DHCP IP address. For the examples below, well
show an example of a static IP address, but DHCP may be used.
Here is an example of the networking configuration for a static IP address.
Next, you will be asked to confirm the network configuration settings:
After confirming the networking configuration, you will be prompted to enter and
then confirm the passwords for the root and virtuser accounts. To keep things
simple, I use smartway for all passwords on the system, but you may choose
any password that you want. If you choose a different password, please write
down the password or make sure that you remember the password that you
enter.
After you have entered the passwords for root and virtuser, the system will
complete the boot process. You will see a typical SUSE Linux Enterprise Server
login prompt. Login as root using the password you entered in the previous step.
You have now completed the steps required to configure the operating system for
your environment. You will be able to use the Trial software for 90 days. After
the 90 day period, the Trial software will be disabled.
IMPORTANT: After you have done your initial configuration of the IP address,
login to the operating system and reboot the system. The first time the system
boots, not all of the IBM services start up properly.
Environment Configuration
The following section outlines the overall monitoring environment that will be used to
monitor your cloud/virtualized environment. There are multiple options for the
deployment configuration. This section outlines our recommended approach for
deploying the Smart Cloud Monitoring Trial VMware environment. In subsequent
sections, other deployment options will be discussed. Our recommended configuration

is to run the hypervisor monitoring agents within the Trial Virtual Machine. The
Monitoring Agents are pre-installed and only need to be configured to begin monitoring
your environment. This is the quickest way to get your Trial up and running.
Appendix A: Remotely Deploying Agents will describe how to install agents on remote
machines.
The diagram below shows the communications ports/protocols that are used by the
virtual image for external communications.
Notice that a few of the agents must be installed on servers outside the trial
virtual image. Those agents are:
o The Citrix XenApp ITM Agent must be installed on the Citrix XenApp server.
o The VIOS Agent is pre-installed into the Virtual OS Server (VIOS).
o The HMC Agent must be installed on an AIX LPAR that has network ssh
connectivity to the HMC.
o The CEC Agent must be installed on an AIX LPAR with network connectivity
to the frame that it is monitoring.
o The UNIX OS Agent is installed on each of the AIX LPARs.
o The Linux and Windows OS Agents must be installed on the operating
systems that are being monitored.
o The Hyper-V Agent must be installed on the Microsoft Hyper-V Server.
If you want to deploy the Agents remotely to servers rather than run the Agents within
the Trial virtual image, the network configuration will look like the following:
The remainder of this document is organized into groups of Agents that are typically seen
in the same customer environment. For example, VMware and NetApp storage are often
used in the same environment. Customers that use Citrix XenServer often use Citrix
XenDesktop or Citrix XenApp. Each section includes the prerequisites, configuration
details, and some exercises to try out the product functionality. The first group of Agents
will focus on a typical VMware environment.
Common Configuration Steps

The next section of this document describes the process for configuring the Agents to run
locally within the Virtual machine. These steps are common to all agents that are preinstalled inside the virtual machine. A few agents like Citrix XenApp, OS Agents, Hyper-V
Agent, CEC Agent, VIOS Agent, and the HMC Agent must be installed on the system being
monitored or installed on an AIX OS. In this section, all of the configuration steps will be
executed via the CandleManage GUI interface. It is possible to configure the Agents
through the Command Lin Interface (CLI), but this document does not address that.
Please see the IBM Tivoli Monitoring documentation for details on CLI configuration.
A couple of the agents require you to copy files to the Virtual Machine because we are
not allowed to ship the 3rd party files or because they need to match the version of the
product you are monitoring. Use scp to copy files to the Trial virtual machine. Here is
an example scp command. scp manageontap.jar root@scmtrial:/tmp. When
prompted, specify the rood password (smartway). This will copy the manageontap.jar
file to the /tmp directory the Trial virtual machine.
Begin the configuration process by opening a terminal window inside the virtual image.
This can be done by right clicking the mouse and selecting Open Terminal. From within
the Terminal window change directory to /opt/IBM/ITM/bin. Then, type the following:
cinfo R
Next, type CandleManage or double click on the Manage Tivoli Enterprise Services
icon on the desktop.
A graphical user interface (GUI) will open and will look like the following:
Some of the components will be configured and running and others will not. When you
want to configure one of the Agents such as the VMware VI Agent, select the row in the
table and right click, and select Configure.
Each Agent will have a different set of configuration panels. However, all of them will
have one panel in common as seen below. That panel configures the communications
between the Agent and the management server. As mentioned previously, this VMware
environment has been configured to use either IP.PIPE and port 1918 or IP.SPIPE and
port 3660. When you configure the Agent communications, specify the hostname of the
system (scmtrial), the protocol (IP.PIPE or IP.SPIPE) and the port number (1918 or 3660).
Most of these should be the default values. Also make sure that the No TEMS
checkbox is unchecked. When you are finished, the configuration panel should look like
the figure below. Then, click Save to complete your changes.
After clicking the Save button, right click on the Agent and select Start Service to start
the Agent.
Configure as many of the agents as you want.
If desired, you can use remote deploy to remotely install agents to other machines.
Remote deploy is described later in the document.
Running the Trial Image

Launching the Tivoli Enterprise Portal
Before you configure any Agents, you may access the IBM Tivoli Monitoring user interface
through the Tivoli Enterprise Portal (TEP). The Tivoli Enterprise Portal may be accessed
from within the virtual machine or any machine with the appropriate Java Version and/or
Browser version. We also recommend using the Java Web Start interface, but the Tivoli
Enterprise Portal also supports a browser interface.
If you wish to access the Tivoli Enterprise Portal from another machine, you will need to
add an entry for the hostname scmtrial to your local hosts file or to the DNS server.
Otherwise, you wont be able to resolve the hostname. If you can ping scmtrial, then
everything will work fine.
To access the Tivoli Enterprise Portal (TEP) via Java Web Start from a remote machine,
open the following URL:
http://scmtrial:15200/tep.jnlp
If you want to access the Tivoli Enterprise Portal via Java Web Start from the console of
the Virtual Machine, you can double click on the TEP icon on the desktop:
To access the Tivoli Enterprise Portal (TEP) browser client, open a browser to the
following URL:
http://scmtrial:15200/cnp.html
Login to the TEP client as sysadmin with password smartway
When launching Java Web Start, sometimes, the browser will open a dialog asking
whether you want to open the file with Firefox Web Browser, as seen below. You dont
want to do that. You need to open this with the javaws executable.
Browse to the the javaws or javaws.exe file to open the tep.jnlp file as seen in the
following dialog. You will need to use a 1.6 or 1.7 JRE to run the tool
This will launch the Java Web Start application. After the JAR files have been
downloaded, you will be prompted with a logon screen.
Login to the TEP client as sysadmin with password smartway

There are some versions of Java that will give errors with the certificate signings on the
*.jnlp files. If you receive the following error, try using a different Java version. I typically
have more success with the IBM 1.6 JREs or 1.7. Ive seen the most trouble with 1.7.1.
Only some of the features of the IBM Dashboard Application Server Hub (DASH) server
will function until you have configured the VMware VI Monitoring Agent or the Power
Systems Agents. The Tivoli Common Reporting will function, but the Health Dashboard
and VMware Capacity Planning tools require the VMware VI Agent to be running. The
PowerVM Capacity Planning tools require that you have the HMC Agent, VIOS Agent, and
Linux OS or UNIX OS Agents on the LPARs for a particular CEC.
To access the DASH server interface, open the following URL:

https://scmtrial:16311/ibm/console/logon.jsp
Login as smadmin with password smartway
If you wish to access the DASH server from another machine, you will need to add an
entry for the hostname scmtrial to your local hosts file or to the DNS server.
Otherwise, you wont be able to resolve the hostname. If you can ping scmtrial, then
everything will work fine.
Exploring IBM SmartCloud Monitoring

Later in this document, you will find detailed instructions for installing or configuring each
of the agents used in the trial. This section is focused on using the SmartCloud
Monitoring 7.2 Trial. Once everything is running, you will be accessing two different user
interfaces to run the demo scenarios.
You will use the IBM Dashboard Application Services Hub (DASH) to access the Tivoli
Common Reporting, the System Status and Health, and the Capacity Planning tools. The
Tivoli Common Reporting tool is used to run historical reports. The System Status and
Health dashboard is a set of dashboards that incorporate the health and performance
metrics of the VMware environment including the Network devices, VMware
environment, and storage devices. The Capacity Planning tool allows you to perform
Capacity Planning and optimization as well as what-if scenarios for your VMware
environment.
Configuring VMware Environments:

In many cloud and virtualized environments, people want to gather performance data
and alerts from the hypervisor, but they also want to gather information from the storage
devices and network switches. Since the performance, availability, and latency of the
storage devices and network switches that are being used by the hypervisor are critical to
the performance of the overall cloud/virtualized environment. If you wish to configure
any of the Storage and Networking Agents, there is a section called Hardware, Storage,
and Networking Agents. If you plan to use the NetApp Agent, we recommend you
configure the NetApp Agent before configuring the VMware VI Agent because some of
the information from the NetApp Agent will be used during the VMware monitoring
agent configuration. In addition, some customers use IBM Systems Director to monitor
their server hardware. The Hardware, Storage, and Networking Agents section of the
document provides instructions on configuring the IBM Systems Director Agent. This will
allow you to integrate hardware data into your IBM Tivoli Monitoring environment.
VMware VI Agent Prerequisites:

The VMware VI Agent uses a user account to gather performance data from VCenter.
Optionally, the Agent can be configured to remotely gather data from one or more ESX
Servers. The recommended configuration is to connect the Agent remotely to VCenter.
If you monitor the ESX/ESXi servers, the requirements below will be the same, but you
will need to provide user accounts on the target systems and ensure that firewall ports
are open to the monitored system(s).
Create a user ID in the VMware Virtual Infrastructure. This user ID is used by the
VMware VI agent to communicate with the VCenter server or the ESX/ESXi
servers. To monitor VMware, the user account must have the following
permissions in VCenter:
System.View and System.Read privileges on all data source objects being

monitored.
If you want ITM to be able to perform corrective actions such as starting and
stopping virtual machines, then you must enable the following permissions:
Virtual Machine-Interaction-Power On
Virtual Machine-Interaction-Power Off
The VMware VI Agent uses either HTTPS or HTTP to communicate to VCenter or

the ESX servers. The default is HTTPS. Ensure that the HTTPS or HTTP port is
open between the Agent and the monitored system.
If the security configuration is setup where an SSL key exchanged between the
VCenter server and the agent, you should ask the VMware admin to provide the
rui.crt file from the VCenter server(s). This file can typically be found in the
following directory: C:\Users\All Users\VMware\VMware VirtualCenter\SSL. See
the VMware VI Agent documentation for more information.
Configuring the VMware VI Agent

the Terminal window, type the following:
/opt/IBM/ITM/bin/cinfo R
Then type:
CandleManage or double click on the Manage Tivoli Enterprise Services icon
on the desktop.
The Manage Tivoli Enterprise Monitoring Services configuration panel will open. See the
dialog below.
Using the Manage Tivoli Enterprise Services user interface, right click on the Monitoring
Agent for VMware VI and select Configure. The following dialog will open:
Click the Add Instance button to create a new VMware monitoring agent instance. The
instance name can be any name, but Best Practice is to use the hostname of the VCenter
server and click OK. We recommend, one Agent instance be created to monitor each
VCenter server.
Next, you will be prompted for the Agent specific information. In the Data Provider
tab, we recommend you set the Validate SSL Certificates to No.
IBM Systems Director Integration

If you wish to integrate the VMware VI Agent with IBM Systems Director, click on the
IBM Systems Director tab and provide the following information as shown in the dialog.
Enter either the IP address or Hostname of the IBM Systems Director server.
Enter the port number used by the IBM Systems Director Server. The default is
8422.
Specify whether your Tivoli Enterprise Portal Server credentials will be used to
authenticate to IBM Systems Director. The default Portal Server username is
sysadmin
NetApp Agent Integration

If you want to integrate NetApp into the environment, you must first install the NetApp
Monitoring Agent. Then, you must gather some information from your system. In a
Terminal window, login to the ITM environment by typing:
tacmd login s scmtrial u sysadmin p smartway
After logging in, type:
tacmd listsystems | grep NU
This command will return the Managed Systems Name of the NetApp Agent as
highlighted below.
You will enter the NetApp Agent Managed System Name into the Storage Agent tab
as shown below.
Next, click on the Data Source tab
Click the New button to add a VCenter or ESX/ESXi server to monitor.
Enter the information required for your VMware environment.
The Data Source ID can be anything, but Best Practice is to use the name of the
VCenter server.
The Data Source Address is the hostname or IP address of the VCenter server.
The default for Use SSL Connection to Data Source is Yes, but this parameter
must match your VCenter environment.
The Data Source User ID and password must be a valid account on the VCenter
server with read only access.
Click Save
After configuring the VMware Agent, right click on the Agent in the Tivoli Enterprise
Management Services user interface and select Start Service. When prompted, select
the Agent instance that you created as shown below.
Click Start Agent
Requirements for Historical Data

Some of the exercises require historical data in the Warehouse. For example, to view some of
the historical reports, it is desirable to have at least 7 days of historical data. The Capacity
Planning and Optimization tool requires a minimum of 2 days of historical data. There are two
ways to obtain this historical data. You can let the system run for 2 or more days gathering
historical data so that you can begin using some of the more advanced features of the software.
The other option is to utilize a tool called Synthesize History that ships with the Trial image.
This tool will synthesize a user defined number of days of historical data. It bases the data off a
small sampling of data gathered from the customers environment. Before running the tool,
allow the system to gather at least 2 hours of historical data for VMware. Then, double open the
history_tool folder on the desktop or change directory to /history_tool. Within the
history_tool directory, you will see a shell script for each agent used in the SmartCloud
Monitoring Trial. Simply execute the shell script. By default, the script will generate 7 days of
synthesized historical data. If you wish to create a different number of days, edit the shell script
and change 7 to the number of days you desire. If you decide to synthesize more than 10 days of
data, you will want to increase the size of the DB2 transaction logs or you run the risk that you will
fill up the transaction logs. The Synthesize History tool uses a sophisticated algorithm to
extrapolate the limited data set gathered from the customers environment. It uses the MIN,
MAX, and AVG data and adds some slight randomness to the data so that it looks realistic. The
tool will even synthesize data that is larger than the current maximum value and smaller than the
current minimum value, but it will not exceed those values by a significant amount and wont
exceed the theoretical minimums and maximums. For example, it wont create negative values
and wont create percentages that are larger than 100%.
To run the tool, double click on one of the shell script icons seen below. Or, run the script from a
Terminal window. For example /history_tool/synthesize_VMware.sh
After synthesizing the historical data, you must wait approximately 1 hour for the Summarization
& Pruning agent to create the Hourly and Daily summarizations. Most of the reports, predictive
analytics, and capacity planning are done using Summarization data. If you wish to accelerate
this activity, you can stop and the restart the Summarization & Pruning Agent. It will begin
summarizing the data immediately after starting. To stop and start the Summarization & Pruning
Agent, issue the following commands:
/opt/IBM/ITM/bin/itmcmd agent stop sy
/opt/IBM/ITM/bin/itmcmd agent start sy
Once you have gathered a minimum of 2 days of historical data or synthesized historical data, you
may begin running through the VMware exercises.
VMware Exercises
Exercise 1: VMware Dashboard
To access the IBM Dashboard Application Services Hub (DASH) interface, open the
following URL: https://scmtrial:16311/ibm/console/logon.jsp
Login as smadmin with password smartway
After logging into the IBM Dashboard Application Services Hub (DASH) interface, you will
see several entries in the upper left corner. Expand the System Status and Health as
shown below.
Click here to view the Health Dashboard
There are three pages that you can open. The first page (VMware Cluster Dashboard) is
the normal Operations page for monitor a VMware environment. It shows the health
and performance all of the VMware Clusters. The second page is used for environments
with stand-alone ESX servers that are not part of a VMware Cluster. You typically wont
need that page. The third page is used to confirm that the configuration of the
dashboard and monitoring are configured and working properly.
Lets take a look at the VMware Cluster Dashboard. Click on the link and a new page
will open as shown below.
As you exercise these capabilities, there are several key points to highlight on the main
health dashboard.
The VMware Dashboard is aimed more at the Operations team than the VMware
administrators. The ITM Tivoli Enterprise Portal is the user interface that will be
used for deep diagnosis of problems. There is launch in context from the VMware
Dashboard to the IBM Tivoli Enterprise Portal to diagnose a problem.
The top level dashboard is an ideal tool for the Operations team to view a
summary of the health of the entire VMware environment. Then, drill down to
isolate the problem to the point where the right subject matter expert can be
contact. For example, the operations team might need to contact the application
owner of the virtual machine, the VMware administrator, the network
administrator, or the storage administrator.
The dashboard integrates metrics and alerts from VMware, Operating System
Agents running within the virtual machines, the network, and storage devices to
provide far more information than can obtained via VCenter.
Now, lets examine the contents of the dashboard.
Highest Severity
Problem bubble
to the top
Filter Clusters
Key KPIs per Cluster

Click on Cluster link to drill
down
Top 5 Clusters for CPU, Memory, and Storage

In the upper left corner, you see the Cluster Scorecard. This shows an indication of the
health of each Cluster in the environment. This shows the Situations that are affecting
any resources in each of the clusters. It is sorted by default so that the Cluster with the
high number of high severity problems is listed at the top. On the top right, you see
some of the key Cluster level KPIs for each cluster.
Youll also notice a filter text box. You can enter characters in this field. As you type the
characters, only the cluster that contains the characters that you have typed will appear
in the page.
At the bottom of the screen, you see a top 5 list of Clusters based on CPU utilization,
Memory Utilization, and Storage usage. These are the clusters that you want to pay
attention to from a capacity perspective.
Identifying a Problem
Since the top portion of the screen is sorted by severity, the quickest way to identify and
resolve problems is by clicking on the name of the Cluster in the top row. This is a link
that will drill down to cluster level details. If you click on a cluster, you will see a page
similar to the one shown below.
As you can see, you see key KPIs for the cluster. The KPIs can be shown in real-time or you may
specify a duration for the historical data.
In the middle of the page, you see the Situation details for the Situations affecting the selected
cluster.
By selecting the Actions dropdown, you can run historical reports in context. The report
will run for the selected Cluster.
At the bottom of the page, you see the number of VSphere Server, Virtual Machines, and
Datastores. If you click on the numbers, you will navigate to a page showing the details for the
VSphere Servers, Virtual Machines, or Datastores. Below, you see the page for the Virtual
Machines.
On the Virtual Machines page, you see the Situations affecting each VM, some key KPIs for each
VM, and a Top 5 graph for CPU, Memory, and Storage.
The screen also contains a Filter text box so that you can filter the contents of the page to a
subset of the virtual machines.
If you click on one of the Virtual Machines,you will drill down to a page showing the details for
that Virtual Machine.
From the Virtual Machine, you can view real-time or historical data. You will see the Situations
for the selected Virtual Machine. And, you can click on the link in the bottom right corner and
link to the OS Dashboard for the Virtual Machine operating system.
On many of the VMware Dashboard pages, you will see tabs showing data from Tivoli
Application Dependency Discovery Manager (TADDM). There are two types of tabs.
One shows a change history for the select resource. The 2nd shows detailed configuration
data for the selected resource. Below, you will see an example of a change history page.
By default, the Trial Virtual Machine does not have TADDM configured. If TADDM is not
configured, the pages will not show any data. If you configure the integration with an
existing TADDM server and have TADDM discover your VMware environment, then youll
see change history and configuration data in context with the selected VMware resource.
Exercise 2: TCR Reports

The Trial virtual machine comes pre-installed with Tivoli Common Reports for most of the
IBM SmartCloud Monitoring Agents. Many of the reports have been scheduled to run
once a day. To view the reports, click on the Common Reporting icon on the left. Then,
select Common Reporting.
You will see a list of installed report packages as seen below. Select one of the report
packages by clicking on one of the links on the left.
After selecting one of the report packages, you will see a list of reports. Some have been
scheduled and some have not. To run the report, click on the report name. If you want
to schedule additional reports, select the calendar icon and fill in the configuration
details.
Click here to
schedule a report
Click for more

options such as
generating PDF,
HTML, or
postscript
The VMware reports are divided into five categories:
Accounting: These reports are used to identify the number of monitored clusters,
hosts, and virtual machines.
Workload Performance Trends and Forecasting: These reports show

performance trends and forecasting of performance data. You will also find Heat
Charts showing utilization each out of the day. These reports show key VMware
metrics such as Memory allocation, CPU Percent Ready, and data store capacity.
The first 2 reports are nice representative reports.
The 2nd report titled VMware VI: Cluster Performance Trends is a really nice
summary report. There are a couple of things to point out on this report. First,
notice that the yellow line indicates the peak utilization over the 30 day reporting
period and the blue line represents the average utilization during that period.
Second, you can select the links at the top of each column to sort on that column.
Finally, point click on the links on the left hand column and drill down into the
details of one of the clusters. From the Cluster report, drill down into a detailed
report for an individual ESX/ESXi server.
Prerequisite Checking: The prerequisite scanner checks to ensure that all of the
correct historical collections as well as summarization & pruning settings are
configured to run the VMware Agent reports.
What-if Analysis for Capacity Estimation: These reports allow you to perform
some basic capacity planning and what-if analysis for your VMware environment.
For example, there is a report that provides an estimate on the number of virtual
machines that can be added to a cluster before it runs out of capacity and
identifies the key metric that is the bottleneck. For example, Memory may be the
limiting factor that prevents you from adding more than 15 additional virtual
machines.
It is important note that the algorithms used for these reports are fairly simple
and do not replace the Capacity Planning tool. The Capacity Planning tool takes
into account processor benchmarks and a much more sophisticated analysis of the
metrics.
Workload Right-sizing and Balancing: The final category of VMware reports are
intended to help you balance your workload and identify unbalanced workloads.
For example, you might find that one of your VMware Clusters has very high CPU
utilization while another Cluster is under-utilized. See the screen capture below
for an example report. Notice that two of the Clusters have significantly higher
CPU utilization than the other clusters. But, the report also shows Memory and
data store space so that you can determine whether it is appropriate to move
virtual machines from one cluster to another. Run the first report in the list
VMware VI Balanced and Unbalanced Clusters to see the report below. There
are also some nice top/bottom reports to show the systems consuming the most
and least amount of resources. For example, an idle virtual machine might
indicate that it can be de-provisioned. By reviewing the VMware VI Balanced
and Unbalanced Host Servers report, you might identify servers where DRS/HA
are not working properly to balance the workload within a cluster.
Click to return to
the previous page
After you have run a report, click the Arrow in the upper right corner to return to the
previous page.
As an exercise, execute several of the VMware reports and schedule at least one report.
After reviewing the VMware reports, return to the complete list of reports by selecting
public folders as shown below.
Click here to return

to the full list of
reports
Notice that there are reports pre-installed for Capacity Analtyics, VMware, Citrix XenApp,
Citrix XenServer, OS Agents, Cisco UCS, and many more. Examine and run any of the
reports that interest you. For the Operating System reports, there is only a single Linux
Agent in the environment, so the data is limited.
If you are interested in building your own reports, select the Launch dropdown in the
upper right corner and then select Query Studio. These exercises are focused on
SmartCloud Monitoring, so I will not attempt to teach you how to create custom reports
with Cognos. However, the data and tools are there if you want to play and learn.
Exercise 3: Capacity Planning

The next exercise involves using the Capacity Planning tool to perform capacity planning
and optimization on the VMware environment. Capacity Planning involves going through
a 5 step process to analyze the VMware. There are two main goals to the capacity
planning tool. The first objective is to attempt to optimize the utilization of the VMware
environment and to ensure that adequate capacity exists. The second objective is to
perform what-if analysis to determine several things:
What ESX/ESXi hardware should I purchase in anticipation of additional load in the

environment?
What is the effect of adding X number of virtual machines into a cluster?
I need to plan for a new business application or acquisition. I need to add 100
virtual machines of varying sizes and I need to understand what hardware I should
purchase for this new workload.
Utilization in the future based on expected growth rates.
As you exercise the capabilities of the capacity planning tool, notice a few key capabilities
and differentiators. These key capabilities are listed below:
People use the term analytics very broadly, but there are multiple aspects. SmartCloud
Monitoring offers multiple capabilities:
The IBM Tivoli Monitoring product includes Dynamic thresholding where we tie the
monitoring thresholds to the actual utilization of each resource. This can be based on time
of day or day of week. But ultimately, it's about detecting changes in behavior. So, if
Disk I/O is normally 100 Bytes per second and it drops to 10 or increases to 200, we want
to know.
The product includes Predictive Analytics capabilities via the Performance Analyzer
Agent. Performance Analyzer Agent changes monitoring from being reactive to proactive.
The product ships with out of the box analytics for OS's, DB2, Oracle, Response Time,
Power Systems, and VMware, but customers can build their own analytics via point and
click UI for any numeric data. The Performance Analyzer includes integration with SPSS,
but SPSS integration does require an extra licensing cost. The main advantage of SPSS is
that it provides both linear and non-linear predictive analytics when looking for predictive
trends. The nice thing about SPSS is that it evaluates each resource individually,
determines the best statistical model for that resource, and then does the projections.
One of key capabilities of Performance Analyzer is the a use case such as the following.
Let's say that Performance Analyzer predicts that a system is trending towards running out
of capacity. Depending on the type of problem, I might need to order hardware such as
more memory. If I need to order HW, how long does it take Visa to get a purchase order
submitted, approved, into the purchasing departments hands, processed and into the
vendors hands, get the parts onsite, and then schedule a change window to install the
additional memory? My guess is a minimum of 60 days. When thresholds are written
with Performance Analyzer, you write them against the number of days notification that
you need.
Finally, we move into Capacity Planning and Optimization. This is a really exciting and
powerful component of IBM SmartCloud Monitoring. The tool is very simple and written
for the VMware admins and not for a set of PHd capacity planning experts. Most
Capacity Planning teams don't waste their times on the infrastructure. They are analyzing
the business applications. This tool provides a way for a VMware admin to optimize and
tune their VMware environment with a few key goals in mind and no mathematical
knowledge. All they need is their business objectives.
We build SPECint benchmarks into the tool so that our capacity estimations are
accurate. Some vendors only use things like CPU percentages in their capacity
planning tools. That's just a very rough guess.
We can perform some what-if scenarios. For example, I have a new business
application coming online and it has 100 virtual machines. Do I have capacity?
Where should I place those 100 VMs to get the best optimiztion? What is the
impact of adding 2 new physical servers of a given machine model.
Finally, we get to the Policy based optimization. We have out of the box rules
(policies) and customers can define their own that lets them optimize the
environment with specific business goals in mind. For example, they might want
to provide 20% more capacity for a specific business application. Or 30% more
capacity for any mission critical application.
We identify various risks in the environment. For example, there might be Virtual
Machines that haven't been allocated enough memory or reside in a cluster that is
running low on capacity.
While it may not be VMware's main goal, one of the primary goals of our capacity
planning is to reduce the cost of running the VMware environment. We answer
questions such as How do I optimize the environment and get better use out of the
HW that I already have? Potentially, I can decommission servers and save on
licensing costs, power, cooling, management costs, etc. Or simply free up
capacity so that I don't need to buy more HW and more VMware licenses. It is not
in VMware's best interest to help customers do that. For us, we're charging per
VM and we really don't care how many physical servers they need.
The Capacity Planning tool is simple to use and no mathematical skills are
required. You only need to understand their business objectives.
It is important to note that IBM SmartCloud Monitoring (SCM) is part of a broader

portfolio. If a customer invests in SCM and sets up the ITM infrastructure, it just requires
an Agent plugin to start monitoring other things in the future. So, if the customer decides
they want to monitor application servers, database servers, response time, or end-to-end
transaction tracking, they can simply plugin a new ITM Agent and be up and running.
There is no need to train in a new tool or setup a new monitoring infrastructure.
Now, lets take a look at the VMware Capacity Planning tool.
The screen capture below shows the initial screen for the VMware Capacity Planning tool.
This tool is designed to be very simple, but powerful. It uses a 5 step process thats
outlined below. Later, well look at each of the 5 steps.
The previous screen shows five buttons that will guide you through the capacity planning
process. In addition, there are URLs and optional advanced steps that well examine.
STEP 1: The first step is the click on the Load Config button. This causes the capacity
planning tool to contact the Tivoli Enterprise Portal Server and gather the configuration
data from the VMware environment. It gathers information about the Data Centers,
Clusters, ESX/ESXi servers, hardware, and virtual machines.
STEP 2: The second step is to define the time range that you want to evaluate. For
example, you might choose to evaluate the last 3 months of historical data. In general,
we recommend that you limit the historical data to about 1 month due to the dynamic
nature of VMware environments. If you environment is very stable, you can evaluate a
longer period of time.
STEP 3: The third step is to define the scope of what you plan to analyze. This step is
worth examining more closely. Click on the Define Scope button and you will see the
screen below.
On this screen, youll notice several important things. First, there are a number of
checkboxes on the left column. These checkboxes define which ESX servers and Clusters
you want to evaluate. Typically, you would only perform capacity planning for the
servers in one physical data center since its unlikely that you will move virtual machines
from one data center to another. However, you might choose to perform capacity
planning on multiple Clusters to try to optimize the workload and determine where new
workloads should be placed.
Notice that there are icons in the menu that allow you to select and de-select all of the
ESX servers as shown below. You can also sort on any of fields to make it easier to find
the ESX servers in a data center.
The most important columns on this screen are the architecture, number of CPU cores,
model, and manufacturer. This information is critical because the capacity planning tool
includes the SPECint benchmarks for thousands of CPU models and numbers of CPU
cores. And, the tool provides the ability to import benchmarks for servers. True capacity
planning can only be done if you understand the capacity of the server where VMware is
running. This is really important to understand. Think about the differences between
a 3.6 GHz processor made 3 or 4 years ago compared to a 2.2 GHz multi-core processor.
You must understand the capacity of the processor in order to accurately do Capacity
Planning.
As long as the VSphere server shows up as green or yellow, it will be taken into account as
you run the capacity planning exercises. If the VSphere servers hows up with a red icon, it
means that either too many benchmarks were found and there were large variations in
the data, or no benchmarks were found. If you want to use that server as part of the
capacity planning exercise, you will need to update the benchmarks in the system so that
your server will be recognized by the tool.
Click on the icon in the upper right corner and you will see the following dialog.
Browse for your Custom Benchmark file. You can use the sample files that are installed
on the system. Go to the
/opt/IBM/ITM/installedDashboards/com.ibm.tivoli.cppowervm/AnalyticsDatabaseInstaller/samples
directory and you will find a USER_DEFINED_BENCHMARK.csv file. You can edit this file or
use it as a template. When you import the Custom Benchmark file, it must reside on the
machine where your browser is running.
If you are looking for the benchmarks for your servers, use the following steps. First, go
to this URL and download the latest benchmarks:
www.spec.org/cgi-bin/osgresults?conf=cint2006;op=dump;format=csvdump
This will download a CSV file.
Open the file in Excel.
Find the entry you are looking for. Make sure you find the server model with the same
number of CPU sockets and cores as your server.
Take column Z and multiply it by 1000. That is the benchmark we use. Add that entry
to the USER_DEFINED_BENCHMARK.csv file and import it into the Capacity Planning tool.
If the benchmark is recognized by the Capacity Planning tool, the icon on the page will
turn Green or Yellow.
View Virtual Machines

Next, lets take a look at the Virtual Machines. Click on Views -> Inventory -> Virtual
Machines.
You will see a list of Virtual Machines in the environment. The list of Virtual Machines
only includes the Virtual Machines running on the ESX servers that you selected in the
previous step. Scroll to the right and you will see several very useful fields. These fields
include Criticality SLA, Primary Business Unit, Primary Business Application, and
Middleware. These fields can be populated via a CSV file or entered manually in the GUI.
This data will be used later in the capacity planning analysis. In addition, you can define
your own custom fields. For example, you might want to add a field such as the ESX
server owner and pager number or the server age. The server age might be useful so to
ensure your mission critical applications run on the newer hardware.
Middleware
Criticality
y
The next step in capacity planning analysis is to view the Virtual Machine Utilization.
Select View -> Virtual Machine Utilization.
Select a subset or all of the checkboxes for the virtual machines. If you dont select any of
the checkboxes, then ALL of the Virtual Machines will be analyzed. If you want to select
all of the virtual machines on the 1st page, select the checkbox in the upper left corner as
shown below.
Business
Unit & App
Then, select Actions -> Compute Usage. This will compute the CPU, Memory, Storage,
and Network usage for each of the virtual machines. When computing the usage, you will
see a dialog similar to the one below. Notice that you can use Average, 90th percentile,
Min, or Max for the calculations. You can also select the Summarization interval. In this
trial image, only the Hourly and Daily Summarization data is configured, so choose either
Hourly or Daily for the summarization interval. As you use this capability, notice a
couple of things. You can choose the time or date ranges that will be evaluated. If you
choose Hourly summarization data, you can select the hours of the day that should be
evaluated. If you choose Daily summarization data, you can choose specific days of the
week and omit weekend data. When you are finished, click the Generate button.
Notice that utilization data for each of the active Virtual Machines will be added to the
table. Next, select Actions -> Generate Workload Stability Type to identify whether the
workload is stable or unstable.
Compute Usage and

Generate Workload
Stability Type
Finally, select Actions -> Edit Usage. In the Edit Usage panel, you can plan for either
absolute or percentage growth in the environment. For example, you might know that
you have just completed an acquisition and need to plan for 20% growth in CPU, 25%
growth in memory, etc. for your VMware environment. The tool allows you to enter the
growth parameters as shown below. This growth planning is for NEW workloads that
cant be calculated by the tool. For example, you might have an acquisition or might be
bringing a new business application online.
Planned
Growth
Factors
After you have completed this step, you can optionally run reports by selecting the
Reports menu item.
After you have finished with this panel, close the tab and go back to the Planning
Center.
STEP 4: The next step in capacity planning is to select the Size VMs button. This
calculates the utilization of the virtual machines. If you generated the Usage in the
previous step, this step is not necessary. It generates the Virtual Machine usage using
the default settings. In step four, you can also click on the link to generate a Current
Environment Report.
Note: This report might take several minutes to complete.

An example report is shown below.
The report includes information about each Data Center, Cluster, ESX/ESXi server, and
virtual machine. The report includes information such as the Capacity Efficiency Index
which is an indication of how efficiently you are using your hardware. The scale is 0 to
100 where 100 is completely efficient.
Capacity
Efficiency
Index
Current CPU Reservation

Recommended CPU Usage
Current Memory
Reservation
Recommended Memory
Usage
Risk factor for the Virtual
Machines
STEP 5: In step 5, you can generate the capacity planning report. However, before you
generate the report, select the Edit Recommended Environment Settings link as shown
below:
You will see the page shown below. This page allows you to select a set of rules you want
to use when performing capacity planning. For example, you might select the rule that
states that you dont want to co-locate virtual machines running WAS and DB2 because
they are both very I/O and CPU intensive. Keep in mind, earlier we were able to define
the middleware running on each virtual machine. If we werent able to do that, we

wouldnt be able to use that information for our capacity planning. When running the
analysis, you can select as many rules as you want. The rules seen in the screen capture
below are the out of the box rules. You also have the ability to define your own rules
using a documented XML based rules language. The screen capture below shows the out
of the box rules. This Policy or rules based capacity planning is a key capability. For
example, you might want to write Boundary or Collocation rules that co-locate as many
similar operating systems as possible on the same ESX servers. If an ESX server is running
multiple virtual machines with the same operating system, VMware will do more memory
sharing. Given that VMware is priced on the server memory, you can reduce your
VMware licensing costs by reducing memory. Other rules might be written for specific
business applications to ensure that they receive enough capacity.
Colocation/Anti-colocation Rules
Boundary Rules
Utilization Rules
Once you have selected the rules that you want, save the changes and click the Generate
Plan button on the Planning Center tab.
The capacity planning tool analyzes the historical data in the Tivoli Data Warehouse and
comes back with a recommendation for each of the ESX servers and virtual machines that
were analyzed. The analysis takes into account each of the rules you selected, the
SPECint benchmark capacity of each server, the current utilization of each system, and
the planned growth for the environment. Here is an example capacity planning report
with suggestions on how to optimize the environment.
Current environment includes 17 ESX

servers that were analyzed. The Capacity
Planning tool indicates that the workload
can be run on 6 ESX servers
Notice that I started out with 17 ESX servers and 43 virtual machines. The capacity
planning tool came back with a recommendation that the entire workload, including
growth factors, can be run on 6 ESX servers. We get better utilization out of the
hardware and can decommission a number of machines. This saves on power, space in
the data center, VMware licensing costs, and the cost to maintain the servers.
Lets examine one of the ways that we optimize the VMware environment. As seen in the
report below, consider multiple VMware Clusters. Cluster 1 might have a very CPU
intensive workload, but low disk I/O and Memory utilization. Cluster 2 might have low
CPU utilization, but high disk I/O and Memory utilization. Cluster 4 might have high Disk
utilization, but low CPU and Memory usage. By moving virtual machines between
clusters per the recommendations from the Capacity Planning tool, we can balance the
workload across the clusters.
The final step in the capacity planning analysis is the what-if analysis that can be
performed. Click on the Define Scope button in the Planning Center. The first what-if
analysis involves adding additional hardware to the environment. For example, I might
want to know which model machine I should purchase to increase the capacity of my
environment.
Select Add Server to

analyze the impact of new
servers on the
environment
Once you select Add Server a list of machine models with the number of CPU cores
appears. You can select an appropriate machine model and perform capacity planning
analysis to see the impact of adding 1 or more servers. This allows you to choose the
best hardware to meet your performance requirements.
Another option is to add a number of fictitious virtual machines. Perhaps I know that I
need to add 50 virtual machines for a new business application or due to an acquisition. I
first select View -> Inventory -> Virtual Machines. Then, from the Actions menu, I select
Add Virtual Machine. I can add 1 or more virtual machines and define the expected
utilization. Then, perform the capacity planning analysis to understand the impact of
adding 50 virtual machines.
If you wish to add fictitious servers and virtual machines, you will need to fill in several of
the fields in the table so that capacity planning can be performed.
Exercise 4: Additional Virtualization Agents

SmartCloud Monitoring includes monitoring agents for VMware, KVM, OS Agents, and
more. In addition, there are virtualization agents available for Citrix XenServer, Citrix
XenDesktop, Citrix XenApp, Cisco UCS, Microsoft Hyper-V, and more. Launch the Tivoli
Enterprise Portal and view the workspaces for the various virtualization/cloud agents.
Launch the Tivoli Enterprise Portal by. Open Firefox and you will see a bookmark named
IBM Tivoli Monitoring (Java Web Start). Or, you can open the following URL in your
browser: http://scmtrial:1920///cnp/kdh/lib/tep.jnlp
Login as user sysadmin with password smartway.
From the Physical Navigation View, expand Linux Systems -> scmtrial -> VMware VI
Agent scmtrial.ibm.com:VM as shown below.
Some of the key features to examine are:
Workspace Links:
One of the best examples of the use of workspace links is the VMware VI Agent. Open
the Clusters workspace and then click on the workspace link next to one of the clusters.
Click on a
workspace link
After clicking on a workspace link, the product will drill down to a detailed page for that
cluster. From the detailed Cluster page, you have a couple of options. First, notice the
Navigator view in the lower left corner. By selecting the workspace link for another
Cluster, you will navigate to an identical workspace, but the context will change to reflect
the selected Cluster. As shown below, select the link for another Cluster.
In addition, you can select the workspace links for an ESX server, Resource Pool, Data
Store, or Virtual Machine and drill down to more details for the selected item. Try
selecting a few of the links to navigate through the VMware VI Agent workspaces.
Click to drill down to the

selected ESX server
Click to drill down

to the selected
Data Store

selected ESX server

selected Virtual Machine
There is one really nice feature that cant be shown with the POT vmware image.
Normally, you can select the links on ESX server pages and link to the operating system
agent. Since the POT image does not contain any OS Agents, these links wont work.
But, it is important to know about this capability.
Click to navigate to the

operating system agent
Before moving on to the next agent, select a few of the other VMware VI Agent
workspaces. Some key metrics to focus on are Percent Ready on the CPU page and the
Balloon Used and Swap Used on the Memory page. If the Percent Ready is high or
the ESX server has high Swap usage, your performance will degrade.
Exercise 5: VMware Expense Reduction Report

The following section will guide you through the process of generating the VMware
Expense Reduction Report and interpreting the results. This report ships with the IBM
Tivoli Monitoring for Virtual Environmants/IBM SmartCloud Monitoring products. This
report can show the potential savings that can be gained by using the VMware Planning
tool and monitoring data. By using the steps below, you should be able to generate the
VMware Expense Reduction Report and demonstrate the product capabilities within 1
day. However, the longer you gather historical data, the more accurate the report will
be.
If you dont have time to gather a week or more of historical data, as described earlier,
you can use the Synthesize History to generate historical data.
It is important to note that the Capacity Planning tool and VMware Expense Reduction
Report require a minimum of 2 days of historical data. You can either gather 2 full days
of historical data or use the Synthesize History utility.
Before Running the VMware Expense Reduction Report

Before you run the VMware Expense Reduction Report, you must go through most of the
steps of the Capacity Planning tool. The Capacity Planning tool allows you to select all or
a subset of the VMware Clusters and VSphere servers. It also allows you to specify times
of day or days of the week to calculate the VMware utilization data. The utilization data
must exist in the capacity planning tool before the VMware Expense Reduction Report
can be executed. We suggest that you go through the Capacity Planning Exercise prior to
running the VMware Expense Reduction Report. This will ensure that all of the data is
available for the report.
Running the Report

To run the report, you must first login to TIP. Login to the following URL as smadmin with
password smartway: https://scmtrial:16311/ibm/console/logon.jsp
From within DASH, click on Common Reportingand then select the IBM Infrastructure
Management Capacity Planner Reports for VMware. You will see a screen similar to the
one below.
Click on the VMware Expense Reduction Report to run the report. You will also see the
report at the bottom of the Capacity Planning tools main page:
When running the report, you will be prompted to provide input data about the
environment. The following parameters are required to run the report:
Data Centers: Select one or more Data Centers. If you select ALL, then all of
the monitored Data Centers will be evaluated.
Clusters: Select more or more of Clusters listed. You can select ALL if you wish
to report on all of the monitored Clusters.
Shift Periods: Since this Warehouse is not setup with Shifts, choose All Shifts
Vacation Periods: Since this Warehouse is not setup with Vacation Periods,
choose All days
Next, there are a number of questions that ask the about the enterprise wide
VMware deployments. These numbers can be rough estimates. The idea is to use
the actual monitored data to extrapolate the potential savings across the
enterprise. Since we dont know the actual utilization and hardware in the
enterprise, this is just a rough estimate, so these numbers dont need to be

extremely accurate:
o Number of Clusters: This represents the number of VMware Clusters
across the enterprise. We will gather historical data from a subset of the
systems, but we want to be able to extrapolate the data to represent the
enterprise.
o Number of vSphere Servers: Again, we will gather historical data for a
subset of the systems, but we want to be able to extrapolate the data to
represent the enterprise.
o Number of Virtual Machines: For the vCenter(s) that were evaluating, we
will have an accurate count of the virtual machines, but we need a rough
estimate for the enterprise in order to extrapolate the potential savings.
o Number of Data Stores: We are looking for a rough assessment of the
number of data stores across the enterprise. Again, for the monitored
environment, we have the actual number of data stores and their
utilization. This field is to estimate potential savings across the enterprise.
o Memory (GB): Again, this is a rough estimate for the entire enterprise.
Lets assume you have 100 vSphere servers with an average of 64 GB of
memory per server, then enter 6,400 GB of RAM
o Number of CPU cores: This is a rough estimate for the enterprise. If there
are 100 vSphere servers and they are typically quad core servers, then you
would enter 400 in this input field.
o CPU (GHz): This is a rough estimate for the enterprise. If the typical
server is 2.5 GHz, then its easy to calculate based on the number of CPU
cores entered above.
o DASD (TB): This is a rough estimate on the total number of Terabytes of
storage being used for VMware across the entire enterprise.
Next, we need to specify the cost basis for the data center(s). The cost of
running a virtualized environment varies considerably from country to country and
can vary quite a bit within a country. For example, labor costs are significantly
higher in New York and Silicon Valley than in other parts of the United States.
Answer the following questions to the best of your ability based on the locations
of the data center(s) and estimated costs. The Cost Basis Examples section
contains some examples for the United States and includes more detailed
explanations of the input parameters.
o Currency: This represents the currency used for in the report. For example,
this might be US dollars, Euro, Pounds, or some other currency. All other
input parameters should be specified in this currency.
o Hardware cost per server: This is the average cost of each server that
comprises the VMware environment.
o Administrative cost per server: This is the average cost of administering a
vSphere Server.
o VMware Licensing per CPU Socket: This is the annual cost of licensing
each CPU socket. VMware licensing is based on the number of sockets
used for the vSphere environment. Please take into consideration any
discounts that your company receives from VMware.
o Energy cost per server per year: This is annual cost for power and cooling
for a typical server in the VMware environment.
o Flooring space per server: This is the average cost for floor space for each
of the vSphere servers.
o Storage cost per TB: This is the average cost to purchase and maintain a
Terabyte of storage for the VMware environment.
o SmartCloud Monitoring software cost per VM: The list price for IBM
SmartCloud Monitoring is $225/Virtual Machine. Before entering this
information, there are a couple of things you should consider.
What is the software price for your countrys currency? $225/VM is

the price in US dollars.
How much of a software discount will you receive?
If you are already paying for VMware monitoring, you might

consider entering zero for this value to represent the fact that
there will be no difference in the price being payed for
management software.
Finally, enter the time range for the report to evaluate. You can select the drop
down box and choose Last 7 days, Last 30 days, etc. Or, you can select Date
Range (below) and then select specific Start and End dates for the report.
Once you have completed all of the input parameters, click Finish to run the
report. Given that the report has extensive amounts of data, we recommend you
have the report printed out on a poster. Otherwise, you can zoom into different
sections of the report. The report was designed for a 22 x 28 poster. Please
keep in mind that some companies like Fedex/Kinkos require 24 hours to produce
a large report. The cost to print the report on a 22 x 28 poster was around $45
US dollars at Fedex/Kinkos.
Cost Basis Examples

This section contains examples of the cost basis for running a vSphere server. Each
location and company has unique costs associated with running their data centers, but
these represent industry averages. Use this information as a guideline, but adjust these
numbers to reflect your costs. Here are the assumptions made below for the cost basis.
You can adjust these numbers based on your location. The costs listed below are for a
typical data center in the US.
Server pricing is an estimate based on the number of CPU sockets. Here is the
rough cost depending on the number of CPU sockets. These prices assume that
the customer is purchasing the latest multi-core processors. VMware pricing is
based on the number of sockets, so the number of cores will not affect the
VMware licensing cost.
o Blade (Dual Socket): $10K (includes overhead for BladeCenter)
o 2 Sockets (4 cores per socket): $18K
o 4 Sockets (4 cores per socket): $30K
VMware pricing in US dollars is $2875 per socket. All of the examples below
assume that cost with adjustments made for currencies. In addition to the base
cost, there is an addition $4995 cost for vCenter and an annual support cost of
$719/socket.
o This is the cost of the VMware vSphere Enterprise product. If the customer
uses vSphere Standard, the list price is $995. If the customer uses vSphere
Enterprise Plus, the list price is $3495.
Many customers get a discount off the list price. Specify the actual price
paid per socket.
Rough estimates in the United States for Storage Total Cost of Ownership (TCO), is
roughly $10,500 per TB. There are some factors to consider that will vary based on
your location. Recommendation is to plan for 1.5 people for every 100 TB of
storage being managed. If a person costs $120K/year, then you will have an
annual cost of $180K/year to manage 100 TB of storage. In addition, you must
consider the support costs for the storage hardware as well as space, power, and
cooling in the data center.
Power and Cooling costs:

o Cost/KWh for power (this will vary based on your location). For the US, we
are assuming $0.10 per kWh for power. Typically, the cooling costs are
approximately the same as the power costs and must be included in the
cost.
2 Socket Blade: 375 Watts ($329/year) Double the cost to include

cooling ($658/year)
2 Socket, 8 cores: 415 Watts ($364/year).

include cooling ($728/year)
4 Socket, 16 cores: 700 Watts ($613/year) Double the cost to

include cooling ($1226/year)
Double the cost to
Floor space costs. This is the cost per server for floor space in the data center.
o Estimated cost per rack is $16K in the US. Standard rack is 44U. Assume 2U
for 2 socket systems, 4U for 4 and 8 Socket systems. BladeCenter is 12U
and hosts 12 blades.
o After including space for a network switch, each rack can host:
36 Blades
21, 2U systems
10 4U systems
o So, calculating the average cost per server based on $16K/rack gives us:
$444/blade
$762/2 Socket system
$1600/4 socket system
Administrative cost per server for a VMware server:

o $1363/2 Socket server
o $2100/4 Socket server
Interpreting the Report Results

The following section describes how to use and interpret the VMware Expense Reduction
Report. There are two key aspects to the VMware Expense Reduction Report. First, it
provides most of the key performance metrics and ROI savings using the customers data.
The ROI report is a very large report that contains a tremendous amount of valuable data.
It is recommended that the report be printed on standard sized poster (22x28 or the
metric equivalent). By providing the data on a poster, you can immediately see the value
of combining many key KPIs and ROI data on the same report. If its not possible to
generate a Poster-sized report, you can create a report using 6 standard 8 x 11 pages
and then tape the pages together. If you take this approach, youll need to print the
pages with no margins on the pages. Many customers like to generate this report or a
similar report on a regular basis. Some of the information in the report is intended for
the VMware administrators and/or capacity planning team and some of the data is
intended for the management team. If desired, you can use the Cognos Report Designer
or Report Studio to split this into two separate reports for each target audience. Here is
a sample report. In order to see the report details, you will need to zoom in.
The report is organized into two main sections. The first section describes the customers
environment. It contains information about the environment that was evaluated. If the
customer can provide information about their overall environment, the report will include
that information as well in the upper left corner. The main idea is to show the customer
key aspects of their VMware environment. Key points are:
How much capacity remains in the cluster(s) that were evaluated and what is the
bottleneck? This chart helps customers identify whether CPU, Memory, or Disk
space is their primary bottleneck if they want to add more virtual machines. As
you can see in the example below, there is capacity for only 44 virtual machines
when Memory is evaluated. We highlight the bottleneck in red.
Is the environment balanced or unbalanced? If there is a significant variation in

CPU, memory, or data store utilization between the clusters, then there are
opportunities to improve utilization in the environment. Notice in the sample
reports below, that one of the clusters has high CPU utilization while one cluster
has extremely low utilization. Meanwhile, a different cluster has very high
memory utilization while other clusters have very low memory utilization. It is
important to analyze all of the key metrics to ensure that by balancing the CPU
workload you dont introduce other problems into the environment such as
Memory constraints.
CPU Percent ready is one of the most important KPIs in a VMware environment. If the
virtual machines in a cluster have high CPU percent ready, it means that the virtual
machines are pausing while waiting for available CPU cycles. In general, if CPU percent
ready is greater than 5% you will notice some performance degradation. If it reaches 10%,
there could be a significant impact on performance. What the CPU Percent Ready graph
shows is the average across all of the virtual machines in the cluster. This is being
evaluated at the cluster level due to the fact that nearly all customers use DRS to
automatically load balance the environment. The report contains a graph showing CPU
percent ready for all of the clusters. As you can see in the graph below, one of the
clusters has extremely high average CPU percent ready for the virtual machines. A second
cluster is running at close to 10% CPU Percent Ready. That would be considered a
Warning for a production workload. As you discuss this chart with customers, point out
any Clusters with CPU percent ready that is high.
In the bottom left, you will see a few graphs showing the Virtual Machine KPIs.
The idea is to identify the outliers. These are the virtual machines at the extremes
in terms of performance utilization.
o The first graph shows the top 10 virtual machines in terms of the number
of snapshots. Large numbers of snapshots can cause two problems. First,
any machine with a snapshot will perform slower than a virtual machine
without snapshots due to the fact that VMware has to keep track of the
changes that have occurred in the virtual machine. Second, snapshots
required a lot of disk space. Typically, you dont want more than one
snapshot for a virtual machine. Ideally, Virtual Machines that are in
production wont have any snapshots unless they are undergoing

maintenance.
o To the right of the snapshot graph is a list of the top 10 virtual machines in
terms of swap space used. In general, you dont want any Swap space
being used by virtual machines. This is due to the fact that the virtual
machines are using shared storage and storage I/O and latency is often the
biggest performance bottleneck in a VMware environment. As you review
the report, make note of any Virtual Machine with swap space above
about 5 Meg. One of the tricky aspects to interpreting this report is that
Linux virtual machines will typically use a little swap space, but if it grows
larger than about 5 Meg you are probably running low on memory within
the virtual machine. Windows systems should show zero swap space
used.
o The pie charts represent a summary of all virtual machines. Depending on

the results, you might notice the number of virtual machines that are
powered off. You might notice the number of virtual machines that dont
have the VMware tools installed, have outdated VMware tools, or the
VMware tools arent running. Having running and updated VMware tools is
critical to having a healthy VMware environment. VMware will run more
efficiently with the VMware tools installed and our monitoring products
have some functions that require the VMware tools.
This report shows the number of VMs that are powered on and powered
off.
o The last two graphs show the bottom 10 virtual machines based on CPU
and Memory utilization. This helps identify virtual machines that are good
candidates for workload consolidation. For example, if a virtual machine is
only utilizing 3% or 5% of a virtual CPU, you might be able to combine this
workload with another production workload. By combining the workloads,
you eliminate the overhead of running an extra operating system, you save
on OS licensing costs, and you save on the management costs for
managing an extra virtual machine. By combining virtual machines, you
can reduce the storage utilization as well as the overhead from running the
operating system. While this information is not included in the ROI savings,
it is important to note that this represents additional potential ROI savings.
Of course, you must take into consideration the effort to consolidate
workloads and decide whether it is worth the effort. Some workloads such
as databases are very easy to consolidate while others require significant
effort.
Recommend Optimizations and Potential Savings
The two sections of the report on the right represent the recommended
optimizations and potential savings. The column on the left represents the
recommended optimizations. The column on the right represents the potential
ROI savings that can be gained by implementing the suggested optimizations. Lets
take a look at each section.
Optimizations:
o The top of the report shows the environment that was evaluated and what
the environment would look like if the recommendations are
implemented. In the example report, notice that we started with 47
vSphere servers and 7,136 GB of memory. By optimizing, we can run the
same workload on 21 vSphere servers and 4,064 GB of memory. In this
scenario, we even planned for a small increase in the number of Virtual
Machines from 883 to 912. By reducing the number of servers and
memory, we can reduce the cost of running the VMware environment.
First, we reduce the VMware licensing cost. We reduce the cost of
administering the VMware environment. We reduce the cost of the
servers used in the vSphere environment. And, we reduce the power,
cooling and cost for space in the data center. Another way to look at this
result is to see how much extra capacity is available in the environment. If I
can run the current workload on 21 vSphere servers, then I have 26 servers
available to run other workloads.
In the following sections of the report, you will see the expected utilization
before and after optimization. The report includes information for each Data
Center that was evaluated. Notice that we always reserve extra headroom for
the environment to ensure that the customer doesnt run out of capacity.
Assuming this is the case, note that we have reduced CPU and Memory
utilization in the Data Center(s).
The next section of the report shows the expected utilization before and after
optimization for each of the Clusters in the Data Center. The report includes
information for each Data Center that was evaluated. Notice that we always
reserve extra headroom for the environment to ensure that you dont run out
of capacity. Assuming this is a typical result, notice how we have reduced CPU
and Memory utilization in the Clusters.
In the next graph, we show the top 10 Virtual Machines that have their CPU or
Memory incorrectly defined. Ideally, customers want their Resource
Reservations to closely match the actual utilization of the Virtual Machines. If
the reservation is significantly different, it can indicate a problem. Overallocating CPU or Memory wastes resources. Lets take a look at an example. If
I reserve 4 GB of Memory for a Virtual Machine, but the actual utilization is
around 2 GB, Ive wasted 2 GB of Memory because VMware will not allow
other Virtual Machines to use that memory. The same is true for CPU, Disk I/O,
or Network reservations. This provides an easy way to reduce the overall
utilization of a VMware environment. Conversely, if virtual machines are
under-reserved, the virtual machines are at risk. Lets take a look at an

example. Assume I reserve 512 MHz of CPU for a virtual machine. If I find that
this Virtual Machine typically uses 2 GHz of CPU, then there is a risk that the
virtual machine wont get the 2 GHz of CPU capacity that it needs during
Cluster CPU spikes in utilization. This reports the top 10 reservations in terms
of how much they vary from the actual utilization. When looking at this report,
please keep in mind that some customers dont use any resource reservations
and other customers only setup reservations for a subset of their virtual
machines. For example, some customers only setup reservations for their
mission critical virtual machines.
o Finally, we show a complete list of the Virtual Machines that we

recommend the customer move from one cluster to another. By
moving Virtual Machines between clusters, we can achieve a more
balanced workload among the existing clusters and free up capacity.
On the first page of the report, you will see approximately the first ten
Virtual Machines that we recommend moving between clusters.
However, there may be many more virtual machines listed on the
remaining pages of the report.
Return on Investment (ROI)

This section describes the potential return on investment (ROI) that can be gained in the
environment. The report contains two key graphs. The first is an ROI assessment of the
Clusters that were evaluated during the trial. The second is a rough estimation of
enterprise wide savings that can be gained. The estimation is an extrapolation that makes
some assumptions about the environment. It assumes that the cost basis and potential
utilization savings are the same for all data centers. That may not be the case, but it will
give you a rough idea of what ROI can be gained.
The first set of data is information that is input when the report is executed.
This represents the cost basis for the data center that is being evaluated.
The cost of running a virtualized data center, vary considerably depending on
where the data center is located. This input data represents an estimate for
the evaluated data center. The key fields where you see a lot of variable are
the following:
o Currency: This represents the customers currency

o Hardware cost per server: This varies based on the currency and
based on the type of server that the customer uses in their VMware
environment. For example, some customers run smaller quad
processor blades and other customer use larger 32 core systems.
o Administrative cost per server: This can vary considerably depending
on the location of the data center. For example, the cost of labor in
New York City is significantly higher than other parts of the United
States. The cost of labor is different around the world and within
various cities within each country. Work with the customer to come up
with a reasonable administrative cost per VMware server.
o Virtualization Licensing cost per CPU socket: This varies primarily
based on the customers currency and on the number of CPU cores in a
typical vSphere server. Starting in late 2012, the licensing cost is based
on a per-socket pricing model, so the number of cores doesnt matter.
o Energy cost per server per year: This is a combination of both Powers
utilized by the server and cooling to cool the data center. Since power
costs vary quite a bit around the world, this will vary quite a bit.
o Flooring space cost per server: This is the cost to maintain a server in
the data center. It is usually based on the physical size of the server
and varies depending on the types of servers the customer uses for
their VMware environment.
o Storage cost per TeraByte: This is the cost of the hardware and
management of a TeraByte of storage.
o Smart Cloud Monitoring software cost per VM: This is the list price of
the Smart Cloud Monitoring software per Virtual Machine.
o The first ROI report describes the estimated return on investment for
the Clusters that were evaluated during the POC. The current
environment and optimized environment monetary amounts are
based on data that is input to the report. For example, if there are 30
vSphere servers and each server requires $2,100 in administrative
costs, the total administrative cost is $63,000.
Notice that the storage cost for the current environment and optimized
environment are the same. There are opportunities to reduce the
storage utilization, but it is difficult to estimate in this ROI report. For
example, we identify virtual machines with VMware snapshots. If the
snapshots are removed, the storage utilization will be reduced.
However, we dont know which snapshots are required, so we cant
quantify the savings. In addition, we identify virtual machines that are
good candidates for consolidation based on low CPU and memory
utilization, but this needs to be a business decision. So, note that
storage savings are available, but we havent quantified that as an ROI
savings. Just below the graph, in blue letters, you will see the overall
ROI percentage savings for the environment.
o The second ROI chart represents the potential savings across the
enterprise. This is a linear extrapolation across the enterprise. As you
examine the ROI savings, it is important to understand that the same
cost basis was used across all data centers. If the cost basis is
different between data centers, it will affect the overall ROI savings.
This report is intended to give you an idea of the potential savings by
using the IBM SmartCloud Monitoring Capacity Planning tools. Once
again, notice that we provide both a total cost savings and a
percentage ROI for the environment.
o It is important to note that the ROI report includes software costs for
monitoring the VMware environment. In some cases, the customer
already has monitoring tools and purchasing IBM SmartCloud

Monitoring would not increase their overall cost. In other cases, the
customer doesnt have any monitoring tools in place. If so, they must
take into account the additional cost of the monitoring software.
PowerVM Environments
The IBM SmartCloud Monitoring product includes a power set of capabilities for
managing your PowerVM environment. It includes deep monitoring for the PowerVM
frames, the HMC, Virtual I/O Servers, and all of the LPARs in the environment. In
addition, the product ships with a capacity planning tool for PowerVM environments.
Combined with the Predictive Analytics capabilities of the Performance Analyzer, and
customers have a powerful set of tools for monitoring and planning for their PowerVM
environments. The following diagram outlines a typical PowerVM system and how the
IBM SmartCloud Monitoring product is used to monitor the environment.
In a typical environment, the following agents are deployed to monitor the PowerVM
environment.
HMC Agent
An HMC Agent is deployed on an AIX LPAR to remotely monitor an HMC, SDMC, or FSM.
The HMC Agent remotely connects to these systems via ssh. In the case of the FSM or
SDMC, the HMC gathers performance and configuration data about the systems that the
FSM or SDMC is managing. In the case of the HMC, the Agent gathers information about
the systems that the HMC is managing and gathers health and performance information
about the HMC. Details on configuring the agent follows in the next section.
VIOS Agent
The VIOS Agent is pre-installed into the Virtual I/OS Server operating system. Because
the Agent is periodically updated, we recommend you keep the version of the VIOS fairly
current. This will ensure that your monitoring agent will have the latest features and
optimizations. To use the Agent you simply issue 1 command to configure the agent and
then a 2nd command to start the Agent. Details on configuring the agent follows in the
next section.
CEC Agent
The CEC Agent is installed on an LPAR that has network connectivity to the CEC. This
agent provides frame level utilization data for the CEC that is being monitored. This
agent provides detalied information about Memory, CPU, Disk, and Network performance
of the frame including utilization data of the LPARs running on that CEC. It is limited to
providing LPAR utilization data for AIX LPARs.
UNIX OS Agent
The UNIX OS Agent is installed on each LPAR or physical AIX system. It gathers detailed
performance metrics for the operating system. It gathers a combination of generic UNIX
metrics that apply to all UNIX operating systems and gathers AIX specific metrics including
WPAR data.
Linux OS Agent
The Linux OS Agent is similar to the UNIX OS Agent. The Linux OS Agent is installed on
the It gathers detailed performance metrics about the Linux operating system running
on a PowerVM LPAR. The data includes CPU, Memory, paging, networking, Disk space,
Disk I/O, process performance, and more.
i5/OS Agent
The i5/OS Agent can be used to monitor i5/OS LPARs. This is installed on the i5/OS
system and gathers in-depth performance metrics for the i5/OS operating system. In
addition to configuration data, system performance, and other metrics similar to the
UNIX OS and Linux OS Agents, the i5/OS Agent also gathers database performance
metrics as well as messaging and queue data.
Agentless OS Agents
Some customers desire to monitor their systems remotely. IBM SmartCloud Monitoring
comes with a set of Agentless OS Agents to monitor UNIX operating systems, Linux
operating systems, and Windows operating systems. The monitoring capabilities are not
as deep as the agent-based monitoring, but is lighter weight and faster to get up and
running. Depending on the operating system, the methodology for gathering remote
performance metrics is slightly different. The following describes how each operating
system is monitored:
Windows: Windows can be monitored remotely using either WMI or SNMP.

In the case of SNMP, you have the option of using SNMP v1, v2c, or v3.
Linux: Linux systems can be monitored remotely using SNMP v1, v2c, or v3
AIX: AIX systems can be monitored remotely using SNMP v1, v2c, or v3
HP/UX: HP/UX Systems can be monitored remotely using SNMP v1, v2c, or v3
Solaris: Solaris systems can be monitored using SNMP, CIM, or via the SunMC
Agent. In the case of SNMP, you have the option of using SNMP v1, v2c, or v3.
Configuring the PowerVM Agents:

This section provides links to the documentation for installing and configuring the
PowerVM Agents. However, steps are provided in Appendix A: Remotely Deploying
Agents in this manual. The individual product manuals can be found here:
Tivoli Documentation Central contains all of the documentation. The top level URL is:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%2
0Documentation%20Central/
The ITM 6.3 FP1 Installation Guide contains some general purpose information for
installing agents such as the UNIX OS Agent and the Linux OS Agent:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/itm63FP1_
install.pdf
For HMC Agent specific information, use the HMC Base Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/phmcagen
t6223_user.pdf
For VIOS Agent specific information, use the VIOS Premium Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/pviosagent
6222_user_rev.pdf
For CEC Agent specific information, use the CEC Base Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/pcecagent
6222_user.pdf
For the UNIX OS Agent, use the UNIX Agent Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/unixosage
nt63_user.pdf
For the Linux OS Agent, use the Linux Agent Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/linuxosage
nt63_user.pdf
For the i5/OS Agent, use the IBM I Users Guide:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/ibmiosage
nt63_user.pdf
The Agentless OS Agent Users Guides can be found here:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/nav/1_1_6_2
PowerVM Monitoring exercises

Once you have the PowerVM Agents deployed, exercise the product capabilities. Lets
examine each of the PowerVM Monitoring Agents.
VIOS Agent
Begin by examing the VIOS Agent. You will find this agent by looking in the Tivoli
Enterprise Portal Server under the UNIX OS Agents and finding the hostname of the VIOS
Server. Much of the information gathered by the VIOS Agent is general UNIX OS metric
data such as Memory, CPU, and Disk utilization. However, the VIOS Agent contains some
important information specific to the Virtual I/O Server. Start by looking at the Virtual
I/O Mappings.
If you right click on Virtual I/O Mappings, you will see 3 workspaces including Network, Storage,
and NPIV mappings.
Next, select Networking and right click. You will see a few workspaces related to the Shared
Ethernet Adapter (SEA). Examine the Shared Ethernet Adapter workspaces.
Next, select Storage and right click. Select the MPIO Stroage Information workspaces.
Finally, select the Situation Editor and examine the out of the box thresholds for the VIOS Agent.
There are many additional metrics and workspaces available for the VIOS Agent. Feel free to
navigate through the workspaces and view the metrics.
Next, open the DASH server and run some of the PowerVM TCR Reports.
HMC Agent
The HMC Agent is one of the most important agents in gaining visibility into your overal PowerVM
environment. This agent contains three types of data. First, it contains data about the health and
performance of the HMC. Given the importance of the HMC in managing your PowerVM
environment, you want to make sure that you are monitoring the health of the HMC. By clicking
on the System navigator item, you will see the health and performance data for the HMC. Next,
the HMC provides summary information about all of the frames that it is managing. In
SmartCloud Monitoring version 7.2 FP2, Frame level and LPAR CPU utilization is now reported by
the HMC Agent. By clicking on the Managed Environment workspace, you will see configuration
and performance data for each frame as seen below.
Finally, you will see a sub-node for each of the physical servers that the HMC is managing. That
subnode contains detailed information about the performance of the frame as well as
performance and configuration data for the LPARs that are running on that frame. See the
worksapce below.
If you click on the LPARs workspace, you will notice that there are workspace links next to each
of the LPAR Names. If you click on one of the links, you will drill down to a detailed page for the
select LPAR:
CEC Agent
You will notice in SmartCloud Monitoring 7.2 FP2, that some of the metrics that customers would
normally monitor using the CEC Agent can now be found in the HMC Agent. In particular, CPU
utilization for the frames and LPARs is now reported by the HMC. The CEC Agent provides
detailed information about the CEC or frame. You will see overall utilization of the CEC as well as
utilization data for the LPARs that are running on the CEC. The CEC Resources workspace shows
the overall resources and allocations for the CEC. The CEC Utilization workspace shows
utilization data for the CEC and for the LPARs. Navigate through the CEC Workspaces and
Situations to see what the CEC can monitor.
UNIX OS Agent
The UNIX OS Agent has a set of common monitoring capabilities for AIX, Solaris, and HP/UX. In
addition, there are some AIX specific metrics that you will want to examine. First, start by looking
at some of the default workspaces for Disk, Network, Process, System Information, etc. Begin
with the very top level workspace by clicking on UNIX OS for a particular server.
On this screen, you will notics a summary of some of the key attributes such as Virtual Memory
utilization, Top proceesses, and Disk space. If you right click on UNIX OS, you will notice that
there are other workspaces available. As you navigate through the product, you will notice that
some workspaces have the word (Supersded) at the end of the workspace name. These are
older workspaces that are designed to support older versions of the agent. For the purposes of
this trial, all of your agents are current and you shouldnt bother with the Superseded
workspaces.
Next, click on some of the other navigator items such as System Information. Youll notice that
there is an icon in the upper left corner of most of the Views on the Workspace that looks like a
calendar with a clock overlayed on the calendar. That indicates that there is historical data
available for those metrics as seen below.
Click on the Historical icon and you will see the following dialog. You will notice several options
including the ability to select shifts or specific time ranges. The most important options are
highlighted below. First, you can select between real-time data, real-time plus the last X
number of hours, or Last. When you choose last, you can choose the last X number of hours,
days, weeks, months, etc. In addition, you have the option of choosing between detailed data
and summarized data. By default, the summarized data will show you Hourly, Daily, Weekly, etc.
data using an Average for that time period.
In addition to the generic UNIX OS metrics, this agent contains some AIX specific metrics including
WPAR data. Lets examine some of the AIX specific metrics.
First, right click on System Information. You will notice that there are several workspaces
available that are AIX specific. If you have WPARs in your environment, select one or more of the
WPAR workspaces. Otherwise, select the AIX LPAR Information workspace. You will find a lot
of useful information regarding the LPAR. For example, you will see the entitlement, whether the
LPAR is in Shared Mode, Capped Mode, SMT Mode, etc. Finally, you will see the CPU utilization
for the LPAR. This CPU utilization takes into account the entitlement, the number of virtual CPUs,
etc.
Next, right click on Disk Usage and you will see a workspace titled AIX Storage which contains
some AIX specific storage metrics.
Linux OS Agent
The Linux OS Agent does not contain any PowerVM specific metric, but it does contain a wealth of
useful Linux metrics to ensure the Linux OS is healthy. This same Agent can be used to monitor
Linux on Intel/AMD systems, PowerVM systems, and Linux on System Z. Start by selecting the
top level workspace by clicking on Linux OS. You will see the workspace listed below. Then
proceed to view other workspaces contained in the Linux OS Agent. If you right click on many of
the navigator items, you will notice that there are multiple workspaces available. For example,
by right clicking on System Information, you will see workspaces for System Information, Virtual
Memory, Disk I/O, and System Configuration.
PowerVM Capacity Planning

Finally, lets take a look at the PowerVM Capacity Planning tool. This tool is very valuable for
running a number of what-if scenarios to ensure that you have capacity for your current workload
and can plan for future growth and new workloads. This section will walk you through a scenario
using the Capacity Planning tool for PowerVM systems. Keep in mind that there are other
capabilities that are available and I encourage you to try out the other features. There are a
couple of fundamental principals that were used in developing the capacity planning tool. We
wanted the tool to be simple to use and not require a PHd in mathematics to use. We wanted the
tool to be customizable so that customers can align their capacity plans to meet their business
objectives. For example, we dont want to treat all LPARs the same because some are running
development and test workloads, others are running production workloads, and others are
running mission critical applications. The tool has the flexibility that customers can tailor their
capacity plans to meet their needs.
The capacity planning tool has a few prerequisites. You must have the HMC Agent installed and
configured. You must have OS Agents installed on all of the UNIX and Linux LPARs. You must
have the VIOS Agent installed on each of the systems that you want to analyze. Finally, you must
have 2 days of historical data collected for these agents. As stated earlier in this document, there
is a synthesize history tool in the /history_tool folder that allows you to accelerate the generation
of historical data. To run the synthesize history tool, you need at least 2 hours of historical data.
The Capacity Planning tool uses a simple five step process that is outline below.
1. The first steps simply loads the configuration data from the IBM Tivoli Monitoring (ITM)
tool. This loads in information about the physical servers and the LPARs in the
environment.
2. The 2nd step sets the historical time range that you want to evaluate. In general, the more
historical data that you have, the more accurate your capacity planning will be. However,
if your environment is fairly dynamic and you are frequently adding/deleting LPARs or
changing LPAR allocations, then you dont want to go back too far in time when doing the
analysis.
3. The 3rd step defines the scope of what you want to analyze. This is where you will choose
the type of capacity planning exercise that you want to do. For example, you might
select 1 physical server and run a scenario to see if that server has capacity for 10
additional LPARs. Or, you might select several servers and plan for 20% growth.
4. In the next step, you calculate the utilization data for the servers you selected in the
previous step.
5. Finally, you generate the Capacity Plan. During this step, you will have a few options. For
example, you can choose to analyze your existing hardware model and determine
whether it has capacity for 10 additional LPARs or 20% growth. You can ask the capacity
planning tool to make a recommendation on machine models to run a specified workload.
Or, you can do a side by side comparison of multiple server models to see how a given
workload will perform.
Now, lets walk through a scenario. We begin by loading the configuration. You can
either load all of your PowerVM systems or select the Load data for selected Managed
Systems as seen below. If you select this option, the tool will bring up a list of your
frames and you can select one or more to analyze.
Next, you click the Set Time button and the following dialog will open. As was mentioned
earlier, be careful about going back too far in time to analyze your environment if there have
been a lot of changes.
When you click on the Define Scope button, you get into the main portion of the
capacity planning tool. First, you may notice that some of the systems have a green
checkbox next to them and others have a red X icon. If you see the red X icon, it means
that you dont have an OS Agent running on one of the LPARs. The UNIX OS Agent is
required in order to get detailed information about the server model and configuration.
On this page, select one or more servers to analyze as shown below. In this case, Im
going to run a scenario where Im going to analyze one server and determine whether it
has capacity run some additional LPARs.
Next, select the View->Inventory->Logical Partitions menu. This will show you a list of LPARs
running on the server(s) you selected in the previous step. The first screen capture shows some
of the configuration details for the LPARs. In the 2nd screen capture, Ive scrolled to the right to
show some additional fields.
Notice in the 2nd screen capture that there are two fields on the right that are blank. There are
some additional fields that are hidden that you can view by selecting the Configure Options icon
at the top of the table. Whats important about these fields is that they allow me to identify key
aspects of the LPARs. I can identify the primary business application and whether the LPAR is
mission critical. This is important because it allows me to tailor my capacity plan based on that
data. This information can be imported via a bulk import or entered on the screen. In the next
screen capture, youll see that Ive imported the data to fill in those fields. You can also create
your own custom fields in the tool.
In our scenario, I want to perform a capacity planning exercise to see if this server can host 3
additional LPARs. To do this, I select the Actions->Add Logical Partitions menu item and I will
select it 3 times.
You should now see three blank rows of data at the bottom of the screen. Before I can use these
3 new LPARs as part of my capacity planning analysis, I must assign some configuration values to
these LPARs. For example, I need to assign a hostname, Entitlement, assigned memory, OS
version,etct. Fill in the required fields and press the Save button.
The next step is to select the View->Logical Partition Utilization menu item. The first time you
view this page, all of the fields except the first three will be empty. You will now calculate the
utilization data for each LPAR. You have some options on how you calculate the utilization. You
may choose to analyze all of the LPARs in the same manner, or you can select individual LPARs
and perform the analysis. For this exercise, we well analyze all of the LPARs in the same manner.
Select the Actions->Compute Usage menu item and the following dialog will appear.
When you calculate the utilization, we recommend you choose either 90th percentile or
Maximum. The tool expects the peak or near-peak utilization. Keep in mind, the Trial image is
only configured to gather Detailed, Hourly, and Daily summarization data, so you cant choose
Weekly, Monthly, etc. to perform the analysis. In the dialog below, I have shown a few options.
In this example, I have chosen 90th percentile for CPU. I have chosen Hourly averages for peak
shift hours for Memory data. Since memory data is not very dynamic, Averages will work fine.
For Storage, I have chosen to use a Daily Maxiumum for weekdays only. For Network data, I have
chosen to use an Hourly Maximum and analyzed all hours of the day. Depending on your
workload characteristics, pick the option that makes the most sense. And, you may find that you
dont want the same options for all of your servers.
When you are done, click the Generate button and it will calculate the utilization data.
For the 3 fictitious LPARs that you added, you will need to manually assign a workload. In the
screen capture below, I have filled in that data based on a historical report on those LPARs. To
edit the usage, select the checkboxes on the left and select Actions->Edit Usage.
Next, select the Action->Generate Workload Stability Type. This will calculate whether the
workload is stable or unstable. Unstable workloads are very spiky in nature and add risk to an
environment.
You may now close the Edit PowerVM Current Environment tab and go back to the main
Planning Center Page. From the main page, you can skip the Analyze LPARs step. You already
did that when you generated the utilization data for your LPARs.
Finally, were ready for the Step 5. Before clicking the Generate Plan button, select the Edit
Recommended Environments Settings link. You will see the following dialog.
In this dialog, you can select from the existing Sizing Rules, or create your own custom rules. For
example, you might create a rule for a specific business application to provide 30% growth. This
step is where you can take advantage of the tagged data that we added earlier. We identified
specific business applications and mission critical VMs. We can now use rules against that tagged
data. Select as many rules as you would like and click Save.
Then, go back to the Planning Center and click the Generate Plan button.
The next screen you will see simply shows you the configuration of the systems and LPARs you
selected:
You can skip straight to the 3rd tab (Selected System).
Click the Choose base for <system name> button

You will now see three options as seen below
The first option is the one that well choose. We are trying to see if the 3 additional LPARs will fit
on our existing system. The other two choices can be very useful depending on your use case.
Once you have select the icon that you want, click Continue and then finish the capacity plan.
The result will look something like this.
There are a couple of important things to notice. First, we see that the Current Model and
Select Model are the same. Thats because we told the capacity planning tool to use the same
machine model. We also know that the additional 3 LPARs can be contained on this server. If we
couldnt contain this additional workload, then the tool would have given us a message indicating
that there isnt capacity. Finally, notice that the tool gives us recommendations to change the
Entitlement and assigned memory based on the actually utilization of the LPARs.
If you want, you can select View->Inventory->VIO Partitions. These LPARs can also be tagged with
additional data.
The next step is to select View->Logical Partition Utilization. The first time you view this screen,
the utilization data
Citrix Environments:
and Networking Agents. In addition, some customers use IBM Systems Director to
monitor their server hardware. The Hardware, Storage, and Networking Agents section
of the document provides instructions on configuring the IBM Systems Director Agent.
This will allow you to integrate hardware data into your IBM Tivoli Monitoring
environment. The remainder of this section will focus on configuring and using the Citrix
monitoring Agents.
Citrix XenDesktop Agent

The Citrix XenDesktop Agent is pre-installed in the appliance. You have the option of
either configuring the Citrix XenDesktop Agent that is pre-installed in the image or
remotely deploying the Citrix XenDesktop Agent to another machine. Ensure that the
Agent has network connectivity to the Citrix XenDesktop server
The Monitoring agent for Citrix XenDesktop supports:
Enterprise Citrix Desktop 5
Express Citrix Desktop 5
There are some terminology differences between Citrix XenDeskop 4 and 5. The
following section describes the differences.
Site
It is Xendesktop 5 terminology.
Corresponding name in Xendesktop 4 : Farm

Site is a top level logical representation of Xendesktop brokering services
Can have multiple broker controllers for load balancing etc
Broker Controller
Xendesktop 4 terminology : Desktop Delivery Controller
Major component of Xendesktop deployment.
It is a server machine running instances of Broker Service
It responds to desktop launch requests from users.
Responsibilities of Controller
Responds to User request for desktop by selecting appropriate virtual
desktop
Optionally powering it up
Maintaining appropriate number of unused, powered up desktop
machines
Broker Machine
Physical or Virtual machine used to deliver desktop to user.
Broker Catalog
Group of Broker Machines with some criterion
Criteria can be:
ThinCloned, SingleImage, PowerManaged,unmanaged
Thin Cloned and Single Image
Machines created and managed via Provisioning service for VMs.
A thin cloned catalog kind is used when the original golden VM image is
cloned when it is assigned to the VM
A single image catalog is used when multiple PVS for VMs provisioned
machines all share a single golden VM image
PowerManaged
Broker Machines are manually provisioned by administrators
Unmanaged
Broker Machines are unmanaged, so there is no associated hypervisor
connection.
Here is an architectural diagram of Citrix XenDesktop and the Agent:
Installation for Citrix XenDesktop Agent

Hardware Requirements
Any windows or Linux OS system
Software Requirements
Tivoli Monitoring 6.2.2 and future fix packs, mod levels and fix packs
Citrix XenDesktop 4.0 and future mod levels and their fix packs
Ensure that the following software is installed on the broker controller:

o Windows Remote Management (WinRM) version 2.0
o Citrix XenDesktop PowerShell 2.0

o XDCommands for Citrix XenDesktop 4

o Citrix XenDesktop 5 Snap-in for Citrix XenDesktop 5
Environment requirements and considerations

o Preferable to point a single instance of an agent to a broker controller.
Broker Controller Configuration:

Broker Controller Configuration
Log on to the computer that hosts the broker controller.
Click Start > All Programs > Accessories > Windows PowerShell. A command prompt
opens.
At the command prompt, run the commands in the following sequence:

1. winrm quickconfig
2. cd wsman:
3. Set-Item .\localhost\MaxTimeoutms 600000
4. cd .\localhost\services
5. Set-Item .\AllowUnencrypted $True (Type this command only for the http
communication.)
6. cd .\Auth
7. Set-Item .\Basic $True
Click Start > Run
In the Open field, enter services.msc. The Services window opens.
Right-click Windows Remote Management (WS-Management), and then click

Restart.
Agent Configuration:
Once the Agent is installed, it must be configured. When configuring the Agent, you
must setup SSL key exchange between the Agent and the Citrix XenDesktop Broker
Controller. See the product documentation for setting up the SSL keys.
The XenDesktop Agent is a multi-instance Agent. So, when configuring the agent follow
these steps:
Right click on agent template ->Configure Using Defaults
Configuration window has below
Data Source Configuration
Next, configure the license server:
Finally, specify the Data Provider Configuration. The default configuration is appropriate
for most environments:
After clicking OK, you will be prompted for the TEMS Connection information. This will
be identical to all other agents.
After the Agent is configured, select the Agent instance, right click, and select Start
Service. In the dialog that opens, select the Agent Instance that you just created.
Click Start Agent
Some information about the agent:
It is a Remote Agent
Citrix Xendesktop Provides its own Powershell SDK for data collection
Xendesktop 5 SDK comes with Installation of the controller
Xendesktop 4 SDK may need to be installed separately on the controller
Data Sources other than SDK
Windows Event Log
Performance Counters
The Agent needs to connect to Xendesktop controller Machine which is a

Windows Server OS
WinRM services running on controller processes WS-Man requests received over

the network
A cmd shell prompt executes powershell cmdlets
Hence Powershell exe runs on Broker controller throughout agent lifetime
Troubleshooting key log entries and debugging:
Citrix XenApp Agent

The Citrix XenApp Agent must be installed on the Citrix XenApp server. In order to install
the XenApp Agent, you will need to download the Citrix XenApp media and install the
agent on the Citrix XenApp server. The Citrix XenApp Agent does not have any
configuration parameters other than connectivity to the TEMS. Setup the TEMS
connectivity just like any other Agent.
If the Citrix XenApp agent is set up to run under a user account other than the
localsystem account, the user account must have the following permissions:
1. Within the Citrix XenApp agent, the user must be added as a XenApp
Administrator with View-Only or Full permission.
2. The user must have permission to view and run all of the files within the
C:\Program Files (x86)\Citrix\HealthMon\Tests\Citrix folder.
3. The user must be granted Logon As Service permission in either the Domain or
Local Security Policy within Windows.
Citrix XenServer Agent

Prerequisites for the Citrix XenServer Agent
The Citrix XenServer agent requires installation of additional files that are not included in
the installation media. You must download the XenServerJava-5.6.100-1 version from the
Citrix website.
The SDK kit can be downloaded from the Download SDKs page of the Citrix Developer
website (http://community.citrix.com/display/xs/XenServer+SDK+Archive).
Extract the following .jar (Java archive) files from the downloaded SDK kit:
ws-commons-util-1.0.2.jar
xenserver-5.6.100-1.jar
xmlrpc-client-3.1.jar
xmlrpc-common-3.1.jar
Place the jar files in: /opt/IBM/ITM/lx8266/xi/bin
The Citrix XenServer Agent has some specific requirements for installation and
configuration.
If a single stand-alone XenServer host that is not a member of a XenServer pool is

to be monitored, a specific Citrix XenServer agent instance must be created to
monitor that single XenServer host.
If 1 to 16 XenServer hosts are grouped together in a unique XenServer pool, a

single specific XenServer agent instance must be configured to monitor all of the
of the XenServer hosts within that unique XenServer pool. Within the Citrix
XenServer agent instance, the configuration details (hostname, username,
password) for each XenServer host in the XenServer pool must be entered or the
agent will not function correctly.
Never configure a Citrix XenServer agent instance to monitor two or more standalone XenServer hosts that are not grouped together in a XenServer pool. If two
stand-alone XenServer hosts exist (each not configured as part of a XenServer
pool), two Citrix XenServer agent instances must be configured one for each
XenServer host.
Never mix XenServer hosts from more than one XenServer pool within the
configuration of a single Citrix XenServer agent instance.
The Citrix XenServer agent is a remote IBM Tivoli Monitoring agent. Do not install
the Citrix XenServer agent on a Citrix XenServer Pool Master or any other
XenServer host in a pool.
Connection Info (XENSERVER_HOSTS_CONNECTIONS)

XenServer hosts connections details..
Note: There are between 1 and 16 XenServer hosts in a XenServer pool. Each of
the XenServer hosts must be configured by using this repeatable configuration
panel, or the agent instance cannot collect data.
The configuration elements defined in this group are always present in the
configuration of the agent. Use the information in this group to create additional
subnodes.
Hostname (Hostname)
The host name of XenServer Host (Hypervisor).
The host name for each XenServer host must match exactly the host name the
XenServer has been assigned. The easiest way to confirm the host name is to run
the hostname command from the command line on the XenServer host. The
output of the command is the value that you should enter for the host name
configuration element.
Note: If SSL is enabled, this host name must match the fully qualified domain
name listed in the imported X.509 certificate for this server.
Configure the Citrix XenServer Agent

Type CandleManage to open the Manage Tivoli Enterprise Services user interface, right
click on the Citrix XenServer Agent, and select Configure. The following dialog will
open:
Click the Add Instance button to create a new Citrix XenServer monitoring agent
instance. The instance name can be any name, but Best Practices is to use the hostname
of the XenDesktop server and click OK.
You will be taken to the next configuration panel.
The Citrix XenServer agent can be configured to securely communicate with its XenServer
data sources using SSL certificates. The default is No. If you choose to use SSL
certificates, you must add a data source SSL certificate to the certificate truststore of the
agent. This is done using the keytool command.
keytool -import -noprompt -trustcacerts -alias CertificateAlias file CertificateFile keystore Truststore -storepass TruststorePassword
The Truststore is the full path and filename to the truststore. On this 64-bit Linux
system, the path and filename is: /opt/IBM/ITM/lx8266/xi/bin/kxi_truststore.jks
The default TruststorePassword is XENTRUST
The next panel configures the Agent logging configuration. The default settings are
appropriate.
In the next panel, you will configure the user access to the Citrix XenServer. Provide a
read-only Domain account and password. Also indicate whether SSL will be used to
encrypt traffic to the XenServer.
In the next panel, you will add one or more Citrix XenServers to monitor. The
information at the top of the configuration panel is the default settings:
For each monitored XenServer Host, you may override the defaults. Click the New
button to monitor each addition XenServer Host. For each Agent Instance, you may only
monitor XenServers that belong to the same XenServer Pool. If the Hosts belong to
different XenServer pools, the Agent will not be able to monitor all of the Hosts. To
ensure that you specify the correct XenServer Host name, execute the following
command on any Citrix XenServer xe host-list. The Host specified in the configuration
panel must exactly match the name returned by xe host-list.
Notice that you are able to specify different parameters for each monitored XenServer
Host. For example, one of the hosts is using SSL and the other is not.
When you are finished adding the XenServer Hosts, click the OK button and you will be
asked to configure the communications to the TEMS.
At this point, the Agent is configured. However, there are some additional requirements
before the Agent can be started.
After the configuration is complete, select the Agent and right click you mouse and select
Start Service. You will be prompted to select the Instance to start. Select the instance
you specified earlier and click Start Agent.
Citrix Exercises
Citrix XenServer Exercises
Exercise 1: Pool Master change analysis

This exercise involves detecting and handling Pool Master change events using out-of-the-box
situations and capabilities in the Citrix XenServer agent. This is a three-step process performed
automatically by the Citrix XenServer agent.
This process includes:
Detection of a down Pool Master,
Detection of the Pool Master change event, and
Discovering the new Pool Master.
If a Pool Master transition occurs, two situations appear under the Events node. First, the
KXI_CONNECTION_FAILURE situation fires to inform the administrator the Pool Master is down.
The second situation is KXI_POOL_MASTER_CHANGED. This situation fires once the Pool Master
transition has been started and discovered. Now that the transition event is discovered, the
administrator is able to drill down and see relevant information to the event. This information
includes the former Pool Master, new Pool Master, event time and discovery time. Additionally,
each Citrix XenServer agent situation contains Expert Advice to help perform root-cause analysis
and offer best practices advice.
Once the Pool Master transition event is complete, the KXI_CONNECTION_FAILURE situation
clears and reports a healthy connection to the new XenServer Pool Master. Leveraging key
situation information with Expert Advice reduces mean time to recover and increases visibility
into pool wide activity.
Citrix XenApp Agent Exercises
Exercise 1 : ICA Listener down scenario

This exercise involves detecting and handling a down ICA Listener event using out-of-the-box
situations and capabilities in the Citrix XenApp agent. Ensuring availability of the ICA Listener is
one of many parts to maintaining a healthy Citrix XenApp environment that agent provides.
The Citrix XenApp agent is capable of detecting and recovering from a down ICA Listener.
This process includes:
detection of a down ICA Listener,
recovering the ICA Listener, and
confirming the ICA Listener is healthy again.
If the ICA Listener is no longer detected as healthy, the KXA_Listener_Down situation appears
under the Server Overview subnode. Drilling down to the situation shows relevant event
information including the XenApp server affected, when the unhealthy service was detected,
current high level metrics, and high level metrics from when the event occurred. Additionally,
each situation contains Expert Advice to help perform root-cause analysis and deliver best
practices advice. For this event, Expert Advice suggests reviewing the configuration of the
XenApp server and using the Services node of the agent to confirm all services are up.
After analyzing the Services node, the administrator is able to determine which critical services
are down. With this knowledge the administrator may take corrective actions on the XenApp
server as illustrated above. Once all services are up and the ICA Listener returns to a healthy
state, the KXA_Listener_Down situation clears. Leveraging key situation information with Expert
Advice reduces mean time to recover and increases visibility into health and availability of the
monitored XenApp server.
Cisco UCS Environments:

In many Cisco UCS environments, people want to gather performance data and alerts
from the storage devices and network switches. Since the performance, availability, and
latency of the storage devices and network switches that are being used by Cisco UCS are
critical to the performance of the overall environment. If you wish to configure any of
the Storage and Networking Agents, there is a section called Hardware, Storage, and
Networking Agents. The remainder of this section will focus on configuring and using
the Cisco UCS monitoring Agent.
cinfo R
Then type:
CandleManage
The Manage Tivoli Enterprise Monitoring Services configuration panel will open. Right
click on the Monitoring Agent for Cisco UCS and select Configure. The following dialog
will open:
Click the Add Instance button to create a new Cisco UCS monitoring agent instance.
The instance name can be any name, but Best Practices is to use the hostname of the
Cisco UCS server and click OK
Next, add the configuration parameters to connect to the Cisco UCS server. The first
parameter is the URL. This is typically http://<hostname of UCS server>/nuova. Then
next two parameters are the username and password used to access the Cisco UCS
server. The default username is admin. For the SSL truststore filename, enter the path
and filename shown below (/opt/IBM/ITM/lx8266/v6/etc/kv6.truststore). Finally, choose
whether you want to validate SSL certificates.
After filling in the parameters, click Next. The next panel configures the logging
settings. We recommend using the default parameters.
Click OK and you will be asked to specify the parameters to communicate with the
TEMS. After providing those settings, the configuration is complete.
If you chose to use SSL certificates, you must obtain the Certificate from the Cisco UCS
server and import it into the keystore using the keytool command as shown below.
keytool -import -noprompt -trustcacerts -alias CertificateAlias -file CertificateFile keystore Truststore -storepass TruststorePassword
Where the Truststore path and filename are:
/opt/IBM/ITM/lx8266/v6/etc/kv6.truststore and the default TruststorePassword is
ITMFORVE
Now you are ready to start the Agent. Right click on the Cisco UCS Agent in the
CandleManage user interface. Select Start Service and select the Agent Instance you
created earlier (for example CiscoUCS1) and click Start.
KVM Environments
and Networking Agents. In addition, some customers use IBM Systems Director to
monitor their server hardware. The Hardware, Storage, and Networking Agents section
of the document provides instructions on configuring the IBM Systems Director Agent.
This will allow you to integrate hardware data into your IBM Tivoli Monitoring
environment. The remainder of this section will focus on configuring and using the KVM
monitoring Agent.
Gathering KVM Agent Requirements:

When configuring the KVM Monitoring Agent, you will need to provide the hostname of
the KVM server(s), a user account, transport protocol, and port number used for that
protocol to access the KVM server(s). The KVM administrator can provide you with that
information. The protocol choices are ssh which uses port 22 by default, TLS, and TCP.
Detailed instructions for each protocol are listed below.
Configuring the KVM Monitoring Agent:

cinfo R
Then type:
CandleManage
The Manage Tivoli Enterprise Monitoring Services configuration panel will open
Agent for Linux Kernel-based Virtual Machines and select Configure. The following
dialog will open:
Click the Add Instance button to create a new Linux KVM monitoring agent instance.
The instance name can be any name, but Best Practices is to use the hostname of the
Linux KVM server and click OK.
The following dialog will open.
The first tab is the Data Provider tab and contains information related to the Agent
Logging. The default values are appropriate for most environments. Next, click on the
Hypervisor tab. You will see a dialog like the one shown below.
In this dialog, click New to add new to monitor additional Linux KVM servers. Each
time you click New, fill in the parameters for the monitored Linux KVM server. A single
Agent instance can monitor many KVM servers.
The *Hypervisor ID is a unique identifier and can be set to any value. However, Best
Practice recommendation is to use the hostname of the Linux KVM server. Set the
*Host to the hostname of the Linux KVM server being monitored. Choose a user
account to access the KVM server. The default value is root. Finally, choose the
*Remote Transport. The default is ssh with Port set to 22. The other choices for
*Remote Transport is TLS or TCP. See the information below on Remote Transport
Configuration
After configuring these parameters, you will be asked to configure connectivity to the
TEMS. When you are finished, right click Monitoring Agent for Linux Kernel-based
Virtual Machines, select the Instance you created, and click Start Agent
Remote Transport Configuration:
SSH Protocol: The KVM Agent can be configured to use ssh to connect to the KVM
server. If ssh is used, the Agent must be able to connect to the KVM server and
execute commands without being prompted for a username and password. See the
users guide for details on setting up the key exchange required for using ssh without
a username/password.
TLS protocol: For the TLS protocol, assume you install the Linux Kernel-based Virtual
Machines agent on Host A and you want to remotely monitor the hypervisor on Host
B.
Follow these steps:
o Confirm that the gnutls and gnutls-utils packages are installed on the KVM
server.
o Confirm that listen_tls is enabled in /etc/libvirt/libvirtd.conf and the tls_port is
16514 (the default).
o Next, you will go to libvirt.org/remote.html and follow the instructions for
setting up a certificate authority between Host A and Host B. Pay special
attention to the sections of Setting up a Certificate Authority (CA), Issuing
server certificates, and Issuing client certificates.
o Have the KVM admin restart the libvirt daemon on Host B in listening mode by
running it with --listen flag or by editing /etc/sysconfig/libvirtd and
uncommenting the LIBVIRTD_ARGS="--listen" line.
When you have finished the configuration, check your work using the virsh command
by entering virsh -c qemu+tls://name or IP address of KVM server:port/system. You
can omit the :port section of the command if you have not changed the default TLS
port. If the virsh command succeeds, the Linux Kernel-based Virtual Machines agent
can connect.
TCP protocol: We only recommend using the TCP protocol for testing. For TCP, assume
you install the Linux Kernel-based Virtual Machines agent on Host A and you want to
remotely monitor the hypervisor on Host B. Follow these steps:
o Have the KVM admin log in to the KVM server.
o Edit /etc/libvirt/libvirtd.conf to make sure that listen_tcp is enabled and tcp_port
is 16509 (the default).
o Edit /etc/libvirt/libvirtd.conf to set auth_tcp to "none". This instructs TCP not to
perform any authentication.
o Restart the libvirt daemon on Host B in listening mode by running it with --listen
flag or by editing /etc/sysconfig/libvirtd and uncommenting the
LIBVIRTD_ARGS="--listen" line.
When you have finished the configuration, check the configuration using the virsh
command by entering virsh -c qemu+tls://name or IP address of KVM
server:port/system. You can omit the :port section of the command if you have not
changed the default TLS port. If the virsh command succeeds, the Linux Kernel-based
Virtual Machines agent can connect.
Hardware, Storage, and Networking Agents

NetApp Monitoring Agent
Gathering Netapp Agent Requirements:
For the NetApp Agent, the Agent will remotely connect to the NetApp Data Fabric
Manager (DFM). Depending on how DFM is configured, the Agent will connect
with either HTTP or HTTPS requests over the default ports (80 or 8080)
You will need to provide a username and password to the NetApp Data Fabric
Manager system with read only privileges. This account must have the
permission to read monitoring data. Ask the storage administrator to provide you
with a username and password for the Data Fabric Manager server and whether
Data Fabric Manager is configured for HTTP or HTTPS.
The NetApp Agent requires the manageontap.jar file. This file must be
downloaded from the NetApp website. See this URL:
http://communities.netapp.com/docs/DOC-1152 or copied from your Data Fabric
Manager server. Copy this file to:
/opt/IBM/ITM/lx8266/nu/lib
Use the FTP server on the virtual machine to copy the file to a directory like /tmp.
FTP with a non-root user account like itmuser with password smartway. Then,
using the root user account, copy the manageontap.jar file to
/opt/IBM/ITM/lx8266/nu/lib.
Make root the owner of the manageontap.jar file by typing chown root
manageontap.jar
Make sure the manageontap.jar file has execute permissions. As root, type
chmod 550 manageontap.jar
Configuring the Netapp Monitoring Agent:

cinfo R
Then type:
CandleManage
The Manage Tivoli Enterprise Monitoring Services configuration panel will open.
The NetApp Agent is a multi-instance Agent. You will have the option to configure
multiple instances. Right click on the Monitoring Agent for NetApp Storage and select
Configure. You will see the following dialog.
In the dialog, click the Add Instance button.

You will be prompted for an instance name as shown below:
The instance name can be anything you want, but we recommend using the hostname of
the Data Fabric Manager (DFM) server. After typing in the name, click OK.
Next, you will see a dialog prompting for the Data Provider configuration information as
seen below. The default values are appropriate and should not be changed.
Next, click on the DataFabric Manager tab and fill in the fields.
Fill in the configuration dialog with the following information that was provided by your
NetApp storage administrator:
*Server: Provide the Server name (hostname) of the NetApp Data Fabric Manager server.
*User: Provide a read-only user account that has been setup to access the Data Fabric
Manager server.
*Password and *Confirm Password: Enter the password for the read-only user that was
setup on the Data Fabric Manager server.
*Protocol: Select the protocol that matches your Data Fabric Manager server. The
default is HTTPS.
You will need to provide a username and password to the NetApp Data Fabric Manager
system with read only privileges.
After you have filled in the parameters, click the OK button.
Next, you will be prompted to configure connectivity to the TEMS server. Make sure the
No TEMS checkbox is unchecked. Finish the configuration selecting the IP.PIPE protocol
and entering a TEMS Hostname of scmtrial and click the Save button.
Finally, start the Agent through the Manage Tivoli Enterprise Services graphical user
interface. Right click on the NetApp Agent and select Start Service.
Tivoli Storage Productivity Center (TPC) Agent

Agent for TPC and select Configure. The following dialog will open:
This dialog controls the log level and log file location. The default parameters are
appropriate. Click Next. In the next panel, specify the hostname or IP address of the
Tivoli Storage Productivity Center (TPC) server. Specify the TPC Device Server port. The
default port is 9550. Specify the Administrator password to access the TPC server.
Click Next.
On the next few panels, you will add a New entry for each of the major components of
the TPC Agent. For example, if you want to monitor the Computers and Hypervisors
Node, click New and assign any name in the field. There will be four panels to
configure the following:
Servers and Data Sources Node
Computers and Hypervisors Node
Storage Systems Node
Fabrics Switches and Node
When finished, click OK. Next, you will be prompted to configure communications to
the TEMS.
Finally, right click the Monitoring Agent for TPC in the CandleManage user interface and
select Start Service.
Network Device Agent:

If you want to configure the Network Device Agent to monitor your Network Switch(es),
the Agent must first be installed on a system. It may be installed on the Virtual Machine
or installed on a remote system. See the steps below in the next section.
Agentless OS Monitoring Agents

Agentless OS Monitoring Requirements
The UNIX and Linux Agentless monitoring agents use SNMP to connect to the monitored
servers. The default SNMP port is 161. For each monitored server, gather the following
information:
SNMP listening port
SNMP version (v1, v2c, or v3)
SNMP Community string
For SNMP v3, provide a username and password with access to SNMP
The Solaris Agentless monitoring agent has 2 other optional configurations. Instead
of using native SNMP to gather data, the server may be setup with SunMC. This using
SNMP, but the configuration is slightly different. Please see the users guide for
details on configuring the agent with SunMC. Solaris can also be monitored using
CIM. CIM is the slowest of the protocols, so we recommend SNMP or SunMC.
If you want to use CIM, ensure the CIM service is configured and started. To
start the CIM service on Solaris, run the following command:
# /etc/init.d/init.wbem start.
To manage the CIM service on Solaris, run this command:
# /usr/sadm/bin/wbemadmin.
CIM uses port 5988. Ensure that port 5988 is open between the agent and
the monitored server.
Provide a username and password that has access to the CIM service.
Ensure that UDP port 161 is open between the Agentless monitoring agent
and the monitored server.
Each of the operating systems has slightly different configuration

requirements for SNMP. Ensure that the following configurations are setup
properly on the monitored server. Here are some tips for SNMP configuration
for each operating system. For more information, see the users guide for
each agent.
AIX:
1. All three SubAgent daemons (aixmibd, hostmibd, and snmpmibd) must be
started to obtain the metric data required.
2. For non-default community names, each SubAgent must be restarted with
knowledge of the community name. For example:
stopsrc -s hostmibd
startsrc -s hostmibd -a -c community_name
3. Also, the SNMP daemon (snmpd) must be refreshed after making any of
the changes above: refresh -s snmpd
4. Lastly, verify that none of the SubAgent details are excluded in the
/etc/snmpdv3.conf. For example, a common line to comment out is:
VACM_VIEW defaultView 1.3.6.1.4.1.2.6.191 - excluded
-Commenting this line allows the aixmibd SubAgent to be included in
SNMP Requests.
Linux:
o On SuSE Linux Enterprise version 9 remote systems, Service Pack 3 or later (provides
net-snmp-5.1-80.22.rpm or later) is required to correctly collect memory statistics.
o For Red Hat operating systems, the /etc/snmpd.conf must be modified to allow the
Host Resources MIB and ucdavis MIB to be viewed by all users.
o Add the following system views to the SNMP configuration:
view systemview included .1.3.6.1.2.1.25
HP/UX:
Follow HPs documentation to setup SNMP.
Solaris:
Follow Oracles documentation to setup SNMP or SunMC
Configuring the Agentless OS Monitoring Agents

cinfo R
Then type:
CandleManage
The Manage Tivoli Enterprise Monitoring Services configuration panel will open.
The Agentless OS Agents are multi-instance Agents. You will have the option to
configure multiple instances. Right click on any of the Agentless Monitoring Agents:
Agentless Monitoring for AIX Operating Systems
Agentless Monitoring for HP-UX Operating Systems
Agentless Monitoring for Linux Operating Systems
Agentless Monitoring for Solaris Operating Systems
Agentless Monitoring for Windows Operating Systems
You will see the following dialog.
In the dialog, click the Add Instance button.

You will be prompted for an instance name as shown below:
In the case of the Agentless Monitoring Agents, the Instance name doesnt represent the system
being monitored. Choose a reasonably short name that you can use when starting and stopping
the Agent instance. For example, inst1
After specifying the instance name, you will be prompted for the default SNMP monitoring
information. For example, select the SNMP port and SNMP version that is most commonly used
in your environment.
Click Next
Depending on which SNMP version you selected, you will be prompted for a different set of
default SNMP parameters. Specify the most common values seen in your environment.
The dialog below shows the default parameter for SNMP v1, which is the SNMP community name.
After entering the default parameters such as Community Name, click Next.
In this configuration panel, click the New button to add a new server to be monitored. You may
add as many servers to remotely monitor with the SNMP based Agentless monitoring Agents.
In this example, I have selected to monitor two remote servers using the default configuration
parameters that were previously defined. However, I have the option to select the Advanced
option and override the default values. Lets say that server1 uses my default values of SNMP v1
and community name of public, but server 2 is configured for SNMP v3. If I select the Select a
section to override values dropdown and select SNMP v3, I will have the option to specify all of
the SNMP v3 parameters to remotely monitor the 2nd server. See the example dialog below.
The Agentless Monitoring Agents for AIX, HP-UX, Linux, Windows, and Solaris all support SNMP
based monitoring and the configuration will be the same for all SNMP based monitoring.
The Windows Agentless Monitoring Agent has the option of remotely monitoring using WMI.
However, WMI based monitor is only supported for the Agentless Monitoring Agent running on a
Windows platform. So, in order to implement these steps, you will need to install the Agent on a
Windows system. See Appendix A: Remotely Deploying Agents to remotely install the
monitoring Agent.
These steps document how to configure WMI based Agentless monitoring. As with all Agentless
OS Monitoring Agents, you will be asked to specify an Instance Name. Then, you will be
prompted for the default connection type. Choose Windows API Connection to monitor via
WMI and click Next.
This will set the default monitoring type. However, you can override that value for a specific
server. The next step is to provide the default password for the remotely monitored servers.
Click Next.
The next panel will allow you to specify 1 or more remotely monitored Windows systems by
clicking the New button. Notice in the configuration that we used the Advanced option to
specify a different password for the server. In the second monitored server, we used the default
value.
It is also important to note that the hostname of the monitored server MUST be in the form of a
Domain\Username even if the server is setup as a Workgroup server. In the case of a
Workgroup server, use the Hostname of the server as the Domain name. If the server is part of a
Domain, specify the actual Domain name and Domain user account.
After the Agent is configured right click the entry in the Manage Tivoli Enterprise Services user
interface and start the Agent.
The Solaris Agentless Monitoring Agent offers three types of monitoring. Solaris systems can be
remotely monitored in the following ways:
Traditional SNMP (versions v1, v2c, or v3)
Monitored using SNMP via the Sun Management Center (SMC)
Monitored remotely using CIM (Common Information Model)
As you configure the default settings and the settings for each monitored server, you may select
SNMP (SMA), SNMP (SMC), or CIM.
Agent Based OS Monitoring

SmartCloud Monitoring includes Agent based OS monitoring agents for the distributed
platforms. These Agents must run locally on the operating system that is being
managed. Download the ITM 6.3 Agent media and install the Agents. For skilled users,
IBM Tivoli Monitoring does have Remote Deployment capabilities. See Appendix A:
Remotely Deploying Agents for information on Remotely Deploying Agents.
Other Agents:
After examining the VMware VI Agent, we recommend you try out some of the
workspaces for the other Agents. As you attempt to debug and problem solve hypervisor
problems, the performance and latency of the backend storage and networking is critical.
Take a look at the NetApp Agent. You will see a number useful metrics including the
LUNs, Aggregates and Volumes. In the screen capture below, you can see that Volume
Latency as well as I/O is captured by this agent. If you have Tivoli Storage Productivity
Center (TPC), there is an ITM Monitoring Agent that can be integrated into the
environment. The SmartCloud Monitoring solution also includes a Network Device
Agent, but it is not included in this POT demo.
Latency
Read/Write
operations
Try out the other Agent workspaces. Youll find that the SmartCloud Monitoring solution
offers in-depth monitoring for the key hypervisors such as, Microsoft Hyper-V, Citrix
XenDesktop, Cisco UCS, and KVM.
Appendix A: Remotely Deploying Agents

This section of the document provides detailed instructions on deploying each of the monitoring
Agents. For Agents that are pre-installed on the appliance, these are optional steps.
The Remote Deploy process requires that the Remote Deploy depot be populated with Agent
images for the various operating system versions where you plan to deploy. The IBM SmartCloud
Monitoring Trial Virtual Machine comes with a Remote Deploy depot that is pre-populated for
Windows 64-bit and Linux 64-bit for most of the Agents. The only exceptions are the PowerVM
Agents. The PowerVM Agents must run on AIX systems and the Remote Deploy depot is
populated for 64-bit AIX. If you wish to deploy to other platforms such as 32-bit Windows or 32bit Linux, you will need to download the product media and populate the depot for those
platforms. See the IBM Tivoli Monitoring Command Linux Reference documentation for
instructions on using the tacmd addbundles command to populate the depot.
When importing media into the Remote Deploy depot, you will issue the following command
tacmd addBundles I <image path>
If you want to import the Remote Deploy files for a Windows target system, issue the following
command:
tacmd addBundles I <media home>/WINDOWS/Deploy
To import the Remote Deploy files to deploy an Agent to a UNIX or Linux system, issue the
following command:
tacmd addBundles I <media home>/unix
You must deploy the OS Agent to each server before remotely deploying an application,
middleware, or hypervisor agent. There are two ways to remotely deploy the OS Agent. You can
use the tacmd exportBundle command to export the OS Agent to a small locally installable
package. Or, you can use the tacmd createNode command to remotely deploy the agent. The
application/middleware/hypervisor agents can be deployed in one of two ways. You may export
a small agent bundle in the same way that you use the tacmd exportBundle command to export
the OS Agent. If you want to remotely deploy the Agent, issue the tacmd addSystem command
instead of tacmd createNode or right click on the OS Agent in the Tivoli Enterprise Portal and
select Add Ssytem. Here is the syntax for each of these commands to deploy the OS Agent.
tacmd exportBundle:
Create a directory such as /tmp/bundle
Type the following command:
tacmd exportbundles -p lx8266 -e /tmp/bundle -t LZ -v 063001000 -o LOCAL

In the command above, the only parameters you should need to change is the
platform and the Agent type. For example, instead of exporting the lx8266 Linux
version, you might choose to export a Windows OS Agent. If you want to export
the Windows OS Agent, change the command to:
tacmd exportbundles -p WIX64 -e /tmp/bundle -t NT -v 063001000 -o
LOCAL
When exporting an Agent bundle, the bundles cant be installed interactively. You must
edit the silent install file and then execute the command below to install the bundle:
Install cmds :
Unix
Windows
: <exportDir>/silentInstall.sh
: <exportDir>\silentInstall.bat
tacmd createNode:
If you wish to use the tacmd createNode command to remotely deploy the OS
agent, issue the following command.
First, login to the TEMS using the tacmd CLI:
tacmd login s scmtrial
When prompted, enter the sysadmin for the username and smartway
for the password.
Then, issue the tacmd createNode command as follows:
For UNIX/Linux:
tacmd createNode -h <hostname or IP address> -d /opt/IBM/ITM -u root
You will be prompted for the root password.
For Windows:
./tacmd createNode -h <hostname or IP address> -d C:\IBM\ITM -u
Administrator
You will be prompted for the Administrator password.

For additional options for tacmd createNode, see the IBM Tivoli Monitoring
Command Line Reference Guide at
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/itm
63_cmdref.pdf
After installing the OS Agent using tacmd createNode, you can use tacmd
addSystem or the TEP UI to install additional agents. Or, you can locally install
the exported agent bundles. Once the Agent is installed, you can configure the
Agent via the CLI or GUI. On Linux and UNIX, you can issue the itmcmd config
command to configure the agent from the command line. Or, you can issue the
CandleManage command to configure the Agent via an X-Windows GUI. On
Windows, we recommend you configure the Agent via the Manage Tivoli
Enterprise Services user interface. You can find this on your Start menu. For
detailed agent configuration steps, see the sections below for each agent.
After you complete the Agent specific configuration tasks, you will be prompted
for the connection information to the TEMS. The default configuration is for the
No TEMS checkbox to be selected. You must unselect the No TEMS checkbox
and then enter the hostname of the HUB TEMS in the TEMS Hostname box. In
this case, the hostname is scmtrial. Finally, make sure that the protocol is set to
IP.PIPE and the port is set to 1918. See the panel below for an example.
As new Agents come online, you will see an Agent in the upper left corner of the
Tivoli Enterprise Portal. In order to see the new Agent appear in the Navigation
Tree, you must click on the icon. Here is a screen capture of the icon to look for
and select.
Remotely Deploying the Hypervisor Agents

This section describes how to remotely install and configure the Agents to monitor each of the
hypervisors. As stated earlier, the Operating System Agent must be installed before any other
agents are installed. In addition, you must download the media for the Agent and import it into
the Remote Deploy depot using the tacmd addBundles command.
Network Ports
If you decide to install the agents remotely, then you will need to ensure that the ports in
the following diagram are opened:
Notice that both ports 1918 and 3660 are listed. The default is IP.PIPE on port 1918
which is not encrypted. Port 3660 is only used if you reconfigure your environment for
encrypted traffic using IP.SPIPE.
Netapp Agent:
For the NetApp Agent, the Agent will remotely connect to the NetApp Data Fabric
Manager (DFM). Depending on how DFM is configured, the Agent will connect with
either HTTP or HTTPS requests over the default ports (80 or 8080)
You will need to provide a username and password to the NetApp Data Fabric Manager
system with read only privileges. This account must have the permission to read
monitoring data.
The NetApp Agent requires the manageontap.jar file. This file must be downloaded from
the NetApp website. See this URL: http://communities.netapp.com/docs/DOC-1152.
Copy the manageontapp.jar file to the following directory depending on the platform of
your NetApp Agent:
Windows (32- and 64-bit): install_dir/tmaitm6
Linux (64-bit): install_dir/lx8266/nu/lib
Ensure that the Agent has network connectivity to the NetApp Data Fabric Manager.
Depending on the configuration, the Agent will connect to the Data Fabric Manager using
either HTTP or HTTPS. Ensure that the HTTP or HTTPS port is not blocked by a firewall.
Remotely Deploying the NetApp Agent via the Tivoli Enterprise Portal
If you wish to Remotely Deploy the NetApp Monitoring Agent via the Tivoli Enterprise
Portal, follow these steps. First, right click on the Node where you want to deploy the
Agent and select Add Managed System. You will see the following dialog.
Select the Monitoring Agent for NetApp Storage (32-bit) and click OK.
You will see three tabs in the next dialog. Fill out all of the information in the three tabs
using the instructions below.
In the Data Provider tab, you should only need to change the instance name to
something meaningful. Leave the remaining fields with the default values.
In the DataFabric Manager tab, enter the following information:
*Server: This is the hostname of the DataFabric Manager server
*User: This is the username that will access the DataFabric Manager
*Password: This is the password used to access DataFabric Manager
*Protocol: Specify whether you want HTTP or HTTPS to access DataFabric

Manager. The default is HTTPS.
Finally, specify the information in the Agent tab. This is the Username and Group name
that the Agent will run as.
Click the Finish button to complete the Remote Deployment. After several minutes,
the new Agent will appear in the Tivoli Enterprise Portal.
Remotely Deploying the NetApp Agent via the Command Line Interface
If you want to Remotely Deploy the NetApp Agent via the command line interface, here is
the syntax and an example command for remotely deploying the NetApp Agent:
Before issuing any tacmd commands, you must first login to the TEMS by typing tacmd
login s scmtrial u sysadmin p smartway
tacmd addSystem -t NU -n OSAgentManagedSystemName -p INSTANCE=InstanceName \
KNU_LOG_FILE_MAX_COUNT=LogFileMaxCount \
KNU_LOG_FILE_MAX_SIZE=LogFileMaxSize \
KNU_LOG_LEVEL=LogLevel \
KNU_DATASOURCE_HOST_ADDRESS=HostAddress \
KNU_DATASOURCE_PROTOCOL=Protocol \
KNU_DATASOURCE_USERNAME=Username \
KNU_DATASOURCE_PASSWORD=Password
In this command, the fields are defined as follows.
OSAgentManagedSystemName: The managed system name of the OS agent that is

running on the system to which the NetApp Storage agent is to be remotely deployed.
InstanceName: The name of the instance being deployed.
LogFileMaxCount: The maximum number of data provider log files. Valid values are
positive integers.
LogFileMaxSize: The maximum size (in kilobytes) of each data provider log. Valid
values are positive integers.
LogLevel: The level of detail in data provider logs. Valid values are OFF, SEVERE,
WARNING, INFO, FINE, FINER, FINEST, and ALL.
HostAddress: The host name or IP address of the NetApp DFM server that is to be
monitored.
Username: A user name on the NetApp DFM server.
Password: The password for the Username.
Example:
tacmd addSystem -t NU -n linuxhost1:LZ -p INSTANCE=Inst1
KNU_LOG_FILE_MAX_COUNT=10 KNU_LOG_FILE_MAX_SIZE=5190
KNU_LOG_LEVEL=Warning KNU_DATASOURCE_HOST_ADDRESS=9.42.15.32
KNU_DATASOURCE_PROTOCOL=HTTP KNU_DATASOURCE_USERNAME=Administrator
KNU_DATASOURCE_PASSWORD=smartway
VMware VI Agent:
The following section outlines the steps required to remotely deploy the VMware VI
Agent. The VMware VI Agent may only be deployed on a Windows or Linux system.
There are several parameters that must be provided. They are described below:
Data Source ID: This must be a unique name for monitored system. Typically, we
recommend using the shortname of the VCenter server or ESX server so that the
ID matches the system being monitored.
Data Source Address: This is either the IP address or fully qualified hostname of
the VCenter server or the ESX/ESXi server.
Use SSL Connection to Data Source: If you specify yes, you will need to import the
rui.crt file obtained from the VCenter server or from each ESX server that you are
monitoring. This file can be found in the following directory: C:\Users\All
Users\VMware\VMware VirtualCenter\SSL
Data Source User ID: This is a valid username on the VCenter server with the
following credentials:
o To monitor VMware, the user account must have the following
permissions in VCenter:
System.View and System.Read privileges on all data source objects

being monitored.
o If you want ITM to be able to perform Take Actions to start and stop VMs,
then you must enable the following permissions:
Virtual Machine-Interaction-Power On
Virtual Machine-Interaction-Power Off
Data Source Password/Confirm Data Source Password: Specify the password on

the VCenter server for the username provided in the Data Source User ID field.
Remotely Deploying the VMware VI Agent via the Tivoli Enterprise Portal
Use the following steps to remotely deploy the VMware VI Agent via the Tivoli Enterprise
Portal. First, selecte the node where you want to remotely deploy the Agent, right click,
and select Add Managed Systems. The following dialog will appear.
Select the Monitoring Agent for VMware VI (32 bit) and click OK.
Next, you will need to fill in the parameters for a few tabs as shown below.
In the Data Provider tab, specify a meaningful name for the Instance Name and leave
the remaining information with the default values.
If you have IBM Systems Director, click on the IBM Systems Director tab and fill in the
following dialog.
Enter the following information:
Enter the hostname or IP Address of the IBM Systems Director server
Enter the port number used by the IBM Systems Director Server. The default is
8422
Enter whether to use Tivoli Enterprise Portal credentials to access the IBM
Systems Director Server. The default is Yes
If you have a NetApp Agent configured in your environment, click the Storage Agent tab
and fill in the parameters as described below.
You must gather some information from your system. In a Terminal window, login to the
ITM environment by typing:
After logging in, type:
tacmd listsystems | grep NU
This command will return the Managed Systems Name of the NetApp Agent as
highlighted below.
You will enter the NetApp Agent Managed System Name into the Storage Agent tab
as shown below.
Next, select the Data Source tab and click the New button at least once to add one or
more monitored VCenter or ESX/ESXi servers. Fill in the information in the dialog as
described below.
*Data Source ID: This can be any value, but Best Practice is to use the hostname
of the VCenter or ESX/ESXi server being monitored.
* Data Source Address: This is the hostname or IP Address of the VCenter or

ESX/ESXi server being monitored
*Use SSL Connection to Data Source: Specify whether you want to use SSL
connections. The default is yes. If you use SSL, you will need to import a
certificate.
*Data Source User ID: This is a user ID on the VCenter or ESX/ESXi server with
read permissions
* Data Source Password: This is the password for the account specified with the
previous parameter.
Finally, click the Agent tab and specify the Username and Group Name that the Agent
will run as.
Click Finish to complete the Remote Deployment of the VMware VI Agent. After several
minutes, the Agent will connect to your ITM environment and be visible in the TEP.
Remotely Deploying the VMware VI Agent via the CLI

If you wish to Remotely Deploy the VMware VI Agent via the command line interface,
here is the syntax and an example command for remotely deploying the VMware VI
Agent:
Before issuing any tacmd commands, you must first login to the TEMS by typing tacmd
login s scmtrial u sysadmin p smartway
The VMware VI agent requires the following command:
tacmd addsystem -t vm -n OS_Agent_ManagedSystemName \
-p INSTANCE=InstanceName \
DATA_PROVIDER.KVM_SSL_VALIDATE_CERTIFICATES=ValidatesSSLCertificates\
DATA_PROVIDER.KVM_LOG_FILE_MAX_COUNT=MaxLogFileCount \
DATA_PROVIDER.KVM_LOG_FILE_MAX_SIZE=MaxLogFileSize \
DATA_PROVIDER.KVM_LOG_LEVEL=LogLevel\
DIRECTOR.KVM_DIRECTOR_AUTHENTICATION=DirectorAuthentication \
DIRECTOR.KVM_DIRECTOR_HOST_ADDRESS=DirectorHostAddress \
DIRECTOR.KVM_DIRECTOR_PORT_NUMBER=DirectorPortNumber \
STORAGE_AGENT.KVM_STORAGE_AGENT_MSN=StorageAgentMSN \
DATASOURCE:UniqueDataSourceID.HOST_ADDRESS=DataSourceHostAddress \
DATASOURCE:UniqueDataSourceID.USERNAME=DataSourceUserID \
DATASOURCE:UniqueDataSourceID.PASSWORD=DataSourcePassword \
DATASOURCE:UniqueDataSourceID.USES_SSL=DataSourceUsesSSL
OS_Agent_ManagedSystemName
The managed system name of the operating system agent that is running on the system
where the VMware agent is to be remotely deployed.
InstanceName
The name of the instance
ValidateSSLCertificates
Whether the agent validates SSL certificates when using SSL to communicate over the
network. Valid values are Yes and No.
MaxLogFileCount
The maximum number of data provider log files. Valid values are positive integers.
MaxLogFileSize
The maximum size in KB of each data provider log. Valid values are positive integers.
LogLevel
The level of detail in data provider logs. Valid values are OFF, SEVERE, WARNING, INFO,
FINE, FINER, FINEST, and ALL.
DirectorAuthentication
Whether to authenticate to the IBM Systems Director Server using the IBM Tivoli
Monitoring Tivoli Enterprise Portal user ID and password. This configuration parameter is
optional. Valid
values are Yes and No.
DirectorHostAddress
The IBM Systems Director host name. This value is optional.
DirectorPortNumber
The IBM Systems Director port number. Valid values are valid TCP port numbers. This
value is optional.
StorageAgentMSN
The managed system name (MSN) of the IBM Tivoli Monitoring storage agent that
monitors the physical storage devices for the VMware environment. This managed
system name must belong to a NetApp Storage agent instance.
UniqueDataSourceID
The data source ID

DataSourceHostAddress
The data source host name
DataSourceUserName
The data source user ID
DataSourcePassword
The data source password
DataSourceUsesSSL
Whether to use SSL to connect to the data source. Valid values are Yes and No.
To configure several data sources, repeat the DATASOURCE section parameters with a
new UniqueDataSourceID
If you havent logged into the TEMS, login by typing the following command before
issuing any other tacmd commands:
Example:
tacmd addsystem -t vm -n linuxhost1:LZ -p INSTANCE=inst1
DATA_PROVIDER.KVM_SSL_VALIDATE_CERTIFICATES=Yes
DATA_PROVIDER.KVM_LOG_FILE_MAX_COUNT=10
DATA_PROVIDER.KVM_LOG_FILE_MAX_SIZE=5190
DATA_PROVIDER.KVM_LOG_LEVEL=Warning
DIRECTOR.KVM_DIRECTOR_AUTHENTICATION=Yes
DIRECTOR.KVM_DIRECTOR_HOST_ADDRESS=9.42.56.23
DIRECTOR.KVM_DIRECTOR_PORT_NUMBER=842
STORAGE_AGENT.KVM_STORAGE_AGENT_MSN=itmx29:ITMX31:NU
DATASOURCE:vcenter1.HOST_ADDRESS=DataSourceHostAddress
DATASOURCE:vcenter1.USERNAME=Administrator
DATASOURCE:vcenter1.PASSWORD=passw0rd
DATASOURCE:vcenter1.USES_SSL=No
Network Device Agent:

The Network Device Agent uses SNMP to connect to the monitored network devices.
The agent supports SNMP v1, v2c, and v3. Depending on which version of SNMP the
network device is setup for, different credentials will be required. SNMP v1 and v2c will
require the SNMP community string and port number. SNMP v3 will require a
community string, port, username, and password. The default port and community
string are 161 and public respectively. However, you will need to confirm the ports,
SNMP versions, and credentials in use.
Remotely Deploying the Network Devices Agent via the TEP

Use the following steps to remotely deploy the Network Devices Agent. First, right click
on the Node where you wish to deploy the Agent. You will see the following dialog.
Select the Monitoring Agent for Network Devices (32/64 bit) and click OK
If you only want to monitor 1 network device, fill in the appropriate SNMP parameters
depending on which SNMP version you are using. If you want to monitor more than one
Network Device, click the New button and add additional network devices to be
monitored. Each device can use different SNMP versions and configuration parameters.
Remotely Deploying the Network Devices Agent via the CLI

If you want to use the CLI to remotely deploy the Network Devices Agent, use the
following procedures.
If you havent logged into the TEMS, login by typing the following command before
issuing any other tacmd commands:
Issue the following commend to remotely deploy the Network Monitoring Agent
tacmd addSystem -t N4 -n Primary:sample.node.name:NT
-p QZ_SNMP_VERSION_DETAILS_PLACEHOLDER.KQZ_SNMP_PLACEHOLDER_TEXT=value
Monitored Network Devices.Monitored Network Devices=value
nma.SNMP_AUTH_PASSWORD=value
nma.SNMP_AUTH_PROTOCOL=value
nma.SNMP_COMMUNITY=value
nma.SNMP_HOST=value
nma.SNMP_PORT=161
nma.SNMP_PRIV_PASSWORD=value
nma.SNMP_PRIV_PROTOCOL=value
nma.SNMP_SECURITY_LEVEL=value
nma.SNMP_USER_NAME=value
nma.SNMP_VERSION=value
QZ_SNMP_VERSION_DETAILS_PLACEHOLDER: This is the SNMP version used by the
monitored network device ("SNMP Version 1", "SNMP Version 2c", "SNMP
Version 3")
Monitored_Network_Devices: This is a unique name assigned to the network device. This must be unique
across the entire IBM Tivoli Monitoring environment.
nma.SNMP_AUTH_PASSWORD: The SNMP password

nma.SNMP_AUTH_PROTOCOL: The authorization protocol (either MD5 or SHA)
nma.SNMP_COMMUNITY=The SNMP Community Name
nma.SNMP_HOST=The fully qualified hostname of the monitored device
nma.SNMP_PORT=The SNMP port (default 161)
nma.SNMP_PRIV_PASSWORD=The SNMP Privacy password
nma.SNMP_PRIV_PROTOCOL=The SNMP Privacy protocol (either DES or CBC DES)
nma.SNMP_SECURITY_LEVEL=SNMP Security Level ("noAuthNoPriv", "authNoPriv", "authPriv")
nma.SNMP_USER_NAME=SNMP User Name
nma.SNMP_VERSION=SNMP Version ("SNMP Version 1", "SNMP Version 2c", "SNMP
Version 3")
VIOS Agent
The VIOS Agent is pre-installed within the VIOS. You simply need to configure the Agent
to connect to the Trial Virtual Machine and then start the agent. Execute the following
command to configure the Agent. You must execute the command from the restricted
shell within the VIOS. To enter the restricted shell, ssh to the Virtual I/O Server as
padmin.
cfgsvc ITM_premium -attr Restart_On_Reboot=TRUE hostname=<TEMS_server> \
managing_system=<HMC server>
By default, the VIOS Agent is configured to connect to the HMC as the hscroot user. If
you wish to use a different user, you can specify the username while configuring the
agent. Here is an example:
cfgsvc ITM_premium -attr Restart_On_Reboot=TRUE hostname=<TEMS_server> \
managing_system=<hmcuser>@<HMC server>
Example:
cfgsvc ITM_premium attr Restart_On_Reboot=TRUE hostname=scmtrial \
managing_system=hmc1
Whichever user you want to connect to the HMC, that user must be able to ssh to the
HMC without specifying a password. For example, you should be able to issue a
command like the one below:
ssh hscroot@hmc1 ls
To exchange ssh keys with the HMC, see the product documentation for the VIOS Agent.
Here is a link to the product documentation:
http://pic.dhe.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.itm.doc_6.3/pviosagent
6222_user_rev.pdf
If you want to stop and start the Agent, issue the following commands.
To start the VIOS Agent, type startsvc ITM_premium
To stop the VIOS Agent, type stopsvc ITM_premium
HMC Agent
The HMC Agent must run on an LPAR that can establish an ssh connection to the HMC.
This section describes how to install and configure the HMC Agent. This assumes that you
are using the Remote Deploy capability to remotely deploy the agent. Before deploying
any other agent remotely, you MUST install an OS Agent on the target AIX system.
Installing and Configuring the HMC Agent via the TEP

Here are the steps to install and configure the HMC Agent via the Tivoli Enterprise Portal
(TEP). Right click on the hostname of the UNIX operating system in the Navigation Tree.
A dialog will open showing the list of available agents to deploy.
Select the Monitoring Agent for HMC Base (64 bit) and click OK. You will be prompted
for some configuration information as seen below. On the first panel, you will be
prompted for the Instance Name, HMC Hostname, and HMC Username. The instance
name can be anything you want, but I usually chose the Hostname of the HMC. The HMC
hostname can either be the shortname or fully qualified hostname, but you must be able
to ping the HMC using that name. The default username is hscroot, but you can use any
user account with hscviewer permissions to gather performance metrics from the HMC.
Click Next to go to the Data Provider tab. The default values in the data provider tab
are fine for most environments.
Click Next to go to the Agent tab. By default, the HMC Agent will run as the same
user as the UNIX OS Agent. Normally, this is the root user account. If you wish the agent
to run as another user, specify the username and group name. Otherwise, leave this
panel blank.
Click Finish to begin the remote deployment of the agent. The installation and
configuration will take a few minutes. After a short period of time, a dialog will open
showing you the transaction ID for the remote deployment.
Write down the transaction ID. We can then go into either the Tivoli Enterprise Portal
(TEP) or the CLI to get the status of the deployment. Since were doing a GUI install,
well use the TEP to check the status. In the navigation tree, right click on Enterprise
and select the Deployment Status Summary workspace. At the bottom of the screen,
you will see all of the Remote Deployments. Initially, the Status will show In_Progress.
After a few minutes, the status should be updated to Success which means the
installation is complete.
After the installation completes, there is one step that remains and it must be executed
locally on the system where you installed the HMC Agent. You must establish an ssh key
exchange between the server running the HMC Agent and the HMC. You can either do
this manually using the the typical key exchange commands. You can find these in the
HMC Agent Users Guide at:
t6223_user.pdf
Or, you can use the key.pl script that ships with the monitoring agent. On the machine
where you installed the HMC Agent, change directory to /opt/IBM/ITM/aix523/pk/bin.
Then, execute the key.pl command. You will be prompted for the hostname of the HMC.
Enter the shortname or fully qualified hostname, but ensure that whatever name you use
can ping the HMC. Next, enter the HMC user name that will be accessing the HMC. This
user should match the username you specified earlier and must have hscviewer
permissions. You will be asked whether you want to setup a backup HMC server. This is
optional. Next, you will be asked whether you want to setup a default managed system.
Enter Yes and you will see a list of systems appear. Choose a number corresponding
with the default managed system that you want. That completes the steps for setting up
the key exchange.
Now, you want to test to make sure that the ssl key exchange was successful. You need
to ensure that you can ssh to the HMC with the user account you specified without using
a password. Type the following command: ssh <HMC user>@<HMC Hostname> ls.
For example, ssh hscroot@hmc1 ls. If you are successful, you will see a listing of the
files and directories in the HMC users home directory. If you are prompted for a
password, you will need to manually setup the key exchange using the procedures
documented in the Users Guide.
Installing and Configuring the HMC Agent via the CLI

If you prefer to install and configure the HMC agent from a command line interface(CLI),
you can use these steps. Either ssh into the scmtrial machine or open a terminal window
within the Virtual Machine. From the command line, issue the following commands.
First, you must login to the HUB TEMS using the following command:
/opt/IBM/ITM/bin/tacmd login s scmtrial t 1440
You will be prompted to enter the username and password. Enter sysadmin as the
username and smartway as the password.
Assuming that you successfully logged into the TEMS with a timeout of 1440 minutes (24
hours), you can issue the command to remotely deploy the agent. The command you will
issue is the following:
tacmd addSystem -t PH -n <sample.node.name>:KUX -p INSTANCE="<instance name>" \
"HMC Information".HMC_HOSTNAME=<HMC Hostname> \
"HMC Information".HMC_USERNAME=<HMC Username> \
[Data_Provider.KPH_LOG_FILE_MAX_COUNT=<# of files>] \
[Data_Provider.KPH_LOG_FILE_MAX_SIZE=<max size of each log file>] \
[Data_Provider.KPH_LOG_LEVEL=<log leveldefault is info>]
<sample.node.name> must match the Managed System Name of the system you
are trying deploy to. If you are unsure, you can issue the
/opt/IBM/ITM/bin/tacmd listSystems command.
<instance name> is any name you want, but I typically use the HMC hostname
<HMC Hostname> is the hostname of the HMC server
<HMC Username> is the username that you will use to access the HMC. This user
account must have hscviewer permissions
The last 3 parameters are optional. If you wish to specify them, they are:
o <# of files> is the number of log files to create. The default is 10
o <max size of each log file> is the size for each log file. The default is 5190
KB
o <log level> is the logging level for the agent. The default is Info. Other
options are Off, Severe, Warning, Fine, Finer, Finest, All. Be
careful about choosing the last four options because they will generate a
huge amount of information and will make it difficult to fine the error
messages. Only use those when debugging a problem with the agent.
Here is an example usage of the command line:
/opt/IBM/ITM/bin/tacmd addSystem -t PH -n aixserv1:KUX -p INSTANCE="HMC1

\
"HMC Information".HMC_HOSTNAME=hmc1 "HMC
Information".HMC_USERNAME=hscroot
locally on the system where you installed the HMC Agent. You must establish an ssh key
exchange between the server running the HMC Agent and the HMC. You can either do
HMC Agent Users Guide at:
t6223_user.pdf
the key exchange.
CEC Agent
The CEC Agent must run on an LPAR on the frame that it is monitoring. This section
describes how to install and configure the CEC Agent. This assumes that you are using the
Remote Deploy capability to remotely deploy the agent. Before deploying any other
agent remotely, you MUST install an OS Agent on the target AIX LPAR.
CEC Agent pre-installed in the VIOS

One option for setting up the CEC Agent is that it is pre-installed in the VIOS. If you want
to use this option, you simply need to configure the agent and establish ssl key exchange
with the HMC. The other option is to remotely deploy the CEC Agent to an LPAR. The
remote deployment steps are described in the next 2 sections.
To configure the CEC Agent within the VIOS, you simply need to issue the following
command. When issuing this command, you must be in the restricted shell within the
VIOS. ssh to the VIOS as padmin.
cfgsvc ITM_cec attr HOSTNAME=tems_hostname_or_address1 \
MIRROR=tems_hostname MANAGING_SYSTEM=hmc_user@hmc_hostname \
SECOND_MANAGING_SYSTEM=hmc_user@hmc_hostname CEC=cec_name \
DIRECTOR_HOST_ADDRESS=director_hostname DIRECTOR_AUTHENTICATION=Yes \
DIRECTOR_PORT_NUMBER=8422 RESTART_ON_REBOOT=value
Where:
ITM_cec: Name of the monitoring agent.
(Required) This name must be ITM_cec
-attr
(Required) This parameter indicates that configuration parameters will follow.
HOSTNAME=tems_hostname
(Required) Either the host name or IP address of the Tivoli Enterprise Monitoring
Server to which the CEC Base agent sends data.
MIRROR=tems_hostname
(Optional) Secondary Tivoli Enterprise Monitoring Server host name or IP address.
MANAGING_SYSTEM=hmc_user@hmc_hostname
(Required) hmc_hostname is the host name or IP address of the primary Hardware
Management Console (HMC) that is attached to the managed system on which
the Virtual I/O Server with the monitoring agent is located.
(Optional) hmc_user is the user on the HMC computer with HMC viewer authority.
The default hscroot user ID is used if no other user ID is provided.
The @ symbol is used to separate the user name from the host name, and is
required only when a user name is specified.
SECOND_MANAGING_SYSTEM=hmc_user@hmc_hostname_or_address4
(Optional) Secondary HMC host name or IP address. User ID requirements are the
same as for the primary managing system.
CEC=cec_name
(Required) Name of the managed system that the agent is monitoring. The value
can be determined by running the following command on the HMC and choosing
the correct CEC from the list that the HMC manages: lssyscfg -r sys -F name
DIRECTOR_HOST_ADDRESS=director_hostname
(Optional) IBM Systems Director Server to which to navigate by using the IBM
Systems Director workspace links.
DIRECTOR_AUTHENTICATION=Yes or No
(Optional) Specify Yes or No.
DIRECTOR_PORT_NUMBER=8422
(Optional) Specify the port number, for example 8422.
RESTART_ON_REBOOT=value
(Optional) Specify TRUE or FALSE:
TRUE: ITM_cec restarts when the Virtual I/O Server restarts.
FALSE: ITM_cec does not restart when the Virtual I/O Server restarts.
Here is an example command where we only specify the HUB TEMS on scmtrial, specify
only a primary HMC, and use the default hscroot user account.
cfgsvc ITM_cec attr HOSTNAME=scmtrial MANAGING_SYSTEM=hmc1 \
CEC=cec_name RESTART_ON_REBOOT=TRUE
After configuring the agent, you must setup an ssl key exchange between the VIOS and
the HMC using the username specified during the configuration steps. To setup the ssl
keys, you can use the key.pl script that ships with the monitoring agent. On the VIOS,
you must first exit the restricted shell. To exit the restricted shell, type:
oem_setup_env
Then, change directory to /opt/IBM/ITM/aix523/pk/bin. Next, execute the key.pl
command. You will be prompted for the hostname of the HMC. Enter the shortname or
fully qualified hostname, but ensure that whatever name you use can ping the HMC.
Next, enter the HMC user name that will be accessing the HMC. This user should match
the username you specified earlier and must have hscviewer permissions. You will be
asked whether you want to setup a backup HMC server. This is optional. Next, you will
be asked whether you want to setup a default managed system. Enter Yes and you will
see a list of systems appear. Choose a number corresponding with the default managed
system that you want. That completes the steps for setting up the key exchange.
You may now exist unrestricted shell on the VIOS by typing exit.
Installing and Configuring the CEC Agent via the TEP

Here are the steps to install and configure the CEC Agent via the Tivoli Enterprise Portal
(TEP). Right click on the hostname of the UNIX operating system in the Navigation Tree.
A dialog will open showing the list of available agents to deploy.
Select the Monitoring Agent for CEC Base (32/64 bit) and click OK. You will be
prompted for some configuration information as seen below. On the first panel, you will
be prompted for information related to integration with IBM Systems Director. If you
dont have IBM Systems Director, just leave the defaults. Otherwise, specify the
configuration data for your IBM Systems Director server.
Click Next to go to the Agent tab. By default, the CEC Agent will run as the same user
as the UNIX OS Agent. Normally, this is the root user account. If you wish the agent to
run as another user, specify the username and group name. Otherwise, leave this panel
blank.
Click Finish to begin the remote deployment of the agent. The installation and
configuration will take a few minutes. After a short period of time, a dialog will open
showing you the transaction ID for the remote deployment.
Write down the transaction ID. We can then go into either the Tivoli Enterprise Portal
(TEP) or the CLI to get the status of the deployment. Since were doing a GUI install,
well use the TEP to check the status. In the navigation tree, right click on Enterprise
and select the Deployment Status Summary workspace. At the bottom of the screen,
you will see all of the Remote Deployments. Initially, the Status will show In_Progress.
After a few minutes, the status should be updated to Success which means the
installation is complete.
locally on the system where you installed the CEC Agent. You must establish an ssh key
exchange between the server running the CEC Agent and the HMC. You can either do
CEC Agent Users Guide at:
6222_user.pdf
the key exchange.
Installing and Configuring the CEC Agent via the CLI

If you prefer to install and configure the CEC agent from a command line interface(CLI),
you can use these steps. Either ssh into the scmtrial machine or open a terminal window
within the Virtual Machine. From the command line, issue the following commands.
First, you must login to the HUB TEMS using the following command:
/opt/IBM/ITM/bin/tacmd login s scmtrial t 1440
You will be prompted to enter the username and password. Enter sysadmin as the
username and smartway as the password.
Assuming that you successfully logged into the TEMS with a timeout of 1440 minutes (24
hours), you can issue the command to remotely deploy the agent. The command you will
issue is the following:
tacmd addSystem -t PK -n sample.node.name:KUX \
-p DIRECTOR.KPK_DIRECTOR_AUTHENTICATION=<Yes or No, use TEP credentials to
connect> \
DIRECTOR.KPK_DIRECTOR_HOST_ADDRESS=<Hostname of Director Server> \
DIRECTOR.KPK_DIRECTOR_PORT_NUMBER=<Port number of IBM Systems Director
server>
<Yes or No, use TEP credentials to connect>: The default is Yes to use TEP
credentials to connect to the IBM Systems Director server
<Hostname of Director Server>: This is the hostname or IP address of the IBM

Systems Director server. If you specify the shortname, ensure that you can ping
the IBM Systems Director server using the shortname. Otherwise, specify the IP
address or fully qualified hostname.
<Port Number of IBM Systems Director Server>: This is the port number of the
IBM Systems Director server. The default port is 8422.
Here is an example usage of the command line:

/opt/IBM/ITM/bin/tacmd addSystem -t PK -n aixserv1:KUX \
-p DIRECTOR.KPK_DIRECTOR_AUTHENTICATION=Yes \
DIRECTOR.KPK_DIRECTOR_HOST_ADDRESS=director1 \
DIRECTOR.KPK_DIRECTOR_PORT_NUMBER=8422
locally on the system where you installed the CEC Agent. You must establish an ssh key
exchange between the server running the CEC Agent and the HMC. You can either do
CEC Agent Users Guide at:

6222_user.pdf
where you installed the CEC Agent, change directory to /opt/IBM/ITM/aix523/pk/bin.
the key exchange.
Citrix XenServer Agent

Network connectivity between the agent and each XenServer host
Network connectivity to the XenServer Pool Master is not sufficient. Ports 80 and 443
must be open between the Citrix XenServer agent instance and each of the XenServer
hosts in a pool.
Enabling SSL communication with Citrix XenServer agent data sources
The Citrix XenServer agent can be configured to securely communicate with its XenServer
data sources using SSL certificates. In this configuration, you must add a data source SSL
certificate to the certificate truststore of the agent.
Note: The following information applies only if the agent is configured to validate SSL
certificates. If SSL certificate validation is turned off, the Citrix XenServer agent connects
to XenServer data sources even if their SSL certificates are expired, untrusted, or invalid.
However, turning off SSL certificate validation is potentially not secure and must be done
with care.
The Citrix XenServer agent requires installation of additional files that are not included in
the installation media. You must download the XenServerJava-5.6.100-1 version from the
Citrix website.
The SDK kit can be downloaded from the Download SDKs page of the Citrix Developer
website (http://community.citrix.com/display/xs/XenServer+SDK+Archive).
Extract the following .jar (Java archive) files from the downloaded SDK kit:
ws-commons-util-1.0.2.jar
xenserver-5.6.100-1.jar
xmlrpc-client-3.1.jar
xmlrpc-common-3.1.jar
Place the jar files in: /opt/IBM/ITM/lx8266/xi/bin
Place these files in the following locations:
Windows - %CANDLE_HOME%\TMAITM6
Windows 64 - %CANDLE_HOME%\TMAITM6_x64
Linux - $CANDLEHOME/platform_code/xi/bin

Select the Monitoring Agent for Citrix XenServer and click OK
Specify an instance name. The instance name can be anything you want, but should be
something meaningful. Then, click Next.
The next pane is used to configure the logging settings. The defaults are appropriate. Click
Next to go to the next panel.
In the next panel, specify the default username and password to access the Citrix XenServer and
whether you want to use SSL. These default parameters can make it easier to configure multiple
XenServers.
After you have configured the default parameters, click Next. In the next configuration panel,
click the New button to add Citrix XenServers that you want to monitor. You can add 1 or
more XenServers. For each XenServer you add to the configuration panel, provide the
parameters required to access that XenServer.
After you have added all of the XenServers you want to monitor, click Next and fill in the
username and group that you want the Agent to run as.
Click Finish to complete the configuration and remotely deploy the Agent. After several
minutes, the icon in the upper left corner of the Tivoli Enterprise Portal will indicate that a new
Agent has come online.
Remotely Deploying the Citrix XenServer Agent via the CLI

Here is the syntax for remotely deploying the Citrix XenServer Agent.
tacmd addSystem -t XI -n Primary:sample.node.name:NT
-p INSTANCE="inst1"
DISABLE_CERT_VERIFICATION.KXI_VALIDATE_SSL_CERT=NO
AGENT_CONFIGURATION.KXI_LOGGING_MAX_FILE_COUNT=5
AGENT_CONFIGURATION.KXI_LOGGING_MAX_FILE_SIZE_MB=1
AGENT_CONFIGURATION.KXI_LOG_LEVEL=WARN
DEFAULT_CREDENTIALS.USERNAME=value
DEFAULT_CREDENTIALS.PASSWORD=value
DEFAULT_CREDENTIALS.USE_SSL=NO
XENSERVER_HOSTS_CONNECTIONS:xenserver.poolmember1.USE_SSL=NO
Citrix XenDesktop Agent:

The Citrix XenDesktop Agent is pre-installed in the appliance. You have the option of
either configuring the Citrix XenDesktop Agent that is pre-installed in the image or
remotely deploying the Citrix XenDesktop Agent to another machine. Ensure that the
Agent has network connectivity to the Citrix XenDesktop server
The Monitoring agent for Citrix XenDesktop supports:
Express Citrix Desktop 5
There are some terminology differences between Citrix XenDeskop 4 and 5. The
following section describes the differences.
Site
It is Xendesktop 5 terminology.
Corresponding name in Xendesktop 4 : Farm
Site is a top level logical representation of Xendesktop brokering services
Can have multiple broker controllers for load balancing etc
Broker Controller
Xendesktop 4 terminology : Desktop Delivery Controller
Major component of Xendesktop deployment.
It is a server machine running instances of Broker Service
It responds to desktop launch requests from users.
Responsibilities of Controller
Responds to User request for desktop by selecting appropriate virtual
desktop
Optionally powering it up
Maintaining appropriate number of unused, powered up desktop
machines
Broker Machine
Physical or Virtual machine used to deliver desktop to user.
Broker Catalog
Group of Broker Machines with some criterion
Criteria can be:
ThinCloned, SingleImage, PowerManaged,unmanaged
Thin Cloned and Single Image
Machines created and managed via Provisioning service for VMs.
A thin cloned catalog kind is used when the original golden VM image is
cloned when it is assigned to the VM
A single image catalog is used when multiple PVS for VMs provisioned
machines all share a single golden VM image
PowerManaged
Broker Machines are manually provisioned by administrators
Unmanaged
Broker Machines are unmanaged, so there is no associated hypervisor
connection.
Here is an architectural diagram of Citrix XenDesktop and the Agent:
Installation for Citrix XenDesktop Agent

Hardware Requirements
Any windows or Linux OS system
Software Requirements
Tivoli Monitoring 6.2.2 and future fix packs, mod levels and fix packs

o XDCommands for Citrix XenDesktop 4

o Citrix XenDesktop 5 Snap-in for Citrix XenDesktop 5
Environment requirements and considerations

o Preferable to point a single instance of an agent to a broker controller.
Broker Controller Configuration:

Broker Controller Configuration
Log on to the computer that hosts the broker controller.
Click Start > All Programs > Accessories > Windows PowerShell. A command prompt
opens.
At the command prompt, run the commands in the following sequence:

8. winrm quickconfig
9. cd wsman:
10. Set-Item .\localhost\MaxTimeoutms 600000
11. cd .\localhost\services
12. Set-Item .\AllowUnencrypted $True (Type this command only for the http
communication.)
13. cd .\Auth
14. Set-Item .\Basic $True
Click Start > Run
In the Open field, enter services.msc. The Services window opens.
Right-click Windows Remote Management (WS-Management), and then click

Restart.
Remotely Deploying the Citrix XenDesktop Agent via the CLI

To remotely deploy the Citrix XenDesktop Agent via the CLI, first select the Node where
you want to install the Agent, right click, and select Add Managed System. You will see
the following dialog.
Select the Monitoring Agent for Citrix XenDesktop and click OK.
Fill in the parameters for the remaining tabs.
In the first tab, provide the following parameters:
*Instance Name: This can be any string, but the recommendation is to name the
Instance the same as the hostname of the XenDesktop server.
*Data Source Address: This is the hostname or IP address of the Citrix XenDesktop
server.
*Data Source User ID: This is the user account that will access the Citrix
XenDesktop server.
Data Source Password: Password for the user account specified in the previous
field.
In the next panel, specify the username and password to access the License Server:
Next select the Data Provider Configuration tab. For most environments, the default
parameters are appropriate.
Select the Agent tab and enter the username and group name that you want the Agent
to run as.
Some information about the agent:
It is a Remote Agent
Citrix Xendesktop Provides its own Powershell SDK for data collection
Xendesktop 5 SDK comes with Installation of the controller
Xendesktop 4 SDK may need to be installed separately on the controller
Data Sources other than SDK
Windows Event Log
Performance Counters
The Agent needs to connect to XenDesktop controller Machine which is a

Windows Server OS
WinRM services running on controller processes WS-Man requests received over

the network
A cmd shell prompt executes powershell cmdlets
Hence Powershell exe runs on Broker controller throughout agent lifetime
Troubleshooting key log entries and debugging:
Remotely Deploying the Citrix XenDesktop Agent via the CLI

If you want to deploy the Citrix XenDesktop Agent via the Command Line interface, here
is the syntax and an example command for remotely deploying the Citrix XenDesktop
Agent. The Citrix XenDesktop agent requires the following command:
If you havent logged into the TEMS, login by typing tacmd login s scmtrial u sysadmin
p smartway before issuing any other tacmd command.
tacmd addSystem t V5 n <Managed Systems Name of OS Agent> -p

INSTANCE=<Instance name>
Example:
tacmd addSystem -t V5 -n Primary:host1:NT-p INSTANCE="inst1"
Citrix XenApp Agent:

The Citrix XenApp Agent must be installed on the Citrix XenApp server. In order to install
the XenApp Agent, you will need to obtain the Citrix XenApp Agent media. Once you
have the media, you can either locally install the Agent on the Citrix XenApp server or use
the Remote Deploy capability in IBM Tivoli Monitoring to install the agent from the
Virtual Image. See Appendix A: Remotely Deploying Agents for more information on
Remote Deployment of Agents. The Citrix XenApp Agent does not have any configuration
parameters other than connectivity to the TEMS. Setup the TEMS connectivity just like
any other Agent.
If the Citrix XenApp agent is set up to run under a user account other than the
localsystem account, the user account must have the following permissions:
1. Within the Citrix XenApp agent, the user must be added as a XenApp
Administrator with View-Only or Full permission.
2. The user must have permission to view and run all of the files within the
C:\Program Files (x86)\Citrix\HealthMon\Tests\Citrix folder.
3. The user must be granted Logon As Service permission in either the Domain or
Local Security Policy within Windows.
Remotely Deploying the Citrix XenApp Agent via the TEP

Select the Monitoring Agent for Citrix XenApp and click OK.
In the next panel, you decide whether you want the Agent to run as the local system
account or as a specific username and password. The default is to run as the local system
account.
Click Finish to complete the configuration and initiate the Remote Deployment of the
Agent. After several minutes, the icon in the upper left corner of the TEP will indicate the
new Agent has come online. Click on the icon and the Agent will appear in the
Navigation Tree.
Remotely Deploying the Citrix XenApp Agent via the CLI

To remotely deploy the Citrix XenApp Agent via the Command Line Interface, issue the following
command:
tacmd addSystem -t XA -n Primary:<Hostname of XenApp Server>:NT p
Example:
tacmd addSystem -t XA -n Primary:xenapp1:NT p
After several minutes, the icon in the upper left corner of the TEP will indicate the a new
Agent has come online. Click on the icon and the Agent will appear in the Navigation
Tree.
Cisco USC Agent:

When remotely deploying the Cisco UCS Agent, ensure that the Agent has network
connectivity to the Cisco UCS Manager. The Cisco USC Agent is a multi-instance agent.
When configuring the agent, we recommend you use the name of the Cisco UCS Manager
for the instance name. After specifying the instance name, follow the instructions below.

We recommend remotely deploying the Cisco UCS Manager by right clicking on the Node
where you want to install the Cisco UCS Agent and selecting Add Managed System. You
will see the following dialog. Select the Cisco UCS Agent.
After selecting the Cisco UCS Agent, you will see a set of configuration dialogs.
In the first dialog, enter the following information:
Enter the instance name. Best Practice is to make this the hostname of the Cisco UCS
BladeCenter.
Provide the URL. The URL is typically http://<hostname>/nuova
Enter the username to access the Cisco UCS Manager. Default is admin
Enter the password for the user account.
Enter the path and file for the truststore. The default for a 64-bit Linux system is
/opt/IBM/ITM/lx8266/v6/etc/kv6.truststore
Specify whether you want to validate SSL Certificates. The default is yes.
Click Next
In the following dialog, enter the username and group that the Agent will run as. For
example, enter the username root and group root.
Click Finish to complete the installation of the Agent. Remote Deployment of the
Agent can take several minutes to complete.
Remotely Deploying the Cisco UCS Agent via the CLI

If you wish to remotely deploy the Cisco UCS Agent from the Command Line Interface,
here is the syntax and an example command for remotely deploying the Cisco UCS Agent.
The Cisco UCS agent requires the following command:
tacmd addSystem -t V6 -n Primary:sample.node.name:NT \
-p CONFIG.KV6_PASSWORD=password for UCS Manager \
CONFIG.KV6_SSL_TRUSTSTORE_FILE_PATH=value \
CONFIG.KV6_SSL_VALIDATE_CERTIFICATES=Yes \
CONFIG.KV6_URL=URL for UCS Manager \
CONFIG.KV6_USERNAME=username for UCS Manager \
LOG_CONFIG.KV6_LOG_FILE_MAX_COUNT=Number of log files \
LOG_CONFIG.KV6_LOG_FILE_MAX_SIZE=maximum size of log file \
LOG_CONFIG.KV6_LOG_LEVEL=Log trace level \
INSTANCE=Instance Name
Example:
tacmd addSystem -t V6 -n Primary:host1:NT -p CONFIG.KV6_PASSWORD=passw0rd
CONFIG.KV6_SSL_VALIDATE_CERTIFICATES=No
CONFIG.KV6_URL=http://ucs_manger_host1
CONFIG.KV6_USERNAME=admin LOG_CONFIG.KV6_LOG_FILE_MAX_COUNT=10
LOG_CONFIG.KV6_LOG_FILE_MAX_SIZE=5190 LOG_CONFIG.KV6_LOG_LEVEL=INFO
INSTANCE="inst1"
KVM Agent
The KVM Agent can be configured with multiple protocols. Depending on how you want
the Agent to connect to the monitored KVM server, you will need to take the following
into consideration.
SSH Protocol: The KVM Agent can be configured to use ssh to connect to the KVM
server. If ssh is used, the Agent must be able to connect to the KVM server and
execute commands without being prompted for a username and password. See the
users guide for details on setting up the key exchange required for using ssh without
a username/password.
TLS protocol: For the TLS protocol, assume you install the Linux Kernel-based Virtual
Machines agent on Host A and you want to remotely monitor the hypervisor on Host
B.
Follow these steps:
o Confirm that the gnutls and gnutls-utils packages are installed on the KVM
server.
o Confirm that listen_tls is enabled in /etc/libvirt/libvirtd.conf and the tls_port
o When you get onsite, you will go to libvirt.org/remote.html and follow the
instructions for setting up a certificate authority between Host A and Host B.
Pay special attention to the sections of Setting up a Certificate Authority (CA),
Issuing server certificates, and Issuing client certificates.
o Have the KVM admin restart the libvirt daemon on Host B in listening mode by
running it with --listen flag or by editing /etc/sysconfig/libvirtd and
uncommenting the LIBVIRTD_ARGS="--listen" line.
When you have finished the configuration, check your work using the virsh command
by entering virsh -c qemu+tls://name or IP address of KVM server:port/system. You
can omit the :port section of the command if you have not changed the default TLS
port. If the virsh command succeeds, the Linux Kernel-based Virtual Machines agent
can connect.
TCP protocol: We only recommend using the TCP protocol for testing. For TCP, assume
you install the Linux Kernel-based Virtual Machines agent on Host A and you want to
remotely monitor the hypervisor on Host B. Follow these steps:
o Have the KVM admin log in to the KVM server.
o Edit /etc/libvirt/libvirtd.conf to make sure that listen_tcp is enabled and tcp_port
o Edit /etc/libvirt/libvirtd.conf to set auth_tcp to "none". This instructs TCP not to
perform any authentication.
o Restart the libvirt daemon on Host B in listening mode by running it with --listen
flag or by editing /etc/sysconfig/libvirtd and uncommenting the
LIBVIRTD_ARGS="--listen" line.
When you have finished the configuration, check the configuration using the virsh
command by entering virsh -c qemu+tls://name or IP address of KVM
server:port/system. You can omit the :port section of the command if you have not
changed the default TLS port. If the virsh command succeeds, the Linux Kernel-based
Virtual Machines agent can connect.
The KVM Agent is a remote monitoring Agent. It may be installed on the KVM server or
another server. The KVM Agent is a multi-instance agent. When configuring the KVM
Agent, one of the parameter you must specify is the instance name.
Remotely Deploying the KVM Agent via the Tivoli Enterprise Portal
To Remotely Deploy the KVM Agent via the Tivoli Enterprise Portal, right click on the
Node where you want the Agent deployed and select Add Managed Systems. You will
see the following dialog appear.
Select the Monitoring Agent for Linux Kernel-based Virtual Machines (32 bit) and click
OK.
In the next dialog, you will see three tabs. Fill in the data on each of the tabs.
In the first tab, enter an instance name. This can be anything meaningful. We suggest
leaving the logging configuration parameters with the defaults.
In the Hypervisor tab, add 1 or more systems to monitor by clicking the New button and
filling in the information for the KVM system being monitored.
Specify the Hypervisor ID. Best Practice is to use the hostname for the Hypervisor ID.
Specify the Host (hostname) of the KVM server being monitored.
Specify the User that will access the hypervisor. For example, specify root
Sepcify the Remote Transport. The default is SSH.
Specify the port. For SSH, the default port is 22.
Specify the Connection Instance Type. In most cases, the default of system is correct.
Finally, specify the information in the Agent tab. This is the Username and Group name
that the Agent will run as.
Click the Finish button to complete the Remote Deployment. After several minutes, the
icon in the upper left corner of the TEP will indicate the a new Agent has come online.
Click on the icon and the Agent will appear in the Navigation Tree.
Remotely Deploying the KVM Agent via the Command Line Interface
If you wish to remotely deploy the KVM Agent using the command line interface, here is
the syntax and an example command for remotely deploying the KVM Agent. The KVM
agent requires the following command:
tacmd addsystem -t v1 -n <Managed System Name of OS Agent> \
-p DATA_PROVIDER.KV1_LOG_FILE_MAX_COUNT=<number of log files> \
DATA_PROVIDER.KV1_LOG_FILE_MAX_SIZE=<Size of log files> \
DATA_PROVIDER.KV1_LOG_LEVEL=<Log tracing level> \
INSTANCE=<instanceName> \
HYPERVISOR:UniqueDataSourceID.HOST_ADDRESS=<hostAddressOrName> \
HYPERVISOR:UniqueDataSourceID.USERNAME=<user> \
HYPERVISOR:UniqueDataSourceID.PROTOCOL=><ssh|tls|tcp> \
HYPERVISOR:UniqueDataSourceID.PORT=<port> \
HYPERVISOR:UniqueDataSourceID.CONNECTION_MODE=<system>
Example:
tacmd addsystem -t v1 -n linux1:LZ -p DATA_PROVIDER.KV1_LOG_FILE_MAX_COUNT=10
DATA_PROVIDER.KV1_LOG_FILE_MAX_SIZE=5190
DATA_PROVIDER.KV1_LOG_LEVEL=INFO
INSTANCE=inst1 HYPERVISOR:UniqueDataSourceID.HOST_ADDRESS=kvmsrv1
HYPERVISOR:UniqueDataSourceID.USERNAME=root
HYPERVISOR:UniqueDataSourceID.PROTOCOL=ssh
HYPERVISOR:UniqueDataSourceID.PORT=22
HYPERVISOR:UniqueDataSourceID.CONNECTION_MODE=system
Tivoli Storage Productivity Center (TPC) Agent

The Tivoli Storage Productivity Center (TPC) Agent can be installed on the TPC server or
remotely. The Agent accesses the TPC server using the default port 9550. Request that
the network team opens up port 9550 between the Agent and the TPC server.
In the first configuration panel, specify the path and filename of the logfile and the
log trace setting.
In the next configuration panel, specify the hostname, port and password to connect to
the TPC server. The default port number is 9550.
On the next 4 configuration panels, add an entry for each of the subnodes that you want
monitored. For example, if you dont have SAN fabric or SAN switches to montor, you
can leave that panel blank.
On this panel, specify the server being monitored.
On the next panel, specify whether you want to monitor the computers and hypervisor
node. The value specified in the dialog doesnt matter.
In the next panel, specify any value if you want to monitor the storage systems.
IBM Systems Director Integration

Application Support for the IBM Systems Director Agent is pre-installed in the Virtual Image. If
you wish to install the IBM Systems Director Agent, you will need to download the media for the
agent. The Agent requires IBM Systems Director V6.1.1.2 or higher. There are two ways
for the Agent to authenticate to IBM Systems Director. It can either use the TEPS
credentials or the user can specify a username and password the first time they use the
IBM Systems Director workspaces in TEP. In either case, you should request a valid
username and password on the IBM Systems Director server.
Agentless OS Monitoring Agent
The UNIX and Linux Agentless monitoring agents use SNMP to connect to the
monitored servers. The default SNMP port is 161. For each monitored server,
gather the following information:
SNMP listening port
SNMP version (v1, v2c, or v3)
SNMP Community string
For SNMP v3, provide a username and password with access to SNMP
The Solaris Agentless monitoring agent has 2 other optional configurations.

Instead of using native SNMP to gather data, the server may be setup with
SunMC. This using SNMP, but the configuration is slightly different. Please
see the users guide for details on configuring the agent with SunMC. Solaris
can also be monitored using CIM. CIM is the slowest of the protocols, so we
recommend SNMP or SunMC.
If you want to use CIM, ensure the CIM service is configured and started. To
start the CIM service on Solaris, run the following command:
# /etc/init.d/init.wbem start.
To manage the CIM service on Solaris, run this command:
# /usr/sadm/bin/wbemadmin.
CIM uses port 5988. Ensure that port 5988 is open between the agent and
the monitored server.
Provide a username and password that has access to the CIM service.
Ensure that UDP port 161 is open between the Agentless monitoring agent and the
monitored server.
Each of the operating systems has slightly different configuration requirements for
SNMP. Ensure that the following configurations are setup properly on the monitored
server. Here are some tips for SNMP configuration for each operating system. For
more information, see the users guide for each agent.
AIX:
1. All three SubAgent daemons (aixmibd, hostmibd, and snmpmibd) must be
started to obtain the metric data required.
2. For non-default community names, each SubAgent must be restarted with
knowledge of the community name. For example:
stopsrc -s hostmibd
startsrc -s hostmibd -a -c community_name
5. Also, the SNMP daemon (snmpd) must be refreshed after making any of
the changes above: refresh -s snmpd
6. Lastly, verify that none of the SubAgent details are excluded in the
/etc/snmpdv3.conf. For example, a common line to comment out is:
VACM_VIEW defaultView 1.3.6.1.4.1.2.6.191 - excluded -Commenting
this line allows the aixmibd SubAgent to be included in SNMP Requests.
Linux:
o On SuSE Linux Enterprise version 9 remote systems, Service Pack 3 or later
(provides net-snmp-5.1-80.22.rpm or later) is required to correctly collect
memory statistics.
o For Red Hat operating systems, the /etc/snmpd.conf must be modified to
allow the Host Resources MIB and ucdavis MIB to be viewed by all users.
o Add the following system views to the SNMP configuration:
HP/UX:
o Follow HPs documentation to setup SNMP.
Solaris
o Follow Oracles documentation to setup SNMP or SunMC
Remotely Deploying the Agentless OS Monitoring Agents via the TEP

To Remotely Deploy any of the Agentless Monitoring Agents via the Tivoli Enterprise
Portal, right click on the Node where you want the Agent deployed and select Add
Managed Systems. You will see the following dialog appear.
Select the Agentless Monitoring Agent that you wish to deploy. The Linux, AIX, and HP-UX
Agentless Monitor Agent configuration panels will be identical. The Solaris and Windows
Agentless Monitoring Agents have a few other options that are shown below.
The first configuration panel will prompt you for the instance name and the default SNMP
settings. The instance name needs to be unique, but can be any value.
Click the Next button.

Depending on which SNMP version you chose, you will see different options in the next screen.
For SNMP v1 and v2c, you will be prompted for the default Community Name as seen below.
After populating the default values, click Next. The next panel allows you to add one or more
monitored systems. Unless you click the Advanced button, the monitored system will use the
default settings you previously specified. Notice in the example below that we have one system
thats using the default settings and one that is overriding the defaults and using SNMP v3
When you are done adding the remotely monitored systems, click Next and fill in the
information regarding the user that the Agent will run as.
When you are finished, click Finish. After several minutes, the icon in the upper left
corner of the TEP will indicate the a new Agent has come online. Click on the icon and
the Agent will appear in the Navigation Tree.
Here is an example of the Solaris configuration panel for using CIM for agentless monitoring.
When using Windows WMI agentless monitoring, you will set a default password. Then, you will
add one or more remote monitoring systems using the configuration panel shown below.
In this example, notice that Ive used our Best Practice and named the Managed System Name
the same as the hostname of the monitored system. In the first example, Ive shown a system
that is part of a workgroup. In the second example, the server belongs to the TIVOLI domain.
Notice that you must include the Domain name along with the username.
Appendix B: Problem Determination

If you have any problems with this virtual image, this section will outline steps to diagnose and
correct the problem. In addition, you can post questions to the SmartCloud Monitoring Demo
Forum at: http://www.ibm.com/developerworks/forums/forum.jspa?forumID=2757
DB2 wont start:

If DB2 wont start, there are a couple of possibilities. Since the image ships with a Trial license for
DB2 and youve been running the image for more than 90 days, the license will have expired.
Assuming the license hasnt expired, there is another possible cause. Ive seen cases where the
file permissions on /etc/resolv.conf are wrong and the db2inst1 user cant ping the scmtrial
hostname. Check the file permissions on /etc/hosts and on /etc/resolv.conf. The db2inst1 user
needs read-only permissions. If you type ls al, the permissions should be 644. Its okay if the
permissions give you more than read-only authority such as 666 or 755, but make sure that the
last digit is not a zero. Also check to make sure that the contents of the /etc/hosts file are
correct. It should contain the correct IP address, hostname, and domain name for scmtrial.
TEPS is not available:

There are a couple possible causes of the TEPS not being available.
DB2 is not running: The most likely in this demo environment is that DB2 did not
start automatically when the machine booted. Login to the system as db2inst1 and
issue the db2start command or use the ps ef | grep db2 command to make sure that
all of the DB2 processes are running. You should see the following processes: db2fmp,
db2wdog, db2ckpwd, db2vend, db2acd, etc. If all of these processes are not running, use
the db2start command to start DB2. Then, restart the TEPS. See the following section
on starting the TEPS
TEPS is not running: If the TEPS process is not running, you can start it manually
using the steps below. First, check whether the TEPS is running by issuing the following
command ps ef | grep cq. You should see two processes running including
KfwServices. Assuming the TEPS is not running, perform the following steps. Logon to
the system as the root use account. Then, cd to /opt/IBM/ITM/bin. Issue the following
command: ./itmcmd agent start cq. If DB2 did not start when the machine booted,
you will need to stop and then start the TEPS using the following two commands:
./itmcmd agent stop cq
Followed by
./itmcmd agent start cq
Unable to launch TEPS Login

The browser version of the TEP client is not configured to run within the VMware image.
It can be run remotely from your base OS, but not from within the Virtual Machine. If
you want to access the TEP Client from within the Virtual Machine, use the Java Web Start
Client. This can be launched by opening the following URL in the Firefox browser:
http://scmtrial:1920///cnp/kdh/lib/tep.jnlp
HUB TEMS is not running:

If for some reason the HUB TEMS did not start properly, you will not be able to login to the TEPS.
First, check whether the TEMS is running by issuing the following command: ps ef | grep
kdsmain and verify that the process is running. If the kdsmain process is not running, perform
the following steps to start the HUB TEMS. First, cd to /opt/IBM/ITM/bin. Then, issue the
command ./itmcmd server start TEMS. After starting the TEMS, you may need to wait a few
minutes for the TEPS to connect to the HUB TEMS.
Summarization & Pruning Problems:

Occasionally, the Summarization & Pruning Agent does not start when the operating system
boots. If this happens, you will notice that the Summarization & Pruning Agent is grayed out in
the Tivoli Enterprise Portal Server (TEPS). To start the Summarization & Pruning Agent, type the
following command:
/opt/IBM/ITM/bin/itmcmd agent start sy
IBM Dashboard Application Services Hub (DASH) (TIP) is Unavailable:

If TIP is unavailable, the first thing to do is check whether the processes are running. Issue the
following command ps ef | grep AppServer. You should see 3 processes running.
Processes are running, but DASH unavailable:

If the DASH processes are running, but DASH is unavailable, restart DASH using the
following steps. First, login into the operating system as. Next issue the following
commands:
/opt/IBM/JazzSM/profile/bin/stopServer.sh server1
After you issue the stopServer.sh command, you will be prompted for the TIP
administrator account and password. The account is smadmin and the password is
smartway.
After stopping DASH, issue the following command to start DASH.
/opt/IBM/JazzSM/profile/bin/startServer.sh server1
DASH Processes are not running:

If the DASH processes are not running, you can follow the previous steps, but you wont
need to stop the TIP server. Ensure you are logged in as root and then issue the
following command:
/opt/IBM/JazzSM/profile/bin/stopServer.sh server1
Agents are not available in TEP:

If the Agents show up as offline (grayed out) in the TEP client, there are a couple possible
solutions. Due to the startup sequence of the operating system, its possible that the Agents
started before the TEMS was available for connections. At the next heartbeat interval, the agents
will connect to the TEMS and show up as online in the TEP. Wait several minutes after powering
on the machine before attempting to fix the problem. Or, you can type the command ps ef |
grep ITM to see if the Agents are running. You should see processes like klzagent, kvmagent, etc.
If you either determine that the Agents arent running or you have waited several minutes with
no luck, you can perform the following steps.
If the Agent processes are running, first stop the processes by typing
/opt/IBM/ITM/bin/itmcmd agent stop all
Then, start the agents by typing:
data/IBM/ITM/bin/itmcmd agent start all
If the Agents were not running, skip the first step and just issue the following command:
data/IBM/ITM/bin/itmcmd agent start all
No Data is Available in the Health Dashboard

When this happens, there are two possible causes.
The first cause is that the Tivoli Portal Server didnt start properly. You can check for this
by typing ps ef | grep cq. If your results look something like this, the Tivoli Enterprise
Portal isnt running.
[root@scmtrial (Scmtrial Trial) bin]# ps -ef | grep cq
root
226 60 0 May11 ?
00:00:00 [cqueue/0]
root
227 60 0 May11 ?
00:00:00 [cqueue/1]
root
8895 7906 0 19:50 pts/2 00:00:00 grep cq
[root@scmtrial (Scmtrial Trial) bin]#

Start the Tivoli Enterprise Portal Server by issuing the following command:
Itmcmd agent start cq
Then, restart the IBM Dashboard Application Services Hub (DASH) by issuing the following
commands:
cd /opt/IBM/JazzSM/profile/bin
./stopServer.sh server1 -username smadmin -password smartway
./startServer.sh server1
The other possible cause is that the IBM Dashboard Application Services Hub (DASH)
started before IBM Tivoli Monitoring. If this happens, the product will eventually start
collecting data and display it in the dashboard, but it may take a while. Instead of
waiting, restart the DASH server using the previous steps.
Capacity Planning is not returning data

The likely cause of this problem is that DB2 did not start properly when the machine booted. The
easiest solution to the problem is to use the two icons on the Linux desktop to stop and then start
the demo components using the StartDemo and StopDemo icons on the desktop as seen
below.
Capacity Planning or TCR reports fail with a Cognos Error

There are a couple of possible causes for this problem and resolutions documented below.
Occasionally objects in your browser cache cause problems for the IBM Dashboard
Application Services Hub (DASH) and Cognos. Clear your Browser Cache and log back into
TIP.
Make sure that you are running a supported browser version. This software only
supports Firefox version 3.6.x and Internet Explorer version 8.x.
Occasionally, the Cognos report server does not start properly. If this happens, stop the
DASH server and restart it using the following commands.
cd /opt/IBM/JazzSM/profile/bin
./stopServer.sh server1 -username smadmin -password smartway
./startServer.sh server1
Previous Workarounds Fail to Resolve the Problem

If all previous workarounds fail to resolve the problem, double check the DASH Connections
You will see a connections panel similar to the one seen below.
Select each of the following connections and press the Edit icon. You will want to verify the
settings for each of the Connections below.
TEMS
For the TEMS, confirm that the hostname is either localhost or scmtrial. Confirm that the
port is 15200. This is the port that the Tivoli EnterprisePortal Server (TEPS) is listening on.
Connection: ITMfVE Capacity Planning Datamart for VMware
For the Connection for ITMfVE Capacity Planning Datamart for VMware, verify that the
information is correct. The hostname should be localhost or scmtrial. The port is the port
number that DB2 is using which by default is 50,000. The database name for the trial is
TADFDCDB. The schema for the trial is TADFDC. The username is db2inst1 and the default
password is smartway. Unless you changed some configuration parameters such as the
password for the db2inst1 user, please use these settings.
If you wish to confirm the port that DB2 is using, login to server as db2inst1 and issue the
following command:
db2 get dbm cfg | grep SVCENAME
You will see a result similar to the following:
TCP/IP Service name
(SVCENAME) = db2c_db2inst1
One you have identified the name of the service that DB2 is using, you can lookup the port
number in the /etc/services file. In this case, the service name is db2c_db2inst1. By editing the
/etc/services file, you will see an entry with the service name and port number. The entry will
look like the following:
db2c_db2inst1 50000/tcp
In this case, we are using the default DB2 port number or 50,000.
Connection: ITMfVE Capacity Planning Datamart for PowerVM

The settings for the Connection for the ITMfVE Capacity Planning Datamart for PowerVM are
nearly identical to the settings for VMware. The only difference is that the schema name is
TADFDCP for PowerVM instead of TADFDC for VMware.
Connection: TDI
For the TDI (Tivoli Directory Integrator) connection, you only need to specify one parameter. The
URL for the TDI server should be set to http://localhost:1098/rest or http://scmtrial:1098/rest. If
you are using an external TDI server, the replace localhost or scmtrial with the hostname of your
TDI server.
It is not necessary to specify a username and password in the TDI connection panel.
Connection: VMware Dashboard

The Connection for the VMware Dashboard is only required if you are trying to integrate data
from TADDM. If you are integrating TADDM, then specify the correct parameters for your
TADDM server. The default port number for the TADDM server should already be filled in.
Specify the correct hostname, username, and password to access the TADDM server.
Appendex D: References
Here are some references that you will find useful if you are not familiar with ITM or the various
monitoring agents:
ITM Installation Guide: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.itm.doc_6.3fp2/install/itm_inst
all.htm?lang=en
ITM Command Reference: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.itm.doc_6.3fp2/ic/landing_cmd
ref.htm?lang=en
ITM Troubleshooting Guide: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.itm.doc_6.3fp2/ic/landing_trou
bleshoot.htm?lang=en
ITM Messages Guide: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.itm.doc_6.3fp2/ic/landing_mes
sages.htm?lang=en
Prerequisites: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2.0.2/prerequ
isites/ve72fp2_systemreqs.html?lang=en
Dashboard, Reporting, and Capacity Planning Users Guide: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2.0.2/dashbo
ards_reports/drcp_landing_user.html?lang=en
VMware VI Agent: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2.0.2/vmwar
e/fac_landing_user.html?lang=en
ITCAM for Microsoft Applications: http://www01.ibm.com/support/knowledgecenter/http://www.ibm.com/support/knowledgecenter/SSDKXQ
_6.3.1/com.ibm.itcamms.doc_6.3.1/welcome_msapps631.html?lang=en
Cisco UCS Agent:
http://publib.boulder.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.tivoli.itmvs.doc_7.2/cisc
oucsagent72_user.pdf
Citrix XenApp Agent:
http://publib.boulder.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.tivoli.itmvs.doc_7.2/xen
appagent72_user.pdf
Citrix XenDesktop Agent:

desktopagent72_user.pdf
http://support.citrix.com/product/xd/v5/
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-overview-key-featuresrho.html
Citrix XenServer Agent:
serveragent72_user.pdf
Linux KVM Agent:
http://publib.boulder.ibm.com/infocenter/tivihelp/v61r1/topic/com.ibm.tivoli.itmvs.doc_7.2/kv
magent72_user.pdf
NetApp Agent: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2/netapp/fac
_aboutthisdoc.html?lang=en
Network Device Agent: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2/devices/fac
_aboutthisdoc.html?lang=en
TPC 5.1.1 Documentation: http://www01.ibm.com/support/knowledgecenter/SS4EKN_7.2.0.2/com.ibm.tivoli.itmvs.doc_7.2/storagepro
dctr.html?lang=en
Trademarks
IBM, the IBM logo, AIX, DB2, the e-business logo, the eServer logo, Lotus, Tivoli, and WebSphere are trademarks of
International Business Machines Corporation in the United States, other countries or both.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other
countries or both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.UNIX is a registered trademark of The Open Group in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product and service names may be trademarks or service marks of others.

Copyright IBM Corporation 2014
IBM United States of America
Produced in the United States of America
All Rights Reserved
The e-business logo, the eServer logo, IBM, the IBM logo, OS/390,
zSeries, SecureWay, S/390, Tivoli, DB2, Lotus and WebSphere are
trademarks of International Business Machines Corporation in the
United States, other countries or both.
Lotus, Lotus Discovery Server, Lotus QuickPlace, Lotus Notes,
Domino, and Sametime are trademarks of Lotus Development
Corporation and/or IBM Corporation.
Java and all Java-based trademarks and logos are trademarks of Sun
Microsystems, Inc. in the United States, other countries or both.
Other company, product and service names may be trademarks or
service marks of others.
INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PAPER AS IS WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this
statement may not apply to you.
Information in this paper as to the availability of products (including
portlets) was believed accurate as of the time of publication. IBM
cannot guarantee that identified products (including portlets) will
continue to be made available by their suppliers.
This information could include technical inaccuracies or typographical
errors. Changes may be made periodically to the information herein;
these changes may be incorporated in subsequent versions of the
paper. IBM may make improvements and/or changes in the product(s)
and/or the program(s) described in this paper at any time without
notice.
Any references in this document to non-IBM Web sites are provided for
convenience only and do not in any manner serve as an endorsement
of those Web sites. The materials at those Web sites are not part of
the materials for this IBM product and use of those Web sites is at your
own risk.
IBM may have patents or pending patent applications covering subject
matter described in this document. The furnishing of this document
does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
4205 South Miami Boulevard
Research Triangle Park, NC 27709 U.S.A.

SmartCloudMonitoring Trial 7.2 FP2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SmartCloudMonitoring Trial 7.2 FP2

Загружено:

Авторское право:

Доступные форматы

IBM SmartCloud Monitoring 7.

Copyright International Business Machines Corporation 2014. All rights reserved.

If you need access to hatsize, send an E-mail to

o http://demoworks.democentral.ibm.com/demoworks/index.php (IBM and

o CSIDE (formerly TIDE-AG) website (IBM Intranet ID required):

Key Enhancements in SmartCloud Monitoring 7.2 FP2

Completely rewritten VMware Health Dashboard

New DASH (IBM Dashboard Application Server Hub) user interface

o Self-Service dashboards. Build custom dashboards using any IBM Tivoli

Improved VMware Capacity Planning:

consolidation of UNIX OS Agent and Premium AIX Agent

Enhancements to the HMC Agent which now includes CPU

Enhancements to other hypervisors

Key Enhancements to the SmartCloud Monitoring 7.2 FP2 Trial

Provides a SynthesizeHistory script that allows you to synthesize historical data

All passwords on the system are initially configured to smartway

Exercise 4: Additional Virtualization Agents ...................................................................... 85

Agent Configuration: ......................................................................................................... 139

Other Agents:.................................................................................................................................. 173

Connection: VMware Dashboard .................................................................................................. 251

ITM 6.3 environment including:

o Citrix XenDesktop Agent

Capacity Planning reports for VMware

Capacity Planning reports for PowerVM

o Dashboards for VMware Clusters and VMware ESX Servers

o Sample Custom Dashboard using Tivoli Directory Integrator to gather data

(DASH): https://scmtrial:16311/ibm/console/logon.jsp. Login as smadmin with

Detailed Installation Steps:

Confirm that you have an appropriate VMware VSphere or VMware Workstation

An IP address must be assigned to the VMware Virtual Machine. The hostname

Booting the Virtual Machine

Here is an example of the networking configuration for a static IP address.

Next, you will be asked to confirm the network configuration settings:

sections, other deployment options will be discussed. Our recommended configuration

Common Configuration Steps

Running the Trial Image

Login to the TEP client as sysadmin with password smartway

To access the DASH server interface, open the following URL:

Exploring IBM SmartCloud Monitoring

Configuring VMware Environments:

VMware VI Agent Prerequisites:

System.View and System.Read privileges on all data source objects being

Virtual Machine-Interaction-Power Off

The VMware VI Agent uses either HTTPS or HTTP to communicate to VCenter or

Configuring the VMware VI Agent

IBM Systems Director Integration

NetApp Agent Integration

Next, click on the Data Source tab

Click the New button to add a VCenter or ESX/ESXi server to monitor.

Enter the information required for your VMware environment.

Requirements for Historical Data

/opt/IBM/ITM/bin/itmcmd agent stop sy

/opt/IBM/ITM/bin/itmcmd agent start sy

Click here to view the Health Dashboard

Now, lets examine the contents of the dashboard.

Key KPIs per Cluster

Top 5 Clusters for CPU, Memory, and Storage

Exercise 2: TCR Reports

Click for more

The VMware reports are divided into five categories:

Workload Performance Trends and Forecasting: These reports show

Click here to return

Exercise 3: Capacity Planning

What ESX/ESXi hardware should I purchase in anticipation of additional load in the