Beruflich Dokumente
Kultur Dokumente
Version 7.2.4.4
Installation and Administration Guide
SC34-2657-08
Note
Before using this information and the product it supports, read the information in Notices on page 525.
Edition notice
This edition applies to IBM Tivoli Service Automation Manager Version 7 Release 2 Modification Level 4 Fix Pack 4
(program number 5724W78), available as a licensed program product, and to all subsequent releases and
modifications until otherwise indicated in new editions.
This edition replaces SC34-2657-07 and any previous editions.
IBM Tivoli Service Automation Manager is also a key part of the software delivered with IBM CloudBurst, an
integrated hardware and software appliance offering.
Order publications through your IBM representative or the IBM branch office serving your area. Publications are
not stocked at the addresses given below.
Address comments on this publication to:
IBM Systems and Technology Group
Systems Software Development
Rajiv Gandhi Infotech Park Phase 2
Plot no Pl - 3 Midc, Hinjewadi, Village limit,
Of Marunji,
Pune, Maharashtra
India - 411057
Make sure to include the following in your comment or note:
v Title and order number of this book
v Page number or topic related to your comment
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any
way it believes appropriate without incurring any obligation to you.
Copyright IBM Corporation 2008, 2012.
US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Tables . . . . . . . . . . . . . . . xi
Preface . . . . . . . . . . . . . . xiii
Who should read this information . . . . . . xiii
Useful links . . . . . . . . . . . . . . xiii
Support information . . . . . . . . . . . xiv
Getting technical training . . . . . . . . xiv
Searching knowledge bases . . . . . . . . xiv
Searching the Internet . . . . . . . . xiv
Using IBM Support Assistant . . . . . . xv
Finding product fixes . . . . . . . . . xv
Getting email notification of product fixes . . xv
Contacting IBM Software Support . . . . . xvi
Setting up a software maintenance contract xvi
Determine the business impact . . . . . xvii
Describe the problem and gather background
information . . . . . . . . . . . . xvii
Submit the problem to IBM Software
Support . . . . . . . . . . . . . xvii
Chapter 1. Tivoli Service Automation
Manager overview . . . . . . . . . . 1
Product components . . . . . . . . . . . . 2
Tivoli Service Automation Manager Installation
Launchpad . . . . . . . . . . . . . . 2
Self-Service Virtual Server Management . . . . 2
User interfaces. . . . . . . . . . . . . 3
Applications in the administrative user interface . 3
Service Definitions application . . . . . . 4
Service Deployment Instances application . . 4
Resource Allocation applications. . . . . . 4
Monitoring Definition applications for
WebSphere Cluster service. . . . . . . . 4
Situation Analysis application . . . . . . 5
Cloud Server Pool Administration application 5
Cloud Storage Pool Administration application 5
Cloud Network Administration application . . 5
Cloud Customer Administration application . . 6
Cloud Maintenance Administration application 7
Service Topology application . . . . . . . 7
Service Update Package application. . . . . 8
Service Topology Node applications . . . . 8
IT Topology Work Orders application . . . . 8
Auxiliary applications . . . . . . . . . 9
WebSphere Cluster Service. . . . . . . . . 9
Service topology node attributes . . . . . 13
Performance monitoring support for the
WebSphere Cluster service . . . . . . . 16
Service structure. . . . . . . . . . . . . 17
Service provider support . . . . . . . . . . 18
Reporting function . . . . . . . . . . . . 20
Tivoli Service Automation Manager report types
and content . . . . . . . . . . . . . 20
Tivoli Usage and Accounting Manager reporting
function . . . . . . . . . . . . . . 21
Additional software installation on the provisioned
servers . . . . . . . . . . . . . . . . 21
VMware additional disk functionality . . . . . 22
VMware clone server functionality . . . . . . 22
Managing POWER LPAR provisioning with
VMControl . . . . . . . . . . . . . . 23
Image management. . . . . . . . . . . . 23
Workload Deployer overview . . . . . . . . 24
Maintenance mode overview . . . . . . . . 25
Chapter 2. Installing and upgrading
Tivoli Service Automation Manager . . 27
Overview of the Tivoli Service Automation Manager
installation process . . . . . . . . . . . . 27
Planning for Tivoli Service Automation Manager . . 28
Hardware and operating system requirements for
Tivoli Service Automation Manager . . . . . 28
Software requirements for Tivoli Service
Automation Manager . . . . . . . . . . 36
Web browser settings . . . . . . . . . 39
Requirements for Self-Service Virtual Server
Management . . . . . . . . . . . . . 40
Requirements for the System z environment . . 40
Providing the installation source files . . . . . 42
Restrictions and limitations . . . . . . . . 44
Installing Tivoli Service Automation Manager . . . 45
Full Installation of Tivoli Service Automation
Manager 7.2.4.4 . . . . . . . . . . . . 45
Preparing the environment for installation . . . 48
Preparing an AIX management server . . . 48
Verifying settings required for installing the
middleware on an AIX management server. 49
Verifying the settings required to install
Tivoli Provisioning Manager on an AIX
management server. . . . . . . . . 50
Packages required on an AIX management
server . . . . . . . . . . . . . 55
Preparing a Linux management server . . . 58
Verifying the settings required to install the
middleware on a Linux management server 59
Verifying the settings required to install
Tivoli Provisioning Manager on a Linux
management server. . . . . . . . . 60
Packages required on a Linux management
server . . . . . . . . . . . . . 64
Preparing a Windows administrative server . 66
Preparing a Linux administrative server . . . 66
Preparing an AIX administrative server . . . 67
Starting the launchpad and performing the
preinstallation steps . . . . . . . . . . 67
Installing Tivoli Service Automation Manager
and its prerequisite software. . . . . . . . 68
Installation defaults for Tivoli Service
Automation Manager . . . . . . . . . 69
Copyright IBM Corp. 2008, 2012 iii
Installing the Tivoli Service Automation
Manager license . . . . . . . . . . . 70
Installing the middleware . . . . . . . 71
Installing base services . . . . . . . . 72
Installing the Tivoli Provisioning Manager
core components . . . . . . . . . . 73
Installing the Tivoli Provisioning Manager
Web components . . . . . . . . . . 74
Installing Tivoli Service Request Manager . . 75
Installing the Advanced Workflow
Components . . . . . . . . . . . . 77
Installing Tivoli Provisioning Manager 7.2.1
Interim Fix 5 core components . . . . . . 78
Installing Tivoli Provisioning Manager 7.2.1
Interim Fix 5 Web components . . . . . . 78
Installing the Tivoli Service Automation
Manager applications . . . . . . . . . 79
Installing additional configuration files . . . 80
Installing the automation packages for Tivoli
Service Automation Manager . . . . . . 81
Post-installation steps . . . . . . . . . . 82
Installing optional software . . . . . . . . 83
Verifying the integrated installation . . . . . 84
Upgrading Tivoli Service Automation Manager from
7.2.2.1, 7.2.2.2, 7.2.3, 7.2.4, 7.2.4.1, 7.2.4.2, 7.2.4.3 to
7.2.4.4 . . . . . . . . . . . . . . . . 85
Starting the launchpad and performing the
preinstallation steps . . . . . . . . . . 85
Uninstalling the additional disk extension for
VMware . . . . . . . . . . . . . . 86
Installing the product . . . . . . . . . . 88
Installing the Advanced Workflow Components 88
Installing Tivoli Provisioning Manager 7.2.1
Interim Fix 5 core components . . . . . . . 89
Installing Tivoli Provisioning Manager 7.2.1
Interim Fix 5 Web components . . . . . . . 89
Performing the post-installation steps. . . . . 90
Finishing the upgrade . . . . . . . . . . 90
Mandatory data migration when upgrading from
Tivoli Service Automation Manager 7.2.2.1 to
7.2.4.4 . . . . . . . . . . . . . . . 91
Upgrading the service instance to the new
revision. . . . . . . . . . . . . . 92
Upgrading network . . . . . . . . . 92
Defining an IP address selection rule . . . 92
Running IP address discovery for
operational servers . . . . . . . . . 93
Migrating restored VMware servers . . . . 94
Migrating VMware Additional Disks . . . . 95
Mandatory data migration when upgrading from
Tivoli Service Automation Manager 7.2.2.2 to
7.2.4.4 . . . . . . . . . . . . . . . 95
Upgrading the service instance to the new
revision. . . . . . . . . . . . . . 96
Mandatory data migration when upgrading from
Tivoli Service Automation Manager 7.2.3 to
7.2.4.4 . . . . . . . . . . . . . . . 97
Mandatory data migration when upgrading from
Tivoli Service Automation Manager 7.2.4 to
7.2.4.4 . . . . . . . . . . . . . . . 98
Mandatory data migration when upgrading from
Tivoli Service Automation Manager 7.2.4.1 to
7.2.4.4 . . . . . . . . . . . . . . . 99
Mandatory data migration when upgrading
from Tivoli Service Automation Manager 7.2.4.2
to 7.2.4.4 . . . . . . . . . . . . . . 100
Mandatory data migration when upgrading
from Tivoli Service Automation Manager 7.2.4.3
to 7.2.4.4 . . . . . . . . . . . . . . 101
Enabling Tivoli Monitoring agent. . . . . . 102
Configuring IBM HTTP Server . . . . . . . 103
Configure the web server to handle HTTP
requests . . . . . . . . . . . . . . 103
Configure the web server to handle HTTPS
requests . . . . . . . . . . . . . . 104
Optional system settings after installation . . . . 106
Disabling Tivoli Provisioning Manager Software
Distribution Infrastructure . . . . . . . . 106
Additional tools and system health options . . . 106
Tools for the Management Server. . . . . . 106
Tools for the Administrative Server . . . . . 106
Tools for the Administrative and Management
Server . . . . . . . . . . . . . . . 107
Uninstalling . . . . . . . . . . . . . . 107
Uninstalling Tivoli Service Automation Manager
components . . . . . . . . . . . . . 107
Uninstalling Tivoli Provisioning Manager core
components . . . . . . . . . . . . . 108
Uninstalling base services other runtime
services. . . . . . . . . . . . . . . 108
Uninstalling middleware . . . . . . . . 109
Chapter 3. Configuring Tivoli Service
Automation Manager . . . . . . . . 111
Overview of the configuration process . . . . . 111
Planning your configuration . . . . . . . . 112
Planning the hypervisor configuration . . . . 113
New capabilities of VMware vSphere 5 . . . 114
Planning the network configuration . . . . . 116
Network templates . . . . . . . . . 116
Customer-specific network configuration . . 117
Network annotation of deployable images 118
Network configuration . . . . . . . . 118
Network configuration strategies . . . . 118
Management network structure overview 120
The multi-NIC networking model on System
p . . . . . . . . . . . . . . . 124
VIO support. . . . . . . . . . . 126
VIO Shared Ethernet Adapter
management . . . . . . . . . . 137
Virtual switch template properties for
System p . . . . . . . . . . . . 138
Planning for System p configuration. . . 140
Troubleshooting . . . . . . . . . 140
Definitions for DCM objects . . . . . . 141
Network planning for VMControl . . . . 144
Sample OVF descriptor file for AIX using
NIM . . . . . . . . . . . . . 145
Sample OVF descriptor file for AIX using
SCS . . . . . . . . . . . . . 148
Preparing the provisioning back ends . . . . . 151
iv Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Configuring the z/VM environment for Tivoli
Service Automation Manager . . . . . . . 151
Introduction to the z/VM environment . . . 151
Setting up z/VM for Linux provisioning . . 152
Modifying the z/VM System
Configuration file . . . . . . . . . 152
System DASD . . . . . . . . . . 153
z/VM network . . . . . . . . . . 153
Modifying system features . . . . . . 154
Updating the z/VM TCP/IP configuration 155
Network devices . . . . . . . . . 155
Home address and gateway . . . . . 156
Autolog statement . . . . . . . . . 156
Port statement . . . . . . . . . . 156
Defining the external IP address to the
TCP/IP stack . . . . . . . . . . 156
Setting up 'Directory Maintenance Facility for
z/VM (DirMaint) . . . . . . . . . . 157
Configuring the CONFIGxx DATADVH
file . . . . . . . . . . . . . . 157
Allocation groups . . . . . . . . . 158
Creating the MAPSRV and MAPAUTH IDs 158
Setting up Linux on System z . . . . . . 160
Defining virtual machines for Linux on
System z . . . . . . . . . . . . 160
Setting up a Linux on System z master
system . . . . . . . . . . . . 162
Verifying your configuration . . . . . 163
Using RACF with z/VM . . . . . . . 163
Permitting access to system resources . . 163
Configuring z/VM networking . . . . 164
Configuring DIRMAINT/DATAMOVE 164
Configuring VSMSERVE. . . . . . . 164
Configuring the KVM environment for Tivoli
Service Automation Manager . . . . . . . 166
Configuring the Xen environment for Tivoli
Service Automation Manager . . . . . . . 168
Preparing for an automatic Xen host install 169
Creating the Post Install Script file . . . . 170
Setting up Xen . . . . . . . . . . . 171
Configuring cloud server pools . . . . . . . 173
Configuring cloud server pools manually . . . 174
Manually configuring cloud server pools for
VMware . . . . . . . . . . . . . 174
Manually configuring cloud server pools for
KVM . . . . . . . . . . . . . . 177
Manually configuring cloud server pools for
System p . . . . . . . . . . . . . 179
Manually configuring cloud server pools for
Power Blades . . . . . . . . . . . 182
Manually configuring cloud server pools for
VMControl . . . . . . . . . . . . 185
Enhancing VMControl discovery
performance. . . . . . . . . . . 188
Enabling or Disabling NPIV Support via
VMControl . . . . . . . . . . . 188
Configuring cloud server pools for zVM . . 189
zVM cloud server pool configuration . . 189
Configuring zVM cloud server pools in
the Cloud Server Pool Administration
application . . . . . . . . . . . 190
Using Data Center Model (DCM) files to
configure cloud server pools . . . . . . . 191
Data Center Model (DCM) object templates 191
Customizing hypervisor independent Data
Center Model (DCM) items. . . . . . 193
Customizing hypervisor dependent Data
Center Model (DCM) items. . . . . . 197
Importing Data Center Model (DCM) object
templates. . . . . . . . . . . . . 202
Customizing cloud pool objects . . . . . 202
Customizing a Tivoli Service Automation
Manager cloud pool for VMware . . . . 204
Customizing a Tivoli Service Automation
Manager cloud pool for PowerVM . . . 206
Customizing a Tivoli Service Automation
Manager cloud pool for KVM . . . . . 212
Customizing a Tivoli Service Automation
Manager cloud pool for IBM Systems
Director VMControl . . . . . . . . 215
Configuring PowerVM SAN disks for VIOS
support using MPIO . . . . . . . . . . 216
Planning for SAN storage . . . . . . . 216
Enabling VIOS support . . . . . . . . 217
Configuring cloud networks . . . . . . . . 217
Setting up the network related Data Center
Model (DCM) objects. . . . . . . . . . 218
Defining network segment usage values . . . 219
Network segment usage values . . . . . 219
Relating an image to a hypervisor-specific
network configuration . . . . . . . . 220
Defining a specific network configuration for
a class of images . . . . . . . . . . 220
Distinguishing between network interfaces of
the same type . . . . . . . . . . . 220
Creating a network template . . . . . . . 221
Creating a network template using the Cloud
Network Administration application. . . . . 222
Creating a customer and assigning a network
template . . . . . . . . . . . . . . 223
Configuring distributed virtual switches . . . 223
Enabling IPv6 addressing support . . . . . 225
IPv6 addressing support. . . . . . . . 225
Enabling customer network for IPv6 auto
configuration . . . . . . . . . . . 227
Enabling IPv6 for the provisioning images 227
Enabling the IPv6 support on the
management server . . . . . . . . . 228
Disabling the IPv6 support on the
management server . . . . . . . . . 228
IP address selection rules . . . . . . . 229
Defining an IP address selection rule . . . 230
IPv6 properties and their layout . . . . . 230
Turning on VIO Shared Ethernet Adapter
management . . . . . . . . . . . . 231
Turning off VIO Shared Ethernet Adapter
management . . . . . . . . . . . . 232
Configuring cloud storage pools . . . . . . . 232
Configuring cloud storage resources. . . . . 234
Setting up purging options for storage disks on
System p . . . . . . . . . . . . . . 235
Purging LPARs . . . . . . . . . . . . 236
Contents v
Changing the default purging configuration . . 237
Saving and restoring projects with storage
resources . . . . . . . . . . . . . . 238
Configuring VMware additional disk feature . . . 238
Configuring cloud storage pools . . . . . . 238
Support for single datastore . . . . . . . 240
Support for Storage vMotion . . . . . . . 240
Configuring the service provider and customer
features . . . . . . . . . . . . . . . 241
Assigning resources to the default customer . . 241
Activating the default customer PMRDPCUST 242
Configuring the interface to Workload Deployer 243
Configuring the managed environment to use the
WebSphere Cluster Service . . . . . . . . . 244
Configuring the DCM to use the WebSphere
Cluster Service . . . . . . . . . . . . 245
Configuring and running discovery on a Tivoli
Provisioning Manager server . . . . . . . 247
Defining configuration items for the WebSphere
Cluster Service . . . . . . . . . . . . 248
Processor Pool planning . . . . . . . . . . 249
Processor pool configuration in the backend . . 250
Processor Pool configuration in the Cloud
Server Pool Administration Application . . . 250
Service request parameters for processor pool
support . . . . . . . . . . . . . . 250
Advanced configuration settings . . . . . . . 251
Reducing the run time of provisioning requests 251
Overcommitting resources on VMware
hypervisor . . . . . . . . . . . . . 252
Overcommitting CPU . . . . . . . . 252
Overcommitting memory . . . . . . . 253
Overcommitting storage . . . . . . . . 254
VMware storage resiliency . . . . . . 255
Integrating Tivoli Service Automation Manager
with other Tivoli products . . . . . . . . . 255
Integrating Tivoli Monitoring . . . . . . . 255
Configuring the provisioning of the
monitoring agent . . . . . . . . . . 256
Preparing the monitoring agent installable 256
Defining the Tivoli Monitoring agent
software definition in Tivoli Provisioning
Manager . . . . . . . . . . . . 257
Enabling the monitoring agent installation
on restored images . . . . . . . . 261
Synchronizing data between Tivoli
Monitoring and Tivoli Service Automation
Manager . . . . . . . . . . . . 261
Configuring monitoring for the WebSphere
Cluster service . . . . . . . . . . . 263
Setting up predefined Tivoli Service
Automation Manager events for
monitoring . . . . . . . . . . . 263
Enabling the SSH command end point to
retrieve IBM Tivoli Monitoring
configuration information . . . . . . 264
Triggering the Tivoli Service Automation
Manager event monitoring application . . 265
Integrating Tivoli Usage and Accounting
Manager . . . . . . . . . . . . . . 266
CSR files . . . . . . . . . . . . . 266
Configuring Tivoli Service Automation
Manager for Tivoli Usage and Accounting
Manager . . . . . . . . . . . . . 267
Configuring for RXA connections between
Tivoli Service Automation Manager and
Tivoli Usage and Accounting Manager . . 268
Enabling table auditing for Tivoli Usage
and Accounting Manager data collection . 268
Enabling CSR file generation . . . . . 269
Defining the directory for CSR file
generation . . . . . . . . . . . 269
Enabling logs for metering . . . . . . 270
Configuring Tivoli Usage and Accounting
Manager to process CSR files . . . . . . 270
Configuring the Tivoli Usage and
Accounting Manager job file to retrieve
CSR files from Tivoli Service Automation
Manager . . . . . . . . . . . . 271
Configuring the Tivoli Usage and
Accounting Manager job file to process
CSR files from Tivoli Service Automation
Manager . . . . . . . . . . . . 272
Metering for additional disks . . . . . . 276
Metering for additional disks that are
created during earlier versions of Tivoli
Service Automation Manager . . . . . 276
Integrating with Tivoli Change and
Configuration Management Database (CCMDB) . 276
Configuration artifacts for integrating with
Tivoli Change and Configuration
Management Database . . . . . . . . 277
Configuring workflow integration . . . . 278
Configuring a Service Request Manager
offering for processing . . . . . . . . 279
Extensions to the Change Management
application . . . . . . . . . . . . 280
Tivoli Change and Configuration
Management Database Configuration Items . 281
The CreateOrUpdateAuthorizedCI
operation. . . . . . . . . . . . 281
The LinkAuthorizedCI operation . . . . 283
The UnlinkAuthorizedCI operation . . . 283
Deriving an operation specific to a
configuration item. . . . . . . . . 284
Using the configuration item operations 284
Configuring security against XSS . . . . . . 285
Chapter 4. Administering Tivoli
Service Automation Manager. . . . . 287
Logging on to the Tivoli Service Automation
Manager administrative interface . . . . . . . 287
Working with the service automation reports . . . 287
Configuring the reporting function . . . . . 288
Generating request pages . . . . . . . 288
Enabling table auditing . . . . . . . . 288
Authorizing users to access reports . . . . 289
Generating, viewing, and scheduling reports 290
Working with usage and accounting reports . . . 291
Project account and the account code structure 291
Generating Tivoli Usage and Accounting
Manager reports . . . . . . . . . . . 292
vi Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Managing cloud networks . . . . . . . . . 292
Network template management . . . . . . 293
Importing network related artifacts . . . . 293
Creating a network template . . . . . . 294
Viewing network segments . . . . . . . 295
Adding a network segment. . . . . . . 295
Deleting a network segment . . . . . . 296
Viewing subnetworks . . . . . . . . 296
Adding a subnetwork . . . . . . . . 296
Deleting a subnetwork . . . . . . . . 297
Viewing virtual switch templates . . . . . 297
Adding a virtual switch template. . . . . 298
Deleting a virtual switch template . . . . 298
Changing the status of a network template 299
Network configuration instance management 299
Viewing network configuration instances . . 300
Importing a customer network configuration
instance . . . . . . . . . . . . . 301
Exporting a customer network configuration
instance . . . . . . . . . . . . . 301
Viewing project network configuration
instances . . . . . . . . . . . . . 301
Importing project network configuration
instance . . . . . . . . . . . . . 302
Exporting a project network configuration
instance . . . . . . . . . . . . . 302
Viewing customers . . . . . . . . . . 303
Configuring overlapping subnetwork . . . . 303
Validating DCM subnetwork for overlapping
IP . . . . . . . . . . . . . . . 303
Managing virtual server resources . . . . . . 304
Increasing the maximum memory settings for
System p . . . . . . . . . . . . . . 304
Moving servers to another host for System p
cloud server pools. . . . . . . . . . . 305
Creating an administrative role for VMware
users . . . . . . . . . . . . . . . 305
Assigning provisioning workflows for VMware
additional disk feature . . . . . . . . . 306
Assigning provisioning workflow to an ESX
server . . . . . . . . . . . . . . 306
Assigning provisioning workflows to
multiple ESX servers . . . . . . . . . 307
Managing server images. . . . . . . . . . 307
Creating operating system image templates . . 307
Creating operating system image templates
for KVM . . . . . . . . . . . . . 307
Preparing a Windows image . . . . . 308
Preparing a Linux image . . . . . . 309
Creating operating system image templates
for VMware . . . . . . . . . . . . 312
Preparing a Windows image . . . . . 312
Preparing a Linux image . . . . . . 318
Creating operating system image templates
for PowerVM . . . . . . . . . . . 324
Preparing an AIX image . . . . . . . 324
Discovering single virtual server image
templates. . . . . . . . . . . . . . 324
Preparing OS image templates for Tivoli Service
Automation Manager. . . . . . . . . . 325
Adding a new image from VMControl . . . . 326
Migrating a VMControl image from 2.3 level
to 2.4.1 or 2.4.2 level . . . . . . . . . 326
Deleting a server image . . . . . . . . . 327
Storing server images . . . . . . . . . 327
Registering single master images to different
VMware clusters and server resource pools . . 327
Multiplying VMware template metadata . . . 328
Enabling the restore across project offerings . . 329
Controlling user access . . . . . . . . . . 330
Security in the administrative user interface . . 330
Security management in the self-service user
interface . . . . . . . . . . . . . . 333
Security groups in the self-service user
interface . . . . . . . . . . . . . 334
Data segregation for service providers . . . . 336
Administering customers and their resources . . . 338
Assigning resources to a customer . . . . . 338
Assigning resources to all customers . . . 340
Returning customer resources . . . . . . . 340
Creating customer templates . . . . . . . 341
Defining quotas and limits . . . . . . . . 342
Activating and deactivating quotas and limits 343
Managing the maintenance mode. . . . . . . 344
Maintenance log . . . . . . . . . . . 344
Maintenance log attributes . . . . . . . 344
Maintenance mode statuses. . . . . . . . 345
Activating the maintenance mode . . . . . 346
Deactivating the maintenance mode . . . . . 346
Forcing the maintenance mode . . . . . . 347
Maintenance mode extensibility . . . . . . 347
Managing request approval, delegation, and
notification . . . . . . . . . . . . . . 348
Communication templates for email notification 348
Managing communication templates. . . . 350
Enabling or disabling automatic approval of
requests . . . . . . . . . . . . . . 350
Enabling or disabling delegation of approval
requests . . . . . . . . . . . . . . 351
Adding new software modules . . . . . . . 352
Starting and stopping the middleware . . . . . 353
Starting the management server . . . . . . 353
Stopping the management server . . . . . . 354
Controlling the middleware with a script . . . 355
Backing up the database. . . . . . . . . . 357
Changing default passwords for Tivoli Service
Automation Manager. . . . . . . . . . . 358
Change the passwords for IBM Tivoli Directory
Server . . . . . . . . . . . . . . . 358
Change the idsccmdb user password . . . 358
Change idsccmdb password in Tivoli
Directory Server . . . . . . . . . . 358
Changing the passwords for Tivoli Provisioning
Manager user IDs . . . . . . . . . . . 359
Change password for wasadmin . . . . . 360
Change wasadmin password in Tivoli
Directory Server . . . . . . . . . . 360
Verify Tivoli Provisioning Manager and
WebSphere . . . . . . . . . . . . 361
Change the maxadmin user password . . . 361
Change the Maximo user password . . . . 362
Change maximo.properties . . . . . . . 363
Contents vii
Update properties.jar . . . . . . . . . 365
Verify password change . . . . . . . . 366
Change OS user ID passwords . . . . . 367
Change the cloud administrator
(PMRDPCAUSR) password. . . . . . . . 367
Updating Tivoli Provisioning Manager certificate in
the Java truststore . . . . . . . . . . . . 368
Using virtual servers for SAP landscapes . . . . 369
Using the Admin Mode . . . . . . . . . . 372
Chapter 5. Reliability, availability, and
serviceability functions . . . . . . . 373
REST API reference for RAS . . . . . . . . 374
Delete DCM virtual servers on given host
platform . . . . . . . . . . . . . . 374
List virtual servers on given host platform . . 375
List virtual servers on given host platform and
in DCM . . . . . . . . . . . . . . 376
Force cleanup of service deployment instance 377
List service deployment instance backend
resources . . . . . . . . . . . . . . 378
List service deployment instance data model
inconsistencies . . . . . . . . . . . . 381
Validation checks . . . . . . . . . . 382
TOPO_VS_DCM validation checks . . . . . 383
TOPO_VS_BC validation checks . . . . . 383
BC_VS_DCM validation checks . . . . . 384
Provide service request current status . . . . 385
Force cleanup of service deployment instance
and back end . . . . . . . . . . . . 385
BIRT reports. . . . . . . . . . . . . . 387
Virtual server synchronization report . . . . . 388
Service deployment instance inconsistencies report 388
Ticket related objects report . . . . . . . . 389
Best practices for using reliability, availability, and
serviceability functions . . . . . . . . . . 390
Rolling back the resource workflow
modification process . . . . . . . . . . 390
Removing a host platform . . . . . . . . 391
Tracking VM Provisioning request by DCM
objects. . . . . . . . . . . . . . . 391
Checking the service request status . . . . . 391
Unlocking hanging requests . . . . . . . 392
Insufficient resources on the Tivoli Service
Automation Manager self-service user interface . 392
Removing phantom servers. . . . . . . 392
Freeing resources locked to deprecated or
inconsistent projects . . . . . . . . . 393
Chapter 6. REST API reference . . . . 395
Structure of the REST URLs used for the 'query'
request . . . . . . . . . . . . . . . 395
Tivoli Process Automation engine base object
queries . . . . . . . . . . . . . . . 397
Get domain definitions (MAXDOMAIN) . . . 397
Get list of installed and enabled languages
(LANGUAGE) . . . . . . . . . . . . 399
Get list of person groups (PERSONGROUP) . . 400
Get person group details (PERSONGROUPDET) 400
Get list of users (MAXUSER) . . . . . . . 401
Get list of user details (MAXUSERDET) . . . 402
Get list of security groups (MAXGROUP) . . . 404
Get security group users (GROUPUSER) . . . 405
Get Images (IMGLIB). . . . . . . . . . 406
Get system property values (MAXPROPVALUE) 407
Tivoli Service Automation Manager based or
modified object queries . . . . . . . . . . 408
Get project-related data
(PMZHBR1_PMRDPPRJVIEW) . . . . . . 408
Get server-related data
(PMZHBR1_PMRDPSRVVIEW) . . . . . . 411
Get storage-related data
(PMZHBR1_PMRDPSTGVIEW) . . . . . . 412
Get the current defined offerings
(PMRDPOFFVIEW) . . . . . . . . . . 414
Get person to group mapping
(PERSONGROUPTEAM) . . . . . . . . 415
(DEPRECATED) Get person to group mapping
details (PERSGRPTMDET) . . . . . . . . 416
Get person groups with person not yet in team
(PMZHBR1_PERSNTINTEAM) . . . . . . 417
Information to calculate user request frequency
(PMZHBR1_FREQUENTREQ) . . . . . . . 418
Network configuration API . . . . . . . . 418
Get network template . . . . . . . . 419
Get matching network segments . . . . . 420
Get network segments matching the
customer configuration . . . . . . . 420
Get network segments matching the
project configuration . . . . . . . . 421
Constructor for the network API client . . . 422
The Get Network configuration method . . . 423
The Set Network configuration method . . . 423
Network schema . . . . . . . . . . 424
Complex type NetworkConfiguration . . 424
Complex type DNS . . . . . . . . 425
Complex type Gateway . . . . . . . 426
Complex type NetworkSegment . . . . 427
Complex type Reference. . . . . . . 430
Complex type Route . . . . . . . . 430
Complex type Routes. . . . . . . . 431
Complex type Subnet. . . . . . . . 431
Complex type VlanId. . . . . . . . 432
Complex type VrfId . . . . . . . . 433
Simple type Type . . . . . . . . . 433
Simple type Version . . . . . . . . 434
JAXB access classes . . . . . . . . . 434
The ANY attributes available in the schema 435
Tivoli Service Request Manager based object
queries . . . . . . . . . . . . . . . 436
Get list of service requests (SR) . . . . . . 436
Get service request details (SRDET) . . . . . 438
Get shopping cart (CART) . . . . . . . . 439
Get user details (MAXUSERDET). . . . . . 440
Get offering information (OFFERING) . . . . 442
Get offering details (OFFERINGDET) . . . . 443
Create service request (SRCREATE) . . . . . 444
Create a shopping cart (CARDCREATE) . . . 447
Create interfaces via REST . . . . . . . . . 448
REST POST-style requests - 'create', 'update',
and 'delete' . . . . . . . . . . . . . 448
viii Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Create catalog requests (PMSCCR) . . . . . 449
Interfaces via Web services (PMRDPBCAPI) . . . 464
pmrdpbcapigetAvailableCapacityData Method 465
pmrdpbcapigetAvailablePoolList Method . . . 467
pmrdpbcapigetAvailableCapacityForPools
Method . . . . . . . . . . . . . . 469
pmrdpbcapigetBCRealSysResMonitoringData
Method . . . . . . . . . . . . . . 470
pmrdpbcapiReassignWfAssignment Method . . 472
pmrdpbcapiChangeWfAssignment Method . . 473
Additional relationships . . . . . . . . . . 473
GETDOMAIN Relationship. . . . . . . . 474
PMZHB_SRSPECCLASS Relationship . . . . 474
Additional filter domains . . . . . . . . . 474
(DEPRECATED) PMZHBT_CLUSERROLE Filter
Domain . . . . . . . . . . . . . . 474
PMZHBT_CLOUDUSER Filter Domain. . . . 475
(DEPRECATED) PMZHBT_CLUSERROLE Filter
Domain . . . . . . . . . . . . . . 475
PMZHBT_LOGGEDONUSR Filter Domain . . 475
PMZHBT_MODCLUSER Filter Domain . . . 476
PMZHBT_REASSIGNLST Filter Domain . . . 477
PMZHBT_SRAPPRLIST Filter Domain . . . . 477
PMZHBT_SRUSRLIST Filter Domain . . . . 478
PMZHBT_SRVPRJLUSER Filter Domain . . . 479
PMZHBT_USERSTEAM Filter Domain . . . . 479
PMZHBT_USERTEAMS Filter Domain . . . . 480
(DEPRECATED) PMZHBT_USRROLELIST Filter
Domain . . . . . . . . . . . . . . 480
PMZHBT_IMGNOSRV Filter Domain . . . . 481
PMZHBT_SWMODULE Filter Domain . . . . 481
PMZHBT_ILMSTRIMG Filter Domain . . . . 482
REST API troubleshooting . . . . . . . . . 482
Common omissions and user errors . . . . . 482
Debugging REST requests with loggers. . . . 483
Chapter 7. Troubleshooting and error
recovery . . . . . . . . . . . . . 485
Trace logging . . . . . . . . . . . . . 485
Common problems and solutions. . . . . . . 486
Defining Cloud.WINDOWS_ADMIN_USER . . . 488
Troubleshooting image registration . . . . . . 488
Troubleshooting installation problems . . . . . 489
Unable to log on to the administrative user
interface after Tivoli Provisioning Manager
installation . . . . . . . . . . . . . 489
Service Request Manager fix pack installation
terminates with error . . . . . . . . . . 490
Release Process Manager installation fails . . . 490
OutOfMemoryError when installing automation
packages . . . . . . . . . . . . . . 491
The TPMfOSd_VersionDiscovery workflow fails
during the Configure Cloud Management
Components post-installation step . . . . . 491
Mail check enabled for tioadmin user is causing
issues during Tivoli Service Automation
Manager installation . . . . . . . . . . 492
SOAP exception error while running
startApplication.py . . . . . . . . . . 492
Errors in the configuration of cloud
management component . . . . . . . . 493
Missing display of tags during installation . . 493
Troubleshooting upgrade and migration . . . . 493
Creating a project from a saved image fails . . 493
Upgrade fails with
VMWare_MigrateDCM_7_3_0_0 workflow errors 493
UpdateDB fails with error messages . . . . . 494
Modifying Cloud Server Pool fails . . . . . 495
Problems in upgrading Tivoli Service
Automation Manager 7.2.2.1 . . . . . . . 495
Provisioning problems . . . . . . . . . . 495
Investigating provisioning failures . . . . . 495
Cleaning up after a provisioning failure . . . 497
Provisioning fails on System p. . . . . . . 497
Virtual server on System p is not created . . . 498
Recovering data model from System p Live
Partition Mobility . . . . . . . . . . . 498
Additional software not available on AIX . . . 499
DB2 installation on Windows fails . . . . . 500
Provisioning fails with HWADDR line in
/etc/sysconfig/network-scripts/ifcfg-eth0. . . 500
Provisioning a VMware project with increased
memory size fails . . . . . . . . . . . 501
Provisioning VMware fails with timeout error 501
Provisioning fails when using Xen image . . . 502
Provisioning fails because of wrong
configuration of default gateways . . . . . 502
Excluding ESX server that is under maintenance
in VMWare . . . . . . . . . . . . . 503
Available resources are not listed properly. . . 503
Modifying disk size fails on Red Hat Enterprise
Linux server. . . . . . . . . . . . . 503
Resources not updated when creating a project 504
Resource pool is not available . . . . . . . 504
Setting automatic logon for Windows . . . . 504
Setting a specific timezone on a Windows
endpoint . . . . . . . . . . . . . . 505
Allowing automatic replacement of existing
servers . . . . . . . . . . . . . . 506
Cleaning up after unexpected stoppage of the
Provisioning Manager engines. . . . . . . . 506
The integrity checker tool functions . . . . . . 506
Manually changing the status of a service request 507
Troubleshooting when using IBM Systems Director
VMControl . . . . . . . . . . . . . . 507
Creating an image template for VMControl fails 507
VMC_FormatFileSystem workflow failure . . . 507
Deployment of more than 10 servers fails . . . 508
Removing hardware resources via VMControl 508
Recovering after unexpected hardware removal
or failure . . . . . . . . . . . . . . 509
Removing an orphan virtual server . . . . . 509
Server cannot be removed in the self-service
interface . . . . . . . . . . . . . 510
Correct physical CPU information is not
reflected on HMC . . . . . . . . . . . 510
Fixing Image Validation Errors . . . . . . 510
Deployment of a virtual appliance with
dedicated cpu or memory values in the OVF
fails . . . . . . . . . . . . . . . 511
VMControl certificate host name does not match 512
Contents ix
Troubleshooting errors in VMControl NPIV
project with additional disk . . . . . . . 513
Troubleshooting when using VMware . . . . . 513
Troubleshooting VMware additional disk feature 514
"Invalid Binding" displayed for data store
names . . . . . . . . . . . . . . . 514
Using the same data store for a server pool and
a storage pool . . . . . . . . . . . . 515
Additional disks for scheduled future projects 515
Error messages . . . . . . . . . . . . 515
VMware Additional Disks fails in non-US . . . 516
VirtualCenter discovery does not load the servers 516
CDSException messages issued for inactive CDS
application . . . . . . . . . . . . . . 517
Configuring extensibility for Workload Deployer
fails . . . . . . . . . . . . . . . . 517
Errors in http_plugin.log files . . . . . . . . 518
Extending an offering fails . . . . . . . . . 519
Troubleshooting additional disk extension for
Power LPAR . . . . . . . . . . . . . 519
Deleting saved images after the owning customer
was deleted . . . . . . . . . . . . . . 520
Errors in the Simple SRM UI display . . . . . 521
Guest OS customization of Windows 8 and
Windows Server 2012 does not complete . . . . 521
Appendix. Accessibility features . . . 523
Notices . . . . . . . . . . . . . . 525
Glossary . . . . . . . . . . . . . 527
A . . . . . . . . . . . . . . . . . 527
C . . . . . . . . . . . . . . . . . 528
E . . . . . . . . . . . . . . . . . 528
H . . . . . . . . . . . . . . . . . 528
J. . . . . . . . . . . . . . . . . . 528
M . . . . . . . . . . . . . . . . . 529
P . . . . . . . . . . . . . . . . . 529
R . . . . . . . . . . . . . . . . . 530
S . . . . . . . . . . . . . . . . . 530
T . . . . . . . . . . . . . . . . . 531
V . . . . . . . . . . . . . . . . . 531
W . . . . . . . . . . . . . . . . . 531
X . . . . . . . . . . . . . . . . . 532
Trademarks and Service Marks. . . . 533
Index . . . . . . . . . . . . . . . 535
Privacy policy considerations . . . . 539
x Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Tables
1. Documentation links for Tivoli Service
Automation Manager component products . . xiii
2. Uniqueness scopes for topology node
attributes . . . . . . . . . . . . . 14
3. Uniqueness specifications for attribute names 15
4. Uniqueness resolution rule . . . . . . . 15
5. Summary of Tivoli Service Automation
Manager Reports and Content . . . . . . 20
6. Management server hardware and operating
system requirements . . . . . . . . . 29
7. Minimum free space requirements for the
management system (AIX) . . . . . . . 30
8. Minimum free space requirements for the
management system (Linux) . . . . . . . 30
9. Administrative server requirements . . . . 31
10. Managed-environment server requirements 32
11. Summary of software in the Tivoli Service
Automation Manager environment . . . . . 36
12. Installation steps and servers on which the
corresponding installation files must be
available . . . . . . . . . . . . . 43
13. Installation scenarios . . . . . . . . . 45
14. Required packages for Linux management
servers . . . . . . . . . . . . . . 64
15. Default and your values for properties . . . 69
16. NIM vs SCS differences . . . . . . . . 144
17. The KVM server and KVM image server
settings worksheet . . . . . . . . . . 168
18. The Management Subnetwork customization: 193
19. The Customer Subnetwork customization: 194
20. . . . . . . . . . . . . . . . . 195
21. The 11_Cloud_NetworkSettings_VMware.xml
file customization . . . . . . . . . . 197
22. Systemp_SwitchTemplate customization 198
23. The 13_Cloud_NetworkSettings_zVM.xml file
customization . . . . . . . . . . . 199
24. The 23_1_Cloud_zLinuxImage_SLES10_zVM.xml
file customization . . . . . . . . . . 199
25. The 23_2_Cloud_Vswitches_zVM.xml file
customization . . . . . . . . . . . 200
26. System z Pool customization . . . . . . 200
27. Customization of the mapserve server section
in the System z Pool object . . . . . . . 201
28. The 14_Cloud_NetworkSettings_KVM.xml file
customization: . . . . . . . . . . . 202
29. Customization of the VIOS settings for the
discovered DCM objects and the System p
VIOS configuration for the CEC server objects 210
30. Sample Data Center Model import files. 218
31. Sample network templates and network
template schema. . . . . . . . . . . 221
32. Classification attributes for configuration
items to be used by the WebSphere Cluster
Service. . . . . . . . . . . . . . 248
33. Account code structure . . . . . . . . 273
34. Account code structure . . . . . . . . 291
35. The minimum rights of a VMware
administrative user . . . . . . . . . 306
36. . . . . . . . . . . . . . . . . 318
37. Roles and groups provided by Tivoli Service
Automation Manager . . . . . . . . . 331
38. Access to requests depending on the security
group . . . . . . . . . . . . . . 335
39. Types of quotas and limits . . . . . . . 342
40. Maintenance log attributes . . . . . . . 344
41. Escalations deactivated during the
maintenance mode. . . . . . . . . . 345
42. Tivoli Service Automation Manager
communication templates . . . . . . . 348
43. Roles for email notifications. . . . . . . 349
44. Management section of the input parameter
file . . . . . . . . . . . . . . . 370
45. Instance profile section of the input
parameter file . . . . . . . . . . . 371
46. ERROR_CODE values . . . . . . . . 382
47. ERROR_TYPE values . . . . . . . . . 382
48. Object structure definition for
MBS_MAXDOMAIN . . . . . . . . . 398
49. Object structure definition for
MBS_LANGUAGE. . . . . . . . . . 399
50. Object structure definition for
MBS_PERSONGROUP . . . . . . . . 400
51. Object structure definition for
MBS_PERSONGROUPDET . . . . . . . 401
52. Object structure definition for
MBS_MAXUSER . . . . . . . . . . 402
53. Object structure definition for
MBS_MAXUSERDET . . . . . . . . . 402
54. Object structure definition for
MBS_MAXGROUP. . . . . . . . . . 404
55. Object structure definition for
MBS_GROUPUSER . . . . . . . . . 405
56. Object structure definition for MBS_IMGLIB 406
57. Object structure definition for MBS_
MAXPROPVALUE . . . . . . . . . . 407
58. Object structure definition for
PMZHBR1_PMRDPPRJVIEW . . . . . . 409
59. Object structure definition for
PMZHBR1_PMRDPSRVVIEW . . . . . . 411
60. Object structure definition for
PMZHBR1_PMRDPSTGVIEW . . . . . . 413
61. Object structure definition for
PMZHBR1_PMRDPOFFVIEW . . . . . . 414
62. Object structure definition for
PMZHBR1_PERSGRPTM . . . . . . . 415
63. Object structure definition for
PMZHBR1_PERSGRPTMDET . . . . . . 416
64. Object structure definition for
PMZHBR1_PERSNTINTEAM . . . . . . 417
65. Object structure definition for
PMZHBR1_PERSNTINTEAM . . . . . . 418
66. Object structure definition for SRM_SR 437
Copyright IBM Corp. 2008, 2012 xi
67. Object structure definition for SRM_SRDET 438
68. Object structure definition for SRM_CART 439
69. Object structure definition for
SRM_MAXUSERDET . . . . . . . . . 440
70. Object structure definition for
SRM_OFFERING . . . . . . . . . . 442
71. Object structure definition for
SRM_OFFERINGDET . . . . . . . . . 443
72. Object structure definition for
SRM_SRCREATE . . . . . . . . . . 444
73. Object structure definition for
SRM_CARDCREATE . . . . . . . . . 447
74. Problems and solutions for common problems 486
75. Timezones and their numeric values . . . . 505
xii Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Preface
This publication documents how to install and administer Tivoli
Service
Automation Manager.
Who should read this information
This information is intended for:
v System and database administrators who are responsible for implementing Tivoli
Service Automation Manager or IBM
CloudBurst
v Service managers responsible for defining specific service offerings based on the
service definitions supplied with Tivoli Service Automation Manager
v Service instance managers and technicians responsible for monitoring and
administering existing IT landscapes represented by service instances
v Service operators responsible for operations management of landscapes that are
deployed or in the process of being deployed
What's new in this release
This release of Tivoli Service Automation Manager offers a set of new features and
enhancements to the existing functions.
v Overlapping IP Address environment for VMControl Hypervisor
v Quotas in VMControl
v Virtual machine cloning for additional disk
v Folders in VMware
v Save / Restore images with additional disk (Vmware)
v Metering for additional disk (VMware)
v NPIV support for VMControl 2.4.2 and 2.4.3.1
v Performance improvement and display for Resource KPI
Useful links
Tivoli Service Automation Manager is a component product. Use the following
topic to find more information about the related products and the requirements
that must be met for them.
Table 1. Documentation links for Tivoli Service Automation Manager component products
Product name Documentation URL
IBM Tivoli Provisioning Manager, version
7.2.1
http://pic.dhe.ibm.com/infocenter/tivihelp/
v45r1/topic/com.ibm.tivoli.tpm.doc/
welcome/ic-homepage.html
IBM Tivoli Service Request Manager, version
7.2.0.1
http://publib.boulder.ibm.com/infocenter/
tivihelp/v32r1/index.jsp?topic=
%2Fcom.ibm.srm.doc%2Fsrm_welcome.htm
Maximo
Application Server
Network Deployment, version 6.1
http://publib.boulder.ibm.com/infocenter/
wasinfo/v6r1/topic/
com.ibm.websphere.base.doc/info/aes/ae/
welcome_base61.html
IBM Systems Director VMControl
version
2.3.1, 2.4.1.1, 2.4.2, 2.4.3.1
http://publib.boulder.ibm.com/infocenter/
director/v6r2x/index.jsp?topic=/
com.ibm.director.vim.helps.doc/
fsd0_vim_main.html
Support information
You can find support information for IBM products from a variety of sources.
v Getting technical training
v Searching knowledge bases
v Contacting IBM Software Support on page xvi
Getting technical training
Information about Tivoli technical training courses is available online.
Go to http://www.ibm.com/software/tivoli/education/.
Searching knowledge bases
If you have a problem with Tivoli Service Automation Manager, search through
one of the many available knowledge bases.
You can begin with the IT Service Management Knowledge Center.
Searching the Internet
If you cannot find an answer to your question in the IT Service Management
information center, search the Internet for the latest, most complete information to
help you resolve your problem.
To search multiple Internet resources, go to the IBM Tivoli Support website. From
there, you can search a number of resources, including:
v IBM technotes
v IBM downloads
v IBM Redbooks
If you still cannot find a solution to the problem, you can search forums and
newsgroups on the Internet for the latest information to help you resolve it.
xiv Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Using IBM Support Assistant
At no additional cost, you can install on any workstation the IBM Support
Assistant, a stand-alone application. You can then enhance the application by
installing product-specific plug-in modules for the IBM products that you use.
The IBM Support Assistant helps you gather support information when you need
to open a problem management record (PMR), which you can then use to track the
problem. The product-specific plug-in modules provide you with the following
resources:
v Support links
v Education links
v Ability to submit problem management reports
For more information, see the IBM Support Assistant Web site at
http://www-01.ibm.com/software/support/isa/.
Finding product fixes
A product fix might be available from the IBM Software Support website.
About this task
Check the website to determine which fixes are available for your product.
Procedure
1. Find the Tivoli Service Automation Manager product at http://www.ibm.com/
software/tivoli/products/.
2. Click the Support Pages link for the product.
3. Click Fixes for a list of fixes for your product.
4. Click the name of a fix to read the description and download the fix.
Getting email notification of product fixes
You can get notifications about fixes and other news about IBM products.
Procedure
1. From the support page for any IBM product, click My support in the
upper-right corner of the page.
2. Optional: If you have not registered, click Register in the upper-right corner of
the support page to set up your user ID and password.
3. Sign in to My support.
4. On the My support page, click Edit profiles in the left navigation pane, and
scroll to Select Mail Preferences. Select a product family and check the
appropriate boxes for the type of information you want.
5. Click Submit.
6. For email notification for other products, repeat steps 4 and 5.
Preface xv
Contacting IBM Software Support
You can contact IBM Software Support if you have an active IBM software
maintenance contract and if you are authorized to submit problems to IBM.
About this task
Before you contact IBM Software Support, follow these steps:
Procedure
1. Set up a software maintenance contract.
2. Determine the business impact of your problem.
3. Describe your problem and gather background information.
What to do next
Then see Submit the problem to IBM Software Support on page xvii for
information on contacting IBM Software Support.
Setting up a software maintenance contract
To be able to submit a problem to IBM, you need to have a software maintenance
contract. The type of contract that you need depends on the type of product you
have.
Procedure
v For IBM distributed software products (including, but not limited to, Tivoli,
Lotus
, and Rational
:
Enrolling online: Go to the Passport Advantage Web page at
http://www.ibm.com/software/lotus/passportadvantage/, click How to
enroll, and follow the instructions.
Enrolling by Telephone: For the telephone number for your country, go to
the IBM Software Support Handbook webpage at http://
www14.software.ibm.com/webapp/set2/sas/f/handbook/contacts.html and
click Contacts.
v For IBM eServer
, and Linux
(System x
and System z
, or
System z. The product also supports the IBM CloudBurst and IBM Workload
Deployer products, which are based on System x hardware. The self-service
environment is supported by the self-service user interface. The Self-Service Virtual
Server Management functional addresses a long-standing need for efficient
management of self-service deployment of virtual servers and associated software.
Using a set of simple, point-and-click tools, the user can select a software stack and
have the software automatically installed or uninstalled in a virtual host that is
automatically provisioned.
These tools integrate with Tivoli Service Request Manager
to provide a
self-service portal for reserving, provisioning, recycling, and modifying virtual
servers, and working with server images, in the following platform environments,
which are a part of a virtualized non-production lab (VNPL):
v VMware on System x (also used in the IBM CloudBurst and IBM Workload
Deployer products)
v Xen on System x
v KVM on System x
v LPARs on Power Systems
v z/VM
guests on System z
v WebSphere CloudBurst Appliance
This function ensures the integrity of fulfillment operations that involve a wide
range of resource actions:
v Creating virtual servers as part of a new deployment project or adding virtual
servers to an existing project, with optional scheduling for implementation at
some future time
v For each virtual server created, installing a software image that includes an
operating system and other applications that are associated with the image.
v Installing additional software on the provisioned virtual machines
v Deleting a virtual server when it is no longer needed, freeing up resources for
other servers
v Saving virtual server images and restoring the servers to their previous state
v Saving and restoring images of servers within the project.
2 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Deleting individual servers.
v Canceling a project and deleting all of the associated virtual servers.
v Starting, stopping, and restarting virtual servers.
v Resetting the administrator password on a virtual server.
v Adding, removing, and modifying users and user teams.
You use these capabilities to achieve incremental value by adopting a self-service
virtual server provisioning process, growing and adapting the process at your own
pace, and adding task automation to further reduce labor costs around defined
provisioning needs.
Before users in the data center can create and provision virtual servers,
administrators perform a set of setup tasks, including configuring the integration,
setting up the virtualization environments managed by the various hypervisors,
and running a Tivoli Provisioning Manager discovery to find servers and images
across the data center.
After this initial setup has been completed, the administrator associates the virtual
server offerings with Tivoli Provisioning Manager virtual server templates. The
Image Library is used as the source for software images to be used in provisioning
the virtual servers.
User interfaces
Tivoli Service Automation Manager provides two options for user interaction: a
self-service user interface and an administrative user interface.
The administrative user interface is the standard interface within the Tivoli
process automation engine framework (formerly known as Maximo). It is intended
primarily for service and system administrators who perform the installation,
upgrade, configuration and administration tasks.
The self-service user interface is tailored to users of self-service offerings and
administrators. It is based on the Web 2.0 standard, which enables for the
context-sensitive and real-time display updating based on the current entry or
selection made by the user. The result is a faster access to the necessary
information without having to go through a sequence of clicks, dialogs, and
panels.
Applications in the administrative user interface
Many of the components of Tivoli Service Automation Manager are implemented
in the form of applications within the administrative user interface. This section
describes the available applications and their functions.
Note: For advanced search operations in administrative UI of Tivoli Service
Automation Manager, you cannot use check boxes for search filtering.
Chapter 1. Product overview 3
Service Definitions application
You use the Service Definitions application to create or modify a service definition
and to instantiate services based on that definition. You can also customize the
service definition delivered with Tivoli Service Automation Manager to suit your
requirements more precisely.
For services that are instantiated (that is, represented with actual hardware) based
on an approved service definition, the Service Definitions application triggers the
instantiation workflow. Self-Service Virtual Server Management, however, employs
an interactive process for instantiation that is carried out using the Service Request
Manager.
Service Deployment Instances application
You use the Service Deployment Instances application to manage existing
deployments (physical implementations) of a service.
Resource Allocation applications
You use Resource Allocation applications allow you to document and review
requirements and allocate configuration items (CIs). Resources are allocated to
fulfill document requirements or allocate configuration items.
There are two purposes for allocating resources.
v Document requirements
Users can insert requirement items to specify the requirements the CI has to
fulfill. These items are classified using the standard Tivoli process automation
engine classification mechanism, which means that the user can reuse predefined
forms.
v Allocate configuration items (CIs)
Once the requirements are set and approved, a CI has to be allocated that
matches those requirements. The user can review and change the set
requirements. Using this information, they can select a CI that matches.
Automated filtering helps the user find the appropriate CI.
The Resource Allocation applications include:
v Resource Allocation Record
v Resource Allocation for Service Deployment Instance
Monitoring Definition applications for WebSphere Cluster service
If you need to modify the service definition delivered with Tivoli Service
Automation Manager to match your requirements for performance monitoring, you
can change the monitoring definition using the set of Monitoring Definition
applications.
Note: This section pertains only to performance monitoring within the scope of
the Tivoli Service Automation Manager WebSphere Cluster service. It does not
describe displaying resource usage data collected by Tivoli Monitoring agents that
are installed on servers provisioned using the Self-Service Virtual Server
Management component.
Performance monitoring is supported in combination with IBM Tivoli Monitoring
on distributed platforms (Linux on System x, System p, and System z, and AIX).
The Monitoring Definition applications refer to the monitoring environment being
used with respect to any given service definition and service deployment instance.
4 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
IBM Tivoli Monitoring must be installed separately. It is no longer offered as an
installation option for Tivoli Service Automation Manager. Alternatively, a
separately installed Tivoli Monitoring environment can be used.
For details on setting up IBM Tivoli Monitoring, see the documentation for this
product IBM (Tivoli Monitoring and OMEGAMON XE documentation).
There are three monitoring related applications:
v Monitoring Definition
v Monitoring Definition Instantiation
v Monitoring Definition Instances
The handling of performance-related situations detected by the monitoring agents
in a deployed landscape is provided by the Situation Analysis application.
Situation Analysis application
You use the Situation Analysis application to review the context of the service
deployment instance in which a performance-related event occurred, including the
topology of the service instance, the CIs involved, and the monitoring definitions.
For an overview of the situation analysis function, see Performance monitoring
support for the WebSphere Cluster service on page 16.
Note: This information pertains only to performance monitoring within the scope
of the Tivoli Service Automation Manager WebSphere Cluster service. It is not
related to displaying resource usage data collected by Tivoli Monitoring agents
that are installed on servers provisioned using the Self-Service Virtual Server
Management component.
Cloud Server Pool Administration application
Use this application to define and configure cloud server pools after the
installation of Tivoli Service Automation Manager.
This application helps you define and configure a cloud server pool for each back
end on which you want to provision servers.
Cloud Storage Pool Administration application
Use this application to create and configure cloud storage pools.
Cloud storage pools are a flexible solution to add additional storage to your
provisioned servers. They are a collection of storage resources for additional disks
that can be assigned to a newly created image if you need more storage space than
just the boot disk.
Cloud Network Administration application
This application is used to perform cloud configurations and to manage them in a
production environment.
The Cloud Network Administration application is one of the applications that are
used during the Tivoli Service Automation Manager configuration process. Use it
after performing the configuration of the backend resources and of the storage
pool. The network configurations handled by this application include:
v Importing network Data Center Model (DCM) objects and parameters that
describe subnetworks and virtual switches
Chapter 1. Product overview 5
v Importing network templates that contain predefined network configuration
parameters
After performing these initial configurations and setting up a production
environment, Tivoli Service Automation Manager configurations change over time.
The Cloud Network Administration application helps you manage these changes
by handling the following tasks:
v Importing a new revision of a network template
v Changing the status of a network template
v Deleting a network template
v Listing network templates
v Showing details of a network template
Cloud Customer Administration application
The Cloud Customer Administration application provides the administrator with
an overview of the allocated resources of a specific customer. The application is
organized into multiple tabs. These tabs show the resources, requests, and
reservations of the selected customer. The main purpose of the Cloud Customer
Administration application is to maintain customers individually. The
administrator can also perform configuration tasks for individual customers and
access other applications that serve this purpose.
Tasks that are available within the Cloud Customer Administration application
include:
v Viewing customer-specific information (users, teams, submitted requests,
projects, saved images, reserved resources, and quotas)
v Creating and removing customer templates and customers
v Assigning resources to customers and returning resources
v Adding, deleting, activating, and deactivating quotas and limits
The application supports three types of customers:
Cloud Template (type=CT)
This type is used as a template for new customers. The cloud template is
created and modified in the administrative user interface. Then it becomes
available in the self-service interface as part of the Create Customer
request. A template customer is not operational, which means that no user
can belong to a customer of type CT.
Cloud Customer (type=CC)
This customer type can be created in the self-service user interface and
then configured or modified in the administrative user interface. If
customer templates are configured, you can use them to create new
customers of type CC. A cloud customer is operational. Users assigned to it
can request and use resources. One user can be assigned to one customer
only, and that user can never be migrated between customers. When a user
is assigned to a customer, that user can access and request resources that
are assigned to that customer.
Service Provider (type=SP)
A predefined global customer that is delivered with Tivoli Service
Automation Manager 7.2.2, with a default name PMRDPCUST. If no other
customers are defined, all users belong to this default customer. New
customers of type SP cannot be created.
6 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
The application is useful if the customer reports a problem with the cloud. The
administrative user can view and find the resources related to that customer. For
example, if the customer reports that a service request on a project failed, the
administrator can easily navigate to the list of all service requests and projects
related to this customer. From this application, the administrator can navigate to
the service request application to get further details about the specific service
request.
For specific information about the features of each tab that is available in this
application, click the ? Help button within the application.
Cloud Maintenance Administration application
Administrators use the Cloud Maintenance Administration application to start and
monitor the maintenance mode for Tivoli Service Automation Manager.
The Cloud Maintenance Administration application includes the following tabs:
List
This tab contains a list of all maintenance logs that were created in Tivoli Service
Automation Manager. The inactive logs are read-only and cannot be modified.
Maintenance Mode Log
This tab contains the details of the maintenance log.
Status This section contains the basic information about the maintenance mode. It
includes the following:
v The maintenance log ID, description, and requester name.
v The start and end time of the maintenance window that affects the users.
v Internal status that informs the administrator about the state of the
maintenance mode.
v The actual start and end date of the maintenance log, that is, the time
during which the log is active.
Log The log window that is updated with log entries when the status is active.
Details
The details section graphically shows the number of service requests in the
different statuses. It also contains separate tabs with tables that the
administrator can use to quickly view the service requests in different
states, all inbox assignments, and logged-on users.
Service Topology application
The Service Topology application is the main application for viewing and editing
service topology templates and instances. If you need to modify the service
definition delivered with Tivoli Service Automation Manager to exactly match your
requirements, you can change the service topology using this application.
The Service Topology application operates mainly on the topology and topology
node data model objects. You use it to view and edit the following:
v Name and description of a topology
v Nodes of a topology
v Basic relationships between nodes (parent-child relationships)
v Monitoring agent assignments for nodes
Chapter 1. Product overview 7
v Resource allocation records for nodes
Service Update Package application
You use this application to manage existing Service Update Packages and deploy
them on one or more Service Definitions or Service Deployment Instances.
Service Topology Node applications
You use these applications to work with topology node objects. These applications
provide more sophisticated and detailed ways for browsing and editing topology
node objects than available with the Service Topology application.
The applications in this category include:
v Service Topology Node
v Service Topology Node Operation
v Node Attribute Uniqueness Violations
v Co-Location Editor
v Topology Customization
In addition to the node viewing capabilities provided by the Service Topology
application, it is possible to change relationships between nodes. For one topology
node, you can display all related nodes (direct parent or child, or otherwise related
nodes) in a list. A child node can be selected and set as the main object for the
application in order to inspect the child node. In this way, you can walk through
and inspect complete hierarchies of topology nodes. This application also allows
you to define custom relationships (in contrast to standard parent-child
relationships) between nodes. Use this when relationships between nodes have to
be defined that cannot be modeled using standard parent-child relationships.
IT Topology Work Orders application
The IT Topology Work Orders application displays the status of an IT topology
work order. This application can be accessed either in the Work Orders tab of the
Service Deployment Instances application or when the error handling workflow
creates an assignment due to an error during processing.
An IT topology work order is used as a frame of reference during management
plan processing. It contains the state of the work order and references to the input
and output definitions for work order operation. When the management plan is
being executed, there is one work order that contains the state of the overall
management plan. This work order is referred to as the top IT topology work order.
When any operation from a management plan starts, another IT topology work
order, the operation work order, is created for the operation and its state. Workflows
that run within the context of an operation focus on the corresponding operation
work order.
Many Tivoli Service Automation Manager operations use a common main
workflow for tasks. This workflow is called the error handling workflow. This
workflow calls the operation-specific implementation workflow. If the workflow
returns an error by ending via the negative-action connection line, the error
handling workflow provides an assignment to the operator entitled 'A Workflow
Failed'. The operation work order is opened in the IT Topology Work Orders
application. The problem is described in the Messages tab of the application. The
operator can then route the workflow assignment and take one of the following
actions:
v Continue by ignoring the failed workflow and processing the remaining steps.
This option can be useful if the failed task was already completed manually by
8 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
the operator or if it can be omitted. Tivoli Service Automation Manager
continues processing by starting the next operation.
v Continue by re-executing the failed workflow. This option may be useful if
errors occur due to temporary problems (such as a temporary network outage).
Tivoli Service Automation Manager restarts the same operation with the current
input values.
v Continue by ignoring the failed workflow and canceling all remaining steps.
This option can be used if continuing the management plan is no longer
practical.
Note: Tivoli Service Automation Manager does not perform a cleanup in this
case.
Canceling means that all remaining job plans and tasks are still executed, but
each job task is considered completed when it is encountered, meaning that the
corresponding workflow is skipped. If an initial management plan is canceled by
the operator, the service deployment instance state is set to 'Canceled'. The user
has to manually clean up all the changes that occurred up to this assignment.
This includes topology changes, such as in the case of a WebSphere Add Server
workflow. It also includes changes made to the managed environment or Tivoli
Provisioning Manager.
You can also use the IT Topology Work Orders application to suspend and resume
work orders and send notifications to users about issues related to the current
management plan.
Auxiliary applications
Several auxiliary applications support special-purpose editing or process control
functions:
v Service Automation Manager
v Management Plan Input Parameters
v Management Plan Target Selection
v Service Topology Customization Editor
WebSphere Cluster Service
The WebSphere Cluster Service allows you to provision the IBM WebSphere
Application Server Network Deployment V6.1 product and manage its life cycle.
This section is relevant only if you have purchased and installed the Tivoli Service
Automation Manager for WebSphere Application Server chargeable component. See
Installing optional software on page 83 for instructions on installing this service.
It can be installed either directly after the main Tivoli Service Automation Manager
installation or at a later time.
Before you begin to use the WebSphere Cluster Service, complete the steps
pertaining to it under Configuring the managed environment to use the
WebSphere Cluster Service on page 244, including defining the configuration
items (CIs) for the associated host platforms.
The WebSphere Cluster Service provisions a WebSphere cluster consisting of the
following elements:
v WebSphere Cell
v WebSphere Network Deployment (ND) Manager
v WebSphere Network Deployment managed node
v WebSphere Application Server instance
Chapter 1. Product overview 9
v WebSphere Cluster
v HTTP Server node
This service comprises the following components:
v WebSphere Cluster Service definition, comprising best-practice WebSphere
topology templates and management plans
v Updated automation package (.tcdriver file), which enables Tivoli Provisioning
Manager to provision WebSphere server instances together with Tivoli Service
Automation Manager. Also included are sample XML files to configure Tivoli
Provisioning Manager to use the WebSphere Cluster service
v Scripts that perform changes in the WebSphere Application Server when they are
executed from Tivoli Service Automation Manager using the Script Adapter
The management plans include internal plans for creating a WebSphere cell or
adding a managed node to an existing cell. Plans for basic management tasks in
the life cycle of the service, such as starting and stopping individual components,
are also provided.
The WebSphere Cluster Service integrates very tightly into basic Tivoli Service
Automation Manager concepts and applications, utilizing the existing Service
Definitions and Service Topologies applications and processes such as Approval.
The following WebSphere components are part of each service deployment
instance. These components are modeled as individual topology nodes:
v Each instance contains and manages a single WebSphere cluster.
v The management instance for a cell, the Deployment Manager, can be
provisioned and is used heavily.
v There is at least one managed node that can be provisioned and managed.
v Each managed node contains a single application server instance, which is also
called a cluster member.
v Provisioning and management of an IBM HTTP server instance are also
supported.
WebSphere topology
In the following sections, the types of topology nodes used in the WebSphere
cluster service are listed. Each of these node types is defined by a Service Request
Manager classification that declares the attributes. Operations for topology nodes
are summarized for each type of node as applicable.
WebSphere Cell
A WebSphere ND Deployment Manager node that manages the cell and all
of its components, one or more WebSphere ND managed nodes hosting
application server instances, and a number of IBM HTTP Server nodes
representing the Web tier of the environment. Furthermore, a cell can
define multiple WebSphere clusters that group similar application server
instances.
Deployment Manager
A special type of WebSphere node for controlling a WebSphere cell and all
of its components. WebSphere components are configured within a cell is
done using the Deployment Manager node. The following operations are
supported:
10 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Installing WebSphere ND on a server and creating a Deployment
Manager profile (and thus a Deployment Manager node). This implicitly
defines a WebSphere cell that is managed by the new Deployment
Manager
v Defining a new WebSphere cluster within a cell. The cluster is initially
created without members
v Creating a new cluster member (application server instance) for an
existing cluster on an existing WebSphere managed node
v Start the deployment manager. The deployment manager has to be
started for most other operations to succeed. This is done during initial
provisioning.
v Stopping the deployment manager
v Starting a complete cluster, that is all members within a cluster
v Stopping a complete cluster, that is all members within a cluster
v Starting a managed node and all cluster members that are managed by
this node
v Stopping a managed node and all cluster members that are managed by
this node. This might be required if the server this node runs on needs
maintenance
v Starting the application server instance
v Stopping the application server instance
v Generating the plug-in configuration for the web servers configured for
a cell and propagate it to the web server. The web server must then
route web traffic based on the new configuration, for example handling
load for newly deployed applications or routing to newly created cluster
members
v If you use Tivoli Monitoring in conjunction with Tivoli Service
Automation Manager, install a Tivoli Monitoring agent on the server this
instance runs on
v If you use Tivoli Monitoring in conjunction with Tivoli Service
Automation Manager, uninstall a Tivoli Monitoring agent from the
server this instance runs on
v Enabling administrative security on this managed node. You can set a
user name and password for the administrative console of the
deployment manager, for example
v Incorporating a managed node in the cell that is managed by this
Deployment Manager. In this way, the Deployment Manager can
introduce changes to the given node
v Removing the given managed node from this cell
v Copying the HTTP Server configuration script that was created by the
HTTP Server installation to the Deployment Manager, so that it can be
invoked to make the HTTP Server known to the Deployment Manager
v Uninstalling WebSphere from a server
Managed Node <n>
A managed node within a WebSphere cell. The node is
managed/controlled by the cell Deployment Manager and does not have
its own management interface (such as an administration console).
Managed nodes host application server instances for deploying J2EE
applications. The following operations are supported:
v Installing WebSphere ND on a server and creating a managed node
profile (and thus a WebSphere managed node).
Chapter 1. Product overview 11
v Installing a Tivoli Monitoring agent on the server this instance runs on.
This is only applicable if you use Tivoli Monitoring in conjunction with
Tivoli Service Automation Manager.
v Uninstalling a Tivoli Monitoring agent from the server this instance runs
on. This is only applicable if you use Tivoli Monitoring in conjunction
with Tivoli Service Automation Manager.
WebSphere Application Server instance
A WebSphere Application Server instance is an implementation of the
WebSphere Application Server. It is a container for hosting J2EE
applications and corresponds to one instance of a Java
Virtual Machine
on the respective node. Application server instances can be hosted on
managed or stand-alone WebSphere nodes; they cannot be hosted by
Deployment Manager nodes, that is, they cannot be defined within
Deployment Manager profiles.
WebSphere Cluster
A WebSphere cluster is a logical grouping defined within a WebSphere cell
for managing similar application server instances, that is, those of equal
configuration. The typical reasons for clustering are load balancing and
high availability.
IBM HTTP Server node
An IBM HTTP Server is the web server product of the WebSphere family.
In a clustered environment, instances of HTTP Server form the web or
front-end tier of a J2EE application-hosting landscape and distribute HTTP
traffic among members of a cluster of WebSphere Application Servers.
Supported operations are as follows:
v Installing and configuring IBM HTTP Server on a server.
v Starting this HTTP Server instance.
v Install a Tivoli Monitoring agent on the server this instance runs on. This
is only applicable if you use Tivoli Monitoring in conjunction with Tivoli
Service Automation Manager.
v Uninstall a Tivoli Monitoring agent on the server this instance runs on.
This is only applicable if you use Tivoli Monitoring in conjunction with
Tivoli Service Automation Manager.
DBMS server
A database management server. This is used in the optional Tivoli
Monitoring integration, such that events reported by this database server
can be correlated to a service deployment instance.
Database instance
A database instance managed by a DBMS server. This is used in the
optional Tivoli Monitoring integration, such that events detected by this
database can be correlated to a service deployment instance.
Management plans
The following processes can be performed on a deployed instance of the
WebSphere Cluster Service:
Add Server
Adds a WebSphere managed node to a cell and creates a member that is
added to an existing cluster
12 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Remove Server
Removes an existing member from a cluster and deprovisions its
associated WebSphere managed node from a cell
Start WebSphere Deployment Manager
Starts the Deployment Manager for this service deployment instance
Stop WebSphere Deployment Manager
Stops the Deployment Manager for this service deployment instance
Start WebSphere Node
Starts a complete WebSphere managed node, including all application
server instances hosted by the node
Stop WebSphere Node
Stops a complete WebSphere managed node, including all application
server instances hosted by the node
Start WebSphere Cluster Member
Starts a specific application server instance on a managed node
Stop WebSphere Cluster Member
Stops a specific application server instance on a managed node
Start WebSphere Cluster
Starts a complete WebSphere cluster, that is, all of the members of the
cluster
Stop WebSphere Cluster
Stops a complete WebSphere cluster, that is, all of the members of the
cluster
Service topology node attributes
The service topology is the set of individual hardware and software components
that constitute the defined or instantiated service. Each element of the topology is
referred to as a node. The following section describes a topology using the
WebSphere Cluster Service as a sample framework.
In the WebSphere Cluster Service, the main logical component of the environment
to be managed is a WebSphere Cell. Consequently, the top node in the hierarchy is
a WebSphere Cell node. A WebSphere Cell contains an IBM HTTP Server, a
Deployment Manager, and one or more managed nodes. A cell can also define
multiple clusters. All of these nodes are direct children of the WebSphere Cell node.
A WAS ND managed node hosts WebSphere Application Server Instances. Thus,
the managed node has a child designated as "AppSrv Instance".
All nodes that require hardware resources for deployment have associated resource
allocation templates that define what the resource must look like.
To support the configuration of more than one topology node on a physical server,
nodes that are eligible for co-location can be assigned to a co-location group. That
group is then assigned to the physical resource. Nodes not assigned to a group are
classified as stand-alone nodes. Nodes in a co-location group can later be
selectively deleted from the group, or an entire group can be dissolved, in each
case the affected nodes are returned to stand-alone status.
The WebSphere Cell contains one or more managed nodes. Each node has three
special attributes:
v Minimum cardinality
v Maximum cardinality
Chapter 1. Product overview 13
v Maximum cardinality unlimited
These attributes are used to define how often a node can occur in an instance of
the topology.
Other attributes indicate whether the node participates in performance monitoring
and whether it needs a hardware resource to run, for example.
Since selected nodes in a service topology can occur multiple times, a mechanism
is required to ensure that the attributes that describe these nodes are unique across
the topology or even across all services.
Node attributes must allow for the definition of a uniqueness scope in order to
prevent conflicts with attributes of other nodes in a topology. For example, all
nodes within a topology should have a unique name. WebSphere Application
Server nodes that are deployed on the same host must also have unique,
non-conflicting port number assignments. A simple resolution of conflicts is
provided through placeholders in character-string-type attributes that are replaced
with numbers that are automatically incremented at instantiation time. These
numbers are replaced and incremented on a per-topology basis.
A more sophisticated and granular handling of attributes (both string and numeric)
is necessary, for example, for port number assignments. In general, automated
resolution of conflicts is done based on numeric variable substitution according to
user-defined rules (see below). With numeric attributes, the entire attribute is
subject to substitution. With string attributes, placeholders for such numeric
variables are placed in the string. It is possible to insert multiple placeholders into
one string, and each of these is replaced. If placeholders in one string are identical,
the same value is inserted for each occurrence in a string. The complete identifier
of such a placeholder variable comprises the fully qualified name (including node
classification ID) of the attribute (see also Attribute Name Handling below) and the
name of the placeholder variable. For numeric attributes, the fully-qualified name
of the attribute itself identifies the replacement variable.
Uniqueness scope: A uniqueness_scope parameter can be set for all specification
attributes that defines which type of uniqueness is to be enforced for that
parameter of a node within a topology. The following uniqueness scopes can be
set:
Table 2. Uniqueness scopes for topology node attributes
Uniqueness scope Meaning
None Uniqueness not enforced (default scope)
Global Uniqueness is enforced across all topology nodes known to the
system
Service Definition Uniqueness is enforced across all topologies of service deployment
instances derived from one service definition
Topology Uniqueness is enforced within the topology. The value of that
attribute of a node must be unique within the entire topology,
meaning that no other node in the same topology can have the same
value for that attribute
Host Uniqueness is enforced on a per-host basis. Nodes deployed on the
same host must not define the value for an attribute
Group Uniqueness is enforced in a user-defined group; once defined, a
group can be referenced by attributes of all nodes, and uniqueness
is enforced in the scope of the selected group
14 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Attribute name handling: The user can define how the name of an attribute is
treated with respect to uniqueness, that is how the uniqueness is enforced between
the attributes of one node and the attributes of other nodes. The following types of
attributes handling can be set:
Table 3. Uniqueness specifications for attribute names
Attribute name
uniqueness Meaning
Exact Only values of identically named attributes are considered for
uniqueness handling (default)
Wildcard An expression containing wildcard characters (%) can be specified to
define a range of attributes that are considered for uniqueness
handling. Not only can the Wildcard specification can be used not
only for selecting a wider range of actual attribute names, it can also
be used to select attributes from multiple classifications. For
example, if attributes PORT_ONE and PORT_TWO are to be
correlated during uniqueness handling (to prevent port assignment
conflicts), the wildcard expression PORT_% could be used
Alias group Arbitrarily named attributes can be assigned to user-defined alias
groups. All attributes that belong to the same alias group are then
considered for uniqueness handling. This allows for correlating
attributes, for example, of different node classifications, that would
be correlatable by name. For example, an attribute of a WebSphere
node named SOAP_PORT (a TCP/IP port) and an attribute
BOOTSTRAP_ADDRESS (also a TCP/IP port) of an Application
Server instance could be assigned to an alias group
NETWORK_PORTS with host scope in order to keep allocated
TCP/IP ports unique on a host.
Uniqueness resolution rules: Within the user-defined uniqueness scope of an
attribute, variables are substituted according to a set of rules that define how
substitution values are calculated. Resolution is always performed on the basis of a
numeric calculation. There is currently one rule defined:
Table 4. Uniqueness resolution rule
Uniqueness resolution rule Meaning
Increment Increments the substitution variable by a
user-defined step value (default 1) starting
at a certain base value (default 1). A unique
value is calculated by obtaining the highest
value for an existing attribute and
incrementing it to assign the value to the
new attribute. The value of a numeric
attribute defines the base value and
overrides any such value specified in the
rule.
Numeric placeholders in character strings are treated the same way as numeric
attributes except that the base value is always the one defined in the rule.
Identically named placeholders within one string are assigned the same value. For
text-only attributes without placeholders, the uniqueness requirements can be
defined, but no automatic uniqueness resolution is performed.
Chapter 1. Product overview 15
Tivoli Service Automation Manager detects violations of the uniqueness rules for
attributes and displays the affected parts of the topology in the Node Attribute
Uniqueness Violations panel.
Performance monitoring support for the WebSphere Cluster
service
You can also use the Tivoli Service Automation Manager to install performance
monitoring software (agents) on the servers it provisions. This software detects
situations that cause degraded performance. Tivoli Service Automation Manager
reacts to such situations by presenting the user with options to analyze and resolve
the problems based on procedures that have been accepted as recommended
practices.
Note: This section applies only to the Tivoli Service Automation Manager
WebSphere Cluster service. It does not apply to the Tivoli Monitoring based
resource usage collection functions offered with the Self-Service Virtual Server
Provisioning component.
Each Tivoli Service Automation Manager service definition can have an associated
monitoring definition. These definitions provide the framework for implementing
the monitoring agents and controlling which types of events it will react to.
If you need to modify the service definition delivered with Tivoli Service
Automation Manager to suit your requirements for performance monitoring, you
can change it using the set of Monitoring Definition applications.
Performance monitoring is supported in combination with IBM Tivoli Monitoring
on distributed platforms (Linux on System x, System p, and System z, and AIX).
The Monitoring Definition applications refer to the monitoring environment being
used with respect to any given service definition and service deployment instance.
IBM Tivoli Monitoring must be installed separately. It is no longer offered as an
installation option for Tivoli Service Automation Manager.
For details on setting up IBM Tivoli Monitoring, see the documentation for this
product (IBM Tivoli Monitoring and OMEGAMON XE documentation).
The Situation Analysis application handles the situations detected by the
monitoring agents in a deployed landscape.
When a monitoring agent detects a situation, it triggers the execution of a
workflow within Tivoli Service Automation Manager. The Situation Analysis
application, which is part of this workflow, is called and assigned to the user with
the role corresponding to the domain that applies to the agent and situation. For
example, if the scenario is part of the domain AIX or DB2, the application
execution within the workflow is assigned to the respective AIX administrator or
DB2 administrator role. A customer can also add a new domain by enhancing the
situation analysis workflow, adding new roles and adding new values to the
domain. An assignment to analyze the event appears in the inbox of the
corresponding user within the Start Center panel of the Tivoli process automation
engine user interface. When the user clicks on this assignment, the application to
analyze the event opens.
The following categories of information are shown:
v Information about the situation, including:
The system on which the situation occurred
16 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
The domain the situation is related to (WAS, DB2, AIX, LINUX)
The name of the situation
v One or more service deployment instances that are candidates for the situation
indicated.
You can then browse the entire context of the instance within which the situation
occurred, including the topology, the CIs involved, and the monitoring
definitions. Deployment instances are only shown when the affected system
belongs to that instance and the situation was defined for one of the agent types
deployed on the system for that instance. Each instance includes a link to the
Service Deployment Instances application so that you can browse all information
and details related to that instance.
v when a service deployment instance is selected, the recommended practices (also
called good practices) for the situation in the context of this instance.
You use analysis practices to analyze a situation and management practices to
resolve a situation. These practices can refer to actions in the Select Action menu
to launch another management tool (such as the TEP console) in order to
analyze or resolve a situation. Analysis practices are displayed as plain text. A
management practice can be either a management action described in text form
and intended to be executed manually by the user, or a Tivoli Service
Automation Manager management plan that can be executed automatically by
the system.
The list of practices is sorted by the probability that the practice will resolve the
event. The number of times the practice was chosen to resolve an event of this
type is used as the sorting criterion. That is, the practice chosen most often and
considered the best approach by an administrator (by clicking on the Feedback
Good Practice button) is displayed as the first element in the list.
Depending on the analysis of the event, you can choose among the following
actions to resolve the problem:
v Close the event if it is only informational and no action is required.
v Go to the Incident application.
v Start a management action from the set of management practices to resolve the
event.
For more information, see the applicable task descriptions and "Working with
performance monitoring functions" in the User's Guide.
Service structure
Services offered by Tivoli Service Automation Manager are organized as follows:
Service definition
Basic set of rules for creating a specific IT landscape. Tivoli Service
Automation Manager delivers preconfigured service definitions that can be
used as templates for customizing the definition to meet your specific
needs.
Service deployment instance
Actual IT landscape described by the service definition.
Service topology
A set of hardware servers and software representing the IT landscape.
Monitoring definition
A framework for activating monitoring software to detect possible
performance problems in a deployed landscape.
Chapter 1. Product overview 17
Management plan
Predefined modification of the provisioned landscape.
Job plan
A tool that implements management plans in terms of software.
Workflows
Preconfigured sequence of steps that perform a specific function. For
example, there are workflows to instantiate (deploy) a service, make
management changes once the instance has been deployed, and perform
error handling.
Work order
A tool that provides the framework for executing management plans.
Resources
Actual hardware and software that can be used in constructing the
landscape.
Service provider support
The new service provider feature allows you to create clouds that can be used by
multiple customers. Two types of resources are available within a cloud: single
customer objects that are assigned to customers individually, and multi-customer
objects that can be shared among customers. The underlying idea of the solution is
data segregation, which is used to associate resources with one or more customers.
Resources can be used more efficiently and customers are able to support multiple
internal organizations.
A customer level is introduced in the self-service user interface. Each customer is
associated with a specific group of teams and users. Users can be assigned to one
or more customers and teams. Users can view only the information and resources
that are related to their associated customers.
Customers and their resources are managed in the administrative user interface,
with the Cloud Customer Administration application. The application is organized
into tabs. The tabs support the following actions:
v Viewing the list of customers, their teams and users, requests, resources,
reservations, quotas, and limits
v Creating customer templates and modifying existing customers
v Assigning and returning customer resources
v Setting quotas and limits on customer resources
In Tivoli Service Automation Manager, there is a clear distinction between objects
that are assigned to only one customer and resources that can be shared by many
or even all customers within a cloud. The Tivoli Process Automation engine service
provider functionality segregates the data for this purpose. Multi-customer
resources are associated manually. Association tasks related to those resources are
performed in the Cloud Customer Administration application. Single customer
resources are assigned automatically to the customer for which the requesting user
is working. For example, if a person who is assigned to a specific customer
submits a request for a new team, the fulfillment flow associates the team with the
customer automatically.
Resources that can be shared by customers are:
v Cloud server pools
18 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Cloud network templates
v Cloud storage pools
v Master images
v Software products
v Cloud customer users
Resources that can be assigned only to individual customers are:
v Teams
v Users
v Service deployment instances, also called projects
v Saved server images
The multi-customer support in Tivoli Service Automation Manager introduces new
tasks related to the data segregation system. This system must ensure that users
see only the data assigned to them.
Four new roles are introduced in the self-service user interface: cloud customer
administrator, approver, multi-customer user (valid only for Cloud customer level
policy), and security administrator. Some significant changes were also made to the
authorities of the existing user roles. The main reason for the overall reorganization
is the introduction of the cloud customer level.
Users in the Cloud customer administrator role have authorities similar to the
authorities of a cloud administrator, but if they are on Cloud Customer Level
Policy, they are dedicated to individual customers. They have no authority to
register or unregister images.
Another role that is strictly connected with the cloud customer level is the
approver role. Approvers can check the status of projects, and see the service
requests associated with their customers. They are also authorized to approve
those service requests. Cloud administrators and cloud customer administrators
can also approve requests.
Important: When a cloud administrator creates another cloud administrator, both
Membership and Grant option must be selected for the new user. It is done
because the newly created Cloud Admin loses the Grant option when the
password is changed.
Multi-customer user role has authorities to administer multiple customers. Only
cloud administrators can create this role.
Security administrator can create, manage and delete users.
User roles are called security groups starting with version 7.2.2, and a user can be a
member of multiple security groups.
You can add new customized security groups. For example, you can define a
separate security group that is authorized to use VMware specific offerings. You
can also reuse the existing roles and group management from LDAP. These
procedures are described in details in the Tivoli Service Automation Manager
Extensions Guide.
Related information
Chapter 1. Product overview 19
For more information about creating and removing customers in the self-service
user interface, see Managing customers in the Tivoli Service Automation Manager
User's Guide.
For more information about the features of the Cloud Customer Administration
application, see Cloud Customer Administration application on page 6.
Reporting function
Reports show information related to service definitions and deployments.
Tivoli Service Automation Manager report types and content
The following types of reports are available with Tivoli Service Automation
Manager. The type of information shown in each report differs depending on the
service.
Table 5. Summary of Tivoli Service Automation Manager Reports and Content
Tivoli Service
Automation Manager
Application Report Type Report Name Selection Parameters Content
Service Definitions All Service Definitions AllSD
<service>
.rptdesign
List of all service definitions
and instances.
Service Definitions Service Definition
Summary
SDSummary
<service>
.rptdesign
Status
Owner
From Date
To Date
Basic service definition
information and list of service
definitions and deployments.
Service Definitions Service Definition
Details
SDDetail
<service>
.rptdesign
Service Name Service-dependent content with
identifying information, status,
topology, monitoring and
resource assignments, and
service definition history
Service Deployment
Instances
Service Deployment
Summary
SISummary
<service>
.rptdesign
Status
Owner
Service Definition Name
From Date
To Date
Service-dependent graphics
and lists showing CPU and
memory levels, servers by
owner, servers by platform
architecture, monitoring agents
by type, and instances
Service Deployment
Instances
Service Deployment
Details
SIDetail
<service>
.rptdesign
Service Name Service-dependent content
including graphics showing
CPU, memory, servers by
architecture, monitoring agents,
and service history
Service Deployment
Instances
Co-Located Nodes coLocation
<service>
.rptdesign
Host Name Information concerning
components of the service
instance that are located on the
same physical server
Service Deployment
Instances
Service Deployment
History Summary
SISummaryHistory
<service>
.rptdesign
From Date
To Date
Service-dependent graphics
showing CPU, memory, servers
(over time and for all
deployments)
To see the complete list of reports available in your environment:
1. Log in to the administrative interface.
2. Click Go To > Administration > Reporting > Report Administration.
3. In the Application field, type PMZHB and press Enter. The list of all available
reports is displayed.
20 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
For details on generating reports, see Working with the service automation
reports on page 287. For post-installation setup tasks required to activate the
Reporting function, see Configuring the reporting function on page 288.
Tivoli Usage and Accounting Manager reporting function
As an option, Tivoli Service Automation Manager can use the Tivoli Usage and
Accounting Manager metering function. Tivoli Usage and Accounting Manager
helps you improve IT cost management. You use it to analyze your costs and track,
allocate, and invoice based on actual resource use by department, user, and many
other criteria.
Tivoli Service Automation Manager instantiates and manages service instances. It is
able to track creation, modification, and deletion of a service instance itself, as well
as the capacity assigned to it. This information can be periodically extracted and
transformed into a so-called CSR (Common Server Resource) file, which can then
be retrieved by Tivoli Usage and Accounting Manager to generate reports.
Tivoli Usage and Accounting Manager helps measure service usage data. In the
Tivoli Service Automation Manager context, this data is the amount of resources
(CPUs and memory) allocated or assigned to servers provisioned by the
Self-Service Virtual Server Provisioning component over time. Servers belong to
projects and projects belong to the service. Each deployment has a user. The user
can own deployments coming from different services, request new deployments, or
request changes to the existing deployments. For accounting purposes,
organizational information must be defined for each user, that is, at the minimum,
a department identification must be assigned to each user identification. For each
project, you can distinguish between the requester of the project and the
organization being charged with the project. You can define organizational
information for a project by adding an (optional) project account code for the team
that is using the project. Reports can then be generated based on the team and its
users. It is also important that no two deployment instances are created with the
same name, because this will result in inaccurate usage and accounting data.
Before you can start using this function, you need to configure both Tivoli Service
Automation Manager and Tivoli Usage and Accounting Manager. For more
information, see Integrating Tivoli Usage and Accounting Manager on page 266.
To find out how to employ the collected data in the form of reports, see Working
with usage and accounting reports on page 291.
Additional software installation on the provisioned servers
With Tivoli Service Automation Manager, you can install one or more software
modules when you create a virtual machine, or you can install them on virtual
machines that were already provisioned.
You can use one of the product components, Tivoli Provisioning Manager, to define
software installation templates and then install that software on the virtual servers.
After the software product definitions are created in the administrative interface,
the self-service interface users can install the software modules on virtual
machines.
Before you install any software modules on a provisioned machine, create software
product definitions using the administrative user interface. See this topic for more
information on creating software product definitions.
Chapter 1. Product overview 21
In the self-service interface, you can install software modules by submitting three
types of requests:
Create Project with server type
You can select software to be installed on the servers that are to be
provisioned in a project. All servers have the same software installed.
Add server type
You can select software to be installed on a new server that is added to a
project.
Install Additional Software on a Server
You can install software modules on a server that is already provisioned.
You can select multiple software items and install them in a specified order. You
can also specify additional configuration parameters for the software items to be
installed.
VMware additional disk functionality
The VMware Additional Disk functionality enables you to provision additional
local storage when provisioning VMware virtual machines using the self-service
user interface.
This feature enables cloud and storage administrators to create cloud storage pools,
which map VMware datastores to customers. You can control whether an
additional storage is to be thin provisioned or not and you can limit the storage of
individual customer using the standard Tivoli Service Automation Manager quota
mechanisms.
The extension also enables team administrators or other users to request additional
storage from the storage pools during the virtual machine (VM) request process,
either when creating a new project or while adding servers to an existing project.
The lifecycle of these disks is equivalent to the lifecycle of the VM. This means that
if the VM is removed, the additional storage is also removed. Similarly, if a backup
image is made of a server, the additional disks will be part of that image and will
be restored when that image is restored.
Disks can be provisioned both for Windows and Linux VMs and can be formatted
and mounted in the VM automatically with a variety of formats.
Note: Only the first SCSI adapter is used for disk provisioning.
VMware clone server functionality
You can use the VMware clone server feature to clone a VMware server that is
provisioned by using Tivoli Service Automation Manager self-service UI. Internally,
after a direct disk clone, the cloned server gets a new IP address in the same IP
pool as defined for the source server. All other configurations or personalizations
of the existing server are left unchanged.
Note: If you use the ITM monitoring agent, then its configuration is not
personalized for the cloned machine by the Tivoli System Automation Manager.
Manual post configuration steps are required for the ITM setup to work properly
in the new VMware clone.
22 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Managing POWER LPAR provisioning with VMControl
This topic provides reference information about managing POWER
LPAR virtual
servers using IBM Systems Director VMControl.
VMControl quick reference
VMControl is a plug-in of IBM Systems Director. Tivoli Service Automation
Manager supports IBM Systems Director VMControl 2.3.1, 2.4.1.1, 2.4.2, 2.4.3.1
Enterprise Edition.
VMControl is an alternative way to provide POWER LPAR virtualization and
image management functions.
For more information about VMControl, see the section on VMControl in the IBM
Systems Director Information Center:
Setting up the environment
Before a Tivoli Service Automation Manager administrator can manage POWER
LPAR computers using VMControl, the environment needs to be configured. For
more information on the procedure, see Configuring cloud server pools on page
173
Managing provisioning
All self-service requests, apart from modifying disk size and saving/restoring
virtual servers, are available for POWER LPAR provisioning via VMControl.
Recovering form errors
For troubleshooting when using VMControl, see Troubleshooting when using IBM
Systems Director VMControl on page 507.
Image management
Software and server images can be maintained in the Tivoli Provisioning Manager
Image Library for selection at provisioning time. New Server image templates can
be created and imported to the library. Once the images are in the library, they
must be registered so that they can be used to provision new virtual servers. A
snapshot-like image of an entire provisioned server can also be saved and restored
in the current project, so that the server can be initialized at the state represented
by the image.
The Tivoli Service Automation Manager User's Guide describes the image-related tasks
that are available to administrators and users working with the self-service user
interface.
For other administrative tasks, see Managing server images on page 307.
Chapter 1. Product overview 23
Workload Deployer overview
IBM Workload Deployer is an optional, separately paid appliance that can be
integrated with Tivoli Service Automation Manager.
Note: The only supported version of IBM Workload Deployer is 3.0.
Workload Deployer offers a comprehensive set of patterns and capabilities that
focus on addressing WebSphere workloads. It enables creating, deploying,
monitoring, and managing service construction and delivery within Tivoli Service
Automation Manager. The appliance is based on special virtual images, such as the
WebSphere Application Sever Hypervisor Edition, and allows creating patterns that
represent the target application environment. These patterns include the
infrastructure nodes of the application and the necessary configuration for the
environment. By using Workload Deployer, you can deploy them into your private
cloud. In this way, the appliance provides management and monitoring capabilities
that give you necessary controls over your running application environments.
The integration with Tivoli Service Automation Manager
The functions of Workload Deployer and Tivoli Service Automation Manager are
complementary in nature.Workload Deployer allows users to create, deploy, and
manage customized environments that are both based on the WebSphere
application and located in a private cloud. Tivoli Service Automation Manager
provides the tools to perform the standardization and the automation in the cloud
environment, thereby enabling rapid provisioning for a wide breadth of workloads.
The integration provides:
v the service delivery and management capability of Tivoli Service Automation
Manager
v the Workload Deployer patterns and capabilities
v a unified interface from which users can deploy and manage their cloud-based
environments
Tivoli Service Automation Manager enables creating and deploying application
environments based on any kind of software. Workload Deployer offers capabilities
for application environments based on IBM software, thereby simplifying
installation, configuration, integration, and orchestration scripting procedures for
those workloads.
The integration of the two applications can be made according to different
scenarios. Depending on what services you want to deliver via the cloud, the most
common scenarios are when:
v When there is a need for unified management of private clouds that include
WebSphere.
v When you need to add request workflow capabilities to Workload Deployer.
After the integration, Tivoli Service Automation Manager becomes the primary
management device for your private cloud. The capabilities of both the products
remain the same. Tivoli Service Automation Manager enables the provisioning and
management of a wide array of cloud-based services including operating systems,
application platforms, and end-user applications. The integration of Workload
Deployer enhances the time to value for delivering WebSphere environments
regardless of what other services you deliver through Tivoli Service Automation
Manager. Moreover, integrating the products allows you to unify management of
your cloud services using the self-service user interface. Workload Deployer
delivers its patterns, namely rapid provisioning, consistent configurations, and
24 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
inherent product knowledge for WebSphere workloads without the need to switch
between multiple service management portals.
Maintenance mode overview
You can use maintenance mode to stop processing requests and restrict user access
during a maintenance window.
The administrator can schedule the maintenance mode by using the Cloud
Maintenance Administration application in the administrative user interface. The
system goes through the following statuses:
1. ONLINE
2. REQUEST_QUIESCE
3. QUIESCING
4. QUIESCED
5. REQUEST_ONLINE
6. PENDING_ONLINE
7. ONLINE
The statuses are described in detail in Maintenance mode statuses on page 345.
The system notifies the self-service interface users when the maintenance window
is scheduled. During the maintenance window, no requests or approvals can be
processed, and users can only view the user interface in read-only mode.
In order to quiesce the Tivoli Service Automation Manager management server, the
framework stops the major escalations that are used to process the service requests
in the various states. When the system enters QUIESCING status, some escalations
are deactivated. When the system enters PENDING_ONLINE status, the
escalations are activated again. When all escalations are reactivated, the system
status changes to ONLINE and users can submit requests again.
For more information about managing maintenance mode, see Managing the
maintenance mode on page 344.
Chapter 1. Product overview 25
26 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Chapter 2. Installing and upgrading Tivoli Service Automation
Manager
This section describes how to
install and upgrade Tivoli
Service Automation Manager
and its prerequisite software.
Overview of the Tivoli Service Automation Manager installation
process
During installation, you use the Tivoli Service Automation Manager Installation
Launchpad to check system prerequisites and then install the prerequisite software
and the Tivoli Service Automation Manager product itself. The principal
prerequisite for Tivoli Service Automation Manager, Tivoli Provisioning Manager,
includes the necessary middleware and base services for the shared product
environment. Tivoli Service Automation Manager itself is packaged as a set of
process management products (PMPs).
Important: Due to the complexity of the installation process, in particular with
respect to the middleware and base services, read the Tivoli Service Automation
Manager and Tivoli Provisioning Manager installation documentation before using
the Launchpad to install components.
Note: The Launchpad includes links and references to external documentation at
the appropriate points in the process. Become familiar with the Launchpad by
starting it on one or more of the prospective administrative or management system
servers.
Because Tivoli Provisioning Manager is a major component in the installation
process, you should refer also to the Tivoli Provisioning Manager Installation Guide
for installation requirements and details. However, use the Tivoli Service Automation
Manager Installation Launchpad, and not the corresponding Tivoli Provisioning
Manager Launchpad, to start the verification scripts and individual installers for
the middleware, base services, and individual products.
The information shown in the Launchpad is appropriate to the local operating
system. Information that does not apply to that operating system (for example, the
use of Windows as a management server) will either not appear in the Launchpad
or related links will not be active.
The Installation Launchpad starts on each server in the management system on
which software is to be installed. The Installation Launchpad is also started on the
administrative server to install certain platform-independent components on the
management system. Software related to the deployment of the components within
the management system is installed on the administrative server itself. You
therefore use the administrative server to install product upgrades and applications
Copyright IBM Corp. 2008, 2012 27
on the management system. The administrative server is not needed for normal
operation, but it is essential for providing service. If you lose the administrative
server, you will no longer be able to maintain the management server. Also, if you
make a backup of your management system, you must back up the state of the
administrative server that exactly matches it. Otherwise you will not be able to
apply any further PMP or any service upgrade to your management system.
The Installation Launchpad drives the installation by checking that prerequisites
have been met. It also calls installers for the prerequisite middleware and base
services, and the Process Solution Installer for the applications: Tivoli Provisioning
Manager, Service Request Manager, and the Service Automation Manager itself.
Optionally, you can also install Tivoli Service Automation Manager for the
WebSphere Application Server component.
Tivoli Service Automation Manager 7.2.4.4 supports two installation modes:
v Full installation
v Upgrade of the 7.2.2.1, 7.2.2.2, 7.2.3, 7.2.4, 7.2.4.1, 7.2.4.2, 7.2.4.3 installation to
version 7.2.4.4
Both these installation modes are available from the Installation Launchpad that is
available in the Tivoli Service Automation Manager 7.2.4.4 upgrade package.
Important: Before starting the installation or upgrade, visit the Installation
Planning section of the Installation Launchpad. Select the correct Server Role and
Installation Type there and provide any other necessary information, such as
package paths.
Depending on which installation type you select, only the relevant subset of
installation steps is visible and accessible in the Installation Launchpad sections.
You must perform all the steps available in the Installation Launchpad in sequence
in order to successfully install or upgrade the product.
Planning for Tivoli Service Automation Manager
Before you start installing the product, review hardware, software, and other
requirements.
Hardware and operating system requirements for Tivoli
Service Automation Manager
The management and administrative servers are subject to certain requirements to
ensure proper installation and subsequent operation in the Tivoli Service
Automation Manager environment.
Overview of the management system topology
The Tivoli Service Automation Manager and prerequisite software is installed on 1
to 3 servers referred to in the Tivoli Service Automation Manager context as the
management system.
The three logical components (or software servers) of the management system are:
v provisioning server (also referred to within Tivoli Provisioning Manager as the
application server and in Tivoli Service Automation Manager as the management
server )
v database server
28 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v directory server
Refer to the Tivoli Provisioning Manager Installation Guide and the Tivoli Service
Automation Manager Installation Launchpad for illustrations of possible
topologies.
Note: The term management server is a Tivoli Service Automation Manager-specific
term that designates the hardware server accommodating at least the Tivoli
Provisioning Manager provisioning server and the Tivoli Service Automation
Manager applications. In the Tivoli Service Automation Manager context, the terms
management server and provisioning server are synonymous.
Each of these software servers can be installed (or could have been preinstalled) on
a separate hardware server (also a virtual server), or can be co-located. In the
single-server configuration, all three components are installed on the same
hardware server.
An administrative server (commonly referred to in the Tivoli Provisioning Manager
context as the administrative workstation) is also needed to install selected Tivoli
Service Automation Manager related software on the management system. The
administrative server is later used to manage upgrades to the management server.
Note: If the prospective provisioning server of the management system also meets
the hardware and software requirements for an administrative server, the two
functions can be co-located. In other words, the same hardware server can be used
for both, the provisioning server and the administrative server. Otherwise, a
separate administrative server is required.
Important: While installing the product using the launchpad, before specifying
system requirements of your servers, decide whether to use your current system as
a management server or an administrative server, or both. You can do that by
checking the appropriate box at the end of Overview of the management system
topology section. A number of installation options is offered depending on your
selection.
Requirements for the management system servers
See the Tivoli Provisioning Manager Installation Guide for details and individual
space requirements for the middleware.
The following table lists the hardware platforms and operating systems that are
supported in the Tivoli Service Automation Manager management system
environment. The management servers running Tivoli Service Automation
Manager must meet the minimum requirements for processors, memory, disk
space, and swap space prescribed here or in the supplementary support
information (technotes) for Tivoli Provisioning Manager and Service Automation
Manager.
Table 6. Management server hardware and operating system requirements
Hardware Operating System
System p
IBM AIX 7.1 64bit
IBM AIX 6.1 Technology Level 3 64bit
IBM AIX 5.3 Technology Level 10, 64bit
Chapter 2. Installing and upgrading 29
Table 6. Management server hardware and operating system requirements (continued)
Hardware Operating System
System x
Red Hat Enterprise Linux Advanced Server 6 Update 3 x86 64bit
Red Hat Enterprise Linux Advanced Server 6 Update 2 x86 64bit
Red Hat Enterprise Linux Advanced Server 6 Update 1 x86 64bit
Red Hat Enterprise Linux Advanced Server 5 Update 5 x86 64bit
Red Hat Enterprise Linux Advanced Server 5 Update 4 x86 64bit
Red Hat Enterprise Linux Advanced Server 5 Update 6 x86 64bit
SUSE Linux Enterprise Server 11 Service Pack 2 x86 64-bit
SUSE Linux Enterprise Server 11 Service Pack 1 x86 64-bit
SUSE Linux Enterprise Server 11 x86 64-bit
SUSE Linux Enterprise Server 10 Service Pack 3 x86 64-bit
System z
Red Hat Enterprise Linux Advanced Server 6 Update 1 (IBM System z 64-bit)
Red Hat Enterprise Linux Advanced Server 5 Update 5 (IBM System z 64-bit)
Red Hat Enterprise Linux Advanced Server 5 Update 4 (IBM System z 64-bit)
SUSE Linux Enterprise Server 11 (IBM System z 64-bit)
SUSE Linux Enterprise Server 10 Service Pack 3 (IBM System z 64-bit)
Note: If you use Power
via
VMControl 2.4.2 via
System Director (Power
6 & Power 7)
v AIX 6.1 TL 4
v AIX 6.1 TL 7
PowerVM via
VMControl 2.4.1.1, 2.4.2,
and 2.4.3.1
v AIX 6.1 TL 4
v AIX 6.1 TL 7
v AIX 7.1
System z z/VM 5.4
v SUSE Linux
Enterprise Server 10
v SUSE Linux
Enterprise Server 11
v Red Hat Enterprise
Linux 5.4
v Red Hat Enterprise
Linux 5.5
Including DirMaint
.
RACF
is optional.
Chapter 2. Installing and upgrading 35
Software requirements for Tivoli Service Automation Manager
Tivoli Service Automation Manager depends on other software to provide services
to complete requests.
Important: Version numbers in the column Version (new installation) apply only
to the new installation of the Tivoli Service Automation Manager 7.2.4. If Tivoli
Service Automation Manager is updated from version 7.2.2.1 or 7.2.2.2, then the
column Version (updated) applies.
See also the Installation Guide for Tivoli Provisioning Manager in its knowledge
center.
The following table summarizes the software components in a Tivoli Service
Automation Manager environment.
Table 11. Summary of software in the Tivoli Service Automation Manager environment
Software Component
Version (new
installation)
Version
(updated) Remarks
Tivoli Service Automation Manager
Tivoli Service
Automation Manager
(Base)
7.2.4 7.2.4
Tivoli Service
Automation Manager
Installation Launchpad
7.2.4 7.2.4
Tivoli Service
Automation Manager
for WebSphere
Application Server
(optional)
7.2.4 7.2.4
Tivoli Service Request Manager for Service Providers
Tivoli Service Request
Manager
7.2.0 with Fix
Pack 1 (7.2.0.1)
7.2.0 with Fix
Pack 1 (7.2.0.1)
A previous installation of Service Request Manager
without Tivoli Provisioning Manager can be used. In
this case, the middleware and base services were
installed with Service Request Manager.
Tivoli Provisioning Manager
Tivoli Provisioning
Manager
7.2.1 7.2.1 A previous installation of Tivoli Provisioning Manager
can be used. In this case, the middleware and base
services were installed with Tivoli Provisioning
Manager.
Tivoli Provisioning
Manager
Interim Fix 3 Interim Fix 3
Advanced Workflow Components
Advanced Workflow
Components
7.3.0.3 7.3.0.3 Delivered in the Tivoli Service Automation Manager
package.
IBM Tivoli Monitoring (optional)
IBM Tivoli Monitoring
(optional)
6.2.1 or 6.2.2 6.2.1 or 6.2.2 Must be installed separately.
IBM Tivoli Monitoring
for AIX (optional)
6.2.1 or 6.2.2 6.2.1 or 6.2.2 Must be installed separately.
Base Services
36 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 11. Summary of software in the Tivoli Service Automation Manager environment (continued)
Software Component
Version (new
installation)
Version
(updated) Remarks
Base services 7.1.1.9 7.1.1.8 This component is included with Tivoli Provisioning
Manager.
Middleware (included with Tivoli Provisioning Manager)
Tivoli Directory Server
(LDAP)
6.3.0.0 6.1.0.10, 6.2.0.2 When you are using new installation of Tivoli Service
Automation Manager, use version 6.1.0.10 on AIX 5.3.
DB2 9.7 FP4 9.5 FP3a To install DB2, you need at least 512 MB RAM.
Note: Tivoli Service Automation Manager version
7.2.4.3 supports the upgrade to DB2 9.7 fix pack 4.
WebSphere Application
Server Network
Deployment
6.1.0.37 6.1.0.23 When you are using new installation of Tivoli Service
Automation Manager, use version 6.1.0.29 on SUSE
Linux 11.
Note: Tivoli Service Automation Manager version
7.2.4.3 supports the migration to WebSphere Application
Server 7 fix pack 27.
IBM HTTP Server 6.1.0.37 6.1.0.23 When you are using new installation of Tivoli Service
Automation Manager, use version 6.1.0.29 on SUSE
Linux 11.
Self-service user
interface
External Software
Tivoli Usage and
Accounting Manager
7.1 or higher 7.1 or higher Note: This product is not installed with Tivoli Service
Automation Manager. Tivoli Service Automation
Manager provides an interface to an external Usage and
Accounting Manager server.
Web browser for
Installation Launchpad
As supported
by the
Common
Launchpad
initiative
As supported
by the
Common
Launchpad
initiative
The browser must be installed on the server on which
the launchpad is started to install the software.
Refer to the Release Notes
, Restrictions and
limitations on page 44 the Tivoli Provisioning Manager
Installation Guide, and other update information for
browser restrictions or differences between the browser
products.
Web browser for
self-service user
interface
v Microsoft
Internet
Explorer 8
and 9
v Mozilla
Firefox 10
ESR
(Extended
Support
Release)
v Mozilla
Firefox 10 or
higher
v Microsoft
Internet
Explorer 8
and 9
v Mozilla
Firefox 10
ESR
(Extended
Support
Release), 17
ESR, 24 ESR
v Mozilla
Firefox 10 or
higher
The browser can be installed on any system with access
to the application server of the management system.
Note: Microsoft Silverlight must be installed if Internet
Explorer 7 is used. For more information, see the User's
Guide.
Refer to the Release Notes, Restrictions and
limitations on page 44 the Tivoli Provisioning Manager
Installation Guide, and other update information for
browser restrictions or differences between the browser
products.
Chapter 2. Installing and upgrading 37
Table 11. Summary of software in the Tivoli Service Automation Manager environment (continued)
Software Component
Version (new
installation)
Version
(updated) Remarks
Web browser for
administrative user
interface
The browser can be installed on any system with access
to the application server of the management system.
Refer to the Release Notes, Restrictions and
limitations on page 44 the Tivoli Provisioning Manager
Installation Guide, and other update information for
browser restrictions or differences between the browser
products.
Tivoli Remote
Execution and Access
Required for secure communication within the network,
which includes the administrative server and
management system. It is also employed for
communication between Tivoli Service Automation
Manager and Usage and Accounting Manager.
This software does not require separate installation.
Tivoli Provisioning Manager
This product provides support for provisioning services within Tivoli Service
Automation Manager. The Tivoli Provisioning Manager installation media also
include the base services and middleware components, if they were not already
installed.
Note: Be sure to study the documentation for the applicable Tivoli Provisioning
Manager release regarding requirements placed on other components in the
Provisioning Manager environment. For example, for Tivoli Provisioning Manager
the command-line prompt for the root user must end with #, $, or >.
Base services
The Tivoli Provisioning Manager product includes base services, which are shared
services required for provisioning, process automation, and service management
functions. These services are also used by other components, such as Tivoli Service
Automation Manager and Tivoli Service Request Manager. The base services are a
short name for Tivoli's process automation engine.
Middleware components
In the Tivoli Service Automation Manager environment, the Tivoli Provisioning
Manager product serves as the source for the middleware in support of the
provisioning and process automation functions if Service Request Manager is not
already installed.
Tivoli Service Request Manager
Tivoli Service Request Manager provides the framework for Tivoli Service
Automation Manager that enables the user to define service offerings and issue
requests for virtual server provisioning and management.
38 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
IBM Tivoli Monitoring
This optional product provides server monitoring services for the Tivoli Service
Automation Manager-managed environment. IBM Tivoli Monitoring comprises:
Tivoli Enterprise Monitoring Server
Collects information from and controls monitoring agents that collect
availability data and alerts from operating systems and applications.
Tivoli Enterprise Portal Server
Analyzes and pre-formats data collected from the monitoring agents and
then routes the data to clients for presentation in views.
Tivoli Enterprise Portal
Presents data from monitoring agents in graphical and tabular views. The
monitoring agents supported are:
v Linux OS agent
v UNIX OS agent
v AIX Premium agent
Note: Tivoli Monitoring is implemented differently and for different purposes in
the WebSphere Cluster service and Self-Service Virtual Server Management
component.
Tivoli Remote Execution and Access
Tivoli Service Automation Manager uses this product to contact other systems and
run commands and scripts on the remote system.
Managed environments
v System z (z/VM Linux)
v System x (VMware)
v System x (Xen)
v System x (KVM)
v System p (PowerVM)
v System p (PowerVM via VMControl)
Packages
See the individual package requirements sections in the on preparing the
management servers.
Web browser settings
Tivoli Service Automation Manager supports a number of web browsers for the
management of the self-service and the administrative user interfaces.
Make sure that you meet the browser requirements for Tivoli Service Automation
Manager:
v Use one of the supported browsers:
Microsoft Internet Explorer 8, 9, and 10
Mozilla Firefox 17 ESR, 18 ESR, 24 ESR (Extended Support Release)
Note: Tivoli Service Automation Manager supports only ESR versions of
Mozilla Firefox.
Chapter 2. Installing and upgrading 39
Google Chrome 27 (27.0.1453.94 m)
v Install Microsoft Silverlight when using Internet Explorer.
v Enable native XMLHTTP support when using Internet Explorer. In the browser
toolbar, click Tools > Internet Options > Advanced and select the Enable native
XMLHTTP support check box.
v Enable JavaScript, CSS, SSL, and cookies.
v Set your browser resolution to a minimum of 1024x768.
Refer to the Release Notes, Restrictions and limitations, and other update
information for browser restrictions or differences between the browser products.
Requirements for Self-Service Virtual Server Management
This section describes special requirements for the Self-Service Virtual Server
Management functionality.
v For VMware:
Tivoli Service Automation Manager requires a vCenter Server 2.5 U4 (also
known as Virtual Center) implementation. Tivoli Service Automation Manager
employs workflows that require VMware templates, which are available only
in the Virtual Center. Certain minimum build levels of the VMware software
apply if you are using Windows Server 2008 as a managed-environment
operating system.
On each VMware template guest operating system that is used for
provisioning by Tivoli Service Automation Manager, VMware Tools must be
installed.
For Red Hat Enterprise Linux (RHEL) VMware templates ,the
resize2fs executable file version 1.39 or higher must be installed to be able
to use the disk resize function. This levelcheck is performed by the
Cloud_Linux_Online_Configure_Disks workflow. If the provisioned server
has a resize2fs version that is lower than 1.39, the workflow copies the file
from the repository to that server. If the file is not in the repository (it is not
by default), you will not be able to modify disk size on that server.
v For System z:
See Requirements for the System z environment for information related to
provisioning virtual servers (as z/VM guests) on System z.
For more information, see Chapter 2, Installing and upgrading Tivoli Service
Automation Manager, on page 27.
Requirements for the System z environment
This section describes special requirements for System z environment.
Restriction:
v Setting up the System z master provisioning environment is part of the Tivoli
Service Automation Manager deployment phase. This environment must be
operational before Self-Service Virtual Server Provisioning can be used to
provision Linux-based System z servers. For detailed instructions on configuring
z/VM, creating the Linux master images, and networking options, refer to
Configuring the z/VM environment for Tivoli Service Automation Manager on
page 151.
See also Requirements for Self-Service Virtual Server Management for specific
requirements related to Self-Service Virtual Server Management.
40 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Linux is the only operating system available for provisioning of z/VM guests
via the Self-Service Virtual Server Management offerings.
See also Restrictions and limitations on page 44.
Software requirements for the z/VM host platform:
v z/VM 5.4
v DirMaint
v RACF (optional)
v for MAPSERVE : SUSE 10 SP2
System z virtual servers:
A System z virtual server is a z/VM guest with virtual direct access storage
devices (DASD), also referred to as disks, and network interfaces. This server is
represented in the Tivoli Provisioning Manager DCM and is associated with a
z/VM virtual guest name.
Virtual servers are created during Tivoli Service Automation Manager provisioning
by Provisioning Manager using the Tivoli Service Automation Manager Cloud
Management Subsystem. Before this process is started, a master System z
provisioning environment must be established, comprising:
v z/VM host platform(s)
v Linux on System z master images
v Boot server
v Network
v Virtual server templates
v DASD resources
v NIC resources
Each z/VM host platform has the following components:
v MAPSERVE guest ID on which the Tivoli Service Automation Manager
IBM-System-z-MAPSERVE package runs. This package includes an RPC client
that communicates with the RPC server (VSMSERVE)
v VSMSERVE guest ID (RPC server)
v DIRMAINT guest ID
v Linux master images
v Linux guests provisioned by Tivoli Service Automation Manager
In order to provision System z software on a z/VM host platform, the Tivoli
Service Automation Manager management server must communicate with the host
platform on the management network. During service instantiation, the OS
administrator selects a host platform from a list of predefined platforms. The
provisioning process then creates a new z/VM virtual guest on the selected host
platform and clones a software image on the DASD attached to the newly
provisioned guest. Performance requirements imposed by the application workload
must be considered when selecting a host platform for provisioning.
The Tivoli Service Automation Manager and other system administrators are
responsible for setting up a host platform, MAPSERVE and VSMSERVE guest IDs,
MASTER images, Vswitches, management, and a customer network and the
associated components.
Chapter 2. Installing and upgrading 41
Once the MAPSERVE guest ID is configured, the MAPSERVE RPM that is
packaged with the Tivoli Service Automation Manager product must be installed
on the MAPSERVE guest.
For further information see Configuring the z/VM environment for Tivoli Service
Automation Manager on page 151.
Providing the installation source files
This topic describes how to prepare the installation source files for Tivoli Service
Automation Manager and its prerequisites on various operating system platforms.
You can install the software directly from the product CD or DVD or download it
from Passport Advantage at http://www.ibm.com/software/howtobuy/
passportadvantage/pao_customers.htm. Fix packs can be downloaded from Fix
Central at http://www.ibm.com/support/fixcentral/. You specify the location of
the CD or DVD or the source directory for all required packages in the Tivoli
Service Automation Manager launchpad. Any software package must be made
available on the appropriate management or administrative server on which the
launchpad is started for that particular step in the process.
Note:
v The sizes of some of the files to be downloaded to the prospective management
server could exceed limits imposed by the operating system for that server. For
example, the default maximum file size for AIX is 1 GB.
v Ensure that any packages or programs that are required to extract downloaded
files have been installed beforehand. See the packages section for that particular
management server operating system.
v The path names for the downloaded files must contain only alphanumeric
characters or an underscore. Spaces or plus signs, for example, are not
permitted.
The Tivoli Service Automation Manager Installation Launchpad starts one or more
times on a combination of servers, depending on the scenario. In each case, the
server must have access to the source files that pertain to that environment.
Software installed from the administrative server is installed primarily on the
provisioning server of the management system (which is ultimately the Tivoli Service
Automation Manager management server). Some software deployment information
is recorded on the administrative server for subsequent component installations.
Therefore, this same administrative server must be used for any such installations.
However, the administrative server is not required for normal operation.
The table shows which steps apply to which server and which source package is
used on that server:
42 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 12. Installation steps and servers on which the corresponding installation files must be available
Step
DVD or CD, or
downloaded files
Administrative
server
Management system
Provisioning
server (Tivoli
Service
Automation
Manager
management
server) Database server Directory server
Middleware Tivoli
Provisioning
Manager 7.2
Middleware
X X X
Base services Tivoli
Provisioning
Manager 7.2.1
Installation
X
Tivoli
Provisioning
Manager core
components
Tivoli
Provisioning
Manager 7.2.1
core components
X
Tivoli
Provisioning
Manager 7.2.1
iFix 5 core
components
Tivoli
Provisioning
Manager 7.2.1
iFix 5 core
components
X
Tivoli
Provisioning
Manager Web
components
Tivoli
Provisioning
Manager 7.2.1
Installation
X
Tivoli
Provisioning
Manager 7.2.1
iFix 5 Web
components
Tivoli
Provisioning
Manager 7.2.1
iFix 5 Web
components
X
Advanced
Workflow
Components
Advanced
Workflow
Components
X
Service Request
Manager
Tivoli Service
Request Manager
for Service
Providers 7.2
X
Tivoli Service
Automation
Manager
Tivoli Service
Automation
Manager 7.2.4.4
base
X X
Tivoli Service
Automation
Manager for
WebSphere
Application
Server
Tivoli Service
Automation
Manager for
WebSphere
Application
Server 7.2.4.4
X
In the Tivoli Service Automation Manager Installation Launchpad, navigate to
Installation Planning > Installation Files to specify the locations where you
Chapter 2. Installing and upgrading 43
placed all the required installation packages. You must unpack the source packages
or have the DVDs available:
v For Tivoli Provisioning Manager base product:
UNIX
: TPM_V721_Install_Unix.tar, TPM_V721_CoreComp_1of2_Unix.tar,
and TPM_V721_CoreComp_2of2_Unix.tar.
Windows
: TPM_V721_Install_Win.zip.
v For middleware:
TPM_V720_Midlwr_<os>.tar, where <os> is the OS of your management server:
AIXPPC64, LinuxX64, or zLinux64.
v For Tivoli Provisioning Manager for Images: CI0D2ML.tar (optional component).
v For Tivoli Provisioning Manager 7.2.1 iFix 4:
7.2.1.0-TIV-TPM-Multi-IF00004.zip
Windows
7.2.1.0-TIV-Components-Windows-IF00004.zip
Linux
7.2.1.0-TIV-Components-Linux-IF00004.tar
Linux
System z: 7.2.1.0-TIV-Components-zLinux-IF00004.tar
AIX
7.2.1.0-TIV-Components-AIXPPC64-IF00004.zip
Note: Unpack the -Components- packages into the tpm_core subdirectory in
the same location where the -Multi- part was unpacked.
v For Service Request Manager for Service Providers: Either the location on the
DVD or where you unpacked TSRMfSP_V720.tar.
v For Service Request Manager Fix Pack: 7.2.0.1-TIV-SRM-FP0001.zip.
Note: The Tivoli Service Automation Manager DVD is required to start the
Installation Launchpad on all systems.
Restrictions and limitations
The following restrictions and limitations apply to Tivoli Service Automation
Manager:
v System z virtual server provisioning is done in a strictly z/VM environment.
Tivoli Service Automation Manager does not provision native LPARs on System
z. Operating systems are provisioned only on z/VM virtual guests, not native
LPARs. Self-Service Virtual Server Provisioning requires Linux as the z/VM
guest operating system.
v The maximum length of a service deployment instance name (and hence also a
deployment project name within the Self-Service Virtual Server Management
component) is 30 characters.
v Software resource template names for Tivoli Service Automation Manager DCM
entries cannot contain a forward slash character ("/"). This character is used
internally as a separator.
v See Self-Service Virtual Server Management on page 2 for platform restrictions
that apply to Self-Service Virtual Server Management.
v Use Windows platforms as managed-environment operating systems.
v The Backup and Restore functions in the self-service user interface (also referred
to as Save Image and Restore Image) are not currently available for servers in
Xen or z/VM managed environments.
44 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Tivoli Service Automation Manager assumes that a disk on the z/VM hypervisor
(DASD 3390 Model 9) has exactly 10017 cylinders. This means that the minidisk
pool must be configured with disk volumes that can hold at least 10017
cylinders.
v When immediately removing both servers from a project that only contains two
servers, requests are accepted at first but the second one results in an error
because a project cannot exist with no servers. This error is a result of a race
condition and occurs because the first service is still queued when the second
one is submitted and Tivoli Service Automation Manager is unable to recognize
that the second service should not be accepted.
v Timezones of the database server and the WebSphere server must be consistent
if they run on different nodes. Otherwise, service requests will fail.
v Tivoli Service Automation Manager does not support the configuration when
any Virtual Center object, such as a Cluster or Data Center, is defined inside a
sub-folder.
v Tivoli Service Automation Manager does not support the discovery of the
already existing virtual machines provisioned out of band. If the virtual
machines are to be managed by Tivoli Service Automation Manager, they must
be provisioned by means of Tivoli Service Automation Manager, for example by
using self-service user interface or API.
v It is highly recommended to use separate data stores for provisioning of virtual
servers and for storing saved images and image templates. The space occupied
by saved images is not considered for available storage capacity calculation
during resource checking.
Installing Tivoli Service Automation Manager
Refer to this section for instructions on how to install a new instance of Tivoli
Service Automation Manager.
Full Installation of Tivoli Service Automation Manager 7.2.4.4
Tivoli Service Automation Manager supports three installation scenarios. Each of
these scenarios can be divided into three phases.
Three basic installation scenarios are supported:
v New installation in which no software has been previously installed.
v Installation using an existing Tivoli Provisioning Manager 7.2.1, in which only
Service Request Manager and Tivoli Service Automation Manager are installed.
v Installation using an existing Service Request Manager 7.2.0.1, in which only
Tivoli Provisioning Manager and Tivoli Service Automation Manager are
installed.
The following table summarizes the process steps involved in each of these
scenarios:
Table 13. Installation scenarios
Installation Scenario
Installation segment New installation
Existing Tivoli
Provisioning
Manager 7.2
Existing Service
Request Manager
7.2.0.1
Install middleware X
Install base services X
Chapter 2. Installing and upgrading 45
Table 13. Installation scenarios (continued)
Installation Scenario
Installation segment New installation
Existing Tivoli
Provisioning
Manager 7.2
Existing Service
Request Manager
7.2.0.1
Install Tivoli
Provisioning
Manager Core
X X
Install Tivoli
Provisioning
Manager Web
X X
Install Tivoli
Provisioning
Manager for Images
X X
Install Service
Request Manager 7.2
X X
Install Service
Request Manager 7.2
Hot fix 7
X X X
Install Service
Request Manager
Runbook Automation
(RBA) 7.3.0.4
X X X
Install Tivoli Service
Automation Manager
Applications
X X X
Install Tivoli Service
Automation Manager
enablement keys
X X X
Install additional
configuration files
X X X
Install automation
packages
X X X
Install Tivoli Service
Automation Manager
for WebSphere
Application Server
(optional)
X X X
Installation process flow:
Tivoli Service Automation Manager is installed in three basic phases:
1. Planning and pre-installation phase:
a. Verifying the overall installation prerequisites
b. Downloading selected software (or using an installation CD or DVD) to the
administrative and management servers. See Providing the installation
source files on page 42
c. Defining whether the current server will be used as administrative server or
management server. See Preparing the environment for installation on
page 48.
46 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
d. Preparing the management and administrative servers for the installation.
See
v Preparing an AIX management server on page 48
v Preparing a Linux management server on page 58
v Preparing a Windows administrative server on page 66
v Preparing a Linux administrative server on page 66
You also use the Installation Launchpad to run scripts that verify that
prerequisite packages have been installed and other system environment
settings have been performed to allow proper installation.
See Preparing the environment for installation on page 48.
2. Installation phase:
a. In accordance with the selected management system topology, installing the
software on each applicable server in the management system by starting
the Tivoli Service Automation Manager Installation Launchpad on that
server, and installing selected platform-independent software components
by starting the Launchpad on the administrative server.
This process is divided into installation segments, in which each segment is
performed by starting the Launchpad on either the administrative server or
one of the management system servers. The order in which the Launchpad
is started on which server must be made (that is, what server a particular
step must be performed on) is determined by the software design. The
segments involve some switching between the administrative and
management servers. See Installing Tivoli Service Automation Manager
and its prerequisite software on page 68.
In addition to the base Tivoli Service Automation Manager software and its
prerequisites, certain optional components can be installed depending on
environment.
Note: When the installation steps are performed on the administrative
server, the software is installed primarily on the management system.
Although the administrative server is not required in the runtime
environment, some software and control information is retained on the
administrative server for later use.
See Installing Tivoli Service Automation Manager and its prerequisite
software on page 68.
3. Post-installation phase:
a. Setting up the basic interfaces between Tivoli Service Automation Manager,
Tivoli Provisioning Manager, Service Request Manager, and Tivoli Process
Automation engine
b. Verifying that the basic Tivoli Process Automation engine environment is
operational.
c. Configuring the managed environments for the Tivoli Service Automation
Manager services that apply to your installation and making this
information available to Tivoli Provisioning Manager
d. Configuring the Tivoli Service Automation Manager interfaces to external
products
See Post-installation steps on page 82 and the configuration chapter for the
applicable virtualization environment.
Chapter 2. Installing and upgrading 47
Preparing the environment for installation
Perform these steps before starting the installation.
Procedure
1. Review the topology descriptions and hardware requirements in Planning for
Tivoli Service Automation Manager on page 28. Read the Tivoli Provisioning
Manager Installation Guide and the supplementary release notes for Tivoli
Provisioning Manager and Service Automation Manager. Tivoli Service
Automation Manager supports a subset of the Provisioning Manager
environments.
2. Define whether you want to use the current system as a management server, an
administrative server, or both. Different installation options on the product
installation page are offered depending on your selection.
Note: The check boxes are enabled or disabled depending on the installed
operating system. For example, you can use a Windows system only as an
administrative system and a System z system as a management system. If the
current operating system is not supported for a selection, the corresponding
check box is disabled.
3. Ensure that the installation source files for Tivoli Service Automation Manager,
Tivoli Provisioning Manager, and Service Request Manager are available on a
CD or DVD or on the system on which the launchpad is started for each
individual step (see Providing the installation source files on page 42).
4. Prepare the management system servers.
Note: When you run the hostname command on the management server, ensure
that the output contains the fully qualified domain name as configured on your
DNS server and is the same after reboot (that is, mytsamserver.mydomain.com).
5. Prepare the administrative server.
What to do next
Each of these steps is described in more detail in the sections that follow. When
you complete these steps, proceed to Installing Tivoli Service Automation
Manager and its prerequisite software on page 68).
Preparing an AIX management server
Note: See the Tivoli Provisioning Manager Installation Guide for details.
Make sure that you have sufficient disk space for the installation. See Hardware
and operating system requirements for Tivoli Service Automation Manager on
page 28.
Important: Make sure that the date and time on the management server is set
correctly, so that the Tivoli Service Automation Manager scheduler performs a
reservation for the same time frame that the user reserves a project.
48 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Verifying settings required for installing the middleware on an AIX
management server:
Note: The Installation Launchpad can start a script that verifies the following
settings prior to starting the installation. If the Launchpad reports a discrepancy,
resolve the problem before continuing.
Refer to the Tivoli Provisioning Manager Installation Guide and release notes for
Tivoli Provisioning Manager and Tivoli Service Automation Manager for details
and updated information.
User limits:
The number of files must be at least 8192. Other limit categories must be set to
unlimited.
For the Installation Launchpad script to be able to verify settings prior to starting
the installation, the AIX limits file must look like this:
default:
fsize = -1
core = 2097151
cpu = -1
data = 262144
rss = 65536
stack = 65536
nofiles = 2000
ctginst1:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
root:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
nofiles = -1
Set the maximum number of processes per user to 2048 or higher:
1. Run the following command:
smit chgsys
2. Ensure that the value for Maximum number of PROCESSES is set to 2048 or
higher by running the command smitty chgsys and set the value of
PROCESSES allowed per user to 2048.
Enable asynchronous I/O
Note: This step is required only for AIX 5.3. In AIX 6.1, it is enabled by default.
Execute the following commands to enable asynchronous I/O:
chdev -l aio0 -P -a autoconfig=available
mkdev -l aio0
lsdev -F status -t aio
Chapter 2. Installing and upgrading 49
lsdev -F status -t aio must return the following:
root@myserver ~# lsdev -F status -t aio
Available
If this is not successful, use the smitty utility:
smitty chgaio
and
smitty aio (Configure Defined Asynchronous I/O)
to change the I/O settings.
Note: On AIX 6.1 TL 4, the command export JAVA_COMPILER=none must be run
before starting the middleware installer.
Verification
The Installation Launchpad can start a verification script that checks the
requirements for the middleware. Resolve any discrepancies noted and rerun the
script until no errors are reported.
1. On the provisioning server of the management system, start the Tivoli Service
Automation Manager Installation Launchpad as described in Starting the
launchpad and performing the preinstallation steps on page 67.
2. Navigate to Pre-Installation Steps > Requirements for installing the
middleware and click the link.
3. In each case, the script reports any errors found. Resolve any problems
reported.
4. Run the script again until no errors are found.
Verifying the settings required to install Tivoli Provisioning Manager on an AIX
management server:
Use this task to verify that the settings on the AIX management server are correct.
Note: The Installation Launchpad provides for invoking a script to verify the
following settings prior to starting the installation. If the Launchpad reports a
discrepancy, resolve the problem before continuing.
Refer to the Tivoli Provisioning Manager Installation Guide and release notes for
Provisioning Manager and Service Automation Manager for details and updated
information.
Checking the root password:
Ensure that the root password for the management server does not contain any
special characters such as "&". An "&" in the root password can cause the
installation process to fail.
Checking the root shell prompt:
The last non-blank character of the command line prompt for the root user must be
$, #, or > on Tivoli Provisioning Manager. Edit the '.profile' file in root's home
directory, adding or changing the line: export PS1="# " (a hash mark followed by a
space). See Hardware and operating system requirements for Tivoli Service
Automation Manager on page 28.
50 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Updating the login script:
The default login shell on AIX is the Korn shell (ksh), and the default login script
is the file .profile in the home directory of the user name. Even if the login shell
is changed, the profile file may still be the login script. Ensure that you know
which login script is used for the root user on your management server so that you
apply the required changes to the correct script.
Verifying operating system requirements:
Ensure that you are using a supported operating system at the correct version level
(for details, refer to Planning for Tivoli Service Automation Manager on page
28).
Verify the following information:
1. Check the operating system version with the following command:
oslevel -r
Returned value for AIX 5.3 TL10:
5300-10
Returned value for AIX 6.1 TL3:
6100-03
2. Verify that the computer has a 64-bit CPU with the command:
prtconf -c
The output for a 64-bit CPU is:
CPU Type: 64-bit
Increasing file system size:
If you find that a file system is too small for Tivoli Service Automation Manager,
use the smitty utility to increase the size:
1. Log on as root.
2. Execute smitty storage
3. Select File Systems.
4. Select Add / Change / Show / Delete File Systems.
5. Select Enhanced Journaled File Systems
6. Select Change / Show Characteristics of an Enhanced Journaled File System.
7. Select the file system name from the list and press Enter.
8. Enter the new size in the Number of units field. The size is expressed as a
number of 512 byte units.
9. Press Enter and then F10 to exit smitty.
Increasing AIX file size limit and number of descriptors
Edit the file /etc/security/limits and complete these required steps, which are
essential to correct installation. In the example, ctginst1 is used as the name of the
database instance user.
1. Edit the /etc/security/limits file by opening it in a text editor.
2. Locate the section for the ctginst1 and root user, and then make changes to the
parameters below using the values listed:
Chapter 2. Installing and upgrading 51
ctginst1:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
root:
fsize = -1
cpu = -1
data = -1
rss = -1
stack = -1
stack_hard = -1
nofiles = 8192
A value of -1 indicates that there is no limit.
Note: Always add a break between the root section and the sections before
and after it.
3. Save the file and exit.
Important: You must reboot the system for these changes to take effect.
Increasing AIX paging space:
Increase the paging space to a minimum of 4 GB, but preferably to the total
amount of physical memory. To determine the size of the physical memory, enter:
root@myserver # bootinfo -r
The following sample output shows that the amount of physical memory (in units
of 1 KB) is 8 GB:
8388608
To list the available paging space, enter:
root@myserver # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
hd6 hdisk1 rootvg 4096MB 1 yes yes lv
To add paging space:
root@myserver # chps -s 32 hd6
which adds 32 logical partitions to the paging space. The default logical partition
size is 128 MB. Add 8 logical partitions for each GB of paging space.
root@myserver # lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
hd6 hdisk1 rootvg 8092MB 1 yes yes lv
The paging space is now 8 GB.
The number of logical partitions that need to be added as paging space depends
on the size of a logical partition. To determine the size of a logical partition, run
the following command:
lslv hd6
52 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Calculate the number of logical partitions that need to be added to reach the
desired amount of paging space based on the previous numbers: (available
physical memory - current amount of paging space) / (size of physical partition).
To add more logical partitions, use the following command:
chps -s xx yyy
where xx is the number of logical partitions to add and yyy identifies the logical
volume.
Changing umask for root
Note: This value is only valid during installation. When installation is complete,
reset it to its original value. If necessary, record the existing value by entering
'umask' with no arguments.
Execute the command:
chuser umask=0022 root
Alternatively, you can set the umask with smitty:
To change the umask setting to 0022 using SMIT on AIX, perform the following
steps:
1. Log on as root.
2. Run the following command from a shell prompt:
smitty user
3. Select Change/Show Characteristics of a User.
4. Enter root in the User NAME field.
5. Press Enter.
6. Scroll down and find File creation UMASK and change the value to 0022.
7. Press Enter to save the changes.
8. Exit smitty interface.
9. Log off and log back in for the changes to take effect.
Setting the home for root user
usermod -d /home/root root
Ensure that the value for Maximum number of PROCESSES is set to 2048 or higher
by using the command smitty chgsys.
Ensure fully qualified (long) host name.
The hostname command must return the fully qualified host name, not just the
short host name.
The following example shows the use of an incorrect host name:
root@myserver ~# hostname
myserver
If only the short host name is returned, set the host name using smitty hostname
or the following commands:
Chapter 2. Installing and upgrading 53
root@myserver ~# chdev -l inet0 -a hostname=myserver.mycompany.com
inet0 changed
The following example shows the use of a correct host name
root@myserver ~# hostname
myserver.mycompany.com
root@myserver ~# /usr/sbin/hostid `hostname`
The DNS server should also return the same long host name as returned by the
hostname command:
root@myserver ~# nslookup `hostname`
Server: ips-boeb-a.mycompany.com
Address: 9.152.120.241
Name: myserver.mycompany.com
Address: 9.152.26.115
Modifying /etc/hosts
If you are using the file /etc/hosts to resolve IP addresses, the file must be
configured correctly.
The file must include:
v The IP address, fully-qualified domain name, and host name of this management
server as the first entry.
v The IP address 127.0.0.1, with loopback as the domain name and localhost as
the host name.
The following example shows settings for a computer with the host name myserver.
# Internet Address Hostname # Comments
9.152.21.28 myserver.mycompany.com myserver
127.0.0.1 loopback localhost # loopback (lo0) name/address
Note: AIX installations differentiate between the IP address for the localhost host
name and the actual host name of the computer. Ensure that your /etc/hosts file
includes the static IP address for both localhost and the actual host name of the
computer.
Important: You must first define the real IP address and then the local host IP
address (127.0.0.1).
Permit SSH root login:
Ensure that the PermitRootLogin option is enabled (uncommented and set to yes)
in the /etc/ssh/sshd_config file.
Setting file permissions for /tmp and /var/tmp
Ensure that the file permissions are 1777:
chmod 1777 /tmp
chmod 1777 /var/tmp
Enabling the WebSphere Application Server SOAP port
Ensure that the WebSphere SOAP port (default 8879) can be reached from the
administrative server by switching off the firewall on the provisioning server.
54 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Verification
The Installation Launchpad provides for invoking a verification script to check the
previously described operating system settings. Resolve any discrepancies noted
and rerun the script until no errors are reported.
1. On the provisioning server of the management system (the Tivoli Service
Automation Manager management server), start the Tivoli Service Automation
Manager Installation Launchpad as described in Starting the launchpad and
performing the preinstallation steps on page 67.
2. To check the operating system prerequisites, navigate to Pre-Installation Steps
> Requirements for installing Tivoli Provisioning Manager and click the link.
3. In each case, the script reports any errors found. Resolve the problems
reported.
4. Run the script again until no errors are reported.
Packages required on an AIX management server:
You must install certain packages and software components before installing Tivoli
Service Automation Manager.
Note: The Installation Launchpad provides for invoking a script to verify package
installation before starting the installation. If the Launchpad reports a discrepancy,
resolve the problem before continuing.
For details and updated information, see Tivoli Provisioning Manager Installation
Guide and the release notes for this product and Tivoli Service Automation
Manager.
The following packages and other software must be installed:
v bash 3
If you use bash 4, downgrade to bash 3.
v bash-doc
v bos.loc.iso.en_US
v cairo 1.0.2-6
v curl
v expect (5.42 or higher) (expect.base for AIX 6.1)
v GNU tar (1.14 or higher) (in addition to UNIX tar)
v glib
v gtk2 2.8.3 or higher
v openssh (5.0.0.5301 or higher)
v openssl
v perl 5.8.2
v procmail (available in the Linux Toolbox for AIX)
v tcl (tcl.base for AIX 6.1)
v tk (tk.base for AIX 6.1)
v unzip
v wget 1.9
v xlC.rte version 9
v xlC.rte.9.0.0.1
v xlC.aix61.rte.10.0.0.2
v X11.base
v X11.apps
v X11.adt
v zip
Chapter 2. Installing and upgrading 55
v xterm (the path is/usr/bin/X11/xterm)
Note: For more information about the packages, see the Tivoli Provisioning
Manager documentation (Tivoli Provisioning Manager knowledge center >
Preinstallation tasks > Step 5: Verify component requirements > Required packages (UNIX
and Linux).
You can obtain packages from the AIX toolbox download site:
http://www.ibm.com/systems/p/os/aix/linux/toolbox/download.html. In
addition, certain packages must be accessible using specific paths.
Note: The unzip version offered at this download site cannot handle the .zip files
larger than 2 GB. Use another program to extract files larger than 2 GB.
Web browsers
To learn about supported browsers, refer to Web browser settings on page 39.
Installing bash-doc
root@myserver / # rpm -Uvh <path_to_updates>/bash-doc-3.0-1.aix5.1.ppc.rpm
bash-doc-3.0-1
Installing expect 5.4x.x
If expect is not installed, install it using the following command:
root@myserver # rpm -Uvh <path_to_updates>/expect-5.42.1-3.aix5.1.ppc.rpm
expect-5.42.1-3
If there are problems with dependencies, the command will generate the following
result:
root@myserver # rpm -Uvh <path_to_updates>/expect-5.42.1-3.aix5.1.ppc.rpm
error: failed dependencies:
libtcl8.4.so is needed by expect-5.42.1-3
libtk8.4.so is needed by expect-5.42.1-3
If there is a problem with dependencies, also update the dependencies TCL and TK
and reissue the command:
root@myserver / # rpm -Uvh --force --nodeps
<path_to_updates>/tcl-8.4.7-3.aix5.1.ppc.rpm
tcl ##################################################
root@myserver / # rpm -Uvh --force --nodeps
<path_to_updates>tk-8.4.7-3.aix5.1.ppc.rpm
tk ##################################################
(now reissue the command)
root@myserver / # rpm -Uvh
<path_to_updates>expect-5.42.1-3.aix5.1.ppc.rpm
expect ##################################################
Installing the GNU tar utility
The native UNIX tar utility does not support long file names. Ensure that the latest
GNU version of tar (gtar) is installed so that installation files can be extracted. You
can use the following commands to check that gtar is installed and which version
it is:
which gtar
gtar --version
If the GNU tar package is not installed, follow these steps:
56 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
1. Download the GNU tar package from http://www.ibm.com/systems/p/os/
aix/linux/toolbox/download.html.
2. Ensure that the GNU tar is in the PATH variable of /etc/environment.
Note: The native UNIX tar utility must also be available.
Checking the xlC* packages
To check if the C/C++ runtime library is installed use lslpp -l xlC*.
root@myserver ~# lslpp -l xlC*
Fileset Level State Description
----------------------------------------------------------------------------
Path: /usr/lib/objrepos
xlC.aix50.rte 9.0.0.1 COMMITTED XL C/C++ Runtime for AIX 5.x
xlC.cpp 9.0.0.0 COMMITTED C for AIX Preprocessor
xlC.msg.EN_US.cpp 9.0.0.0 COMMITTED C for AIX Preprocessor
Messages--U.S. English UTF
xlC.msg.EN_US.rte 9.0.0.0 COMMITTED C Set ++ Runtime
Messages--U.S. English UTF
xlC.rte 9.0.0.1 COMMITTED XL C/C++ Runtime
xlC.aix50.rte and xlC.rte must be available and must have a version > 6.0.
Note: For AIX 6.1, the package name is xlC.aix61.rte
Package path requirements
Some utilities are required by Tivoli Provisioning Manager and must be available
from the following locations:
v bash: /bin/bash
v expect, tar, gzip: /usr/bin
If they are not installed in these locations, create a symbolic link from those
directories to the actual location.
1. Check whether bash is available at /bin/bash:
root@myserver ~# ls -l /bin/bash
lrwxrwxrwx 1 root system 27 Sep 4 15:25 /bin/bash@ -> ../../opt/freeware/bin/bash*
root@myserver ~# echo $?
0
2. Ensure that the "shells" line in /etc/security/login.cfg points to /bin/bash
and not /usr/bin/bash. If both /usr/bin/bash and /bin/bash are in the shells
line, remove /usr/bin/bash from it.
3. Define /bin/bash as the default shell for user root:
a. Enter smitty user
b. Select Change / Show Characteristics of a User
c. Enter the user name root
d. Ensure that Initial PROGRAM is /bin/bash.
4. Check that expect and gzip are accessible from /usr/bin:
root@myserver # ls -l /usr/bin/expect
lrwxrwxrwx 1 root system 29 Sep 4 15:25 /usr/bin/expect@ -> ../../opt/freeware/bin/expect*
root@myserver # echo $?
0
root@myserver # ls -l /usr/bin/gzip
lrwxrwxrwx 1 root system 27 Sep 4 15:25 /usr/bin/gzip@ -> ../../opt/freeware/bin/gzip*
root@myserver # echo $?
0
5. Verify that GNU tar is in the environment path. Ensure that the PATH variable
contains both the native UNIX tar and GNU tar paths, and that the native
UNIX tar path is defined before the GNU tar path. For example:
Chapter 2. Installing and upgrading 57
PATH=/usr/bin:/opt/freeware/bin/:/etc:/usr/sbin:
/usr/ucb:/usr/bin/X11:/sbin:/usr/java14/jre/bin:/usr/java14/bin
Verifying that the required software packages are installed
You can check the installation of individual packages with the lslpp command. For
example, to check the 'expect' package, enter lslpp -L expect*.
To verify that all packages are installed, run a script from the Launchpad:
1. On the provisioning server of the management system (the Tivoli Service
Automation Manager management server), start the Tivoli Service Automation
Manager Installation Launchpad as described in Starting the launchpad and
performing the preinstallation steps on page 67.
2. Navigate to Pre-Installation Steps > Pre-requisite packages for Tivoli
Provisioning Manager
3. Click the link to run the verification script for the required packages. Error
messages are issued if any discrepancies are noted.
4. Install any package reported as missing or at an incorrect level.
5. Run the script again until all errors have been resolved.
Note: The script can only make general decisions about whether a required
package is installed. It cannot always determine the version of a package.
Successful execution of the script does not necessarily mean that the version of an
existing package is the correct one. The user must verity that the correct package
has been installed.
Preparing a Linux management server
Note: Unless otherwise noted, this section applies generally to Linux on System x
and Linux on System z and to the Red Hat and SUSE distributions. Differences are
noted where applicable.
Refer to the Tivoli Provisioning Manager Installation Guide and the release notes for
Tivoli Provisioning Manager and Tivoli Service Automation Manager for details.
Make sure that you have sufficient disk space for the installation. See Hardware
and operating system requirements for Tivoli Service Automation Manager on
page 28.
Important:
v Make sure that the date and time on the management server is set correctly, so
that the Tivoli Service Automation Manager scheduler performs a reservation for
the same time frame that the user reserves a project.
v Make sure that the correct umask value is set up. The umask value can be set for
all users either in /etc/bashrc file or in /etc/profile file. By default, most
Linux distributions set it to 0022 (022) or 0002 (002). To change the umask value:
1. Open /etc/profile or /.bashrc file
2. Enter:# vi /etc/profile or $ vi /.bashrc
3. To set up a new umask value, add or modify the following line: umask 022
4. Logout from the shell.
58 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Verifying the settings required to install the middleware on a Linux
management server:
This section describes operating system settings that are required to install the
middleware on a Linux management server.
Note: The Installation Launchpad provides for invoking a script to verify the
following settings before starting the installation. If the Launchpad reports a
discrepancy, resolve the problem before continuing.
Refer to the Tivoli Provisioning Manager Installation Guide and the release notes for
Tivoli Provisioning Manager and Tivoli Service Automation Manager for details
and updated information.
Set LD_LIBRARY_PATH for zLinux: Set the LD_LIBRARY_PATH variable:
LD_LIBRARY_PATH=/usr/lib
Modify kernel parameters for DB2: You can find the kernel parameters using the
appropriate commands, for example:
Free memory
# free -o -b
total used free shared buffers cached
Mem: 10432819200 10371768320 61050880 0 77840384 9825697792
Swap: 21476163584 0 21476163584
The following values must be set:
v kernel.shmmax=physical memory in bytes
v kernel.shmall=twice the memory in bytes as required by DB2
v kernel.msgmax=65536
v kernel.msgmnb=65536
For more details on these settings refer to the DB2 documentation.
After setting the kernel parameters, run the following command, so that the new
settings take effect:
/sbin/sysctl -p
Set user limits: To set the user limits:
1. Log on as root.
2. Edit the file /etc/security/limits.conf. When a limit is not specifically
configured for a user, the default value is used. The default is typically
unlimited for all the required limits except stack size.
a. Remove any existing entries for ctginst1 so that the default limits are
assigned. Ensure that the default limits are set to unlimited.
b. To change the stack size to the maximum value for ctginst1 and root, add
the following entries to the file:
ctginst1 - stack unlimited
root - stack unlimited
c. Set the limit for open file descriptors to 65536 or higher for the root user,
add the following entry to the file:
root - nofile 65536
3. For SUSE Linux Enterprise Server 11, add the following values to /etc/profile:
Chapter 2. Installing and upgrading 59
ulimit -v unlimited
ulimit -m unlimited
4. Log out as root and log back in for the changes to take effect.
5. If DB2 is already installed, restart the database instance by running the
following commands:
su - dasusr1 -c "db2admin start"
su - ctginst1 -c "db2start"
6. Verify the system resource limit settings by running the following command:
ulimit -a
Verify the settings: The Installation Launchpad provides for invoking a verification
script to check the requirements for installing the middleware.
1. On the provisioning server of the management system, invoke the Installation
Launchpad as described in Starting the launchpad and performing the
preinstallation steps on page 67
2. To check the middleware prerequisites, navigate to Pre-Installation Steps >
Requirements for installing the middleware and click the link.
3. Resolve any discrepancies noted and rerun the script checks until no errors are
reported.
Verifying the settings required to install Tivoli Provisioning Manager on a Linux
management server:
This section describes certain operating system settings needed to install Tivoli
Provisioning Manager.
Note: The Installation Launchpad can start scripts that verify the following
settings prior to starting the installation. If the Launchpad reports a discrepancy,
resolve the problem before continuing.
Refer to the Tivoli Provisioning Manager Installation Guide and the Tivoli
Provisioning Manager and Tivoli Service Automation Manager release notes for
details and updated information.
Check the root password:
Ensure that the root password for the management server does not contain any
special characters such as "&". An "&" in the root password can cause the
installation to fail.
Check the root shell prompt:
The last non-blank character of the command line prompt for the root user must be
$, #, or > on Tivoli Provisioning Manager. A suggested prompt is a hash mark
followed by a space. To set the prompt, log on as the root user and add or change
the "export PS1" line in file .profile (AIX) or .bashrc (Linux) to:
export PS1="# "
Log off as root and log back in for these changes to take effect.
60 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Verify operating system requirements
v Red Hat Enterprise Linux distribution
Verify that you have the required release installed:
cat /etc/redhat-release
v SUSE Linux Enterprise Server distribution
Verify that you have the required release installed:
cat /etc/SuSE-release
v libstdc++.so.5
Verify that libstdc++.so.5 is installed.
The middleware installation program requires the libstdc+.so.5 system library to
be present on a Linux system.
[root@myserver ~]# rpm -qal | grep -e "/libstdc++.so.5$"
/usr/lib/libstdc++.so.5
[root@myserver ~]# ls -l /usr/lib/libstdc++.so.5
lrwxrwxrwx 1 root root 18 May 15 2008
/usr/lib/libstdc++.so.5 -> libstdc++.so.5.0.7
For SUSE Linux Enterprise Server 10 Service Pack 3, ensure that you have both
the 64 and the 32-bit version of libstdc++.so.5 installed. Run the following
commands to verify that:
ls -la /usr/lib/libstdc++.so.5
ls -la /usr/lib64/libstdc++.so.5
v Kernel version
Version 2.6 of the kernel is required. Run the following command to verify the
kernel version:
uname -r
The output must begin with "2.6". For example:
[root@myserver ~]# uname -r
2.6.9-67.ELsmp
Ensure fully qualified (long) host name
On the management server, the host name must be fully qualified. If it is not, run
the following command as root to set it to a fully qualified name (replacing
myserver.mycompany.com accordingly):
hostname myserver.mycompany.com
Modify /etc/hosts
If you are using the file /etc/hosts to resolve hostnames to IP addresses, the file
must be configured correctly. Even if you are not using /etc/hosts to resolve
hostnames, it is recommended that your /etc/hosts file be configured as follows to
avoid errors reported by the pre-installation check utility.
The file must include:
v The IP address, fully-qualified domain name, and host name of this management
server as the first entry.
v The IP address 127.0.0.1, with loopback as the domain name and localhost as
the host name
The following example shows settings for a computer with the host name myserver.
Chapter 2. Installing and upgrading 61
# Internet Address Hostname # Comments
9.152.27.78 myserver.mycompany.com myserver
127.0.0.1 loopback localhost # loopback (lo0) name/address
Important: You must first define the real IP address and then the local host IP
address (127.0.0.1).
Disable /tmp cleanup (tmpwatch and anacron)
By default, the tmpwatch script runs daily and removes files in /tmp that have not
been accessed in 10 days. The anacron scheduler also runs scripts in
etc/cron.daily when the computer is booted. By default, the Tivoli Provisioning
Manager installer is installed under /tmp.
Before you start Tivoli Provisioning Manager installation, ensure that the
automated cleanup of /tmp is disabled for the duration of the installation. Check
/etc/crontab and /etc/anacrontab to determine whether scripts in /etc/cron.daily
are called. If so, either delete or relocate the tmpwatch (RHEL) or
suse.de-clean-tmp (SUSE) file, or comment out the applicable entries in the file:
v (Red Hat) Edit the /etc/cron.daily/tmpwatch script and comment out the lines
that perform the cleanup of /tmp.
v (SUSE) Edit file /etc/cron.daily/suse.de-clean-tmp and comment out the
following lines:
# cleanup_tmp ${MAX_DAYS_IN_TMP:-0} ${TMP_DIRS_TO_CLEAR:-/tmp}
# cleanup_tmp ${MAX_DAYS_IN_LONG_TMP:-0} ${LONG_TMP_DIRS_TO_CLEAR}
Example:
#/usr/sbin/tmpwatch -x /tmp/.X11-unix -x /tmp/.XIM-unix -x /tmp/.font-unix
-x /tmp/.ICE-unix -x /tmp/.Test-unix 240 /tmp
#/usr/sbin/tmpwatch 720 /var/tmp
#for d in /var/{cache/man,catman}/{cat?,X11R6/cat?,local/cat?}; do
# if [ -d "$d" ]; then
# /usr/sbin/tmpwatch -f 720 $d
# fi
#done
Note: The verification script reports an error if the file exists. If you retain the files
but comment out the entries that are applicable to /tmp cleanup, you can ignore
the script error message.
Start xinetd
The xinetd daemon must be running. Check whether it is running:
# ps -ef | grep xinetd | grep -v grep
root 4928 1 0 14:23 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
If necessary, start it with the command:
# /etc/init.d/xinetd start
If it does not start, try to do the following:
[root@myserver ~]# rcxinetd restart
Shutting down xinetd: done
Starting INET services. (xinetd) failed
If it still does not start, enable any service, for example echo.
62 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
To do this, edit /etc/xinetd.d/echo and set the property disable to no:
# default: off
# description: An echo server. This is the tcp version.
service echo
{
type = INTERNAL
id = echo-stream
socket_type = stream
protocol = tcp
user = root
wait = no
disable = no
}
Start xinetd again:
[root@myserver ~]# /etc/init.d/xinetd start
Starting INET services. (xinetd) done
Verify that the xinetd process exists:
[root@myserver ~]# ps -ef | grep xinetd | grep -v grep
root 17262 1 0 13:52 ? 00:00:00 /usr/sbin/xinetd
Permit SSH root login:
By default, SSH is permitted for root. Ensure that the PermitRootLogin option is
enabled (uncomment and set to yes, or commented out to start the default) in the
/etc/ssh/sshd_config file.
Set file permissions for /tmp and /var/tmp
Ensure that the file permissions are 1777:
chmod 1777 /tmp
chmod 1777 /var/tmp
Enable the WebSphere Application Server SOAP port
Ensure that the WebSphere SOAP port (default 8879) can be reached from the
administrative server. To do so, switch the firewall on the management server off,
for example:
chkconfig -level 2345 iptables off
service iptables save
service iptables stop
Swap space:
Swap space should be at least twice the amount of memory. Run this command to
check the swap space and memory size:
# free -o -b
total used free shared buffers cached
Mem: 10432819200 10371768320 61050880 0 77840384 9825697792
Swap: 21476163584 0 21476163584
Verification:
Chapter 2. Installing and upgrading 63
The Installation Launchpad can start a verification script that checks the above
settings. Resolve any discrepancies noted and rerun the script until no errors are
reported.
1. On the provisioning server of the management system, start the Tivoli Service
Automation Manager Installation Launchpad as described in Starting the
launchpad and performing the preinstallation steps on page 67
2. Navigate to Pre-Installation Steps > Requirements for installing Tivoli
Provisioning Manager and click the link.
3. Resolve any discrepancies noted and run the script checks again until no errors
are reported.
Packages required on a Linux management server:
This section identifies the packages that are needed on a Linux management server.
Some of the packages must be accessible using a specific path. A script can be run
from the Installation Launchpad to verify that all packages have been installed.
Note: The information about the versions of the packages is available in the Tivoli
Provisioning Manager documentation. For more details, see Tivoli Provisioning
Manager knowledge center > Preinstallation tasks > Step 5: Verify component
requirements > Required packages (UNIX and Linux). The following three packages are
specific for Tivoli Service Automation Manager: libXaw, procmail, xterm.
Table 14. Required packages for Linux management servers
Package Remarks
compat-db-4.1.25-9 RHEL only. For RHEL 5, the 32-bit and the
64-bit versions are required.
compat-libstdc++ No longer available. Use libstdc++ for 32 and 64
bit.
curl
expect 5.42 or later
ftp
gtk
ksh RHEL 6.x only
libaio
libstdc++
libXaw 32bit-version RHEL 5.5 only
libXmu Not required for Linux on System x
libXp Linux on System z only
libXpm RHEL only
ncftp SLES only
openssh
perl
procmail
rpm-build-4.3.3-22 RHEL only
tcl
telnet
tk
64 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 14. Required packages for Linux management servers (continued)
Package Remarks
wget
xorg-x11-xfs RHEL only
xorg-x11-font-utils RHEL only
xterm For Linux, the required path for xterm is
/usr/bin/xterm.
Verify that all required software packages are installed:
1. On the provisioning server of the management system, start the Tivoli Service
Automation Manager Installation Launchpad as described in Starting the
launchpad and performing the preinstallation steps on page 67.
2. Navigate to Pre-Installation Steps > Prerequisite packages for Tivoli
Provisioning Manager Click the link to run the verification script for required
packages, which indicates any packages that are missing or at the wrong level.
Error messages are issued if any discrepancies are noted.
3. Install any package reported as missing or at an incorrect level.
4. Run the script again until no discrepancies are reported.
You can also run the rpm -ivh command to install any packages that are missing
or that are at an incorrect level. For example:
# pwd
/media/SUSE-Linux-Enterprise-Server_001/suse/x86_64
# ls | grep expect
expect-5.43.0-16.4.164.x86_64.rpm
# rpm -ivh expect-5.43.0-16.4.164.x86_64.rpm
Preparing... ########################################### [100%]
1:expect ########################################### [100%]
#
Note: The script can only make general decisions about whether a required
package is installed. Successful execution of the script does not mean that the
version of an existing package is the correct one. This is supposed to be verified by
the user.
Package path requirements
Some packages must be available from certain locations:
v bash: /bin/bash
v expect, tar, gzip: /usr/bin
If they are not installed in these locations, create a symbolic link from those
directories to the actual location.
myserver:~ # cd /usr/bin
myserver:/usr/bin # ls -l tar
~/bin/ls: tar: No such file or directory
myserver:/usr/bin # ln -s /bin/tar tar
myserver:/usr/bin # ls -l tar
lrwxrwxrwx 1 root root 8 Oct 30 17:48 tar -> /bin/tar
myserver:/usr/bin # ls -l expect
-rwxr-xr-x 1 root root 11145 Jul 1 2004 expect
myserver:/usr/bin # ls -l gzip
lrwxrwxrwx 1 root root 9 Jun 12 16:58 gzip -> /bin/gzip
Chapter 2. Installing and upgrading 65
Preparing a Windows administrative server
An administrative server is needed to install components of Tivoli Provisioning
Manager, Service Automation Manager, and Service Request Manager. The
administrative server used to install the base services must also be used to install
other components that require an administrative server.
A Windows administrative server is also required if the management server cannot
also serve as the administrative server.
Note: If the installation is not performed using the product CD or DVD, the
installation files for the steps that require starting the launchpad on the
administrative server must be downloaded to the administrative server before
beginning installation.
Setting up the host name (computer name):
1. Open a Windows command prompt.
2. Enter hostname and press Enter.
3. If the host name of the computer is reported in the <localhost>.<localdomain>
format, it is configured correctly.
Setting up the hosts file:
If your environment does not use a name server to resolve host names to IP
addresses, but rather relies on the /etc/hosts file for name resolution, you must
enable local host name resolution of the administrative server and target
management server host names on the administrative server. To do so, edit file
C:\Windows\system32\drivers\etc\hosts file and add entries for both the
administrative and target management servers. Ensure that the loopback entry
exists and that it comes after the administrative server entry. Be sure to press Enter
after the last line of the file.
Example:
192.168.1.100 tsam-admin-server.mycompany.com tsam-admin-server
127.0.0.1 loopback host.domain localhost
192.168.1.101 tsam-mgmt-server.mycompany.com tsam-mgmt-server
Preparing a Linux administrative server
Components packaged for a Linux-based installation require a Linux
administrative server. A Linux administrative server can be co-located with a Linux
management server if the hardware and software requirements are met.
Important: Before installing Tivoli
V5,
64-bit Support (C88TJML).
WebSphere Application Server Network Deployment V6.1 Supplements for
AIX 5L V5, 64-bit Support (C88TMML).
2. Switch to the Tivoli Provisioning Manager user tioadmin. Run the command:
su - tioadmin
3. Install the IBM-Http-Server.tcdriver file:
a. Obtain the file from OPAL (Open Process Automation Library) at
http://www-01.ibm.com/software/brandcatalog/portal/opal/
results?catalog.searchTerms=&catalog.c=Tivoli+Provisioning+Manager.
b. Copy the file to $TIO_HOME/drivers.
c. Install the file by running the command:
$TIO_HOME/tools/tc-driver-manager.sh installDriver IBM-Http-Server
For detailed information on using the tc-driver-manager command, refer to
the Information Center for the Tivoli Provisioning Manager.
4. Install IBM-TSAM.tcdriver. Skip this section if you have already installed the
IBM-TSAM.tcdriver. To install IBM-TSAM.tcdriver:
a. Locate the IBM-TSAM.tcdriver file at /opt/IBM/TSAM/tc-driver/IBM-TSAM on
the Tivoli Service Automation Manager management server.
b. Copy the file to $TIO_HOME/drivers.
c. Run the following command: .
$TIO_HOME/tools/tc-driver-manager.sh installDriver IBM-TSAM
For detailed information on using the tc-driver-manager command, refer to
the Tivoli Provisioning Manager information center.
5. Customize the file WAS_repository_Template.xml according to your setup:
a. Rename the sample file in $TIO_HOME/repository/IBM-TSAM/samples/
DCMTemplates/WAS_repository_Template.xml.
b. Assign a name for the file repository server.
c. Assign the IP address and netmask of the file repository server.
d. Assign the credentials requested to access the repository server.
6. Customize the file WAS_HTTP_software_module.xml according to your setup:
a. Rename the sample file in $TIO_HOME/repository/IBM-TSAM/samples/
DCMTemplates/WAS_HTTP_software_module.xml.
b. Assign the name of the file repository server.
c. Assign the name and path of each software module where the installable
can be found.
Note: The specification of a software module for Linux on System z (intended
for a virtual server provisioned in the self-service user interface) must include
the following software requirement entry:
246 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
<software-requirement name="platform.architecture" type="HARDWARE" enforcement="MANDATORY" hosting="false" accept-non-existing="true">
<software-requirement-value value="390" />
<software-requirement-value value="s390" />
</software-requirement>
Ensure that the corresponding host platform server specification includes:
<resource name="Platform" resource-type="platform" managed="true" partitionable="false">
<property component="KANAHA" name="platform.architecture" value="390" />
</resource>
7. Import the customized XML files by running the command:
$TIO_HOME/tools/xmlimport.sh file:filename, where filename is the name of
your XML file. For detailed information about using the xmlimport command,
see the information center for Tivoli Provisioning Manager.
8. When logged on to Tivoli Provisioning Manager, delete the software module
IBM WebSphere Application Server 6.1:
a. Click Go To > IT Infrastructure > Software Catalog > Software Products.
b. Search for the IBM WebSphere Application Server 6.1 software module and
delete it.
9. Restart the Tivoli Provisioning Manager server.
Configuring and running discovery on a Tivoli Provisioning
Manager server
Learn how to configure and run discovery on a Tivoli Provisioning Manager
server. This task makes the managed environment available to Tivoli Provisioning
Manager.
Procedure
1. Run the Initial Discovery:
a. Log on to the administrative user interface.
b. Click Go To > Discovery > Provisioning Discovery > Discovery
Configurations.
c. Filter for and open Initial Discovery.
d. Click New Row on the Computers tab and add the host name of the server
that you want to discover. Alternatively, click New Row on the IP Address
Ranges tab and add the IP address ranges of your managed servers.
e. Click New Row on the Credentials tab and add your credentials to access
the managed servers.
f. Click Run Discovery.
g. Confirm that you want to run this discovery by clicking Submit. The flow
takes you to the Provisioning Task Tracking application, where you can
monitor the success of the discovery. Wait for completion.
2. After the Initial Discovery has successfully run, run the Tivoli Provisioning
Manager Inventory Discovery:
a. Log on to the administrative user interface.
b. Click Go To > Discovery > Provisioning Discovery > Discovery
Configurations.
c. Filter for and open Tivoli Provisioning Manager Inventory Discovery.
d. Check both Hardware and Software boxes, and select Use software
signatures.
e. Click Run Discovery. A pop-up window appears.
Chapter 3. Configuring 247
f. Confirm that you want to run this discovery by clicking Submit. The flow
takes you to the Provisioning Task Tracking application, where you can
monitor the success of the discovery. Wait for completion.
g. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning
Computer.
h. Select the discovered computer and check the details tab to view the details
(such as hardware resources) for the computer that is the target of the
discovery.
Defining configuration items for the WebSphere Cluster
Service
This section describes how to define configuration items to be used by the
WebSphere Cluster Service.
About this task
The WebSphere Cluster service uses authorized configuration items (CIs) in the
process automation database to identify the servers that are to accommodate the
WebSphere ND environment. These CIs have attributes that are typically found in
the SYS.COMPUTERSYSTEM classification, but another classification name can be
assigned.
Note: This function was previously done automatically by the Tivoli Service
Automation Manager Data Loader for Tivoli Provisioning Manager, which is no
longer provided with Tivoli Service Automation Manager.
The following table lists the required classification attributes for servers:
Table 32. Classification attributes for configuration items to be used by the WebSphere
Cluster Service
Classification Attribute Description
COMPUTERSYSTEM_MEMORYSIZE Total RAM memory size for server. This
attribute is used for filtering in the resource
allocation records and can be adapted there.
COMPUTERSYSTEM_FQDN Fully qualified domain name of the server.
This attribute is used in the Script Adapter
to establish SSH connections to the server.
COMPUTERSYSTEM_NAME Name of the server as defined in Tivoli
Provisioning Manager. This attribute is used
to get the DCM ID of the server to invoke
Tivoli Provisioning Manager workflows.
COMPUTERSYSTEM_ARCHITECTURE Name of the architecture for the server. This
attribute is used for filtering in the resource
allocation records and can be adapted there.
Configuration items must be generated manually after the initial Tivoli
Provisioning Manager discovery process (which enters the server into the DCM)
and when the DCM has been updated. Use the Configuration Items application of
the administrative user interface is used to define the CIs. To do that:
Procedure
1. Log on to the administrative user interface.
2. Click Go To > IT Infrastructure > Configuration Items.
248 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
3. Click the New CI button.
4. Enter a name for the configuration item.
5. Enter the classification IT\SYS.COMPUTERSYSTEM in the classification field.
6. In the Alphanumeric Value field of the corresponding attribute in the
specifications table, enter at least one of the required attributes listed in table
Table 32 on page 248.
Processor Pool planning
System p provides a new capability that is called processor pools for Power 6 and
Standard Edition of PowerVM. This feature is primarily used for license
management and further partitioning of a CEC.
It covers the following aspects:
v Cloud Server Pool Administration Application is enhanced to enable processor
pool support for a Cloud Pool of type LPAR.
v Processor Pool Discovery is triggered from the Cloud Server Pool Administration
application.
v Provisioning of LPARs into a specified processor pool.
v Placement and resource checks during provisioning are enhanced to check if the
LPAR can be provisioned on the specified CEC within the specified processor
pool.
v New VSRPARM properties included in the Service Request for processor pool.
The processor pool support has the following assumptions:
v At least a Power 6 CEC with PowerVM Enterprise edition is required.
v The LPAR on the processor pool is independent of its power state.
v There is no support for the processor pool reserved processor unit attribute.
v There is no web 2.0 support for processor pools.
v The deployment is done only with SAN Storage.
v The processor pool support is enabled on a per cloud pool base.
v The resource check is done on Tivoli Provisioning Manager deployment level.
Processor pools are not accepted in Reservation or are treated as sub pools
during reservation.
v There is only a basic discovery support. The CECs in the Cloud Pool are
updated with processor pool information.
v There is a VSRPARM parameter to use the processor pool through REST API
only.
v There is a new discovery extension point available, which is callable from the
CSPA (Cloud Server Pool Administration Application) to enable customer
extension for discovery. The extension point contains an OOTB implementation
to do a CEC level Discovery.
v The processor pools must be defined on all CECs within the cloud pool. If not
done, it results in deployment errors.
v Modify server resources is not supported for LPARs that are in a processor
pool.
v No processor pools support from the web 2.0 UI.
Chapter 3. Configuring 249
Processor pool configuration in the backend
The processor pools must be set up on the CECs within a cloud pool before you
run the discovery of the processor pool. Setup of the processor pools on the CECs
must be done through HMC. The processor pools must be defined on all the CECs
within a cloud pool.
Processor Pool configuration in the Cloud Server Pool
Administration Application
Enablement of Processor Pool support is done within the Cloud Server Pool
Administration Application on a per cloud pool base. You can enable Processor
Pool support in the Host Platform and VIOS Configuration tab only for SAN
storage. You can trigger the processor pool discovery from the Processor Pool
Settings tab. All CECs must be added to the cloud pool before theprocessor pool
discovery is run.
Procedure
1. Go to Cloud Server Pool Administration > Cloud Server Pool Details tab.
2. In the Resource Configuration section, go to Host Platform and VIOS
Configuration tab.
3. In the Hostplatform Features section, select SAN Storage/Multiple VIOS
Mode.
4. Select Enable Processor Pools? When you enable the processor pools, the
Processor Pool Settings tab is available.
Note: In the Processor Pool Settings tab, the value of Processor Pool
Discovery Workflow Name is preset to "pSeries_DiscoverProcessorPools".
5. Click Processor Pool Discovery to start the asynchronous workflow.
6. Wait for the process to complete.
Important: If you change the processor pool definitions on a CEC, then the
processor pool discovery must be executed to reflect the changes in the data
center model (DCM). If a HMC discovery is executed for a cloud pool that has
processor pool enabled, then it is required to run the processor pool discovery
before you enable the cloud pool.
Service request parameters for processor pool support
A new property is introduced to specify the processor pool that the LPAR must be
provisioned to - PMRDP.SystemP.CPU.Shared_proc_pool_name .
The value of this property must be set to the name of the processor pool. The
srctype of this property must be VST. The property must be stored in the
VSRPARM section of the Service Request.
VSRPARM properties to set are as follows:
v SRCATTRNAME = PMRDP.SystemP.CPU.Shared_proc_pool_name
v SRCTYPE = VST
v SRCTOKEN = 0
v SRCATTRVAL = <name of the processor pool>
250 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
VST properties
The following properties in the VSRPARM must be set if
PMRDP.SystemP.CPU.Shared_proc_pool_name is set and the cloud pool is enabled for
Processor Pool support:
v SRCATTRNAME = PMRDP.SystemP.CPU.Sharing_mode
v SRCTYPE = VST
v SRCTOKEN = 0
v SRCATTRVAL = Constant string with either cap or uncap. If not set
uncap is the default.
v SRCATTRNAME = PMRDP.SystemP.CPU Uncap_weight
v SRCTYPE = VST
v SRCTOKEN = 0
v SRCATTRVAL = Integer with the uncap weight ( 0-255). If not set default
is 128
Example form to set VSRPARM:
!-- Example for PMRDPVSRPARM values created and filled during SR creation -->
!-- sets the PMRDP.SystemP.CPU.Shared_proc_pool_name
variable in the VST to the value mypool -->
VSRPARM.1.DESCRIPTION
input name="PMRDPVSRPARM.1.DESCRIPTION"
value="Processor Pool Name" type="text">p/>
VSRPARM.1.SRCTOKEN
input name="PMRDPVSRPARM.1.SRCTOKEN"
value="0" type="text">p/>
VSRPARM.1.SRCTYPE
input name="PMRDPVSRPARM.1.SRCTYPE" value="VST" type="text">p/>
VSRPARM.1.SRCATTRNAME
input name="PMRDPVSRPARM.1.SRCATTRNAME"
value=" PMRDP.SystemP.CPU.Shared_proc_pool_name" type="text">p/>
VSRPARM.1.SRCATTRVAL
input name="PMRDPVSRPARM.1.SRCATTRVAL" value="0" type="mypool">p/>
Advanced configuration settings
Learn about the optional and additional configuration settings that you can set in
your environment.
Reducing the run time of provisioning requests
You can reduce the run time of your provisioning requests to prevent them from
staying in the 'Queued' status for a long time.
About this task
Tivoli Service Automation Manager uses an algorithm to place virtual machines on
the defined host platforms in a resource pool. The algorithm helps to find an
optimal placement in context of the resources available in the resource pool. All
open provisioning requests take part in this optimization process. This includes
future reservations and active provisioning requests still waiting to be fulfilled.
Chapter 3. Configuring 251
Normally the process is run in a short timeframe but in rare situations it might
take considerably more time. Such situations are dependent on the resources that
are still available in the resource pool and on the kind of requests submitted. If
such behavior occurs, you can reduce the run time of the algorithm:
Procedure
1. Add the PMRDP.Fitting.Spray.Basic.MaxDepth parameter as a variable to the
Tivoli Provisioning Manager spare pool. By default, this parameter is not set
and its default value is 4.
2. Set the value of this parameter to less than 4 to reduce the run time of the
placement. Do not increase the value to more than 4.
Results
Setting the value to less than 4 reduces the time of the placement but the
placement process is not as optimal as originally.
Overcommitting resources on VMware hypervisor
The VMware hypervisor provides the capability to allocate more CPU, memory,
and storage resources to the virtual machines than physically available on the
hypervisor machines. This functionality is supported in Tivoli Service Automation
Manager with overcommit factors. Physical resources on the VMware cluster are
multiplied by the overcommit factor, and the reservation system permits to allocate
to the virtual machines more resources than physically available.
About this task
Overcommitting resources allows for more cost-effective usage of the cloud at the
cost of lower performance on the virtual machines.
For more information about the capabilities and strategies for overcommitting
resources on VMware, refer to the VMware Resource Management Guide available at
http://www.vmware.com/pdf/vi3_301_201_resource_mgmt.pdf.
Note: Changing the overcommit factors takes effect after the Virtual Center
Discovery was run in the Cloud Server Pool Application. Only the newly
provisioned virtual machines are affected. All existing virtual machines continue to
consume the resources as configured at the time of the last Modify Resources
request, or, if this request was not submitted, the last provisioning operation.
Overcommitting CPU
You can configure the system to assign more CPU to a VMware virtual machine
than is physically available on the hypervisor.
Procedure
1. Log on to the administrative user interface as user maxadmin.
2. Click Go To > Service Automation > Configuration > Cloud Server Pool
Administration.
3. Select the cloud pool that you want to configure.
4. In the Cloud Server Pool Details tab, ensure that the Resource Pool
Configuration sub-tab is open.
5. Verify that a resource pool is configured in the Resource Pool Name field. If it
is not configured, follow the steps described in Manually configuring cloud
server pools for VMware.
252 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
6. If the resource pool is configured, click Detail Menu > Go To Resource
Pools.
7. Open the Variables tab and click New Row.
8. In the Variable field, type: Cloud.overcommitfactor.cpu.
9. In the Value field, enter the required value for the overcommit factor.
10. When all overcommit factors are set up, run a virtual center discovery.
Results
If the Cloud.overcommitfactor.cpu property is not set, a default value of 1.0 is
assumed. When you define this property, the actual CPU value discovered during
the VMware virtual center discovery is multiplied by the overcommit factor to
provide the number of physical CPU that is available for Tivoli Service Automation
Manager virtual machines.
Overcommitting memory
You can configure the system to assign more memory to a VMware virtual
machine than is physically available on the hypervisor.
About this task
If the memory overcommit factor is not set, a default value of 1.0 is assumed. If
the memory reservation overcommit factor is not set, a default value of 0.75 is
assumed. When you increase the memory overcommit factor, you must at the same
time decrease the memory reservation overcommit factor, so that the physical
memory reservation on VMware does not limit provisioning.
Tivoli Service Automation Manager virtual machine provisioning fails if the actual
hardware in the hypervisor is not able to satisfy the request, that is, if the reserved
physical memory for all started virtual machines exceeds 100%. The default
memory reservation factor of 0.75 takes the overhead incurred by the hypervisor
into account. Tivoli Service Automation Manager does not provide a means to
monitor or warn the user about exceeding physical memory. The administrator
must implement an external monitoring infrastructure to avoid such a situation,
and define a process to increase the hardware resources in such situations.
Procedure
1. Log on to the administrative user interface as user maxadmin.
2. Click Go To > Service Automation > Configuration > Cloud Server Pool
Administration.
3. Select the cloud pool that you want to configure.
4. In the Cloud Server Pool Details tab, ensure that the Resource Pool
Configuration sub-tab is open.
5. Verify that a resource pool is configured in the Resource Pool Name field. If it
is not configured, follow the steps described in Manually configuring cloud
server pools for VMware.
6. If the resource pool is configured, click Detail Menu > Go To Resource
Pools.
7. Open the Variables tab and click New Row.
8. In the Variable field, type: Cloud.overcommitfactor.memory.
9. In the Value field, enter the required value for the overcommit factor.
10. Click New Row.
Chapter 3. Configuring 253
11. In the Variable field, type: Cloud.overcommitfactor.memoryreservation.
12. In the Value field, enter the required value for the overcommit factor.
13. When all overcommit factors are set up, run a virtual center discovery.
Results
When you define the Cloud.overcommitfactor.memory property, the actual
discovered hypervisor memory value is multiplied by the memory overcommit
factor to get the amount of memory that is available for Tivoli Service Automation
Manager virtual machine reservation.
When you define the Cloud.overcommitfactor.memoryreservation property, the
memory reservation overcommit factor is multiplied by the requested memory size
for a virtual machine to define the memory reservation value for the VMware
hypervisor. This value is the guaranteed amount of physical memory that VMware
reserves for the virtual machine.
Overcommitting storage
You can configure the system to allocate more storage to the VMware virtual
machine than is physically available on the hypervisor.
Before you begin
Note:
v When you use this functionality, you must manually monitor your storage
consumption to prevent system failures.
v The storage allocation can only be overcommitted when you are using thin
provisioned virtual machines.
Tivoli Service Automation Manager can thin provision virtual machines if the
master image is configured to use thin provisioned disks.
If you use this functionality, you must manually monitor your resources. If the
thin provisioned storage exceeds the available disk space, any new provisioning
request fails. If any existing virtual machines allocate additional storage by writing
new data to their filesystem, these virtual machines stop and they cannot be
accessed any more.
Procedure
1. Log on to the administrative user interface as user maxadmin.
2. Click Go To > Administration > Provisioning > Provisioning Global Settings.
3. Open the Variables tab and click New Row.
4. In the Variable field, type: Cloud.overcommitfactor.disk.
5. In the Value field, enter the required value for the overcommit factor.
6. When all overcommit factors are set up, run a virtual center discovery.
Results
If the Cloud.overcommitfactor.disk property is not set, a default value of 0.90 is
assumed. The value is smaller than 1 to account for overhead that is used for
virtual machine metadata and memory swap files. The actual discovered data store
size value will be multiplied by the overcommit factor to define the amount of
storage that is available for Tivoli Service Automation Manager virtual machine
reservation.
254 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
VMware storage resiliency:
Tivoli Service Automation Manager 7.2.4 validates the current capabilities of the
selected data store when provisioning is run, and corrects the selected data store
when necessary. This function compensates for the out-of-band-operations
performed in the VMware storage environment unknown to Tivoli Service
Automation Manager and that affects both the internal data model and allocation
tracking of Tivoli Service Automation Manager.
When the following formula is activated, it is used to validate disk placement,
regardless of the implemented thin- or thick-disk provisioning:
datastore-capacity Cloud.overcommitfactor.disk >= nominal VM space + Tivoli Service
Automation Manager current provisionings
Note: Nominal VM space: Virtual machine's regular disk space allocated during
thick-disk provisioning.
Depending on the type of provisioning performed by using thin-disk provisioning,
define the Cloud.overcommitfactor.disk parameter.
The VMware storage resiliency function is disabled by default. To enable it, define
the Tivoli Provisioning Manager global variable:
Cloud.ENABLE_VMWARE_STORAGE_RESILIENCY=true
Restriction: VMware storage resiliency function might interfere with high
performance requirements. If you demand high throughput to quickly create a
large number of VMs, switch off this function.
Integrating Tivoli Service Automation Manager with other Tivoli
products
This chapter discusses configuration tasks applying to the interface of Tivoli
Service Automation Manager with other Tivoli products outside the scope of TPAE.
Integrating Tivoli Monitoring
This section discusses configuration tasks applying to the interface of Tivoli Service
Automation Manager with Tivoli Monitoring.
Before you begin
There are two distinct and independent applications for Tivoli Monitoring within
Tivoli Service Automation Manager:
v Self-Service Virtual Server Management component: A Tivoli Monitoring agent
can be installed when a virtual server is provisioned. This agent then reports
resource consumption for the server, such as CPU and memory, in the
self-service user interface.
v WebSphere Cluster service: Definition of performance-related events to be
monitored and triggering respective event monitoring applications to assist the
user in resolving the problems noted.
Chapter 3. Configuring 255
Configuring the provisioning of the monitoring agent
Perform this configuration task to enable Tivoli Service Automation Manager to
deploy the Tivoli Monitoring agent on the provisioned virtual machines.
Before you begin
Ensure you meet the following requirements:
v The Tivoli Monitoring server version 6.2.2, or at minimum 6.2.1, is installed and
running. See theTivoli Monitoring knowledge center to install the server for your
OS and platform.
v You have the following information readily available from the Tivoli Monitoring
server:
The IP address of the server as well as its IP port number (the default is
typically 1918).
The User ID and password of the administrator managing the server.
v In Tivoli Service Automation Manager 7.2.4.4, a 32 bit Tivoli Monitoring agent
must be installed on a 32 bit operation system and 64 bit Tivoli Monitoring
agent must be installed on a 64 bit operating system. If there is a mismatch
between the agent and operating system, then an error occurs - "update
windows registry for TEMS server details".
Preparing the monitoring agent installable:
This task describes how to make the IBM Tivoli Monitoring agent installable
accessible in Tivoli Service Automation Manager.
Procedure
Obtain a copy of the Tivoli Monitoring agent installable for UNIX and Windows
from the IBM Tivoli Monitoring media.
v To prepare the monitoring agent installable for UNIX operating systems:
1. Locate the NFS server and ensure that it belongs to the same subnetwork of
the provisioned virtual machines.
2. Record the IP address and subnetwork mask of this server. (They must
match the settings on the DCM file repository object in the DCM that
represent this NFS server).
3. Copy the Tivoli Monitoring agent installable tar file to a directory on that
NFS server.
4. Create a directory called, for example, /repository on the NFS server, and
export it. (This name should match the root-path property in the DCM file
repository object that represents this NFS server).
5. Create a subdirectory called itm621 and untar the Tivoli Monitoring agent
installable into that directory.
Important: After you untar the monitoring agent installable, you need to
make a change to the install.sh file inside /repository/itm621:
a. Run the following command: cp install.sh install.sh.original.
b. Edit the install.sh and replace while getopts
":h:j:d:o:p:acqv:g(forceCDgskit)" opt with while getopts
":h:j:d:o:p:acqv:g" opt.
c. Save the changes to the file.
256 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v To prepare a Tivoli Service Automation Manager agent installable for Windows
Operating Systems:
1. Locate the Samba server and ensure that it belongs to the same subnetwork
of the provisioned virtual machines.
2. Record the IP address and subnetwork mask of this server. (They must
match the settings on the DCM file repository object in the DCM that
represent this Samba server.
3. Copy the agent installable tar file to a directory on that Samba server.
4. Create a directory called, for example, repository on the Samba server, and
export it with that name. (The export name should match the root-path
property in the DCM file repository object that represents this Samba server).
5. Create a subdirectory named itm621/WINDOWS, and unpack the monitoring
agent installable into that directory.
Defining the Tivoli Monitoring agent software definition in Tivoli Provisioning
Manager:
This task describes how to add an IBM Tivoli Monitoring agent software definition
customized for Tivoli Service Automation Manager to the Tivoli Provisioning
Manager software catalog . It also describes minimal configuration steps required
so that Service Automation Manager can provision the monitoring agent.
Before you begin
Tivoli Service Automation Manager requires a software definition that represents
the monitoring agent with version 6.2.1. Tivoli Service Automation Manager also
requires special customization of the software definition so that it can be deployed
on virtual machines. This procedure describes how to customize and create the
monitoring agent software definition using the Cloud Pool Administration
application and by customizing a DCM XML file provided by the Tivoli Service
Automation Manager installation. The DCM XML files are located in the
/etc/cloud/install/DCM directory on the Service Automation Manager server.
Important: If other monitoring agent definitions already exist in the software
catalog with the name IBM Tivoli Monitoring Agent but do not match the
customization described in this section, then they must be either deleted or
renamed in Tivoli Provisioning Manager. You can view the list of software
definitions by clicking Go To > IT Infrastructure > Software Catalog > Software
Products.
Procedure
1. Depending on whether you are configuring the monitoring agent for one or
more operating systems (AIX, Linux, Windows), choose the appropriate DCM
XML file to edit:
v Windows: 41_Cloud_ITM_Agent_Windows.xml
v Linux: 42_Cloud_ITM_Agent_Linux.xml
v AIX: 43_Cloud_ITM_Agent_AIX.xml
v Multiple OSs: 44_Cloud_ITM_Agent_AIX_Linux_Windows.xml
2. Verify that you have the proper file repositories defined in Tivoli Provisioning
Manager and that they reflect the previously mentioned NFS and Samba
servers.
Chapter 3. Configuring 257
a. To view the defined file repositories, log on to the administrative user
interface as the maxadmin user and list them by clicking Go To > IT
Infrastructure > Provisioning Inventory > File Repositories
b. If you have already configured Tivoli Service Automation Manager for
VMware or PowerVM, then file repositories will already be in the database
defined with the following default names:
v Cloud File Repository for the NFS server
v Cloud Windows File Repository for the Samba server
3. Depending on whether the repositories are already defined in Tivoli
Provisioning Manager or not, perform the appropriate step.
File repository is already defined
Update the IP address and subnetwork mask in the network interface
settings for each repository in Tivoli Provisioning Manager to match
the corresponding NFS and Samba servers you prepared previously.
File repository is not defined
a. In the chosen DCM XML files, customize the section below
according to your environment:
<!--For ITM and other installables package repository. -->
<file-repository name="CloudFileRepository" is-device-model="Cloud File Repository" root-path="/export/backups/repository">
<nic name="NIC0" failed="false" managed="false" management="false" netboot-enabled="false">
<network-interface name="eth0" failed="false" managed="false" management="true" dynamic-ipaddress="false" ipaddress="0.0.0.0"
netmask="0.0.0.0" address-space="DEFAULT" allocation="none"/>
</nic>
</file-repository>
<!--For ITM and other installables package repository. -->
<file-repository name="Cloud Windows File Repository" is-device-model="Cloud File Repository" root-path="repository">
<nic name="NIC0" failed="false" managed="false" management="false" netboot-enabled="false">
<network-interface name="eth0" failed="false" managed="false" management="true" dynamic-ipaddress="false" ipaddress="0.0.0.0"
netmask="0.0.0.0" address-space="DEFAULT" allocation="none"/>
</nic>
<sap name="SMB" protocol-type="unknown" app-protocol="UNKNOWN" context="NOCONTEXT" port="139" auth-compulsory="true" role="host">
<credentials search-key="default" is-default="true">
<password-credentials username="Administrator" password="xxxxxx" is-encrypted="false" />
</credentials>
</sap>
</file-repository>
b. In the file-repository section with name CloudFileRepository,
set the ipaddress, netmask, and root-path to match those of the
NFS server.
c. In the Cloud Windows File Repository section, set the ipaddress,
netmask, root-path, username, and password to match those of
the Samba server
d. Tivoli Provisioning Manager requires that subnetworks must
already exist in the DCM for any IP addresses used in the network
interface of defined objects. If the IP addresses used in the
previous steps belong to an existing subnetwork in Tivoli
Provisioning Manager, proceed to the next step, otherwise, you
need to define a subnetwork. Use either the administrative user
interface to define the subnetwork, or you can define it using the
following XML section. Add the following section to the
previously chosen DCM files right above the file repositories and
customize it for the required subnetwork.
<subnetwork address-space="DEFAULT" name="Subnet for NFS and SMB server"
ipaddress="10.100.0.0" netmask="255.255.255.0">
<property component="KANAHA" name="broadcast" value="10.100.0.255" />
<property component="KANAHA" name="gateway" value="10.100.0.1" />
<property component="KANAHA" name="vm-mgmt-route" value="true" />
</subnetwork>
e. Save the file.
258 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
4. As indicated at the beginning of this task, ensure that there are not any
software definitions in Tivoli Provisioning Manager with the same name as
the software definition described above, specifically IBM Tivoli Monitoring
Agent, otherwise, the next step might fail.
5. Customize the Tivoli Monitoring agent software definition and define it in
Tivoli Provisioning Manager:
a. In the section of type software-resource-template, with name = "ITM
Installation Template - <OS_type>", set the value for the parameters
host and port to match the IP address and port number of the Tivoli
Monitoring server.
b. Save the file.
6. Import the DCM XML file using the Cloud Server Pool Administration
application: Go To > Service Automation > Configuration > Cloud Server
Pool Administration
7. Update the monitoring agent software definition with the Tivoli Provisioning
Manager object ID of all the installable software definitions in Tivoli
Provisioning Manager that represent the operating systems on which the
monitoring agent will be installed.
a. Log on to the administrative user interface as the user maxadmin.
b. Use the Object Finder to look up the object ID of all the software
definitions corresponding to the operating systems with which you want
the monitoring agent to be deployed. Repeat these steps for each software
definition.
1) Click Go To > IT Infrastructure > Image Library > Master Images,
and select the image that you registered.
2) In the Master Image tab, take note of the Guest Operating System and
Software Stack names.
3) From the Start Center, in the Data model object finder portlet, filter
for the name of the Guest Operating System object.
4) Take note of the associated Software Definition object ID.
5) Filter for the name of the Software Stack object.
6) Take note of the associated Software Stack and Image object IDs
c. Click Go To > IT Infrastructure > Software Catalog > Software Products
and select the monitoring agent software definition customized for Tivoli
Service Automation Manager.
d. Click the Variables tab
e. In the Variables section, click the variable named dependencies_1.
f. In the Value field, enter the object IDs (software definition, software stack,
image) determined in the previous step. Separate each value by a comma.
g. Define one more variable named exposetotivsam, with value 1.
h. Click Save.
8. Add the monitoring agent software definition to the software stack associated
to the resource pool that represents the virtual environment for which you
have configured Tivoli Service Automation Manager.
a. Click Go To > IT Infrastructure > Software Catalog > Software Stacks.
b. Click on the appropriate software stack from the list. For example, if you
want the agent to be deployed into a VMware environment configured
with defaults, choose the software stack called ESXPoolStack. For
PowerVM (if supported), choose the default software stack
ODSDS_PPC_host_stack.
Chapter 3. Configuring 259
c. From the Select Action menu, click Add Stack Entry.
d. Search for and select the IBM Tivoli Monitoring Agent from the list.
e. Click Submit.
f. Save the changes.
9. Configure the Tivoli Monitoring server endpoint PMRDPITM:
a. Click:Go To > Integration > Endpoints
b. Search for and select the PMRDPITM endpoint.
c. Set USERNAME and PASSWORD values with the credentials required to
access your Tivoli Monitoring server.
d. Set the value of REQUESTURL to: http://<ITM_Server_Hostname>:1920///
cms/soap
e. Set the value of SOAPTIMEOUT in seconds. Default value is 3600.
f. Click Save.
Note: If you change the end point URL in an operational Tivoli Service
Automation Manager environment, you have to restart the management
server, so that the change works properly in the administrative user interface.
10. Enable monitoring agent installation during provisioning for each of following
offerings:
v PMRDP_0211A_72 (Add VMware Servers)
v PMRDP_0212A_72 (Add POWER LPAR Servers)
v PMRDP_0213A_72 (Add Xen Servers)
v PMRDP_0214A_72 (Add z/VM Linux Servers)
v PMRDP_0215A_72 (Add KVM Servers)
v PMRDP_0201A_72 (Create Project with VMware Servers)
v PMRDP_0202A_72 (Create Project with POWER LPAR Servers)
v PMRDP_0203A_72 (Create Project with Xen Servers)
v PMRDP_0204A_72 (Create Project with z/VM Linux Servers)
v PMRDP_0205A_72 (Create Project with KVM Servers)
v PMRDP_0206A_72 (Create POWER LPAR Servers via IBM Systems Director
VMControl)
v PMRDP_0216A_72 (Add POWER LPAR Servers via IBM Systems Director
VMControl)
a. Log on to the administrative user interface as PMSCADMUSR.
b. Click Go To > Service Request Manager Catalog > Offerings
c. Click on the offering to open it.
d. Click the Change Status button and change the status of the offering to
Pending.
e. Switch to the Specifications tab.
f. In the Presentation section, select the Mandatory check box, and unselect
the Hidden check box, which correspond to the offering attribute
PMRDPCLSWS_MONITORING.
g. Change the status of this offering to Active.
260 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Enabling the monitoring agent installation on restored images:
By default, if a server image was saved, and that server had a monitoring agent
installed on it, you can no longer use the monitoring feature when you restore the
image. If you want the monitoring agent to work on the restored images, you need
to enable the Monitoring agent to be installed check box for the Create Project
from Saved Image and the Add Server from Saved Image offerings.
Procedure
1. Log on to the administrative user interface as PMSCADMUSR.
2. Navigate to Go To > Service Request Manager Catalog > Offerings
3. Filter for Create Project from Saved Image offering and open it.
4. From the Select Action menu, select Change Status.
5. Change the status of the offering to PENDING and click OK.
6. Click the Specification tab.
7. In the Presentation subsection of the Default Presentation Details, filter for
PMRDPCLSWS_MONITORING.
8. Deselect the Hidden check box and select the Mandatory box.
9. Change the status of the offering to ACTIVE.
10. Click Save.
11. Filter for Add Server from Saved Image offering, open it, and repeat the steps
4 to 10.
Results
You can now check the Monitoring agent to be installed check box in the Create
Project from Saved Image and Add Server from Saved Image requests.
Synchronizing data between Tivoli Monitoring and Tivoli Service Automation
Manager:
You can set the frequency in which you can monitor and synchronize data between
Tivoli Monitoring and Tivoli Service Automation Manager. After you install and
configure Tivoli Monitoring, you must activate the cron job to initiate data refresh.
Activate ITMSyncCron cron task and configure its frequency to refresh data. The
synchronized data renders UI values for Manage Project Details and Server Details.
Procedure
1. Go to > System Configuration > Platform Configuration > Cron Task Setup.
2. In Cron Task tab, search for ITMSyncCron.
3. Select Active? to activate monitoring. The default is inactive.
4. Optional: Change the value of Schedule or Time Interval in which the
monitoring activity must take place. The default value is not less than 15
minutes for 300 servers.
Important: Do not set smaller frequency for many virtual machines, as it
impacts performance.
5. Save the record.
6. If you modify the resources of a virtual machine, then restart virtual machine.
Chapter 3. Configuring 261
Important: The recent changes that are made to the virtual machine get
refreshed on the UI only after the next cron task is run.
7. Required: Stop and start the MXServer whenever you change the cron job
schedule:
su - tioadmin
./tio.sh stop wasadmin <wasadmin_password>
./tio.sh start wasadmin <wasadmin_password>
Note: To view the details about the virtual machine usage values, see Viewing
virtual machine usage values.
Viewing virtual machine usage values:
You can view the details of values that are shown in Manage server and other
Tivoli Service Automation Manager UI panels. Alternatively, you can get the values
of CPU, Memory, and Disk from Tivoli Monitoring.
Procedure
View the details of values that are shown in Manage server and other Tivoli
Service Automation Manager UI panels:
1. Log in to Simple SRM.
2. Go to Manage Servers.
Note: In the Resources tab, the capacity values are displayed. The values are
same as the values with which the virtual machine was created. In many UI
panels of Tivoli Service Automation Manager, you can find the following
values:
v CPU(%) - average CPU usage values. CPU corresponds Cpu_Averages of
Tivoli Monitoring.
v Memory(%) - Percentage of Memory that is used as against the total memory
size of the virtual machine. Memory corresponds to Free_Memory of Tivoli
Monitoring.
v Disk(%) - Percentage of Disk that is used as against the total disk size of the
virtual machine. Disk usage corresponds to Space_Available of Tivoli
Monitoring.
View the values of CPU, Memory, and Disk in Tivoli Monitoring:
3. Log in to Tivoli Monitoring Agent.
4. Run SOAP calls to query for available space: Example:
<CT_Get><userid>sysadmin</userid><password></
password><object>ManagedSystem</object><target>ManagedSystemName</
target></CT_Get>
Note: Within the Object tag, you can query for Space_Available (summation of
all the partitions), Free_Memory, Cpu_Averages.
5. Click Make SOAP Request.
Remember: Tivoli Monitoring Server and memory commands show disk usage
per file system in the virtual machine. The Disk(%) values are calculated based
on total disk size that is allocated to the virtual machine and hence there can be
some differences in the values. The templates also determine the number of
filesystems or drives a virtual machine can have.
262 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Configuring monitoring for the WebSphere Cluster service
About this task
The following sections describe tasks related to setting up the function to monitor
performance on deployed service instances of the WebSphere Cluster service.
Setting up predefined Tivoli Service Automation Manager events for
monitoring:
This task describes how you set up the Tivoli Service Automation Manager events
for monitoring, when using WebSphere Cluster service.
Before you begin
Note: This task is relevant only if you have purchased and installed the Tivoli
Service Automation Manager for WebSphere Application Server and IBM Tivoli
Monitoring products.
About this task
Before monitoring agents are deployed along the lines of creating a new service
instance and before scenario-based monitoring can take place, the events defined
for the various scenarios must be set up. The setup must be done on a Linux or
AIX system, where an IBM Tivoli Monitoring server (the hub monitoring server) is
installed. By default, the hub monitoring server is assumed to be installed on the
local host. Alternatively, the events can be defined to a hub monitoring server
running on another host. In any case, the hub monitoring server must be
configured to use SOAP services.
Procedure
1. The script ctjzhCreateSit.sh is installed on the Tivoli Service Automation
Manager management server system in install_dir/bin. The install_dir
defaults to /opt/IBM/TSAM.
2. Execute install_dir/bin/ctjzhCreateSit.sh to setup the predefined events.
Syntax:
ctjzhCreateSit.sh [-u username] [-p password] [-s server]
Meaning:
-u username
Specifies the user to authenticate at the monitoring server. If no
username is passed, the default user sysadmin is assumed without any
password.
-p password
Specifies the password of the user to authenticate at the monitoring
server.
-s server
server is the name of a system where a hub monitoring server is
running. By default, it is assumed that the hub monitoring server is
running on the local host.
Example
The following example creates the product-defined events and defines them at the
monitoring server running on the local host. To authenticate, the user id tstadmin
Chapter 3. Configuring 263
is provided together with the valid password: ctjzhCreateSit.sh -u tstadmin -p
<password>
Deleting events:
About this task
Individual events can be deleted using the script ctjzhDeleteSit.sh. Like
ctjzhCreateSit.sh, it is installed on the Tivoli Service Automation Manager
management server system in install_dir/bin, which defaults to
/opt/IBM/TSAM/bin. A list of all situations defined by the product is provided in
the ctjzhSituations file also located in install_dir/bin.
Syntax:
ctjzhDeleteSit.sh [-u username] [-p password] [-s server]
Meaning:
-u username
Specifies the user to authenticate at the monitoring server. If no username is
passed, the default user sysadmin is assumed without any password.
-p password
Specifies the password of the user to authenticate at the monitoring server.
-s server
server is the name of a system where a hub monitoring server is running.
By default, it is assumed that the hub monitoring server is running on the
local host.
Example
The following example deletes the situation pmzhb_zos_pageds_not_oper currently
being defined at the monitoring server running on the local host. To authenticate,
the user ID tstadmin is provided, together with the valid password:
ctjzhDeleteSit.sh -u tstadmin -p <password> pmzhb_zos_pageds_not_oper
The following example deletes all situations listed in file ctjzhSituations (or any
other file of choice):
for name in `cat ctjzhSituations` do; ctjzhDeleteSit.sh -u tstadmin -p
<password>; done
Enabling the SSH command end point to retrieve IBM Tivoli Monitoring
configuration information:
This task describes how to configure the end point when common performance
monitoring attributes are collected from local definition files.
About this task
When a monitoring definition is created the first time and the hub Tivoli Enterprise
Management Server (TEMS) is installed on the management server, common
performance monitoring attributes can be collected from the local definition files. To
enable this function, the endpoint PMZHBPCFG has to be configured. To configure
the endpoint, you must:
264 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Procedure
1. Click Go To, Integration, and End Points.
2. Select end point PMZHBPCFG.
3. Check the setting of property CMDWORKDIR. You are not required to change
this property unless you installed Tivoli Service Automation Manager to a
non-default location. Otherwise, specify your own install path followed by
/bin.
4. Enter details for the property USERNAME. The specified user must have
permission to read and execute scripts from the Tivoli Service Automation
Manager installation directory, and also have permission to read IBM Tivoli
Monitoring configuration files. By default, Tivoli Service Automation Manager
installs these components using the root user name.
5. Enter details for the property PASSWORD. This is the password for the user
that was specified in the previous step.
6. Save your settings by clicking the Save symbol. Alternatively, you can press
Ctrl-Alt-S.
Once the end point PMZHBPCFG has been defined, you can click on the Get
Configuration button on the Monitoring Definition panel to retrieve the settings
of IBM Tivoli Monitoring directly (instead of having to enter them manually).
Triggering the Tivoli Service Automation Manager event monitoring
application:
You need to configure a SOAP service to trigger the Tivoli Service Automation
Manager event monitoring application.
About this task
Whenever a predefined event has been detected by a performance monitor, the
Tivoli Service Automation Manager Situation Analysis application is triggered via
IBM Tivoli Monitoring reflex automation. The reflex automation command sends
correlation information to Tivoli Service Automation Manager using a SOAP
service.
Note: In order to be able to switch from the Tivoli Service Automation Manager
application to the Incident application via the Route Workflow button, the
performance security group to which the user belongs must have access rights for
the Incident application.
Procedure
1. Edit the install_dir/bin/.ctjzhtrigger file. Specify the host name and the
port number of the SOAP service listener inside Tivoli Service Automation
Manager. The .ctjzhtrigger file defines the Tivoli Service Automation
Manager host that is to be triggered, and also the Tivoli's process automation
engine user credentials that are used if a predefined event becomes true.
2. Specify a valid Tivoli's process automation engine user ID and password
required to authorize the SOAP service caller. The following example settings
trigger Tivoli Service Automation Manager on host
your.management.server.name on port 9080 for the user maxadmin.
#
# Settings for Maximo SOAP service
#
Chapter 3. Configuring 265
hostname=your.management.server.name
portnum=9080
maxusername=maxadmin
maxuserpassword=maxadmin
3. Create and deploy a Web service that initiates an event analysis workflow. This
should occur whenever a trigger is sent via the IBM Tivoli Monitoring reflex
automation, using ctjzhtrigger.sh. Complete the following steps:
a. Set the system property mxe.int.webappurl in Tivoli's process automation
engine:
1) Click Go To > System Configuration > Platform Configuration >
System Properties.
2) Type mxe.int.webappurl in the Property Name filter field.
3) Replace localhost by specifying <hostname>:<port> of the Tivoli Service
Automation Manager Server hosting the SOAP service listener.
4) Click Save.
5) Select the global property mxe.int.webappurl again.
6) Click Live Refresh.
Now both the Global Value and the Current
Value of the
mxe.int.webappurl property should contain the specified host name and
port.
b. Click Go To > System Configuration > Platform Configuration > Web
Services Library.
c. On the Select Action menu, select Create Web Service > Create WS from
Standard Service.
d. In the Create Web Service from a Standard Service Definition window, select
source name PMZHBPWO and click Create.
e. Select the PMZHBPWO Web service.
f. On the Select Action menu, select Deploy Web Service and click OK.
Integrating Tivoli Usage and Accounting Manager
Before you employ the usage and accounting function you need to configure both
Tivoli Service Automation Manager and Tivoli Usage and Accounting Manager to
work together.
Note: In Tivoli Service Automation Manager, a metering framework is used to
generate metering data of virtual server resources. The metering framework is also
the default method to generate the CSR files for integrating with Tivoli Usage and
Accounting Manager. For more details about the metering framework, see The
metering framework section in the Tivoli Service Automation Manager Extensions Guide.
CSR files
Service usage data is provided by Tivoli Service Automation Manager for Tivoli
Usage and Accounting Manager by generating periodically an appropriate CSR
(Common Server Resource) file. This file contains information about virtual servers
and their capacity with respect to the number of CPUs and the amount of memory
that is assigned to the virtual server during the lifetime of the service using them.
The extraction of service usage data from the auditing tables is typically performed
once a day.
The CSR file contains the following list of identifiers and resources:
v Server_Hostname - host name of the server
v Server_Platform - for example, VMware, LPAR, Xen, KVM
266 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Deployment_Instance - the name of the deployment instance (project) the server
is allocated to
v Service_Definition - the name of the service definition that is used to create the
deployment instance
v Deployment_Owner - the user that requested the deployment instance
v Account_Code - the identifier consists of three values:
<CUSTOMER> unique customer short name
<PROJECTACCOUNT> the project account value that is specified in the Create
Team and Modify Team requests.
Note: Metering data is collected only for projects that have active customers.
<PERSONGROUP> unique team identifier
The CSR file contains five metrics for chargeback:
v SERVHRS - time (in hours) the server is allocated to a given deployment project
v CPUHRS - product of the time (in hours) and number of CPUs assigned to the
server
v MEMMBHRS - product of the time (in hours) and amount of memory (in MB)
assigned to the server
v STGGBHRS - product of the time (in hours) and amount of storage (in GB)
assigned as root disk to the server
v ADDSTGGBHRS - product of the time (in hours) and amount of storage (in GB)
assigned as Additional Disk to the server
The name of the generated CSR file is derived from the name of the service
definition, the revision of the definition and its timestamp:
<service_definition>_<revision>_<timestamp>.txt.
The CSR files remain on the Tivoli Service Automation Manager management
server after being retrieved by Tivoli Usage and Accounting Manager. The
transferred files must be archived or deleted by the administrator.
Configuring Tivoli Service Automation Manager for Tivoli Usage
and Accounting Manager
Configure Tivoli Service Automation Manager so that it generates appropriate CSR
files needed for Tivoli Usage and Accounting Manager.
Before you begin
You need to have Tivoli Service Automation Manager Administrator privileges to
perform this task.
Procedure
1. Configure Tivoli Service Automation Manager server to enable RXA
connections. See Configuring for RXA connections between Tivoli Service
Automation Manager and Tivoli Usage and Accounting Manager on page 268.
2. Enable metering and accounting in the administrative user interface:
a. Enable auditing of changes to service deployment instances. The generation
of the CSR file uses the identical configuration changes to the database as
the Reporting function. If reporting is already enabled, nothing else has to
be configured, if not, refer to Enabling table auditing on page 288 and
perform the steps as described.
Chapter 3. Configuring 267
b. Ensure an identification of a charge-back department for users requesting
deployment instances. This is done by adding project account information
to the team definition for the user requesting the project. Once the project
account information is defined for the team, the user creating the project
has to select the respective team name in the panel. See the User's Guide for
details.
c. Activate the recurring generation of metering and accounting data for Tivoli
Service Automation Manager. See Enabling CSR file generation on page
269.
d. Define the location of the CSR file. See Defining the directory for CSR file
generation on page 269.
Configuring for RXA connections between Tivoli Service Automation Manager
and Tivoli Usage and Accounting Manager:
Tivoli Usage and Accounting Manager uses RXA to connect to the Tivoli Service
Automation Manager server to retrieve the generated CSR files. This task
comprises the definition of the user ID and the pass key. If this task is omitted,
CSR file transfer to the Tivoli Usage and Accounting Manager server is not
possible.
Procedure
1. Log on as root on the Tivoli Service Automation Manager server and enter the
following commands:
cd .ssh
ssh-keygen -t rsa
cat TSAM_id_rsa.pub >>authorized_keys
scp TSAM_id_rsa.pub root@<tuam_server>:/root/.ssh/TUAM_id_rsa.pub
2. Log in as root on the Tivoli Usage and Accounting Manager server and enter
the following commands:
cd .ssh
cat TUAM_id_rsa.pub >>authorized_keys
3. Ensure that the file permissions for the .ssh directory and the authorized_keys
file are set to 600.
Enabling table auditing for Tivoli Usage and Accounting Manager data
collection:
You need to enable auditing in tables to permit collection of data for the Tivoli
Service Automation Manager interface.
Note: You do not need to enable table auditing if you are using the metering
framework introduced with Tivoli Service Automation Manager version 7.2.2.1.
Before you begin
The TPAe platform allows for auditing of database changes. Tivoli Service
Automation Manager uses this feature in conjunction with the generation of
reports. The generation of the CSR file uses the same configuration changes to the
database as the reporting function (see Working with the service automation
reports on page 287). If reporting is already enabled, nothing else has to be
configured, if not, the same steps as for report configuration have to be performed.
268 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Enabling CSR file generation:
You need to activate the escalation that enables generation of the CSR files for the
Tivoli Usage and Accounting Manager interface.
Before you begin
The PMZHBCRDPMD escalation is used to trigger the extraction of data. An
escalation defines a schedule, an object as the target, and a condition related to the
target object. The default schedule for the escalation is once a day at 1 a.m. to
extract usage and accounting data for the previous day.
The target of the escalation is RDPVS service definition. A service-specific action is
invoked that retrieves the data from the database and generates the respective CSR
file.
Procedure
1. In the administrative user interface, click Go To > System Configuration >
Platform Configuration > Escalations.
2. Enter the escalation name PMZHBCRDPMD.
3. From the Select Action menu, select Activate/Deactivate Escalation.
4. If you are using the metering framework introduced with Tivoli Service
Automation Manager 7.2.2.1, you might need to configure two additional
properties for the escalation:
pmzhb.rb.metering.enabled = {true,false}
When set to true, this property enables the escalation to generate the
metering records based on the new metering framework. When set to
false, the audit tables are used to generate the metering data. Default
value is true.
pmzhb.rb.metering.overwrite.startdate = {yyyyMMdd}
The property can be used to overwrite the start point of the meter
generation, where yyyy is the year, MM is the month and dd is the day of the
month. The escalation generates a file for each day starting from the date
specified, until the current day. The value must be reset manually,
otherwise generation always starts at overwrite time. This flag works only
for the new metering framework, that is, when pmzhb.rb.metering.enabled
= true.
To modify the properties, click Go To > System Configuration > Platform
Configuration > System Properties.
Defining the directory for CSR file generation:
This section describes the procedure for defining the directory in which the CSR
files for IBM Tivoli Usage and Accounting Manager are generated.
Before you begin
The directory in which CSR files will be generated can be defined by the customer
as a TPAE system property. The default directory is /var/IBM/TSAM/metering. A
trailing slash is optional.
Procedure:
Chapter 3. Configuring 269
Procedure
1. Ensure that the directory to be specified exists. Tivoli Service Automation
Manager does not create this directory (even the default directory)
automatically. If the directory does not exist at runtime, an error message is
issued.
2. Ensure that the directory has the necessary permissions. Change the ownership
(chown) of the directory (for example /var/IBM/TSAM/metering) to the uid
and gid of tioadmin.
3. From the Start Center of the administrative user interface, select Goto >
System Configuration > Platform Configuration > System Properties
4. Enter the property name (pmzhb.csr.dir).
5. Open the property and set the value to the desired directory (or retain the
default value).
6. Save the changes
7. Select the property from the list and select Live Change from the action bar.
Enabling logs for metering:
Optionally, if you want to capture the metering logs, enable logging. In the logging
page, set the log level for PMZHB to debug and apply settings.
Procedure
Set the log level for PMZHB to debug:
1. In the Maximo start center, click Go To > System Configuration > Platform
Configuration > Logging.
2. Search for PMZHB and change the Log Level to Debug.
3. Select Apply Settings in Select Action list.
4. In the System Message about applying the selected settings, click OK.
Configuring Tivoli Usage and Accounting Manager to process
CSR files
After you have enabled metering in Tivoli Service Automation Manager, configure
Tivoli Usage and Accounting Manager server to retrieve and process the CSR file.
Before you begin
You need to have Tivoli Usage and Accounting Manager Administrator privileges
to perform this task.
Procedure
1. Define the account code structure:
a. In the Tivoli Integrated Portal, select Administration > Usage and
Accounting Manager > Account Code Structure. For more details on the
account code, see Project account and the account code structure on page
291.
2. Associate the account code structure with the Tivoli Service Automation
Manager user that is entitled to view the reports:
a. Click Identity and Access > Usage and Accounting > User Groups.
b. Select the appropriate user group in your environment.
c. Edit the group to add the newly defined account code structure.
3. Verify that the user is able to view reports:
270 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
a. Click Identity and Access > Usage and Accounting > Users.
b. Click the selected user and verify that the Common Reporting checkbox is
marked.
4. Define Tivoli Service Automation Manager rate group and rate codes:
a. In Tivoli Integrated Portal, select Financial > Usage and Accounting >
Rates.
b. Define rates and rate codes for the provided resources: SERVHRS,
MEMMBHRS, CPUHRS, and ADDSTGGBHRS. The descriptions specified
are the descriptions that you will see in the reports.
c. Create a rate group called TivSAM and associate the new rates with this
group.
5. Customize the sample job file to retrieve the CSR file. See Configuring the
Tivoli Usage and Accounting Manager job file to retrieve CSR files from Tivoli
Service Automation Manager for more information.
6. Customize the sample job file to process the retrieved CSR file. See
Configuring the Tivoli Usage and Accounting Manager job file to process CSR
files from Tivoli Service Automation Manager on page 272 for more
information.
Configuring the Tivoli Usage and Accounting Manager job file to retrieve CSR
files from Tivoli Service Automation Manager:
This section describes the procedure for configuring a job file to periodically
retrieve the CSR files from Tivoli Service Automation Manager.
Before you begin
IBM Tivoli Usage and Accounting Manager provides sample jobs to transfer CSR
files between servers. The following values are required to customize the sample
job file to transfer the Tivoli Service Automation Manager CSR file to the Tivoli
Usage and Accounting Manager server:
v Host name of the Tivoli Service Automation Manager management server
v Path to User ID/passkeys generated as part of RXA (see Configuring for RXA
connections between Tivoli Service Automation Manager and Tivoli Usage and
Accounting Manager on page 268
v Path to the CSR file on the Tivoli Service Automation Manager server as
described in Defining the directory for CSR file generation on page 269.
v Target location of the transferred CSR file on the Tivoli Usage and Accounting
Manager server
The sample must be adapted to:
v Read the transferred file.
v Process the file, that is, add an additional account code that corresponds to the
account code structure defined in Tivoli Usage and Accounting Manager.
v Load the processed data into the Tivoli Usage and Accounting Manager
database.
To transfer the CSR file from Tivoli Service Automation Manager management
server, run a job file on the Tivoli Usage and Accounting Manager server. The
sample job file SampleFileTransferSSH_withPW.xml can be used to create a job file
to transfer the file via SSH to a UNIX or Linux server. Job execution creates a log
file on the Tivoli Usage and Accounting Manager server in the /log files directory.
This log file must be examined in case of errors.
Chapter 3. Configuring 271
The Tivoli Usage and Accounting Manager administrator starts the file transfer by
invoking the startJobRunner shell script or .bat file, depending on the platform of
the Tivoli Usage and Accounting Manager server, with the xml file and the
appropriate date specification. CSR files will not be deleted automatically on the
Tivoli Service Automation Manager server after retrieval.
Important: If you upgrade from earlier versions of Tivoli Service Automation
Manager, run this file transfer again. The additional disk metering is enabled in
7.2.4.4 and the CSR file format is updated. For the job file to understand the new
CSR format, you must run this file transfer again. In case you must initiate
metering for additional disks that were added in earlier versions of Tivoli Service
Automation Manager, see Metering for additional disks that are created during
earlier versions of Tivoli Service Automation Manager on page 276.
A customized job file might appear as follows:
<Process id="SSHFileTransfer" description="Transfer remote files to this machine via ssh"
joblogShowStepOutput="true"
joblogShowStepParameters="true"
active="true">
<Steps stopOnStepFailure="true">
<Step id="FileTransferViaSSH" description="Transfer remote files to this machine via ssh"
type="Process"
programName="FileTransfer"
programType="java"
active="true">
<Parameters>
<Parameter type="ssh"/>
<Parameter serverName="<management server host name>"/>
<Parameter userId="root"/>
<Parameter userPassword="userPassword"/>
<!-- If you generated the keys using a passphrase, the userPassword parameter
has to be set to the passphrase. If you left the passphrase empty,
it has to be set to a non-empty string -->
<Parameter KeyStoreFileName="/root/.ssh/TSAM_id_rsa"/>
<Parameter from=="ssh:///var/IBM/TSAM/metering/RDP_%LogEnd_Date%.txt"
to="file://%CollectorLogs%/RDP_%LogEnd_Date%.txt"
action="Copy"
overwrite="true"/>
</Parameters>
</Step>
</Steps>
</Process>
Configuring the Tivoli Usage and Accounting Manager job file to process CSR
files from Tivoli Service Automation Manager:
This section describes the procedure for configuring a job file to process CSR files
received from Tivoli Service Automation Manager.
Before you begin
The Tivoli Usage and Accounting Manager administrator initiates the process by
invoking the startJobRunner shell script or .bat file, depending on the platform of
the Tivoli Usage and Accounting Manager server, with the xml file and the
appropriate date specification. CSR files will not be deleted automatically on the
Tivoli Service Automation Manager server after retrieval.
The account code structure is:
272 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 33. Account code structure
Identifier Length in characters Description
Account_Code 40 consisting of:
<CUSTOMER> 12
<PROJECTACCOUNT> 20
<PERSONGROUP> 8
Account_Code consists of
three values:
<CUSTOMER> unique
customer short name
<PROJECTACCOUNT> the
project account value that is
specified in the Create Team
and Modify Team requests
<PERSONGROUP> unique
team identifier
Deployment_Owner 30 The user that requested the
project.
Service_Definition 4 First four characters of the
service definition name, used
to identify the service in a
report.
Deployment_Instance 30 The name of the project the
server is associated to.
The Tivoli Usage and Accounting Manager Integrator is used to generate an
account code based on the values of the identifiers in the CSR file. The following
illustrates the job file. Invocation of this file is similar to the file transfer job file.
Job execution creates a log file on the Tivoli Usage and Accounting Manager server
in the log files directory. This file must be examined if errors occur.
Sample XML file for processing Tivoli Service Automation Manager CSR files
on Tivoli Usage and Accounting Manager:
Chapter 3. Configuring 273
<Jobs xmlns="http://www.ibm.com/TUAMJobs.xsd">
- <Job id="TSAM" description="Daily collection" active="true" joblogShowStepParameters="true" joblogShowStepOutput="true" processPriorityClass="Low" smtpSendJobLog="false" smtpServer="mail.YourCo
- <Process id="TSAM" description="Process TSAM Usage and Configuration CSR file" active="true">
- <Steps stopOnStepFailure="true">
- <Step id="Integrator_Account_Code_Generation" description="Add Account Code Information" type="Process" programName="integrator" programType="java" active="true">
- <Integrator>
- <Input name="CSRInput" active="true">
- <Files>
<File name="%LogDate_End%.txt" />
</Files>
</Input>
- <Stage name="CreateIdentifierFromIdentifiers" active="true">
- <Identifiers>
- <Identifier name="Account_Code">
- <FromIdentifiers>
<FromIdentifier name="Chargeback_Department" offset="1" length="15" />
<FromIdentifier name="Deployment_Owner" offset="1" length="30" />
<FromIdentifier name="Service_Definition" offset="1" length="5" />
<FromIdentifier name="Deployment_Instance" offset="1" length="30" />
</FromIdentifiers>
</Identifier>
</Identifiers>
- <Parameters>
<Parameter keepLength="true" />
<Parameter modifyIfExists="true" />
</Parameters>
</Stage>
- <Stage name="RenameResourceFromIdentifier" active="true">
- <Identifiers>
<Identifier name="Server_Platform" />
</Identifiers>
- <Resources>
<Resource name="CPUHRS" />
</Resources>
- <Parameters>
<Parameter dropIdentifier="false" />
<Parameter renameType="prefix" />
</Parameters>
</Stage>
- <Stage name="RenameResourceFromIdentifier" active="true">
- <Identifiers>
<Identifier name="Server_Platform" />
</Identifiers>
- <Resources>
<Resource name="SERVHRS" />
</Resources>
- <Parameters>
<Parameter dropIdentifier="false" />
<Parameter renameType="prefix" />
</Parameters>
</Stage>
- <Stage name="RenameResourceFromIdentifier" active="true">
- <Identifiers>
<Identifier name="Server_Platform" />
</Identifiers>
- <Resources>
<Resource name="MEMMBHRS" />
</Resources>
- <Parameters>
<Parameter dropIdentifier="false" />
<Parameter renameType="prefix" />
</Parameters>
</Stage>
- <Stage name="RenameResourceFromIdentifier" active="true">
- <Identifiers>
<Identifier name="Server_Platform" />
</Identifiers>
- <Resources>
<Resource name="STGGBHRS" />
</Resources>
- <Parameters>
<Parameter dropIdentifier="false" />
<Parameter renameType="prefix" />
</Parameters>
274 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
</Stage>
- <Stage name="RenameResourceFromIdentifier" active="true">
- <Identifiers>
<Identifier name="Server_Platform" />
</Identifiers>
- <Resources>
<Resource name="ADDSTGGBHRS" />
</Resources>
- <Parameters>
<Parameter dropIdentifier="false" />
<Parameter renameType="prefix" />
</Parameters>
</Stage>
- <!-- Rename since limit of 8 characters applies to rate codes
-->
- <Stage name="RenameFields" active="true">
- <Fields>
<Field name="LPARCPUHRS" newName="PCPUHR" />
<Field name="VMWARECPUHRS" newName="XCPUHR" />
<Field name="KVMCPUHRS" newName="KCPUHR" />
<Field name="LPARSERVHRS" newName="PSERVHR" />
<Field name="VMWARESERVHRS" newName="XSERVHR" />
<Field name="KVMSERVHRS" newName="KSERVHR" />
<Field name="LPARMEMMBHRS" newName="PMEMMBHR" />
<Field name="VMWAREMEMMBHRS" newName="XMEMMBHR" />
<Field name="KVMMEMMBHRS" newName="KMEMMBHR" />
<Field name="LPARSTGGBHRS" newName="PSTGGBHR" />
<Field name="VMWARESTGGBHRS" newName="XSTGGBHR" />
<Field name="KVMSTGGBHRS" newName="KSTGGBHR" />
<Field name="LPARADDSTGGBHRS" newName="PASTGBHR" />
<Field name="VMWAREADDSTGGBHRS" newName="XASTGBHR" />
<Field name="KVMADDSTGGBHRS" newName="KASTGBHR" />
</Fields>
</Stage>
- <Stage name="CSROutput" active="true">
- <Files>
<File name="%ProcessFolder%/AcctCSR.txt" />
</Files>
</Stage>
</Integrator>
</Step>
- <Step id="Process" description="Standard Processing for TSAM" type="Process" programName="Bill" programType="java" active="true">
- <Bill>
<Parameters />
</Bill>
</Step>
- <Step id="DatabaseLoad" description="Database Load for TSAM" type="Process" programName="DBLoad" programType="java" active="true">
- <DBLoad>
<Parameters />
</DBLoad>
</Step>
- <Step id="Cleanup" description="Cleanup TSAM CSR Processing" type="Process" programName="Cleanup" programType="java" active="false">
- <Parameters>
<Parameter DaysToRetainFiles="45" />
<Parameter cleanSubfolders="true" />
</Parameters>
</Step>
</Steps>
</Process>
</Job>
</Jobs>
Chapter 3. Configuring 275
Metering for additional disks
Metering for additional disks is included in Tivoli Service Automation Manager
7.2.4.4. You do not have to execute any separate steps to enable metering for
additional disks. The general steps to enable metering also enables metering for
additional disks. Metering is also extended to additional disks that are included in
the earlier versions of Tivoli Service Automation Manager.
Metering for additional disks that are created during earlier versions of Tivoli
Service Automation Manager:
To use metering feature for additional disks that were created in earlier versions of
Tivoli Service Automation Manager, run escalation after you upgrade to Tivoli
Service Automation Manager 7.2.4.4. Escalation is a one time activity to enable
additional disk data collection to the metering table.
Procedure
1. In the Maximo start center, click Go To > System Configuration > Platform
Configuration > Escalations.
2. In Description search for PMZHBMETEXADDDSK. For example, enter Meter in
Description and press ENTER
3. Go to Escalations tab.
4. As a one time activity, in the Select Action list, select Activate/Deactivate
Escalation.
Remember: This is a one time activity.
Attention: Before you activate this escalation, verify whether you have
enabled metering.
Integrating with Tivoli Change and Configuration Management
Database (CCMDB)
You can integrate Tivoli Service Automation Manager processing with change and
configuration management to apply governance of these processes that is aligned
with Information Technology Infrastructure Library (ITIL).
About this task
Tivoli Service Automation Manager operations perform changes to the managed
datacenter, such as deployment of new virtual servers or installation of software.
You can integrate this processing with ITIL-aligned governance processes such as
change management or configuration management. By doing this, you are able to
apply ITIL-aligned governance implemented in these processes, for example
assessment or scheduling of changes done by Tivoli Service Automation Manager,
still using the benefits of Tivoli Service Automation Manager for automating
management actions.
The integration is recommended for some environments that already use
ITIL-aligned processes implemented with Tivoli Change and Configuration
Management Database.
276 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Configuration artifacts for integrating with Tivoli Change and
Configuration Management Database
Learn about configuration artifacts shipped with Change and Configuration
Management Database Integration Process Management Product that are used to
integrate Tivoli Service Automation Manager operations with the change
management process.
Create Standard Change from SR Action (PMZHBCCSTCA action)
This action is used to define ticket templates, or, if the service request is processed
with a workflow, it serves as a Tivoli Process Automation engine workflow action,
configured on the edge of the workflow.
PMZHBCCSTCA is an action that creates a request for change (RFC) from a service
request, then associates that change with the Tivoli Service Automation Manager
service instance and management plan so that the management plan is processed
in context of the change management process.
Create Standard Change from SR (PMZHBCCSTC job plan)
PMZHBCCSTC is a pre-configured activity job plan used to define ticket templates. It
starts the PMZHBCCSTCA action.
TSAM Standard Change (PMZHBCSCHG ticket template)
Ticket templates are a new concept introduced with Service Request Manager 7.2.
They provide users with default ways of processing service requests and tickets.
They are also used to define Service Request Manager offerings. This means, after
a user selects an offering and a service request is created, a specific ticket template
starts to process the request in a default way.
PMZHBCSCHG is a pre-configured ticket template that can be assigned to a service
request or used for a Service Request Manager offering. The template defines how
a request for change (RFC) is created from that service request.
TSAM Standard Change (PMZHBCSCHG change template)
Change templates are a new concept introduced with the Change Management
Process Management Product of CCMDB. A change template is a part of a job
plan, and is used to predefine a list of reviews and approvals that are required for
changes that correspond to this specific change template.
Within Tivoli Service Automation Manager, it is possible to define template job
plans as a part of single management plans of a service definition. You can use
such a template job plan to point to a change template, which in turn associates a
list of required reviews and approvals with the management plan. When the
management plan is processed during change management, the necessary review
and approval steps are triggered automatically.
Tivoli Service Automation Manager includes a sample PMZHBCSCHG change template
that can be used as the basis for defining new templates.
A change template assigned to a Tivoli Service Automation Manager management
plan is an empty job plan with the change template-specific parts filled out, but
with no tasks. It defines properties specific to the change process, and can be
found in the job plans application.
Chapter 3. Configuring 277
Note: You can only customize new change templates when the Default WO Class
property is set to CHANGE. Then the Change Template tab is displayed, and you can
enter information necessary for the management plan to which a change template
is to be assigned.
Start SR Activity (PMZHBSSRACT escalation)
In a typical situation, after a service request is created and associated with a ticket
template, the service desk staff manually starts the process for creating a request
for change. This process can also be executed automatically by an escalation, which
is part of the CCMDB Integration Process Management Product.
PMZHBSSRACT is a default escalation that can be used to execute service requests
processing. The execution process depends on the service request classification that
is encoded in the Condition WHERE clause of the escalation. The condition must
be adapted to the type of the service request to be processed.
Note: Ensure that the escalation is active in the system.
TSAM Asynchronous Request Correlation Escalation (PMZHBCREQCORA
escalation)
The Tivoli Service Automation Manager management plan preparation workflows
can be executed as part of the change process. In such a situation, the actual
change process does not start until the Tivoli Service Automation Manager
management plan preparation workflows have completed. The change process is
then resumed asynchronously with the PMZHBCREQCORA escalation.
Note: Ensure that the escalation is active in the system.
Configuring workflow integration
This section describes how you can integrate Tivoli Service Automation Manager
processing with Change Management workflows of the Change and Configuration
Management Database.
About this task
The execution of Tivoli Service Automation Manager management plan preparation
workflows can be included in the change management workflows as subprocesses
in order to achieve an end-to-end integrated flow. The workflows are run when
you start the management plans in order to perform preparations that are specific
to Tivoli Service Automation Manager.
Workflow integration is not configured by default when you install the Change
and Configuration Management Database integration Process Management Product
as part of Tivoli Service Automation Manager installation. Otherwise, any
customizations that might have been made to the change workflows could be
overwritten. Therefore, it is necessary to perform the configuration manually.
It is recommended to include the execution of the Tivoli Service Automation
Manager management plan preparation workflows in the Accept and Categorize
(PMCHGACCAT)) subprocess of the IT Infrastructure Library change process
(PMCHGITIL). The results calculated by Tivoli Service Automation Manager are then
available in the next phases of the change process, such as the assessment phase.
278 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
The following procedure assumes that the Change Management content Process
Management Product is installed and that workflows contained in that Process
Management Product exist with default names.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Workflow
designer.
2. Deactivate the PMCHGITIL change workflow to make sure that any other
modifications are active later.
3. Open the Accept and Categorize workflow (PMCHGACCAT) and use the
toolbar to create a new revision.
4. In the new revision of the PMCHGACCAT workflow, delete the last edge that goes
from VALIDATE to STOP2 (this edge does not contain any action).
5. Insert a new subprocess node between VALIDATE and STOP2 and connect it
to them using a positive input edge and a positive and negative output edge.
6. Name that subprocess node, for example TSAMPREP. If the required
information is available at run time, the node starts the PMZHBCPRCH subprocess
that starts the Tivoli Service Automation Manager Management plan
preparation workflow.
7. Enable and activate the modified PMCHGACCAT workflow.
8. Reactivate the PMCHGITIL overall change process.
Results
The subprocess started by the subprocess node is the PMZHBCPRCH workflow, which
is shipped with the Change and Configuration Management Database integration
Process Management Product. At run time, this workflow checks whether all
information that Tivoli Service Automation Manager requires to start its
management plan preparation workflow is available for the current change. If the
information is available, it starts the workflow. Make sure that the PMZHBCPRCH
workflow is enabled and active.
Note: For the integration of Tivoli Service Automation Manager and the Change
Process, a modification has also been made to the default management plan
preparation workflows PMZHBSIWWA (Service Instantiation Workflow) and
PMZHBSIMOD (Service Modification Workflow). Make sure that the latest revision of
those workflows is enabled and activated.
Configuring a Service Request Manager offering for processing
Perform this task to integrate the Tivoli Service Automation Manager processing
with an ITIL-aligned governance.
About this task
Associate a ticket template to an offering to use the default behavior for opening a
request for change (RFC) and associating it to a Tivoli Service Automation
Manager management plan whenever you select the offering and create a service
request.
Procedure
1. Define a new offering and select Service Request in the Offering Type field.
2. Specify the name of the ticket template in the Ticket Template attribute.
Default ticket template name is PMZHBCSCHG.
Chapter 3. Configuring 279
Some specification attributes must be set for the offering to allow you to create
the RFC and associate the information required by this RFC. You must define
those attributes as part of classification PMZHBCSCOFF, which can be used as base
for deriving custom subclassifications that can then inherit these attributes.
3. Select the Specifications tab. In the Service Definition ID and Service
Definition Revision fields, specify the attributes that point to the service
definition to which the offering refers.
4. In the Management Plan ID field, specify the attribute that points to the
management plan that is triggered when you submit a request for the offering.
Note: These three attributes are normally hidden from end users and the
values that are defined are fixed values for the offering configuration.
Specify the Service Instance ID attribute only when you modify an existing
service instance. The attribute must be set during the request time, for example
by using the lookup mechanism in the offering dialog.
The two remaining attributes, Service Instance Name and Service Instance
Description are required for requests used to create new service instances.
These attributes are typically specified by the requester of the offering.
Extensions to the Change Management application
The Change and Configuration Management Database integration Process
Management Product introduces several extensions that are specific to the Changes
Management application to the Tivoli Service Automation Manager administrative
user interface.
When a change is associated with a Tivoli Service Automation Manager service
instance and management plan, a new section called Related Service Automation
Items is displayed in the Changes application on the Related Records tab. This
section includes the name and description of the service instance associated with
the current change and the management plan that is run in the context of that
change. It also includes a link you can use to open the Service Deployment
Instances application.
After accepting a request for change (RFC) and routing the workflow by clicking
the Change button on the toolbar, the Tivoli Service Automation Manager
management plan preparation workflow is run for the associated management
plan. Depending on the service definition and the management plan, this
preparation workflow can involve manual tasks.
At the end of the workflow, the standard change process continues using all the
information generated during the Tivoli Service Automation Manager management
plan preparation workflow.
You can switch to the Schedule tab to view and schedule all tasks that are
generated based on the associated management plan template.
Switch to the Workplan Map tab to view a graphical representation of these tasks
and their dependencies.
Based on the service topology information contained in the associated service
deployment instance, Tivoli Service Automation Manager can also calculate the
configuration items (CIs) affected by the change. A graphical representation of this
information is displayed on the Impact tab.
280 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Tivoli Change and Configuration Management Database
Configuration Items
This section describes the role of configuration items that are stored in CCMDB,
and reflects changes made to the managed IT infrastructure during execution of
Tivoli Service Automation Manager management plans.
You can use the CCMDB Integration Process Management Product of Tivoli Service
Automation Manager to define additional tasks that automatically update the
configuration items during execution of management plans. The Service Topology
Node Operations application contains templates that can be used for this purpose.
With those tasks the authorized configuration items are updated, not the actual
configuration items that are updated automatically during the discovery. The
procedure for creating authorized configuration items and performing other
operations from the Service Topology Node Operations application is optional,
which means that the already existing management plans can be executed without
any updates to the configuration items.
The CCMDB Integration Process Management Product of Tivoli Service
Automation Manager provides three template operations that can be used to define
management plan tasks for creating and updating configuration items and the
relationships between those items. Two of these are ready-to-use operations, and
one is a real template that must be customized. Do not use it as is. Instead, derive
the custom operations you need. Detailed descriptions of all three operations and
examples of how to use them are provided in the following sections.
The CreateOrUpdateAuthorizedCI operation:
Use this operation to create a new authorized configuration item (CI) using a task
in a management plan or to perform updates to an already existing configuration
item.
The CreateOrUpdateAuthorizedCI operation is a template operation. Do not use it
without any modifications. It only defines a generic set of input parameters that
are required for all configuration item types; it does not define parameters specific
for a configuration item type. Use this operation to derive custom operations for
specific configuration item types.
Parameters
This operation defines four input parameters that are required for all configuration
item types and that must be present in any derived operations. The parameters are:
CINUM
This parameter is the identifier of the configuration item that is to be created
or updated. If an authorized configuration item with the same identifier exists
in Change and Configuration Management Database, this operation performs
an update to the attributes or the status of that configuration item. If no such
configuration item is found, the operation creates a new one. A unique ID is
then generated by appending a number to the identifier passed via the CINUM
parameter. The resulting identifier is generated and returned as output
parameter CINUM of the operation. For example, if a new configuration item is
created and a value "MYCI" is provided as input, a possible resulting identifier
is "MYCI~2001".
ClassificationID
This parameter is the ID of the classification (configuration item type) used for
Chapter 3. Configuring 281
the new configuration item. You can find the configuration item classifications
in the Classifications application. An example of a valid configuration item
classification is APP.SOFTWAREINSTALLATION.
Description
This parameter is a description to assign to the configuration item in case of
creating a new one.
Status
This parameter is the status that is set for the new configuration item. This
status is set both for new configuration items and for the existing ones. You
can use this operation to update the status of existing configuration items.
Note: The internal value for configuration item status must be provided as input
value for that parameter, and not the potentially translated, external value. You can
check the internal configuration item status value by checking the domain
CISTATUS in the Domains application. By default, this domain contains the
following values NOT READY, OPERATING, and DECOMMISSIONED.
Custom operations derived from the base operation must also define the input
parameters specific to the configuration item type according to the following
naming conventions:
CIATTR_...
Input parameters that start with the prefix CIATTR_ are used to set primary
attributes of the affected configuration item, that is, the attributes of the
configuration item object, not the specification attributes.
CISPEC_...
Input parameters that start with the prefix CISPEC_ can be used for setting
specification attributes of the affected configuration item. You can check the set
of available specification attributes for a specific configuration item type
(classification) by looking up the respective configuration item classification in
the Classifications application.
The operation also defines one output parameter, CINUM, which is used to create the
final generated configuration item identifier for newly created configuration items
(see the description of the CINUM input parameter). Store this output parameter in
an attribute of the service topology node associated with the configuration item so
that it can be found later. For example, if a service topology node is associated
with a configuration item, attribute PRIMARY_CI can be defined for that node. The
identifier of the configuration item created with the CreateOrUpdateAuthorizedCI
operation (the output parameter CINUM) can hen be mapped to that PRIMARY_CI
attribute.
See this topic for an example of deriving an operation specific to a configuration
item.
282 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
The LinkAuthorizedCI operation:
Use this operation to create a relationship between two existing configuration items
(CIs).
You can use the LinkAuthorizedCI operation as is. It is not necessary to derive a
custom operation from it because no special input parameters are required for
different kinds of configuration item relationships.
Parameters
The following input parameters are defined by the LinkAuthorizedCI operation:
SourceCI
The identifier of the source configuration item of the relationship to be created.
TargetCI
The identifier of the target configuration item of the relationship to be created.
Relationship
The name or type of the relationship to be created.
When using this operation in a management plan, make sure that the relationship
type that is created between the two configuration items is valid. You can find the
valid relationship types for specific types of source and target configuration items
in the Relationships application. Open it by selecting Go to > IT Infrastructure.
For example, a valid relationship for a source configuration item of the Software
Installation type and a target configuration item of the Operating System type is
InstalledOn.
See this topic for an example procedure of using the configuration item operations.
The UnlinkAuthorizedCI operation:
Use this operation to delete an existing relationship between two configuration
items (CIs).
You can use the UnlinkAuthorizedCI operation as is - it is not necessary to derive a
custom operation from it because no special input parameters are required for
different kinds of configuration item relationships.
Parameters
The following input parameters are defined by the UnlinkAuthorizedCI operation:
SourceCI
The identifier of the source configuration item of the relationship to be deleted.
TargetCI
The identifier of the target configuration item of the relationship to be deleted.
Relationship
The name or type of the relationship to be deleted.
Note: If the relationship does not exist at run time, the operation completes
without performing any action. No errors are reported in such case.
Chapter 3. Configuring 283
Deriving an operation specific to a configuration item:
The CreateOrUpdateAuthorizedCI operation is a generic template and you can
derive custom operations for creating or updating configuration items of specific
types from it.
About this task
This example task describes how to create an operation for creating or updating a
software installation configuration item (classification APP.SOFTWAREINSTALLATION).
By performing this operation a number of attributes can be set or updated. The
attributes are:
v Install Location (SOFTWAREINSTALLATION_INSTALLEDLOCATION)
v Manufacturer Name (SOFTWAREINSTALLATION_MANUFACTURERNAME)
v Product Name (SOFTWAREINSTALLATION_PRODUCTNAME)
v Release (SOFTWAREINSTALLATION_RELEASE)
v Version String (SOFTWAREINSTALLATION_VERSIONSTRING)
To define such an operation follow the steps below:
Procedure
1. Open the original CreateOrUpdateAuthorizedCI operation in the Service
Topology Node Operations application and create a duplicate of the operation
by using the Action menu.
2. Enter a new Operation ID and Owner ID in the respective fields.
3. Define the new input parameters specific for the configuration item type in
order to set and update the specification attributes.
Remember: Define the input parameter names for setting the configuration
item specification attributes using the prefix CISPEC_ followed by the name of
the specification attribute. For example, the input parameter for setting a
specification attribute SOFTWAREINSTALLATION_PRODUDCTNAME, is
CISPEC_SOFTWAREINSTALLATION_PRODUCTNAME.
Using the configuration item operations:
In this example, a software installation configuration item for a WebSphere
Deployment Manager node that gets installed on a server is created using both the
LinkAuthorizedCI operation and the CreateOrUpdateAuthorizedCI operation.
About this task
This software installation configuration item is then linked to the computer system
configuration item on which it is installed. To perform this task, you must insert
two tasks into the management plan after the task that actually installs the
WebSphere Deployment Manager component. One of these tasks is required for
creating the software installation configuration item
(CreateOrUpdateSoftwareInstallationCI derived from
CreateOrUpdateAuthorizedCI), and the other for linking it to the computer system
configuration item (LinkAuthorizedCI).
Procedure
1. Open the Edit Management Task window to view the management task
details. The input parameter mappings are displayed in this window.
284 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
2. Set the ClassificationID parameter to a constant value
APP.SOFTWAREINSTALLATION
3. Use the PMZHB_WAS_NODE_NAME attribute of the associated topology node to set
the CINUM input parameter.
4. Map the CINUM output parameter to the PMZHB_PRIMARY_CI attribute. The final
identifier of the created configuration item is then stored in that node attribute
for later reference.
Note: The attributes used in steps 3 and 4 are examples created for the purpose
of this documentation.
5. Define the rest of the input parameters (such as release, version string, or
manufacturer name) using constant values. In this example, the
LinkAuthorizedCI task establishes an INSTALON relationship between the newly
created software installation configuration item and the computer system
configuration item on which the WebSphere Deployment Manager is installed.
6. Open the Edit Management Task window to view the management task
details. The parameter mappings are displayed in this window.
7. Set the constant value INSTALON as the Relationship parameter. This value is
the name of a valid relationship that can be created between a software
installation configuration item and a computer system configuration item.
Note: This is just an example. Always check which types of relationship are
valid for a system on which a specific service definition is used with a task
definition.
8. Use the value stored in the PMZHB_PRIMARY_CI attribute of the deployment
manager node to define the SourceCI parameter.
9. Map the TargetCI parameter to the identifier of the configuration item that
represents the computer system on which the deployment manager is installed.
Configuring security against XSS
As a protection against XSS, external URL references, or sql injection, you cannot
enter certain special characters for fields. The default is "^a-zA-Z0-9\s\/\.\\@~#$
&+\"\'!_-". However, you can configure the special characters that are allowed for
a field. The characters that are defined outside the list results in an error message
from the server.
Procedure
1. Go To System Configuration > Platform Configuration > Database
Configuration.
2. From Select Action list, select Manage Admin Mode.
3. In Turn Admin Mode ON, turn the Admin mode to on and click OK in the
system message.
4. In database configuration, go back to the List tab and filter for Object SR.
5. In Attributes tab, filter for DESCRIPTION.
6. Select DESCRIPTION and expand the row. The Details of DESCRIPTION is
displayed.
7. In the class field, enter
com.ibm.ism.pmzhb.sc.app.FldTicketDescriptionValidation.
8. Save the record and go back to the List tab.
9. Verify whether the Status of the SR is To Be Changed.
10. From Select Action list, select Apply Configuration Changes.
Chapter 3. Configuring 285
11. In Non-Structural Database Configuration, click Start Configuring the
Database.
12. After successfully configuring the database, from Select Action list, select
Manage Admin Mode.
13. In Turn Admin Mode OFF, click Turn Admin Mode OFF.
14. Optional: In System Properties, you can set a system property pmrdp.regex to
manually specify the regex to be used for allowed characters. Example:
[^a-zA-Z0-9\s\/!,_\\-]. Default value that is used in case this property is not
set is [^a-zA-Z0-9\s\/\.\\@~#$&+\"\'!,_-].
a. Open the Maximo UI and Go To > System Configuration > Platform
Configuration > System Properties.
b. Click New Row for Global Properties and enter the following details:
v Property Name - pmrdp.regex
v Description - this property decides whether the regex is used for a
valid input.
v Global Value - For example, [^a-zA-Z0-9\s\/\.\\@~#$&+\"\!,_-].
v Select the following options - Global Only, Online Changes Allowed,
Live Refresh.
c. Click Save.
d. Search for pmrdp.regex in the property name filter.
e. Select the property and click Live Refresh in the Application panel .
f. Click OK.
15. In addition, you can also set another property pmrdp.regex.assetattributes,
which can be set to manually specify the attributes in a "," separated string on
which this regex validation is enforced. Example:
PMRDPCLCVS_PROJECTNAME,PMRDPCLCVS_DESCRIPTION, and other attributes. The
default behavior applies to all attributes in Tivoli Service Automation Manager
that has a prefix "PMRDP".
286 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Chapter 4. Administering Tivoli Service Automation Manager
This chapter discusses various administrative
tasks for Tivoli Service Automation Manager.
These are tasks that can apply on a recurring
basis, possibly also as initial configuration
steps after installation.
Logging on to the Tivoli Service Automation Manager administrative
interface
The administrative user interface is used to modify the configuration of the Tivoli
Service Automation Manager components.
Procedure
1. In a supported browser, open the following URL:
https://<management_server_hostname>:9443/maximo
After IBM HTTP server is configured, the administrative interface is also
accessible using this address:
http://<management_server_hostname>/maximo
2. Log on with the credentials that you have been assigned.
Default administrative credentials:
Username: maxadmin
Password: maxadmin
Related tasks:
Configuring IBM HTTP Server on page 103
Configure the IBM HTTP Server after installing Tivoli Service Automation Manager
and its components.
Working with the service automation reports
This section describes the procedures for generating and viewing reports within
Tivoli Service Automation Manager.
About this task
Note: Reports can be produced only if the appropriate data is collected by the
system, and they can be accessed only if the user has been granted such
authorization. See Configuring the reporting function on page 288.
Copyright IBM Corp. 2008, 2012 287
Configuring the reporting function
Before users can view the Tivoli Service Automation Manager reports, the
administrator must configure them and authorize users to view them.
Generating request pages
To use the Tivoli Service Automation Manager reports, you must generate request
pages once. Users specify selection parameters using the request pages.
Procedure
1. Click Go To > Administration > Reporting > Report Administration.
2. In the Application field, enter PMZHB and press Enter to list all Tivoli Service
Automation Manager reports.
3. Click Generate Request Pages on the right side at the bottom of the table. The
process might take several minutes.
Enabling table auditing
You need to activate the auditing of database tables. The data collected by the
audit is used to produce reports within Tivoli Service Automation Manager that
show the service infrastructure or the progression of services over time.
About this task
Although other setup operations are performed automatically by Tivoli Service
Automation Manager, this task must be performed manually after installation.
All Tivoli Service Automation Manager reports with "History' in the name require
auditing for two tables. If you are going to use these reports, you must configure
audit tables. If you are not going to use these reports, you do not need to
configure table auditing. In this case, these reports must deleted from the system
so that they cannot be accessed. It is possible to re-import these reports from the
management server at a later time if required.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Database
Configuration.
2. In the Object field, enter PMZHBWTN to find the Service Topology Node object
and open the Objects tab.
3. Select the Audit Enabled? check box.
a. Open the Attributes tab.
b. For each of the fields listed below, enable auditing by opening the property
with the twistie and selecting the option Audit Enabled?:
v CLASSSTRUCTUREID
v INSTANCE_STATE
v IS_TEMPLATE
v NAME
v PARENT_NODE_ID
v RESOURCE_ALLOCATION_RECORD_ID
v TOPOLOGY_ID
c. Save your changes.
d. Return to the List tab.
4. In the Object field, enter PMZHBWTNSPEC and select the Audit Enabled? check
box.
a. Open the Attributes tab.
288 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
b. For each of the fields below, select the field by opening the property with
the twistie and select the option Audit Enabled?:
v ALNVALUE
v ASSETATTRID
v NUMVALUE
v REFOBJECTID
c. Save the changes.
d. Return to the List tab.
5. In the Select Actions menu, select Apply Configuration Changes and click
OK.
Note: Changes must be applied in admin mode if there is already data present
in the PMZHBWTN table.
Authorizing users to access reports
The maxadmin user can authorize other users in a group to generate and access
reports.
Procedure
1. Log on to the administrative interface as user maxadmin.
2. Click Go To > Security > Security Groups.
3. Select the user group to be authorized.
4. Switch to the Applications tab.
5. Perform the steps for each of the following applications:
v Service Definitions
v Service Deployment Instances
a. Open the application.
b. Ensure that the user group has at least read access to the application.
c. Activate Grant Access? for the option Run Reports.
6. Click Go To > Administration > Reporting > Report Administration.
7. Select Action > Set Application Security.
8. Filter the application table by entering PMZHB in the application row.
9. Click the New Row button to add access rights for the security group to the
Service Definitions and Service Deployment Instances applications. In the
Detail section of the dialog, check the BIRT Reports? option.
10. Click OK.
11. Apply the changes by restarting the WebSphere Application Server.
Alternatively, you can switch the Admin Mode off and then on again in order
to refresh the system cache.
What to do next
Note: If security exceptions persist as a result of making these changes, restart the
WebSphere Application Server.
Chapter 4. Administering 289
Generating, viewing, and scheduling reports
Authorized users can generate the reports and view them immediately, or schedule
them in the future.
About this task
For authorized users, the entry Run Reports is presented in the Select Action
menu of the panels for the Service Definitions and Service Deployment Instances
applications. This menu item opens a window showing all previously imported
reports associated with the current application.
Procedure
1. Log on to the administrative interface as a user who has privileges to access
reports.
2. On the home page, next to the Go To menu, click Reports > Service
Automation, and select the type of reports that you want to access.
The Reports window is displayed. The On Demand Reports tab lists all
currently defined report types, and the Scheduling Status tab lists information
for previously scheduled reports.
v To run a specific report immediately:
a. In the On Demand Reports tab, select the report type. The Request Page
window for the indicated report type opens, where you can specify
additional parameters.
b. Specify any required parameters to limit the output. The date parameters
refer to the date that the service definition or deployment instance was
last changed.
c. Select Immediate to run the report without scheduling.
d. Click Submit.
The report is generated in HTML format and presented online in the BIRT
Viewer application.
v To schedule a report to run in the future, either once or on a recurring basis:
a. In the On Demand Reports tab, select the report type that you want to
schedule. The associated Request Page window is displayed.
b. Specify any required parameters to limit the output. The date parameters
refer to the date the service definition or deployment instance was last
changed.
c. To generate the report once, in the Schedule section, select At this time,
and click the Select Date icon to select the date and time.
d. To generate the report on a periodic basis, in the Schedule section, select
Recurring and click the Select Value icon to select a schedule or time
interval.
e. In the Email section enter one or more validated email addresses, and
specify the output format.
f. If required, enter a subject and comments. If the Subject entry is omitted,
the report description is used as the subject.
g. Click Submit.
Tip: For authorized users, the entry Run Reports is also present in the Select
Action menu of the panels for the Service Definitions and Service Deployment
Instances applications. This menu item opens a window that shows all
previously imported reports that are associated with the current application.
290 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Working with usage and accounting reports
If you have integrated your Tivoli Service Automation Manager installation with
Tivoli Usage and Accounting Manager, you can generate reports on usage of the
services for the accounting purposes.
Note: Ensure that you have configured both Tivoli Service Automation Manager
and Tivoli Usage and Accounting Manager , as described in Integrating Tivoli
Usage and Accounting Manager on page 266.
Project account and the account code structure
If you are planning to use the Tivoli Usage and Accounting Manager reporting
function, each team in the self-service user interface must be assigned a project
account. The project account value is part of the account code structure that is
defined in Tivoli Usage and Accounting Manager.
The account code structure reflects the chargeback hierarchy for the organization.
Tivoli Usage and Accounting Manager uses an account code to identify entities for
billing and reporting. This code determines how Usage and Accounting Manager
interprets and reports input data.
The account code consists of the following elements:
Table 34. Account code structure
Identifier Length in characters Description
Account_Code 40 consisting of:
<CUSTOMER> 12
<PROJECTACCOUNT> 20
<PERSONGROUP> 8
Account_Code consists of
three values:
<CUSTOMER> unique
customer short name
<PROJECTACCOUNT> the
project account value that is
specified in the Create Team
and Modify Team requests
<PERSONGROUP> unique
team identifier
Deployment_Owner 30 The user that requested the
project.
Service_Definition 4 First four characters of the
service definition name, used
to identify the service in a
report.
Deployment_Instance 30 The name of the project the
server is associated to.
Chapter 4. Administering 291
Generating Tivoli Usage and Accounting Manager reports
You can use the Tivoli Usage and Accounting Web Reporting application to
generate reports on service usage.
About this task
The Tivoli Usage and Accounting Manager Web Reporting application provides
comprehensive cost accounting, chargeback, and resource reporting in a
browser-based environment. You can generate reports on service usage based on
the information from the CSR files that are retrieved from the Tivoli Service
Automation Manager server. You can save, copy text from, and print reports. In
addition, many reports include multi-level drill-down capabilities that enable you
to view detailed resource usage and cost information.
Note: In Tivoli Service Automation Manager 7.2.4.4, metering support is extended
for the usage of additional disks, so an additional column Tivoli Service
Automation Manager Additional Storage GB Hour is displayed in the report.
Procedure
1. Start Web Reporting from a supported browser by typing http://host_name in
the address bar, where host_name is the server name or IP address of the server
that is running Web Reporting.
2. From the menu bar, select Reports > Run Reports, then select report type.
3. In the window that opens, select parameters for the report and click OK. The
report is generated.
What to do next
For more information about working with reports, see IBM SmartCloud Cost
Management > Version 7.1.2 > Administering web Reporting > Working with reports in
the IBM Tivoli Usage and Accounting Manager knowledge center.
Managing cloud networks
Use the Cloud Network Administration application to manage your cloud
networks or to configure network DCM objects.
About this task
Perform the following steps to open the application:
Procedure
1. Log on to the administrative user interface.
2. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
292 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Network template management
Network templates are used during the Create Customer offering to define the
initial network setup that the new customer gets.
Network templates can be created by:
v Importing the sample network template files provided with the product. For
more information, see Importing network-related artifacts.
v Creating a network template within the cloud network administration
application. The related tasks are:
Creating a network template
Adding a network segment
Adding a subnetwork
Adding a virtual switch template
Deleting a network segment
Deleting a subnetwork
Deleting a virtual switch template
Network templates are visible in the self-service user interface as soon as their
status is set to active. The related task is:
v Changing the status of a network template
A network template can be modified at any time. It is used only during the Create
Customer offering in the self service user interface to create a customer network
configuration instance.
Note: Modifying a network template only affects newly created customers.
Importing network related artifacts
Use the Cloud Network Administration application to import Data Center Model
(DCM) definitions and network templates.
Before you begin
To access the Cloud Network Administration application, log on to the
administrative user interface and click Go To > Service Automation >
Configuration > Cloud Network Administration.
About this task
To import the network configuration:
Procedure
1. Click Import Network DCM Objects, browse for the XML file that you want to
import, and click Import. If any problems appear during the import, a dialog
box informs you about it. After the DCM definitions are imported, they become
available in Tivoli Service Automation Manager.
2. Click Import Network Template xml and browse for a network template XML
file to import a network template. In the window that appears, specify the
name and description for the network template.
Note: At this point, Tivoli Service Automation Manager checks whether:
v The template conforms to the network template schema.
Chapter 4. Administering 293
v The DCM resources referenced from the network template already exist.
They are referenced by their name so there can be only one resource with the
specified name for the given type in the DCM database.
v The network segment names are unique within the network template.
v The subnet names are unique within a network segment.
v The network segment usage values exist in the PMZHBNETSEGUSAGE domain.
v The network segment names are unique within the template
v The subnet names are unique within a network segment.
3. After the network template is imported, press Enter in the Name input field to
see the imported template.
4. Set the status of the network template to Active.
Creating a network template
You can use the Cloud Network Administration application to create a network
configuration template.
Procedure
1. Log on to the administrative user interface.
2. Select Go To > Service Automation > Configuration > Cloud Network
Administration.
3. Click the New Network Template button in the application menu. A new
empty network configuration template is created.
4. Specify a name and click Save. The network configuration template editor
at the bottom of the page is enabled.
5. In the network configuration template editor:
a. Define network segments.
b. Associate subnetworks with network segments.
c. Define virtual switch settings for each subnetwork.
Note: For each network configuration template at least one network segment of
type "Management" must be defined. Each network segment must have at least
one subnetwork associated with it. This subnetwork must have a reference to
an existing DCM subnetwork object that specifies the network parameters
(network address, netmask, gateway, blocked IP ranges). At least one virtual
switch template must be defined for each subnetwork.
Results
A new network template is created. You can use the Cloud Network
Administration application to edit network configuration templates. This procedure
is done using the built-in graphical editor. Changes to network templates affect
only new customers. Editing a network configuration comprises:
v Adding and removing network segments
v Modifying network segments (for example, change the network segment type)
v Adding subnetworks to segments
v Removing subnetworks from segments
v Editing virtual switch template settings for subnetworks
294 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Viewing network segments
You can use the Cloud Network Administration application to view and then
modify network segments.
About this task
Perform the following steps to view a network segment:
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, open the Network Templates list to list all
network templates.
3. Select a network template. The Network Details tab is displayed.
Results
In the Network Segment section of the Network Details tab, all the network
segments are listed. The following information is displayed for each network
segment:
v Network segment name
v Segment type
v Description
v Segment usage
You can now perform a variety of tasks on the network segments.
Adding a network segment
You can use the Cloud Network Administration application to add new network
segments.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
3. Click New Network Segment.
4. Specify the name and type of the new network segment.
5. In the DNS Settings tab, specify the required information in the fields.
6. In the Subnetwork Settings tab, fill in the required fields and select an
associated subnetwork data object.
7. Click Save.
Chapter 4. Administering 295
Deleting a network segment
You can use the Cloud Network Administration application to remove a network
segment from a network configuration template.
Procedure
1. Log on to the administrative user interface.
2. Select Go To > Service Automation > Configuration > Cloud Network
Administration.
3. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments defined for this
template.
4. Click the Mark Row for Delete icon next to the network segment that you
want to remove.
5. Click Save.
Viewing subnetworks
You can use the Cloud Network Administration application to view a list of
existing subnetworks.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
3. Click the View Details icon next to the name of a network segment to display
its details.
4. Switch to the Subnetwork Settings tab.
Results
The following information about the network segment is listed:
v Subnetwork title
v Subnetwork description
v Associated subnetwork data object
v IP address
v Subnetwork mask
Adding a subnetwork
You can use the Cloud Network Administration application to add a new
subnetwork to one of the existing network segments.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
296 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
3. Click the View Details icon next to the name of a network segment to display
its details.
4. Switch to the Subnetwork Settings tab.
5. Click New Subnetwork Reference
6. Specify the subnetwork title and the associated subnetwork data object.
7. Click Save.
Deleting a subnetwork
You can use the Cloud Network Administration application to remove a
subnetwork that is assigned to network segments.
Procedure
1. Log on to the administrative user interface.
2. Select Go To > Service Automation > Configuration > Cloud Network
Administration.
3. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments that are defined for
this template.
4. Click the View Details icon next to the name of a network segment to display
its details.
5. Open the Subnetwork Settings tab.
6. Click the Mark Row for Delete icon next to the subnetwork that you want to
remove.
7. Click Save.
Viewing virtual switch templates
You can use the Cloud Network Administration application to view a list of virtual
switch templates assigned to a subnetwork.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
3. Click the View Details icon next to the name of a network segment to display
its details.
4. Switch to the Subnetwork Settings tab.
5. Click the View Details icon in the Virtual Switch Templates column.
Results
A new section is displayed with tabs that include information about virtual switch
templates for the supported hypervisors.
Chapter 4. Administering 297
Adding a virtual switch template
You can use the Cloud Network Administration application to add a virtual switch
template to a subnetwork.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
3. Click the View Details icon next to the name of a network segment to display
its details.
4. Switch to the Subnetwork Settings tab.
5. Click the View Details icon in the Virtual Switch Templates column. A new
section is displayed with tabs that include information about virtual switch
templates for the supported hypervisors.
6. Click New Virtual Switch Template Reference.
7. Specify the required information in the fields.
8. Click Save.
Deleting a virtual switch template
You can use the Cloud Network Administration application to delete a virtual
switch template.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template. The Network
Details tab is displayed with a list of all network segments.
3. Click the View Details icon next to the name of a network segment to display
its details.
4. Switch to the Subnetwork Settings tab.
5. Click the View Details icon in the Virtual Switch Templates column. A new
section is displayed with tabs that include information about virtual switch
templates for the supported hypervisors.
6. Click the Mark Row for Delete icon next to the virtual switch template that
you want to delete.
7. Click Save.
298 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Changing the status of a network template
You can set the status of an imported network template to ACTIVE, DRAFT or
INACTIVE.
About this task
After a network template is imported, it is in the DRAFT status. A network
template with this status is not visible in the self-service user interface during the
customer on-boarding process in the network template box. If you want a network
template to be displayed in the self-service user interface, set its status to ACTIVE.
If you want to remove a network template from the selection box and indicate that
the template is no longer valid, set the status to INACTIVE.
Procedure
1. To access the Cloud Network Administration application, log on to the
administrative user interface and click Go To > Service Automation >
Configuration > Cloud Network Administration.
2. Select a previously imported network template.
3. In the Cloud Network Template Status section, click the icon next to the Status
field.
4. Select the new status.
5. Click Save on the toolbar to save this change.
Note: Changes of the status of a network template are reflected in the
self-service user interface in the following way:
v After you import a network template, it is in status DRAFT and is not
displayed in the dropdown box for network templates in the Create
Customer window of the self-service user interface.
v After you set the status to ACTIVE, the network template is displayed in the
dropdown box for network templates in the Create Customer window of the
self-service user interface.
v After you set the status to INACTIVE, the network template is not displayed
in the dropdown box for network templates in the Create Customer window
of the self-service user interface.
Network configuration instance management
The network configuration instances are created during the Create Customer or
Create Project offerings.
During customer creation process, a network template is assigned to the customer.
This assignment creates an instance (copy) of the selected network template that is
used in subsequent provisioning operations related with the customer. Subsequent
changes to the network configuration template are not promoted to the instances.
The network configuration instances are of two types:
Customer network configuration instance
Customer network configuration instances are created during the Create
Customer offering from the select network template. They can be modified
in the Instances tab of the network template in the Cloud Network
Administration application. There is no editor for these instances. Changes
are made by exporting or importing the instance, or by modifying the
XML file. For more information, see:
v Importing a customer network configuration instance
Chapter 4. Administering 299
v Exporting a customer network configuration instance
Note: Modifications only affect the selected instance and recently created
projects.
Project network configuration instance
Project network configuration instances are created during the Create
Project offering from the customer network configuration instance. The
customer status of the logged-on users defines which customer network
configuration instance is used in the default setting. Project network
configuration instance can be modified in the Cloud Network
Administration application by selecting the network template and then
moving to the Instances tab. For each customer a list of project network
configuration instances is displayed. There is no editor for these instances.
Changes are done by exporting or importing the instance, or by modifying
the XML file. For more information, see:
v Importing a project network configuration instance
v Exporting a project network configuration instance
Note: Modifications only affect the selected instance and servers recently
added to the related project.
Viewing network configuration instances
You can use the Cloud Network Administration application to view a list of
network instances related to a network template.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, open the Network Templates list to list all
network templates.
3. Select a template and open the Network Instances tab.
Results
A list of all network configuration instances related to this network template is
displayed. The following information is provided about each network instance:
v Name and Description
v Associated Customer
v Usage Type: Customer
v Status of the network instance
300 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Importing a customer network configuration instance
You can use the Cloud Network Administration application to import or update a
network configuration instance.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. Select a network template and switch to the Network Instances tab. The
Network Instances list contains information about all customer network
configuration instances associated with this network template.
3. Click the Import new Network Instance icon located in the same row as the
network configuration instance that you want to update.
4. Select the network instance XML file and click Import. The current version of
the customer network configuration instance is replaced by the imported one.
Exporting a customer network configuration instance
You can use the Cloud Network Administration application to export a network
configuration instance.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. Select a network template and switch to the Network Instances tab. The
Network Instances list contains information about all customer network
configuration instances associated with this network template.
3. Click the Export Network Instance icon located in the same row as the
network configuration instance that you want to export.
4. Copy and save the content of the dialog window to the required location.
Viewing project network configuration instances
You can use the Cloud Network Administration application to view a list of project
network configurations related to a network instance.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. Select a network template and switch to the Network Instances tab. The
Network Instances list contains information about all customer network
configuration instances associated with this network template.
3. Click the View Details icon next to the name of a network instance to view its
details.
Chapter 4. Administering 301
Results
A list is displayed that shows all project network configuration instances available
for the selected customer network configuration instance. The following
information about each project network configuration is provided:
v Name and description
v Associated customer
v Service deployment instance
v Usage type: project
v Status of the project network configuration
You can navigate to the related service deployment instance and customer.
Importing project network configuration instance
You can use the Cloud Network Administration Application to update a project
network configuration.
Procedure
1. Log on to the administrative user interface.
2. Select Go To > Service Automation > Configuration > Cloud Network
Administration.
3. Select a network template and click the Network Instances tab. The network
instances list contains information about all customer network configuration
instances associated with the network template.
4. Click the View Details icon next to the name of a customer network
configuration instance to display the list of the project network configuration
instances.
5. Click the Import New Project Configuration icon located in the same row as
the project network configuration instance that you want to update.
6. Select the project network configuration XML file and click Import. The current
version of the project network configuration instance is replaced by the
imported one.
Exporting a project network configuration instance
You can use the Cloud Network Administration application to view a list of project
network configurations related to a network instance.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. Select a network template and switch to the Network Instances tab. The
Network Instances list contains information about all customer network
configuration instances associated with this network template.
3. Click the View Details icon next to the name of a network instance to view its
details. A list is displayed that shows all project network configuration
instances available for the selected customer network configuration instance.
You can navigate to the related service deployment instance and customer.
4. Click the Export Project Configuration icon located in the same row as the
description of the project network configuration that you want to export.
5. Copy and save the content of the dialog window to the required location.
302 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Viewing customers
You can use the Cloud Network Administration application to view a list of
customers assigned to a network template.
Procedure
1. Open the application:
a. Log on to the administrative user interface.
b. Click Go to > Service Automation > Configuration > Cloud Network
Administration.
2. In the Network Administration tab, select a network template.
3. Switch to the Customers tab.
Results
A list of all customers associated with this network template is displayed in the
Customers section.
Configuring overlapping subnetwork
You can define or import subnetworks that have the same IP address range and
same subnet mask. However, when you define such networks, ensure that the
subnetwork names and VLANs are unique. The overlapping IP addresses is only
supported for VMControl Hypervisor.
Validating DCM subnetwork for overlapping IP
During the import of a DCM subnetwork definition template, you can configure to
enable validation of subnetwork for overlapping IP ranges. This task describes the
configuration options to set the validation elements during the import of a
subnetwork template.
About this task
The validation can be configured using the PMRDP.Net.SubnetworksValidation
system property. Possible values of the property are:
v Not set: Strict validation is active. At the default validation level, only the start
IP address and the netmask are validated.
v Relaxed: Consider blocked ranges in the subnetwork definitions.
v Disabled: Do not validate subnetwork definitions. Set this to Disabled if you
want to use the overlapping IP for subnetwork.
Procedure
1. Log on to the administrative user interface.
2. Select Go To > System Configuration > Platform Configuration > System
Properties.
3. Click New Row and add the PMRDP.Net.SubnetworksValidation property.
4. In the Global Value field, enter one of these values for the property: Disabled.
5. Save the changes.
6. Click Live Refresh icon. A window appears.
7. Select the values that are to be updated. The new global value is automatically
set as the current value.
Note: If you want to revert to the default setting, perform the following steps:
Chapter 4. Administering 303
a. Log on to the administrative user interface.
b. Select Go To > System Configuration > Platform Configuration > System
Properties.
c. Delete the PMRDP.Net.SubnetworksValidation property.
d. Save the changes.
Managing virtual server resources
You can administer virtual servers for various host platforms.
Increasing the maximum memory settings for System p
You can modify the value for the maximum memory that is available for LPAR
virtual servers.
About this task
The following procedure does not change:
v Future reservations - The values to create an LPAR are taken from the virtual
server template that has been created for the specific Create Project request.
v Saved images - The LPAR settings are stored in a virtual server template and
cannot be modified.
Procedure
1. Schedule an outage for all virtual LPAR servers which were previously
deployed with the old maximum values.
2. Log on to the administrative user interface as user maxadmin.
3. Select Go To > Service Automation > Configuration > Cloud Server Pool
Administration.
4. Filter for the System p cloud pool for which you want to modify memory
settings.
5. Click the Disable button in order to disable the cloud server pool.
6. Change the values in the Provisioning Parameters tab as needed. For
example, specify the maximum memory in MB.
Note: During provisioning, in case of insufficient resource, resource check is
done on all host platforms that are available in the same pool. If available,
then it is allocated and the data structures are updated accordingly.
7. Log on to HMC.
8. Modify the max.memory value in the profile settings for each existing LPAR for
which you want to increase memory.
9. Stop the LPAR servers for which the settings changed and then start them.
10. Using the Cloud Server Pool Administration application, run CEC discovery.
This process updates the maximum values in the data center model for the
provisioned LPARs.
11. Enable and validate the cloud pool.
Results
v Every max.memory field for each virtual server is updated in the data model.
v The memory for each LPAR virtual server can now be dynamically increased in
the self-service user interface.
304 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v If resources are allocated from a different host platform of the same pool, then
the data structures are updated after allocation.
Moving servers to another host for System p cloud server
pools
The Live Partition Mobility feature is implemented for System p Cloud Server
Pools only. The Server Management tab in the Cloud Server Pool Administration
application lists all servers that run on host and are associated with the current
cloud server pool. Click Move Server To Another Host to trigger the Live Partition
Mobility operation for a selected server. The HMC selects the default settings
automatically for Live Partition Mobility.
About this task
Procedure
1. Go to Server Pool Administration.
2. Open Server Management tab. A list of all servers that run on host and are
associated with the current cloud server pool are displayed.
3. Click Move Server To Another Host. You cannot move the server in case the
following conditions exist:
v A VIO-server must not be moved to other hosts.
v The move is not possible whenever the pool is enabled. You must disable to
avoid complications and inconsistencies that might occur because of parallel
provisioning operation.
A Live Partition Mobility is triggered for the selected server and the Move
Server Operation window is displayed. The Move Server Operation list all
possible targets for the movement of the selected server.
4. In the Move Server Operation window, select the target host where you want
to move the server instance.
Important:
If an LPAR is configured for a particular shared processor pool, the target
server must provide the same shared processor pool with sufficient resources.
There is no resource check performed on the list of target servers that are
displayed. Insufficient resources on the target CEC causes the operation to fail.
5. Click Move Server.
Creating an administrative role for VMware users
To access and administer the VMware system, users must log on to the vCenter
server and they must have administrative permissions. You can create a
customized VMware user role with the permissions that make it possible to
perform administrative tasks. Then, you can associate the new role with a specific
user or group of users.
Before you begin
You must be logged on as a user with Aministrator rights.
Procedure
1. In the vSphere Client Home page, click Administration > Roles > Add roles.
2. In the Add New Role panel:
Chapter 4. Administering 305
a. Type the Name for the new role.
b. Select at least the following privileges:
Table 35. The minimum rights of a VMware administrative user
Privilege name Options to be selected
Data store
v Allocate space
v Browse DataStore
Distributed Virtual Port Group
v Create
v Modify
v Delete
Network
v Assign Network
v Configure
v Move Network
Resources
v Assign virtual machine to resource pool
Virtual Machine Select all permissions in this group.
c. Click OK.
Assigning provisioning workflows for VMware additional disk
feature
If you are using the VMware additional disk feature, each ESX server must be
assigned the workflow for provisioning additional disks. This workflow is called
vmware_HostPlatform_AddStorage2 and is assigned to the existing servers
automatically when the feature is installed. When additional ESX servers are
discovered after product installation, you must assign this workflow manually.
For additional information about provisioning workflows, see theDeveloping
automation > Provisioning workflows and automation packages in the Tivoli
Provisioning Manager v7.2.0.2 knowledge center.
Assigning provisioning workflow to an ESX server
When other than the default device model "Cloud VMware VirtualCenter Host" is
associated to ESX hosts, you must add the workflow for provisioning additional
disks to this ESX server. The default device model will be extended automatically
during discovery.
Procedure
1. In the administrative user interface, click Go To > IT Infrastructure >
Provisioning Inventory > Provisioning Computers.
2. In the Computer field, filter for the required ESX server.
3. Once selected, go to the Workflows tab.
4. Click Assign provisioning workflow to assign the workflow for provisioning
additional disks.
5. Select vmware_HostPlatform_AddStorage2.
6. Click Save.
Results
The new workflow for provisioning additional disks is now assigned to the ESX
server.
306 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Assigning provisioning workflows to multiple ESX servers
If multiple ESX servers are discovered after product installation, you can run a
script that assigns the workflow for provisioning additional disks to every
discovered ESX server.
Procedure
1. Connect to the Maximo database using the DB2 client. For example, on a Linux
system connect by running the following command:
source ~ctginst1/sqllib/db2profile
db2 connect to maxdb71 user maximo
2. Run an SQL script to assign the workflow to any new discovered ESX servers:
db2 -f /opt/IBM/SMP/maximo/tools/maximo/en/cl_ad_pmp/assign_workflow.sql
3. Close the database connection using the following command:
db2 disconnect all
Results
The vmware_HostPlatform_AddStorage2 workflow for provisioning additional disks
is now assigned to any discovered ESX servers. If you navigate to the Provisioning
Computers application and search for any newly discovered ESX server, you can
confirm that the workflow for provisioning additional disks has been assigned to
this ESX server.
Managing server images
This section describes the procedures for administering server and software
images.
Creating operating system image templates
Before templates can be used by Tivoli Service Automation Manager to fulfill a
service request, there are special requirements that must be met.
Creating operating system image templates for KVM
By building one or more KVM templates, you can deploy multiple virtual machine
images in your environment.
The documentation includes information about creating operating system image
templates for the following operating systems:
v Windows Server 2003
v Windows Server 2008
v Windows Server 2008 R2
v Windows Server 2008 R2 SP1
v Red Hat Enterprise Linux
v SUSE Linux Enterprise Server
Chapter 4. Administering 307
Preparing a Windows image:
Configure the Windows image templates that you want to use for provisioning the
target virtual machines.
Before you begin
If you create the Windows 2008 64-bit R2 images, with Cygwin version greater
than 1.5 you must use preinstalled Cygwin method. Post-install Cygwin method is
not supported in this case. For more information, see Installing Cygwin on page
315
Note: For the Windows 7 64-bit images, Cygwin version 1.7.9-1 is not supported.
Windows 2008 64-bit R2 is the only certified Windows flavor for Cygwin 1.7.9-1.
Important: Only 32 bit version of Cygwin is supported.
About this task
This procedure applies to all supported Windows platforms. If a step is needed
only for specific platforms, that is indicated in parentheses.
Important:
v Use only virtual images without snapshots. Existing snapshots must be
integrated before you convert the virtual image to a template.
v Only virtual images with one hard disk configured can be deployed.
Procedure
1. Create a new virtual machine. Install a clean version of one of the following
operating systems:
v Windows 2003
v Windows 2008
v Windows 2008 R2
v Windows 2008 R2 SP1
Note: In case of windows 2003 extract sysprep tools deploy.cab from OS
installation disc to c:\Sysprep.
2. Install the Windows operating system on the virtual machine with the
minimum requirements for disk space and memory. During provisioning,
Tivoli Service Automation Manager extends the virtual machine disk partition
to the requested size.
Note: (Windows 2008) Specify at least 512 MB of RAM and 16-GB disk space.
3. Disable the firewall.
4. After the installation is completed, prepare a Cygwin installation file with the
name cloud_cygwin_install.zip:
a. Go to http://www.cygwin.com/ and download the Cygwin (version 1.7.1)
installable files to the \TEMP\CYGWIN directory. During the setup process,
when installing the packages for the first time, setup.exe does not install
every package. Only the minimal base packages from the Cygwin
distribution are installed by default. Click Categories and then Packages in
the setup.exe package installation screen to control what is installed or
308 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
updated. To install every Cygwin package, select the Default field next to
All category. For Windows 2008, use all packages available.
b. When the download is completed, you can find a folder named after the
URL of the mirror chosen during the installation in the\TEMP\CYGWIN
directory. Open that folder.
c. Copy the contents of that folder back into the \TEMP\CYGWIN directory and
delete the folder.
d. Place the following post-configuration scripts into the \TEMP directory:
postInstallAfter.bat, postInstallBefore.bat, shutdown.bat
e. Create the cloud_cygwin_install.zip compressed file with the contents of
the \TEMP\CYGWIN directory.
5. Copy cloud_cygwin_install.zip to the Windows virtual machine under the
root directory C:\.
6. Extract cloud_cygwin_install.zip on the Windows virtual machine. The
C:\TEMP directory now contains a CYGWIN folder.
7. Copy the file cloudPostinstallWindows.zip, from /opt/IBM/tsam/files/ on
the Tivoli Service Automation Manager management server, to the Windows
virtual machine under the root directory C:\ and extract it there.
8. Ensure that the contents of the \TEMP directory and the \TEMP\CYGWIN directory
reflect the contents and structure of the compressed file.
9. The scripts in the KVM directory are to be used for Windows image template
configuration.
10. Add the cloud_disable_autologon and the cloud_win2008R2.bat for Windows
2008 or cloud_win2003.bat for Windows 2003 scripts to the C:\temp\scripts\
folder. You can find these scripts in the cloudPostinstallWindows.zip
package.
11. Modify the files cloud_setup2008.bat and cloud_win2008.reg for Windows
2008 or cloud_setup2003.bat and cloud_win2003.reg for Windows 2003.
Change the password into the same as the administrator password.
12. Run script C:\temp\scripts\cloud_setup2008.bat for Windows 2008 or
C:\temp\scripts\cloud_setup2003.bat for Windows 2003.
13. Power off the Windows template, copy the disk file and the XML
configuration file, to the KVM repository for discovery.
14. Discover the Windows template and register the image through the user
interface.
15. For Windows 2008 or Windows 2008 R2, replace the instcygw-local.bat file
with the file provided.
Preparing a Linux image:
Configure the Linux image templates that are used for provisioning the target
virtual machines.
Before you begin
v Only one hard disk can be configured per image.
v No logical volumes should be included on the hard disk.
v Partition one must be the boot partition (/boot) and partition two the root
partition (/).
v Root (/) partition should be mountable externally to allow for configuring
network settings. Avoid creating a swap partition to reduce provisioning time.
Chapter 4. Administering 309
v Image size should be reduced as much as possible before making it available for
provisioning. Resize the file system to the size of data contained in the image
and resize the image hard disk to the size of the file system.
v The size of the root partition of the Linux image can be increased to the amount
specified by the user during provisioning. The tool resize2fs is used to modify
the size of the root partition, and the minimum required version is 1.39. SUSE
Linux Enterprise Server 10 SP2 ships with version 1.38, so a manual upgrade of
the tool in the image is required. To check the version of the tool, run the
following command on your image: # resize2fs.
v The file system on the root partition must be ext 3 or 4.
v For SUSE, bootloader must be installed in the Master Boot Record (MBR) and
not in the partitions.
v The following UNIX tools must be available in the Linux installation to enable
disk size modification in the Modify Server Resources request:
resize2fs, version 1.39 or higher
parted
fdisk
sfdisk
grep
sed
awk
tail
cut
Procedure
1. Create a new virtual machine using virt-manager.
2. Install the Linux Operating System on the virtual machine (Red Hat or SUSE)
with the minimum requirements. During the provisioning, Tivoli Service
Automation Manager extends the virtual machine disk/file system to the
requested size.
Note: Do not create templates with Volume groups during OS installation to
avoid provisioning failures.
a. Remove the SWAP partition, if any.
b. Use the minimum amount of disk space and memory size required. For
example, 5 GB of disk space and 1024 MB of memory.
3. After the operating system is installed, perform the following steps:
a. Stop the local firewall and set it to manual start.
SUSE
1) Select YaST > Security and Users > Firewall.
2) In the Service Start section, set the firewall startup to manual
and stop the firewall.
Red Hat
Disable the firewall and Security Enhanced Linux.
b. Remove persistent network interfaces.
SUSE
1) cd /etc/udev/rules.d
310 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
2) Edit the file 30-net_persistent_names.rules and remove all the
network entries, leave only comments.
Note: When the image is built, these entries reappear after each
reboot. Ensure that you repeat this step every time the virtual
machine reboots before converting the image to a template.
Red Hat
1) cd /etc/sysconfig/network-scripts
2) Remove all files matching the token ifcfg-eth*.
c. Remove all ssh keys in the root home directory, if any.
d. Remove all the ssh host keys, if any: cd /etc/ssh; rm ssh_host*
SUSE Linux Enterprise Server 11 image - PolicyKit Settings for Authorization free shut
down:
The default PolicyKit settings interfere with the Stop Server and Restart Server
use cases on the provisioned virtual server. Perform the steps in this section to
change the default settings.
Procedure
1. Log in to the virtual machine.
2. Open a terminal and run the following command:
polkit-gnome-authorization
3. In the left pane of the window that is displayed, navigate to
org.freedesktop.consolekit.system and click Stop the System.
4. Edit the Implicit Authorization for Anyone, Console and Active Console to
Yes.
5. Click Modify. Provide root authentication.
6. Close the window.
Red Hat Enterprise Linux 5.4 image:
Obtain a Red Hat 5.4 image and place it in a corresponding directory in the KVM
image server.
About this task
To provision virtual machines with KVM in Tivoli Service Automation Manager,
the image templates must be stored on the KVM image server.
Procedure
1. On the KVM image server, in the /repository/kvmimages directory, create a
directory, for example for Red Hat Enterprise Linuxrhel.
2. Inside the rhel directory, create another one, rhel54, where you will store the
image.
3. Name the image disk file with the same name of the directory, for example,
rhel54.img, and place it in the newly created directory.
4. Name the XML configuration file with the same name of the directory,
example, rhel54.xml, and place it in the newly created directory.
Important: Ensure that the .xml and .img files are placed in the correct
directory, that is in the second directory below /repository/kvmimages.
Chapter 4. Administering 311
What to do next
Now, you have to prepare the created template so that it can be used by Tivoli
Service Automation Manager to fulfill a service request. See Preparing OS image
templates for Tivoli Service Automation Manager on page 325.
Creating operating system image templates for VMware
By building one or more VMware templates, you can deploy multiple virtual
machine images in your environment.
The documentation includes information about creating operating system image
templates for the following operating systems:
v Windows Server 2008
v Windows Server 2008 R2
v Red Hat Enterprise Linux
v SUSE Linux Enterprise Server
Important: Drive-letter Z: must be free within the Windows template and available
for Tivoli Provisioning Manager to mount installation sources (e.g. for ITM agent
installation). If Z is not free, installation will fail because this drive-letter is always
used to mount the installation source.
Note:
v To work with VMware templates, you must have installed the VMware Tools
package.
v Do not create or use templates that have a MAC address set manually. In Tivoli
Provisioning Manager, each MAC address must be unique, and MAC addresses
created manually for VMware virtual servers are not supported. When copying a
template with manually set MAC address to another ESX or VirtualCenter,
ensure that you edit the manual MAC address to a new unique one or set it to
automatic.
v Even when automatic MAC generation is set, the same MAC address might be
generated for two templates. Ensure that the MAC address is unique for each
template as this is required for Tivoli Provisioning Manager.
Preparing a Windows image:
Configure the Windows image templates that you want to use for provisioning the
target virtual machines.
Before you begin
If you create the Windows 2008 64-bit R2 images, with Cygwin version greater
than 1.5 you have to to use preinstalled Cygwin method. Post-install Cygwin
method is not supported in this case. For more information, see Installing
Cygwin on page 315
Important: Only 32 bit version of Cygwin is supported.
Note: For the Windows 7 64-bit images, Cygwin version 1.7.9-1 is not supported.
Windows 2008 64-bit R2 is the only certified Windows flavor for Cygwin 1.7.9-1.
Note: For Windows 7, change the power-saving settings. Go to Control Panel >
Hardware > Power Option > Change when the computer sleeps. Set Put the
312 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
computer to sleep to Never. In this way, you will prevent your VM from going
into suspended mode after you added a new disk.
About this task
This procedure applies to all supported Windows platforms. If a step is needed
only for specific platforms, that is indicated in parentheses. For special
platform-dependent requirements, including minimum build levels of the ESXi and
vCenter Server components, see Planning for Tivoli Service Automation Manager
on page 28
Important:
v Use only virtual images without snapshots. Existing snapshots have to be
integrated before you convert the virtual image to a template.
v Only virtual images with one hard disk configured can be deployed.
Procedure
1. From the VMware Infrastructure Client, click Inventory and select Hosts and
Clusters.
2. Select the ESX server from the data center cluster to be managed by Tivoli
Service Automation Manager.
3. Create a new virtual machine.
4. Install the Windows operating system on the virtual machine with the
minimum requirements for disk space and memory. During provisioning,
Tivoli Service Automation Manager extends the virtual machine disk partition
to the requested size.
Note: (2008) Specify at least 512 MB of RAM and 16-GB disk space.
5. Install the Microsoft Sysprep tools on your vCenter Server machine. Microsoft
includes the Sysprep tool set on the installation CDs for Windows. It also
distributes Sysprep from the Microsoft website. To customize Windows, you
must install the Sysprep tools either from your installation disc, or from the
Microsoft download package.
For detailed information about this topic, visit the VMware Knowledge Base:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US
&cmd=displayKC&externalId=1005593.
Note: The Sysprep version is specific to the operating system:
Windows Server 2003 x64
v Location: C:\Documents and Settings\All Users\Application
Data\VMware\VMware VirtualCenter\sysprep\srv2003-64
v Download: http://www.microsoft.com/downloads/
details.aspx?familyid=C2684C95-6864-4091-BC9A-52AEC5491AF7
&displaylang=en
v Instructions: Extract the contents of the EXE and then extract the
file SP2QFE\deploy.cab. Copy these files to the srv203-64 folder.
6. Install VMware Tools on the Windows virtual machine image.
a. Open the console on the newly created virtual machine.
b. Select VM > Guest > Install/Update VMware tools.
7. After the installation completes, prepare a Cygwin installation file with the
name cloud_cygwin_install.zip.
Chapter 4. Administering 313
a. Go to http://www.cygwin.com and download the latest Cygwin
installable files to the \TEMP\CYGWIN directory with at least the following
packages: alternatives, ash, base-files, base-passwd, bash, bzip2, coreutils,
crypt, csih, cygrunsrv, cygutils, cygwin, cygwin-doc, db, diffutils,
editrights, expat, findutils, gawk, gdbm, gettext, grep, groff, gzip, less,
libiconv, login, man, minires, ncurses, openssh, openssl, pcre, perl, popt,
readline, rebase, run, sed, setup.exe, tar, tcp_wrappers, termcap, terminfo,
texinfo, tzcode, unzip, which, zip, zlib. For Windows 2008, use all
packages available.
b. When the Cygwin download completes, change to the \TEMP\CYGWIN
directory. There should be a directory named after the URL of the mirror
chosen during the installation. Change to that directory.
c. Copy the contents of the URL directory back into the \TEMP\CYGWIN
directory.
d. Delete the URL directory from the \TEMP\CYGWIN directory.
e. Place the post configuration scripts into the \TEMP directory:
postInstallAfter.bat, postInstallBefore.bat, shutdown.bat,
postInstallAfterCloning.bat, cloud_cygwin_ssh_config_cloning.sh.
f. Create the cloud_cygwin_install.zip compressed file with the contents of
the\TEMP\CYGWIN directory.
Note: You can also opt for a preinstalled Cygwin scenario. For more
information, see Installing Cygwin on page 315.
8. Copy cloud_cygwin_install.zip to the Windows virtual machine under the
root directory (C:\)
9. Extract cloud_cygwin_install.zip on the Windows virtual machine. The
C:\TEMP directory should now contain a CYGWIN folder.
10. Copy the file, cloudPostinstallWindows.zip, located in /opt/IBM/tsam/files/
on the Tivoli Service Automation Manager management server to the
Windows virtual machine under the root directory (C:\).
11. Extract the file C:\cloudPostinstallWindows.zip on the Windows virtual
machine.
12. Ensure the contents of the \TEMP directory and the TEMP\CYGWIN directory
reflect the contents and structure in the compressed file.
13. (Vista, 2008) Disable the firewall: Control Panel > Administrative Tools >
Services
Important: The save/restore function can save running images on VMware.
However, when the saved image is restored, the image is booted. For
Windows 2003 and 2008, the Windows shutdown event tracker realizes this
issue and prompts at the root console for the shutdown reason. Since the root
console is typically not accessible to users, this feature must be disabled.
Detailed instructions are available at: http://support.microsoft.com/kb/
293814
14. Shut down and power off the virtual machine.
15. From the VMware Infrastructure Client, right-click the virtual machine and
select Template > Convert to Template.
16. Follow the wizard instructions and save the template to the image data store.
Results
You created a Windows template.
314 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Important: If a VMware template that is already registered in Tivoli Service
Automation Manager, and it has to be modified, do not clone the virtual machine,
because then you will not be able to use the modified VMware template. Instead,
do the following procedure:
1. Use VirtualCenter to convert the template into a virtual machine.
2. Start the VM and modify it as required.
3. Convert the VM back into a template.
What to do next
Now, you have to prepare the created template so that it can be used by Tivoli
Service Automation Manager to fulfill a service request. See Preparing OS image
templates for Tivoli Service Automation Manager on page 325.
Note: Do not use VMware Infrastructure Client to provision a virtual machine
from the created template. Virtual machines should be provisioned by the Tivoli
Service Automation Manager self-service user interface only. See Creating a project
and adding virtual servers in the product Users Guide for more details.
Tip: If the timezone for the provisioned servers is not set correctly, as a
workaround, you can set the sysprep.timezone attribute for the server template. It
is described in the Tivoli Provisioning Manager information center. (See Table 4:
Hidden Parameters for VMware in User Guide > Configuring virtual servers > Managing
virtual servers and host platform servers using VMware > Part 3: Creating a virutal
server > Creating virtual servers.)
Installing Cygwin:
You can install Cygwin directly from the Internet or from a local directory.
Before you begin
If you create a Windows 2008 R2 template with preinstalled Cygwin version
1.7.9-1, refer to Creating Windows 2008 R2 template when using preinstalled
Cygwin 1.7.9-1 on page 316.
Important: Only 32 bit version of Cygwin is supported.
Procedure
1. Make sure that the \TEMP\CYGWIN directory on your computer contains only the
following files:
v cloud_cygwin_ssh_config.sh
v configure_ssh.sh
v instcygw-local.bat
Delete all other files.
Note: If opened in notepad on a Windows server, the .sh files inside the TEMP
folder need a format conversion from dos2unix. There is a command
dos2unix.exe in Linux and Cygwin which makes the file compatible again if
opened on a Windows server.
2. Go to http://www.cygwin.com.
3. Click setup.exe and download the file.
4. Run setup.exe from your computer.
Chapter 4. Administering 315
5. Select a download source:
Install from Local Directory
Select this option if you have the files locally. Otherwise, choose Install
from Internet.
Install from Internet
Select this option if you do not have the files locally. The downloaded
files will be saved for future use.
Click Next and follow the installation wizard.
6. In the Select Packages window, select the packages and the respective
installation options. Click Next to complete the installation. Once the
installation is complete you can see a Cygwin icon on the desktop.
Tip: In case of an error while selecting the packages, choose Reinstall.
7. Remove the Cygwin packages or keep them for future use.
What to do next
Important: In Windows 2003 64-bit, steps to allow Cygwin to use applications
from system32:
1. Remove the CD/DVD drive.
2. Implement the following hotfix: http://support.microsoft.com/kb/942589 .
Important: When you will be asked to permanently add the
%SystemRoot%\sysnative or ;%WinDir%\sysnative to your path, follow the
instructions found here: http://technet.microsoft.com/en-us/library/cc736637.
Complete the procedure described in Preparing a Windows image on page 312,
starting from step 13.
Creating Windows 2008 R2 template when using preinstalled Cygwin 1.7.9-1:
You must perform additional steps when creating a Windows 2008 R2 template
with preinstalled Cygwin version 1.7.9-1.
Procedure
1. Create a virtual machine and install Windows 2008 R2 64-bit operating system
on it.
2. Disable the firewall.
3. Install the VMware tools on the Windows virtual machine image:
a. Open the console on the newly created virtual machine.
b. Select VM > Guest > Install/Update VMware tools.
4. Modify the Recycle Bin properties:
a. Select Dont move files to the Recycle Bin, Remove files immediately
when deleted.
b. Clear the Display delete confirmation dialog check box.
5. Create a temp folder on drive C:\ and copy the following files into it: From:
/opt/IBM/tsam/files/cloudPostinstallWindows.zip/PreInstalledCygwin/temp.
v cloud_cygwin_ssh_config_preinstalled.sh
v postInstallAfter.bat
From: /opt/IBM/tsam/files/cloudPostinstallWindows.zip/temp directory
316 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v shutdown.bat
v postInstallBefore.bat
v postInstallAfterCloning.bat
v cloud_cygwin_ssh_config_cloning.sh
6. Install Cygwin in the Virtual Machine as the Administrator user.
7. After Cygwin installation completes, copy cloud_cygwin_ssh_config.sh to the
C:\cygwin\bin directory. The file cloud_cygwin_ssh_config.sh is present in the
/opt/IBM/tsam/files/cloudPostinstallWindows.zip package that must be
owned by Administrator. When you extract this package, two folders are
created: PreInstalledCygwin and temp. The cloud_cygwin_ssh_config.sh file
can be found in the temp/cygwin folder.
8. Convert the virtual machine to template, and run image template discovery to
use the template.
Tip: If the following error message is displayed:
The Recycle Bin on C:\ is corrupted. Do you want to empty the Recycle
Bin for this drive? follow the instruction provided in Common problems
and solutions on page 486.
VMware Windows provisioning with changed built-in administrator account name:
Non-standard built-in administrator account name for Windows system
provisioning and management.
Tivoli Service Automation Manager provisions VMware Windows guests with
non-standard administrator accounts. When a used Windows image is registered,
Tivoli Service Automation Manager renames the build-in administrator account to
the name specified in the Administrative User Account field of the self-service UI.
The renamed account retains identical management rights of the built-in
administrator account, and it is further used to manage the system.
Note: No account must have the account name that was given during the
registration of Windows image.
Ensure that the command-line interface WMIC for Windows Management
Instrumentation (WMI) is available in your master image. It is the case for default
installation. After provisioning, all management functions are called through ssh,
which is realized by cygwin.
Attention: Only Windows templates that have a built-in Administrator account are
supported.
A built-in account has extended account permissions in combination with cygwin.
The built-in Administrator accounts SID ends with -500. If it is not the case, then
use the unchanged account.
Tip: The custom Tivoli Provisioning Manager workflows do not need any
customization because all communication and execution, such as
Device.ExecuteCommand use the service access point that is configured for RSA
authentication with the changed administration account name.
Chapter 4. Administering 317
Preparing a Linux image:
Configure the Linux image templates that are used for provisioning the target
virtual machines.
Before you begin
Important:
v Requirements for the virtual machine:
Only virtual images without snapshots may be used. Existing snapshots must
be integrated before you convert the virtual image to a template.
Only one hard disk (vmdk) can be configured per image.
v Requirements for the guest partition:
No logical volumes (lvm) should be included on the hard disk.
The root (/) partition must be the last partition (/). A swap partition after the
root partition is tolerated.
Root (/) partition should be mountable externally to allow guest
configuration.
The file system on the root (/) partition must be ext 3 or 4.
v For SUSE, bootloader must be installed in the Master Boot Record (MBR)
and not in the partitions.
v Performance:
Reduce the image size as much as possible before making it available for
provisioning. Resize the file system to the size of data contained in the image
and resize the image hard disk to the size of the file system.
Avoid including a swap partition in the template to reduce provisioning time.
Swap space is created dynamically during provisioning, if requested.
v Requirements for the guest operating system:
Depending on the Linux version, the following components must be present
before the installation:
-
Table 36.
Architecture libstdc++ libgcc
li6243/li6246 32bit agent for
Linux Intel kernel 2.4
(RHEL3,SLES8)
libstdc++-2.96-98 N/A
li6263/li6266 32bit agent for
Linux Intel kernel 2.6
(RHEL4, RHEL5,
SLES9,SLES10)
libstdc++-3.3.3-43.41 libgcc-4.1-4.1.2_20070115-0.2
lx8266 64bit agent for Linux
x64 kernel 2.6
libstdc++-3.4.4-2 libgcc-3.4.4-2
lia266 64bit agent for Linux
IA64 kernel 2.6
libstdc++-3.2.2-23 libgcc-3.2.2-23
lpp266 64bit agent for Linux
PPC kernel 2.6
libstdc++-3.3.3-43.41 libgcc-3.3.3-43.41
ls3243 31bit agent for zLinux
kernel 2.4 (RHEL3,SLES8)
libstdc++-3.2.2-54 libgcc-3.2.2-54
318 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 36. (continued)
Architecture libstdc++ libgcc
ls3246 64bit agent for zLinux
kernel 2.4 (RHEL3,SLES8)
libstdc++-3.2.2-54 libgcc-3.2.2-54
ls3263 31bit agent for zLinux
kernel 2.6 (RHEL4, RHEL5,
SLES9,SLES10)
libstdc++-3.3.3-43.34 libgcc-3.3.3-43.34
ls3266 64bit agent for zLinux
kernel 2.6 (RHEL4, RHEL5,
SLES9,SLES10)
libstdc++-3.3.3-43.34 libgcc-3.3.3-43.34
The following UNIX tools must be available in the Linux installation:
- resize2fs version 1.39 or higher or ext2online on older Linux versions
- parted
- fdisk
- sfdisk
- grep
- sed
- awk
- tail
- cut
- bc
For Red Hat Enterprise Linux 6 x64 and SUSE Enterprise Linux 11 x64 in
combination with VMware 5, you must install:
- The following 32 bit and 64 bit compat-libstdc++libraries:
v compat-libstdc++-296.2.96.i386
v compat-libgcc-296.2.96.i386
v compat-libstdc++-33.3.2.3.x86_64
v compat-libstdc++-33.3.2.3.i386
v libXpm-3.5.5-3
- Parted version 1.8.1 that is available at http://ftp.gnu.org/gnu/parted/
onto the virtual machine, logging in as root.
Then, proceed to create a template as for any other Red Hat Enterprise Linux
x64 or SUSE Enterprise Linux x64 versions.
These tools are used during configuration of the guest.
To install DB2 on Red Hat Enterprise Linux 6.2 provisioned VM, a
libstdc++.so.6 rpm package is required.
Procedure
1. From the VMware Infrastructure Client, click Inventory and select Hosts and
Clusters.
2. Select the ESX server from the data center cluster to be managed by Tivoli
Service Automation Manager.
3. Create a new virtual machine.
Note: While creating CentOS templates supported by Tivoli Service
Automation Manager using VMware versions lower than 4.1, ensure that you
select Red Hat Enterprise Linux as the guest OS type.
Chapter 4. Administering 319
4. Install the Linux Operating System on the virtual machine (Red Hat or SUSE)
with the minimum requirements. During the provisioning, Tivoli Service
Automation Manager extends the virtual machine disk/file system to the
requested size.
Note: Do not create templates with Volume groups during OS installation to
avoid provisioning failures.
a. Remove the SWAP partition, if any.
b. Use the minimum amount of disk space and memory size required. For
example, 5 GB of disk space and 1024 MB of memory.
c. Ensure that the file systems on the root partition are set to ext 3 or ext 4.
5. After the operating system is installed, perform the following steps:
a. Stop the local firewall and set it to manual start.
SUSE
1) Select YaST > Security and Users > Firewall.
2) In the Service Start section, set the firewall startup to manual
and stop the firewall.
Red Hat
1) As root, disable the firewall by typing the following
commands:
service iptables save
service iptables stop
chkconfig iptables off
2) Disable Security Enhanced Linux:
a) Type: edit /etc/selinux/config
b) Change the SELINUX line to be as follows:
SELINUX=disabled
b. Ensure that the bootloader is installed in the Master Boot Record.
SUSE
1) Select YaST > System > Boot Loader.
2) Click the Boot Loader Installation tab and go to the Boot
Loader Location section.
3) Clear the Boot from Boot Partition check box.
4) Select the Boot from Master Boot Record check box.
c. Remove persistent network interfaces.
SUSE
1) Type: cd /etc/udev/rules.d
2) Edit the file 30-net_persistent_names.rules (for SUSE Linux
Enterprise Server 11, edit 70-persistent-net.rules) and
remove all the network entries, leave only comments.
Note: When the image is built, these entries reappear after
each reboot. Ensure that you repeat this step every time the
virtual machine reboots before converting the image to a
template.
Red Hat
1) Type: cd /etc/sysconfig/network-scripts
320 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
2) Remove all files matching the token ifcfg-eth*.
3) For Red Hat Enterprise Linux 5.4 and CentOS 5.4 templates,
edit the /etc/rc.local file in the template and add a line:
service network restart
at the end of this file.
d. Remove all ssh keys in the root home directory, if any.
e. Remove all the ssh host keys, if any: cd /etc/ssh; rm ssh_host*
6. For SUSE Linux Enterprise Server 11, verify that the red prompt is disabled on
the terminal. Open the terminal, and if the prompt appears in color red,
follow the steps below, otherwise ignore:
a. Edit /etc/bash.bashrc and comment the PS1="\[$_bred\]$PS1\[$_sgr0\]"
line as shown in the example:
if test "$UID" -eq 0 -a -t ; then
_bred="$(path tput bold 2> /dev/null; path tput setaf 1 2> /dev/null)"
_sgr0="$(path tput sgr0 2> /dev/null)"
# PS1="\[$_bred\]$PS1\[$_sgr0\]"
unset _bred _sgr0
fi
7. Install VMware tools.
a. Open the console of the newly created virtual machine.
b. From the console for the virtual machine, select VM > Guest >
Install/Update VMware tools.
c. Open a terminal and access the VMware tools by typing the following
commands:
mkdir -p /media/cdrom
mount /dev/cdrom /media/cdrom
ls -l /media/cdrom
You see the VMware tools software.
d. Copy VMware tools software to a temporary directory and unpack it by
typing the following commands:
cd
mkdir temp_vmwtools
cd temp_vmwtools
cp /media/cdrom/vmware-tools-distrib.tar.gz ./
gunzip vmware-tools-distrib.tar.gz
tar -xvf vmware-tools-distrib.tar
e. Install the VMware tools software:
1) Type the following commands:
cd /vmware-tools-distrib
./vmware-install.pl
2) Select all default options, including the option to configure VMware
tools.
3) Wait for the installation to complete.
f. Tidy up the temporary directory by typing the following commands:
cd ../..
rm -rf <temporary directory>
g. Click VM > Guest and check the menu options.
Chapter 4. Administering 321
h. (Optional) If you have such an option within your menu, click VM >
Guest > End Install VMware tools.
i. Close the terminal.
8. Once again verify the requirements described in Before you begin.
9. Shut down the guest operating system and power off the virtual machine.
10. From the VMware Infrastructure Client, right-click the virtual machine and
select Template > Convert to Template.
11. Follow the wizard instructions and save the template to the image data store.
Note: For SUSE Linux Enterprise Server 11 with vSphere version lower than
4.1 and 4.0 Update 2, while converting the virtual machine to template, you
need to change the OS type of the virtual machine to SUSE Linux Enterprise
Server 10 64-bit using Edit settings, and then convert it to a template.
What to do next
Now, you have to prepare the created template so that it can be used by Tivoli
Service Automation Manager to fulfill a service request. See Preparing OS image
templates for Tivoli Service Automation Manager on page 325.
Partition and file system requirements for the disk resize functionality:
Tivoli Service Automation Manager offers a functionality to resize a Linux virtual
machine if certain requirements are met.
When the resize is performed, three things happen :
1. The container of the virtual machine on the hypervisor is extended.
2. The partition table is modified to include the additional space.
3. The root (/) file system is resized so that additional space is available for the
user.
For second and the third point, certain assumptions are made regarding the
partition layout and the file system. These assumptions function as requirements
that must be met for the default disk resize functionality to work. However,
sometimes different partition layouts have to be supported, logical volumes have
to be included, or different file systems have to be used. In such cases, you can
customize the disk resize implementation by overwriting it with your own
implementation.
The standard disk resize implementation does not support logical volumes. It also
requires a specific layout of partitions as described in Preparing a Linux image
on page 318. You can avoid these limitations by adding custom-built scripts to the
image for handling disk resize. These are the locations for the scripts:
v /opt/IBM/tsam/config/configure_disks
v /opt/IBM/tsam/config/configure_disks_after_reboot (optional)
If the scripts exist in these locations and if they are executable files, then they
overwrite the standard implementation for disk resize.
Both scripts are called with one parameter swap_size. The
configure_disks_after_reboot script is optional. If it exists, the operating system
is rebooted before the script is called. Otherwise, the operating system is not
rebooted after exiting configure disks. Therefore, configure_disks_after_reboot
is only called if configure disks exists. Both scripts communicate success by
exiting with return code 0. Otherwise, the underlying management action is
322 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
stopped with an error.
VMware Linux provisioning with sudoer account instead of the standard root account:
The non-standard built-in "root" account name for Linux system provisioning and
management with VMware.
The Linux system to be used for image or template must work with SUDO instead
of root. The built-in root account exists, but is normally disabled for external
access, like ssh.
When the image is prepared, do the following to restrict ssh access for the built-in
root account:
1. Add or change line in /etc/ssh/sshd_config: PermitRootLogin no
2. Restart sshd service: /etc/init.d/sshd restart
Tivoli Service Automation Manager is working with RSA credential, as the user of
the client system can change passwords. Therefore, the sudoer must be configured
to do the following tasks:
v Administrative execution without password
v Add or change line in /etc/sudoers file for "<user-account-name>ALL=(ALL)
NOPASSWD: ALL" in the Linux template
The newly created user account with sudoer capability must be able to access all
executable commands that are available at the Linux system. You can customize
the exported PATH to enable this access.
During the image registration in the self-service UI, overwrite the default value
root in the Administrative User Account field with the alternative admin account
name that is prepared in a used image.
Tip: Customize the custom workflows, because during system creation, the RSA
authentication service access point is configured so that it is used together with
sudo command.
For simple commands or shell script execution through Device.ExecuteCommand, no
change is required, as the service access point handles the sudo usage during
execution.
If the command is more complex, it might be necessary to wrap the command
with bash -c "complex command chain", where internal hyphens (") must be
escaped.
Using the scriptlet, workflow inline script definition, it is required to place the
sudo in front of all commands where it is required. For example, see workflow
Cloud_Linux_Online_Configure_Disks.wkf. There is no automatic processing of
sudo even if the service access point contains the sudoers configuration.
Attention: Some Linux do not allow sudo operations unless you log in like that of
Red Hat Enterprise Linux. To enable remote login and sudo operation, comment
out Defaults requiretty in /etc/sudoer file.
bash -c "rm -f /etc/sysconfig/network/routes ;
echo \"0.0.0.0 9.152.136.1 0.0.0.0
$(ifconfig -a | egrep'HWaddr 00:50:56:00:43:56'
Chapter 4. Administering 323
| gawk'{ print $1 }')\">>
/etc/sysconfig/network/routes ;
echo \"default 9.152.136.1 - - \"
>> /etc/sysconfig/network/routes"
Creating operating system image templates for PowerVM
The following sections describe the steps to configure the operating system image
templates for PowerVM.
Preparing an AIX image:
Configure the AIX image templates that will be used for provisioning the target
virtual machines.
About this task
AIX images for provisioning must fulfill the requirements outlined in the
"Deploying operating systems" and "Deploying software" topics in the Tivoli
Provisioning Manager Provisioning User Guide. Provide your AIX administrator
with any special requirements you have for the images.
Procedure
1. The AIX administrator captures the required AIX operating system image.
2. The AIX administrator provides the root password of the captured OS image to
the Tivoli Service Automation Manager administrator. This password is
required during a Tivoli Service Automation Manager configuration step for the
images to be used by Tivoli Service Automation Manager.
What to do next
Now, you have to prepare the created template so that it can be used by Tivoli
Service Automation Manager to fulfill a service request. See Preparing OS image
templates for Tivoli Service Automation Manager on page 325.
Discovering single virtual server image templates
To save time, you can limit the scope of discovery of images that are managed by
the VirtualCenter.
About this task
Restriction: This option is available only for VMware Cloud Pools.
The previous implementations of the image template discovery discovered and
reconciled all images that were managed by the VirtualCenter. You can now limit
the scope of the discovery to a certain cluster or a number of clusters. If your
back-end is large, this image discovery can take a long time. For data validity and
consistency reasons, you should not reconcile existing registered images.
Procedure
1. Deactivate the current cloud pool.
2. In the Cloud Service Pool Administration application, click the Image
Template Discovery tab, select Discover Selected Image Templates?.
3. In the Image Template Names field, specify the name of the virtual server
image that is to be discovered or reconciled. You can specify more than one
image template name at the same time by using a comma-separated list.
324 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
4. Click Discover Selected Images.
5. To see the discovery workflow ID, name, and status that are stored in the Most
recent image discovery section, click Refresh.
Preparing OS image templates for Tivoli Service Automation
Manager
You can prepare the OS image templates that you created, so that they can be used
by Tivoli Service Automation Manager to fulfill a service request.
Procedure
1. Use the Tivoli Provisioning Manager to discover the created operating system
templates from the hypervisor environment and add them to the data center
model:
a. Log on to the Tivoli Service Automation Manager administrative user
interface.
b. Go to Service Automation > Configuration > Cloud Pool Administration.
c. Click the Cloud Pool Details tab.
d. Scroll down to find the discovery-related sections.
e. Depending on the type of your hypervisor, use one of the following
discovery procedures:
v VMware: Discover image templates for VMware.
v PowerVM: Run the NIM discovery.
v KVM: Discover KVM images.
2. Register the image to the image library. See the Managing Image Library section
in the Tivoli Service Automation Manager User's Guide.
3. You must assign the image template, either to all customers or to selected
customers.
To assign the image template to all customers:
a. Go to IT Infrastructure > Image Library > Master Images.
b. Select an image and click the Customers tab.
c. Select the Assigned to all customers check box.
d. Click Save.
To assign the image only to selected customers:
a. Go to Service Automation > Configuration > Cloud Customer
Administration.
b. Select the customers to which you want to make the virtual server image
available.
c. Click the Customer details tab and then click IL Master Images tab in the
Associated Resources section.
d. To select customers for whom the image is available, click Assign Master
Images.
e. Click Save.
Chapter 4. Administering 325
Adding a new image from VMControl
If you have added a new image in IBM Systems Director VMControl, you need to
synchronize the Tivoli Provisioning Manager image repository before the image
can be used to provision virtual machines in the self-service user interface.
About this task
Note: When importing a Virtual Appliance in VMControl, which is to be used by
Tivoli Service Automation Manager for automated provisioning, do not set the
hostname property in the corresponding OVF description file.
To register an image added via VMControl:
Procedure
1. Log on to the administrative interface and synchronize the repository:
a. Click Go To > IT infrastructure > Image Library > Image Repositories.
b. Select the repository that contains the required image (virtual appliance),
and click Synchronize Repository to bring any new images into the Tivoli
Provisioning Manager data model.
2. Log on to the self-service user interface:
a. Click Request a New Service > Virtual Server Management > Manage
Image Library > Register VM Image via IBM Systems Director
VMControl.
b. Select the required image and click OK to register it.
Results
The image can now be used to create new virtual machines.
Migrating a VMControl image from 2.3 level to 2.4.1 or 2.4.2 level
VMControl 2.4.1 and 2.4.2 provides backward compatibility for VMControl 2.3
resources.
About this task
VMControl 2.4.1 and 2.4.2 supports 3 types of images:
v NIM 23 - Network Installation Manager for version 2.3
v NIM 24 - Network Installation Manager for version 2.4
v SCS - Storage Copy Services
A NIM 23 is simply an image that is supported by VMControl 2.3.
Procedure
1. Deploy a VMControl 2.3 image in VMControl 2.4.1 or 2.4.2.
2. Capture the provisioned LPAR to NIM 24 or SCS repository.
3. Optional: If you want to create an SCS image:
a. Deploy the NIM 23.
b. Install the activation engine.
c. Stop the image using the activation engine.
d. Capture the image to the SCS image repository.
326 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Results
After this migration, the virtual images are available for provisioning using
VMControl 2.4.1 or 2.4.2.
Deleting a server image
When an image is no longer needed, you need to remove it from both the
administrative and the self service user interfaces. Moreover, any future
reservations related to this image must be canceled.
About this task
To remove an image:
Procedure
1. Log on to the self-service user interface and unregister the image from the self
service user interface.
2. To unregister the image, click Request a New Service > Virtual Server
Management > Manage Image Library > Unregister Image.
3. On the hypervisor user interface, delete the image.
4. On the administrative user interface, run the discovery.
Results
The image is deleted from Tivoli Provisioning Manager Image Library and can no
longer be used to create new servers.
Storing server images
Use separate data stores for storing images that serve different functions.
Use separate data stores for storing:
1. Provisioned images
2. Save/restore images
3. Image templates and non-Tivoli Service Automation Manager managed
resources.
Note: Do not store non-Tivoli Service Automation Manager managed resources on
the data stores used for provisioning and save/restore. If you do and they become
full, you will run into resource allocation problems.
Registering single master images to different VMware clusters
and server resource pools
You can register a single VMware template to different server resource pools.
Before you begin
You must have access to the virtual center by using a VMware Infrastructure Client
software.
Procedure
1. By using an NFS server, mount the master image datastore to the ESX server of
the VMware cluster. Initially, the NFS server has at least one dedicated network
Chapter 4. Administering 327
card where one interface is configured and exported. Configure a set of
interfaces to be used as interface to mount the NFS master image datastore. To
configure it:
v Use different network cards, where each network card has one single
interface that is configured and added to the export list.
v Configure network interface's alias interfaces on a single network card by
running ip a add 10.102.2.50/16 broadcast 10.102.255.255 dev eth1. You
can list the configuration by using ip a s.
In case of parallel provisioning, the NFS mounted datastore results in bad
performance. To avoid processing timeouts, keep the number of concurrent
provisioned systems low. Because of different sizes and overall network traffic
limitations, you must figure out the number by testing. Each ESX server
connects to the master image store by using its own IP address and NFS
mount. This configuration can be performed for an NFS mounted master image
datastore as well. In such case, you do not have to use different IP addresses.
2. Register the image to the ESX server, that is to the vCenter library. Use different
names for each image. Think about a naming convention, for example, use an
image name stem adding a sequence number when you register it to the cluster
ESX servers (example: SLES11_1, SLES11_2).
3. Run the template discovery. You have registered single master image template
source to multiple VM clusters. You have also registered them with different
names to the vCenter library which resulted in differently named image library
master image entries. You can associate them to different customers and
therefore to different server resource pools.
What to do next
The disadvantage is the bottleneck in the network traffic capabilities. To avoid it,
follow the instructions described here Multiplying VMware template metadata.
Multiplying VMware template metadata
About this task
You cannot manipulate the connection to the datastore content by using different
IP addresses. Therefore, you cannot apply the FlashCopy feature to avoid the
performance bottleneck that caused by the network and NFS mounted master
image datastore. In a SAN storage, you cannot use a command shell or access the
file system in a similar way to copy and edit the image metadata.
To multiply the VMware template metadata:
Procedure
1. Download the vmtx file from the single image template by using the VMware
Infrastructure Client.
2. Update the file name and the display name with identical names. Use a naming
convention to differentiate between the source and copy, for example SLES11,
SLES11_C1. The names must be unique in a vCenter. If one of the master
images gets deleted, all copies cannot be used any more. Therefore, you are
advised to use the master image or template datastore as read-only to avoid
deleting it by accident.
3. Upload the updated vmtx file to the directory from which you downloaded it.
328 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
4. Add a new virtual machine template to the inventory of ESX server in different
cluster as compared to the registration of the source master image or template.
5. Run the discovery. The discovery lists the new master images in image library
master images. You can assign them to individual customers or server resource
pools.
Enabling the restore across project offerings
Learn about the assumptions that have to be met and about the procedure of
enabling the restore across project offerings.
Before you begin
Any project can have an individual network configuration. The restore across
project offerings can be performed successfully only if the source and the target
network configurations are equal. For this reason, Tivoli Service Automation
Manager ships the restore across project offerings disabled. As long as you do not
use the network extensibility function for a network configuration at individual
project level, you can enable the restore across project offerings again. To
successfully enable the restore across project offerings, the following requirements
must be met:
v The network extensibility to create project level network configuration is not
being used.
v The network configuration of the saved image is equal to the project the saved
image should be deployed in.
If the above mentioned assumptions are valid for your environment, you can
enable the following restore across project offerings:
v Create Project from saved Image
v Add Server from saved Image
Note: If the assumptions are not valid anymore and you want to enable these
offerings, disable the restore across project offerings again.
Procedure
1. Log on to the administrative user interface as PMSCADMUSR or as a user who has
the same privileges.
2. Open the offerings application by selecting Go To > Service Request Manager
Catalog > Offerings.
3. Locate the PMRDP_0248A_72 (Add Server from Saved Image) offering.
4. Change the status of the offering from pending to active. Save the changes.
5. Locate the PMRDP_0249A_72 (Create Project from Saved Image) offering
6. Change the status of the offering from pending to active. Save the changes.
Results
The restore across project offerings are available in the Web 2.0 UI as offerings.
What to do next
If you want to disable one or both of the restore across project offerings, repeat the
procedure and change the status of each of the offerings from active to pending.
Chapter 4. Administering 329
Controlling user access
This section provides information about the security policy, user roles, and data
segregation within Tivoli Service Automation Manager.
Security in the administrative user interface
Learn about the security concepts and roles in Tivoli Service Automation Manager.
The discussed functions are performed with the administrative user interface.
Security information in stored in two places in the Maximo environment:
v In the WebSphere Application Server, with one or more configured LDAP
servers
v In the Maximo database
Therefore, some of the security-related items (for example, security groups and
users) need to be configured in two places. However, tools are provided that
enable you to keep the definitions in LDAP and the Maximo database in sync.
Security concepts
The Maximo platform offers a highly sophisticated security framework. Security
can be categorized as follows:
Authentication
Implemented via WebSphere Application Server security and LDAP.
Authentication checks whether a user is known to the system and whether
the credentials that are provided are valid for database access.
Authorization
Handles user access rights for certain entities. Access rights are defined
using security groups. Once a user is authenticated, the authorization checks
what the user is permitted to do. Authorization is provided by
membership in one or more security groups. All security groups a user
belongs to make up the security profile of a user. Access rights are checked
by the system against the user's security profile. Security groups can
restrict access to various areas, including applications, sites, data
restrictions, start centers, and so on. Security groups can be configured to
provide access to specific catalogs and can also control the offerings that
are restricted within these catalogs.
Roles and work assignments
Whenever an interactive task is triggered by a workflow, the task is
assigned to one or more persons. Roles control the assignment of these
tasks. Roles are used as part of communication templates, escalations,
service level agreements, or workflow processes. When a role is used
within a process, the database management software determines which
users to route the process to based on information within the role record.
Roles do not serve any function related to security authorizations. The
security groups associated with a user ID determine the security
authorization of that user.
Security elements provided by Tivoli Service Automation Manager
v To configure security in the Maximo environment, you must configure security
groups, roles, users, persons, and person groups.
v Most of these activities are customer specific, and therefore need to be
configured at your site.
330 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v Tivoli Service Automation Manager provides a set of predefined groups and
roles to which your users can be mapped.
Here is an overview of the roles and security groups that are provided by Tivoli
Service Automation Manager.
Table 37. Roles and groups provided by Tivoli Service Automation Manager
Role Description
Person Group (8
chars) Role (10 chars)
Security Group (must
be created in LDAP)
Service Administrator TSAMSADM PMZHBSADM PMZHBSADM
Service Definition Designer TSAMSSDD PMZHBSSDD PMZHBSSDD
Service Definition Manager TSAMSSDM PMZHBSSDM PMZHBSSDM
Service Deployment Instance Manager TSAMSSIM PMZHBSSIM PMZHBSSIM
Service Deployment Instance Operator TSAMSSIO PMZHBSSIO PMZHBSSIO
Service Resource Allocation Manager TSAMSRAM PMZHBSRAM PMZHBSRAM
WebSphere Cluster Service
Performance - AIX Administrators TSAMPAXA PMZHBPAIXA PMZHBPAIXA
Performance - WAS Administrators TSAMPWAS PMZHBPWASA PMZHBPWASA
Performance - Linux Administrators TSAMPLXA PMZHBPLNXA PMZHBPLNXA
Performance Monitoring Administrator TSAMPPMA PMZHBPPMA PMZHBPPMA
Self-Service Virtual Server Provisioning component
Tivoli Service Automation Manager
Administrator (for Self-Service Virtual
Server Provisioning)
Not applicable
PMSCADMUSR PMSCMADMUSR
Note:
v A corresponding role exists for each security group. Therefore, a user who is
assigned a task can easily also be configured to have authorization to accomplish
the task.
v The PMZHBTSAMR security group is a special security group that consists of
read authorization for all Tivoli Service Automation Manager applications. The
intent of this group is to simplify a configuration where, for example, a z/VM
administrator can gain read access to all other Tivoli Service Automation
Manager-related applications.
v The PMZHBTSAMR security group also configures the Tivoli Service
Automation Manager Start Center.
v The security groups only contain authorizations to Tivoli Service Automation
Manager applications. If a user in a certain role requires access to other
applications, this must be configured by the local Maximo security administrator.
v The shipped configuration of each role includes a person group. All of these
person groups contain only MAXADMIN as a person entry. Therefore, in the
default configuration, all tasks are assigned to MAXADMIN. This can be
re-configured with standard security tooling.
Chapter 4. Administering 331
v For details on how to manage security (for example, creating roles, persons,
person groups, and users), refer to the documentation that is supplied with the
CCMDB product (although Tivoli Service Automation Manager does not actually
use it).
Pre-Configured Roles provided for Tivoli Service Automation Manager:
Service Definition Manager
The Service Definition Manager role is designated for users who are
responsible for triggering and tracking new service definitions. This role is
also responsible for assigning the tasks for new definitions to designers,
and to approve designed service definitions for instantiation.
Service Definition Designer
The Service Definition Designer role is designated for users who are
responsible for creating new service definitions when instructed to do so
by a service manager.
Service Deployment Instance Operator
The Service Deployment Instance Operator is designated for users who are
responsible for instantiation of designed and approved service definitions.
These users operate service instances, such as starting a job plan.
For self-service offerings, users assigned to this group are authorized to
troubleshoot unexpected problems that arise with the automated
fulfillment of service requests submitted by members of the PMRDPUSR
(Offering Catalog user) group.
Service Deployment Instance Manager
The Service Deployment Instance Manager role is designated for users who
are responsible for controlling and approving the execution of service
instances.
Service Resource Allocation Manager
The Service Resource Allocation Manager role is designated for users who
manage the allocation of resources (CIs) to service instances. For example,
servers that are represented in CIs can be allocated to a specific instance.
Service Administrator
The Service Administrator role is a 'super user' for all aspects of service
definitions and instances. This user has the authority to exercise all the
functions of a Service Deployment Instance Manager, Service Deployment
Instance Operator , Service Definition Designer, and Service Definition
Manager.
For self-service offerings, the administrator performs a series of tasks that
set up the applications to enable service requesters to initiate and manage
the requests. This administrator also manages the offering catalog.
Performance: AIX Administrators
Users in this role are responsible for all kinds of performance and problem
determination tasks related to AIX systems.
Performance: WAS Administrators
Users in this role are responsible for all kinds of performance and problem
determination tasks related to WebSphere systems.
Performance: Linux Administrators
Users in this role are responsible for all kinds of performance and problem
determination tasks related to Linux systems.
332 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Performance Monitoring Administrator
Users in this role are responsible for all kinds of problem determination
tasks. They have the authority to perform all tasks that are defined in the
performance and problem determination tasks.
Tivoli Service Automation Manager Administrator (for Self-Service Virtual
Server Provisioning)
Users in this role perform various administrative tasks that are available
only in the administrative interface, such as managing the offering catalog
for the Self-Service Virtual Server Provisioning component.
Security management in the self-service user interface
In the self-service user interface, the administrator defines user access and rights
by customer and team assignment, policy level, and security groups.
A user can be assigned to one customer, either the default global customer, or any
other specified by the requester. Optionally, a user is assigned to one or more
teams.
A user can be assigned to multiple customers, but assignment must be done only
by the cloud administrator.
A new security step is also introduced in the Create User and Modify User
requests, where the requester specifies the privileges and permissions of the new
user. Permissions include the rights a user has to access data in the cloud, which
depend on his policy level, and the rights that a user can grant to other users by
means of the grant option. Privileges are the requests a user can submit, and they
are managed by assignment to security groups. For each user, the following
settings can be specified:
v Customer
Administrators always create users in the context of the customer for which they
are working when they request that a user be created. The customer cannot be
changed later. If you have the required privileges, you can select a customer in
the title bar of the main panel before submitting any request.
v Team
Team assignment is not obligatory, but to be able to use a project, the user must
be a member of the team that has access to this project. A user can be a member
of more than one team, but all of the teams must belong to the same customer.
v Policy level
Policy levels define which cloud objects or resources the user can access. Two
policy levels are predefined:
Cloud level
Users on this level can access the information and resources available in
the cloud, regardless of customer limits. They are assigned to a default
global customer called PMRDPCUST.
Customer level
Users in this level are always assigned to one customer only; however,
the cloud admin can choose to assign the user to multiple customers
using the multi-customer option.
v Security groups
Each user can be assigned to seven predefined security groups. Each group
defines which requests the user can submit, and what information they can
access. Groups can be combined. When creating a user, you can also specify the
grant option for each security group. When the grant option is checked for a
Chapter 4. Administering 333
security group, the user is allowed to create new users and assign them to that
security group. Security groups are described in detail in Security groups in the
self-service user interface.
To create users for the self-service interface and add them to the teams, submit the
appropriate requests in this interface. See the Managing Users section in the Tivoli
Service Automation Manager User's Guide.
In addition to the individual settings for user accounts, the administrator can also
enable approval of self-service requests. Cloud administrators, cloud customer
administrators, and cloud approvers have permissions to approve the requests. If a
new request for a customer is submitted, all the approvers assigned to this
customer are notified. Any of them can grant approval. The approval process is
disabled by default and all requests are auto-approved. For more information
about enabling the approval function, see Enabling or disabling automatic
approval of requests on page 350.
Security groups in the self-service user interface
User authorizations for the Tivoli Service Automation Manager self-service
interface are managed with security groups. Group membership determines which
requests the user can access. Seven predefined security groups are available in the
self-service user interface.
A user can belong to more than one group. When you create a user, not only do
you select security groups, you also select the grant option for each group that the
user belongs to. When the grant option is enabled, the user can create new users
within the security group.
The groups for the self-service user interface include:
Cloud administrator
Users in this role are the administrators of the cloud. They can be created
only on Cloud Level Policy, and are always assigned to the PMRDPCUST
global customer. They can perform the following tasks:
v Create customers based on customer templates and delete them
v Modify their own information
v Register and unregister software images
v Allow resource allocations and changes within the whole cloud
v Check the status of projects and monitor the servers for all users
v Approve or decline provisioning requests made by cloud customer
administrators
Cloud customer administrator
Users in this role can be administrators dedicated to individual customers,
if they are on Cloud Customer Level Policy. They can perform the
following tasks:
v Define new teams, user accounts, and the associated roles for their
customers
v Modify their own information
v Allow allocations and changes to the resources assigned to their
customers
v Check the status of projects and monitor the servers for their users
v Approve or decline provisioning requests made by team administrators
334 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
If they are on Cloud Level Policy, they can perform all these tasks for any
customer.
Cloud manager
Users in this role are the read-only administrators of the cloud. They can
perform the following tasks:
v Check the status of projects and monitor the virtual servers for any team
Approver
Users in this role are administrators who are dedicated to individual
customers. They can perform the following tasks:
v Check the status of projects, and see the service requests assigned to
their customer
v Approve service requests associated with their customer
Security administrator
Users in this role can perform the following tasks:
v Create new users
v Modify and delete existing users
Team administrator
Users in this role can perform the following tasks:
v Place requests for provisioning servers and check the status of projects
v Monitor the servers
v Change the server status or password
v Log in and use the provisioned servers and applications
Team user
Users in this role can perform the following tasks:
v View projects available for their team
v Check the status of the servers provisioned for their team
v Log in and use the provisioned servers and applications
Table 38. Access to requests depending on the security group
Cloud
Administrator
Cloud
Manager
Team
Administrator Team User
Cloud
Customer
Administrator Approver
Security
Administrator
Create project v - v - v - -
Create project
from saved
image
v - v - v - -
Add server v - v - v - -
Add server
from saved
image
v - v - v - -
Clone VMware
server
v - v - v - -
Modify
reservation
v - v - v - -
Cancel project v - v - v - -
Modify server
resources
v - v - v - -
Reset server
password
v - v - v - -
Start, stop, or
restart server
v - v - v - -
Install
software
v - v - v - -
Remove server v - v - v - -
Create server
image
v - v - v - -
Chapter 4. Administering 335
Table 38. Access to requests depending on the security group (continued)
Cloud
Administrator
Cloud
Manager
Team
Administrator Team User
Cloud
Customer
Administrator Approver
Security
Administrator
Restore server
from image
v - v - v - -
Remove saved
images
v - v - v - -
Register image v - - - - - -
Unregister
image
v - - - - -
Create user v - - - v - v
Modify user
v
only their own
information
only their own
information
only their own
information
v - v
Remove user v - - - v - v
Create team v - - - v - -
Modify team v - v - v - -
Remove team v - - - v - -
Create
customer
v - - - - - -
Remove
customer
v - - - - - -
Approve and
reject requests
v v - - v v -
View requests
v v v v v
only those
requests that
require
approval
-
View projects v v v v v v -
View servers v v v v v v -
Data segregation for service providers
In Tivoli Service Automation Manager, you can use the multi-customer support
feature to segregate data.
User within a cloud other than cloud administrator is assigned to a customer. All
the requests that these users submit are automatically associated with that
customer.
Users can also be assigned to multiple customers. At a time, these users can select
a customer to administer.
A single cloud can support multiple customers, but each user only sees the objects
that are associated with the customer they are assigned to. Objects visible to an
individual customer include both customer-specific resources and resources that
are shared among customers of a cloud. Because the main focus is meeting the
specific needs of all customers, it is possible to customize data center resources so
that they meet individual requirements or are shared among customers. In this
way, resources can be used more efficiently.
The data is filtered from the moment the users log on to the self-service user
interface, so that they see only the resources available for them. The data
segregation process runs on a level-based security policy. In Tivoli Service
Automation Manager, there are two predefined levels of visibility: cloud level and
cloud customer level.
Users on cloud level policy have unrestricted visibility:
v They are assigned to the global customer PMRDPCUST.
v They can see all resources within the cloud.
v They can switch to a specific customer to work for only this customer.
336 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
v They can work with objects that belong to different teams and users.
When working in the self-service user interface, such users must select a specific
customer that they want to work for. The view is then filtered, so that they see
information related with this customer only.
On cloud customer level, users have restricted visibility:
v Users can be assigned to more than one customer.
v Users can access only the objects associated to the assigned customer.
v Security group and team assignment impose further restrictions.
On cloud customer level, customer specific objects are segregated, so that only
authorized customers can view the resources. The following resources can be
shared among multiple customers:
v Cloud server pools
v Cloud network templates
v Cloud storage pools
v Master images
v Software products
v Multi-customer user
The following resources are owned by exactly one customer:
v Teams
v Users
v Service deployment instances, also called projects
v Saved server images
Customer-specific objects and sets of predefined data restrictions for those objects
are used to implement data segregation. New tasks make managing
multiple-customer clouds possible.
The customer management tasks are used to create, modify, and delete customers.
Cloud administrators can create and delete customers in the self-service user
interface. They can use the administrative interface to create customer templates,
and modify existing customers.
Another group comprises tasks that are related to configuration of data center
resources. Cloud administrators can assign data center resources to individual or
multiple customers. Those tasks are performed within the Cloud Customer
Administration application in the administrative interface.
The Cloud Customer Administration application can also be used to define quotas
and limits that are assigned to specific customers. Quotas are sets of limits for a
specific resource pool. These limits define the amount of resources that can be
requested by an individual customer, for example the amount of storage. If service
requests are submitted that involve modification of resources or reservation time,
the framework checks whether the quotas in the requested pool allow for request
processing.
Chapter 4. Administering 337
Administering customers and their resources
Administrators can manage customer-related objects in the Cloud Customer
Administration application. Learn how to create customer templates, manage
customer-related resources, quotas, and limits by using this application.
Note: To manage cloud customers the administrator must use the Cloud Customer
Administration application provided by Tivoli Service Automation Manager. The
application available in Go To > Service Provider (SP) > Customers (SP) is not
supported to modify or create cloud customers for Tivoli Service Automation
Manager.
For more information about the application itself, see Cloud Customer
Administration application on page 6.
Tip: A Customer tab is also provided in the following applications:
v Go To > Service Automation > Configuration > Cloud Server Pool
Administration
v Go To > Service Automation > Configuration > Cloud Storage Pool
Administration
v Go To > Service Automation > Configuration > Cloud Network
Administration
v Go To > IT Infrastructure > Image Library > Master Images
v Go To > IT Infrastructure > Software Catalog > Software Products
In the Customer tab, you can view a list of customers that have access to the
selected resource. You can also use it to make the resource customer-independent
(This feature is not supported for network).
Assigning resources to a customer
Using the Cloud Customer Administration application, the administrative user can
manage the resources of a customer. A customer can use only those resources that
are assigned to them or that are defined as customer independent by marking the
Assigned to all customers? flag.
Before you begin
Ensure that the following resources have been configured correctly:
v Server pools are configured in the Cloud Server Pool Administration application.
v Network configuration is defined in the Cloud Network Administration
application.
v Master images are discovered in the Image Library.
v Optional: Additional storage resources are configured in the Cloud Storage Pool
Administration application.
v Optional: Software products are configured.
Only configured resources can be assigned to the customer. The following
procedure describes how to assign a resource to a particular customer. For more
information on making the resource available to all customers, see Assigning
resources to all customers on page 340. Network resources cannot be shared
between customers.
338 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Procedure
1. Click Go To > Service Automation > Configuration > Cloud Customer
Administration.
2. Select a customer.
3. In the Associated Resources section, select the tab for the resource type that you
want to assign to the customer.
4. Click the Assign Resource Type button under the table.
5. In the dialog that opens, select the specific resources to be assigned to the
customer.
6. Click Assign Resource Type.
Important: If you are planning to assign OS dependent software modules to
the customer, you also need to assign the software stack corresponding to the
OS master image, and ensure that it has the required properties defined. After
assigning the master image and the software module, perform the following
steps:
a. In the Cloud Customer Administration Application click Detail Menu >
Go To Master Images.
b. Next to the software stack click Detail Menu > Go To Software Stacks.
c. In the Variables tab, ensure that the software stack has the following
variables defined:
v exposetotivsam=1
v swType=OS
If they are not present, click New Row and add them.
d. Click Return to return to the Cloud Customer Administration
Application.
e. In the Software Modules tab, assign the software stack corresponding to
the image to the customer.
f. Save the changes.
Results
The selected resources are listed in the table and available for the customer.
What to do next
v If server pools or storage pools are shared among multiple customers, you can
define quotas and limits for these resources. Proceed to Defining quotas and
limits on page 342.
v Regardless of whether the resources are currently in use or not, they can be
returned to the pool. Proceed to Returning customer resources on page 340.
Chapter 4. Administering 339
Assigning resources to all customers
For each resource type, apart from network, it is possible to assign it to all
customers by default.
About this task
This task can be performed in the administrative user interface, in the application
dedicated to administering a particular resource:
v For server pools, select Go To > Service Automation > Configuration > Cloud
Server Pool Administration.
v For storage pools, select Go To > Service Automation > Configuration > Cloud
Storage Pool Administration.
v For master images, select Go To > IT Infrastructure > Image Library > Master
Images.
v For software products, select Go To > IT Infrastructure > Software Catalog >
Software Products.
Each of these applications includes the Customers tab, where the assignment can
be specified.
Procedure
1. Open the administration application for the resource.
2. Select the resource, and open the Customers tab.
3. Select the Assigned to all customers? check box.
4. Click Save.
Results
The resource pool is now shared by all customers. It is also available to any
customers created in the future.
Returning customer resources
Regardless of whether the resources are currently in use by the customer or not,
they can be returned to the pool.
Procedure
1. Click Go To > Service Automation > Configuration > Cloud Customer
Administration.
2. Select a customer.
3. In the Associated Resources section, select the tab related to the resource.
4. In the table row related to the resource, click Return Resource.
Results
The customer is not able to request any further resources in this resource pool.
Resources currently in use are not affected.
340 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Creating customer templates
Cloud customer templates can be created to facilitate the onboarding process of
new customers.
About this task
Customer templates are defined in the Cloud Customer Administration application
of the administrative user interface. They are used in the self-service user interface
to create customers.
Procedure
1. In the administrative user interface, click Go To > Service Automation >
Configuration > Cloud Customer Administration.
2. Click New Customer in the toolbar.
3. Enter a value for customer name and fill in any other required fields.
4. To change the status of the customer to active, click Change Status in the
toolbar, and select ACTIVE from the New Status list.
5. Use the tabs in the Associated Resources section to assign selected resources to
the customer. In the selected tab:
a. Click Assign resource.
b. In the dialog window that opens, select the required resources and click
Assign resource.
c. Repeat these steps for any other required resources.
6. Click Save.
7. In the Quotas and Limits tab, assign quotas for server and storage pools:
a. In the Cloud Server Pool Quotas tab, click Add Cloud Server Pool Quota.
b. In the dialog that is displayed, select the cloud server pool and click Add
Quota for Cloud Server Pools. You can now define limits for each resource
of the selected server pool.
c. Select the resource that you want to modify, and click View Details.
d. In the Details section, you can specify the value of the limit and the value at
which a warning is issued. You can also activate the limit by selecting the
check box.
v Value: Specify the limit value for the selected resource.
v Warning Value: Specify the limit at which warning is issued. This option
is only available if additional escalation is configured for warnings.
v Active?: Select this check box to activate the limit.
v Escalation Role: Specify if additional escalation is configured.
For more information about defining quotas and limits, see Defining
quotas and limits on page 342.
e. Repeat the steps in the Cloud Storage Pool Quotas tab.
f. Click Save.
Results
The customer template is available in the Create Customer request in the
self-service user interface. When a template is selected in the request, the values for
Chapter 4. Administering 341
resources and quota limits defined in this template are copied to the new customer
object. No additional configuration is required. However, the resources and limits
for a customer created from a template can still be modified in the administrative
interface.
Defining quotas and limits
You can use the Cloud Customer Administration application in the administrative
user interface to define limits for selected customers on the usage of server and
storage resources.
If a service provider shares resources among multiple customers, reservation limits
might be necessary for each customer. For example, if a storage pool of 100 GB is
shared between customer A and customer B, the service provider can set a limit of
50 GB for customer A and 50 GB for customer B. Otherwise, one customer might
be able to reserve all of the resources.
If limits are activated, a quota check is performed for each incoming service
request. The system determines whether the limit has been reached for the
customer. If the limit is reached, the service request fails. The check is performed
for Create Project, Add Server, Modify Server, and Modify Reservation requests in
the self-service user interface. The quota check is performed automatically when
the request is submitted, or manually whenever the user clicks the Check
Resources button to verify that the resources are available. The quota check is
performed with an offset of 8 hours to the scheduled end time of the project in
order to reflect the decommissioning time of the project.
The Limits section in the Quotas and Limits tab also shows the actual reservation
of the resource in the pool. A bar chart depicts how much of the available
resources in the pool are currently being used by the customer. The chart does not
account for resources reserved for the future.
Quotas and limits can be defined or modified at any time in the customer life
cycle. If limits are decreased to the point where the amount of reserved resources is
higher than the limit, the customer users are not able to request any further
resources from that resource pool.
Before you begin
A quota can be defined for cloud server pool and cloud storage pool resources and
limits can be defined for each quota. Quotas can only be defined on resource pools
that are assigned to the selected customer. For cloud server pools, limits for CPU,
memory, and file system capacity can be defined, and for cloud storage pools limit
for additional disks capacity can be defined. The following table lists the types of
quotas and limits available:
Table 39. Types of quotas and limits
Quota Type Limit Type Limit Type Description
Measure
Unit
Cloud server
pool
COMPUTERSYSTEM_MEMORYSIZE Amount of memory GB
COMPUTERSYSTEM_PROCESSCAPACITYUNITS 10th of physical CPU
COMPUTERSYSTEM_NUMCPUS Number of virtual CPUs
FILESYSTEM_CAPACITY Amount of default disk space GB
Cloud
storage pool
FILESYSTEM_CAPACITY Amount of storage on
additional disks
GB
342 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Procedure
1. In the administrative user interface, click Go To > Service Automation >
Configuration > Cloud Customer Administration.
2. In the List tab, select a customer.
3. Open the Quotas and Limits tab, and define quotas for pools in the Cloud
Server Pool Quotas and Cloud Storage Pool Quotas tabs:
a. Click Add Resource Pool Quota.
b. In the dialog window that opens, select the required resources.
c. Click Add Quota to Resource Pool.
Default quotas are now defined and no limits are assigned to a customer.
4. Define the limits for each quota that requires them:
a. Select a quota to set its limits. The Limits table shows the default values for
this quota.
b. Select limit type and click View Details.
c. In the Details section, specify the Value field. You can also specify the
Warning Value if additional escalation is configured for this value.
d. Repeat these steps for the remaining limit types.
5. When all limits for the quotas are defined, click Save.
What to do next
You can activate or deactivate each quota and limit. For more information see
Activating and deactivating quotas and limits
Activating and deactivating quotas and limits
After you define quotas for resources, you can activate or deactivate them. All
limits are active by default, but they can also be deactivated.
About this task
When a quota is inactive, the limit check is not performed, and customer users can
reserve all resources in the assigned pool. When you activate a quota, all limits for
this quota are also activated.
Procedure
1. In the administrative user interface, click Go To > Service Automation >
Configuration > Cloud Customer Administration.
2. In the List tab, select a customer.
3. In the Quotas and Limits tab, select a quota.
4. In the Active column of the Quotas table, select or clear the check box.
5. Optionally, you can deactivate a selected limit in the active quota by clearing
the check box next to it in the Limits table.
6. Click Save.
Chapter 4. Administering 343
Managing the maintenance mode
You can use the maintenance mode to stop processing requests and restrict user
access during a maintenance window.
Maintenance log
You can use the maintenance log to monitor the system when the maintenance
mode is activated. It provides the status and log details of the current maintenance
window. The Cloud Maintenance Administration application is used to manage the
log.
When the administrator activates maintenance mode, a new active log is created.
Only one active instance of a maintenance log can exist at a time. When the status
of the maintenance mode changes to ONLINE, the log becomes inactive and no
further log statements are written. Inactive log instances are marked as read-only
and can be used for history and audit purposes.
The active log is frequently updated by the system.
Maintenance log attributes
Table 40. Maintenance log attributes
Attribute Description
ID The unique identifier of the log.
Description A detailed description of the purpose for the
maintenance window.
Active A flag that indicates the active log instance.
Only one active instance exists in the system
at a certain point in time.
Internal Status An attribute that specifies the maintenance
mode status and the position in the life
cycle. The processing and behavior of the
system depend on the status.
Log An object that contains the details and log
statements that are written during the
processing. It is frequently updated and
contains, for example:
v The number of active inbox assignments.
v The number of logged-on users.
v The number of service requests in the
system per status: NEW, WAPPR,
QUEUED, INPROG, RESOLVED.
v A log statement for each status change.
Each log entry is written with the current
time stamp and status.
Date/time when the system is Quiescing A date and time when the status of
maintenance mode changes from
REQUEST_QUIESCE to QUIESCING. This
time is used to warn users before they are
restricted.
344 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 40. Maintenance log attributes (continued)
Attribute Description
Date/time when the system is Online A date and time that is used to switch from
PENDING_ONLINE to ONLINE. The time
is used to run scheduled service requests
before allowing users to submit and approve
new service requests.
Maintenance mode statuses
During maintenance mode, the system goes through a number of statuses. A status
change from the current to the next status occurs when specific conditions are met.
Each status change also triggers an action.
ONLINE
The system is online and operates as normal. Users have unlimited access.
When the administrator requests quiesce mode, the status changes to
REQUEST_QUIESCE.
REQUEST_QUIESCE
Maintenance mode was requested. Log is activated. Users are notified
about planned maintenance but they still have unlimited access. When the
start time that is specified by the administrator is reached, the status
changes to QUIESCING.
QUIESCING
The system is preparing for the maintenance mode. Users have read-only
access. No new service requests can be submitted. The system processes
any requests that are already in progress. If manual steps are required to
complete any requests, the administrator gets an inbox assignment. Some
escalations are deactivated. When no more requests are in progress, the
status changes to QUIESCED.
QUIESCED
All pending requests are processed and the maintenance window has
started. Users have read-only access. The maintenance process can be
started. When maintenance is finished, the administrator requests that the
system return to normal operation. The status changes to
REQUEST_ONLINE.
REQUEST_ONLINE
The administrator requested that maintenance mode be finished. Users
have limited access.
PENDING_ONLINE
Escalations are reactivated. Users have limited access until the status
changes to ONLINE.
The following escalations are deactivated when the system is in status:
QUIESCING, QUIESCED, REQUEST_ONLINE, PENDING_ONLINE:
Table 41. Escalations deactivated during the maintenance mode
Escalation Description
PMRDPICRSR Create RDP Service Requests for expiring
reservations
Chapter 4. Administering 345
Table 41. Escalations deactivated during the maintenance mode (continued)
Escalation Description
PMRDPWEB20ESC2 Escalation that runs the approval workflows
on SRs submitted by the Web 2.0 UI (status
NEW)
PMZHBCRDPMD Daily Collection of metering data
PMZHBISTWO Process TivSAM Service Requests, called
Scheduler (status QUEUED)
Activating the maintenance mode
You can activate the maintenance mode in Tivoli Service Automation Manager by
using the Cloud Maintenance Administration application. During the maintenance
window, requests cannot be processed and users have read-only access with the
self-service user interface.
Procedure
1. In the administrative user interface, select Go To > Service Automation >
Configuration > Cloud Maintenance Administration.
2. Create a maintenance log by clicking New in the toolbar.
3. Enter a description and start and end time of the maintenance window that
affects the users.
4. In the Select Action menu, click Request Quiesce and wait until the status
changes to QUIESCED.
Results
The log entry in the application shows the status of your request. If any manual
steps are required to complete the operation, you see a notification in the
Inbox/Assignment window. When the status changes to QUIESCED, the
management server is quiesced and cannot fulfill any further self-service requests.
Users can access the self-service user interface in read-only mode.
What to do next
When you finish the maintenance operation, you must activate the system again,
as described in Deactivating the maintenance mode.
Deactivating the maintenance mode
You must deactivate maintenance mode when the maintenance work is finished.
Procedure
1. In the administrative user interface, select Go To > Service Automation >
Configuration > Cloud Maintenance Administration.
2. If necessary, modify the time when the system status is to change to ONLINE.
3. In the Select Action menu, click Request Online and wait until the status
changes.
Results
When the status changes to ONLINE, the log is deactivated and in read-only
mode, and self-service requests can be processed again.
346 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Forcing the maintenance mode
You can use the Select Action menu in the Cloud Maintenance Administration
application to force the status QUIESCE and ONLINE . This emergency procedure
must not be used unless the normal procedure cannot be performed.
About this task
The operations described in this task do not execute the extension points and no
notifications are sent out. The Force Quiesce operation changes the status to
QUIESCED and deactivates the escalations. The Force Online operation changes
the status to ONLINE and activates the escalations.
Procedure
1. In the administrative user interface, select Go To > Service Automation >
Configuration > Cloud Maintenance Administration.
2. In the Select Action menu, click Force Quiesce.
3. When the maintenance process is finished, return to the Cloud Maintenance
Administration application, and in the Select Action menu, click Force Online.
Maintenance mode extensibility
The PMRDPQM escalation is used to process the status of the maintenance log.
Escalations contain the following settings:
v They run on active log instances only.
v By default, they run every minute.
v They include 12 reference points:
One reference point for each of the six status modes that are repeated in an
attempt to start a runbook (A).
One reference point for each of the six status modes that are not repeated in
an attempt to send out a notification once. (N)
The reference points that complete actions A continuously start a runbook based on
the status mode. For each status, a different runbook exists. All runbooks go
through the following sequence of events:
1. Append the log entry to the maintenance log.
2. Call condition C, which controls the changes in the status mode.
a. If condition C is true, an action is completed, which triggers a status
change, and extension point EXECTRUE is entered.
b. If condition C is false, no action is completed and extension point
EXECFALSE is entered.
Runbooks go through the status modes listed in Maintenance mode statuses on
page 345. The runbook changes the log status when the required conditions are
met. The EXECFALSE extension is called multiple times, whereas the EXECTRUE
extension is only called once. The workflow extension registry can be used to plug
in custom actions.
Chapter 4. Administering 347
Managing request approval, delegation, and notification
You can use the administrative user interface to configure optional settings on the
self-service user interface, such as approving and delegating requests, or changing
the notification workflows.
Communication templates for email notification
Use communication templates to standardize frequently used email notifications.
You can also use these templates to create email notifications for automated
workflow and escalation processes. A self-service provisioning involves multiple
users, all of whom must be notified of changes that affect their areas of
responsibility.
Each communication template is used for a specific purpose. The following table
lists the communication templates that are used with the Self-Service Virtual Server
Management tasks. These templates are applied to the related events, so
notifications defined by each of the shipped templates are automatically sent when
the events occur.
Table 42. Tivoli Service Automation Manager communication templates
Template Event that triggers notification
PMRDPAFREJA A service request approval was rejected; the submitting
user is notified.
PMRDPNOTAS A server has been added; the user is notified.
PMRDPNOTCP A deployment has been created; the user is notified.
PMRDPNOTDETAIL A successful execution triggers a detailed notification to
the service requester.
PMRDPNOTMS A server has been modified; the user is notified.
PMRDPNOTRP A deployment has been canceled; the user is notified.
PMRDPNOTRS A server has been removed; the user is notified.
PMRDPNOTSAVE A virtual server image has been saved; the user is
notified.
PMRDPNOTSTARTS A server has been started; the user is notified.
PMRDPNOTSTOPS A server has been stopped; the user is notified.
PMRDPRBREJ A service request approval was rejected; the submitting
user is notified.
PMRDPSRAF A service request approval is required; the affected user
is notified.
PMRDPSROK A service request was automatically approved; the
submitting user is notified.
PMRDPSRRB A service request approval is required; the user who
reported the request is notified.
PMRDPIMRR A virtual server was restored.
PMRDPIMDL A virtual server image was deleted.
PMRDPIMSV A virtual server image was created.
PMRDPNOTDPAT A Workload Deployer pattern project was created.
PMRDPNOTPEND Removal of a server is pending due to an expired
reservation.
348 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Table 42. Tivoli Service Automation Manager communication templates (continued)
Template Event that triggers notification
PMRDPNOTPENDPR Removal of a project is pending due to an expired
reservation.
PMRDPNOTPRP Removal of a Workload Deployer pattern is pending.
PMRDPNOTREMPATT A Workload Deployer pattern deployment was canceled.
PMRDPNOTRES The project reservation time was modified.
PMRDPNOTSERVEROP A server operation was carried out.
PMRDPNOTAPP Approval is required.
PMRDPIMUPG Upgrade of service instance completed.
PMRDPNOTCHPW A virtual server password was changed.
PMRDPNOTSWI Software was successfully installed.
PMRDPSRFAIL A service request failed.
PMRDPAPRREQ Informs Cloud Administrator of a required approval.
Tip: You can see more information about a template, such as the recipient, sender,
or its contents, by clicking Go To > Administration > Communication Templates
in the administrative user interface.
Note: Be aware that all communication templates that define PMZHBWLSWO in
the Applies To field, do not apply to the Work Order object, but the Service
Request object. The variable substitution of these templates is done
programmatically by Tivoli Service Automation Manager as a part of the Service
Request processing. If you modify the message text of these templates by adding
substitution variables, you can either query information from the related Service
Request ticket itself by specifying the ATRIBUTE (e.g.:TICKETID), or access attributes
from related objects by specifying RELATIONSHIP.ATTRIBUTE (e.g.:PERSON.FIRSTNAME).
The following roles are defined in Tivoli Service Automation Manager
communication templates to receive email notifications:
Table 43. Roles for email notifications
Role Definition
PMRDPNOTRQ User that issued a provisioning request.
PMRDPNOTSO Owner of the project, that is a user who created the
project.
PMRDPNOTUG Team of the user who issued a provisioning request. On
CC list.
By default, the requester and all customer team members receive a notification
regarding server requests. Cloud Administrators must be registered as team
members to receive notifications.
You can use the Communication Templates application to create, modify, and
remove the templates. The online help for this application provides a detailed
description of communication templates and how to work with them.
Chapter 4. Administering 349
Managing communication templates
You can customize the communication templates that are sent to notify users about
requests submitted in the self-service user interface.
Before you begin
A subset of the built-in communication templates is included in the self-service
virtual server provisioning service that is defined in Tivoli Service Automation
Manager. You can view a list of predefined templates, their name, and content in
the Notification tab of the Service Definitions application. You can modify, add,
and remove templates using the Communication Templates application.
Procedure
1. Click Go To > Administration > Communication Templates.
2. Filter for the template that you want to modify.
3. Modify the details as required.
4. Click Save.
Tip: For more information about managing the communication templates, see
the online help for the application.
Enabling or disabling automatic approval of requests
Requests that are submitted in the self-service interface are auto-approved by
default. You can disable automatic approval for some of the requests using the
administrative interface.
This option is available for requests related to the server only. The following
requests cannot be sent for approval:
v Install Software
v Manage Users
v Manage Teams
v Manage Image Library
By default, cloud customer administrators and cloud approvers can approve and
decline requests. Cloud administrators can approve requests if they are assigned to
the Cloud Approver security group. If a request for a customer is sent for
approval, all approvers associated with the customer are notified, and any of them
can approve the request. The approval request also shows up in an
Inbox/Assignment section in the administrative user interface.
Before you begin
Important: Before changing the pmrdp.enable.autoapproval setting, ensure that no
requests are pending approval in the system.
Procedure
1. Log on to the administrative user interface as administrator, for example
maxadmin.
2. Select Go To > System Configuration > Platform Configuration > System
Properties.
3. Filter for pmrdp.enable.autoapproval or navigate to it using the green arrows.
4. Edit Global Value and change its value to N.
350 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
5. Click Save.
6. Select the check box next to the property name and click Live Refresh to see its
current value.
7. In the Live Refresh window, filter for pmrdp.enable.autoapproval or use the
green arrows to navigate to it and click OK.
Results
The requests related to server placed in the self-service interface is sent for cloud
administrator's approval. The cloud administrators can manage requests for
approval it in the My Approvals section on the self-service interface home page.
They can approve, decline, or, if configured, delegate requests for approval.
What to do next
You can enable delegation of requests. For more information about delegation, see
Enabling or disabling delegation of approval requests.
Enabling or disabling delegation of approval requests
As a cloud administrator, you can enable the delegation of requests if you want to
reassign a pending request to a different user. You can only delegate requests that
are related to servers.
About this task
Before you can reassign requests to a different user, you must first disable
automatic approval of requests. Otherwise the requests are approved by default.
The following requests cannot be sent for approval, and, therefore, cannot be
delegated:
v Install Software
v Manage Users requests
v Manage Teams requests
v Manage Image Library requests
Procedure
1. Log on to the administrative user interface as administrator.
2. Select Go To > System Configuration > Platform Configuration > System
Properties.
3. Filter for the pmrdp.enable.delegation property or navigate to it using the
green arrows in order to edit this property.
Note: If the pmrdp.enable.delegation property does not exist, click the New
Row button. In the Property Name field, enter pmrdp.enable.delegation and in
the Description field, enter a description of your choice.
4. Edit the Global Value:
v Set the value to Y if you want to enable delegation of requests
v Set the value to N if you want to disable delegation.
5. Click Save.
6. Click Live Refresh.
7. In the Live Refresh window, filter for pmrdp.enable.delegation or use the
green arrows to navigate to it, and click OK.
Chapter 4. Administering 351
Adding new software modules
Before you can install additional software modules on the provisioned virtual
machines in the self-service user interface, you need to create software product
definitions in Tivoli Provisioning Manager and then configure them. You can access
the necessary Provisioning Manager functionality in the administrative user
interface.
Important: There are the following restrictions when defining software product for
Tivoli Service Automation Manager:
v Software module names must be unique and versioning of software modules is
not supported. As a result, different software module definitions must be created
for different versions or platforms of the same software.
v Each software module/software product definition must have only one software
installable and one (default) software resource template (SRT) associated with it.
v The default software resource template (SRT) must be in the first position.
v If the software product definition is modified after the request is submitted and
before the actual installation happens, the software installation may fail.
v Software modules representing the operating system image should expose the
os.family capability with appropriate value.
v Software modules should expose appropriate requirements and capabilities.
These requirements and capabilities will be used to verify if a given software
module can be installed on a virtual sever.
v The values for Requirements and Capabilities must be single value attributes
(not multi-valued).
v Software modules to be installed in the self-service interface must have a
software module definition and must have the exposetotivsam property defined.
v Software installation feature is independent of hypervisor at the back end. If a
server fulfills the requirements of the selected software module then that
software module is listed as installable on it.
v Make sure that the server meets the requirements of the software module which
you install. For example, DB2 recommends 1 GB of RAM to install.
Before you begin
You need to be the Tivoli Service Automation Manager administrator (maxadmin)
to perform this task.
Procedure
1. Create new software definition. See the Provisioning User Guide in the Tivoli
Provisioning Manager knowledge center, and follow the steps as described in
Deploying software > Administering installed software > Software concepts > Defining
software in the software catalog.
2. Define the exposetotivsam property:
a. Click Go To > IT Infrastructure > Software Catalog > Software Products.
b. Select the software definition from the list and click the Variables tab.
c. Select exposetotivsam, and in the Value field, specify 1.
Tip: If the value is not available, click New Row and specify the details.
d. Click Save.
3. Add a new installation workflow:
352 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
a. Select Go To > Administration > Provisioning > Provisioning Workflows.
b. Click the New Workflow icon and write a workflow.
4. Assign the new installation workflow to the software product definition. Click
Software Installables > Workflows > Assign Provisioning Workflow and
select the workflow that you have created for this definition.
5. Assign the new software module to a customer using the Cloud Customer
Administration application. For more information, see Assigning resources to
a customer on page 338.
What to do next
After you have configured the software product as described in this task, you can
install that software on a virtual machine using the self-service user interface.
Starting and stopping the middleware
You can start, stop, and check the status of the Tivoli Service Automation Manager
middleware manually, or configure the scripts so that the middleware is restarted
automatically.
Starting the management server
Use a sequence of commands to manually start Tivoli Service Automation
Manager, Tivoli Provisioning Manager, and all of their components after a
shutdown or system reboot.
About this task
All paths and profile names in the following procedure are examples only and
must be replaced by the actual values in your management environment.
Remember: Run all these commands as the root user unless otherwise specified.
Procedure
1. As root user, start DB2 database instances:
su dasusr1 c db2admin start
su ctginst1 c db2start
2. As root user, start LDAP:
/opt/IBM/ldap/V6.3/sbin/idsdiradm I idsccmdb
/opt/IBM/ldap/V6.3/sbin/idsslapd I idsccmdb
/opt/IBM/ldap/V6.3/bin/ibmdirctl -D cn=root -w <LDAP root password> start
Note: If you receive the following error:
The server is unable to run the directory server instance idsccmdb
while the admin server is running
manually stop the admin server and then start the directory server instance.
3. Start Tivoli Provisioning Manager and its WebSphere Application Server. The
procedure differs depending on which situation you are in:
Chapter 4. Administering 353
Important: During installation, ensure that the Tivoli Provisioning Manager
light-weight infrastructure runtime is not started unless explicitly mentioned in
the launchpad.
v During installation, before Tivoli Provisioning Manager is installed, as root
user, run the following commands:
/opt/IBM/WebSphere/AppServer/profiles/ctgDmgr01/bin/startManager.sh
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/bin/startNode.sh
v During installation, after Tivoli Provisioning Manager is installed, as
tioadmin, run the following command:
$TIO_HOME/tools/tio.sh start -w <wasadmin> <password>
v After installation is complete, as tioadmin, run the following commands:
$TIO_HOME/tools/tio.sh start <wasadmin> <password>
Note: For startup errors, you can check the following log files:
v /usr/ibm/tivoli/common/COP/logs/tio_start.log
v /usr/ibm/tivoli/common/COP/logs/tio_start_service.log
v /opt/IBM/tivoli/tpm/lwi/logs
4. As root user, start the HTTP server:
/opt/IBM/HTTPServer/bin/apachectl start
What to do next
You can check if the configuration is correct and Tivoli Service Automation
Manager, Tivoli Provisioning Manager and all their components are running. To do
so, check the Tivoli Service Automation Manager and Tivoli Provisioning Manager
components with the commands:
su - tioadmin
$TIO_HOME/tools/tioStatus.sh <wasadmin> <wasadmin password>
exit
Stopping the management server
Use a sequence of commands to manually shut down Tivoli Service Automation
Manager, Tivoli Provisioning Manager, and all of their components.
About this task
All paths and profile names in the following procedure are examples only and
must be replaced by the actual values in your management environment.
Remember: Run all these commands as the root user unless otherwise specified.
Procedure
1. As root user, stop the HTTP server:
/opt/IBM/HTTPServer/bin/apachectl stop
354 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
2. Stop Tivoli Provisioning Manager and its WebSphere Application Server. The
procedure differs depending on which situation you are in:
v During installation, before Tivoli Provisioning Manager is installed, as root
user, run the following commands:
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopServer.sh MXServer -username <wasadmin> -password <password>
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/bin/stopNode.sh -username <wasadmin> -password <password>
/opt/IBM/WebSphere/AppServer/profiles/ctgDmgr01/bin/stopManager.sh -username <wasadmin> -password <password>
v During installation, after Tivoli Provisioning Manager is installed, as
tioadmin, run the following command:
$TIO_HOME/tools/tio.sh stop -w <wasadmin> <password>
v After installation is complete, as tioadmin, run the following commands:
$TIO_HOME/tools/tio.sh stop <wasadmin> <password>
3. As root user, stop LDAP:
v
Linux
/opt/IBM/ldap/V6.2/bin/ibmdirctl D cn=root w <password> stop
/opt/IBM/ldap/V6.2/bin/ibmdirctl D cn=root w <password> admstop
v
AIX
/opt/IBM/ldap/V6.2/bin/ibmdirctl D cn=root w <password> stop
/opt/IBM/ldap/V6.2/bin/ibmdirctl D cn=root w <password> admstop
4. As root user, stop DB2 database instances:
su - idsccmdb
db2stop force
db2_kill
exit
su ctginst1
db2stop force
db2_kill
exit
su dasusr1 c db2admin stop
Controlling the middleware with a script
This task describes how to configure and run a script to start, stop, restart, or
determine the status of the middleware.
If the system is restarted, the middleware for the process automation engine must
be started. A sample script is provided to help with automating the starting and
stopping of the middleware.
About this task
A script tsam_middleware.sh can be used to start, stop, restart and obtain the status
of the middleware components:
v DB2
v LDAP
v HTTP server
v WebSphere Application Server (deployment manager and node).
Chapter 4. Administering 355
The script is available in directory install/tools/tsam_middleware.sh on the Tivoli
Service Automation Manager installation source package. In one of the last steps of
the installation, the script is copied to /opt/IBM/tsam/tools on the management
server. The script must be adapted to the actual management server environment
before it can be used. You can then add this script to the runlevel sequence so that
the middleware is automatically started when the operating system is started.
Note: This script can be used only in a single-server management system
configuration. It also assumes that the middleware was installed via the
Middleware Installer (MWI), which is started by the Tivoli Service Automation
Manager Installation Launchpad.
The script writes its output to /var/log/mwi.
Procedure
1. Edit the script install/tools/tsam_middleware.sh as requested. All values can
be specified in a parameter section at the beginning of the script:
v At least three password entries (LDAPROOTPASSWORD, WASADMIN_PW and
TIOADMIN_PW) must be entered.
v The paths and user IDs for the middleware products must be checked and
adapted as necessary.
v Entries in quotation marks can contain embedded spaces. If they do not
contain spaces, the quotation marks are optional.
2. Run the script manually:
a. Log on as user root.
b. Run the following command:
<directory>/tsam_middleware.sh <option>
where <directory> is the location of the modified script and <option> is
one of the following:
status
Reports the status of each middleware component. Returns 0 if all
middleware components have been started and a value other than 0
otherwise.
start
Starts the middleware. Returns 0 if everything was started correctly.
Returns a value other than 0 otherwise.
stop
Stops the middleware. Returns 0 if everything was stopped correctly.
Returns a value other than 0 otherwise.
restart
Restarts the middleware. Returns 0 if everything was restarted correctly.
Returns a value other than 0 otherwise.
3. Optional: Add the script to the runlevel sequence:
v
Linux
:
a. Copy the script to /etc/init.d.
b. Link tsam_middleware.sh to rc.d, runlevel 2 (network without X
Window System) and runlevel 3 (network with X Window System), and
a single link into runlevel 6 (restart):
356 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
ln -s /etc/init.d/tsam_middleware.sh /etc/rc.d/rc2.d/S99tsam_middleware
ln -s /etc/init.d/tsam_middleware.sh /etc/rc.d/rc2.d/K01tsam_middleware
ln -s /etc/init.d/tsam_middleware.sh /etc/rc.d/rc3.d/S99tsam_middleware
ln -s /etc/init.d/tsam_middleware.sh /etc/rc.d/rc3.d/K01tsam_middleware
ln -s /etc/init.d/tsam_middleware.sh /etc/rc.d/rc6.d/K01tsam_middleware
v
AIX
:
a. Copy the script to /etc/rc.d/init.d.
b. Link tsam_middleware.sh to rc.d, AIX default runlevel:
ln -s /etc/rc.d/init.d/tsam_middleware.sh /etc/rc.d/rc2.d/Stsam_middleware
ln -s /etc/rc.d/init.d/tsam_middleware.sh /etc/rc.d/rc2.d/Ktsam_middleware
Backing up the database
You can back up the Maximo database in the offline mode.
For additional information regarding backing up a DB2 database or performing an
online backup, refer to DB2 documentation on the IBM DB2 support site.
Procedure
1. Log on to the Tivoli Service Automation Manager management server as user
ctginst1.
2. Run the following command:
db2 get db cfg
3. Check the following parameters to ensure that the database is configured for an
offline backup:
Log retain for recovery status = NO
User exit for logging status = NO
4. Stop Tivoli Service Automation Manager as described in Stopping the
management server on page 354.
5. Run the following command to ensure that no additional application is
accessing the database:
db2 force application all
6. Run the following command to back up the database:
db2 backup database maxdb71 to <backup_dir>
where <backup_dir> is a path to the backup directory.
7. Start Tivoli Service Automation Manager as described in Starting the
management server on page 353.
Chapter 4. Administering 357
Changing default passwords for Tivoli Service Automation Manager
Follow the steps described in this section to change the default passwords for
Tivoli Service Automation Manager.
Before you begin
Before you change any password, back up the Tivoli Service Automation Manager
image.
If exploiting high availability (single or dual node), before following this
procedure, type: samctrl M t. After changing passwords for Tivoli Service
Automation Manager, type: samctrl M f.
Change the passwords for IBM Tivoli Directory Server
Change the idsccmdb user password
About this task
Log on as root. In order to change the password for idsccmdb:
Procedure
1. Stop the Tivoli Provisioning Manager processes:
a. Type su tioadmin
b. Type cd $TIO_HOME/tools
c. Type ./tio.sh stop wasadmin <wasadmin password>
d. Type exit
2. To change the password for idsccmdb in the OS, type: echo "idsccmdb:<new
password>" | chpasswd
Note: The operating system is configured in such a way that, the first time a
user logs on after having changed the password, the system requests the user
to change the password again. This means that you must first assign the user a
temporary password, then log on with the user name and assign a permanent
password.
3. Restart DB2 as idsccmdb:
a. Type su idsccmdb
b. Type db2stop force
c. Type db2start
Change idsccmdb password in Tivoli Directory Server
Procedure
1. As the idsccmdb user, stop all Tivoli Directory Server processes:
a. Type cd /opt/IBM/ldap/V6.2/sbin
b. Type ./ibmslapd I idsccmdb k
2. To change the password for idsccmdb, in the /opt/IBM/ldap/V6.2/sbin directory
perform the following steps:
a. Type ./idscfgdb I idsccmdb w <new password>
b. When prompted, type 1 to continue.
3. Once the password has been successfully changed, log in as rooton and start
the Tivoli Directory Server processes:
358 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
a. Type cd /opt/IBM/ldap/V6.2/sbin
b. Type ./ibmslapd I idsccmdb
4. Verify that the Tivoli Directory Server is running:
a. Type su - idsccmdb
b. Type cd /opt/IBM/ldap/V6.2/bin
c. Type ./ibmdirctl D cn=root w password status
5. As idsccmdb, verify database connection using the new password:
a. Type db2 list db directory
b. Type db2 connect to security user idsccmdb using <new password>
c. Type db2 connect to ldapdb2b user idsccmdb using <new password>
6. Log in as root, and start Tivoli Provisioning Manager:
a. Type su - tioadmin
b. Type $TIO_HOME/tools/tio.sh start wasadmin <wasadmin_password>
c. Type exit.
Changing the passwords for Tivoli Provisioning Manager user
IDs
The following list presents the user IDs and where the passwords must be
changed.
OS user ID Changed in OS
Change in Tivoli
Provisioning
Manager
Change in
Tivoli Directory
Server
Change in
WebSphere
Application
Server
maximo Yes Yes No Yes
tioadmin Yes Yes No No
ctginst1 Yes No No No
dasusr1 Yes No No No
db2fenc1 Yes No No No
virtuser Yes No No No
root Yes No No No
idsldap (not
used)
Yes No No No
The following is the list of LDAP user IDs and where the passwords must be
changed.
LDAP user ID Changed in OS
Change in Tivoli
Provisioning
Manager
Change in
Tivoli Directory
Server
Change in
WebSphere
Application
Server
wasadmin No No Yes Yes
maxadmin No No Yes No
PMSCADMUSR No No No No
Chapter 4. Administering 359
Change password for wasadmin
Procedure
1. Log on as root and stop all Tivoli Provisioning Manager processes:
a. Type su tioadmin
b. Type cd $TIO_HOME/tools
c. Type ./tio.sh stop wasadmin <wasadmin password> The default wasadmin
password is password.
2. As tioadmin, change the casprofile password:
a. Type :
cd /opt/IBM/WebSphere/AppServer/profiles/casprofile/logs/server1
cd /usr/IBM/WebSphere/AppServer/profiles/casprofile/logs/server1
b. Type rm SystemOut.log (if the file exists)
c. Type:
cd /opt/IBM/WebSphere/AppServer/profiles/casprofile/bin
cd /usr/IBM/WebSphere/AppServer/profiles/casprofile/bin
d. Type ./startServer.sh server1
3. Create a new file /tmp/test.py and enter the following information in the file:
AdminTask.changeFileRegistryAccountPassword([-userId, wasadmin, -password,
<new wasadmin password>, -uniqueName, uid=wasadmin,o=defaultWIMFileBasedRealm])
AdminConfig.save()
4. Invoke the WebSphere command line to update the password in WebSphere:
a. Type:
cd /opt/IBM/WebSphere/AppServer/profiles/casprofile/bin
cd /usr/IBM/WebSphere/AppServer/profiles/casprofile/bin
b. Type ./wsadmin.sh -lang jython -user wasadmin -password <old wasadmin
password> -f /tmp/test.py
5. Stop casprofile:
a. Type:
cd /opt/IBM/WebSphere/AppServer/profiles/casprofile/bin
cd /usr/IBM/WebSphere/AppServer/profiles/casprofile/bin
b. Type ./stopServer.sh server1 user wasadmin password <old wasadmin
password>
c. Type exit
Change wasadmin password in Tivoli Directory Server
Procedure
1. Log on as idsccmdb.
2. Create the file /tmp/chgpwd.ldif and enter the following information in the file:
dn: cn=wasadmin,OU=users,OU=SWG,O=IBM,C=US
changetype: modify
replace: userpassword
userpassword: <new password>
where <new password> is the new password for wasadmin
3. Type cd /opt/IBM/ldap/V6.2/bin
4. Type ./ldapmodify D cn=root w password i /tmp/chgpwd.ldif
5. Verify that the password change was successful:
a. Type:
360 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
./idsldapsearch D cn=root w password s base b
"cn=wasadmin,OU=users,OU=SWG,O=IBM,C=US" objectclass=*
An output example:
cn=wasadmin,ou=users,ou=SWG,o=IBM,c=US
sn=wasadmin
objectclass=organizationalPerson
objectclass=inetOrgPerson
objectclass=person
objectclass=top
uid=wasadmin
cn=wasadmin title=VMM Administrator
userpassword=<new password>
b. Type exit
6. Log on as root and start the Tivoli Provisioning Manager processes by doing
the following:
a. Type su - tioadmin
b. Type $TIO_HOME/tools/tio.sh start wasadmin <new password>
c. Type exit
Verify Tivoli Provisioning Manager and WebSphere
Verify that the Tivoli Provisioning Manager user interface can be launched from a
web browser.
Procedure
1. Log in to the Tivoli Provisioning Manager user interface by accessing
https://icb-nfs/tivsam/admin in a web browser.
2. When prompted for "MAXIMO Web Application Realm" authentication, enter:
user ID: maxadmin
password: <maxadmin password>
3. Launch the WebSphere Admin Console and log in as the wasadmin user with
the new password.
Note: Tivoli Provisioning Manager must be running to access this web
interface.
4. Log out and close the web browser.
Change the maxadmin user password
Procedure
1. Log on as root and stop the Tivoli Provisioning Manager processes:
a. Type su tioadmin
b. Type cd $TIO_HOME/tools
c. Type ./tio.sh stop wasadmin <wasadmin password>
d. Type exit
2. Log on as idsccmdb and change maxadmin password in Tivoli Directory Server.
a. Create a file /tmp/chgpwd.ldif, and enter the following information in the
file:
dn: uid=maxadmin,OU=users,OU=SWG,O=IBM,C=US
changetype: modify
replace: userpassword
userpassword: <new password>
where <new password> is the new password for maxadmin.
Chapter 4. Administering 361
b. Type cd /opt/IBM/ldap/V6.2/bin
c. Type ./ldapmodify D cn=root w password i /tmp/chgpwd.ldif
d. Verify that the password change was successful:
1) Type:
./idsldapsearch D cn=root w password s base b
uid=maxadmin,OU=users,OU=SWG,O=IBM,C=US objectclass=*
An output example:
uid=maxadmin,ou=users,ou=SWG,o=IBM,c=US
objectClass=inetorgperson
objectClass=organizationalPerson
objectClass=person
objectClass=top
uid=maxadmin
sn=maxadmin
cn=maxadmin
userpassword=<new password>
2) Type exit
3. Log on as tioadmin , and start Tivoli Provisioning Manager by doing the
following:
a. Type su - tioadmin
b. Type $TIO_HOME/tools/tio.sh start wasadmin <wasadmin password>
c. Type exit
4. Verify that the Tivoli Provisioning Manager user interface can be launched from
a web browser.
a. In a web browser, access the following address: https://
<management_server_hostname>:9443/maximo.
b. When prompted for "MAXIMO Web Application Realm" authentication,
enter the following credentials:
user ID: maxadmin
password: <new password>
5. When logged on to the Tivoli Provisioning Manager user interface as maxadmin,
update the PMRDPRBC end point:
a. Click Go To > Integration > End Points.
b. Search for and expand the PMRDPRBC end point.
c. For the property PASSWORD, enter the new maxadmin password.
d. Save your changes.
Change the Maximo user password
To change the Maximo user password, run the changePassword command as
tioadmin, then update the password at operating system level.
Procedure
1. Stop the provisioning server:
a. Type: su - tioadmin
b. Type: /opt/IBM/tivoli/tpm/tools/tio.sh stop wasadmin <wasadmin
password>
2. Start WebSphere Application Server by typing $TIO_HOME/tools/tio.sh start
-w.
3. Change the owner of the following directory and file by running:
362 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
chown -R tioadmin:tioadmin
/opt/IBM/WebSphere/AppServer/logs
chown tioadmin:tioadmin
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/wsadmin.traceout
chown -R tioadmin:tioadmin
/usr/IBM/WebSphere/AppServer/logs
chown tioadmin:tioadmin
/usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/logs/wsadmin.traceout
4. Run the changePassword command by typing $TIO_HOME/tools/
changePassword.sh -c database -n <new maximo password> -u wasadmin -p
<wasadmin_password>.
Note: For more information, see Tivoli Provisioning Manager 7.2.1 > Reference >
Command line tools > Tivoli Provisioning Manager command line tools>
changePassword command in the Tivoli Provisioning Manager Knowledge Center.
5. Stop WebSphere Application Server by typing $TIO_HOME/tools/tio.sh stop
-w.
6. Change the maximo password at the operating system level:
a. Type: echo "maximo:<new password>" | chpasswd
Note: On System p, the first time a user logs on after having changed the
password, the system requests the user to change the password again. You
must first assign a temporary password to the user, then log on with the user
name and assign a permanent password.
Change maximo.properties
About this task
There are three instances of the maximo.properties file in the Tivoli Service
Automation Manager environment. Two of them are on the management server
under the following locations:
v /opt/IBM/tivoli/tpm/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/properties/
maximo.properties
v /opt/IBM/tivoli/tpm/eclipse/plugins/tpm_pmp/properties/maximo.properties
The third one can be found on the administrative server under the following
location: /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties.
You must edit all three instances of the file when you change the database
password. You must encrypt them afterward. Additionally, when the
maximo.properties on the administrative server is changed, you must redeploy
and rebuild the maximo.ear file.
Procedure
1. Log on as root and change the maximo.properties file:
a. Type su - tioadmin
b. Type cd /opt/IBM/tivoli/tpm/lwi/runtime/tpm/eclipse/plugins/tpm_pmp/
properties
c. Type cp p maximo.properties maximo.properties.orig
2. Edit the maximo.properties file:
a. Delete the following line: mxe.encrypted=true
b. Delete the last line in the file, which is the encrypted password.
c. Add the following line: mxe.db.password=<new maximo password>.
Chapter 4. Administering 363
d. Set mxe.db.user=maximo.
3. Save the file.
4. To encrypt maximo.properties again, perform the following steps:
a. Log on as root.
b. Type cd /opt/IBM/SMP/maximo/applications/maximo/properties
c. Type cp -p maximo.properties maximo.properties.orig to save the
original maximo.properties file.
d. Type cp -p /opt/IBM/tivoli/tpm/lwi/runtime/tpm/eclipse/plugins/
tpm_pmp/properties/maximo.properties .
e. Type cd /opt/IBM/SMP/maximo/tools/maximo
f. Type ./encryptproperties.sh to encrypt the maximo.properties file.
g. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties /opt/IBM/tivoli/tpm/lwi/runtime/tpm/eclipse/
plugins/tpm_pmp/properties/maximo.properties to copy the encrypted
file.
h. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties.orig /opt/IBM/SMP/maximo/applications/maximo/
properties/maximo.properties to restore the original file.
5. Back up the maximo.properties file in the directory:
a. Type su - tioadmin
b. Type cd /opt/IBM/tivoli/tpm/eclipse/plugins/tpm_pmp/properties
c. Type cp p maximo.properties maximo.properties.orig
6. Edit the maximo.properties file:
a. Delete the following line: mxe.encrypted=true
b. Delete the last line in the file, which is the encrypted password.
c. Add the following line: mxe.db.password=<new maximo password>.
d. Set mxe.db.user=maximo.
7. To encrypt the maximo.properties file again, perform the following steps:
a. Log on as root.
b. Type cd /opt/IBM/SMP/maximo/applications/maximo/properties
c. Type cp -p maximo.properties maximo.properties.orig to save the
original maximo.properties file.
d. Type cp -p /opt/IBM/tivoli/tpm/eclipse/plugins/tpm_pmp/properties/
maximo.properties
e. Type cd /opt/IBM/SMP/maximo/tools/maximo
f. Type ./encryptproperties.sh to encrypt the maximo.properties file.
g. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties /opt/IBM/tivoli/tpm/eclipse/plugins/tpm_pmp/
properties/maximo.properties to copy the encrypted file.
h. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties.orig /opt/IBM/SMP/maximo/applications/maximo/
properties/maximo.properties to restore the original file.
8. Log on to the administrative server and back up the maximo.properties file
that is located there:
a. Type su - tioadmin
b. Type cd /opt/IBM/SMP/maximo/applications/maximo/properties/
c. Type cp p maximo.properties maximo.properties.orig
9. Edit the maximo.properties file:
364 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
a. Delete the following line: mxe.encrypted=true
b. Delete the last line in the file, which is the encrypted password.
c. Add the following line: mxe.db.password=<new maximo password>.
d. Set mxe.db.user=maximo.
10. To encrypt the maximo.properties file again, perform the following steps:
a. Log on as root.
b. Type cd /opt/IBM/SMP/maximo/applications/maximo/properties
c. Type cp -p maximo.properties maximo.properties.orig to save the
original maximo.properties file
d. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties
e. Type cd /opt/IBM/SMP/maximo/tools/maximo
f. Type ./encryptproperties.sh to encrypt the maximo.properties file.
g. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties /opt/IBM/tivoli/tpm/eclipse/plugins/tpm_pmp/
properties/maximo.properties to copy the encrypted file.
h. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties.orig /opt/IBM/SMP/maximo/applications/maximo/
properties/maximo.properties to restore the original file.
11. Run the following set of commands to rebuild and redeploy the maximo.ear
file:
cd /opt/IBM/SMP/maximo/deployment
./buildmaximoear.sh
cd /opt/IBM/SMP/jacl/solutions
./DeployApplication.sh wasadmin <wasadmin-password> MAXIMO
ctgNode01 MXServer
/opt/IBM/SMP/maximo/deployment/default/maximo.ear maximo_host
webserver1
Update properties.jar
About this task
Update the properties.jar file:
Procedure
1. Log on as root.
2. Update maximo.properties inside /opt/IBM/WebSphere/AppServer/profiles/
ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/properties.jar
a. Type: cd /tmp
b. Type:
v System x: /opt/IBM/WebSphere/AppServer/java/bin/jar -xf
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/
ctgCell01/MAXIMO.ear/properties.jar maximo.properties
v System p: /usr/IBM/WebSphere/AppServer/java/bin/jar -xf
/usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/
ctgCell01/MAXIMO.ear/properties.jar maximo.properties
c. Edit the maximo.properties file:
1) Delete the following line: mxe.encrypted=true
2) Delete the last line in the file, which is the encrypted password.
3) Add the following line: mxe.db.password=<new maximo password>.
Chapter 4. Administering 365
3. To encrypt the maximo.properties file again, perform the following steps:
a. Log on as root.
b. Type cd /opt/IBM/SMP/maximo/applications/maximo/properties
c. Type cp -p maximo.properties maximo.properties.orig to save the original
maximo.properties file.
d. Type cp -p /tmp/maximo.properties .
e. Type cd /opt/IBM/SMP/maximo/tools/maximo
f. Type ./encryptproperties.sh to encrypt the maximo.properties file.
g. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties /tmp/maximo.properties to copy the encrypted file.
h. Type cp -p /opt/IBM/SMP/maximo/applications/maximo/properties/
maximo.properties.orig /opt/IBM/SMP/maximo/applications/maximo/
properties/maximo.properties to restore the original file.
i. Type: cd /tmp
j. Type:
v System x: /opt/IBM/WebSphere/AppServer/java/bin/jar -uf
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/
ctgCell01/MAXIMO.ear/properties.jar maximo.properties
v System p: /usr/IBM/WebSphere/AppServer/java/bin/jar -uf
/usr/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/
ctgCell01/MAXIMO.ear/properties.jar maximo.properties
4. Start Tivoli Provisioning Manager:
a. Type: su - tioadmin
b. Type: /opt/IBM/tivoli/tpm/tools/tio.sh start wasadmin <wasadmin
password>
c. Type: exit
5. Verify that the maximo password is changed by checking the
<WAS_INSTALL>\profiles\ctgAppSrv01\logs\MXServer\SystemOut.log file. To
perform this step, see an example of the message that is present in the file if
the database connection is verified.
BMXAA6451I - The database manager is psdi.server.DBManager@43164316
BMXAA6385I - Connecting to the database at: jdbc:db2://vm-tpm-s122.torolab.ibm.com:50005/maxdb71
BMXAA6388I - Database product: DB2/NT BMXAA6389I - Database product version: SQL09053 -- 9.5
BMXAA6390I - Database driver: IBM DB2 JDBC Universal Driver Architecture
BMXAA6391I - Database driver version: 3.53.70 Connection pool initialized with 8 free connections.
BMXAA6453I - The server is connecting to database version: V7115-149
If a similar message is present in your file, the database connection is verified.
Verify password change
About this task
To verify the password change, launch the Tivoli Provisioning Manager user
interface.
Note: Open a new browser to ensure that you will be prompted to enter a userid
and password.
Procedure
Log on to the Tivoli Provisioning Manager user interface (https://
<management_server_hostname>:9443/maximo) with the following credentials:
366 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
user ID: maxadmin
password: <new password>.
Change OS user ID passwords
After you change the passwords in Tivoli Provisioning Manager, Tivoli Directory
Server, and WebSphere Application Server, you must update them within the
operating system.
About this task
The passwords for the following user IDs must be changed in the operating system
:
v tioadmin
v ctginst1
v dasusr1
v db2fenc1
v virtuser
v root
Procedure
1. As the root user, enter the following command:
echo "userid:<new password>" | chpasswd
where:
userid is one of the user IDs listed above,
<new password> is the new password for this user ID.
Note: The operating system is configured in such a way that, the first time a
user logs on after having changed the password, the system requests the user
to change the password again. This means that you must first assign the user a
temporary password, then log on with the user name and assign a permanent
password.
2. Repeat the step for all user IDs for which the passwords must be changed.
Change the cloud administrator (PMRDPCAUSR) password
About this task
All users of the cloud computing center can access the self-service user interface at
https://<hostname>:9443/SimpleSRM.
Procedure
1. Log on with the following credentials:
user ID: PMRDPCAUSR
password: maxadmin
The home page for the cloud administrator is displayed.
2. Click Request a New Service > Virtual Server Management > Manage Users
and Teams > Modify User.
3. From the drop down list, select the PMRDPCAUSR user and click OK.
4. Specify the new password in the Password and Confirm Password fields and
click OK
Chapter 4. Administering 367
5. Log out of the Tivoli Service Automation Manager user interface, then log on
again as PMRDPCAUSR and enter the new password.
What to do next
When all passwords for Tivoli Service Automation Manager are changed, type the
following command:
samctrl M f
Updating Tivoli Provisioning Manager certificate in the Java truststore
You can update the Java truststore when a new certificate is generated by the
WebSphere
Application Server.
About this task
Tivoli
or
), these symbols
indicate U.S. registered or common law trademarks owned by IBM at the time this
information was published. Such trademarks may also be registered or common
law trademarks in other countries. A current list of IBM trademarks is available on
the Web at http://www.ibm.com/legal/copytrade.shtml.
Adobe, the Adobe logo, PostScript, and the PostScript logo are trademarks or
registered trademarks of Adobe Systems, Incorporated, in the United States and/or
other countries.
Intel, the Intel logo, Intel Inside, the Intel Inside logo, Intel Centrino, the Intel
Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are
trademarks or registered trademarks of Intel Corporation or its subsidiaries in the
United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.
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.
Copyright IBM Corp. 2008, 2012 533
534 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Index
A
accessibility features 523
account code 291
Admin Mode
managing 372
administering
Tivoli Service Automation
Manager 287
administrative server
AIX 67
Linux on System x 66
preparation for Tivoli Service
Automation Manager
installation 66
Windows 66
administrative user interface
applications 3
applications
Co-Location Editor 8
IT Topology Work Orders 8
Management Plan Input
Parameters 9
Management Plan Target Selection 9
Monitoring Definition 4
Monitoring Definition Instances 4
Monitoring Definition Instantiation 4
Node Attribute Uniqueness
Violations 8
overview 3
Resource Allocation for Service
Deployment Instance 4
Resource Allocation Record 4
Service Automation Manager 9
Service Definitions 4
Service Deployment Instances 4
Service Topology 7
Service Topology Customization
Editor 9
Service Topology Node 8
Service Topology Node Operation 8
Situation Analysis 5
Topology Customization 8
approval
delegation
disabling 351
enabling 351
disabling 350
enabling 350
C
cloud 238
cloud server pool 174
Cloud storage pools 238
communication templates 348
managing 350
components
overview 2
configuration 174
cloud server pool 173
configuration (continued)
DCM objects 218
network 217
network artifacts 293
network segment usage values 219,
220
network template 221, 223
overview 111
provisioning 251
purging 235, 236, 237
restore 329
SAN storage 216, 217
storage pool 232
storage resources 234, 238
configuring
Tivoli Provisioning Manager DCM for
WebSphere Cluster Service 245
CSR
enabling generation 269
CSR files
defining directory location 269
customer
activating 242
administering 338
assigning resources 338
creating template 341
defining limits 342
defining quotas 342
initial setup 241
returning resources 340
customer support
contact xvi
customer template
creating 341
D
DCM for Tivoli Provisioning Manager,
configure to enable WebSphere Cluster
service 245
delegation of approval
disabling 351
enabling 351
Discovery, configuring 247
E
education
see Tivoli technical training xiv
F
fixes, obtaining xv
G
glossary 527
H
hardware requirements 28
administrative system 31
management system 29
System z environment 40
I
IBM Software Support
submitting a problem xvii
IBM Support Assistant xv
image
removing 327
installation 84
additional configuration files 80
automation packages 81
Base Services 72
default values and settings 69
middleware 71
overview 27
preparing for 42
SRM 75
Tivoli Provisioning Manager core 73
Tivoli Service Automation
Manager 27, 67, 68
Tivoli Service Automation Manager
Base component 79
Tivoli Service Automation Manager
license 70
Tivoli Service Automation Manager
WAS 83
web components 74
Installation Launchpad
overview 2
integrating
Tivoli Service Automation Manager
with other Tivoli products 255
integration
CCMDB 277, 278, 279, 280, 281, 283,
284
Tivoli Monitoring 255, 256, 257, 263,
264, 265
Tivoli Usage and Accounting
Manager 266, 267, 268, 269, 270,
271, 272
Internet, search for problem
resolution xiv
Internet, searching for problem
resolution xv
invalid binding 514
K
knowledge bases, searching xiv
KVM image server setup 166
KVM setup
KVM server setup 166
Copyright IBM Corp. 2008, 2012 535
L
limit
activating 343
deactivating 343
defining 342
M
maintenance mode
activating 346
deactivating 346
forcing 347
log 344
overview 25
statuses 345
managed environment
WebSphere Cluster service 244
management plans 12
management server
AIX 48, 49, 50, 55
Linux 58, 59, 60, 64
starting 353
stopping 354
middleware
controlling with a script 355
starting 353
stopping 353, 354
middleware requirements
base services requirements 38
components 38
Tivoli Monitoring 39
Tivoli Provisioning Manager 38
Tivoli Remote Execution and
Access 39
Monitoring function
configuring 263
N
notifications
managing 350
O
operating system requirements 28
administrative system 31
management system 29
System z environment 40
P
performance monitoring 16, 263
Performance Monitoring function
configuring 263
PMRDPCUST
activating 242
post-installation steps 82
problem determination
describing problem for IBM Software
Support xvii
determining business impact for IBM
Software Support xvii
submitting a problem to IBM
Software xvii
project account 291
Q
quota
activating 343
deactivating 343
defining 342
R
ras 390
reporting
overview 20
Reporting function
configuring 248
reports 307, 330, 369
Tivoli Service Automation
Manager 287
authorizing users 289
configuring 288
generating 290
generating request pages 288
scheduling 290
table auditing 288
viewing 290
types 20
usage and accounting 291
generating 292
resources
assigning to all customers 340
assigning to customer 338
defining limits 342
defining quotas 342
returning 340
restrictions 44
S
security 330
CCMDB 330
person groups 330
roles 330
security groups 330
self-service user interface 333
Self-Service Virtual Server
Management 330
security groups 334
self-service user interface
communication templates 348
security 333
settings 348
Self-Service Virtual Server Management
overview 2
requirements 40
Tivoli Provisioning Manager
integration 3
server image management
overview 23
service provider
configuring 241
service structure 17
services
Self-Service Virtual Server
Management 2
WebSphere Cluster Service 9
software modules
adding 352
configuring 352
software products
adding 352
configuring 352
software requirements
Service Request Manager 38
Software Support
contact xvi
describing problem for IBM Software
Support xvii
determining business impact for IBM
Software Support xvii
SSH command end point for Tivoli
Monitoring information 264
storage 238
support information xiv
System z
requirements 40
T
Tivoli Provisioning Manager
running Discovery 247
Tivoli Provisioning Manager
Discovery 247
Tivoli Service Automation Manager
components 2
installing 27
RXA setup for Tivoli Usage and
Accounting Manager interface 268
Tivoli Service Automation Manager
events for monitoring, setting up 263
Tivoli Service Automation Manager
security, setting up 330
Tivoli technical training xiv
Tivoli Usage and Accounting Manager
enabling table auditing 268
RXA setup for Tivoli Service
Automation Manager interface 268
topology
WebSphere 10
topology node attributes 13
training, Tivoli technical xiv
troubleshooting 390, 485
U
usage and accounting function
configuring 266
configuring server to process
CSR 270
configuring Tivoli Service Automation
Manager 267
generating reports 292
overview 21
user interface 3
user roles
See security groups
V
verify the installation 84
verifying 84
VMControl
error recovery 507
hardware failure 509
536 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
VMControl (continued)
orphan servers
removing 509
removing hardware 508
VMware Additional Disk
overview 22
W
WebSphere 10
WebSphere Cluster service
configuring managed
environment 244
Workload Deployer
configuring 243
overview 24
Index 537
538 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide
Privacy policy considerations
IBM Software products, including software as a service solutions, (Software
Offerings) may use cookies or other technologies to collect product usage
information, to help improve the end user experience, to tailor interactions with
the end user or for other purposes. In many cases no personally identifiable
information is collected by the Software Offerings. Some of our Software Offerings
can help enable you to collect personally identifiable information. If this Software
Offering uses cookies to collect personally identifiable information, specific
information about this offerings use of cookies is set forth below.
This Software Offering does not use cookies or other technologies to collect
personally identifiable information.
If the configurations deployed for this Software Offering provide you as customer
the ability to collect personally identifiable information from end users via cookies
and other technologies, you should seek your own legal advice about any laws
applicable to such data collection, including any requirements for notice and
consent.
For more information about the use of various technologies, including cookies, for
these purposes, See IBMs Privacy Policy at http://www.ibm.com/privacy and
IBMs Online Privacy Statement at http://www.ibm.com/privacy/details the
section entitled Cookies, Web Beacons and Other Technologies and the IBM
Software Products and Software-as-a-Service Privacy Statement at
http://www.ibm.com/software/info/product-privacy.
Copyright IBM Corp. 2008, 2012 539
540 Tivoli Service Automation Manager V7.2.4.4 Installation and Administration Guide