Tsam Admin Book

Tivoli Service Automation Manager
Version 7.2.2
Installation and Administration Guide
SC34-2657-00
Tivoli Service Automation Manager

Version 7.2.2
Installation and Administration Guide
SC34-2657-00
Note Before using this information and the product it supports, read the information in Notices on page 439.
Edition notice This edition applies to IBM Tivoli Service Automation Manager Version 7 Release 2 Modification Level 2 (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-2611-04 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 Deutschland Research and Development GmbH IBM Systems and Technology Group Systems Software Development Dept. 2705, Bldg. 71032-16 Schoenaicher Str. 220 71032 Boeblingen Germany FAX (Germany): 07031 16 4240 FAX (other countries): (+49) 7031 16 4240 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, 2011. 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 What's new in this release . . . . . . . . . xiii Useful links . . . . . . . . . . . . . . xiv Support information . . . . . . . . . . . xv Getting technical training. . . . . . . . . xv Searching knowledge bases . . . . . . . . xv Searching the Internet . . . . . . . . . xv Using IBM Support Assistant . . . . . . xvi Finding product fixes . . . . . . . . . xvi Getting email notification of product fixes . . xvi Contacting IBM Software Support . . . . . xvii Setting up a software maintenance contract xvii Determine the business impact . . . . . xviii Describe the problem and gather background information . . . . . . . xviii Submit the problem to IBM Software Support . . . . . . . . . . . . . xviii Additional software installation on the provisioned servers . . . . . . . . . . . . . . . Managing POWER LPAR provisioning with VMControl . . . . . . . . . . . . . Image management. . . . . . . . . . . Workload Deployer overview . . . . . . . . 21 . 22 . 22 . 23
Chapter 2. Installing Tivoli Service Automation Manager. . . . . . . . . 25

Starting the Tivoli Service Automation Manager Installation Launchpad . . . . . . . . . . Overview of the Tivoli Service Automation Manager installation process . . . . . . . . . . . . Planning for Tivoli Service Automation Manager . . Hardware and operating system requirements for Tivoli Service Automation Manager . . . . . Software requirements for Tivoli Service Automation Manager . . . . . . . . . . Web browser settings . . . . . . . . . Requirements for Self-Service Virtual Server Management . . . . . . . . . . . . . Requirements for the System z environment . . Providing the installation source files . . . . . Restrictions and limitations . . . . . . . . Preparing the environment for installation . . . . Preparing an AIX management server . . . . Verifying settings required for installing the middleware on an AIX management server . . Verifying the settings required to install Tivoli Provisioning Manager on an AIX management server . . . . . . . . . . . . . . Packages required on an AIX management server . . . . . . . . . . . . . . Preparing a Linux management server . . . . Verifying the settings required to install the middleware on a Linux management server . Set LD_LIBRARY_PATH for zLinux. . . . . Modify kernel parameters for DB2. . . . Set user limits . . . . . . . . . . Verify the settings . . . . . . . . . Verifying the settings required to install Tivoli Provisioning Manager on a Linux management server. . . . . . . . . . Packages required on a Linux management server . . . . . . . . . . . . . . Preparing a Windows administrative server . . Preparing a Linux administrative server . . . . Preparing an AIX administrative server . . . . Installing Tivoli Service Automation Manager and its prerequisite software . . . . . . . . . . Installation defaults for Tivoli Service Automation Manager . . . . . . . . . . Installing the Tivoli Service Automation Manager license . . . . . . . . . . . . . . . Installing the middleware . . . . . . . . 25 25 29 29 34 37 37 38 39 43 43 44 44
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 Service Topology application . . . . . . . 7 Service Update Package application. . . . . 7 Service Topology Node applications . . . . 7 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 . . . . . . . 15 Service structure . . . . . . . . . . . . . 17 Service provider support . . . . . . . . . . 18 Reporting function . . . . . . . . . . . . 19 Tivoli Service Automation Manager report types and content . . . . . . . . . . . . . 19 Tivoli Usage and Accounting Manager reporting function . . . . . . . . . . . . . . 20
Copyright IBM Corp. 2008, 2011
46 51 54 54 55 55 55 56
56 60 61 62 62 63 65 67 67
iii
Installing base services . . . . . . . . . Installing the Tivoli Provisioning Manager core components . . . . . . . . . . . . . Installing the Tivoli Provisioning Manager web components . . . . . . . . . . . . . Installing Tivoli Service Request Manager (step 1 of 2) . . . . . . . . . . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 1 core components . . . . . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 1 Web components . . . . . . . . . . . Installing Base Services Fix Pack . . . . . . Installing Tivoli Service Request Manager (step 2 of 2) . . . . . . . . . . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 2 core components . . . . . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 2 Web components . . . . . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components . . . . . . . Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 Web components . . . . . . . Installing the Tivoli Service Automation Manager applications . . . . . . . . . . . . . Installing additional configuration files . . . . Installing the automation packages for Tivoli Service Automation Manager . . . . . . . Installing optional software . . . . . . . . . Post-installation steps . . . . . . . . . . . Verifying the integrated installation . . . . . . Configuring IBM HTTP Server . . . . . . . . Configure the web server to handle HTTP requests . . . . . . . . . . . . . . Configure the web server to handle HTTPS requests . . . . . . . . . . . . . . Optional system settings after installation . . . . Disabling Tivoli Provisioning Manager Software Distribution Infrastructure . . . . . . . . Uninstalling . . . . . . . . . . . . . . Uninstalling Tivoli Service Automation Manager components . . . . . . . . . . . . . Uninstalling Tivoli Provisioning Manager core components . . . . . . . . . . . . . Uninstalling base services other runtime services. Uninstalling middleware . . . . . . . . .
69 70 71 72 74 74 75 76 77 77 78 79 79 80 81 82 83 84 85 85 86 88 88 88 88 89 89 90
Upgrading the network model . . . . . . Activating the default customer after network upgrade . . . . . . . . . . . . . Upgrading storage . . . . . . . . . . Upgrade scenarios for multi-disk support on Power systems . . . . . . . . . . . Multi-disk storage discovery for POWER systems . . . . . . . . . . . . . Upgrading future projects . . . . . . . . Completing the upgrade. . . . . . . . . Updating the CSR records . . . . . . . Activating CSR file generation. . . . . . Reactivating the view to show projects and provisioned servers . . . . . . . . . Reactivating the monitoring agent installation
. 99 . 100 . 100 . 101 . . . . . 102 102 103 103 104
. 104 105
Chapter 4. Configuring Tivoli Service Automation Manager . . . . . . . . 107

Overview of the configuration process . . . . . Planning your configuration . . . . . . . . Planning the hypervisor configuration . . . . Planning the network configuration . . . . . Network templates . . . . . . . . . Customer-specific network configuration . . Network annotation of deployable images Network configuration . . . . . . . . Network configuration strategies . . . . Management network structure overview The multi-NIC networking model on System p . . . . . . . . . . . . . . . VIO support. . . . . . . . . . . Virtual switch template properties for System p . . . . . . . . . . . . Planning for System p configuration. . . Troubleshooting . . . . . . . . . Definitions for DCM objects . . . . . . Preparing the provisioning back ends . . . . . Configuring the z/VM environment for Tivoli Service Automation Manager . . . . . . . Introduction to the z/VM environment . . . Setting up z/VM for Linux provisioning . . Modifying the z/VM System Configuration file . . . . . . . . . System DASD . . . . . . . . . . z/VM network . . . . . . . . . . Modifying system features . . . . . . Updating the z/VM TCP/IP configuration Network devices . . . . . . . . . Home address and gateway . . . . . Autolog statement . . . . . . . . . Port statement . . . . . . . . . . Defining the external IP address to the TCP/IP stack . . . . . . . . . . Setting up 'Directory Maintenance Facility for z/VM (DirMaint) . . . . . . . . . . Configuring the CONFIGxx DATADVH file . . . . . . . . . . . . . . Allocation groups . . . . . . . . . Installing DDRCOPY EXEC on DirMaint Creating the MAPSRV and MAPAUTH IDs Setting up Linux on System z . . . . . . 107 109 109 110 111 112 112 113 113 114 118 120 131 133 133 134 136 136 137 138 138 138 139 139 140 141 141 141 141 142 142 142 143 143 144 145
Chapter 3. Upgrading . . . . . . . . 91
Upgrade scenario . . . . . . . . . . . Upgrade source files . . . . . . . . . . Preparing for upgrade . . . . . . . . . . Preparing instance data for upgrade . . . . Deactivating CSR file generation . . . . . Updating configuration changes in the database Upgrading Tivoli Service Automation Manager components . . . . . . . . . . . . . Upgrading existing service definitions . . . . Upgrading service deployment instances . . . Upgrading to the new user security model . . . Upgrading to the customer model . . . . . Upgrading to the new security groups . . . Upgrading network . . . . . . . . . . . . . . . 91 92 92 92 93 94 95 96 96 97 97 98 99
. . . . . . .
iv
Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide
Defining virtual machines for Linux on System z . . . . . . . . . . . . Setting up a Linux on System z master system . . . . . . . . . . . . Verifying your configuration . . . . . Using RACF with z/VM . . . . . . . Permitting access to system resources . . Configuring z/VM networking . . . . Configuring DIRMAINT/DATAMOVE Configuring VSMSERVE. . . . . . . Configuring the KVM environment for Tivoli Service Automation Manager . . . . . . . Configuring the Xen environment for Tivoli Service Automation Manager . . . . . . . Preparing for an automatic Xen host install Creating the Post Install Script file . . . . Setting up Xen . . . . . . . . . . . Configuring cloud server pools . . . . . . . Configuring cloud server pools manually . . . Manually configuring cloud server pools for VMware . . . . . . . . . . . . . Manually configuring cloud server pools for KVM . . . . . . . . . . . . . . Manually configuring cloud server pools for System p . . . . . . . . . . . . . Manually configuring cloud server pools for System p (POWER7 Blade scenario) . . . . Manually configuring cloud server pools for VMControl . . . . . . . . . . . . Configuring cloud server pools for zVM . . zVM cloud server pool configuration . . Configuring zVM cloud server pools in the Cloud Server Pool Administration application . . . . . . . . . . . Using Data Center Model (DCM) files to configure cloud server pools . . . . . . . Data Center Model (DCM) object templates Customizing Hypervisor Independent Data Center Model (DCM) items . . . . Customizing Hypervisor Dependent Data Center Model (DCM) items. . . . . . Importing Data Center Model (DCM) object templates . . . . . . . . . . . . . Customizing cloud pool objects . . . . . Customizing a Tivoli Service Automation Manager cloud pool for VMware . . . . Customizing a Tivoli Service Automation Manager cloud pool for PowerVM . . . Customizing a Tivoli Service Automation Manager cloud pool for KVM . . . . . Customizing a Tivoli Service Automation Manager cloud pool for IBM Systems Director VMControl . . . . . . . . Configuring PowerVM SAN disks for VIOS support using MPIO . . . . . . . . . . Planning for SAN storage . . . . . . . Enabling VIOS support . . . . . . . . Configuring cloud networks . . . . . . . . Setting up the network related Data Center Model (DCM) objects . . . . . . . . . . Defining network segment usage values . . .
145 147 148 148 149 149 150 150 152 154 154 156 157 158 159 160 161 163 166 168 170 170
171 172 172 174 176 181 181 183 185 191
194 195 195 196 196 197 197
Network segment usage values . . . . . Relating an image to a hypervisor-specific network configuration . . . . . . . . Defining a specific network configuration for a class of images . . . . . . . . . . Distinguishing between network interfaces of the same type . . . . . . . . . . . Creating a network template . . . . . . . Creating a customer and assigning a network template . . . . . . . . . . . . . . Configuring distributed virtual switches . . . Configuring cloud storage pools . . . . . . . Configuring cloud storage resources . . . . . Setting up purging options for storage disks on System p . . . . . . . . . . . . . . Purging LPARs . . . . . . . . . . . . Changing the default purging configuration . . Storage resources . . . . . . . . . . . Configuring the service provider and customer features . . . . . . . . . . . . . . . Assigning resources to the default customer . . Activating the default customer PMRDPCUST Configuring the interface to Workload Deployer Configuring the managed environment to use the WebSphere Cluster Service . . . . . . . . . Configuring the DCM to use the WebSphere Cluster Service . . . . . . . . . . . . Configuring and running discovery on a Tivoli Provisioning Manager server . . . . . . . Defining configuration items for the WebSphere Cluster Service . . . . . . . . . . . . Advanced configuration settings . . . . . . . Reducing the run time of provisioning requests Integrating Tivoli Service Automation Manager with other Tivoli products . . . . . . . . . Integrating Tivoli Monitoring . . . . . . . Configuring the provisioning of the monitoring agent . . . . . . . . . . Preparing the monitoring agent installable Defining the Tivoli Monitoring agent software definition in Tivoli Provisioning Manager . . . . . . . . . . . . Enabling the monitoring agent installation on restored images . . . . . . . . Configuring monitoring for the WebSphere Cluster service . . . . . . . . . . . Setting up predefined Tivoli Service Automation Manager events for monitoring . . . . . . . . . . . Enabling the SSH command end point to retrieve IBM Tivoli Monitoring configuration information . . . . . . Triggering the Tivoli Service Automation Manager event monitoring application . . Integrating Tivoli Usage and Accounting Manager . . . . . . . . . . . . . . CSR files . . . . . . . . . . . . . Configuring Tivoli Service Automation Manager for Tivoli Usage and Accounting Manager . . . . . . . . . . . . .
198 198 199 199 199 201 201 203 203 204 205 206 207 207 207 208 209 211 211 213 214 215 215 216 216 216 217
218 221 222
222
224 224 226 226
227
Contents
Configuring for RXA connections between Tivoli Service Automation Manager and Tivoli Usage and Accounting Manager . . Enabling table auditing for Tivoli Usage and Accounting Manager data collection . Enabling CSR file generation . . . . . Defining the directory for CSR file generation . . . . . . . . . . . Configuring Tivoli Usage and Accounting Manager to process CSR files . . . . . . Configuring the Tivoli Usage and Accounting Manager job file to retrieve CSR files from Tivoli Service Automation Manager . . . . . . . . . . . . Configuring the Tivoli Usage and Accounting Manager job file to process CSR files from Tivoli Service Automation Manager . . . . . . . . . . . . Integrating with Tivoli Change and Configuration Management Database (CCMDB) . Configuration artifacts for integrating with Tivoli Change and Configuration Management Database . . . . . . . . Configuring workflow integration . . . . Configuring a Service Request Manager offering for processing . . . . . . . . Extensions to the Change Management application . . . . . . . . . . . . Tivoli Change and Configuration Management Database Configuration Items . The CreateOrUpdateAuthorizedCI operation . . . . . . . . . . . . The LinkAuthorizedCI operation . . . . The UnlinkAuthorizedCI operation . . . Deriving an operation specific to a configuration item . . . . . . . . . Using the configuration item operations
227 228 228 228 229
230
231 234
234 236 237 238 238 239 240 241 241 242
Chapter 5. Administering Tivoli Service Automation Manager. . . . . 243

Logging on to the Tivoli Service Automation Manager administrative interface . . . . . . Working with the service automation reports . . Configuring the reporting function . . . . Generating request pages . . . . . . Enabling table auditing . . . . . . . Authorizing users to access reports . . . Generating, viewing, and scheduling reports Working with usage and accounting reports . . Project account and the account code structure Generating Tivoli Usage and Accounting Manager reports . . . . . . . . . . Managing cloud networks . . . . . . . . Importing network related artifacts . . . . Changing the status of a network template . Viewing network configuration instances . . Viewing network segments . . . . . . . Adding a network segment. . . . . . . Viewing subnetworks . . . . . . . . Adding a subnetwork . . . . . . . . Viewing virtual switch templates . . . . . . . . . . . 243 243 244 244 244 245 246 . 247 247 248 248 248 249 250 250 251 251 252 252
. . . . . . . . . .
Adding a virtual switch template. . . . . . Deleting a virtual switch template . . . . . Importing a customer network configuration instance . . . . . . . . . . . . . . Exporting a customer network configuration instance . . . . . . . . . . . . . . Viewing project network configuration instances Exporting a project network configuration instance . . . . . . . . . . . . . . Viewing customers . . . . . . . . . . Managing virtual server resources . . . . . . Increasing the maximum memory settings for System p . . . . . . . . . . . . . . Managing server images. . . . . . . . . . Creating operating system image templates . . Creating operating system image templates for VMware . . . . . . . . . . . . Preparing a Windows image . . . . . Preparing a Linux image . . . . . . Creating operating system image templates for PowerVM . . . . . . . . . . . Preparing an AIX image . . . . . . . Creating operating system image templates for KVM . . . . . . . . . . . . . SUSE Linux Enterprise Server 11 image PolicyKit Settings for Authorization free shut down . . . . . . . . . . . Red Hat Enterprise Linux 5.4 image . . . Preparing OS image templates for Tivoli Service Automation Manager. . . . . . . . . . Adding a new image from VMControl . . . . Deleting a server image . . . . . . . . . Enabling the restore across project offerings . . Controlling user access . . . . . . . . . . Security in the administrative user interface . . Security management in the self-service user interface . . . . . . . . . . . . . . Security groups in the self-service user interface . . . . . . . . . . . . . Data segregation for service providers . . . . Administering customers and their resources . . . Assigning resources to a customer . . . . . Assigning resources to all customers . . . Returning customer resources . . . . . . . Creating customer templates . . . . . . . Defining quotas and limits . . . . . . . . Activating and deactivating quotas and limits Managing request approval, delegation, and notification . . . . . . . . . . . . . . Communication templates for email notification Managing communication templates. . . . Enabling or disabling automatic approval of requests . . . . . . . . . . . . . . Enabling or disabling delegation of approval requests . . . . . . . . . . . . . . Adding new software modules . . . . . . . Starting and stopping the middleware . . . . . Starting the management server . . . . . . Stopping the management server . . . . . . Controlling the middleware with a script . . . Backing up the database. . . . . . . . . .
252 253 253 254 254 255 255 255 256 256 257 257 257 261 264 264 265
266 266 267 268 268 269 270 270 273 274 276 277 278 279 280 280 281 283 283 283 285 285 286 287 289 289 290 291 293
vi
Changing default passwords for Tivoli Service Automation Manager. . . . . . . . . . . Defining global password policy . . . . . . Change the passwords for IBM Tivoli Directory Server . . . . . . . . . . . . . . . Change the idsccmdb user password . . . Change idsccmdb password in Tivoli Directory Server . . . . . . . . . . Changing the passwords for Tivoli Provisioning Manager user IDs . . . . . . . . . . . Change password for wasadmin . . . . . Change wasadmin password in Tivoli Directory Server . . . . . . . . . . Verify Tivoli Provisioning Manager and WebSphere . . . . . . . . . . . . Change the maxadmin user password . . . Change the Maximo user password . . . . Change maximo.properties . . . . . . . Update properties.jar . . . . . . . . . Verify password change . . . . . . . . Change OS user ID passwords . . . . . Change OS password for root . . . . . . Change the cloud administrator (PMRDPCAUSR) password. . . . . . . . Using virtual servers for SAP landscapes . . . . Using the Admin Mode . . . . . . . . . .
293 294 295 295 295 296 296 297 298 298 299 300 301 302 302 303 303 304 306
Freeing resources locked to deprecated or inconsistent projects . . . . . . . .
. 325
Chapter 7. REST API reference . . . . 327

Structure of the REST URLs used for the 'query' request . . . . . . . . . . . . . . . Tivoli Process Automation engine base object queries . . . . . . . . . . . . . . . Get domain definitions (MAXDOMAIN) . . . Get list of installed and enabled languages (LANGUAGE) . . . . . . . . . . . . Get list of person groups (PERSONGROUP) . . Get person group details (PERSONGROUPDET) Get list of users (MAXUSER) . . . . . . . Get list of user details (MAXUSERDET) . . . Get list of security groups (MAXGROUP) . . . Get security group users (GROUPUSER) . . . Get Images (IMGLIB). . . . . . . . . . Get system property values (MAXPROPVALUE) Tivoli Service Automation Manager based or modified object queries . . . . . . . . . . (DEPRECATED) Get list of projects and servers (PMRDPSIVIEW) . . . . . . . . . . . Get project-related data (PMZHBR1_PMRDPPRJVIEW) . . . . . . Get server-related data (PMZHBR1_PMRDPSRVVIEW) . . . . . . Get storage-related data (PMZHBR1_PMRDPSTGVIEW) . . . . . . Get the current defined offerings (PMRDPOFFVIEW) . . . . . . . . . . Get person to group mapping (PERSONGROUPTEAM) . . . . . . . . Get person to group mapping details (PERSGRPTMDET) . . . . . . . . . . Get person groups with person not yet in team (PMZHBR1_PERSNTINTEAM) . . . . . . Information to calculate user request frequency (PMZHBR1_FREQUENTREQ) . . . . . . . Network configuration API . . . . . . . . Get network template . . . . . . . . Get matching network segments . . . . . Get network segments matching the customer configuration . . . . . . . Get network segments matching the project configuration . . . . . . . . Constructor for the network API client . . . The Get Network configuration method . . . The Set Network configuration method . . . Network schema . . . . . . . . . . Complex type NetworkConfiguration . . Complex type DNS . . . . . . . . Complex type Gateway . . . . . . . Complex type NetworkSegment . . . . Complex type Reference . . . . . . . Complex type Route . . . . . . . . Complex type Routes. . . . . . . . Complex type Subnet. . . . . . . . Complex type VlanId. . . . . . . . Complex type VrfId . . . . . . . . Simple type Type . . . . . . . . .
Contents
327 329 329 331 332 332 333 334 336 337 337 339 340 340 341 344 346 347 349 349 350 351 352 352 353 353 354 356 356 357 357 358 358 359 360 363 363 364 364 365 366 366
Chapter 6. Reliability, availability, and serviceability functions . . . . . . . 307

REST API reference for RAS . . . . . . . Delete DCM virtual servers on given host platform . . . . . . . . . . . . . List virtual servers on given host platform . List virtual servers on given host platform and in DCM . . . . . . . . . . . . . Force cleanup of service deployment instance List service deployment instance backend resources . . . . . . . . . . . . . List service deployment instance data model inconsistencies . . . . . . . . . . . Validation checks . . . . . . . . . TOPO_VS_DCM validation checks . . . . TOPO_VS_BC validation checks . . . . BC_VS_DCM validation checks . . . . Provide service request current status . . . BIRT reports. . . . . . . . . . . . . Virtual server synchronization report . . . . Service deployment instance inconsistencies report Ticket related objects report . . . . . . . Best practices for using reliability, availability, and serviceability functions . . . . . . . . . Rolling back the resource workflow modification process . . . . . . . . . Removing a host platform . . . . . . . Tracking VM Provisioning request by DCM objects. . . . . . . . . . . . . . Checking the service request status . . . . Unlocking hanging requests . . . . . . Insufficient resources on the Tivoli Service Automation Manager self-service user interface Removing phantom servers. . . . . . . 308 . 308 . 309 . 310 311 . 312 . . . . . . . . 315 316 317 317 318 319 319 320 320 . 321 . 322 . 322 . 323 . 323 . 323 . 324 . 324 . 324
vii
Simple type Version . . . . . . . JAXB access classes . . . . . . . . The ANY attributes available in the schema Tivoli Service Request Manager based object queries . . . . . . . . . . . . . . Get list of service requests (SR) . . . . . Get service request details (SRDET) . . . . Get shopping cart (CART) . . . . . . . Get user details (MAXUSERDET). . . . . Get offering information (OFFERING) . . . Get offering details (OFFERINGDET) . . . Create service request (SRCREATE) . . . . Create a shopping cart (CARDCREATE) . . Create interfaces via REST . . . . . . . . REST POST-style requests - 'create', 'update', and 'delete' . . . . . . . . . . . . Create catalog requests (PMSCCR) . . . . Interfaces via Web services (PMRDPBCAPI) . . pmrdpbcapigetAvailableCapacityData Method pmrdpbcapigetAvailablePoolList Method . . pmrdpbcapigetAvailableCapacityForPools Method . . . . . . . . . . . . . pmrdpbcapigetBCRealSysResMonitoringData Method . . . . . . . . . . . . . pmrdpbcapiReassignWfAssignment Method . pmrdpbcapiChangeWfAssignment Method . Additional relationships . . . . . . . . . GETDOMAIN Relationship. . . . . . . PMZHB_SRSPECCLASS Relationship . . . Additional filter domains . . . . . . . . PMZHBT_CLUSERROLE Filter Domain . . PMZHBT_CLOUDUSER Filter Domain . . . PMZHBT_CLUSERROLE Filter Domain . . PMZHBT_LOGGEDONUSR Filter Domain . PMZHBT_MODCLUSER Filter Domain . . PMZHBT_REASSIGNLST Filter Domain . . PMZHBT_SRAPPRLIST Filter Domain . . . PMZHBT_SRUSRLIST Filter Domain . . . PMZHBT_SRVPRJLUSER Filter Domain . . PMZHBT_USERSTEAM Filter Domain . . . PMZHBT_USERTEAMS Filter Domain . . . PMZHBT_USRROLELIST Filter Domain . . PMZHBT_IMGNOSRV Filter Domain . . . PMZHBT_SWMODULE Filter Domain . . . PMZHBT_ILMSTRIMG Filter Domain . . . REST API troubleshooting . . . . . . . . Common omissions and user errors . . . . Debugging REST requests with loggers . . .
. 367 . 367 368 . . . . . . . . . . 369 369 371 372 373 375 376 377 380 381
. 381 . 382 . 397 398 . 400 . 402 . . . . . . . . . . . . . . . . . . . . . . . . . 403 405 406 406 407 407 407 407 408 408 408 409 410 410 411 412 412 413 413 414 414 415 415 415 416
OutOfMemoryError when installing automation packages . . . . . . . . . . . . . . Troubleshooting upgrade and migration . . . . Creating a project from a saved image fails . . Upgrade fails with VMWare_MigrateDCM_7_3_0_0 workflow errors Provisioning problems . . . . . . . . . . Cleaning up after a provisioning failure . . . Provisioning fails on System p. . . . . . . Virtual server on System p is not created . . . Provisioning fails with HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth0 . . . Provisioning a VMware project with increased memory size fails . . . . . . . . . . . Provisioning VMware fails with timeout error Provisioning fails when using Xen image . . . Provisioning fails because of wrong configuration of default gateways . . . . . Available resources are not listed properly. . . Modifying disk size fails on Red Hat Enterprise Linux server. . . . . . . . . . . . . Resources not updated when creating a project Resource pool is not available . . . . . . . Setting automatic logon for Windows . . . . Setting a specific timezone on a Windows endpoint . . . . . . . . . . . . . . Cleaning up after unexpected stoppage of the Provisioning Manager engines. . . . . . . . Manually changing the status of a service request Troubleshooting when using IBM Systems Director VMControl . . . . . . . . . . . . . . Creating an image template for VMControl fails Deployment of more than 10 servers fails . . . Removing hardware resources via VMControl Recovering after unexpected hardware removal or failure . . . . . . . . . . . . . . Removing an orphan virtual server . . . . . Server cannot be removed in the self-service interface . . . . . . . . . . . . . Troubleshooting when using VMware . . . . . CDSException messages issued for inactive CDS application . . . . . . . . . . . . . . Configuring extensibility for Workload Deployer fails . . . . . . . . . . . . . . . . Passwords expired for administrative users when using global password policy . . . . . . . .
422 422 422 422 423 423 423 424 424 425 425 426 426 427 427 427 428 428 428 430 430 430 430 431 431 432 432 433 433 434 434 435
Appendix. Accessibility features . . . 437 Notices . . . . . . . . . . . . . . 439 Glossary . . . . . . . . . . . . . 441

A C E H J. M P R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441 441 441 441 441 441 442 442
Chapter 8. Troubleshooting and error recovery . . . . . . . . . . . . . 417

Trace logging . . . . . . . . . . . . Common problems and solutions. . . . . . Troubleshooting installation problems . . . . Unable to log on to the administrative user interface after Tivoli Provisioning Manager installation . . . . . . . . . . . . Service Request Manager fix pack installation terminates with error . . . . . . . . . Release Process Manager installation fails . . . 417 . 418 . 420
. 420 . 421 . 422
viii
S T V W X
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
442 442 443 443 443
Trademarks and Service Marks . . . . 445 Index . . . . . . . . . . . . . . . 447
Contents
ix
Tables
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Documentation links for Tivoli Service Automation Manager component products . . xiv Uniqueness scopes for topology node attributes . . . . . . . . . . . . . 14 Uniqueness specifications for attribute names 14 Uniqueness resolution rule . . . . . . . 15 Summary of Tivoli Service Automation Manager Reports and Content . . . . . . 19 Installation scenarios . . . . . . . . . 27 Management server hardware and operating system requirements . . . . . . . . . 30 Minimum free space requirements for the management system (AIX) . . . . . . . 30 Minimum free space requirements for the management system (Linux) . . . . . . . 31 Administrative server requirements . . . . 31 Managed-environment server requirements 33 Summary of software in the Tivoli Service Automation Manager environment . . . . . 34 Installation steps and servers on which the corresponding installation files must be available . . . . . . . . . . . . . 40 Required packages for Linux management servers . . . . . . . . . . . . . . 60 Default and your values for properties . . . 65 Upgrade Source Files . . . . . . . . . 92 The KVM server and KVM image server settings worksheet . . . . . . . . . . 153 The Management Subnetwork customization: 174 The Customer Subnetwork customization: 175 The 11_Cloud_NetworkSettings_VMware.xml file customization . . . . . . . . . . 176 Systemp_SwitchTemplate customization 177 The 13_Cloud_NetworkSettings_zVM.xml file customization . . . . . . . . . . . 178 The 23_1_Cloud_zLinuxImage_SLES10_zVM.xml file customization . . . . . . . . . . 178 The 23_2_Cloud_Vswitches_zVM.xml file customization . . . . . . . . . . . 179 System z Pool customization . . . . . . 179 Customization of the mapserve server section in the System z Pool object . . . . . . . 180 The 14_Cloud_NetworkSettings_KVM.xml file customization: . . . . . . . . . . . 181 Customization of the VIOS settings for the discovered DCM objects and the System p VIOS configuration for the CEC server objects 189 Sample Data Center Model import files. 197 Sample network templates and network template schema. . . . . . . . . . . 200 Classification attributes for configuration items to be used by the WebSphere Cluster Service . . . . . . . . . . . . . . 214 Account code structure . . . . . . . . 231 Account code structure . . . . . . . . 247 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. Roles and groups provided by Tivoli Service Automation Manager . . . . . . . . . Access to requests depending on the security group . . . . . . . . . . . . . . Types of quotas and limits . . . . . . . Tivoli Service Automation Manager communication templates . . . . . . . Roles for email notifications. . . . . . . Management section of the input parameter file . . . . . . . . . . . . . . . Instance profile section of the input parameter file . . . . . . . . . . . ERROR_CODE values . . . . . . . . ERROR_TYPE values . . . . . . . . . Object structure definition for MBS_MAXDOMAIN . . . . . . . . . Object structure definition for MBS_LANGUAGE . . . . . . . . . . Object structure definition for MBS_PERSONGROUP . . . . . . . . Object structure definition for MBS_PERSONGROUPDET . . . . . . . Object structure definition for MBS_MAXUSER . . . . . . . . . . Object structure definition for MBS_MAXUSERDET . . . . . . . . . Object structure definition for MBS_MAXGROUP. . . . . . . . . . Object structure definition for MBS_GROUPUSER . . . . . . . . . Object structure definition for MBS_IMGLIB Object structure definition for MBS_ MAXPROPVALUE . . . . . . . . . . Object structure definition for PMZHBR1_PMRDPSIVIEW . . . . . . . Object structure definition for PMZHBR1_PMRDPPRJVIEW . . . . . . Object structure definition for PMZHBR1_PMRDPSRVVIEW . . . . . . Object structure definition for PMZHBR1_PMRDPSTGVIEW . . . . . . Object structure definition for PMZHBR1_PMRDPOFFVIEW . . . . . . Object structure definition for PMZHBR1_PERSGRPTM . . . . . . . Object structure definition for PMZHBR1_PERSGRPTMDET . . . . . . Object structure definition for PMZHBR1_PERSNTINTEAM . . . . . . Object structure definition for PMZHBR1_PERSNTINTEAM . . . . . . Object structure definition for SRM_SR Object structure definition for SRM_SRDET Object structure definition for SRM_CART Object structure definition for SRM_MAXUSERDET . . . . . . . . . 271 275 282 283 284 305 305 316 316 330 331 332 333 333 334 336 337 338 339 340 342 344 346 348 349 350 350 351 370 371 372 373
14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
29. 30. 31.
32. 33.
xi
66. 67. 68.
Object structure definition SRM_OFFERING . . . Object structure definition SRM_OFFERINGDET . . Object structure definition SRM_SRCREATE . . .
for . . for . . for . .
69. . . . . . . . . . . . . . 375 . 376 . 377 70. 71.
Object structure definition for SRM_CARDCREATE . . . . . . . . . 380 Problems and solutions for common problems 418 Timezones and their numeric values . . . . 428
xii
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 section provides a summary of new product features and enhancements to existing functions. Extensions Guide The new guide available for Tivoli Service Automation Manager version 7.2.2 documents how to build new or extend existing solutions in the areas of cloud computing or IT service management using the product. Service provider support The service provider feature introduced with Tivoli Service Automation Manager 7.2.2 allows for creating clouds that can be used by multiple customers. Resources can be used more efficiently and customers are able to support multiple internal organizations. The Cloud Customer Administration application allows you to configure new customers and manage their resources. For more information see Service provider support on page 18. New security model The service provider feature introduces a customer object, and new security levels. Moreover, instead of user roles, users can be assigned to multiple security groups. For more information, see Security management in the self-service user interface on page 273. Support for additional storage on System p virtual machines Tivoli Service Automation Manager 7.2.2 offers a flexible and extensible way to assign additional storage resources to your System p virtual machines. The new Cloud Storage Pool Administration application enables you to easily manage your cloud storage pools.
xiii
For more information, see Configuring cloud storage pools on page 203. Reliability, availability, and serviceability (RAS) To support troubleshooting when using Tivoli Service Automation Manager, seven RAS functions are introduced in version 7.2.2, including three new types of BIRT reports, and documentation on best practices. For more information see Chapter 6, Reliability, availability, and serviceability functions, on page 307. New application for managing your cloud server pools The Cloud Server Pool Administration application enables you to create cloud server pools in two ways. You can either use the application to import the customized DCM items, or you can create a cloud server pool using the interface of the application. You can also use it to perform a variety of operations on the cloud server pools. For more information, see Configuring cloud server pools on page 158. Network changes You can define the network metadata of an image, for example how many and what kind of network interfaces the image requires. You can also use the extensible network model. The new Cloud Network Administration application enables you to manage network templates, network segments, subnetworks, virtual switch templates, and network configuration instances. For more information, see Managing cloud networks on page 248.
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 IBM Tivoli Provisioning Manager, version 7.2.0.2 Documentation URL http://publib.boulder.ibm.com/infocenter/ tivihelp/v45r1/index.jsp?topic= %2Fcom.ibm.tivoli.tpm.doc%2Fwelcome %2Fic-homepage.html
IBM Tivoli Service Request Manager, version http://publib.boulder.ibm.com/infocenter/ 7.2.0.1 tivihelp/v32r1/index.jsp?topic= %2Fcom.ibm.srm.doc%2Fsrm_welcome.htm Maximo Base Services http://publib.boulder.ibm.com/infocenter/ tivihelp/v3r1/index.jsp?topic= %2Fcom.ibm.mam.doc_7.1 %2Fmam_welcome.htm http://publib.boulder.ibm.com/infocenter/ tivihelp/v2r1/index.jsp?topic= %2Fcom.ibm.IBMDS.doc%2Fwelcome.htm
IBM Tivoli Directory Server, version 6.3
xiv
Table 1. Documentation links for Tivoli Service Automation Manager component products (continued) Product name DB2 , version 9.5
Documentation URL http://publib.boulder.ibm.com/infocenter/ db2luw/v9r5/topic/com.ibm.db2.luw.doc/ welcome.html http://publib.boulder.ibm.com/infocenter/ wasinfo/v6r1/topic/ com.ibm.websphere.base.doc/info/aes/ae/ welcome_base61.html
IBM WebSphere Application Server Network Deployment, version 6.1
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 xvii
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 Information Center at http://publib.boulder.ibm.com/infocenter/tivihelp/v10r1/index.jsp.
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.
Preface
xv
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.
xvi
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 xviii 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 products, as well as IBM DB2 and IBM WebSphere products that run on Microsoft Windows or UNIX operating systems), enroll in IBM Passport Advantage: 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 software products, you can purchase a software maintenance agreement by working directly with an IBM marketing representative or an IBM Business Partner. For more information about support for eServer software products, go to the IBM Technical support advantage webpage at http://www.ibm.com/servers/eserver/techsupport.html.
What to do next
If you are not sure which type of software maintenance contract you need, call 1-800-IBMSERV (1-800-426-7378) in the United States. For a list of support telephone numbers for your location, go to the Software Support Handbook page at http://www14.software.ibm.com/webapp/set2/sas/f/handbook/contacts.html.
Preface
xvii
Determine the business impact

When you report a problem to IBM, you are asked to supply a severity level. In order to provide this information, understand and assess the business impact of the problem you are reporting.
Severity 1 Critical business impact: You are unable to use the program, resulting in a critical impact on operations. This condition requires an immediate solution. Significant business impact: The program is usable but is severely limited. Some business impact: The program is usable with less significant features (not critical to operations) unavailable. Minimal business impact: The problem causes little impact on operations, or a reasonable circumvention to the problem has been implemented.
Severity 2 Severity 3 Severity 4
Describe the problem and gather background information

When explaining a problem to IBM, it is helpful to be as specific as possible. Include all relevant background information so that IBM Software Support specialists can help you solve the problem efficiently. To save time, know the answers to these questions: v What software versions were you running when the problem occurred? v Do you have logs, traces, and messages that are related to the problem symptoms? IBM Software Support is likely to ask for this information. v Can the problem be recreated? If so, what steps led to the failure? v Have any changes been made to the system? For example, hardware, operating system, networking software, and so on. v Are you currently using a workaround for this problem? If so, be prepared to explain it when you report the problem.
Submit the problem to IBM Software Support

You can submit the problem to IBM Software Support online or by telephone. Online Go to the IBM Software Support Web site at http://www.ibm.com/ software/support/probsub.html. Enter your information into the appropriate problem submission tool. By Telephone For the telephone number to call in your country, go to the contacts page of the IBM Software Support Handbook at http:// www14.software.ibm.com/webapp/set2/sas/f/handbook/contacts.html. If the problem that you submit is for a software defect or for missing or inaccurate documentation, IBM Software Support creates an Authorized Program Analysis Report (APAR). The APAR describes the problem in detail. If a workaround is possible, IBM Software Support provides one for you to implement until the APAR is resolved and a fix is delivered.
xviii
Chapter 1. Tivoli Service Automation Manager overview

Tivoli Service Automation Manager assists in the automated provisioning, management, and deprovisioning of cloud resources, comprised of hardware servers, networks, operating systems, middleware, and application-level software. Several virtualization environments (hypervisors) are supported in the process of individual virtual server provisioning.
Tivoli Service Automation Manager also provides management support for services consisting of a specific set of middleware, in combination with AIX, and Linux (System x and System z). IBM provides many automation and best-practice service definition templates, including specialized job plans or workflows. Tivoli Service Automation Manager makes use of the entire spectrum of Tivoli process automation engine tools. Tivoli Service Automation Manager helps you define and automate services that are lifecycle oriented, for example, a service to establish and administer an IT server network for a limited period of time, to satisfy increased demand for processing capacity or to serve as a test environment. Predefined service definitions determine the overall framework for the services. The actual service instances are requested using these service definitions. The Self-Service Virtual Server Management environment, is used by the cloud users to request provisioning and manage the virtual environments. Tivoli Service Automation Manager uses IBM Service Management and the Tivoli process automation engine as an integration platform. IBM Service Management is an approach designed to automate and simplify the management of business services. It concentrates on four areas: v v v v Technology integration and standards Improved collaboration among IT people spread across organizational silos Best-practices based process modules for automated process execution Sharing of business-critical IT information to improve decision making
Tivoli Service Automation Manager offers the following standard service environments and definitions: Self-Service Virtual Server Management environment In this service environment, which is a collection of service offerings, users request the provisioning of projects comprising virtual servers. The service environment has an intuitive self-service user interface with Web 2.0 technology for enhanced interactive feedback. An administrator function is also provided. The basic service structure described in Service structure on page 17 supports this component, except for the interface to Tivoli Monitoring, which has a different implementation in the Self-Service Virtual Server Provisioning context.
WebSphere Cluster Service This optional, separately priced service provisions and manages a WebSphere cluster.
Product components
This section provides the overview the components of Tivoli Service Automation Manager.
Tivoli Service Automation Manager Installation Launchpad

The Tivoli Service Automation Manager Installation Launchpad guides the user through the installation process. For details, see Chapter 2, Installing Tivoli Service Automation Manager, on page 25.
Self-Service Virtual Server Management

Tivoli Service Automation Manager provides support for user-initiated provisioning and management of virtual servers on System x, System p, 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.
v v v v v
Deleting individual servers. Canceling a project and deleting all of the associated virtual servers. Starting, stopping, and restarting virtual servers. Resetting the administrator password on a virtual server. 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.
Chapter 1. Product overview
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.
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 http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/index.jsp?toc=/ com.ibm.itm.doc/toc.xml). 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 15. 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
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.
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.
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 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 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 82 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 211, 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 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: 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
10
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). 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
11
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 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
12
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 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
13
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 None Global Service Definition Topology Meaning Uniqueness not enforced (default scope) Uniqueness is enforced across all topology nodes known to the system Uniqueness is enforced across all topologies of service deployment instances derived from one service definition 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 Uniqueness is enforced on a per-host basis. Nodes deployed on the same host must not define the value for an attribute 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
Host Group
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 Exact Wildcard Meaning Only values of identically named attributes are considered for uniqueness handling (default) 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
14
Table 3. Uniqueness specifications for attribute names (continued) Attribute name uniqueness Alias group Meaning 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 Increment Meaning 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. 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.
15
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 (http://publib.boulder.ibm.com/infocenter/tivihelp/v15r1/ index.jsp?toc=/com.ibm.itm.doc/toc.xml). 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 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
16
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. 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.
17
Resources Actual hardware and software that can be used in constructing the landscape.
Service provider support

The new service provider feature introduced with Tivoli Service Automation Manager 7.2.2 allows for creating 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 are always assigned to one customer only. They can be assigned to multiple teams, but all of these teams must belong to the same customer. Users can view only the information and resources that are related to their associated customer. 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 7.2.2, 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 v Cloud network templates v Cloud storage pools v Master images v Software products 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
18
The multi-customer support in Tivoli Service Automation Manager 7.2.2 introduces new tasks related to the data segregation system. This system must ensure that users see only the data assigned to them. Three new roles are introduced in the self-service user interface: cloud customer administrator, approver, 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. Cloud customer administrator role is strictly connected with the cloud customer level. Users in this role have authorities similar to the authorities of a cloud administrator, but they are dedicated to individual customers. They have no authority to create or remove users and register or unregister software 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. Security administrator can create, manage and delete users. User roles are called security groups in version 7.2.2, and a user can be a member of multiple security groups. In Tivoli Service Automation Manager 7.2.2, 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 Extended Solution Guide. Related information 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 Service Definitions
Report Type
Report Name
Selection Parameters
Content List of all service definitions and instances.
All Service Definitions AllSD <service> .rptdesign
19
Table 5. Summary of Tivoli Service Automation Manager Reports and Content (continued)
Tivoli Service Automation Manager Application Service Definitions
Report Type Service Definition Summary
Report Name SDSummary <service> .rptdesign SDDetail <service> .rptdesign
Selection Parameters Status Owner From Date To Date Service Name
Content Basic service definition information and list of service definitions and deployments. Service-dependent content with identifying information, status, topology, monitoring and resource assignments, and service definition history
Service Definitions
Service Definition Details
Service Deployment Instances
Service Deployment Summary
SISummary <service> .rptdesign
Status Service-dependent graphics Owner and lists showing CPU and Service Definition Name memory levels, servers by From Date owner, servers by platform To Date architecture, monitoring agents by type, and instances Service Name Service-dependent content including graphics showing CPU, memory, servers by architecture, monitoring agents, and service history Information concerning components of the service instance that are located on the same physical server Service-dependent graphics showing CPU, memory, servers (over time and for all deployments)
Service Deployment Details
SIDetail <service> .rptdesign
Co-Located Nodes
coLocation <service> .rptdesign SISummaryHistory <service> .rptdesign
Host Name
Service Deployment History Summary
From Date To Date
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. For details on generating reports, see Working with the service automation reports on page 243. For post-installation setup tasks required to activate the Reporting function, see Configuring the reporting function on page 244.
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.
20
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 226. To find out how to employ the collected data in the form of reports, see Working with usage and accounting reports on page 247.
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. 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.
21
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.0.2 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 2.3.0.2 in the IBM Systems Director Information Center: http://publib.boulder.ibm.com/ infocenter/director/v6r2x/topic/com.ibm.director.vim.helps.doc/ fsd0_vim_c_vmc_230.html. 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 158 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 430.
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 256.
22
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 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
23
inherent product knowledge for WebSphere workloads without the need to switch between multiple service management portals.
24
Chapter 2. Installing Tivoli Service Automation Manager

This section describes how to install Tivoli Service Automation Manager and its prerequisite software.
Starting the Tivoli Service Automation Manager Installation Launchpad

The Tivoli Service Automation Manager Installation Launchpad can be started from DVD or the hard disk drive.
Before you begin

Note: The procedure given here is the basic procedure. See the Tivoli Provisioning Manager Installation Guide for additional information, in particular concerning the use of Firefox and mounting the DVD.
Procedure
1. Log on as root (Linux or AIX) or from an account with system administration privileges (Windows). 2. If you are using DVDs, insert the Tivoli Service Automation Manager Base DVD to run the Launchpad. 3. Run the Tivoli Service Automation Manager Installation Launchpad: v v
Windows Linux
: from ./TSAMBASE7220/launchpad.exe. or
AIX
: by running ./TSAMBASE7220/launchpad.sh.
Note: Under Linux or AIX, ensure that launchpad.sh is executable. If not, you must ensure the required access rights for it, for example:
chmod -R 777 ./TSAMBASE7220/launchpad.*
4. When the Launchpad is started, you can select the language from the drop-down list in the upper right corner of the main window.
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).
25
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 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 WebSphere Application Server component. Three basic installation scenarios are supported: v A new installation, in which none of the software is already installed. v An installation using an existing Tivoli Provisioning Manager 7.2, in which only Service Request Manager and Tivoli Service Automation Manager are installed. v An 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:
26
Table 6. Installation scenarios Installation Scenario Existing Tivoli Provisioning Manager 7.2 Existing Service Request Manager 7.2.0.1
Installation segment Install middleware Install base services Install Tivoli Provisioning Manager Core Install Tivoli Provisioning Manager Web Install Tivoli Provisioning Manager for Images Install Service Request Manager 7.2 Install Service Request Manager 7.2 Hotfix 7 Install Tivoli Provisioning Manager 7.2 Fix Pack 1 Install Tivoli Provisioning Manager 7.2 Fix Pack 2 Install Tivoli Service Automation Manager Applications Install Tivoli Service Automation Manager enablement keys Install additional configuration files Install automation packages Install Tivoli Service Automation Manager for WebSphere Application Server (optional)
New installation X X X
X X
X X X
X X X
X X X
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
Chapter 2. Installing
27
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 39 c. Defining whether the current server will be used as administrative server or management server. See Preparing the environment for installation on page 43. d. Preparing the management and administrative servers for the installation. See v Preparing an AIX management server on page 44 v Preparing a Linux management server on page 54 v Preparing a Windows administrative server on page 61 v Preparing a Linux administrative server on page 62 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 43. 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 63. 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 63. 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
28
d. Configuring the Tivoli Service Automation Manager interfaces to external products See Post-installation steps on page 83 and the configuration chapter for the applicable virtualization environment.
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 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.
29
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 7. Management server hardware and operating system requirements Hardware System p Operating System IBM AIX 6.1 Technology Level 3 64bit IBM AIX 5.3 Technology Level 10, 64bit Red Hat Enterprise Linux Advanced Server 5 Update 5 x86 64bit System x Red Hat Enterprise Linux Advanced Server 5 Update 4 x86 64bit 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 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: The following are minimum free-space requirements for key system directories during installation. These figures apply to a single-server configuration. Refer to the Tivoli Provisioning Manager installation documentation for space data concerning the individual software components that apply in a multiserver configuration.
Table 8. Minimum free space requirements for the management system (AIX) Directory or category / (root) /home /opt /usr /tmp /var/tmp Recommended free space (approximate) Installation images Space required (single-server configuration) 3 GB 20 GB 13 GB 9 GB 10 GB 8 GB 60 GB 20 GB
30
Table 9. Minimum free space requirements for the management system (Linux) Directory or data category / (root) /home /opt /usr /tmp /var/tmp Recommended free space (approximate) Installation images Space required (single-server configuration) 3 GB 20 GB 18 GB 1 GB 10 GB 8 GB 60 GB 20 GB
A minimum of 8 GB of memory (RAM) is required. For adequate run-time performance, 2 or more CPUs and 10 GB of memory (RAM) are recommended. The minimum required memory for non-English systems is 10 GB. Command line prompt: It is required that the command-line prompt for the root user consists of one of the following marks followed by a space: #, >, or $. Example: To set the prompt to start with #, log in as root and add or change the export PS1 line in file .profile (AIX) or .bashrc (Linux) to:
export PS1="# "
Log out and then in again for the change to take effect.
Requirements for the administrative server

See the Tivoli Provisioning Manager Installation Guide for details. The administrative server must meet the following minimum requirements:
Table 10. Administrative server requirements Hardware System p Operating System AIX 6.1 Technology Level 3 (IBM System p 64-bit) Windows Server 2003 Service Pack 3 (Standard, Enterprise, or DataCenter), 32 or 64bit Windows 2008 R2 System x SUSE Linux Enterprise Server 10 Service Pack 3 64-bit Red Hat Enterprise Linux Advanced Server 5 Update 4 x86 64bit Red Hat Enterprise Linux Advanced Server 5 Update 5 x86 64bit
Note: The software packages needed depend on the platform of the administrative server. When using a Windows administrative server, software packaged for Windows is required. When using a Linux administrative server, software packaged for Linux is required. Software packaged for either platform can be used on either environment.
31
Disk space: Recommended minimum free space is 40 GB, with an additional 10 GB for installation images. 12 GB of the required 40 must be reserved for the following directories: v v
Windows Linux
: C:\IBM\SMP and
AIX
: /opt/IBM/SMP
Important: If the administrative server is on the same system as the management server, the space requirement for /opt/IBM/SMP must be added to the space requirement for /opt on the management server.
Requirements for the managed environment

The following requirements apply to the hardware and software involved in the provisioning and management of virtual servers by Tivoli Service Automation Manager:
32
Table 11. Managed-environment server requirements Platform System x Hypervisor v VMware ESX 3.5 v VMware ESXi 3.5 Virtual Server (Guest) Operating System v SUSE Linux Enterprise Server 10 v SUSE Linux Enterprise Server 11 Remarks The following minimum build levels are needed to support Windows 2008: v ESXi 3.5.0 Build 153875
v Red Hat Enterprise Linux v vCenter Server 2.5.0 Build 147633 5.4 v Red Hat Enterprise Linux 5.5 v Microsoft Windows 2008 v VMware ESX 4.0, ESXi 4.0 v vSphere 4.0 v vSphere 4.1 v SUSE Linux Enterprise Server 10 v SUSE Linux Enterprise Server 11 The following minimum build levels are needed to support Windows 2008: v vCenter Server 2.5.0 Build 147633
v Red Hat Enterprise Linux v VMware ESX 4.0 for 5.4 Vitalization Executive v Red Hat Enterprise Linux (Hypervisor) 5.5 v Microsoft Windows 2008 v Microsoft Windows 2008 R2 KVM on Red Hat Enterprise Linux 5.4 v Red Hat Enterprise Linux RHEV-H 5.4 is not supported. 5.4 v Red Hat Enterprise Linux 5.5 v SUSE Linux Enterprise Server 11 Xen 3.0.3 on Red Hat Enterprise Linux 5.3 v Red Hat Enterprise Linux 5.4 v SUSE Linux Enterprise Server 10.2 v CentOS 5.3 System p P-Hypervisor (including PowerVM and PowerVM via VMContol) v AIX 5.3 v AIX 6.1 v AIX 7.1 v POWER7 Blades are supported. POWER5 and POWER6 Blades are not supported. v IBM Systems Director VMControl version 2.3.0.2 Enterprise Edition is supported. 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.
33
Software requirements for Tivoli Service Automation Manager

Tivoli Service Automation Manager depends on other software to provide services to complete requests. See also the Installation Guide for Tivoli Provisioning Manager in its information center at: http://publib.boulder.ibm.com/infocenter/tivihelp/v38r1/index.jsp. The following table summarizes the software components in a Tivoli Service Automation Manager environment.
Table 12. Summary of software in the Tivoli Service Automation Manager environment Software Component Version Remarks
Tivoli Service Automation Manager Tivoli Service Automation Manager (Base) Tivoli Service Automation Manager Installation Launchpad Tivoli Service Automation Manager for WebSphere Application Server (optional) 7.2.2 7.2.2
7.2.2
Tivoli Service Request Manager Tivoli Service Request Manager 7.2.0 with Fix Pack A previous installation of Service Request Manager without Tivoli 1 (7.2.0.1) 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 Tivoli Provisioning Manager Tivoli Provisioning Manager 7.2 A previous installation of Tivoli Provisioning Manager can be used. In this case, the middleware and base services were installed with Tivoli Provisioning Manager.
Fix Pack 1 Fix Pack 2
IBM Tivoli Monitoring (optional) IBM Tivoli Monitoring (optional) IBM Tivoli Monitoring for AIX (optional) Base Services Base services Base services fix pack 7.1.1.6 7.1.1.8 This component is included with Tivoli Provisioning Manager. This component is included with Tivoli Service Automation Manager. 6.2.1 or 6.2.2 6.2.1 or 6.2.2 Must be installed separately. Must be installed separately.
Middleware (included with Tivoli Provisioning Manager) Tivoli Directory Server (LDAP) DB2 6.1.0.10, 6.2.0.2 9.5 FP3a Use version 6.1.0.10 on AIX 5.3.
34
Table 12. Summary of software in the Tivoli Service Automation Manager environment (continued) Software Component WebSphere Application Server Network Deployment IBM HTTP Server Self-service user interface External Software Tivoli Usage and Accounting Manager Web browser for Installation Launchpad 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. 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 43 the Tivoli Provisioning Manager Installation Guide, and other update information for browser restrictions or differences between the browser products. 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 43 the Tivoli Provisioning Manager Installation Guide, and other update information for browser restrictions or differences between the browser products. 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 43 the Tivoli Provisioning Manager Installation Guide, and other update information for browser restrictions or differences between the browser products. 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. Version 6.1.0.23 Remarks Use version 6.1.0.29 on SUSE Linux 11.
6.1.0.23
Use version 6.1.0.29 on SUSE Linux 11.
As supported by the Common Launchpad initiative
Web browser for self-service user interface
Microsoft Internet Explorer 7 or 8, Mozilla Firefox 3
Tivoli Remote Execution and Access
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 >.
35
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.
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 v v v System System System System z x x x (z/VM Linux) (VMware) (Xen) (KVM)
36
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 Mozilla Firefox 3.5 or 3.6 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 on page 38 for information related to provisioning virtual servers (as z/VM guests) on System z.
37
For more information, see Chapter 2, Installing Tivoli Service Automation Manager, on page 25.
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 136. See also Requirements for Self-Service Virtual Server Management on page 37 for specific requirements related to Self-Service Virtual Server Management. 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 43. Software requirements for the z/VM host platform: v v v v z/VM 5.4 DirMaint RACF (optional) 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
38
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. 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 136.
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.
39
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:
Table 13. Installation steps and servers on which the corresponding installation files must be available Management system Provisioning server (Tivoli Service Automation Manager management server) X
Step Middleware
DVD or CD, or Administrative downloaded files server Tivoli Provisioning Manager 7.2 Middleware Tivoli Provisioning Manager 7.2 Installation Tivoli Provisioning Manager 7.2 core components X
Database server X
Directory server X
Base services
Tivoli Provisioning Manager core components
Tivoli Tivoli Provisioning Provisioning Manager Fix Pack Manager 7.2 Fix Pack 1 core 1 core components components Tivoli Tivoli Provisioning Provisioning Manager Fix Pack Manager 7.2 Fix Pack 2 core 2 core components components Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components Tivoli Provisioning Manager web components Tivoli Provisioning Manager 7.2 Fix Pack 2 Interim Fix 1 Tivoli Provisioning Manager 7.2 Installation X
Tivoli Tivoli Provisioning Provisioning Manager Fix Pack Manager 7.2 Fix 1 web Pack 1 web components components
40
Table 13. Installation steps and servers on which the corresponding installation files must be available (continued) Management system Provisioning server (Tivoli Service Automation Manager management server)
Step
DVD or CD, or Administrative downloaded files server X
Database server
Directory server
Tivoli Tivoli Provisioning Provisioning Manager Fix Pack Manager 7.2 Fix 2 web Pack 2 web components components Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 web components Service Request Manager Tivoli Provisioning Manager 7.2 Fix Pack 2 Interim Fix 1 Tivoli Service Request Manager for Service Providers 7.2 Tivoli Service Automation Manager 7.2.2 base Tivoli Service Automation Manager for WebSphere Application Server 7.2.2
Tivoli Service Automation Manager Tivoli Service Automation Manager for WebSphere Application Server
In the Tivoli Service Automation Manager Launchpad, navigate to Installation Planning > Installation Files to specify the locations where you 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_V720_Install_Unix.tar, TPM_V720_CoreComp_1of2_Unix.tar, and TPM_V720_CoreComp_2of2_Unix.tar.
Windows : TPM_V720_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: CZWY4ML.tar. v For Tivoli Provisioning Manager Fix Pack 1 core components:
AIX 7.2-TIV-TPM-AIXPPC64-FP0001.tar and 7.2-TIV-ComponentsAIXPPC64-FP0001.tar
7.2-TIV-TPM-Linux-FP0001.tar and 7.2-TIV-Components-LinuxFP0001.tar

Linux
41
Linux System z: 7.2-TIV-TPM-Linux-FP0001.tar and 7.2-TIV-ComponentszLinux-FP0001.tar.
Note: Unpack the -Components- packages into the same location where the core components part was unpacked. v For Tivoli Provisioning Manager Fix Pack 1 web components:
UNIX
7.2-TIV-WebComp-Unix-FP0001.tar
Windows 7.2-TIV-WebComp-Windows-FP0001.zip v For Tivoli Provisioning Manager Fix Pack 2 core components:
AIX 7.2-TIV-TPM-AIXPPC64-FP0002.tar and 7.2-TIV-ComponentsAIXPPC64-FP0002.tar
7.2-TIV-TPM-Linux-FP0002.tar and 7.2-TIV-Components-LinuxFP0002.tar

Linux Linux System z: 7.2-TIV-TPM-Linux-FP0001.tar and 7.2-TIV-ComponentszLinux-FP0001.tar.
Note: Unpack the -Components- packages into the same location where the core components part was unpacked. v For Tivoli Provisioning Manager Fix Pack 2 web components:
UNIX
7.2-TIV-WebComp-Unix-FP0002.tar
Windows 7.2-TIV-WebComp-Windows-FP0002.zip v For Tivoli Provisioning Manager interim fix:
Windows Linux
7.2.0.2-TIV-TPM-Multi-IF00001.zip
7.2.0.2-TIV-TPM-Multi-IF00001.zip and 7.2.0.2-TIV-ComponentsLinux-IF00001.tar

Linux System z: 7.2.0.2-TIV-TPM-Multi-IF00001.zip and 7.2.0.2-TIV-Components-zLinux-IF00001.tar.
7.2.0.2-TIV-TPM-Multi-IF00001.zip and 7.2.0.2-TIV-ComponentsAIXPPC64-IF00001.tar

AIX
Attention: 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.
42
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. 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 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.
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 29. 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.
43
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 39). 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 63).
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 29. 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.
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.
44
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
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.
45
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 Tivoli Service Automation Manager Installation Launchpad on page 25. 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 29. 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 29). Verify the following information:
46
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. 6. 7. 8. Select Enhanced Journaled File Systems Select Change / Show Characteristics of an Enhanced Journaled File System. Select the file system name from the list and press Enter. 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:
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.
47
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 hd6 hdisk1 Volume Group rootvg Size %Used Active 4096MB 1 yes Auto yes Type 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 hd6 hdisk1 Volume Group rootvg Size %Used Active 8092MB 1 yes Auto yes Type 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
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
48
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:
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:
49
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 9.152.21.28 127.0.0.1 Hostname # Comments myserver.mycompany.com myserver 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, for example:
chkconfig -level 2345 iptables off service iptables save service iptables stop
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.
50
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 Tivoli Service Automation Manager Installation Launchpad on page 25. 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 or higher) 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 v xterm (the path is/usr/bin/X11/xterm) Note: For more information about the packages, see the Tivoli Provisioning Manager documentation: http://publib.boulder.ibm.com/infocenter/tivihelp/ v38r1/index.jsp?topic=/com.ibm.tivoli.tpm.ins.doc/install/rins_packages.html .
51
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 37. 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: 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
52
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, tar, and gzip are accessible from /usr/bin:
root@myserver lrwxrwxrwx root@myserver 0 root@myserver lrwxrwxrwx root@myserver 0 root@myserver lrwxrwxrwx root@myserver 0 ~# ls -l /usr/bin/expect 1 root system 29 Sep 4 15:25 /usr/bin/expect@ -> ../../opt/freeware/bin/expect* ~# echo $? ~# ls -l /usr/bin/tar 1 root system 21 Sep 10 13:56 /usr/bin/tar@ -> /opt/freeware/bin/tar* ~# echo $? ~# ls -l /usr/bin/gzip 1 root system 27 Sep 4 15:25 /usr/bin/gzip@ -> ../../opt/freeware/bin/gzip* ~# echo $?
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:
53
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 Tivoli Service Automation Manager Installation Launchpad on page 25. 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 29. 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.
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.
54
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 8192 or higher for the root user, add the following entry to the file:
root - nofile 8192
3. For SUSE Linux Enterprise Server 11, add the following values to /etc/profile:
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
55
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 Tivoli Service Automation Manager Installation Launchpad on page 25 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. 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.
56
[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.
# Internet Address 9.152.27.78 127.0.0.1 Hostname # Comments myserver.mycompany.com myserver 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
57
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: Starting INET services. (xinetd) done failed
If it still does not start, enable any service, for example echo. 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 id socket_type protocol user wait disable }
= = = = = = =
INTERNAL echo-stream stream tcp root no no
Start xinetd again:

[root@myserver ~]# /etc/init.d/xinetd start Starting INET services. (xinetd) done
58
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 (uncommented 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 Mem: Swap: total used free 10432819200 10371768320 61050880 21476163584 0 21476163584 shared 0 buffers cached 77840384 9825697792
Verification: 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 Tivoli Service Automation Manager Installation Launchpad on page 25 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.
59
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 the following section: http://publib.boulder.ibm.com/infocenter/tivihelp/v38r1/index.jsp?topic=/ com.ibm.tivoli.tpm.ins.doc/install/rins_packages.html. The following three packages are specific for Tivoli Service Automation Manager: libXaw, procmail, xterm.
Table 14. Required packages for Linux management servers Package compat-db-4.1.25-9 compat-libstdc++ curl expect 5.42 or later ftp gtk libaio libstdc++ libXaw 32bit-version libXmu libXp libXpm ncftp openssh perl procmail rpm-build-4.3.3-22 tcl telnet tk wget xorg-x11-xfs xorg-x11-font-utils xterm RHEL only RHEL only For Linux, the required path for xterm is /usr/bin/xterm. RHEL only RHEL 5.5 only Not required for Linux on System x Linux on System z only RHEL only SLES only Remarks RHEL only. For RHEL 5, the 32-bit and the 64-bit versions are required. No longer available. Use libstdc++ for 32 and 64 bit.
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 Tivoli Service Automation Manager Installation Launchpad on page 25.
60
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
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.
61
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 127.0.0.1 192.168.1.101 tsam-admin-server.mycompany.com tsam-admin-server loopback host.domain localhost 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. In general, the requirements for setting up a Linux administrative server are analogous to those for a Windows server. See Preparing a Windows administrative server on page 61 Note: For Red Hat Enterprise Linux version 5.5 you need to install an additional library libXaw 32bit-version that is required for the Launchpad.
Preparing an AIX administrative server

Components packaged for a AIX-based installation require an AIX administrative server. An AIX administrative server can be co-located with an AIX management server if the hardware and software requirements are met. In general, the requirements for setting up an AIX administrative server are analogous to those for a Windows server. See Preparing a Windows administrative server on page 61 Note: The AIX level is not automatically detected when using Firefox 3.5. Ensure that the AIX level you are using is supported.
62
Installing Tivoli Service Automation Manager and its prerequisite software

Installing Tivoli Service Automation Manager involves running the Tivoli Service Automation Manager Installation Launchpad on the administrative and management system servers to install the software on the management system. The sequence of these invocations and the respective server involved is dictated by the software and the installation scenario. This involves some switching between the two environments. Some software related to the deployment process is installed on the administrative server. However, this server is not required for normal operation when installation has been completed.
Before you begin

Consult the Release Notes for Tivoli Service Automation Manager and the associated products for up-to-date information. The installation process employs the Tivoli Service Automation Manager Installation Launchpad to install Tivoli Provisioning Manager, Service Request Manager, and Tivoli Service Automation Manager. In the Tivoli Provisioning Manager documentation, the process is referred to as a custom installation. Special icons are provided in the Launchpad to indicate the server (administrative or management) on which a particular step must be performed. 1. Ensure that you have selected the function of the current server. You can do that on the Installation Planning page in the Launchpad. 2. Ensure that you have specified and verified the locations of all installation source files in the Installation Planning page in the Launchpad. 3. Ensure that the pre-installation steps have been completed. See Preparing the environment for installation on page 43. 4. Important: Create backup copies of the management and administrative servers. If the installation fails, you will have to restore to these backup images. Note: Throughout the installation and configuration processes, there may be recommendations to back up the administrative and management servers. While backing up is not required, it is strongly recommended. If a backup image is not taken and the installation fails, you may have to start again with a clean operating system image. Perform the operation on both the administrative and management servers. If the administrative and management servers are virtual machines, you can use the VM image backup capability provided by your virtualization software. For example, a VMware virtual machine can also be backed up by taking a snapshot of the VM image. An AIX management server running in an LPAR can be backed up to a NIM server. For servers installed on physical hosts, however, commercial backup software such as Norton Ghost can be used. UNIX servers can be backed up and restored using the dd utility. For details, consult the system administration guide for your operating system. 5. As recommended in the Tivoli Provisioning Manager Installation Guide, consider disabling antivirus software on all involved servers for the duration of the installation.
Procedure
1. Start the Launchpad on the server on which you want to perform the installation first, based on the preinstalled components.
63
2. Install the Tivoli Service Automation Manager license (see Installing the Tivoli Service Automation Manager license on page 67). The installation-related links in the Launchpad are unavailable until the license agreement has been accepted and the license installed. Note: License acceptance is required once on each server on which the Launchpad is invoked. 3. For a new installation: a. Install the middleware (see Installing the middleware on page 67). b. Install the base services and language pack (see Installing base services on page 69). 4. If Tivoli Provisioning Manager 7.2 was not installed previously: a. Install the Tivoli Provisioning Manager core components (see Installing the Tivoli Provisioning Manager core components on page 70) b. Install the Tivoli Provisioning Manager web components (see Installing the Tivoli Provisioning Manager web components on page 71) 5. If Service Request Manager 7.2 and 7.2.0.1 were not installed previously: a. Install Service Request Manager, Service Request Manager fix pack, and related interim fix. For more information, see Installing Tivoli Service Request Manager (step 1 of 2) on page 72. 6. Install Tivoli Provisioning Manager Fix Pack 1: a. Install the Tivoli Provisioning Manager Fix Pack 1 core components (see Installing Tivoli Provisioning Manager Fix Pack 1 core components on page 74) b. Install the Tivoli Provisioning Manager Fix Pack 1 web components (see Installing Tivoli Provisioning Manager Fix Pack 1 Web components on page 74) 7. Install Base Services Fix Pack 7.1.1.8 (see Installing Base Services Fix Pack on page 75). 8. Install additional components of Service Request Manager. For more information, see Installing Tivoli Service Request Manager (step 2 of 2) on page 76. 9. Install the Tivoli Provisioning Manager Fix Pack 2: a. Install the Tivoli Provisioning Manager Fix Pack 2 core components (see Installing Tivoli Provisioning Manager Fix Pack 1 core components on page 74) b. Install the Tivoli Provisioning Manager Fix Pack 2 web components (see Installing Tivoli Provisioning Manager Fix Pack 1 Web components on page 74) 10. Install the Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1: a. Install the Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components (see Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components on page 78) b. Install the Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 web components (see Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 Web components on page 79) 11. Install the Tivoli Service Automation Manager applications (see Installing the Tivoli Service Automation Manager applications on page 79) 12. Install additional configuration files. (see Installing additional configuration files on page 80)
64
13. Install the automation packages for Tivoli Service Automation Manager (see Installing the automation packages for Tivoli Service Automation Manager on page 81) 14. (Optional) Install Tivoli Service Automation Manager for WebSphere Application Server (see Installing optional software on page 82). 15. Perform the post-installation steps (see Post-installation steps on page 83). 16. Verify the integrated solution of the Tivoli Process Automation Engine components by performing connectivity tests (see Verifying the integrated installation on page 84). Note: After completing the installation, make sure to reset any operating system modifications that were required only during the installation. Refer to the Tivoli Provisioning Manager documentation for details.
Installation defaults for Tivoli Service Automation Manager

To avoid conflicts within your enterprise, review the defaults the installation process uses to determine if you should perform an advanced install and set new values. Whether the default values that Tivoli Service Automation Manager uses conflict with systems already in place or do not adhere to standards in your enterprise is a key consideration when deciding between a simple or advanced install. To help with that decision, Table 15 lists the defaults used by the installer. Use this table to record your values as an aid when you run the installer.
Table 15. Default and your values for properties Installation Panel Remote Access Configuration DB2 Configuration Property User ID Default Value root Your value
Installation Directory Linux, AIX: /opt/IBM/db2/v9.5 Port Linux Red Hat: 50000 Linux SUSE (SLES 10 and 11): 50001 AIX: 50000 Note: On SUSE Linux, the middleware installer (MWI) initially offers the port 50000, but this port is typically already in use. If this is the case, use port 50001 instead. db2inst1 dasusr1 db2fenc1 db2grp1 ctginst1 ctginst1
Instance Userid DAS User ID Fence User ID Admin Group CCMDB User ID Config Instance Username
65
Table 15. Default and your values for properties (continued) Installation Panel Property Default Value Your value
IBM Tivoli Directory Server Installation Directory Linux, AIX: Configuration /opt/IBM/ldap/V6.2 Administration Port Secure Administration Port Instance Name Database Name Database Port LDAP Port Secure LDAP Port LDAP Username LDAP Suffix LDAP Organization WebSphere Configuration 3538 3539 idsccmdb security 3708 389 636 cn=root o=organization,c=country ou=orgunit
Installation Directory Linux: /opt/IBM/WebSphere/AppServer AIX: /usr/IBM/WebSphere/AppServer User ID wasadmin
IBM HTTP Server Configuration
Installation Directory Linux /opt/IBM/HTTPServer AIX /usr/IBM/HTTPServer Administration Port HTTP Port 8008 80 /opt/IBM/SMP Linux: ~root/ibm/tivoli/mwi/workspace 50005 maxdb71 maximo MAXIMOCLUSTER u=users,o=organization,c=country u=groups,o=organization,c=country intjmsds
Base Services
Base services location Tivoli middleware workspace location Port Database Name Database user ID Cluster name User base entry Group base entry
Integration Adapter JMS Configuration Tivoli Provisioning Manager
JMS DataSource Name
For details, refer to the Tivoli Provisioning Manager Installation Guide.
66
Installing the Tivoli Service Automation Manager license

To activate the installation links in the Installation Launchpad you must first install the licence. The license must be installed on each server on which the Launchpad is started. Acceptance of the license agreement in each case is recorded.
Before you begin

Server: Any
Procedure
1. Start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > License Agreement. 3. Click on the link to install the license. 4. Read and accept the license agreement. When the license has been installed, the Launchpad panel refreshes and the links become active.
Installing the middleware

You can use the Tivoli Service Automation Manager Installation Launchpad to install the middleware. Omit this step if the middleware has already been installed for an existing product. If Service Request Manager or Tivoli Provisioning Manager has already been installed, the associated middleware is also present.
Before you begin

Important: 1. If you are installing the middleware on SUSE Linux Enterprise Server 11, see the instructions in Installing the middleware on Solaris 10 SPARC and SUSE Linux Enterprise Server 11 in the Tivoli Provisioning Manager information center. 2. While installing WebSphere Application Server 6.1 (build WAS-ND_LinuxIA64_Custom_v61023_ISC7106.tar.gz.) on SLES 11 x86_64 bit, a message warning that your operating system failed a prerequisite check may appear. Ignore this message and install WebSphere Application Server 6.1 and Fix Pack 29. 3. You must use the Tivoli Service Automation Manager Installation Launchpad and not the Tivoli Provisioning Manager Launchpad. Once the middleware installer has started, however, refer to the corresponding section in the Tivoli Provisioning Manager information center for detailed instructions. 4. If you encounter an error during the installation of the WebSphere plug-in, perform the workaround: edit the file /opt/.ibm/.nif/.nifregistry and remove the entry "6.1.0-WS-IHS-LinuxX64-FP0000029". 5. DB2 9.7 is included in the Tivoli Service Automation Manager installation bundle because it is possible to upgrade to DB2 9.7 after the installation. However, installing Tivoli Service Automation Manager on DB2 9.7 is not supported. Instead, use the middleware bundle available for Tivoli Provisioning Manager 7.2, which includes DB2 9.5. Server: Each server in the management system
67
The distribution of the middleware in the management system depends on the number of physical servers. The middleware installer can install a selected combination of the three software servers (provisioning/application, database, directory) on the current physical server each time it is started. The default installation is performed on one server and all three options can be selected at once.
Procedure
To install the middleware on a single server, start the Tivoli Service Automation Manager Installation Launchpad on that server: 1. Click Product Installation > Foundation Software > Install the middleware. 2. Click the link to verify the middleware installation prerequisites. Select the check box and hit return. 3. Specify the location of the Tivoli Provisioning Manager installation DVD or the directory in which you unpacked the installation package TPM_V72_Install_Win.tar or TPM_V72_Install_Unix.tar. 4. Select the language 5. To install all middleware on one server, check the boxes for all parts of the middleware (DB2, Directory Server, WebSphere). 6. Complete the installation. Note: To distribute the middleware on up to three servers (provisioning server, database server, and directory server), you can invoke the middleware installer several times, once on each server. Repeat the single server installation procedure on each server. Depending on the middleware you want to distribute on a given server, check the appropriate box and complete the installation.
What to do next
1. Optional: You can now configure the script for controlling the middleware. This script simplifies middleware operations such as starting and stopping. It must be configured prior to use. See Controlling the middleware with a script on page 291. 2. Start the middleware for verification, for example, by using the script from the previous step. Note: Do not continue until all problems or discrepancies have been resolved. 3. Perform a backup of the management system servers. 4. After installing the middleware, install a fix for WebSphere 6.1 to address the Java parseDouble vulnerability security issue. Refer to http://www.ibm.com/ support/docview.wss?uid=swg21469961 for the necessary steps. This step can be done at any time after the middleware has been installed, preferably before the system is made available to users. The fix does not affect the functionality of Tivoli Service Automation Manager.
68
Installing base services

Base services are components that are shared by multiple products in the process automation environment. Note: Omit this step if the base services were already installed with an existing product. For example, if Tivoli Service Request Manager or Tivoli Provisioning Manager is already installed, the base services are also present.
Before you begin

v The AIX level is not automatically detected when using Firefox 3.5. Ensure that you are using a supported level as your administrative server. v Ensure that the middleware is started as described in Starting the management server on page 289. Server: Administrative server The procedure must be run on the administrative server. This same server later becomes the mandatory administrative server for subsequent component installation.
Procedure
1. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25 2. Navigate to Product Installation > Foundation Software > Install the Base Services and required components. 3. Click the link to verify the base services installation prerequisites. When you are done with the verification, select the check box and click Back to the product installation page. 4. Click the link to install the base services. Refer to the Tivoli Provisioning Manager Installation Guide for detailed instructions. 5. When the Process Solution Installer is started, an overview table is displayed showing which version of base services is to be installed. Make sure that in the Target version field the version number for base services is 7.1.1.6. If 7.1.1.8 is displayed, then you have selected the wrong base services installer package (the one that comes with Tivoli Service Automation Manager). Make sure that you select the base services package that is packaged with Tivoli Provisioning Manager 7.2.
What to do next
1. Verify that DBHEAP settings for DB2 are set to 6000 or more. Run the command: su - ctginst1 -c "db2 get database configuration for maxdb71" | grep DBHEAP If the settings are not correct: a. Connect to the database: db2 connect to <database_name> user <database_user> using <database_password> where: v <database_name> is maxdb71 by default
69
Windows
<database_user> is db2admin by default
UNIX <database_user> is ctginst1 by default v b. Update the database configuration:
db2 update db cfg using dbheap 6000 c. Reset the database connection: db2 connect reset 2. Verify the installation by logging on to the administrative user interface at https://<IP address of the administrative server>:9443/maximo/ui/login. Use user maxadmin and the password specified during Base Services installation. If no errors are reported, the installation is successful. Note: Do not continue until all problems or discrepancies have been resolved. Important: You can perform a full system backup after every successful installation step. The absolute minimum that should be backed up is the base services home directory (at least 9 GB of free space required), as described in Tivoli Provisioning Manager documentation (Installing the base services section). Proceed to Installing the Tivoli Provisioning Manager core components
Installing the Tivoli Provisioning Manager core components

Use the Tivoli Service Automation Manager installation launchpad to install the Tivoli Provisioning Manager core components.
Before you begin

Make sure that the middleware and base services are started as described in Starting the management server on page 289. Server: Management server This procedure must be run on the provisioning server of the management system.
Procedure
1. On the provisioning server of the management system, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > Tivoli Provisioning Manager > Install the Tivoli Provisioning Manager core components. 3. Click the link to verify the core components installation prerequisites. When this has been done, check the box and return. 4. Click the link to install the core components. 5. The core component installer launches. Refer to the Provisioning Manager documentation for detailed instructions. Note: v Ensure that you select the option to install Tivoli Provisioning Manager for OS Deployment. v When installing Tivoli Provisioning Manager for OS Deployment, the host name of the target system must be written in lower case. Otherwise, the installation fails.
70
v If you do not want to change the host name or if it is not possible, install Tivoli Provisioning Manager for OS Deployment manually, after the core components are installed. v If errors occur during the installation, you may need to repeat the previous step in the installation process, and then continue. 6. When the core component installation is finished, go back to the Tivoli Service Automation Manager launchpad. 7. Click the link to install Tivoli Provisioning Manager for Images components. 8. Enter the required parameters and click on the link to start the installation script.
What to do next
1. Back up the management-system servers. 2. Proceed to Installing the Tivoli Provisioning Manager web components.
Installing the Tivoli Provisioning Manager web components

Use the Tivoli Service Automation Manager installation launchpad to install the Tivoli Provisioning Manager web components.
Before you begin

Make sure that the middleware and base services are started as described in Starting the management server on page 289. Server: Administrative server This procedure must be run on the same administrative server that was used for the base services installation.
Procedure
1. On the administrative server, start the Tivoli Service Automation Manager installation launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > Tivoli Provisioning Manager > Install the Tivoli Provisioning Manager Web components. 3. Click the link to verify the installation prerequisites. When this has been done, check the box and return. 4. Click the link to install the web components. 5. The Tivoli Provisioning Manager Web Component installer is launched. Refer to the Provisioning Manager documentation for detailed instructions. Follow the instructions in the installer. 6. Wait until the web component installer has finished.
What to do next
1. Perform the post-installation steps for Tivoli Provisioning Manager: a. In the launchpad, go to Product Installation > Tivoli Provisioning Manager > Post-installation tasks for Tivoli Provisioning Manager. b. Click Perform the Tivoli Provisioning Manager post-installation tasks. c. Follow the steps described in the panel displayed.
71
2. On completion, log on to the administrative user interface to ensure that it is operational. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface. Note: Do not continue until all problems or discrepancies have been resolved. Important: It is recommended that you perform a full system backup (management server and administrative server) after the installation is finished. Depending on the installation scenario you are following: v If Tivoli Service Request Manager was not previously installed, proceed to Installing Tivoli Service Request Manager (step 1 of 2). v If Tivoli Service Request Manager is installed, proceed to the installation of Tivoli Provisioning Manager Fix Pack 1 core components. For more information, see Installing Tivoli Provisioning Manager Fix Pack 1 core components on page 74.
Installing Tivoli Service Request Manager (step 1 of 2)

Service Request Manager 7.2 is installed from the Service Request Manager DVD. The file for Fix Pack 1 is provided on Fix Central at http://www.ibm.com/ support/fixcentral/.
Before you begin

Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server This procedure must be run on the same administrative server used for the base services installation.
Procedure
1. Install Tivoli Service Request Manager V7.2: a. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25 b. Select Product Installation > Tivoli Service Request Manager (part 1 of 2). c. Click the link to verify the Service Request Manager installation prerequisites. When finished, check the box and return to the Launchpad. d. Click the link to install the Tivoli Service Request Manager applications. See the product documentation for details. Note: In the Tivoli Service Automation Manager environment, the WebSphere RXA user ID is tioadmin. e. When prompted for features selection, select all boxes under Service Request Manager 7.2. However, the check boxes to any wanted language support features are optional.
72
Important: When you select a root check box, you do not automatically select its children. f. On completion, log on to the administrative user interface to ensure that it is operational. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface. Note: Back up the administrative and the management servers so that you can preserve the system environment for fix pack installation. 2. Install the Tivoli Service Request Manager fix pack: a. If you performed a backup and rebooted your systems, make sure that you started the middleware as described in Starting and stopping the middleware on page 289. b. As the root user, stop the WebSphere MXServer process on the management server:
<was_home_dir>/bin/stopServer.sh MXServer -username <wasadmin_user> -password <wasadmin_password>
where by default: v <was_home_dir> is /opt/IBM/WebSphere/AppServer/ v <wasadmin_user> is wasadmin c. After unpacking the installation programs from the Tivoli Service Request Manager fix pack, make sure that the programs have executed permissions. d. Review the readme file for Service Request Manager V7.2 Fix Pack 1. e. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. f. Select Product Installation > Tivoli Service Request Manager. g. Click the link to install Tivoli Service Request Manager Fix Pack. h. Follow the instructions in the installer. Important: In some rare situations, you might receive the following message:
CTGIN2252W: Cannot connect to base services web application
This warning can reflect a real problem or a timing problem. To rule out an actual error, log on to the administrative user interface when the installation program finishes. If you are able to log on, the message can be ignored. If it is unsuccessful, closer investigation is needed. If you are installing a language other than English, and the fix pack installer reports that it is unable to log on to the administrative user interface, perform the workaround procedure described in Unable to log on to the administrative user interface after Tivoli Provisioning Manager installation on page 420. 3. Install the Service Request Manager Limited Availability Fix following the instructions in the installer.
What to do next
Important: Perform a full system backup (management server and administrative server) after the installation is finished.
73
1. Log on to the administrative user interface to ensure that it is operational. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface. 2. Proceed to Installing Tivoli Provisioning Manager Fix Pack 1 core components.
Installing Tivoli Provisioning Manager Fix Pack 1 core components

Download the required Tivoli Provisioning Manager fix pack packages and install the core components using the Tivoli Service Automation Manager launchpad.
Before you begin

v Make sure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 1 files from Fix Central at http://www.ibm.com/support/fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Management server
Procedure
1. On the launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 1. 2. Click the link to install Tivoli Provisioning Manager Fix Pack 1 components. 3. Enter the required parameters and click the link to start the installation script.
What to do next
Proceed to Installing Tivoli Provisioning Manager Fix Pack 1 Web components.
Installing Tivoli Provisioning Manager Fix Pack 1 Web components

Learn how to install the Tivoli Provisioning Manager fix pack Web components using the launchpad.
Before you begin

v Make sure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 1 files from Fix Central at http://www.ibm.com/support/fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server
Procedure
1. On the launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 1.
74
2. Click the link to install the Web components and follow the instructions in the installer.
What to do next
1. Perform the post-installation steps for Tivoli Provisioning Manager: a. On the launchpad, go to Product Installation > Tivoli Provisioning Manager Fix Pack 1 > Post-installation tasks for Tivoli Provisioning Manager Fix Pack 7.2.0.1. b. Click Perform the Tivoli Provisioning Manager fix pack post-installation tasks. c. Follow the steps described in the panel displayed. 2. Proceed to Installing Base Services Fix Pack. Important: Perform a full system backup of both the management and administrative servers after the installation is finished.
Installing Base Services Fix Pack

Learn how to install the Base Services Fix Pack using the launchpad.
Before you begin

1. The AIX level is not automatically detected when using Firefox 3.5. Ensure you are using a supported level on your administrative server. 2. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> 3. When the middleware is active, as the root user, stop the WebSphere MXServer process again. To achieve this, on the management server enter:
<was_home_dir>/bin/stopServer.sh MXServer -username <wasadmin_user> -password <wasadmin_password>
where by default: v <was_home_dir> is /opt/IBM/WebSphere/AppServer/ v <wasadmin_user> is wasadmin 4. Clear the browser cache. Server: Administrative server
Procedure
1. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25 2. Navigate to Product Installation > Base Services Fix Pack > Base Services Fix Pack 7.1.1.8. 3. Verify the prerequisites and mark the check box. 4. Click the link Upgrade base services components and follow the instructions in the installer. 5. Click the link Install base services Limited Availability fix and follow the instructions in the installer. 6. Run the script to perform miscellaneous installation actions.
75
7. On completion, log on to the administrative user interface to ensure that it is operational. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface.
What to do next
Important: It is recommended that you perform a full system backup (management server and administrative server) after the upgrade completes. Proceed to Installing Tivoli Service Request Manager (step 2 of 2).
Installing Tivoli Service Request Manager (step 2 of 2)

Perform this procedure after installing the Base Services Fix Pack.
Before you begin

Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server This procedure must be run on the same administrative server used for the base services installation.
Procedure
1. From the installation launchpad, select Product Installation > Tivoli Service Request Manager (2/2). 2. From the Launchpad, click Install Common Process Components for Service Providers and follow the instructions in the installer. Note: To improve installation time, in the package options panel, you can check the Defer Application Redeployment and the Defer Update of the Maximo Database boxes. 3. From the Launchpad, click Install Service Provider Enablement Components and follow the instructions in the installer. Note: To improve installation time, in the package options panel, you can check the Defer Application Redeployment and the Defer Update of the Maximo Database boxes. 4. From the Launchpad, click Install Advanced Workflow Components and follow the instructions in the installer. Note: Make sure that the Defer Application Redeployment and the Defer Update of the Maximo Database boxes remain unchecked for this step.
What to do next
Important: Perform a full system backup of both the management and the administrative servers after the installation is finished.
76
Proceed to the installation of Tivoli Provisioning Manager Fix Pack 2 (see Installing Tivoli Provisioning Manager Fix Pack 2 core components).
Installing Tivoli Provisioning Manager Fix Pack 2 core components

Download the required Tivoli Provisioning Manager fix pack packages and install the core components using the Tivoli Service Automation Manager launchpad.
Before you begin

v Ensure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 2 files from Fix Central at http://www.ibm.com/support/fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Management server
Procedure
1. On the Launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 2. 2. Click the link to install Tivoli Provisioning Manager Fix Pack 2 components. 3. Enter the required parameters and click the link to start the installation script.
What to do next
Proceed to Installing Tivoli Provisioning Manager Fix Pack 2 Web components.
Installing Tivoli Provisioning Manager Fix Pack 2 Web components

Install the Tivoli Provisioning Manager Fix Pack 2 Web components using the launchpad.
Before you begin

v Make sure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 2 files from Fix Central at http://www.ibm.com/support/fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server
Procedure
1. On the Launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 2. 2. Click the link to install the Web components and follow the instructions in the installer.
77
What to do next
1. Perform the post-installation steps for Tivoli Provisioning Manager: a. On the launchpad, go to Product Installation > Tivoli Provisioning Manager Fix Pack 2 > Post-installation tasks for Tivoli Provisioning Manager Fix Pack 7.2.0.2. b. Click Perform the Tivoli Provisioning Manager fix pack post-installation tasks. c. Follow the steps described in the panel displayed. Important: Perform a full system backup of both the management and the administrative servers after the installation is finished. 2. Proceed to Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components.
Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 core components
Download the required Tivoli Provisioning Manager interim fix packages and install the core components using the Tivoli Service Automation Manager launchpad.
Before you begin

v Make sure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 2 Interim Fix 1 files from Fix Central at http://www.ibm.com/support/ fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Management server
Procedure
1. On the launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 2 iFix 1. 2. Click the link to install Tivoli Provisioning Manager Fix Pack 1 iFix1 components. 3. Enter the required parameters and click the link to start the installation script.
What to do next
Proceed to Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 Web components on page 79.
78
Installing Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 Web components
Install the Tivoli Provisioning Manager Fix Pack 2 Web components using the Tivoli Service Automation Manager launchpad.
Before you begin

v Ensure that you downloaded Tivoli Provisioning Manager 7.2 Fix Pack 2 interim fix 1 files from Fix Central at http://www.ibm.com/support/fixcentral/. v Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server
Procedure
1. On the launchpad, select Product Installation > Tivoli Provisioning Manager Fix Pack 2 iFix 1. 2. Click the link to install the Web components and follow the instructions in the installer.
What to do next
1. Perform the post-installation steps for Tivoli Provisioning Manager: a. On the launchpad, go to Product Installation > Tivoli Provisioning Manager Fix Pack 2 iFix1 > Post-installation tasks for Tivoli Provisioning Manager Fix Pack 7.2.0.2 iFix1. b. Click Perform the Tivoli Provisioning Manager fix pack post-installation tasks. c. Follow the steps described in the panel displayed. Important: Perform a full system backup of both the management and the administrative servers after the upgrade completes. Proceed to Installing the Tivoli Service Automation Manager applications.
Installing the Tivoli Service Automation Manager applications

This section describes how to install the Tivoli Service Automation Manager base component.
Before you begin

1. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Administrative server This procedure must be run on the same administrative server that was used for the base services installation.
79
Procedure
1. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > Tivoli Service Automation Manager > Install the Tivoli Service Automation Manager applications. 3. Click Verify the Tivoli Service Automation Manager installation prerequisites. When the prerequisites are verified, check the box and return. 4. Click Modify Tivoli's process automation engine REST deployment descriptor, follow the steps in the launchpad, and mark the check box. 5. Click Install Tivoli Service Automation Manager applications to install the applications and follow the instructions in the installer. Ensure that there are no errors during the installation process. If you started the launchpad from the location where you unpacked the product package or from Tivoli Service Automation Manager DVD, the location of the application package is found automatically. In case the package is not found automatically, specify the location of the Tivoli Service Automation Manager DVD or where you unpacked the product package. 6. Click Install Tivoli Service Automation Manager enablement keys to install the enablement keys and follow the instructions provided. Ensure that there are no errors during the installation process. 7. On completion, log on to the administrative user interface to ensure that it is operational. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface. Note: If you want to install the optional Tivoli Service Automation Manager for WebSphere Application Server component, you can do so in a separate procedure either immediately following the Tivoli Service Automation Manager Base installation or at a later time.
What to do next
Important: It is recommended that you perform a full system backup (management server and administrative server) after the upgrade completes. Proceed with Installing additional configuration files.
Installing additional configuration files

This segment extracts the Cloud Management Subsystem configuration files onto the management server in the /etc/cloud directory.
Before you begin

Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> Server: Management server
80
Procedure
1. On the management server, invoke the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > Tivoli Service Automation Manager > Install additional configuration files. 3. Click the link to install the additional configuration files. 4. Enter the required parameters and click on the link to start the installation script.
What to do next
In a multiserver topology, it is advisable to copy the /etc/cloud directory to each additional server in the management system or to run and perform this Launchpad step on each server. There are setup steps that require selected files to be accessible on the database or directory servers. Proceed with Installing the automation packages for Tivoli Service Automation Manager.
Installing the automation packages for Tivoli Service Automation Manager

You can use the installation launchpad to install automation packages for Tivoli Service Automation Manager.
Before you begin

1. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> 2. Make sure that the following services are running: v On AIX
/etc/rc.d/init.d/dbgw start /etc/rc.d/init.d/rembo start /etc/rc.d/init.d/rbagent start
v On Linux:
/etc/init.d/dbgw start /etc/init.d/rembo start /etc/init.d/rbagent start
Server: Provisioning server of the management system (Tivoli Service Automation Manager management server)
Procedure
1. On the Tivoli Service Automation Manager management server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 2. Navigate to Product Installation > Tivoli Service Automation Manager > Install the automation packages for Tivoli Service Automation Manager.
81
3. Click the link to install the automation packages. Note: Do not continue with subsequent installation or post-installation steps until all problems or discrepancies have been resolved.
What to do next
Important: It is recommended that you perform a full system backup (management server and administrative server) after the upgrade completes. Proceed either with Installing optional software or with Post-installation steps on page 83.
Installing optional software

You can install Tivoli Service Automation Manager for WebSphere Application Server as an optional, separately paid service provided for Tivoli Service Automation Manager. Note: Run this step after Tivoli Service Automation Manager Base has been installed (either immediately or at a later time).
Before you begin

1. Clear the browser cache. 2. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password>
Procedure
1. On the administrative server, start the Tivoli Service Automation Manager Installation Launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25 2. Navigate to Optional Software > Install Tivoli Service Automation Manager for WebSphere Application Server 3. Click the link to install Tivoli Service Automation Manager for WebSphere Application Server. Refer to the Tivoli Provisioning Manager installation documentation for details. Note: Do not continue until all problems or discrepancies have been resolved.
What to do next
Perform the Post-installation steps on page 83 if you have not done it before. Configure the component (see Configuring the managed environment to use the WebSphere Cluster Service on page 211).
82
Post-installation steps
Perform the post-installation steps in the installation launchpad to integrate Tivoli Service Automation Manager and its interfaces with other solution components.
Before you begin

1. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password> 2. Make sure that the following services are running: v On AIX
/etc/rc.d/init.d/dbgw start /etc/rc.d/init.d/rembo start /etc/rc.d/init.d/rbagent start
v On Linux:
/etc/init.d/dbgw start /etc/init.d/rembo start /etc/init.d/rbagent start
Procedure
1. On the launchpad, select Post-Installations Steps > Specify Installation Parameters Required for Component Integration. On this page, you enter all necessary input parameters that are needed throughout the rest of the post-installation. These parameters are used as input for various scripts that are started in the background. Also, an automated validation capability is available that verifies most user IDs and passwords that are entered. Important: Due to technical limitations, not all IDs and passwords can be validated. You must verify the maxadmin ID and password manually, and ensure that exactly this password is entered in the launchpad. Verify the parameters and mark the check box. 2. Click Configure Tivoli Process Automation Engine Global Properties. A script is run to update some global properties in the Maximo database and set some properties for the endpoints PMRDPRBC and PMZHBWSCR. Mark the check box if the script returns no errors. 3. Click Set up Tivoli Service Request Manager. Perform a set of manual steps to set up Service Request Manager. See the details in the launchpad, and at:http://publib.boulder.ibm.com/infocenter/ tivihelp/v32r1/topic/com.ibm.srm.doc/install/install/ c_ccmdb_initialdataconfiguration.html. Verify the parameters and mark the check box. Note: The default insert site defines the site a service request is for. A user can create a service request for a site they cannot access. If the default insert site is changed for a user, the site authorization list in the following security groups must be updated: PMRDPCA, PMRDPCM, PMRDPTA, PMRDPTU. 4. Click Configure the Cloud Management Components.
83
A script is run to perform a set of activities. See the more detailed list in the launchpad. Verify the parameters and mark the check box. 5. Click Set up the Self-Service Environment. Perform the manual steps to complete this task as described on the launchpad.
What to do next
When finished, verify the integrated solution by performing connectivity tests between the various components. For more information, see Verifying the integrated installation. Perform additional steps to configure IBM HTTP server.
Verifying the integrated installation

You can verify the integrated installation by performing simple connectivity tests to the WebSphere Application Server console, Tivoli Service Automation Manager administrative and self-service user interfaces, and the Tivoli Provisioning Manager user interface.
Before you begin

Make sure all middleware including the Tivoli Provisioning Manager deployment engine is started as described in Starting and stopping the middleware on page 289.
Procedure
1. Log on to the WebSphere Application Server console for the MXServer. a. Start the browser:
https://<management_server_hostname>:9043/admin
b. Log on as wasadmin and enter the password. c. Log out and close the browser. 2. Log on to the administrative user interface as maxadmin. a. Start the browser:
https://<management_server_hostname>:9443/maximo
b. Log on as maxadmin and enter the password. Use the password that you set during the installation. c. Log out and close the browser. 3. Log on to the administrative user interface as PMSCADMUSR. Use this user to modify the service offerings or catalogs in Tivoli Service Request Manager. a. Start the browser:
b. Log in as PMSCADMUSR and enter the password that you set during the Base Services installation. Use the default password maxadmin unless you have changed it after the installation. c. Log out and close the browser.
84
4. Log on to the self-service user interface as PMRDPCAUSR. This user ID is assigned the Tivoli Service Automation Manager Cloud Administrator role, and is created automatically during product installation. Log on to the self-service user interface for this time with this user. a. Start the browser:
https://<management_server_hostname>:9443/SimpleSRM/
b. Log on as PMRDPCAUSR and enter the password. The password set during installation is maxadmin. c. Log out and close the browser.
Configuring IBM HTTP Server

Configure the IBM HTTP Server after installing Tivoli Service Automation Manager and its components.
Configure the web server to handle HTTP requests

Procedure
1. Specify port 80 for maximo_host: a. Log on to the WebSphere Application Server administrative console (https://<server>:9043/ibm/console). b. Click Environment > Virtual Hosts. c. Select maximo_host. d. Under Additional Properties, click Host Aliases. e. Verify that port 80 is shown in the list. If not, add it. 2. Edit httpd.conf: a. In the WebSphere administrative console, click Servers > Web servers. b. Click webserver1 in the list and click Edit to edit httpd.conf. c. If it is not done already, uncomment (or add, if missing) the following lines at the end of the file:
LoadModule was_ap20_module /opt/IBM/HTTPServer/Plugins/bin/32bits/mod_was_ap20_http.so WebSpherePluginConfig /opt/IBM/HTTPServer/Plugins/config/webserver1/plugin-cfg.xml
d. Click OK to save httpd.conf. 3. Generate the plug-in configuration: a. In the WebSphere administrative console, click Servers > Web servers. b. Mark the check box next to webserver1 and then select Generate Plug-in. c. Mark the check box next to webserver1 again and then select Propagate Plug-in. 4. Restart WebSphere Application Server: a. Open the command window. b. Run the following as user tioadmin:
$TIO_HOME/tools/tio.sh stop <wasadmin> <password> $TIO_HOME/tools/tio.sh start <wasadmin> <password>
5. Restart the HTTP server: a. Open the command window. b. Run the following commands as user root:
/opt/IBM/HTTPServer/bin/apachectl stop /opt/IBM/HTTPServer/bin/apachectl start
85
6. Log on to the administrative user interface to ensure that it is operational. Use the address http://<server>/maximo to access the interface through the HTTP server. For more details, see Logging on to the Tivoli Service Automation Manager administrative interface.
Configure the web server to handle HTTPS requests

Procedure
1. Enable SSL for the web server: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console/), click Servers > Web Servers. b. Click webserver1 and select Web Server Virtual Hosts. Click New in the window that opens. c. In the window, select Security enabled virtual host and click Next. d. Enter the following parameters: v webserver1 as Key store file name v $(WEB_INSTALL_ROOT)/conf as the Target key store directory v WebAS as Key store password v selfSigned as Certificate alias e. Click Next. f. Enter the following parameters: v * as IP Address v 443 as the Port Note: Make sure that port 443 is available on your system. If not, use 444 or any other available port for this step and for all subsequent steps. g. Click Next and then click Finish. h. Click Save. 2. Export the AppServer public certificate for later import into the WebSphere Key Store: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console/), click Security > SSL certificate and key management. b. Under Configuration settings, click Manage endpoint security configurations. c. Under Outbound, expand ctgCell01 > nodes > ctgNode01 > servers and click MXServer. d. Click Key stores and certificates. e. Click TpmKeyStore. f. Click Personal Certificates. g. Mark the check mark for tpmuicert and click Extract. h. Enter a certificate file name, for example /tmp/key.cert and click OK. 3. Correct the settings in the plugin-cfg.xml file to support SSL: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console/), click Servers > Web Servers. b. Click webserver1 and select Plug-in properties. c. In the section Repository copy of Web server plug-in files, change the filename for plug-in key store file name to webserver1.kdb.
86
d. In the section Web server copy of Web server plug-in files, change the filename for plug-in key store directory and file name to /opt/IBM/HTTPServer/conf/webserver1.kdb. e. Click OK. f. Click Save. 4. Import the Appserver certificate: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console/), click Servers > Web Servers. b. Click webserver1 and select Plug-in properties. c. In the section Repository copy of Web server plug-in files, click Manage keys and certificates. d. Click Signer Certificates. e. Click Add. f. Enter TSAM for Alias. g. Enter the file name of the previously exported AppServerCertificate, for example /tmp/key.cert. h. Click OK. i. Click Save. 5. Define the SSL port for maximo_host: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console), click Environment > Virtual Hosts. b. Click maximo_host. c. Under Additional Properties, click Host Aliases. d. Verify that the port that you want to use (for example 443) is displayed in the list. If not, add it. 6. Generate the plug-in configuration: a. In the WebSphere administrative console (https://<server>:9043/ibm/ console), click Servers > Web Servers. b. Mark the check box next to webserver1 and then select Generate Plug-in. c. Mark the check box next to webserver1 again and then select Propagate Plug-in. 7. Restart WebSphere Application Server: a. Open the command window. b. Run the following commands as user tioadmin:
$TIO_HOME/tools/tio.sh stop <wasadmin> <password> $TIO_HOME/tools/tio.sh start <wasadmin> <password>
8. Restart the HTTP Server: a. Open the command window. b. Run the following commands as user root:
/opt/IBM/HTTPServer/bin/apachectl stop /opt/IBM/HTTPServer/bin/apachectl start
9. Verify the configuration by going to https://<server>/SimpleSRM/. Note: If you specified a different port than the default SSL port 443, make sure to include this port number in the URL. In case you receive the error message Error 403: AuthorizationFailed, clear all cookies and try again.
87
Optional system settings after installation

Learn about the additional settings that you can optionally modify in your environment.
Disabling Tivoli Provisioning Manager Software Distribution Infrastructure

About this task
During Tivoli Provisioning Manager installation, Software Distribution Infrastructure is also installed and enabled. This component is not required for Tivoli Service Automation Manager, and you can disable it to avoid loading its server-side code for performance reasons.
Procedure
1. Edit the TPM.javaopt file: v Windows: C:\Program Files\IBM\tivoli\tpm\lwi\conf\overrides v UNIX: /opt/IBM/tivoli/tpm/lwi/conf/overrides 2. At the end of the file, add the line:
-DSdiTaskInfrastructure.disabled=true
3. Save the file.
Uninstalling
Uninstalling Tivoli Service Automation Manager requires you to remove its components in a sequential manner: external, core, base services, and middleware.
About this task

Important: Do not use any other uninstall methods, such as the Add/Remove Programs panel in Windows.
Uninstalling Tivoli Service Automation Manager components

Remove all solution components that are independent of the Tivoli Process Automation engine.
Before you begin

You must have the following operating system privileges: v v
Windows UNIX
Administrator
Linux
root
Procedure
1. Remove the license installer on both the admin workstation and on the management server: v v
Windows Go to %APPDATA%\IBM\tsam and run Uninstall_IBM_Tivoli_Service_Automation_Manager_License.exe UNIX Linux
Go to /opt/IBM/tsam/ and run Uninstall_IBM_Tivoli_Service_Automation_Manager_License 2. Remove the directories where Service Automation Manager was installed.
88
Windows
%APPDATA%\IBM\tsam and %PROGRAMFILES%\IBM\tsam
UNIX Linux /opt/IBM/tsam v a. Log on to the administrative workstation:
Windows
as Administrator
UNIX Linux as root v b. Remove the directory:
Windows
%APPDATA%\IBM\tsam and %PROGRAMFILES%\IBM\tsam
UNIX Linux /opt/IBM/tsam v c. Log on to the management server as root. d. Remove the directory /opt/IBM/tsam and /etc/cloud
What to do next
Proceed to Uninstalling Tivoli Provisioning Manager core components
Uninstalling Tivoli Provisioning Manager core components

If you no longer require it for other software solutions, uninstall Tivoli Provisioning Manager core components and perform cleanup tasks.
Procedure
1. Uninstall Provisioning Manager core components. 2. Remove items remaining after uninstallation.
What to do next
Proceed to Uninstalling base services other runtime services.
Uninstalling base services other runtime services.

Remove base services, Tivoli Service Request Manager, Tivoli Provisioning Manager Web components, and the Tivoli Service Automation Manager Process Manager package.
Before you begin

Important: Do not perform this task if you plan to continue using any of the services it removes. You must have the following operating system privileges: v v
Windows UNIX
Administrator
Linux
root
Procedure
1. Log on to the administrative workstation. 2. Run a command to uninstall the base services: v
Windows
<Maximo_HOME>\_uninstall\uninstall.exe
Note: The default location for Maximo_HOME is c:\ibm\SMP v

UNIX Linux
<Maximo_HOME>/_uninstall/uninstall
89
3. Remove the Maximo_HOME directory.
What to do next
Proceed to Uninstalling middleware.
Uninstalling middleware
Remove remaining middleware to complete the uninstall of Tivoli Service Automation Manager.
Before you begin

Important: Do not perform this task if any other products installed in your infrastructure use the middleware or its parts. You must have the following operating system privileges: v v
Windows UNIX
Administrator
Linux
root
Procedure
1. Log on to the administrative workstation. 2. Start the Tivoli Service Automation Manager launchpad. 3. In the launchpad navigation pane, select Product Installation / Foundation Software. 4. Click Install the Middleware to start the middleware installer. 5. 6. 7. 8. Select a language for the installation and click OK. From the Welcome panel, click Next. Accept the license agreement and click Next. From the Choose Workspace panel, specify the workspace directory containing the currently deployed plan, and then click Next. The default location for the workspace will be the last workspace location specified. By default: v
Windows
c:\ibm\tivoli\mwi\workspaces
9. 10. 11. 12.
UNIX Linux /ibm/tivoli/mwi/workspace v From the Select Operation panel, select Undeploy the plan, and then click Next. From the Undeployment Preview panel, click Next to undeploy the plan. From the Successful Undeployment panel, click Cancel to exit the middleware installer. Reboot the system.
90
Chapter 3. Upgrading
You can upgrade IBM Tivoli Service Automation Manager from version 7.2.1.4 to 7.2.2.
Important: For information about upgrading to 7.2.1.4, refer to the readme file provided with the fix pack.
Upgrade scenario
Use the following scenario as a guide when you upgrade form version 7.2.1.4.
Preparing for upgrade

Before you start upgrading, you need to prepare your local environment. 1. Prepare instance data for upgrade. 2. Deactivate CSR file generation. 3. Update configuration changes in the database
Upgrade tasks
1. Upgrade your basic product components using the Tivoli Service Automation Manager Installation Launchpad. Only some steps in the Launchpad are required. 2. Upgrade the existing service definitions. 3. Upgrade the existing service deployment instances. 4. Upgrade to the new security model - service provider. 5. Upgrade network. 6. Upgrade storage. 7. Upgrade future projects.
Completing the upgrade

There are some additional steps that might be necessary after you finish upgrading. 1. Update the CSR records. 2. Reactivate CSR file escalation. 3. Reactivate the view to show projects and provisioned servers. 4. Reactivate the monitoring agent installation.
91
Upgrade source files

Source files for Tivoli Provisioning Manager, Service Request Manager, and Service Automation Manager are required to perform the upgrade.
Table 16. Upgrade Source Files File Tivoli Service Automation Manager 7.2.2 Details Tivoli Service Automation Manager 7.2.2 product package is required to install the Tivoli Service Automation Manager applications and automation packages. The package is available on the product CD or DVD or can be downloaded from Passport Advantage at http://www.ibm.com/ software/howtobuy/passportadvantage/ pao_customers.htm. It also contains: v Source packages to upgrade base services to version 7.1.1.8 v A Limited Availability fix for 7.1.1.8 v The advanced workflow components Tivoli Service Request Manager for Service Providers The required package is TSRMfSP_V720.tar. It is available on the product CD or DVD or can be downloaded from Passport Advantage at http://www.ibm.com/ software/howtobuy/passportadvantage/ pao_customers.htm. For more information about the packages needed for Tivoli Provisioning Manager 7.2 Fix Pack 2, see Providing the installation source files on page 39. For more information about the packages needed for Tivoli Provisioning Manager 7.2 Fix Pack 2 Interim Fix 1, see Providing the installation source files on page 39
Tivoli Provisioning Manager 7.2 Fix Pack 2
Tivoli Provisioning Manager 7.2 Fix Pack 2 Interim Fix 1
Preparing for upgrade

Perform the steps described before you start upgrading.
Preparing instance data for upgrade

Before you start upgrading, prepare the instance data for upgrade. Ensure that no projects are scheduled during the upgrade timeframe.
Procedure
1. Ensure that no requests are waiting for processing:
Option Self-service user interface Administrative user interface Description No requests are waiting for processing in My Approvals. No service requests are waiting for processing in the Inbox/Assignments.
2. Ensure that no service requests are running in the self-service user interface:
92
Option Self-service user interface
Description 1. From the Home panel on the Projects pod, select Manage Requests.... A list of all requests will appear. 2. Ensure there are no requests in status "New", "Waiting for approval" or "In progress".
Administrative user interface
1. Click Go To > Service Request Manager Catalog > Service Requests 2. Ensure no requests have status "New", "Waiting for approval" or "In progress". If service requests in those statuses exists, check the related work orders by clicking Service Request > Related Records > Related Work Order > Go To > IT Topology Work Orders
Tip: Service requests from a reserved project wait to be run in state "Queued". If you did not remove all reserved projects, a service request in state "Queued" might be from a reserved project. 3. Make sure that no reservations are set to expire during the upgrade time frame. a. Log in to the self-service user interface as PMRDPCAUSR. b. Click Manage Projects. c. Sort projects by end date. d. If a listed project end date is within your upgrade time window, use the modify reservation offering to extend the time.
Deactivating CSR file generation

If you enabled IBM Tivoli Usage and Accounting Manager CSR file generation on your system, deactivate the escalation called PMZHBCRDPMD to generate CSR file data before you start upgrading.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Escalations. 2. Search for the PMZHBCRDPMD escalation and open it. 3. In the Select Action menu, click Activate/Deactivate Escalation.
Results
The CSR file generation is now inactive. It can be activated after the upgrade procedures are finished.
93
Updating configuration changes in the database

Before you begin
v Ensure that the middleware servers are running and that the MXServer application server is shut down. For more information see Starting and stopping the middleware on page 289. v Back up your database as described in Backing up the database on page 293.
Procedure
1. If you changed the IP address, host name, or password for your database server or other servers, you must make the appropriate changes on the administrative server. Note: When you upgrade, the installation program uses the host names and passwords stored in the database and the maximo.properties file. If they do not match your environment, the upgrade fails. Use the instructions in the following technote to make the changes before installing: http://www.ibm.com/support/search.wss?q1=updateserverprops. Additionally, set up the new database host name reported in the CASInstall.DBHostname attribute of the /opt/IBM/AgentManager/install/ AMInstall.properties file that is stored on the Tivoli Service Automation Manager node. 2. Before upgrading, apply configuration changes to the Maximo database. Details can be found in the Service Request Manager 7.2 Installation Guide in topic Applying changes to the database. 3. To confirm that all changes were committed, run the following SQL query against the Maximo database.
SELECT count (*) from maxobjectcfg where changed != N
If any entries are returned with a value of '0' instead of 'N', you will have to go back to step 2 and apply the changes. 4. Determine whether there are any temporary tables left in the Maximo database using the following command:
DB2 SELECT count (*) from sysibm.systables where name like XX% and creator = MAXIMO
5.
If any tables are listed, perform the following steps to drop them: a. Log on to the WebSphere administrative console and stop the MXServer application server. b. Run the following commands on the Administrative system:
cd <base_services_install_dir>\maximo\tools\maximo configdb restorefrombackup dropbackup dropbackup
Important: The dropbackup command is run twice. c. Restart the MXServer application server.
94
Upgrading Tivoli Service Automation Manager components

Use the Installation Launchpad to upgrade Tivoli Service Automation Manager from version 7.2.1.4 to 7.2.2.
Before you begin

Important: You can only upgrade to version 7.2.2 from 7.2.1.4. v Review the Tivoli Service Automation Manager Release Notes to learn about known unsupported scenarios and unresolved restrictions. v Ensure that the middleware servers are running and that the MXServer application server is shut down. For more information see Starting and stopping the middleware on page 289. v Back up your database as described in Backing up the database on page 293.
Procedure
1. The following packages are required for the upgrade: v Tivoli Service Automation Manager DVD or the downloaded product package v Tivoli Provisioning Manager Fix Pack 2 packages v Tivoli Provisioning Manager Fix Pack 2 Interim Fix 1 packages v Service Request Manager for Service Provider product package For details and specific names of the packages, see Providing the installation source files on page 39. Note: It is not necessary to provide the components which are already installed. 2. Start the launchpad as described in Starting the Tivoli Service Automation Manager Installation Launchpad on page 25. 3. Install license, as described in Installing the Tivoli Service Automation Manager license on page 67. 4. Skip the installation of the base services, Tivoli Provisioning Manager and Service Request Manager. 5. Proceed with the step Installing Base Services Fix Pack on page 75. 6. Perform all the remaining steps up to and including the installation of the automation packages. Do not perform the post-installation steps from the launchpad as these steps are for a new installation only. 7. Make sure that the middleware and base services are started as described in Starting the management server on page 289. Make sure that Tivoli Provisioning Manager deployment engine is stopped. In case it is running, use the following command as tioadmin on the management server: $TIO_HOME/tools/tio.sh stop -t <wasadmin> <password>. 8. Run script <temp>/install/postinstall/configureTSAMupgrade.sh, where <temp> is the location of the DVD or the directory where you unpacked the product package. When prompted, enter the WAS administrative user (e.g. wasadmin) and the password.
95
Upgrading existing service definitions

Update the structure and processes of your existing service definitions.
Before you begin

This step is only required if the RDPVS service definition was copied to implement custom changes. Use this task to merge all new management plans into your custom service definition, preserving your changed management plan in your copy.
About this task

You need to perform this task to ensure that each of your cloud projects are upgraded to the latest supported level.
Procedure
1. Log on to the administrative user interface as user maxadmin (https://server:9443/maximo/). 2. Open the Service Update Packages application by clicking Go To > Service Automation > Service Update Packages. 3. In the List tab, select RDPVS Revision 5. 4. Select the Service Definition Deployments tab. 5. Click Deploy on Service Definitions. 6. In the Deploy Service Update Package on Service Definitions box, select the service definitions you want to upgrade with the contents of the Service Update Package. Note: You can select only the service definitions that have Design status. 7. Click Deploy on Service Definitions to start the deployment for the selected service definitions. 8. Click Refresh in the Status History section to update the status of the deployment process. Verify that the status is Applied for each Service Package deployment to ensure the upgrading process succeeded.
What to do next
Proceed to Upgrading service deployment instances.
Upgrading service deployment instances

Update the structure and processes of your existing service instances to ensure each of your cloud projects are upgraded to the latest supported level.
Procedure
1. Log on to the administrative user interface as user maxadmin (https://server:9443/maximo/). 2. Click Go To > Service Automation > Service Update Packages. 3. In the List tab, select RDPVS Revision 5. 4. Select the Service Instance Deployments tab. 5. Click Deploy on Service Deployment Instances. The Deploy Service Update Package on Service Deployment Instances window is displayed.
96
6. Select the service deployment instances that you want to upgrade with the content of the Service Update Package. Note: Only service deployment instances with status 'Operational' or 'Maintenance' can be selected. 7. Click Deploy on Service Deployment Instances to start the deployment for the selected service deployment instances. 8. Click Yes when prompted about the execution of the management plan after deploying the update package. 9. Click the Refresh button in the Toolbar menu. Verify that the status is 'Applied' for each Service Update Package deployment to ensure the upgrading process succeeded.
Upgrading to the new user security model

With the introduction of the service provider functionality, a new security model was introduced in version 7.2.2. You need to upgrade to this new model so that the existing self-service interface users are operational.
About this task

The service provider function introduces a customer object, and new security levels. Even if you are not planning to use the service provider functions, you must create at least one customer. Then you must move the existing users to the appropriate security groups so that they can provision new projects. The fully automated migration tasks help you to move to the new security model.
Upgrading to the customer model

In Tivoli Service Automation Manager version 7.2.2, customer objects are introduced as part of the service provider functionality. Since the service provider functionality is not optional and is enabled by default, the existing data must be upgraded to the new model.
Before you begin

1. Enter the Admin Mode to verify that no other user is working on the system. 2. Back up your database as described in Backing up the database on page 293.
About this task

Even if you are not planning to use the service provider functionality, you must configure at least one customer and you must migrate the existing data to this customer. For this purpose, Tivoli Service Automation Manager 7.2.2 provides a default customer PMRDPCUST of type SP to represent the service provider. Once the main upgrade tasks are finished, you need to migrate the existing objects. The fully automated migration task runs through all existing instances of objects that are introduced as customer objects in version 7.2.2 and assigns these objects to the default customer PMRDPCUST. The following object types are migrated: v v v v v v Cloud Server Pools IL Master Images Software Products Saved Images Projects Users and Teams
97
Procedure
1. In the administrative user interface, click Go To > Service Automation > Configuration > Cloud Customer Administration. Do not select a customer. 2. From the Select Action menu, select Migrate Customer Objects. A dialog is displayed showing progress. 3. Click Start Migration. 4. Refresh to view the details of the process.
Results
The text box shows the customer object types that are upgraded. The number of upgraded objects is depicted in the brackets. A log is written to the default customer PMRDPCUST.
What to do next
If an error occurs during the upgrade task, a message box appears that shows the error message. Select the PMRDPCUST customer and navigate to the Log tab to view the log file. When the error is resolved, you can restart the upgrade task to upgrade the remaining objects.
Upgrading to the new security groups

In Tivoli Service Automation Manager 7.2.2, a new role and security model is introduced, which requires you to upgrade the existing 7.2.1 users. Use the administrative user interface to upgrade users from version 7.2.1 to 7.2.2.
Before you begin

1. Ensure that customer objects were upgraded successfully. 2. Ensure that the Admin Mode is turned on. 3. Back up your database as described in Backing up the database on page 293.
About this task

In version 7.2.2 a new security model is introduced together with the customer level. There are two levels of access to data - cloud level and cloud customer level. Users on customer level can only access data that is assigned to the same customer to which they are assigned. Moreover, new user roles, which are now called security groups, are introduced. The existing users must be migrated to the new security model. The upgrade task runs through all existing roles and assigns the users to the appropriate policy level security groups. The following roles are upgraded: v v v v Cloud Administrator Cloud Team Administrator Cloud Team User Cloud Manager
Procedure
1. In the administrative user interface, click Go To > Service Automation > Configuration > Cloud Customer Administration. Do not select any customer. 2. From the Select Action menu, select Migrate Users. A dialog is displayed showing the details of the migration progress. 3. Click Start Migration.
98
4. Refresh to view the details of the process.
Results
The text box in the dialog shows the roles that are upgraded. The number of upgraded users is depicted in the brackets. A log is written to the default customer PMRDPCUST. The users are assigned to the default customer PMRDPCUST and can access only the data assigned to that customer. Because all data is assigned to the default customer, the user is able to access the same data as before migration.
What to do next
1. If an error occurs during the upgrade task, a message box appears that shows the error message. Select the PMRDPCUST customer and navigate to the Log tab to view the log file. When the error is resolved, you can restart the upgrade task to upgrade the remaining objects. 2. Turn off the Admin Mode.
Upgrading network
Perform the network configuration migration from the 7.2.1.4 model to the 7.2.2 model before activating the PMRDPCUST default customer.
Upgrading the network model

Upgrade your network configuration from previous versions to the one supported by Tivoli Service Automation Manager 7.2.2. Tivoli Service Automation Manager 7.2.2 uses a new network model because it now includes the service provider functionality. Important: Tivoli Service Automation Manager 7.2.2 supports only the multi-NIC network model. Make sure that you have upgraded to the multi-NIC network model before you perform the network upgrade to version 7.2.2.
About this task

The following entities are upgraded during the process: v All projects from the enabled resource pools v Registered and saved images The following entities are created during the process: v Network template Network_Migration_Template v Network configuration instances
Procedure
1. Log on to the administrative user interface as the cloud network administrator. 2. Select Go To > Service Automation > Configuration > Cloud Network Administration. 3. From the Select Action menu, choose Migration from TivSAM 7.2.1. 4. Click OK in the window that opens. 5. Wait for the migration to complete.
99
Note: The time that the process takes depends on the following factors: v The number of active projects and servers of the enabled resource pools v The number of registered and saved images During the upgrade, a WebSphere Application Server log shows the progress and lists any problems. If any problems occur, identify and fix them, and restart the network upgrade process.
Results
If the procedure ends successfully, you can verify that a new network configuration Network_Migration_Template was added to the list of network configuration templates. To do this, enter the Cloud Network Administration application and press Enter in the Name field. A list of all network configuration instances that exist on the system is displayed. It includes the one that was created as a result of the upgrade process.
Activating the default customer after network upgrade

After you upgrade to the new network model , you need to activate the default customer PMRDPCUST.
About this task

During the migration process, a network template is generated with the name Network_Migration_Template. This template is set to the Active status and contains the entire network segments for all the upgraded resource pools. Use this network template during the activation of the default customer PMRDPCUST in the self-service user interface.
Procedure
1. Log on to the self-service user interface as PMRDPCAUSR. 2. In the Home panel, click Request a New Service > Virtual Server Management > Manage Customers > Create Customer. 3. Specify the network template. 4. Click OK to submit the request. 5. Refresh the browser.
Results
After activating the default customer with the Network_Migration_Template network template, the network upgrade process is complete.
Upgrading storage
Upgrade your storage configuration to the one supported by Tivoli Service Automation Manager 7.2.2. The additional storage functionality is only available for the System p hypervisor.
100
Upgrade scenarios for multi-disk support on Power systems

If you are use Power systems, you can upgrade to the multi-disk support. Two upgrade scenarios are available. Tivoli Service Automation Manager version 7.2.2 supports identification of storage area network (SAN) disks using the Physical Volume ID (PVID) only. Identification using the disk serial number is not supported as not all storage vendors support disk serial number. If a disk that is mapped to a virtual input/output server (VIOS) has no PVID, the PVID is generated during storage discovery. In new resource pools, the PMRDP.Systemp.disks.PVID property is obsolete and it is always assumed to be true. You upgrade from a single disk (boot disk) to multiple disk support in one of two ways, depending on the current state of the Tivoli Service Automation Manager environment. The following tables provide more details about each of these scenarios. 1. Scenario 1: Existing resource pools identify disks using disk serial number. The value for the PMRDP.Systemp.disks.PVID property is set to false.
Tivoli Service Automation Manager environment Existing Projects = N Future Projects = N Existing projects = Y Future Projects = Y / N Upgrade mechanism Run multi-disk storage discovery. 1. Run the migration workflow pSeries_CloudStorage_MigrateSNToPVID.wkf. Note: The input for this workflow is the DCM ID of the resource pool which is to be migrated. This workflow changes the identifier from disk serial number to PVID for all the storage volumes in the associated storage pool. It also updates the reference to PVID in VST associated with virtual servers in this resource pool. At an allocated LPAR, the hardware allocation property key vio.diskSN.vtscsi is also changed to vio.diskPVID.vtscsi. 2. Run the multi-disk storage discovery.
2. Scenario 2: Existing resource pools identify disks using PVID. The value for the PMRDP.Systemp.disks.PVID property is set to true.
Tivoli Service Automation Manager environment Existing Projects = Y/ N Future Projects = N Upgrade mechanism Run multi-disk storage discovery.
101
Tivoli Service Automation Manager environment Existing Projects = Y/ N Future Projects = Y
Upgrade mechanism Run the multi-disk storage discovery. Note: In this process, depending on the size range specified in multi-disk storage discovery for boot and data disks, some of the disks might be moved from a preexisting boot disk pool to a data disk pool. If there are not enough disks in the boot disk pool, some of the future provisioning requests that are already approved might fail.
Multi-disk storage discovery for POWER systems

Take these points into consideration when you run the discovery. v The process discovers all the LUNs attached to the VIO server and it inserts them into or removes them from the Tivoli Provisioning Manager storage pool based on the size range specified for each boot disk pool and data disk pool. v The discovery can be run multiple times. Use the same size ranges every time for the discovery. If a different range is specified, then the disks might be moved from a boot disk pool to a data disk pool or the other way around. v If the boot disk pool does not contain enough disks, some provisioning requests that have already been approved might fail. v Disks that are in the IN_USE state are kept in the pool even if they are outside the size range specified during the rediscovery.
Upgrading future projects

Perform this task if you have project drafts within Tivoli Service Automation Manager 7.2.1 that are scheduled for a future time, but you want them to run within version 7.2.2. After you complete the required tasks within the self-service user interface, all the future projects are canceled and created again. The settings for the upgraded projects do not change and they are run within Tivoli Service Automation Manager 7.2.2. as planned.
Procedure
1. Enable the Upgrade Future Projects request for your self-service user interface: a. Log on to the administrative user interface as PMSCADMUSR user. b. Click Go To > Service Request Manager Catalog > Offerings. c. Select the PMRDP_0351A_72 offering and change the status to ACTIVE. 2. Upgrade future projects: a. Log on to the self-service user interface as PMRDPCAUSR user. b. In the Home panel, click Request a New Service > Virtual Server Management > Administration > Upgrade Future Projects. c. Click OK. d. Wait until the status of your request changes to Resolved. Note: v If the status of any of your upgrading requests turned to Failed, find a solution and perform the task again. All the future projects, including projects that are already upgraded, are canceled and created again. Repeat this task until all the project drafts are upgraded successfully.
102
v If you upgrade a future project that has more than one servers reserved for the Create Project service request, in version 7.2.2 you get: A new service request for creating a project with one server Service requests for adding a new server for each additional server from the original future project A service request for canceling the project 3. Disable the Upgrade Future Projects request within the self-service user interface: a. Log on to the administrative user interface as maxadmin user. b. Click Go To > Service Request Manager Catalog > Offerings. c. Select the PMRDP_0351A_72 offering and change the status to PENDING. The Upgrade Future Projects offering is no longer displayed in the self-service user interface. To make the offering available again, change the status to ACTIVE.
Completing the upgrade

You might need to perform additional tasks after upgrading your environment to a new version.
Updating the CSR records

If you are using the Usage and Accounting functionality, after upgrading to Tivoli Service Automation Manager Version 7.2.2, you need to update the Chargeback_Department identifier for CSR file generation.
About this task

In version 7.2.2, the Chargeback_Department identifier is replaced with Account_Code, which consists of the following values: v <CUSTOMER> - 12 characters - unique customer short name v <PROJECTACCOUNT> - 20 characters - the project account value that is specified in the Create Team and Modify Team requests v <PERSONGROUP> - 8 characters - unique team identifier You can either update the Tivoli Usage and Accounting Manager job files manually to reflect this change, or you can use the compatibility mode system property: pmrdp.team.projectaccount.compatibilitymode, as described in the following procedure.
Procedure
1. In the administrative user interface, click Go To > System Configuration > Platform Configuration > System Properties. 2. Filter for pmrdp.team.projectaccount.compatibilitymode and click its details. 3. Change the Global Value from N to Y. Save. 4. Click 5. Mark the check box to the left of the property name. 6. Click Live Refresh and then OK. to view
103
Results
The Chargeback_Department identifier in CSR records is replaced with Account_Code, but its value consists of <PROJECTACCOUNT> only. The <CUSTOMER> and <PERSONGROUP> values are not provided in the Account_Code identifier.
Activating CSR file generation

If you enabled Tivoli Usage and Accounting Manager CSR file generation on your system, activate the escalation after the upgrade tasks are completed.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Escalations. 2. Search for the PMZHBCRDPMD escalation and open it. 3. If the escalation is inactive, in the Select Action menu, click Activate/Deactivate Escalation.
Results
The CSR file generation is now active.
Reactivating the view to show projects and provisioned servers

If you implemented application logic that still requires the PMRDPSIVIEW view for compatibility reasons, you can perform this optional procedure to reactivate it.
Before you begin

Ensure that Tivoli Service Automation Manager is stopped. To stop it, run the following command on your management server as user tioadmin:
$TIO_HOME/tools/tio.sh stop
About this task

In Tivoli Service Automation Manager 7.2.2, the PMRDPSIVIEW view is replaced by views PMRDPPRJVIEW and PMRDPSRVVIEW. If required, you can reactivate the PMRDPSRVVIEW at any point in time.
Procedure
1. On the administrative system, log on as user root (for UNIX) or as an administrative user (for Windows) and open the command window. 2. Change directory to the Maximo home directory: v For UNIX: cd $CTG_MAXIMO_HOME/tools/maximo/internal v For Windows: cd %CTG_MAXIMO_HOME%\tools\maximo\internal 3. Run the following script to import the PMRDPSIVIEW configuration: v For UNIX: ./importObject.sh -input=../en/rdp_pmp/V750_06.content/ RDP_pmrdpsiview_chg.xml v For Windows: .\importObject.bat -input=../en/rdp_pmp/V750_06.content/ RDP_pmrdpsiview_chg.xml 4. Run the following script to import the PMRDPSIVIEW object structure:
104
v For UNIX: ./importObject.sh -input=../en/rdp_pmp/V750_06.content/ NBAPITSAM_maxintobject_change.xml v For Windows: .\importObject.bat -input=../en/rdp_pmp/V750_06.content/ NBAPITSAM_maxintobject_change.xml 5. Run the following script to commit the changes to the database: cd.. v For UNIX: ./configdb.sh v For Windows: .\configdb.bat 6. If the Tivoli Service Automation Manager system has been set up with a base language different from English, run the following command on the administrative server as user root:
/opt/IBM/SMP/maximo/tools/maximo/TDToolkit.sh/.bat -pmpupdaterdp_pmp -VersionV710-000
Results
Successful completion is indicated by the following messages: v BMXAA6820I - ConfigDB completed without errors. v BMXAA6820I - RestoreFromBackup completed without errors.
What to do next
Restart Tivoli Service Automation Manager. Run the following command on your management server as user tioadmin:
$TIO_HOME/tools/tio.sh start
Reactivating the monitoring agent installation

If you enabled the Tivoli Monitoring agent installation on your virtual machines before the upgrade, you need to reactivate this functionality.
About this task

You can 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 v v v v v v PMRDP_0213A_72 PMRDP_0214A_72 PMRDP_0215A_72 PMRDP_0201A_72 PMRDP_0202A_72 PMRDP_0203A_72 PMRDP_0204A_72 (Add Xen Servers) (Add z/VM Linux Servers) (Add KVM Servers) (Create Project with VMware Servers) (Create Project with POWER LPAR Servers) (Create Project with Xen Servers) (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)
105
Procedure
1. 2. 3. 4. 5. 6. Log on to the administrative user interface as PMSCADMUSR. Click Go To > Service Request Manager Catalog > Offerings Click on the offering to open it. Click the Change Status button and change the status of the offering to Pending. Switch to the Specifications tab. In the Presentation section, select the Mandatory check box, and unselect the Hidden check box, which correspond to the offering attribute PMRDPCLSWS_MONITORING. Change the status of this offering to Active. Save your changes.
7. 8.
106
Chapter 4. Configuring Tivoli Service Automation Manager

Depending on the features that you plan to use, some configuration is required after the product is installed.
Overview of the configuration process

After successful installation of Tivoli Service Automation Manager, you must configure it to be able to use it for server provisioning or for storage. Configuration of Tivoli Service Automation Manager involves four main tasks. For each of these tasks, there is a Tivoli Service Automation Manager application that helps you to perform the configuration process.
107
1. Configuration of a cloud server pool for each hypervisor (using the Cloud Server Pool Administration application)
1.1 Discovery of virtual server images for each hypervisor
2. Configuration of cloud storage pools for storage managers (optional)
3. Network configuration (multiple NIC configuration)
4. Service Provider enablement (Creating customers and making them operational)
4.1 Assign resources to customers and create customer templates (using the Cloud Customer Administration application)
5. Register images (using the self-service user interface)
4.2 Create a default customer PMRDPCUST in the self-service user interface
6. Create cloud customer administrator (using the self-service user interface)
4.3 Create additional customers (optional)
7. Manage users and teams (using the self-service user interface)
Legend
Tivoli Service Automation Manager Administrator
8. Create a project (using the self-service user interface)
Cloud Administrator Cloud Customer Administrator and Team Administrator
Figure 1. Tivoli Service Automation Manager configuration overview
Note: You can access all of these applications by logging on to the administrative user interface and clicking Go To > Service Automation > Configuration. It is necessary to define and configure cloud server pools to provision servers on VMware, PowerVM, KVM, VMControl, and z/VM back ends.
108
Planning your configuration
In the following sections you can find information about the supported hypervisor and network configurations.
Planning the hypervisor configuration

This section describes supported configuration scenarios and the key environment configuration aspects that need to be considered when configuring Tivoli Service Automation Manager. Hardware configurations Network configurations v Multi NIC support The multi NIC mode assumes there could be multiple networks connected to the provisioned virtual machine. One could be marked as the management network. One could be marked to be the source of the hostname resolution for the virtual machine. The resource pool defines the number of network interfaces which will be connected to the provisioned virtual machine. For each network defined in the resource pool there is a pool of subnets. Each subnet defines the Layer 3 network configuration including the VLAN ID. In addition it contains a link to a virtual switch template which defines the Layer 2 configuration of the network on the hypervisor layer. The virtual switch template is a hypervisor platform specific configuration of the Layer 2 network configuration and contains all the required parameters to define the connection between the virtual NIC on the virtual machine to the physical NIC on the hypervisor platform. There is one set of DNS configuration which is defined on the resource pool level. The multi NIC networking model supports a set of end user extensibility which allows to customize certain behavior of the out of the box capabilities. Note: The subnetwork configuration and definition in Tivoli Service Automation Manager is common to all hypervisors. All subsequent hypervisor configurations must be configured for the same subnetwork. Storage configurations v Local storage dedicated to a blade server or LPAR hardware and shared among the virtual machines on the blade server. v Globally shared storage through a Storage Area Network (SAN).
Chapter 4. Configuring
109
v Configuration of storage must be done for the virtual machine disks. v Configuration of storage must be done for hosting the images. v Configuration of storage must be done for hosting backup images. v Other general considerations: Virtual machine images might contain only one disk or partition. The single partition and the file system it contains, are resized (made larger) to the size requested for the virtual machines during the provisioning process. For Linux-based guest operating systems, a swap partition is automatically created and configured for the size requested. Software Configurations Guest operating systems v Windows v AIX v Linux for System x v Linux for system z Operating system image template requirements v The OS images need to be created and configured according to specific requirements. Supported hypervisors v VMware v v v v PowerVM Kernel-based Virtual Machine (KVM) Xen z/VM
v Number of hypervisors: Adding additional but similar hypervisors to be managed by Tivoli Service Automation Manager Adding additional but heterogeneous hypervisors to be managed by Tivoli Service Automation Manager. v Number of resource pools per hypervisor. Note: This documentation describes a basic first time configuration for each supported hypervisor. Currently, it does not cover configuring additional hypervisors of the same or different types.
Planning the network configuration

Before you start configuring your network, refer to this section for information about supported configurations.
110
Network templates
A network template defines the network resources that are available to a customer. A network template is an XML file that is built and verified against a schema provided by Tivoli Service Automation Manager (PMZHB_NetworkConfiguration.xsd). The XSD files are a part of the Tivoli Service Automation Manager distribution and are located in install/files/DCM/ NetworkConfigurations. In this folder, you can also find some sample XML network templates that can be used for single NIC and dual NIC configurations. The resources that can be assigned to customers are grouped into network segments.
Network segments
Network segments are groups of network interfaces that are able to communicate with one another. These network interfaces are configured based on the subnet and DNS definitions of the network segment. Network segments have a type and a usage. The network segment type is a value predefined by Tivoli Service Automation Manager that cannot be changed by the user. The following values are available: v Management - This value marks this network segment as the management network for the provisioned virtual machine. v Customer - This value marks this network segment as the customer network for the provisioned virtual machine. v Storage - This value marks this network segment as the storage network for the provisioned virtual machine. v Backup-Restore - This value marks this network segment as the Backup-Restore network for the provisioned virtual machine. Out of these four network segment types, the management network segment has a special role as it is used by Tivoli Service Automation Manager to provision and manage the virtual machine. The other values help to better distinguish the role that the network segments play for the virtual machines.
Network segment usage

In addition to these network segment type values that are predefined by Tivoli Service Automation Manager, there is one value that is fully definable by the customer. The value is called network segment usage. Users of Tivoli Service Automation Manager can use this value to more specifically define the purpose of the network segment. For example, the value can be used to: v restrict a network segment to a specific resource pool v restrict a network segment to a specific deployable image The network segment usage values are stored in the administrative domain PMZHBNETSEGUSAGE. See this topic for more information about network segment usage values and how to set them.
111
Customer-specific network configuration

Tivoli Service Automation Manager offers an option to set a different network configuration for each customer in the system. When you create a customer, you must select a single network template. During the process of creating and configuring a customer, the network template is used to create the active network configuration of a customer. The following scenarios are possible: v A set of customers share a single network configuration. v Each customer has a different network configuration. The network configuration provided by default with Tivoli Service Automation Manager has the following capabilities: v Each network interface gets an IP address from a pool of subnets defined in its associated network segment. Multiple subnet definitions in a network segment are treated as a large IP address pool by Tivoli Service Automation Manager. v Exactly one network interface must be configured to be the management network interface. v Exactly one network interface must have the host name resolve attribute that is used to derive the host name for the virtual machine. The DNS configuration of the selected segment is used to customize the DNS setup of the virtual machine. The network interface properties come from the deployable image and are entered during the Register Image offering. The network segments with the DNS and subnet configuration come from the customer to which the logged-on user belongs.
Network annotation of deployable images

You can annotate an image with network requirements that it must meet to be deployed. To add network requirements to the deployable images, use the Register Image offering that is available in the self-service user interface. You can use this offering to define the number of network interfaces the image will get during deployment. You can specify the following attributes for each network interface: v Type of the network interface. The same values as for network segment types can be used here. v Usage of the network interface. The same values as for network segment usage can be used here. v The hostname resolve attribute of the network interface. The attribute defines if it is used to derive the virtual machine host name from the IP address that the interface gets during provisioning of the virtual machine. These attributes are used during the Create Project and Add Server offerings to find the suitable network segment to which the virtual machine is able to connect. The following rules apply when finding the suitable network segments: v The network segments come from the network configuration of the customer to which the logged-on user belongs (this user triggers the provisioning request). v Only the network segments that match the network interface type are displayed and can be selected.
112
v If a network interface has usage values defined, only these network segments that have at least one of the image usage values defined are shown. For example, if an image has the usage definitions A and B defined, and there is a network segment with usage A and a network segment with usage C, only the network with usage value A is displayed and can be selected. The self-service user interface offers a dropdown box for each network interface present in the deployable image. In each of these dropdown boxes, the network segments are displayed in which this image can be deployed. If one of the boxes is empty, then the image cannot be deployed. In such case, either the image registration, or the network configuration of the customer is incompatible. The evaluation is performed when the deployable image is selected during the Create Project or Add Server offerings in the self-service user interface wizard.
Network configuration
This topic lists issues you need to consider when planning the deployment and configuration of your hypervisor environment. Network configuration strategies: The multi NIC network support is the only available networking mode and it includes the previously supported network configuration strategies. Note: In earlier network configuration, Tivoli Service Automation Manager supported three key network configuration strategies: v A single management subnetwork hosting the Tivoli Service Automation Manager components, the hypervisor components, and the provisioned virtual machines. v A separate management subnetwork hosting the Tivoli Service Automation Manager components and the hypervisor components and a separate subnetwork hosting the provisioned virtual machines, referred to as the customer subnetwork. v A multi NIC network support where it is possible to have a set of network interfaces to the provisioned virtual machine which can be individually configured. Additionally, support for network isolation via VLAN IDs is available. Currently, the only supported networking mode is the multi-NIC networking support. The first two strategies (single management subnetwork and separate management subnetwork) are no longer supported. The multi NIC network support is defined and selected in Tivoli Service Automation Manager by setting the global provisioning property PMRDP.Net.MultiNicSupport to true in the Data Center Model (DCM). Important: This strategy is automatically enabled by the Cloud Server Pool Administration application. Make sure that none of the following global properties are defined in the global provisioning properties: v Cloud.VRF_MODE v Cloud.ENABLE_VLAN_SUPPORT v Cloud.DUAL_NIC_MODE
113
Note: For information about multi-NIC networking model on System p, see The multi-NIC networking model on System p on page 118. Hostname naming convention The default naming convention for host names is: Prefix (max three characters) and IP address blocks left padded with zeros. For example, ipaddress "1.2.3.4" and prefix "VM" = VM001002003004. When using the multi-NIC networking support, the variable PMRDP.Net.HostnamePrefix property of the subnetwork defines the hostname prefix to be used to generate the virtual machine hostname if the reverse DNS lockup on the Tivoli Service Automation Manager server is not successful. The check box Use this interface for host name resolution in the Register Image offering defines which interface is used to resolve the hostname. Management network structure overview: The management network coordinates the workflow between the Tivoli Service Automation Manager Server and external network environments.
Tivoli Service Automation Manager Server
Boot Servers File Repositories
Tivoli Service Automation Manager Network
Hypervisors
Management VLAN Resource Pool 1
Provisioned Virtual Machines for Resource Pool 1
The diagram shows an overview of the Tivoli Service Automation Manager network. It is required that the external network environment ensures that the management network can communicate with all management VLANs for the various Resource Pools. Tivoli Service Automation Manager does not ensure or provision the external network infrastructure. Networking support covers the network management on the supported hypervisors for configuring the virtual switches.
114
One of the network interfaces must be defined as the management network. The external network setup must ensure that it is possible to communicate between the following elements through the interface: v Tivoli Service Automation Manager Management Node v Boot Servers v Hypervisors Network communication is initiated from the Tivoli Service Automation Manager components. When planning the structure of your Management network, ensure you know the following overviews, which correspond to the groups of components shown in the Tivoli Service Automation Manager network diagram: v Customer network planning overview v Hypervisor and virtual machine overview Servers permitted to reside on the Tivoli Service Automation Manager management network The following management servers require network contact with the endpoint virtual machine and with Tivoli Service Automation Manager. It is required that the external network configuration ensures that these servers can communicate with the management networks defined in the resource pools and the virtual machines which are provisioned through their management network interface. Tivoli Service Automation Manager does not provision or manage this connectivity. It is required that the external network setup ensures this connectivity. Networks are defined using the following: v v v v Tivoli Provisioning Manager server NIM server IBM Tivoli Monitoring server Hardware Management Console is not required, but recommended
v Any file repository (for example, NFS server) containing software to be installed on virtual machines, for example, the IBM Tivoli Monitoring agent. This is not required for file repositories that store only virtual machine images. v Virtual I/O server (VIO) v PowerVM CEC Customer network planning overview: Private or shared customer networks can be related with each of the resource pools through provisioned virtual machines.
115
Tivoli Service Automation Manager Network
Private Customer network 1
Shared Customer network 1
Private Customer network 2
The diagram shows the lower part of Management network, including the customer network structures. For a comprehensive view of the network structure, Management network structure overview on page 114. Each resource pool can have multiple customer networks. They are defined in the same way as the management network: PMRDP.Net.SubnetPool_n = subnet1,subnet2,... where n=0,1,2,... This property defines a pool of subnetworks which are used to derive the IP configuration from and creates a network interface on the created virtual machine. The DNS properties are specified on the resource pool level. Hypervisor and virtual machine overview: You can configure the hypervisor and the virtual machines by defining a number of DCM objects.
116
Resource Pool/ Subnet DCM Object
Network Interface Configuration and Number of Interfaces
Hardware Box Virtual Switch Template DCM Object

Network Card Configuration (Hypervisor Level)
Hypervisor
Virtual Machine
NI 1 E1
NI 2 E2
VLAN Configuration (Hypervisor Level)
P
Virtual Switch
PG
Virtual Switch
Predefined Network Configuration
A
Subnets SP VLANs
SP
External Ethernet Switch
The diagram shows hypervisor and virtual machine configuration structure. The hypervisor is directly related with the Management network structure (see Management network structure overview on page 114). The following DCM objects are used to configure the network support on the hypervisor and virtual machine level: v Spare Pool (Resource Pool) - defines the number of network interfaces for the created virtual machine, the DNS configuration, and the subnets v Subnetwork (Subnet) - defines the network interface configuration (IP address, netmask, gateway, VLAN ID etc.) v Switch (Virtual Switch Template) - defines the hypervisor virtual switch configuration used for the virtual network adapter connected to the virtual machine The external network hardware must be pre-configured by the network administrator before the first provisioning run. For the DCM objects definition types, see Definitions for DCM objects on page 134. Management of the virtual switches for the supported hypervisors is covered by Tivoli Service Automation Manager. This support varies depending on the hypervisor type:
117
v VMware - virtual switches must exist and only the port groups are managed v KVM and Xen - network bridges on the hypervisor are configured v z/VM - virtual switches must exist and only the connection between the Ethernet adapters of the virtual machine and the virtual switches is configured v PowerVM - depending on the network configuration at the user's side, Shared Ethernet Adapters (SEAs) are created and configured by Tivoli Service Automation Manager or must be predefined.
The multi-NIC networking model on System p

The multi-NIC networking model is also supported on System p. The support for the new networking model is similar to the support for other hypervisors: v Configuration per resource pool v Network isolation on the hypervisor level (VIO, VIO set) v Shared Ethernet adapter failover support in the dual VIO scenario v EtherChannel support for shared Ethernet adapters v Management of shared Ethernet adapters on VIO sets v The configuration of VIOs and shared Ethernet adapters with the use of virtual switch template and properties on the hosting platform (CEC) Starting with version 7.2.1.1, Tivoli Service Automation Manager also supports the following solutions: v v v v Dual VIO scenarios Multiple VIO sets per CEC Separate VIOs for networking Multiple network interfaces in LPAR
Assumptions
v VIOs and CECs are preinstalled and configured so that they can be accessed from the HMC and via network. v VIOs on the CECs are discovered by Tivoli Provisioning Manager and exist in the data center model. v VIOs in a VIO set share the same configuration settings. The main focus is on the mapping of the Ethernet adapters to the external network. v All Ethernet adapters that transport tagged traffic must be connected to the external switch through trunk ports. v If the EtherChannel (link aggregation) is used, the external switches and the virtual switch template must be configured accordingly.
118
Network topology
pSeries CEC 2 pSeries CEC 1 VIO Set 2 VIO Set 1 VIO1

ent0 (phys) ent1 (virt) ent3 (virt) ent4 (virt) SP VLAN 1 VLAN 2
Shared Ethernet Adapter (SEA)
Control Channel
External Ethernet Switch 1
VIO2
ent4 (virt) Shared Ethernet Shared Ethernet Adapter (SEA) Adapter (SEA) ent3 (virt) ent1 (virt) ent0 (phys) VLAN 2 VLAN 1 SP
LPAR1
ent0 (virt) ent0 (virt) VLAN 2 VLAN 1
LPAR2
ent0 (virt) ent0 (virt) VLAN 2 VLAN 1
Legend: v SP - trunk switch port
119
VIO support: Learn more about VIO, dual VIO, and multiple VIO set supports available within the management network.
VIOSETs CEC
Global (VIOS.SET)
LPAR
NI 1 E1 NI 2 E2
Network specific (VIOS.SET.NET) PU P PU P
VIO
Ether Channel
Legend: v NI - network interface inside the operating system v v v v E - Ethernet adapter on the virtual machine PU - virtual Ethernet adapter for untagged traffic P - virtual Ethernet adapter with VLAN ID A - Ethernet adapter in HW BOX
VIO support The following assumptions are made for the shared Ethernet adapter management: v a shared Ethernet adapter can be created: on top of a single Ethernet adapter on top of a single EtherChannel that groups multiple adapters together v When a shared Ethernet adapter is created, it consists of the following elements: a single virtual Ethernet adapter used for untagged traffic (PMRDP.Net.UntaggedTrafficPVID) (PU) a single virtual Ethernet adapter used for the control session (Ctrl) (PMRDP.Net.SEACtrlSessionVIandId) v Additional VLANs are handled through additional Ethernet adapters connected to the shared Ethernet adapter (P) (subnet parameters PMRDP.Net.VLAN_PVID, PMRDP.Net.VLANID). The adapter is created with
120
the use of the PV ID and VLAN ID. One adapter per VLAN is created. As a result, a shared Ethernet adapter can support 15 VLANs maximum. Additionally a VLAN device is created for each additional VLAN. v An EtherChannel is created if more than one Ethernet adapter is specified in the virtual machine switch template. The PMRDP.Net.LinkTypeIEEE8023AD property specifies the type of EtherChannel that is created. v If a shared Ethernet adapter and the adapter for the VLAN already exist, no action is taken. If a shared Ethernet adapter with a PV ID as specified by the PMRDP.Net.UntaggedTrafficPVID property and with the physical adapters as specified in the virtual switch template already exists on the VIO, it is used instead of creating a new shared Ethernet adapter. v The PMRDP.Net.VIOPairAlias property specifies the VIO pair that the shared Ethernet adapter is created on.
PU
Ctrl
Ether Channel
Dual VIO and multiple VIO set support v Dual VIO is supported by defining a VIO set. To define the VIO set, use the properties on the CEC. There are two ways to define them: 1. VIOS.SET defines a global VIO for storage and networking 2. VIOS.SET.NET defines a network VIO Each property is an array of attributes in the following form: Symbolic Name assigns a symbolic name to a VIO set VIO DCM Name of the first VIO in the set VIO DCM Name of the second VIO in the set. It is optional and, if not defined, results in a single VIO setup Example: TEST1;v01;v02 v VIOS.SET takes precedence over VIOS.SET.NET v There are multiple definitions per CEC. The property is an array. v VIO sets are referenced from the virtual switch template according to their symbolic name. v If a VIO set is defined, it must also exist on all the CECs in the resource pool.
121
Important: Dual VIO configuration is only supported for HMC/CEC-based Power hypervisors. IVM/PowerBlade hypervisors do not support dual VIO configuration in general. Migration The following migrations are not supported: v from a single VIO to a dual VIO scenario v from a single VIO to a multiple VIO Set scenario Minimal VIO setup for System p: A number of minimal VIO setup scenarios is possible within the management network. General considerations Keep in mind the following information as it is valid for all scenarios: v The VLAN ID of a virtual network adapter in the hardware management console (HMC) must match the PMRDP.Net.VLAN_PVID value in the subnet definition. v Additional VLANs of a virtual network adapter on the HMC must match the PMRDP.Net.VLANID value in the subnet definition. v Dual VIOS configuration is only supported for HMC/CEC-based POWER hypervisors. IVM/PBlade hypervisors do not support this kind of configuration in general. Tivoli Service Automation Manager automates the VIO network configuration based on the subnet and virtual switch template customization. The workflow accesses the VIOs either directly through the network or using the HMC. Therefore, network accessibility to the VIO and the HMC is required from the Tivoli Service Automation Manager server node. Start the VIO network stack before running the Tivoli Service Automation Manager discovery to make the VIO accessible from Tivoli Provisioning Manager. The network automation creates: v A separate virtual network adapter for the untagged traffic for each SEA. v A separate virtual network adapter for each VLAN that is routed using a SEA. A SEA can have up to 16 virtual network adapters assigned to it. Therefore, a maximum of 15 VLANs can be served by a SEA managed by Tivoli Service Automation Manager. The PMRDP.Net.VLAN_PVID property of a subnet must not be equal to the PMRDP.Net.UntaggedTrafficPVID value of the referenced System p virtual switch template. Preparing a minimal network setup of the VIO is necessary for Tivoli Service Automation Manager to perform the automation. All other network configurations are done through these automation workflows, resource pool definitions, subnet definitions, and virtual switch definitions. The SEAs and adapters are created during the provisioning of the virtual machines on the affected VIOs.
122
Minimal VIO setup scenarios The following scenarios are possible while configuring the VIO for System p on the management network: v Minimal VIO setups with a single adapter v Minimal VIO setups with ether channels v With a single adapter and with separate System p management network Minimal VIO setup with a single adapter: Lists scenarios for minimal VIO setup with a single adapter. You can choose one of two scenarios of minimal VIO setup with a single adapter for your management network: Minimal VIO setup with a single adapter and with VLAN ID on management network The scenario assumes that the Management network is using tagged network traffic and has a separate VLAN Id. Note: The customer network is optional but shown for the scenario's purpose. The minimum setup has the following components: v A management network that is accessible from the Tivoli Service Automation Manager management and NIM Server. v The eth0 and the associated SEA 1. It is possible to have an ether channel with more than one adapter if it is necessary. v The control channel (CTRL) for SEA1. This is required for a dual VIO setup. v The adapter for untagged traffic VLAN (PU). v The VE ( Virtual Ethernet adapter) on VIO1 and VIO2 that are connected to the management VLAN. The adapters are using the VLAN Id of the management network adapter (PA) and therefore are connected to the management network by the hypervisor. Make sure that the network stack is started on this network adapter so that the VIO is reachable. v The PT adapter that is created via the PVID (PMRDP.Net.VLAN_PVID) and VLAN Id (PMRDP.Net.VLANID) of the management subnet network. v The network interfaces of each VIO ( NI VIO1, NI VIO2) that provide each VIO with network connectivity. These are the IP interfaces which show up on the DCM representation of the VIO as the management interfaces.
123
Minimal VIO setup with a single adapter and with no VLAN ID on management network
System p CEC
PU
Ctrl
VE
VE
NI VIO1
NI VIO2
Shared Ethernet Adapter (SEA) 1
VIO1
eth0 A1 eth1 A2 eth0 A1
VIO2
eth1 A2
Customer Network
Management Network
The scenario assumes that the Management network is using untagged network traffic. The tagging can be done by, for example, a switch. Note: The customer network is optional but shown for the scenario's purpose. The minimum setup has the following components: v A management network which is accessible from the Tivoli Service Automation Manager management and NIM Server. v The eth0 and the associated SEA 1. It is also possible to have an ether channel with more than one adapter if it is necessary. v The control channel (CTRL) for SEA1. This is required for a dual VIO setup. v The adapter for untagged traffic VLAN (PU). v The VE (Virtual Ethernet adapter) on VIO1 and VIO2 connected to the management VLAN. The adapter are using the untagged network traffic PVID from the PU adapter and therefore are connected to the management network by the hypervisor. v The network interfaces of each VIO (NI VIO1, NI VIO2) that provide each VIO with network connectivity. These are the IP interfaces which show up on the DCM representation of the VIO as the management interfaces. Via these IP addresses, VIOs can be reached by the Tivoli Service Automation Manager management network. The second VIO (VIO2) contains only the setup for the management network interface (VE + NI VIO2). In a dual VIO scenario, the mapping of the network adapters (A1 and A2) and the resulting device names (eth0 and eth1) on the VIOs has to be
124
equal. This means that the management network has to be mapped to Ethernet adapter (A1) as device eth0 on both VIOs in the given example. The customer network is mapped to Ethernet adapter (A2) as device eth1 on each VIO. After initial discovery, the DCM objects for the two VIOs have to be updated via the following property: PMRDP.Net.TrunkPriority., for example 1 for VIO1 and 2 for VIO2. It is required that each VIO on the CEC has a unique value. CEC also shows up as a DCM object after discovery. The following properties have to be set on this DCM Object: v VIOS.SET or VIOS.SET.NET. Use these two properties to define the VIO sets on CEC. In the given example it contains the following values: VIOS.SET VIOSET1;VIO1;VIO2 where VIOSET1 is the symbolic name of the VIOSET and VIO1 and VIO2 are the DCM names of the two discovered VIOs. Save the following values for later usage: v the VLANID of the control session VLAN of SEA1 v v v v the the the the PVID of the PU DCM name of VIO1 and VIO2 device name of the Ethernet Adapters (A) connected to both VIOs ether channel type (if it is used)
Minimal VIO setup with ether channels: Lists scenarios for minimal VIO setup with ether channels. You can choose one of two scenarios of minimal VIO setup with ether channels for your management network:
125
Minimal VIO setup with ether channels and with no VLAN ID on management network
System p CEC
PU
Ctrl
VE
VE
NI VIO1
NI VIO2
VIO1
VIO2
Ether Channel eth0 A1 eth2 A3 eth1 A2 eth3 A4 eth0 A1 eth2 A3 eth1 A2 eth3 A4
Customer Network
Management Network
The scenario assumes that the Management network is using untagged network traffic. The tagging can be done by, for example, a switch. Note: The customer network is optional but shown for the scenario's purpose. The minimum setup has the following components: v A management network that is accessible from the Tivoli Service Automation Manager management and NIM Server. v The eth0 and the associated SEA 1. It is possible to have an ether channel with more than one adapter if it is necessary. v The control channel (CTRL) for SEA1. This is required for a dual VIO setup. v The adapter for untagged traffic VLAN (PU). v The VE ( Virtual Ethernet adapter) on VIO1 and VIO2 that are connected to the management VLAN. The adapters are using the untagged network traffic PVID from the PU adapter and therefore are connected to the management network by the hypervisor. v The network interfaces of each VIO ( NI VIO1, NI VIO2) that provide each VIO with network connectivity. These are the IP interfaces which show up on the DCM representation of the VIO as the management interfaces. Via these IP Addresses the VIOs can be reached by the Tivoli
126
Service Automation Manager management network. The second VIO (VIO2) contains only the setup to have a management network interface (VE + NI VIO2). In a dual VIO scenario the mapping of the network adapters (A1,A2,A3 and A4) and the resulting device names (eth0,eht1,eth2 and eth3) on the VIOs have to be equal. This means that the management network has to be mapped to Ethernet adapter (A1 and A3) as device eth0,eth2 on both VIOs in the given example. The customer network is mapped to Ethernet adapter (A2,A4) as device (eth1,eth3) on each VIO. The devices (Eth0, Eth2) are each grouped together via an ether channel. After initial discovery the DCM objects for the two VIOs have to be updated via the following property: PMRDP.Net.TrunkPriority., for example 1 for VIO1 and 2 for VIO2. It is required that each VIO on the CEC has a unique value. CEC also shows up as a DCM object after discovery. The following properties have to be set on this DCM Object: v VIOS.SET or VIOS.SET.NET. Use these two properties to define the VIO sets on CEC. In the given example it contains the following values: VIOS.SET VIOSET1;VIO1;VIO2 where VIOSET1 is the symbolic name of the VIOSET and VIO1 and VIO2 are the DCM names of the two discovered VIOS. Save the following values for later usage: v the VLANID of the control session VLAN of SEA1 v the PVID of the PU v the DCM name of VIO1 and VIO2 v the device name of the Ethernet Adapters (A) connected to both VIOs v the ether channel type (if it is used)
127
Minimal VIO setup with ether channels and with VLAN ID on management network
System p CEC
PU
Ctrl
PT
VE
VE
NI VIO1
NI VIO2
VIO1
VLAN device
VIO2
Ether Channel eth0 A1 eth2 A3 eth1 A2 eth3 A4 eth0 A1 eth2 A3 eth1 A2 eth3 A4
Customer Network
Management Network
The scenario assumes that the Management network is using tagged network traffic and has a separate VLAN Id. Note: The customer network is optional but shown for the scenario's purpose. The minimum setup has the following components: v A management network that is accessible from the Tivoli Service Automation Manager management and NIM Server. v The eth0 and the associated SEA 1. It is possible to have an ether channel with more than one adapter if it is necessary. v The control channel (CTRL) for SEA1. This is required for a dual VIO setup. v The adapter for untagged traffic VLAN (PU). v The VE ( Virtual Ethernet adapter) on VIO1 and VIO2 that are connected to the management VLAN. The adapters are using the VLAN Id of the management network adapter (PA) and therefore are connected to the management network by the hypervisor. Make sure that the network stack is started on this network adapter so that the VIO is reachable. v The PT adapter that is created via the PVID (PMRDP.Net.VLAN_PVID) and VLAN Id (PMRDP.Net.VLANID) of the management subnet network.
128
v The network interfaces of each VIO ( NI VIO1, NI VIO2) that provide each VIO with network connectivity. These are the IP interfaces which show up on the DCM representation of the VIO as the management interfaces. It is required to create a virtual VLAN device for the VLAN Id (PMRDP.Net.VLAN_PVID) on the SEA. The second VIO (VIO2) contains only the setup for the management network interface (VE + NI VIO2). In a dual VIO scenario the mapping of the network adapters (A1,A2,A3 and A4) and the resulting device names (eth0,eht1,eth2 and eth3) on the VIOs have to be equal. This means that the management network has to be mapped to the Ethernet adapter (A1 and A3) as device eth0,eth2 on both VIOs in the given example. The customer network is mapped to the Ethernet adapter (A2,A4) as device (eth1,eth3) on each VIO. The devices (Eth0, Eth2) are each grouped together via an ether channel. After initial discovery, the DCM objects for the two VIOs have to be updated via the following property: PMRDP.Net.TrunkPriority, for example 1 for VIO1 and 2 for VIO2. It is required that each VIO on the CEC has a unique value. CEC also shows up as a DCM object after discovery. The following properties have to be set on this DCM Object: v VIOS.SET or VIOS.SET.NET. Use these two properties to define the VIO Sets on the CEC. In the given example it contains the following values: VIOS.SET VIOSET1;VIO1;VIO2 where VIOSET1 is the symbolic name of the VIOSET and VIO1 and VIO2 are the DCM names of the two discovered VIOs. Save the following values for later usage: v the VLANID of the control session VLAN of SEA1 v the PVID of the PU v v v v the the the the DCM name of VIO1 and VIO2 device name of the Ethernet Adapters (A) connected to both VIOs ether channel type (if it is used) VLAN Id and PVID of the PT adapter
Minimal VIO setup with a single adapter and with separate System p management network: Learn more about components, properties, and values involved in this setup.
129
System p CEC
SP/PU
Ctrl
VE
SP/PU
Ctrl
VE
NI VIO1
NI VIO2
VIO1
VLAN device eth0 A1 eth0 A1 VLAN device
VIO2
Customer Network
Management Network
System p Management Network
The scenario assumes that the Management network is using tagged network traffic and has a separate VLAN Id. Note: The customer network is optional but shown for the scenario's purpose. The minimum setup has the following components: v A management network that is accessible from the Tivoli Service Automation Manager management and NIM Server. v The eth0 and the associated SEA 1. It is possible to have an ether channel with more than one adapter if it is necessary. v The control channel (CTRL) for SEA1. This is required for a dual VIO setup. v The VE ( Virtual Ethernet adapter) on VIO1 and VIO2 that are connected to the management VLAN. The adapters are using the VLAN Id of the management network adapter (PA) and therefore are connected to the management network by the hypervisor. Make sure that the network stack is started on this network adapter so that the VIO is reachable. v The SP/PU adapter that has to be created via the untagged traffic PVID and the VLAN Id of the System p management network as the additional VLAN Id on the adapter.
130
v The network interfaces of each VIO ( NI VIO1, NI VIO2) that provide each VIO with network connectivity. These are the IP interfaces which show up on the DCM representation of the VIO as the management interfaces. It is required to create a virtual VLAN device for the VLAN Id of the System p management network on the SEA. The second VIO has to be setup in the same way as VIO1 for high availability. In a dual VIO scenario the mapping of the network adapters (A1 and A2) and the resulting device names (eth0 and eth1) on the VIOs have to be equal. This means that the management network has to be mapped to the Ethernet adapter (A1) as device eth0, on both VIOs in the given example. The customer network is mapped to the Ethernet adapter (A2) as device (eth1) on each VIO. Important: The System p management network is not known to Tivoli Service Automation Manager. Therefore the setup of this network and the interfaces including high availability have to be performed manually. After initial discovery, the DCM objects for the two VIOs have to be updated via the following property: PMRDP.Net.TrunkPriority, for example 1 for VIO1 and 2 for VIO2. It is required that each VIO on the CEC has a unique value. CEC also shows up as a DCM object after discovery. The following properties have to be set on this DCM Object: v VIOS.SET or VIOS.SET.NET. Use these two properties to define the VIO Sets on the CEC. In the given example it contains the following values: VIOS.SET VIOSET1;VIO1;VIO2 where VIOSET1 is the symbolic name of the VIOSET and VIO1 and VIO2 are the DCM names of the two discovered VIOs. Save the following values for later usage: v the VLANID of the control session VLAN of SEA1 v the PVID of the PU v the DCM name of VIO1 and VIO2 v the device name of the Ethernet Adapters (A) connected to both VIOs v the ether channel type (if it is used) Virtual switch template properties for System p: Lists virtual switch parameters and properties, and describes their functions. A virtual switch template definition corresponds to a Shared Ethernet Adapter (SEA) on a VIO server. The following list provides information about the virtual switch template properties for System p: v PMRDP.Net.Cloud set to true indicates that this switch is used for Tivoli Service Automation Manager v PMRDP.Net.SwitchType set to Virtual Switch Template specifies the usage type v PMRDP.Net.SEACtrlSessionVlanId specifies the ID of the shared Ethernet adapter control session VLAN v PMRDP.Net.LinkTypeIEEE8023AD defines the link aggregation type used. The value may be either true (IEEE) or false (Cisco) v PMRDP.Net.UntaggedTrafficPVID specifies the VLAN ID for untagged traffic for this shared Ethernet adapter on System p
131
v PMRDP.Net.VIOPairAlias is the alias name that specifies the VIO Set used on the System p platform. This value must be resolvable on the set of System p CECs that are defined in the resource pool. v The connection to physical network adapters is modeled by: interface card entries interface card, for example, entx, where x starts with 0 card type: serial If more than one adapter is specified, an EtherChannel adapter is created by Tivoli Service Automation Manager System p networking support to group the adapters together. In this case, the PMRDP.Net.LinkTypeIEEE8023AD property must be set. Depending on the PMRDP.Net.LinkTypeIEEE8023AD property, you must configure the external switches for this link aggregation. This configuration is an external administrative task. Additional parameters on the subnet for System p The PMRDP.Net.VLAN_PVID property is specific for System p. It defines the PVID used for the virtual adapter attached to the shared Ethernet adapter if PMRDP.Net.VLANID is set. If the PMRDP.Net.VLANID property is not specified, you can omit the PMRDP.Net.VLAN_PVID property. on the VIO definition The PMRDP.Net.TrunkPriority parameter specifies the trunk priority to be used for the virtual Ethernet adapter. The possible values are: v 0 means is_trunk=0 and there is no access to the external network v the values from 1 to 15 specify the priority of trunk. The trunk priority must be unique across the VIOS of the CEC. on the System p CEC v pSeries CEC settings (Provisioning Computer System) VIOS.SET is a property array that stores VIO pairs available for provisioning. This array specifies VIO pairs that are shared between the storage and network. Each entry of the property array consists of comma-separated values in the following form: Alias name, primary VIO, secondary VIO; for example, Hugo;V1;V2 - Alias name: the name of the VIO pair used in the virtual switch template to select the VIO that is used for provisioning. Do not include commas in the alias name as it is a delimiter. - First VIO: the name of the first VIO for networking - Second VIO: the name of the secondary VIO for networking. You can omit it if only a single VIO is required. VIOS.SET.NET is a property array that stores the VIO pairs available for provisioning. This array specifies VIO pairs for networking only. Each entry of the property array consists of comma separated values in the following form: Alias name, primary VIO, secondary VIO; for example, Otto;V3;V4 - Alias name: the name of the VIO pair used in the virtual switch template to select the VIO that is used for provisioning. - First VIO: the name of the first VIO for networking - Second VIO: the name of the secondary VIO for networking. You can omit it if only a single VIO is required.
132
Note: The VIOS.SET parameter takes precedence over VIOS.SET.NET v VIO sets must exist on all CECs that belong to the resource pool. v The virtual switch template references to the alias name of VIOS.SET by the PMRDP.Net.VIOPairAlias property. Planning for System p configuration: Learn how to retrieve the parameters from System p CEC and VIO. About this task You can retrieve the following parameters from the System p CEC and VIO: v the trunk values used for your VIOs v the IDs of the control session VLAN used on CECs Procedure 1. Make sure VIOs are discovered. 2. Make sure if there are enough free slots on VIOs and the property values for slot management are correct. These property values are: LPAR.available_slots, LPAR.max_virtual_slots, LPAR.next_virtual_slot 3. Define the VIO sets (VIOS.SET or VIOS.SET.NET) on the CEC. What to do next Check the external network setup: v how the Ethernet adapters are mapped to VIOs v v v v if ether channels are used which ether channel type is used if the Ethernet adapters are connected to the switch through trunk ports which VLAN IDs are used
Troubleshooting: Lists the conditions that have to be met to configure correctly your network. Make sure that the following conditions are met: v Matching values are used for the control session VLAN for SEAs and the trunk priority for VIOs is set correctly. Failures can result in network outage if more than one VIO serves System p internal network. In this case, there can be a MAC table inconsistency and the associate VLAN is not accessible. v VIO sets are defined for all CECs that belong to the resource pool. v VIOs that are in a VIO set share the same configuration settings and have the same mappings of the Ethernet adapters. v If Ether channels are used, configure them consistently on VIO and on the external switch. v VIOs are accessible through network so that you can issue commands to them. On VIOs, there must be network interface configured and active after startup. v The subnets that are used for management match the NIM server definitions. Otherwise, the NIM provisioning fails. Each LPAR must be accessible from the NIM server through their management network. You must define the provisioning image on the NIM server (mksys backup and spot) correctly.
133
v The capacity of LPAR is high enough to boot up before the provisioning timeout occurs (for example, 30 minutes). v The communication between the NIM server, HMC, System p, and VIO is possible. v The LPAR management interface communicates with the NIM and Tivoli Service Automation Manager server. v The DNS connected to the Tivoli Service Automation Manager node can be resolved from the given IP address for the LPAR to the fully qualified domain name (FQDN) and that the short name part of the FQDN can be resolved to the same IP address again. Both resolutions are done during provisioning. If this is not true, a problem may occur that the LPAR cannot be provisioned because it has no management interface.
Definitions for DCM objects

Lists the definitions for DCM objects involved in the network support configuration. The following DCM objects are responsible for the network support configuration: v Resource Pool v Subnet v Switch
Definitions on the Resource Pool DCM object

The Resource Pool defines general settings, such as: v VMWare adapter type configuration. VMware can have multiple different network adapter types. With Tivoli Service Automation Manager, it is possible to set this type on a resource pool base. PMRDP.Net.VMware.NicAdapterType - this property can contain one of the VMWare supported adapter types (E1000, VMXNET 2, VMXNET 3)
Definitions on the subnetwork DCM object

The subnet defines the network configuration on the operating system level: v PMRDP.Net.Cloud - set to true to indicate usage by Tivoli Service Automation Manager v PMRDP.Net.VLANID - VLAN ID for the subnet v PMRDP.Net.VLAN_PVID - PVID used for the virtual adapter attached to the SEA if PMRDP.Net.VLANID is set. If no PMRDP.Net.VLANID property is specified, the property can be omitted v PMRDP.Net.Broadcast - broadcast mask for subnet v PMRDP.Net.Gateway - gateway IP address for the subnet v PMRDP.Net.DomainName - domain name used for hostname generation if DNS reverse resolution does not work v PMRDP.Net.HostnamePrefix - hostname prefix used to generate the Virtual Machine hostname if DNS and Domain Name are not specified. The algorithm creates a name in the form <prefix><IP Address>, for example, VM010010010010, where the IP address is 10.10.10.10 and the prefix is VM. v Default route parameter. Parameters are only supported if PMRDP.Net.Gateway is specified: PMRPD.Net.DefaultRoute.Destination - default route for the network interface PMRPD.Net.DefaultRoute.NetMask - default route for the network interface
134
PMRPD.Net.DefaultRoute.Metric - default route for the network interface v Virtual switch templates per hypervisor. A case in which multiple of these entries exist is supported, for example if more that one hypervisor supports a subnet: PMRDP.Net.VMware.SwitchTemplate - name of the virtual switch template for the VMware hypervisor PMRDP.Net.KVM.SwitchTemplate - name of the virtual switch template for the KVM hypervisor PMRDP.Net.Systemp.SwitchTemplate - name of the virtual switch template for the PowerVM hypervisor PMRDP.Net.Systemz.SwitchTemplate - name of the virtual switch template for the System z hypervisor PMRDP.Net.Xen.SwitchTemplate - name of the virtual switch template for the Xen hypervisor
Definitions on the virtual switch DCM object

The virtual switch template is based on the DCM object switch. It is used as a template to customize the virtual switches on the hypervisor level. Functions The virtual switch defines the network adapters on the hypervisor which are bound to the virtual switch. This is done by configuring interface cards on the switch. There is one entry defined per adapter of type serial. v For KVM and Xen, a single adapter can be defined that is connected to the network bridge and on which the VLAN device is configured. v For PowerVM, multiple adapters are supported if an ether channel is used, or a single adapter if no ether channel is available. v For System z and VMware, this definition is not used. Tivoli Service Automation Manager assumes that the hypervisors are connected using the trunk ports to the external switches. VLAN tagging is done using the virtual switches of the supported hypervisors. It is the responsibility of the external network setup to: v predefine Virtual LANs on the external switches v set up the external switches, routers, or firewalls v configure the external switch ports v assure communication between the Tivoli Service Automation Manager management network and the management VLANs for the different resource pools Properties This template contains hypervisor-specific properties. v VMware related properties: PMRDP.Net.VSwitchName - the VMware virtual switch name where the port groups are created PMRDP.Net.BridgePrefixName - prefix name that is used to create the port group name in VMware: <prefix>+ 4-digit VLAN ID PMRDP.Net.HostGroupId - specifies the DCM ID of the VMware virtual center v System p related properties:
135
PMRDP.Net.VIOPairAlias - alias name that specifies the VIOS pair used on the system p Platform. This value must be resolvable on each of the PowerVM CECs that are defined in the resource pool. PMRDP.Net.SEACtrlSessionVlanId - shared ethernet adapter control session VLAN ID Note: This parameter is not required for the Power Blade scenario. PMRDP.Net.UntaggedTrafficPVID - VLAN ID that allows untagged network traffic to pass through PMRDP.Net.LinkTypeIEEE8023AD - defines link aggregation type used true (IEEE) or false (Cisco) There must be one entry in the interface card list which specifies the network adapter name the shared ethernet adapter binds to during creation. v System z related properties: PMRDP.Net.zVM_NetworkPortDeviceNumber - NIC device number which is used during virtual machine provisioning PMRDP.Net.zVM_NetworkDeviceRange - device allocation range. This parameter is used during virtual machine provisioning. v KVM-related properties: PMRDP.Net.BridgePrefixName - prefix name used to create the network bridge name: <prefix>+ 4-digit VLAN ID There must be one entry in the interface card list which specifies the network adapter name the bridge binds to during creation. v Xen related properties: PMRDP.Net.BridgePrefixName - prefix name used to create the network bridge name: <prefix>+ 4-digit VLAN ID There must be one entry in the interface card list which specifies the network adapter name the bridge binds to during creation. v Global parameters required for all hypervisors: PMRDP.Net.Cloud - set to true to indicate usage by Tivoli Service Automation Manager PMRDP.Net.SwitchType - set to Virtual Switch Template to indicate that this is a virtual switch template
Preparing the provisioning back ends

If you are using z/VM, KVM or Xen, then setup the environment so that Tivoli Service Automation Manager can provision and manage virtual servers with them.
Configuring the z/VM environment for Tivoli Service Automation Manager

This section provides information on how to set up the z/VM environment so that Tivoli Service Automation Manager can provision and manage virtual servers with the z/VM hypervisor.
136
Introduction to the z/VM environment

This section describes the required z/VM setup for provisioning of z/VM Linux guests by Tivoli Service Automation Manager. The following outlines the basic steps in this process: 1. Plan for the environment. 2. Define CP_Owned and User_Volume DASD. 3. Set up the z/VM Network version 5.4, and VSWITCH. 4. Update the TCP/IP configuration. 5. Set up DIRM. 6. Enable VSMSERVE. For details, see http://publib.boulder.ibm.com/infocenter/ zvm/v6r1/topic/com.ibm.zvm.v610.dmse6/toc.htm. 7. Create the Linux prototype. 8. Install the Linux master system. 9. Enable personalization. Systems that have RACF enabled require additional setup by the security administrator. For more information about z/VM, and Linux on System z, see the z/VM publication Getting Started with Linux on System z .
Planning the z/VM environment

The following information needs to be collected before starting the configuration: v What DASD volumes will be used to contain the Linux systems? Minidisks for master systems = Minidisk_volume Minidisk pool for provisioned systems = Minidisk_Pool_Volume v What devices are available for network connectivity? OSA device for Vswitch = VSwitch_OSA_Addr OSA device for IP = IP_OSA_Device_Addr v What IP addresses are available for use by new Linux systems? Provisioned IP address pool = IP_Pool v What is the z/VM IP address? z/VM IP address = External IP_Addr
Required software
v z/VM 5.4 with DIRM enabled v z/VM TCP/IP for network connectivity v SUSE Linux Enterprise Server 10 SP2 (or Red Hat Enterprise Linux 5 update 4) Linux on System z z/VM guest for MAPSRV ID v v Master image: SUSE Linux Enterprise Server 10 Linux on System z SUSE Linux Enterprise Server 11 Linux on System z Red Hat Enterprise Linux 5 update 4 Linux on System z
137
Setting up z/VM for Linux provisioning

This task describes how to configure z/VM to provision Linux guests. Modifying the z/VM System Configuration file: About this task Directions for updating the SYSTEM CONFIG file can be found in z/VM CP Planning and Administration. Refer to this publication if you have doubts about what you are changing. Errors in this file can have serious repercussions on the usability of the system. See http://publib.boulder.ibm.com/infocenter/zvm/v6r1/ topic/com.ibm.zvm.v610.hcpa5/toc.htm The SYSTEM CONFIG file contains the primary system definitions used when CP is booted (IPLed). All of the information needed to configure CP statically comes from this file. The SYSTEM CONFIG file resides in the same location as the bootable CP kernel. Update SYSTEM CONFIG from the main id. To access the SYSTEM CONFIG file, perform the following steps to release the primary parm disk: Procedure 1. Release Parm disk from CP:
cprelease a
2. Access the primary parm disk (MAINT's CF1):

link * cf1 cf1 mr access cf1 z
3. Edit the SYSTEM CONFIG file:

xedit system config z
System DASD: About this task The User_Volume_List is a list of DASD volumes that CP should automatically attach to the system for user mini-disk definitions. Because all minidisks are managed by CP, all volumes that house minidisks must be attached to the z/VM system. Update the User_Volume_List section to list all DASD that are used for mini-disks across all master, guest, and DASD pools.
/**********************************************************************/ /* User_Volume_List */ /* Multiple labels can be stacked on one statement. */ /**********************************************************************/ /* USER_VOLUME_LIST USRP01 USRP02 USRP03 USRP04 User_Volume_List Minidisk volumes /*DASD for Minidisks*/ User_Volume_List Minidisk volumes /*DASD for Pools*/ */
138
z/VM network: About this task Add the VSWITCH definitions. Network definitions for provisioned systems must be in the main SYSTEM CONFIG file. Using embedded files for network definitions is not supported. VSWITCH The VSWITCH is set up in trunk mode to allow guests to be provisioned on unique VLANs. [OSA_Addr] is the OSA address for the VSwitch that will be attached to provisioned systems.
DEFINE VSWITCH zVM_LAN Name RDEV OSA_Addr CON CONTR DTCVSW1
Modifying system features: About this task The FEATURES statement in SYSTEM CONFIG allows you to modify attributes associated with the running system at IPL time. Allow passwords on commands: About this task The Passwords_on_Cmds feature tells CP which commands allow passwords. Edit the Features statement to enable passwords as follows:
Passwords_on_Cmds, Autolog yes , Link yes , Logon yes
Enable system shutdown: About this task The Disconnect_timeout feature controls whether and when a virtual machine is logged off after it has been forced to disconnect. You will turn this feature off, so that any virtual machine that has been forced to disconnect will not be logged off. Add the Disconnect_timeout off option to the Features statement. The ShutdownTime and Signal ShutdownTime features enable a virtual machine to register with CP to receive a shutdown signal when z/VM is shutting down. CP waits to shut itself down until the time interval (in seconds) is exceeded, or until all of the virtual machines enabled for the signal shutdown have reported a successful shutdown. Linux distributions support this function, which allows Linux to shut down cleanly before z/VM shuts down. Add the following line after the Features statement.
Set, ShutdownTime 30 , Signal ShutdownTime 500
139
Custom user classes: About this task The following commands need to be added to allow the MAPSRV Linux system to manage and update the virtual network devices.
/********************************************************************/ /* IBM DI PRIVCLASS SETUP */ /********************************************************************/ MODIFY CMD SET SUBC VSWITCH IBMCLASS B PRIVCLASS BT MODIFY CMD QUERY SUBC * IBMCLASS B PRIVCLASS BT MODIFY CMD IND IBMCLASS E PRIVCLASS ET MODIFY CMD QUERY SUBC * IBMCLASS G PRIVCLASS GT MODIFY CMD LINK IBMCLASS G PRIVCLASS GT
Restore z/VM Parm disk: About this task Perform the following steps to release the primary parm disk: Procedure 1. Release Parm disk from CP
release z
2. Access the primary parm disk (MAINT's CF1).

link * cf1 cf1 rr
3. Edit the SYSTEM CONFIG file

cpaccess maint cf1 a sr
Updating the z/VM TCP/IP configuration

This task describes how to configure TCP/IP for z/VM Linux provisioning.
About this task

The TCP/IP stack on z/VM needs to be set up to allow communication between the MAPSERVE guest and the VSMSERVE server in the TCP/IP stack. It is also necessary to set up the external TCP/IP communications. To do this:
Procedure
1. Add network devices, home address, routing information, port definitions and autolog definitions. 2. Log on to the tcpmaint id and edit PROFILE TCPIP on the 198 disk. You will need to know the device addresses and port names for the Vswitch, and the IP/Gateway addresses for the IP network. This information will be defined by the VM system programmer.
140
Network devices: About this task The following example presents a sample network device definition for the TCP/IP stack.
DEVICE OSA_DEV_Name OSD OSA_Device_Addr PORTNAME OSA_Portname AUTORESTART LINK ETH0 QDIOETHERNET OSA_DEV_Name
Add the following start statements at the end of the profile:

START OSA_DEV_Name
Home address and gateway: About this task The next step is to add the IP address for the stack and the routing statements.
HOME External_IP_Addr Subnetmask ETH0 GATEWAY ; Network Subnet First Link MTU ; Address Mask Hop Name Size ; ------------- --------------- --------------- ---------------- ----Network_Address Subnetmask = ETH0 1492 DEFAULTNET Gateway_Address ETH0 1492
Only the external OSA connection (eth0) needs a route. Autolog statement: About this task The following servers need to be present in the AUTOLOG.
AUTOLOG FTPSERVE PORTMAP VSMSERVE ENDAUTOLOG 0 0 0 ; FTP SERVER ; PORTMAP SERVER ; VM SMAPI SERVER
Port statement: About this task The following ports need to be defined to the TCP/IP stack:
PORT 20 TCP FTPSERVE NOAUTOLOG 21 TCP FTPSERVE 23 TCP INTCLIEN 111 TCP PORTMAP 111 UDP PORTMAP 172.16.0.1 1023 TCP VSMSERVE ; ; ; ; ; ; FTP Server FTP Server TELNET Server Portmap Server Portmap Server VM SMAPI SERVER
141
Defining the external IP address to the TCP/IP stack: About this task This section defines how to add the external IP OSA to the z/VM TCP/IP stack. The OSA addresses for external IP connectivity are assigned by the VM system programmer. Procedure 1. Edit the SYSTEM DTCPARMS file on tcpmaint.198. This is normally accessed as drive D:
file SYSTEM DTCPARMS D
2. Xedit the file and add the following statement:

:NICK.TCPIP :TYPE.SERVER :CLASS.STACK :ATTACH.OSA Addresses for IP
3. Save the file and exit.
Setting up 'Directory Maintenance Facility for z/VM (DirMaint)

This task describes how to configure DIRM
About this task

DIRM needs to be enabled as part of the z/VM setup. All DIRM commands issued must complete with RC=0. Multiple CONFIG* DATADVH files are allowed. Multiple CONFIG* DATADVH files are searched in reverse alphabetical order. Be sure to select the correct configuration file. In the examples below, CONFIGxx is the system configuration file. Configuring the CONFIGxx DATADVH file: About this task Two statements need to be added to CONFIGxx DATADVH Procedure 1. Use DIRM commands to get and replace the file:
dirm send configxx datadvh
Note: The command will return the file. Receive it with the replace command. 2. Add the three statements:
ALLOW_ASUSER_NOPASS_FROM= VSMSERVE * ASYNCHRONOUS_UPDATE_NOTIFICATION_EXIT.UDP= DVHXNE EXEC USE_RACF= YES ALL
3. Verify that the following parameters are set correctly:

RUNMODE= OPERATIONAL ONLINE= IMMED DASD_ALLOCATE= EXACT_FF DATAMOVE_MACHINE= DATAMOVE * * DVHDXD_FLASHCOPY_BEHAVIOR= 2 DVHDXD_FLASHCOPY_COMPLETION_WAIT= 0 0 MAXIMUM_UNASSIGNED_WORKUNITS= 100
142
4. Save the file and exit. 5. Replace the file and make it active:
dirm dirm dirm dirm file configxx datadvh rldcode rlddata rldextn
Allocation groups: About this task Configure DirMaint to automatically allocate minidisks from a predefined pool of volumes. These pools are defined in the EXTENT CONTROL file: Procedure 1. Retrieve the EXTENT CONTROL file from DirMaint.
DIRM SEND EXTENT CONTROL RECEIVE 138 = = A
2. Edit the extent control file to include the available DASD to be used as a DASD pool
* ******************************************************************** :REGIONS. *RegionId VolSer RegStart RegEnd Dev-Type Comments 000001 Minidisk Pool Volume 0001 3338 3390-03 000002 Minidisk Pool Volume 0001 3338 3390-03 000003 Minidisk Pool Volume 0001 3338 3390-03 :END. :GROUPS. *GroupName RegionList POOL0 (ALLOCATE ROTATING) POOL0 000001 000002 000003 :END.
3. Send the EXTENT CONTROL file back to DirMaint, and make it active:
DIRM FILE EXTENT CONTROL A DIRM RLDEXTN
Installing DDRCOPY EXEC on DirMaint: About this task To install ddrcopy exec on DirMaint, follow these steps: Procedure 1. Log off the maint id. c 2. From the mapsrv id, FTP ddrcopy.exec to maint. 3. Logon to maint and send ddrcopy exec to dirmaint using the following command:
dirm file ddrcopy exec a
143
Creating the MAPSRV and MAPAUTH IDs

This task describes how to configure the MAPSRV and MAPAUTH IDs
About this task

The MAPSRV ID serves as the Tivoli Provisioning Manager boot server. MAPAUTH is the class A userid that issues restricted system commands on behalf of Tivoli Provisioning Manager. Use the following directory entries to create the MAPSRV and MAPAUTH IDs. MAPSRV DIRECT A
USER MAPSRV PASSW0RD 512M 1G GT INCLUDE IBMDFLT IPL 150 MACHINE ESA OPTION LNKNOPAS LANG AMENG * DEDICATE 0150 [Addr_of Dedicated DASD_for_Linux_System] * NICDEF Vswitch_OSA_Addr TYPE QDIO LAN SYSTEM Vswitch_Name NICDEF MAPLAN_OSA_Addr TYPE QDIO LAN SYSTEM MAPLAN * MDISK 0191 3390 Starting cylinder 10 Minidisk volume MR MDISK 0151 3390 Starting cylinder 200 Minidisk volume MR MDISK 0192 3390 Starting cylinder 50 Minidisk volume
MAPAUTH DIRECT A
USER MAPAUTH PASSW0RD 32M 32M ABCDEFG INCLUDE IBMDFLT MDISK 0191 3390 Starting_cylinder 10 Minidisk volume MR
After the two files have been created, they need to be added to the z/VM user directory:
dirm add mapsrv dirm add mapauth
Installing Linux on the MAPSRV ID Information on installing Linux on System z can be found in Getting Started with Linux on System z. Install SLES 10 or RHEL 54 on the mapsrv id and verify that the vmcp command works.
mapsrv:~ # vmcp q time TIME IS 06:37:02 EST THURSDAY 04/10/08 CONNECT= 99:59:59 VIRTCPU= 017:11.47 TOTCPU= 023:44.53
If the command fails, edit /etc/sysconfig/kernel and add vmcp to the MODULES_LOADED_ON_BOOT section:
MODULES_LOADED_ON_BOOT="vmcp"
144
Copy IBM-System-z.MAPSRV-7.2.1-1.s390x.rpm from the Tivoli Service Automation Manager management server to the mapsrv id and install it with the rpm command:
mapsrv:~ # rpm -ivh IBM-System-z.MAPSRV-<version number>.s390x.rpm
Reboot the mapsrv id. Granting MAPAUTH the authority to issue DIRM commands: Issue the following commands to DIRM to grant the authorizations:
dirm for all authfor mapauth cmdlevel 140a cmdset adghmops dirm for all authfor mapauth cmdlevel 150a cmdset adghmops
Authorizing MAPAUTH to issue SMAPI commands VSMSERVE is the machine that runs the z/VM SMAPI. When setting up SYSTEM CONFIG, MAPLAN is created. Since the SMAPI is an RPC interface, the traffic is secured by allowing only the MAP and TCPIP systems to connect to it. To authorize MAPAUTH to issue the SMAPI commands: 1. Log on to vsmserve:
#cp ipl cms
2. When prompted, enter any characters to stop the IPL and return to CMS mode. 3. Xedit the VSMSERVE AUTHLIST file and add MAPAUTH:
DO.NOT.REMOVE MAINT VSMSERVE MAPAUTH DO.NOT.REMOVE ALL ALL ALL
4. Save the file the log off VSMSERVE.
Setting up Linux on System z

This task describes how to configure to provision Linux guests.
About this task

This section describes how to create Linux on System z master systems. Defining virtual machines for Linux on System z: About this task
145
Creating Linux directory files: About this task A directory prototype will allow all provisioned guests to share common statements. Multiple directory prototypes can be created to support as many configurations as are needed. Procedure 1. Create a file called LNXPROTO PROTODIR A:
USER LNXPROTO PASSW0RD 512M 512M G CPU 00 CPU 01 CLASS G STORAGE 512M MAXSTORAGE 2047M IPL 500 MACHINE ESA 2 OPTION MAINTCCW TODENABLE CONSOLE 0009 3215 T *
2. Use the DirMaint FILE command to tell DirMaint to keep a copy of this prototype for future use:
dirm file LNXPROTO protodir
Note: The zVM_Prototype variable in the Tivoli Provisioning Manager virtual server template (see "Customizing virtual server templates") must be set to the appropriate protodir file. 3. Create a default Linux directory entry called LINDFLT DIRECT A:
PROFILE LINDFLT CLASS G STORAGE 512M MAXSTORAGE 2047M IPL 500 IUCV ALLOW MACHINE ESA OPTION QUICKDSP CONSOLE 0009 3215 T NICDEF Vswitch_OSA_Addr TYPE QDIO LAN SYSTEM zVM_LAN_Name SPOOL 000C 2540 READER * SPOOL 000D 2540 PUNCH A SPOOL 000E 1403 A LINK MAINT 0190 0190 RR LINK MAINT 019D 019D RR LINK MAINT 019E 019E RR LINK TCPMAINT 0592 0592 RR
146
Creating Linux master systems: About this task The Linux master system serves as a template for provisioned Linux systems. The Linux master can be built using VM minidisks, or full-pack mini-disk. The master system must have a single disk containing the Linux root and boot partitions. If GNU/Linux LVM is used for the root partition, then any number of disks may be added to the guest dynamically during provisioning. The boot partition cannot be part of a logical volume. Procedure 1. Log on to maint and create a Linux master directory entry called SL10MSTR DIRECT A: Sample for master with VM minidisk
USER SL10MSTR PASSW0RD 1024M 1024M G 64 INCLUDE IBMDFLT CPU 0 NODEDICATE CPU 1 NODEDICATE IPL CMS MACHINE ESA 4 OPTION QUICKDSP APPLMON * NICDEF Vswitch_OSA_Addr TYPE QDIO LAN SYSTEM zVM_LAN_Name * MDISK 0193 3390 Start_Cylinder End_Cylinder Volume_Name
You must specify a read password for Linux on System z mini-disks. Note: For a full-pack minidisk, the DEVNO keyword must be used on the MDISK statement. 2. Use DIRM to create a z/VM guest for SL10MSTR:
dirm add sl10mstr
Setting up a Linux on System z master system: Installing Linux on SL10MSTR: About this task Install Linux on System z on the SL10MSTR user ID. See Getting Started with Linux on System z for more information on installing Linux on System z. Enabling personalization: About this task After installing the master system, make changes to the Linux system to enable personalization: Procedure 1. Regardless of which Linux distribution you use, make sure that python and python-xml packages are installed 2. Copy IBM-System-z.MASTER-<version number>.s390x.rpm from the Tivoli Service Automation Manager management server to the Linux master ID and install it with the following command:
147
sl10mstr:~ # rpm -ivh IBM-System-z.MASTER-<version number>.s390x.rpm
3. Check the mount definitions in file etc/fstab. Mounts should happen by label, not by device or id which can change in the copied image. (Optional) Disabling the boot menu at IPL: About this task This procedure will eliminate the 10 second wait for the boot menu during the IPL. Procedure 1. Edit the :menu section of /etc/zipl.conf and change prompt = 1 to prompt = 0. 2. Save the change and run the zipl command. Disabling parallel boot option on SUSE Linux Enterprise Server 11: About this task On SUSE Linux Enterprise Server 11, ensure that parallel boot option is disabled. To disable this option: Procedure 1. Edit the file /etc/sysconfig/boot. 2. Edit the following parameter as shown:
RUN_PARALLEL="no"
3. Save the file. Verifying your configuration: About this task To verify the new configuration: Procedure 1. Log in to mapsrv. 2. Change to directory /opt/ibm/ztsam/workflow and run the following command: ../bin/uhubrpcclient <z/VM IP address> <SM API port number> mapauth <password> 12345 imagequery SL10MSTR The command should return the z/VM directory entry of SL10MSTR.
Using RACF with z/VM

This task describes how to work with z/VM in a RACF environment.
About this task

If the RACF Security Server for z/VM is installed, additional setup is required for Tivoli Service Automation Manager. The system RACF Administrator will need to configure RACF to allow Tivoli Service Automation Manager to access system resources. The setup in the previous sections must be completed before configuring RACF. The steps are as follows: 1. Permit access to system resources
148
2. Configure z/VM networking 3. Grant RACF Admin authority to Dirmaint / Datamove 4. Configure VSMSERVE. Permitting access to system resources: Procedure 1. Configure the maint, operator, and ftpserve IDs to access the system reader:
rac permit maint class(vmrdr) id(datamove) acc(update) rac permit operator class(vmrdr) id(tcpip) acc(update) rac permit ftpserve class(vmrdr) id(ftpserve) acc(control)
2. Allow VSMSERVE to access the z/VM parm disk:

rac setropts generic(vmmdisk) rac permit maint.cf1 acc(alter) id(vsmserve) rac permit maint.cf2 acc(alter) id(vsmserve)
Configuring z/VM networking: Procedure 1. Define RACF resources for Vswitches. In the RACF commands below, zVM_LAN_Name is the name of the Vswitch defined on the system.
RAC RDEFINE VMLAN SYSTEM.[zVM_LAN_Name] UACC(NONE)
2. If the system implements a VLAN, define a RACF resource for the VLAN. The VLAN number must be 4 digits, with leading zeroes if necessary.
RAC RDEFINE VMLAN SYSTEM.[zVM_LAN_Name].[VLAN] UACC(NONE)
3. Reset VMLAN definitions:

RAC PERMIT SYSTEM.[zVM_LAN_Name] CLASS(VMLAN) RESET(ALL)
4. Allow update access to Maint and Dtcvsw1:

RAC PERMIT SYSTEM.[zVM_LAN_Name] CLASS(VMLAN) ID(MAINT) ACCESS(UPDATE) RAC PERMIT SYSTEM.[zVM_LAN_Name] CLASS(VMLAN) ID (DTCVSW1) ACCESS(UPDATE)
5. Allow Mapsrv and Tcpip to connect to vswitch. If a VLAN is defined, it must be 4 digits.
RAC PERMIT SYSTEM.[zVM_LAN_Name] CLASS(VMLAN) ID(MAPSRV) ACCESS(UPDATE) RAC PERMIT SYSTEM.[zVM_LAN_Name].[VLAN] CLASS(VMLAN) ID(MAPSRV) ACCESS(UPDATE)
6. Activate the VMLAN class:

RAC SETROPTS CLASSACT(VMLAN)
149
Configuring DIRMAINT/DATAMOVE: Procedure Give Dirmaint and Datamove RACF Admin authority:
rac alu dirmaint special rac alu datamove operations
Configuring VSMSERVE: Procedure 1. Allow VSMSERVE to perform password validation:

RAC RDEFINE VMCMD DIAG0A0.VALIDATE UACC(NONE) RAC PERMIT DIAG0A0.VALIDATE CLASS(VMCMD) ID(VSMSERVE) ACCESS(READ) RAC SETROPTS CLASSACT(VMCMD)
2. Allow VSMSERVE to connect to the RACF service machine:

RAC RDEFINE FACILITY ICHCONN UACC(NONE) RAC PERMIT ICHCONN CLASS(FACILITY) ID(VSMSERVE) ACCESS(UPDATE) RAC SETROPTS CLASSACT(FACILITY)
3. If protection for DIAG0A0 is not currently active, activate it by issuing:

RALTER VMXEVENT EVENTS1 DELMEM(DIAG0A0/NOCTL) SETEVENT REFRESH EVENTS1
Note: DIAG0A0 is active by default. However, this setting can be changed in the currently active VMXEVENT profile by issuing:
RDEFINE VMXEVENT EVENTS1 ADDMEM(DIAG0A0/NOCTL)
Updating VSMSERVE DTCPARMS: Procedure 1. Log on to VSMSERVE 2. IPL CMS: enter any characters to bypass the IPL function 3. Xedit vsmserve dtcparms and verify that the following statements are coded
:Nick.VSMSERVE :Type.server :Class.VSMAPI :ESM_ENABLE.YES :PARMS.-E :Owner.VSMSERVE :Exit.VSMEXIT :Nick.VSMAPI :Type.class :Name.Virtual System Management API server :Command.DMSVSMAS :Runtime.C :Diskwarn.YES :ESM_Validate.RPIVAL :ESM_Racroute.RPIUCMS
150
Updating DIRMAINT: Procedure 1. From the maint ID, retrieve CONFIGXX DATADVH and add definitions for RACF. See Setting up 'Directory Maintenance Facility for z/VM (DirMaint) on page 142for more information on the CONFIGXX DATADVH file. The DIRMAINT-RACF relationship present in the default DIRMAINT configuration files and the modifications shown here must be preserved so that DIRMAINT can perform the appropriate ADDUSER/DELUSER RDEFINE/RDELETE commands when the CP directory entries for provisioned servers are created and deleted. You can extend these configuration files and the DVHXPN user exits as long as the ability to perform these operations is preserved.
dirm send configxx datadvh
2. Add the following lines to the file

POSIX_CHANGE_NOTIFICATION_EXIT= DVHXPESM EXEC LOGONBY_CHANGE_NOTIFICATION_EXIT= DVHXLB EXEC USER_CHANGE_NOTIFICATION_EXIT= DVHXUN EXEC DASD_OWNERSHIP_NOTIFICATION_EXIT= DVHXDN EXEC PASSWORD_CHANGE_NOTIFICATION_EXIT= DVHXPN EXEC RACF_ADDUSER_DEFAULTS= UACC(NONE) RACF_RDEFINE_VMMDISK_DEFAULTS= UACC(NONE) AUDIT(FAILURES(READ)) RACF_RDEFINE_VMPOSIX_POSIXOPT.QUERYDB= UACC(READ) RACF_RDEFINE_VMPOSIX_POSIXOPT.SETIDS= UACC(NONE) RACF_RDEFINE_SURROGAT_DEFAULTS= UACC(NONE) AUDIT(FAILURES(READ)) RACF_RDEFINE_VMBATCH_DEFAULTS= UACC(NONE) AUDIT(FAILURES(READ)) RACF_RDEFINE_VMRDR_DEFAULTS= UACC(NONE) AUDIT(FAILURES(READ)) RACF_RDEFINE_VMMDISK_DEFAULTS= UACC(NONE) AUDIT(FAILURES(READ))RACF_VMBATCH_DEFAULT_MACHINES= BATCH1 BATCH2 TREAT_RAC_RC.4= 0 | 4 | 30
3. Save the file by entering:

dirm file configxx datadvh
4. Xedit vsmserve dtcparms and verify that the following statements are coded:
:Nick.VSMSERVE :Type.server :Class.VSMAPI :ESM_ENABLE.YES :PARMS.-E :Owner.VSMSERVE :Exit.VSMEXIT :Nick.VSMAPI :Type.class :Name.Virtual System Management API server :Command.DMSVSMAS :Runtime.C :Diskwarn.YES :ESM_Validate.RPIVAL :ESM_Racroute.RPIUCMS
151
Configuring the KVM environment for Tivoli Service Automation Manager

This section provides information on how to set up the KVM environment so that Tivoli Service Automation Manager can provision and manage virtual servers with the KVM hypervisor.
Before you begin

These setup steps are intended for a skilled KVM administrator. Before you configure Tivoli Service Automation Manager for KVM, there are some preparatory steps that are required to be performed on the KVM environment. This task will describe the high level steps for setting up the KVM hypervisor and the KVM image server to meet the Tivoli Service Automation Manager requirements. Customize the KVM environment as described in this section and collect the settings as they will be required as input for the subsequent configuration task. If you already have a KVM server and KVM image server installed ensure their settings match the requirements described. To facilitate the task, use the tableTable 17 on page 153 to record your settings.
About this task Procedure

1. Install and configure the KVM hypervisor on a host. This is the server that will provision the virtual machines. a. Install Linux on a server and ensure that ssh and NFS server are installed and active. b. Mount a partition on the server to /var and ensure it has the maximum space available since it will be used for provisioning servers. c. Record the password for the root user Id in the worksheet or in a protected source. d. Record the IP address, the Subnetwork mask and the MAC address of the KVM server in the worksheet. e. When configuring the networks on the KVM hypervisor host, if you are configuring separate networks on the host, one for the management network and one for the customer network, you must configure the first network card on the host ("eth0") to be on the management network (by default, 10.160.0.0/255.255.0.0) and the second network card ("eth1") to be on the customer network (by default, 10.180.0.0/255.255.0.0). If configuring only one network for both, they should both be on the first network card ("eth0"). f. If the KVM host is configured with a non-static IP, you need to obtain the range of IPs that the DHCP server gives out and record it in the worksheet. Tivoli Service Automation Manager needs this range so that when it discovers the host on which the KVM hypervisor is running, it can assign it the static IP address within Tivoli Provisioning Manager. You will need to set this range in a later configuration step for Tivoli Service Automation Manager. Record these values in the worksheet. If you assign a static IP to your host, ensure it is outside the range defined for the management network. g. Increase the maximum number of loop devices to be used per provisioning to 64, then reboot the hypervisor.
152
vi /etc/modprobe.conf (add the following line) options loop max_loop=64 vi /etc/udev/makedev.d/50-udev.nodes # add loop9 to loop63
Note: For large KVM hosts it may be necessary to increase the maximum number of loop devices up to the kernel limit (currently 256). 2. Install and configure the KVM image server and NFS server on a host. This is the server on which the operating system images templates should be stored. This server must belong to the management subnetwork that you will configure in the subsequent section Customizing a Tivoli Service Automation Manager cloud pool for KVM on page 191. a. Install Red Hat Linux version 5.4 on a physical server and ensure that the KVM image server and NFS server are installed as well as the KVM hypervisor packages. b. Create a /repository directory, if not already present. c. Configure the NFS server to export that directory. This is the directory that will be mounted to access the images to use during the KVM provisioning or virtual machines. d. Create a subdirectory called /kvmimages in the /repository directory. This will be the directory where the KVM images should be stored for use. e. Record the password for the root user ID in the worksheet or in a protected source. f. Record the IP address of the KVM image server in the worksheet. 3. Customize the KVM environment for the KVM image backups. a. Select the server that you will use for KVM image backups. This server must have enough space for storing KVM image backups. This server must belong to the management subnetwork that you will configure in the subsequent section Customizing a Tivoli Service Automation Manager cloud pool for KVM on page 191. b. Record the IP address of that server in the worksheet. c. Record the password for the root user ID in the worksheet or in a protected source. d. Create a directory that can be used as for image backups. e. Record the path of that kvm_backup_directory in the worksheet below. 4. Create one or more OS image templates that can be used by Tivoli Service Automation Manager and store them on the KVM Image server in the directory /repository/kvmimages. Special requirements must be met for these templates so that they can be used by Tivoli Service Automation Manager. Refer to Creating operating system image templates for KVM on page 265 for more details about creating these templates.
Results
Table 17. The KVM server and KVM image server settings worksheet Your KVM setting DHCP server IP ranges Description Range of IP addresses that the DHCP server uses when assigning dynamic IP addresses to hosts. IP address of the KVM hypervisor server host
Your value
IP address
153
Table 17. The KVM server and KVM image server settings worksheet (continued) Your KVM setting Subnetwork mask MAC address password Description Subnetwork mask of the KVM hypervisor server host MAC address of the KVM hypervisor server host Password for the root user of the KVM hypervisor server host IP address of KVM image server host Password for the root user of the KVM image server host IP address of the host used for KVM image backups Password for the root user of the host used for KVM image backups The name of the directory used for backup and located on the host used for KVM image backups You may want to record the password in a protected source. You may want to record the password in a protected source. You may want to record the password in a protected source. Your value
IP address password IP address password
kvm_backup_directory
Configuring the Xen environment for Tivoli Service Automation Manager

This section provides information about the prerequisites required for setting up Xen so that Tivoli Service Automation Manager can provision and manage virtual servers with Xen.
Preparing for an automatic Xen host install

If DHCP is available, the Xen hosts can be installed automatically by booting the target server from network.
About this task

Remember that the only version of Xen supported by Tivoli Service Automation Manager is Xen 3.0.3 on Red Hat Enterprise Linux 5.3. Newer versions of Xen are not supported.
Procedure
1. Create a configuration file called /etc/dhcpd.conf that contains the following code:
# DHCP Server Configuration file. # see /usr/share/doc/dhcp*/dhcpd.conf.sample # ddns-update-style interim; ignore client-updates; option option option option option option space gpxe; gpxe-encap-opts code 175 = encapsulate gpxe; gpxe.bus-id code 177 = string; iscsi-initiator-iqn code 203 = string; gpxe.bios-drive code 189 = unsigned integer 8; gpxe.keep-san code 8 = unsigned integer 8;
154
subnet 10.160.0.0 netmask 255.255.0.0 { #option domain-name ""; #option domain-name-servers 10.160.0.1; option routers 10.160.0.1; option subnet-mask 255.255.0.0; range dynamic-bootp 10.160.250.0 10.160.254.0; default-lease-time 86400; max-lease-time 86400; option vendor-class-identifier "PXEClient"; #version 3 # Vendor Class setup for PXE option vendor-encapsulated-options 01:04:00:00:00:00:ff; next-server 10.160.0.64; filename "pxelinux.0"; host test { hardware ethernet 00:14:5E:6D:86:66; next-server 10.160.0.64; filename ""; option iscsi-initiator-iqn "iqn.1994-05.com.ibm:00145e6d8660"; option root-path "iscsi:10.160.0.25::::iqn.1986-03.com.ibm:sn.101184607"; # option gpxe.bios-drive 130; option gpxe.keep-san 1; if not exists gpxe.bus-id { filename "gpxe/undionly.kpxe"; } } }
a. Locate the subnet 10.160.0.0 netmask 255.255.0.0 and replace it to match your own subnet. b. Locate the range dynamic-bootp 10.160.250.0 10.160.254.0 and replace the ip range to match your own dynamic ip range. c. Locate the next-server 10.160.0.64 and replace this IP address with the IP of your tftpboot server, in our case it is same as our DHCP server. 2. Start DHCP. a. Log on as root. b. Run the service dhcpd start command. 3. Ensure that DHCP is running: a. Log on as root. b. Type service dhcpd status. You should see:
dhcpd (pid ####) is running...
4. Log on to the NFS server as root and create a /repository with the following subdirectories: v xen-host-platform including the OS installation images for kick start installation v xenimages - including the Xen images for Xen provisioning v kvmimages - including the KVM images for KVM provisioning v itm621 Tivoli Monitoring v6.2.1 installation images for the monitoring agent middleware provisioning
155
v windows including the Windows sysprep files for Windows image creation
Creating the Post Install Script file

About this task
Create the CloudPostInstall script to complete the process of setting up Xen. When copying the code to the file you are creating, pay special attention to the following values and change them accordingly: v Replace the value 10.160.0.130 with the IP address of your Tivoli Provisioning Manager server. v The last two values of the # chkconfig 2345 99 01 line set the priority to start and stop the scripts. You may need a set of different values for your environment, for example 85 15.
Procedure
1. Log on to the NFS server. 2. Create the CloudPostInstall directory using the following command: > mkdir -p /repository/xen-host-platform/rhel5.3-64/CloudPostInstall. 3. Copy the following lines into /repository/xen-host-platform/rhel5.3-64/ CloudPostInstall/CloudPostInstall:
#! /bin/bash ## CloudPostInstall Cloud Post Install script ## chkconfig: 2345 99 01 # description: script should be started in levels 2,3,4, and 5, start priority should be 99, \ # and stop priority should be 01. # source function library . /etc/init.d/functions TPM_URL="http://10.160.0.130:9080" RETVAL=0 start() { echo -n $"Running Cloud Post Install scripts..." #set authorized_keys mkdir -p /root/.ssh rm -f /root/.ssh/authorized_keys wget -O /root/.ssh/authorized_keys "$TPM_URL/TpmListener?getpublickey=true" chmod 644 /root/.ssh/authorized_keys #get the interface that have an IP. dev=ìfconfig | grep -B 2 "inet addr:" | head -n 1 | cut -f 1 -d" "` IPADDR=ìfconfig $dev | grep Mask | awk {print $2} | cut -f2 -d:` MACADDR=ìfconfig $dev | grep HWaddr | awk {print $5}` MASK=ìfconfig $dev | grep Mask | awk {print $4} | cut -f2 -d:` wget "$TPM_URL/TpmListener/CallbackServlet?ip="$IPADDR"&mac="$MACADDR"&initmask="$MASK"&poolname= Cloud Pool" chkconfig CloudPostInstall off chkconfig --del CloudPostInstall rm /etc/init.d/CloudPostInstall [ $RETVAL -eq 0 ] && touch /var/lock/subsys/CloudPostInstall } stop() { echo -n $"not implemented" RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/CloudPostInstall } case "$1" in start) start stop) ;;
156
stop ;; restart|reload) stop start RETVAL=$? ;; *) esac echo $"Usage: $0 {start|stop|restart}" exit 1 exit $RETVAL
Results
The CloudPostInstall script is ready.
Setting up Xen
About this task
If you do have a DHCP available in your environment, you can boot your target server from the network, and install your OS with kick start automatically. After the OS installation, the post-installation steps in the kick start file will call the CloudPostInstall scripts to prepare your rhel5.3 system and reboot. After the reboot, the installation process will call the RP.CreateBareMetalHost workflow to finish up the Tivoli Provisioning Manager DCM setup. After this Xen host has been created as a Provisioning Computer object, you can proceed to step 2. Check the status of RP.CreateBareMetalHost workflow to continue your setup. If you do not have a DHCP available in your environment, follow this procedure, manually prepare your Xen host, and then proceed to step 2. Check the status of RP.CreateBareMetalHost workflow.
Procedure
1. Install rhel5.3 manually. a. Use Linux text install. b. Type in the license number c. Select disabled for firewall. d. Select disabled for selinux. e. Allocate all disks to VolGroup00. f. Allocate 5 GB to LogVol00 as / directory, and define fstype as ext3. g. Allocate 1 GB to LogVol01 as swap. h. Make sure select virtualization package. 2. Verify the rhel5.3 system you just installed. Make sure that you have the following rpm installed in your system, otherwise install it. v ntp-4.2.2p1-9.el5.x86_64.rpm v xen-libs-3.0.3-80.el5.i386.rpm v xen-libs-3.0.3-80.el5.x86_64.rpm v compat-libstdc++-33-3.2.3-61 v vnc-server-4.1.2-14.el5 3. Edit the /boot/grub/menu.lst file and change the value of dom0_mem to 512M. 4. Run the CloudPostInstall script.
157
a. Log on as root of the Xen host which you just installed. b. Mount the NFS, locate the CloudPostInstall script, and run this script by rebooting the system. v mkdir /repository (create /repository directory, if it is not there yet) v mount <NFS_server_IP>/repository/repository v cd /repository/xen-host-platform/rhel5.3-64/CloudPostInstall (replace rhel5.3-64 to point to your install image). v cp CloudPostInstall /etc/init.d/ (copy the CloudPostInstall script to /etc/init.d directory) v chmod 777 /etc/init.d/CloudPostInstall v chkconfig add CloudPostInstall v chkconfig CloudPostInstall on v chkconfig sendmail off v echo "blacklist tg3" >> /etc/modprobe.d/blacklist v reboot
Results
The CloudPostInstall script will start the RP.CreateBareMetalHost Tivoli Provisioning Manager workflow.
Configuring cloud server pools

Use the Tivoli Service Automation Manager Cloud Server Pool Administration application to create and configure cloud server pools.
About this task

A cloud server pool is the central object that Tivoli Service Automation Manager uses to define cloud environments. It contains references to all Data Center Model (DCM) resources needed for the pool (including hypervisor manager, host platform, file repositories, and resource pools). Furthermore, it defines reservation parameters used during the provisioning of cloud projects. For each hypervisor used for server provisioning, one cloud server pool must be created and properly configured. The creation and configuration of such pools is facilitated by the Cloud Server Pool Administration application. Note: The image repository that you configure must have enough space to save images at any time. Tivoli Service Automation Manager does not check whether there is enough space available. If no space is available when saving an image, an inbox assignment is created to manually recover from the situation. You must then manually cancel the save request and all following steps. Then, add additional disk space to the image repository at the back end by using hypervisor-specific administration tasks. You can choose one of the two methods to create a cloud server pool: v Create DCM XML files, load the vrpool.properties file, perform the discovery and then validate and enable the cloud server pool. v Perform all the configuration steps manually using the Cloud Server Pool Administration application. The following is the general procedure for cloud server pool creation:
158
Procedure
1. Create all objects required for the pool, such as a computer object for the hypervisor host, a file repository object for the virtual machine images, network definitions, etc. These are the objects that fundamentally define the hypervisor on which servers are to be provisioned. 2. Define user-specific reservation parameters. 3. Create a cloud server pool object. 4. Associate all the objects created to the cloud server pool object. 5. Perform all the required steps (e.g. hypervisor discovery). 6. Validate and enable the cloud server pool.
Configuring cloud server pools manually

You can use the Cloud Server Pool Administration application to manually perform all the configuration steps one after another.
About this task

This documentation suggests a certain order of configuration steps according to which cloud server pools and cloud storage pools are configured before the network configuration is performed. Server and repository DCM objects that are created during cloud server pool configuration in the Cloud Server Pool Administration application require associated subnetwork DCM objects to be operable. These subnetworks are created automatically if no matching ones exist in DCM that are compatible with the specified network address of the server or repository. It is important that the subnetwork of these server or repository objects do not overlap with the management or customer subnetworks that are created as part of the network configuration. Such configuration is not supported and leads to errors. To overcome potential problems, you can import the network DCM objects or perform the network configuration before configuring cloud server and cloud storage pools. You can also avoid this problem by using DCM objects instead of the "Quick Define" functions to configure cloud server pools. This section contains topics that describe the procedure for manually creating a new cloud server pool for all supported hypervisors. The steps are performed in the Cloud Server Pool Administration application.
Procedure
1. Log on to the administrative user interface. 2. Click Go to > Service Automation > Configuration > Cloud Server Pool Administration. Note: Configuring a cloud server pool for different hypervisors involves different steps. When you change the hypervisor type in the Hypervisor Type field, the tabs in the Resource Configuration section are also changed.
159
Manually configuring cloud server pools for VMware

Perform these steps to manually configure a VMware cloud server pool in the Cloud Server Pool Administration application.
Before you begin

Collect the following information about the VirtualCenter: v The host name, IP address, and network mask v User name and password v VirtualCenter host certificate Additionally, collect the following information: v The name of the data center, for example "CloudDC" v The name of the data store or data stores attached to the ESX hosts
Procedure
1. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example "VMware Cloud Pool 1". Set the hypervisor type to VMware. 2. In the Resource Configuration section, in the Resource Pool Configuration tab, click the Define New Resource Pool button. a. In the Define New VMware Resource Pool window that appears, enter a name for the new resource pool, for example "VMware Resource Pool 1". Optionally, enter the NIC adapter type in this window. b. Click Save. 3. Open the Virtual Center Configuration tab. a. Click Define New Virtual Center. b. Specify the name of the DCM server object that is to be created, the Datacenter path of the hypervisor, the IP address and network mask, and credentials of the virtual center. Note: If no matching subnetwork exists in DCM, the subnetwork is created automatically. c. Click Save. d. Click Virtual Center Discovery. Note: First, you must import the SSL certificate of the virtual center into the WebSphere certificate store. Otherwise, the discovery workflow fails with a "No certificate found" error. e. Click Save. f. Click Refresh to see the current discovery workflow state. Note: "Success" indicates that this step is finished. If the workflow fails, you can open the Provisioning Workflow application and start the workflow manually. You can also open the Provisioning Workflow Status application to analyze the failed workflow. After the discovery, the ESX host or hosts are added to the resource pool. You can click the Delete icon on the right to remove hosts from the resource pool. Note: Running parallel host platform discoveries is not supported by Tivoli Provisioning Manager.
160
4. You do not need to run the image discovery in the Image Template Discovery tab at this point. Virtual server images are discovered during the virtual center discovery. Use the Image Discovery button in this tab only if you want to discover new images that were added at a later time. 5. Open the Additional Resources tab. a. Specify the name of the data store on which you want Tivoli Service Automation Manager to create provisioned virtual servers. b. Click Save. 6. Open the Save / Restore Settings tab. a. Select the data store that you want to use for saved virtual server images. Note: These data repositories are discovered during the virtual center discovery. Therefore, wait until the discovery workflow status changes to "Success" before trying to select the data store in this field. b. Click Save. 7. Review the values in the Provisioning Parameters tab and adjust them to your needs. 8. If you want to assign this cloud server pool to all customers: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?. Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 9. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are grayed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 10. If the following error message is displayed during the validation: CTJZH2064E - The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
Manually configuring cloud server pools for KVM

Perform these steps to manually configure a KVM cloud server pool in the Cloud Server Pool Administration application.
Before you begin

Collect the following information about the KVM Image Server: v v v v IP address and network mask user name and password for SSH / SCP access the path on the image server the master images are stored the path on the image server where to store the instance images
161
v the path on the image server where to store the saved / backup images Additionally, collect the following information about the KVM host or hosts: v IP address v network mask v MAC address
Procedure
1. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example "KVM Cloud Pool 1". Set the hypervisor type to KVM. 2. In the Resource Configuration section, in the Resource Pool Configuration tab, click the Define New Resource Pool button. a. In the Define New KVM Resource Pool window that appears, enter a name for the new resource pool, for example "KVM Resource Pool 1". b. Click Save. 3. Open the Boot Server Configuration and Image Discovery tab. a. Click Define New KVM Image Server to define the KVM image server in DCM. b. Specify the name of the server, its IP address, the network mask, and the SSH and SCP credentials. c. Click Save. d. Specify the directory name where he master images are located on the KVM image server. e. Click Install Boot Server and wait until the workflow is completed successfully. Click Refresh to see the current workflow state. f. Click KVM Image Discovery to discover images. Wait until the discovery workflow is finished. 4. Open the Additional Resources tab. a. Specify the name of the repository, for example "KVM File Repository", as well as the IP address and network mask of the KVM image server that is to be used. b. Click Save. 5. Open the Save / Restore Settings tab. a. Click Define New Saved Image Repository. b. Specify the name of the repository, for example "KVM Saved Image Repository". c. Select the KVM Image Server and the path where to store the saved images, for example /repository/kvmsavedimages. d. Click Save. e. Click Define New Instance Image Repository. f. Specify the name of the repository, for example "KVM Instance Image Repository". g. Click Save. 6. Open the Host Platform Configuration tab. a. Specify the parameters that are necessary to create a KVM host: IP address of the KVM host, the network mask, MAC address, and root password. b. Click Create KVM Host.
162
Note: The host platform is created with the specified parameters and it is attached to the resource pool. You can verify this in the Resources Overview section. Try to connect to the KVM host at the specified address using SSH. 7. Review the values in the Provisioning Parameters tab and adjust them to your needs. 8. If you want to assign this cloud server pool to all customers, do the following: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?. Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 9. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are greyed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 10. If the following error message is displayed during the validation: CTJZH2064E - The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
Manually configuring cloud server pools for System p

Perform these steps to manually configure a System p cloud server pool in the Cloud Server Pool Administration application.
Before you begin

Collect the following information about the Hardware Management Console (HMC) server: v host name, IP address, network mask v hscroot password v CEC name to be used for this cloud server pool Collect the following information about the host platform and VIOS configuration: v CEC Host Platform Name v Name of the Physical Ethernet Device, for example "eth0" v the IP address and host name of the VIO server Collect the following information about the NIM server: v host name, IP address, network mask, gateway address, root password v path on the NIM boot server where the saved / backup images are to be stored, for example /export/nim/images/backups.
163
Procedure
1. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example System p Cloud Pool 1. Set the hypervisor type to LPAR. 2. In the Resource Configuration section, in the Resource Pool Configuration tab, click the Define New Resource Pool button. a. In the Define New PowerVM Resource Pool window that appears, enter a name for the new resource pool, for example System p Resource Pool 1. b. Click Save. 3. Open the HMC Discovery tab. a. Click Define New HMC Server in order to define HMC in DCM. b. Specify the server name, IP address, network mask, and the credentials for the HSCROOT access. Note: Server name must be valid and must be resolvable by DNS. Run a DNS lookup on the Tivoli Service Automation Manager management server if you are not sure if a name is valid. You can specify an IP address as a server name as well. c. Click Save. d. Specify the Central Electronic Complex (CEC) name to be discovered. This parameter is optional. If you leave this field blank, all CECs managed by this HMC are discovered which normally takes much time. e. Click Save. f. Click HMC Discovery and wait for the workflow to complete successfully. 4. Open the Host Platform and VIOS Configuration tab. a. Check the SAN Storage / Multiple VIOS Mode? box if you want to use SAN storage in MPIO mode. Such setting is default for a System p cloud use case. Checking this box also unlocks the Storage Discovery tab. b. Enter the CEC and VIOS parameters and run the Configure CEC workflow. The CEC host platform is now attached to the resource pool. You can verify this in the Resources Overview section. Try to connect to the host and VIO server at the specified address using SSH. This step must be repeated for all hosts that are to be added to the resource pool. c. Optionally, you can assign a new device model to the host platform or platforms attached to the resource pool. To use the Tivoli Service Automation Manager LPAR storage extension, select the Cloud pSeries HostPlatform Storage device model and click Assign Device Model. The new device model is listed in the Resources Overview section. d. Configure the VIOS Sets for each host platform using the table in the VIOS Configuration section below the Assign Device Model to Hostplatforms section. For each host platform, open the VIOS section by clicking the little arrow icon next to its name. Click Add VIOS Set and select a VIOS set type. Each host platform can define at most one VIOS.SET, at most one VIOS.SET.SAN, or at most one VIOS.SET.NET e. Click New VIOS Set Entry and add the alias for the VIOS set. Important: This alias must match the alias specified in the network configuration (System p Switch Template definition). f. Click Add VIOS Server to add a VIOS server or servers to this VIOS set and specify the trunk priority if needed. g. Review the VIOS set entries and click Save.
164
5. Open the NIM Discovery tab. a. Click Define New NIM Server. b. In the window that appears specify the DNS resolvable host name or IP address as NIM Server Name. Specify the IP address, network mask, and the SSH user credentials for the NIM server. c. Click OK. d. Click Define New Boot Server. e. Specify the server name, for example NIMBootServer, the IP address, network mask, and gateway address for this boot server. f. Click NIM Discovery and wait until the workflow is finished successfully. Note: During creation of NIM boot server a -BootServer suffix is appended to the server name that you specified. This is to ensure that a unique NIM boot server object is created even if the NIM server and the NIM boot server have the same name. Unique name is required for Tivoli Provisioning Manager. g. Click Save. 6. Open the Save / Restore Settings tab. a. Click Define New PowerVM Repository. b. Specify the name, for example System p Repository. Select the previously created NIM boot server and specify the location of the saved images on the NIM server. c. Click Save. 7. In the Storage Discovery tab, click Storage Pool Discovery. This tab is only available if the LPAR storage extension is installed. 8. Review the values in the Provisioning Parameters tab and adjust them to your needs. 9. If you want to assign this cloud server pool to all customers, do the following: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?. Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 10. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are grayed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 11. If the following error message is displayed during the validation: CTJZH2064E - The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
165
Manually configuring cloud server pools for System p (POWER7 Blade scenario)
Perform these steps to manually configure a POWER7 Blade cloud server pool in the Cloud Server Pool Administration application.
Before you begin

Collect the following information about the Power Blade server: v host name, IP address, network mask v hscroot password v Host platform object name to be used for this cloud server pool Collect the following information about the host platform and VIOS configuration: v Host Platform Object Name v Name of the Physical Ethernet Device, for example "eth0" v the IP address and host name of the VIO server Collect the following information about the NIM server: v host name, IP address, network mask, gateway address, root password v path on the NIM boot server where the saved / backup images are to be stored, for example /export/nim/images/backups. Important: Make sure that all POWER Blades to be discovered are already defined as computer objects in the Tivoli Provisioning Manager DCM with proper SAP definitions. In this way, it is possible to access the management interface of the Blade using SSH.
Procedure
1. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example System p Cloud Pool 1. Set the hypervisor type to LPAR. 2. In the Resource Configuration section, in the Resource Pool Configuration tab, click the Define New Resource Pool button. a. In the Define New PowerVM Resource Pool window that appears, enter a name for the new resource pool, for example System p Resource Pool 1. b. Click Save. 3. Use the following method to discover POWER Blades: a. Click Go to > Discovery > Provisioning Discovery > Discovery Configurations. b. Click New Discovery Configuration on the toolbar. c. Specify a name for the new discovery definition, for example Cloud_p5_Blade_Discovery. d. Select the category Other. e. Click the icon next to the Method field and select the IVM Discovery method. Click OK to save the discovery definition. f. Open the defined discovery and select Run Discovery. g. In the section Select targets, select the computer objects representing the Power Blades to be discovered. h. In the section Scheduling select Now. i. Click Submit to run the discovery.
166
After the discovery, each Power Blade is displayed with its system name as own host platform, similarly to how CECs are presented in DCM. 4. In the HMC Discovery tab, enter the name of an IVM computer object in the entry field HMC Computer Name and click Save. Restriction: Do not run an HMC discovery by clicking HMC Discovery. 5. Open the Host Platform and VIOS Configuration tab. a. Check the SAN Storage / Multiple VIOS Mode? box if you want to use SAN storage in MPIO mode. Such setting is default for a System p cloud use case. Checking this box also unlocks the Storage Discovery tab. b. Enter the CEC and VIOS parameters and run the Configure CEC workflow. The CEC host platform is now attached to the resource pool. You can verify this in the Resources Overview section. Try to connect to the host and VIO server at the specified address using SSH. This step must be repeated for all hosts that are to be added to the resource pool. c. Optionally, you can assign a new device model to the host platform or platforms attached to the resource pool. To use the Tivoli Service Automation Manager LPAR storage extension, select the Cloud pSeries HostPlatform Storage device model and click Assign Device Model. The new device model is listed in the Resources Overview section. d. Configure the VIOS Sets for each host platform using the table in the VIOS Configuration section below the Assign Device Model to Hostplatforms section. For each host platform, open the VIOS section by clicking the little arrow icon next to its name. Click Add VIOS Set and select a VIOS set type. Each host platform can define at most one VIOS.SET, at most one VIOS.SET.SAN, or at most one VIOS.SET.NET e. Click New VIOS Set Entry and add the alias for the VIOS set. Important: This alias must match the alias specified in the network configuration (System p Switch Template definition). f. Click Add VIOS Server to add a VIOS server or servers to this VIOS set and specify the trunk priority if needed. g. Review the VIOS set entries and click Save. 6. Open the NIM Discovery tab. a. Click Define New NIM Server. b. In the window that appears specify the DNS resolvable host name or IP address as NIM Server Name. Specify the IP address, network mask, and the SSH user credentials for the NIM server. c. Click OK. d. Click Define New Boot Server. e. Specify the server name, for example NIMBootServer, the IP address, network mask, and gateway address for this boot server. f. Click NIM Discovery and wait until the workflow is finished successfully. Note: During creation of NIM boot server a -BootServer suffix is appended to the server name that you specified. This is to ensure that a unique NIM boot server object is created even if the NIM server and the NIM boot server have the same name. Unique name is required for Tivoli Provisioning Manager. g. Click Save. 7. Open the Save / Restore Settings tab.
167
a. Click Define New PowerVM Repository. b. Specify the name, for example System p Repository. Select the previously created NIM boot server and specify the location of the saved images on the NIM server. c. Click Save. 8. In the Storage Discovery tab, click Storage Pool Discovery. This tab is only available if the LPAR storage extension is installed. 9. Review the values in the Provisioning Parameters tab and adjust them to your needs. 10. If you want to assign this cloud server pool to all customers, do the following: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?. Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 11. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are grayed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 12. If the following error message is displayed during the validation: CTJZH2064E - The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
Manually configuring cloud server pools for VMControl

Perform these steps to manually configure a VMControl cloud server pool in the Cloud Server Pool Administration application.
Before you begin

Collect the following information about the VMControl hypervisor: v the trust certificate of the VMControl hypervisor v the hostname, IP address, netmask, and credentials required to access the VMControl hypervisor v the name of the post installation script to be run on the provisioned server ("postInstallScript" by default)
Procedure
1. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example "VMControl Cloud Pool 1". Set the hypervisor type to PowerHMC. 2. In the Resource Configuration section, in the Resource Pool Configuration tab, click the Define New Resource Pool button.
168
a. In the Define New VMC Resource Pool window that appears, enter a name for the new resource pool, for example "VMControl Resource Pool 1", and provide the name of the post installation script to be run on provisioned systems. You can leave the default name "postInstallScript" in this field. b. Click OK. 3. Click Save to save the newly created VMControl server pool. 4. Open the Hypervisor Manager tab. a. Click Define New VMC Server. b. In the window that appears, specify the name of the DCM server object to be created, the IP address, network mask, and credentials of the VMControl hypervisor. Important: A subnetwork is created automatically if no matching one exists in DCM. This can lead to problems because the IP address ranges of the automatically created subnetwork overlap with the ones that are loaded afterwards in the Cloud Network Configuration application. Problems can appear especially if the management network and the network of the managed VMs are the same or overlap. To avoid such a situation, load appropriate network DCM objects (using the Cloud Network Configuration application) before creating a cloud server pool. c. Click Save. d. Click VMControl Inventory Discovery to discover the VMControl hypervisor. Note: Import the SSL certificate of the VMControl hypervisor into the Websphere certificate store. Otherwise, the discovery workflow fails with a "No certificate found" error. e. Click Save. f. Click Refresh to check the current state of the discovery workflow. Note: "Success" indicates that this step is finished. If the workflow fails, you can open the Provisioning Workflow application and start the workflow manually. You can also open the Provisioning Workflow Status application to analyze the failed workflow. After the discovery, the VMControl inventory host platform computer or computers are created in DCM. They are not automatically added to the selected resource pool and must be added manually. 5. Open the Resource Pool Configuration tab again. a. Click Add VMC Host to add to the selected resource pool at least one host platform which has been discovered by the VMControl inventory discovery workflow. b. Click Save. The added host platforms are displayed in the Resources Overview section. You can use the Delete icon to remove hosts from the resource pool. 6. Review the values in the Provisioning Parameters tab and adjust them to your needs. 7. If you want to assign this cloud server pool to all customers, do the following: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?.
169
Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 8. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are greyed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 9. If the following error message is displayed during the validation: CTJZH2064E The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
Configuring cloud server pools for zVM

Learn to create and configure a zVM cloud server pool using DCM import XML files and the Cloud Server Administration application. zVM cloud server pool configuration: Read the following information before you proceed to configure a zVM cloud server pool. Almost all hypervisor types support two configuration modes: manual configuration using "Quick Define" operations and configuration with DCM import XML files. However, the configuration of a zVM cloud server pool can be performed using DCM import files only. Therefore, the configuration of a zVM cloud server pool consists of the following steps: 1. Customizing the DCM import files that are delivered with the Tivoli Service Automation Manager media: v v v v v v v 10_Cloud_Global_NetworkSettings.xml 13_Cloud_NetworkSettings_zVM.xml 23_0_Cloud_Bootserver_zVM.xml 23_1_Cloud_zLinuxImage_zVM.xml 23_2_Cloud_Vswitches_zVM.xml 33_Cloud_Pool_zVM.xml 42_Cloud_ITM_Agent_Linux.xml (if IBM Tivoli Monitoring is required)
2. Loading the customized DCM import files. 3. Creating a cloud server pool for zVM using the Cloud Server Pool Administration application. 4. Running the zVM discovery and enabling the cloud server pool. Collect the following information before you start configuring a cloud server pool for zVM: v Network settings (required during network configuration):
170
The management and customer subnetworks in 10_Cloud_Global_NetworkSettings.xml The virtual switch definitions in 13_Cloud_NetworkSettings_zVM.xml Mapserve zLinux host: Name of the mapserve host (usually named "mapsrv") that is defined in 23_0_Cloud_Bootserver_zVM.xml in the Hostplatform property value zLinux images: Configuration parameters of the zLinux master images that are defined in 23_1_Cloud_zLinuxImage_zVM.xml Virtual switch to host platform mapping: The switch names and their mapping to host platforms are defined in 23_2_Cloud_Vswitches_zVM.xml System z hypervisors (defined in 33_Cloud_Pool_zVM.xml) IP address, network mask of the hypervisor. SSH, and PING credentials for the hypervisor IP address, network mask, and SMAPI credentials for the vsmserve zVM machine which processes the dirmaint commands The following host platform configuration settings: - cpu.family = "s390" - cpu.size - cpu.type="64-bit" - memory.size - disk name and size
Configuring zVM cloud server pools in the Cloud Server Pool Administration application: Perform these steps to manually configure a zVM cloud server pool in the Cloud Server Pool Administration application. Before you begin See zVM cloud server pool configuration on page 170. About this task Procedure 1. In the Cloud Server Pool Overview tab, click Import DCM Objects and import the prepared DCM XML files. 2. In the Cloud Server Pool Details tab, click the New Cloud Server Pool icon. Specify a name for your new cloud server pool, for example "zVM Cloud Pool". Set the hypervisor type to zVM. 3. In the Resource Configuration section, in the Resource Pool Configuration tab, select the resource pool that was defined in and loaded with the DCM import file 33_Cloud_Pool_zVM.xml. 4. Click Save to save the newly created zVM cloud server pool. Verify that the host platform is listed as server in the Resource Pool overview. 5. Open the zVM Host Discovery tab. a. Click Select Value next to the Hypervisor Manager field and select the hypervisor computer loaded with the DCM import file 33_Cloud_Pool_zVM.xml.
171
b. Click Save. c. Click zVM Discovery to run the zVM host discovery. Push the Refresh button to see the updated workflow status. 6. Review the values in the Provisioning Parameters tab and adjust them to your needs. 7. If you want to assign this cloud server pool to all customers, do the following: a. Switch the main tab from Cloud Server Pool Details to Customers. b. Mark the box Assigned to all customers?. Such cloud server pool is shared by all customers and it is not necessary to assign it to individual customers in the Cloud Customer Administration application. 8. Click Validate and Enable Cloud Server Pool. Note: After validation, all input fields are greyed out and become read-only. Discoveries are not possible until the cloud server pool is disabled again. 9. If the following error message is displayed during the validation: CTJZH2064E The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
Using Data Center Model (DCM) files to configure cloud server pools
You can use the DCM XML files to easily create or configure a cloud pool.
Data Center Model (DCM) object templates

DCM global provisioning parameters and DCM objects are defined in XML files and then imported into Tivoli Service Automation Manager. A set of Data Center Model (DCM) object templates are delivered with the Tivoli Service Automation Manager installation DVD and copied to the management server during the installation. All of these XML and properties files must be copied and adapted to your environment. The default location is /etc/cloud/install/DCM. These files need to be customized by adding specific IP addresses, host names, and credentials for your environment. Note: Before you can customize Data Center Model object templates, you must have: v maxadmin rights. v access to the Tivoli Service Automation Manager installation DVD. v read-access for all files to be imported. The templates are structured as follows:
172
Important: The templates are prefixed with numbers, reflecting the order they need to be imported. CAUTION: Multiple imports of any DCM template are not supported and can lead to errors.
Template 10_Cloud_Global_NetworkSettings.xml 11_Cloud_NetworkSettings_VMware.xml Description Global file containing all network DCM objects. Hypervisor network configuration for VMWare. Virtual Switch Templates for Management and Customer network. Hypervisor network configuration for System P. Virtual Switch Templates for Management and Customer network. Hypervisor network configuration for z/VM. Virtual Switch Templates for Management and Customer network. Hypervisor network configuration for KVM. Virtual Switch Templates for Management and Customer network. Hypervisor network configuration for XEN. Virtual Switch Templates for Management and Customer network. Boot Server configuration for z/VM. Image definition of SLES10 for z/VM. VSwitch definition for z/VM. Cloud Pool Definition for z/VM. Contain software module definitions for the Tivoli Monitoring Agent required to install the monitoring agent on the provisioned virtual machine. Note: Before any Tivoli Monitoring Agent DCM object templates can be imported, the following data must be customized: network-interface name, IP address, netmask password-credentials.
12_Cloud_NetworkSettings_Systemp.xml
13_Cloud_NetworkSettings_zVM.xml
14_Cloud_NetworkSettings_KVM.xml
15_Cloud_NetworkSettings_XEN.xml
23_0_Cloud_Bootserver_zVM.xml 23_1_Cloud_zLinuxImage_SLES10_zVM.xml 23_2_Cloud_VSwitches_zVM.xml 33_Cloud_Pool_zVM.xml IBM Tivoli Monitoring Templates
41_Cloud_ITM_Agent_Windows.xml 42_Cloud_ITM_Agent_Linux.xml 43_Cloud_ITM_Agent_AIX.xml 44_Cloud_ITM_Agent_AIX_Linux_Windows.xml
In general, the customization of DCM object templates includes two configuration steps. Start with customizing 10_Cloud_Global_NetworkSettings.xml that is used regardless of the hypervisor type, then copy and configure the DCM objects that are specific for your hypervisor type. Each of these steps is described in more detail in the sections that follow.
173
Customizing Hypervisor Independent Data Center Model (DCM) items: Before you can configure your cloud pool objects, you need customize and import a couple of DCM items. Start with 10_Cloud_Global_NetworkSettings.xml that is used regardless of the hypervisor type. Procedure 1. Copy the 10_Cloud_Global_NetworkSettings.xml file from the /install/files/DCM directory on the Tivoli Service Automation Manager DVD to a local location. 2. Customize the 10_Cloud_Global_NetworkSettings.xml file: v Customize the Management Subnetwork:
Table 18. The Management Subnetwork customization: Property Name ipaddress netmask blocked-range PMRDP.Net.Gateway Description Update the IP Address according to your environment. Update the IP Address according to your environment. Update the IP Address according to your environment. Update the IP Address according to your environment or omit this property if no gateway is used. Update the IP Address according to your environment. Update the IP Address according to your environment or omit this property if no VLAN is required. Update the IP Address according to your environment or omit this property if no VLAN is required. The value has to exist if PMRDP.Net.VLANID is defined. It has to specify a unique PVID on your system p CEC. Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination. Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination.
PMRDP.Net.Broadcast PMRDP.Net.VLANID
PMRDP.Net.VLAN_PVID
PMRDP.Net.DefaultRoute.Destination
PMRDP.Net.DefaultRoute.NetMask
174
Table 18. The Management Subnetwork customization: (continued) Property Name PMRDP.Net.DefaultRoute.Metric Description Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination. Allows to specify the domain name for the hostname. It can be omitted if not used. Allows to specify the hostname prefix of the generated hostname for the LPAR.
PMRDP.Net.DomainName PMRDP.Net.HostnamePrefix
v Customize the Customer Subnetwork:

Table 19. The Customer Subnetwork customization: Property Name ipaddress netmask blocked-range PMRDP.Net.Gateway Description Update the IP Address according to your environment. Update the IP Address according to your environment. Update the IP Address according to your environment. Update the IP Address according to your environment or omit this property if no gateway is used. Update the IP Address according to your environment. Update the IP Address according to your environment or omit this property if no VLAN is required. Update the IP Address according to your environment or omit this property if no VLAN is required. The value has to exist if PMRDP.Net.VLANID is defined. It has to specify a unique PVID on your system p CEC. Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination. Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination.
PMRDP.Net.Broadcast PMRDP.Net.VLANID
PMRDP.Net.VLAN_PVID
PMRDP.Net.DefaultRoute.Destination
PMRDP.Net.DefaultRoute.NetMask
175
Table 19. The Customer Subnetwork customization: (continued) Property Name PMRDP.Net.DefaultRoute.Metric Description Allows to specify a single static route for your subnet . If the property is set, the following properties must be defined: PMRDP.Net.Gateway, PMRDP.Net.DefaultRoute.NetMask, PMRDP.Net.DefaultRoute.Metric and PMRDP.Net.DefaultRoute.Destination. Allows to specify the domain name for the hostname. It can be omitted if not used. Allows to specify the hostname prefix of the generated hostname for the LPAR.
PMRDP.Net.DomainName PMRDP.Net.HostnamePrefix
Customizing Hypervisor Dependent Data Center Model (DCM) items: After you have customized the hypervisor independent Data Center Model objects you need to configure DCM objects that are specific for the hypervisor type. Follow the instruction that applies to your hypervisor type. v VMware v PowerVM v z/VM v KVM Customizing Data Center Model (DCM) items for VMware: Customize the DCM templates prior to importing them to create a VMware hypervisor cloud pool. Procedure 1. Copy the 11_Cloud_NetworkSettings_VMware.xml file from the /install/files/DCM directory on the Tivoli Service Automation Manager DVD to a local location. 2. Customize the 11_Cloud_NetworkSettings_VMware.xml file:
Table 20. The 11_Cloud_NetworkSettings_VMware.xml file customization Property Name PMRDP.Net.VSwitchName Description Specify the name of the virtual switch on which the port group should be created, e.g. vSwitch0, vSwitch1, ...
Customizing Data Center Model (DCM) items for PowerVM: Customize the DCM templates before importing them to create a PowerVM hypervisor cloud pool. Procedure 1. Copy the 12_Cloud_NetworkSettings_Systemp.xml file from the /install/files/DCM directory on the Tivoli Service Automation Manager DVD to a local location. 2. Customize the 12_Cloud_NetworkSettings_Systemp.xml file:
176
v customize Systemp_SwitchTemplate:
Table 21. Systemp_SwitchTemplate customization Property Name PMRDP.Net.LinkTypeIEEE8023AD Description Specifies the type of either channel. If true, it is IEEE type. If false, it is CISCO type. The value is required if more than one Ethernet adapter is configured for the SEA. See property icname = The shared Ethernet adapter (SEA) requires a control session in a dual VIO mode. This value specifies the VLAN Id used for that. The value must be unique on the CEC and must match all other SEAs on the CEC if they function as servers to the same internal network. Note: Failing to configure this can lead to network outages due to an internal loop. Specifies the PVID for the adapter to be used for untagged traffic. This PVID must be unique on the CEC. All the untagged network traffic goes to this adapter. Specifies the VIO Set which should be used. The VIO Set is referenced by the symbolic name and must exist on all CECs which are part of the resource pool. Defines the device name on the VIO on which the shared Ethernet adapter or ether channel is created. There can be multiple entries in which case an ether channel is created. The PMRDP.Net.LinkTypeIEEE8023AD property is required in case of multiple entries.
PMRDP.Net.SEACtrlSessionVlanId
PMRDP.Net.UntaggedTrafficPVID
PMRDP.Net.VIOPairAlias
ic name=
Customizing Data Center Model (DCM) items for z/VM: Customize the Data Center Model (DCM) templates before importing them to create a z/VM hypervisor cloud pool. Procedure 1. Copy the following files from the /install/files/DCM directory on the Tivoli Service Automation Manager DVD to a local location: v 13_Cloud_NetworkSettings_zVM.xml v 23_0_Cloud_Bootserver_zVM.xml v 23_1_Cloud_zLinuxImage_SLES10_zVM.xml v 23_2_Cloud_Vswitches_zVM.xml v 33_Cloud_Pool_zVM.xml 2. Customize the 13_Cloud_NetworkSettings_zVM.xml file:
177
Table 22. The 13_Cloud_NetworkSettings_zVM.xml file customization Property Name PMRDP.Net.VSwitchName Description Specifies the name of the virtual switch on which the port group should be created. Defines the template port device number. This is the template value for all virtual servers which are created in turn. Defines the port device range and is set to 3 by default. For each VLAN used by z/VM the corresponding Tivoli Provisioning Manager VLAN needs to be defined. The vlan-number denotes the actual physical VLAN tag.
PMRDP.Net.zVM_NetworkPortDeviceNumber
PMRDP.Net.zVM_NetworkDeviceRange vlan name and vlan-number
3. Customize the 23_1_Cloud_zLinuxImage_SLES10_zVM.xml file: Note: When changing the XML attribute value on any of the following XML elements, you need to be aware of the links between Virtual Server Template, Software Stack, Image and Master Image. All these elements are linked by name. When changing one of the following values, all other values have to be changed as well before importing the file to DCM:
XML Element software-stack image virtual-server-template image image-library-master-image-entry XML Attribute Name name software-module image-stack-name name v name v image-software-stack-uniqueidentifier Value Software stack name, for example SLES10 GM OS for Minidisks Software stack name, for example SLES10 GM OS for Minidisks Software stack name, for example SLES10 GM OS for Minidisks Image name, for example SLES10 SP2 for Minidisks v Image name, for example SLES10 SP2 for Minidisks v Software stack name with additional reference data, for example [SLES10 GM OS for Minidisks]:[IBM]:[1.0]:[1]. Change the characters only within the first bracket.
Table 23. The 23_1_Cloud_zLinuxImage_SLES10_zVM.xml file customization Property Name zVM_Password zLinux_RootPassword Description The initial password for the provisioned z/VM guest. The initial password for the provisioned Linux root access.
178
Table 23. The 23_1_Cloud_zLinuxImage_SLES10_zVM.xml file customization (continued) Property Name Minidisk image definition section: zVM_Prototype Description Name of the z/VM prototype to be used for new z/VM guests, as defined during the z/VM backend setup phase. Name of the guest that owns the master image disk. A space separated list of disk device numbers to be cloned from the master image when provisioning a new guest. The device number of the disk that contains the Linux boot/root partition.
zVM_DiskOwnerId
zVM_CloneDisks
zVM_SystemDisk
4. Customize the 23_2_Cloud_Vswitches_zVM.xml file: Note: This file contains definitions of existing z/VM virtual switches. For each virtual switch template defined in the 13_Cloud_NetworkSettings_zVM.xml there must be one related object in this file.
Table 24. The 23_2_Cloud_Vswitches_zVM.xml file customization Property Name switch name Description The name of the virtual switch object that must match the PMRDP.Net.VSwitchName in the virtual switch template. The name of the mapserve server object that must match the mapserve names in 23_0_Bootserver_zVM.xml and 33_Cloud_Pool_zVM.xml.
host-platform property value
5. Customize the 33_Cloud_Pool_zVM.xml file: v Customize System z Pool: Note: The settings with "PMRDP.Net" suffix can also be configured in the Network Settings tab of the Cloud Pool Administration application.
Table 25. System z Pool customization Property Name PMRDP.Net.SubnetPool_0 PMRDP.Net.SubnetPool_1 Description Defines the first network adapter on the host and lists the existing subnetwork names. Defines the second network adapter on the host and lists the existing subnetwork names. It is omitted if a single network is sufficient. There can be multiple entries in the form PMRDP.Net.SubnetPool_x, where x is a number from 0 to the max number of network adapters supported by the hypervisor. Note: Having more than one entry with the same value is not supported. Defines the management network and contains the number from the end of the PMRDP.Net.SubnetPool_x property.
PMRDP.Net.ManagementNIC
179
Table 25. System z Pool customization (continued) Property Name PMRDP.Net.HostNameResolveNIC Description Defines the Network which is used to generate the host name of the LPAR via reverse DNS resolution on the Tivoli Service Automation Manager management node. It contains the number from the end of PMRDP.Net.SubnetPool_x property. Defines the list of name servers. Contains a comma-separated list of IP addresses. Defines the domain name server suffixes. Contains a comma-separated list of DNS suffixes.
PMRDP.Net.DNSServers PMRDP.Net.DNSSuffix
v Customize the mapserve server section in the System z Pool object:

Table 26. Customization of the mapserve server section in the System z Pool object Property Name NIC object(s) Description Defines the number of NICs on mapserve that limits the number of NICs on a provisioned server. Set the management flag on the Nic0 entry. Defines the IP address and netmask of the mapserve.
ipaddress and netmask in the network-interface section
username and password in the PING and Defines the user name and password needed to zVM SSH service access point (sap) access the mapserve (Linux root user) for the definitions respective protocols. username and password in the SMAPI service access point (sap) definition vmserve-address and vmserve-port CPU, disk.size and memory.size Defines the user name and password needed to use the system management API of z/VM. Defines the IP address and port of the z/VM host itself. Specifications of CPU, disk, and memory resources available for server provisioning. Note: Those values do not need to be set manually, as they are updated during the z/VM resource discovery.
Note: The 23_0_Cloud_Bootserver_zVM.xml file contains a template of a BootServer Tivoli Provisioning Manager object and does not need to be customized. Customizing Data Center Model (DCM) items for KVM: Customize the DCM templates before importing them to create a KVM hypervisor cloud pool. Procedure 1. Copy the 14_Cloud_NetworkSettings_KVM.xml file from the /install/files/DCM directory on the Tivoli Service Automation Manager DVD to a local location. 2. Customize the 14_Cloud_NetworkSettings_KVM.xml file:
180
Table 27. The 14_Cloud_NetworkSettings_KVM.xml file customization: Property Name Adapter name (ic name=) Description Specify the name of the network adapter for the management and customer network templates.
Importing Data Center Model (DCM) object templates

After customizing the appropriate DCM object templates for the hypervisor you plan to configure, import them into Tivoli Service Provisioning Manager.
Before you begin

You must have: v maxadmin rights. v customized the DCM object templates appropriate for the hypervisors you want to configure. v read-access for all files to be imported.
Procedure
1. Enter the Cloud Pool Administration application by clicking: Go To > Service Automation > Configuration > Cloud Server Pool Administration. 2. Click the Import DCM Objects... button. 3. Browse for and select all the DCM import XML files you customized. Important: Import the templates according to their prefix number, from the lowest to the highest.
What to do next
You can now proceed to configuring the cloud server pool.
Customizing cloud pool objects

As newly installed systems have no cloud pools present, you need to use the Tivoli Service Automation Manager Cloud Server Pool Administration application to create and configure cloud pool objects for them.
About this task

You can create a completely new cloud pool or use a preconfigured one. In both cases you need to customize it to your needs using the Cloud Server Pool Administration application. Work through all the sections in the Cloud Pool Details tab, then validate/enable the cloud pool to make it available for provisioning actions. The customization steps differ depending on hypervisor type, but there is one general procedure that is common for all of them:
Procedure
1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Configuration > Cloud Server Pool Administration. 2. Create a new cloud pool or select it from the Cloud Pool Overview tab that has been imported earlier.
181
3. Type the parameters in the Pool Configuration Parameters section. If the pool was imported from the properties file, a great number of the parameters has been already entered. 4. Create and configure host platforms (dependent on hypervisor type). 5. Discover the hypervisor manager to examine the back end and create appropriate objects in the Data Center Model. 6. Discover image templates that are to be used for the provisioning of servers. 7. Create Image Library Resources (only for VMware and LPAR hypervisor types). 8. Configure network parameters of the pool. 9. Validate and enable the pool. Note: In Tivoli Service Automation Manager 7.2.0, a vrpool.properties file, located in the /etc/cloud directory on the manager server was used for the administration of cloud server pools. Within version 7.2.1 and 7.2.2, it is only used for the import of preconfigured cloud server pools for and in the migration processes during the upgrade from version 7.2.0 to 7.2.1 or to 7.2.2. Remember: If you have installed the IBM Tivoli Monitoring server in your environment, you can configure Tivoli Service Automation Manager to include the monitoring agent installation when it provisions virtual machines using VMware. The configuration steps in the subsequent sections do not include the configuration required for including the monitoring agent. This configuration can be performed after completing the configuration of Tivoli Service Automation Manager for VMware by following the configuration steps described in Configuring the provisioning of the monitoring agent on page 216. 10. If the following error message is displayed during the validation: CTJZH2064E - The global provisioning property Cloud.RSAFile is not configured properly. Current value: __TIO_HOME_/keys/TSAM/identity, then the Cloud.RSAFile global provisioning property is generated but not customized. Perform the following steps to customize it: a. Log on to the administrative user interface and click Go to > Administration > Provisioning > Provisioning Global Settings. b. Open the Variables tab and in the field enter Cloud.RSAFile. c. Replace the string __TIO_HOME_ with the fully qualified path to the directory of the Tivoli Provisioning Manager management server, for example /opt/IBM/tivoli/tpm. d. Click Save.
What to do next
To finish the customization, follow the procedures that apply to your hypervisor type: v VMware v PowerVM v KVM v PowerVM with VMControl
182
Customizing a Tivoli Service Automation Manager cloud pool for VMware: A cloud pool needs to be configured prior to using it for provisioning virtual servers for VMware hypervisor. Before you begin It is required to have: v the maxadmin role. v the following data center model (DCM) import templates customized: 10_Cloud_Global_NetworkSettings.xml, 11_Cloud_NetworkSettings_VMware.xml. See Data Center Model (DCM) object templates on page 172 for more information. Procedure 1. Add the VMware server trust certificates to WebSphere Application Server. The VirtualCenter host certificate must be imported into the certificate store of the Tivoli Service Automation Manager management server. a. Stop the Tivoli Provisioning Manager:
su - tioadmin $TIO_HOME/tools/tio.sh stop <wasadmin> <wasadmin password>
b. Copy the following certificates to the Tivoli Provisioning Manager server, for example, to the path /tmp/SSL/. ESX server /etc/vmware/ssl/rui.crt or rui.cer vCenter server v 2003: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ *.crt or *.cer .
Windows Windows 2008: C:\ProgramData\VMware\VMware VirtualCenter\SSL.
c. Import the certificates: 1) Log on to the management server as root and set up the $JAV A_HOME variable as follows:
# export JAVA_HOME=/opt/IBM/WebSphere/AppServer/java/
2) Update the PATH environment variable and ensure that the keytool command is from the $JAVA_HOME/jre/bin directory.
# export PATH=$JAVA_HOME/jre/bin:$PATH
3) Change directories.
# cd $JAVA_HOME/jre/lib/security
4) Run the following command and, when prompted, answer "yes" to the question "Trust this certificate?":
keytool -import -v -trustcacerts -alias any-alias-name -file location-of-the-cert -storepass changeit -keystore cacerts
183
where any-alias-name can be the host name of the vCenter or the ESX server. For example,
keytool -import -v -trustcacerts -alias tpm711 -file /tmp/SSL/rui.crt -storepass changeit -keystore cacerts
d. As tioadmin, start the Tivoli Provisioning Manager:

su - tioadmin $TIO_HOME/tools/tio.sh start <wasadmin> <wasadmin password>
The certificate is now imported and communication with the VirtualCenter is possible. 2. Enter the Cloud Pool Administration application by clicking: Go To > Service Automation > Configuration > Cloud Server Pool Administration. 3. Import the customized data center model (DCM) templates: a. Click Import DCM Objects.... b. Browse for and select the DCM import xml files you customized: 10_Cloud_Global_NetworkSettings.xml, 11_Cloud_NetworkSettings_VMware.xml. Important: The templates must be imported according to their prefix number, from the lowest to the highest. 4. Create a new VMware Cloud Server Pool and execute all steps as described in chapter Manually configuring cloud server pools for VMware on page 160. Defining a new VMware virtual center: After you have successfully defined a VMware resource pool, use the Cloud Server Pool Administration application to define a new VMware virtual center. About this task It is necessary to perform this task in order to configure a new VMware cloud pool. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the Virtual Center Configuration tab. 3. Click Define New Virtual Center. 4. Enter the necessary information about the Virtual Center Properties, Virtual Center IP Details, and Virtual Center Login Details in the fields and click OK. Results A message is displayed that informs you about successful creation of the new virtual center. The object name of the newly created virtual center is displayed in the Hypervisor Manager field in the Cloud Server Pool Administration application.
184
Customizing a Tivoli Service Automation Manager cloud pool for PowerVM: A cloud pool needs to be configured before using it for provisioning virtual servers for PowerVM hypervisor. You must decide whether to use local partitionable disk from single VIOS or external SAN storage with the dual VIOS capability. Before you begin v This task can only be performed with maxadmin role. v Verify that you customized the following data center model (DCM) import templates: 10_Cloud_Global_NetworkSettings.xml, 12_Cloud_NetworkSettings_Systemp.xml. See Data Center Model (DCM) object templates on page 172 for more information. Note: By default, Tivoli Service Automation Manager resource reservation utilizes system memory up to 85% on System p back end hypervisor. The remaining 15% is the amount of memory reserved for the hypervisor firmware. For more information see Manually adjusting memory allocated to firmware. Procedure 1. Click Go To > Service Automation > Cloud Pool Administration The Cloud Pool Administration application opens. 2. Import the customized data center model (DCM) templates: a. Click Import DCM Objects.... b. Browse for and select the DCM import xml files you customized: 10_Cloud_Global_NetworkSettings.xml, 12_Cloud_NetworkSettings_Systemp.xml. Important: Import the templates according to their prefix number, from the lowest to the highest. 3. Create a new System p cloud server pool and perform all steps as described in chapter Manually configuring cloud server pools for System p on page 163. Manually adjusting memory allocated to firmware: For each particular CEC, you can manually adjust the amount of memory that is reserved for firmware. About this task By default, Tivoli Service Automation Manager resource reservation uses system memory up to 85% on System p back-end hypervisor. The 15% is the amount of memory reserved for the hypervisor firmware. The 85% value is rounded down to the next multiple of 256 MB. You can change this default setting manually by specifying the absolute amount of memory to be reserved for firmware for each particular CEC. The specified amount of memory is then considered to be allocated as hypervisor firmware memory and is subtracted from the total amount of system memory. The remaining memory is rounded down to the next multiple of 256 MB. Note: Tivoli Service Automation Manager does not read the size of the allocated firmware memory from the back end. Since this size is subject to change and it is influenced by the way LPARs are defined with respect to the definition and usage of the various virtual resources, the setting must be reviewed regularly.
185
Procedure For each CEC for which you want to change the memory setting, add the PMRDP.Power.Firmware.MemoryMB variable. The value of this variable must be integer and it must be specified in MB. To switch off the default memory handling to consider 15% of the built-in hypervisor memory, specify the parameter PMRDP.Power.Firmware.MemoryMB with a value of 0. If the parameter is a negative integer, the default behavior of subtracting 15% is used. Defining a new PowerVM resource pool: Use the Cloud Server Pool Administration application to define a new resource pool for the PowerVM hypervisor. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. In the Cloud Server Pool Details tab, create a new cloud server pool of the LPAR type. 3. Click Define New Resource Pool. A Define New Power VM Resource Pool window is displayed. 4. Enter the name of the new resource pool. 5. Click OK. Results A message is displayed that informs you about successful creation of the new resource pool. The name of the newly created resource pool is displayed in the Resource Pool Name field in the Cloud Server Pool Administration application. What to do next Perform this task. Defining a new HMC server: After you successfully created a resource pool, use the Cloud Server Pool Administration application to define a new Hardware Management Console (HMC) server. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the HMC Discovery tab. 3. Click Define New HMC Server. A Define New HMC Server window is displayed. 4. Enter the required information about HMC Server Properties, HMC Server IP Details, and HMC Server SSH Login Details in the fields. 5. Click OK.
186
Results A message is displayed that informs you about successful creation of the new HMC server. The name of the newly created HMC server is displayed in the HMC Computer Name field in the Cloud Server Pool Administration application. Note: v Pay attention to the discovery timeout value. The value depends on how many System p Central Electronic Complexes (CECs) are attached to the configured HMC. Specify the name of the System p CEC you want to discover in the CEC Name for Discovery (optional) field to reduce the time of the discovery. v CECs that belong to one resource pool are not required to be managed by one particular HMC. If more than one HMC is required to manage the CECs within one resource pool, the HMC discovery has to be invoked multiple times on respective HMCs. Then all CECs are discovered and are known in Tivoli Provisioning Manager. Each CEC has a property specifying the name of the HMC by which it is managed. Fail-over scenarios in which one CEC is managed by more than one HMC are not supported by Tivoli Service Automation Manager. What to do next Perform this task. Defining a new NIM server: After you have successfully defined a new HMC server, user the Cloud Server Pool Administration application to define a new Network Installation Management (NIM) server. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the NIM Discovery tab. 3. Click Define New NIM Server. A Define New NIM Server window is displayed. 4. Enter the required information about NIM Server Properties, NIM Server IP Details, and NIM Server SSH Login Details in the fields. 5. Click OK. Results A message is displayed that informs you about successful creation of the new NIM server. The name of the newly created NIM server is displayed in the Image Repository Host field in the Cloud Server Pool Administration application. What to do next Perform this task.
187
Defining a new boot server: After you have successfully defined a new NIM server, use the Cloud Server Administration application to define a new boot server. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the NIM Discovery tab. 3. Click Define New Boot Server. A Define New Boot Server window is displayed. 4. Enter the required information about Boot Server Properties and Boot Server IP Details in the fields. 5. Click OK. Results A message is displayed that informs you about successful creation of the new boot server. The name of the newly created boot server is displayed in the NIM Boot Server Name field in the Cloud Server Pool Administration application. Customizing the PowerVM VIOS network configuration for the CEC: As part of the cloud pool customization for PowerVM, you need to customize the VIOS network for the Central Electronic Complex (CEC). About this task Depending on the network configuration type used in your environment, perform one of the tasks described below. Default network configuration: For the default network configuration type with multiple NIC support enabled (global variable PMRDP.Net.MultiNicSupport is set), follow the instructions in this task. Procedure 1. Set the VIO server pair used for network virtualization management on all CECs assigned to the cloud pool. For every CEC: a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. Find the computer representing the CEC, and click it to open the configuration details. c. Select the Variables tab and click New Row to add a new variable. d. In Variable, type VIOS.SET.NET or VIOS.SET, depending on whether the VIO server pair is to be used only for network virtualization management, or both network and storage virtualization management. e. Select the Is Array? check box. f. Click Add New Value to add one or more lists of VIO servers, containing semicolon-separated values for: pair alias name; first VIOS name; second VIOS name. For more information, see Table 28 on page 189.
188
2. Set trunk priorities for network virtualization VIO servers. For each network VIO server: a. Click Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. Find the computer representing the VIOS, and click it to open configuration details. c. Select the Variables tab and click New Row to add a new property. d. In Variable, type PMRDP.Net.TrunkPriority. e. Set the value to trunk priority of the VIO server. This is a numeric value starting with 0, for example: 0, 1, 2,...) For more information about trunk priority, see Table 28. Example
Table 28. Customization of the VIOS settings for the discovered DCM objects and the System p VIOS configuration for the CEC server objects Property Name VIOS.SET Description The default array property that enables defining VIOS Sets on a CEC. It defines a VIOS Set used by Storage and Networking. Each entry in the array is composed of 3 values which are separated by a semicolon (;) : v The first value is a symbolic name. v The second value is the DCM name of the first VIOS n the VIOS Set. v The third value is the DCM name of the second VIOS in the VIOS Set. Optional for a single VIOS configuration. Example: test1;VIOS1;VIOS2. All defined VIOS Sets symbolic names must be equal and resolvable on all CECs in the resource pool. VIOS.SET.NET An array property that enables defining multiple VIOS Sets on a CEC. It defines a VIOS Set used exclusively by Networking. Each entry in the array is composed of 3 values which are separated by a semicolon (;) : v The first value is a symbolic name. v The second value is the DCM name of the first VIOS in the VIOS Set. v The third value is the DCM name of the second VIOS in the VIOS Set. Optional for a single VIOS configuration. Example: testnet1;VIOS3;VIOS4. All defined VIOS Sets symbolic names must be equal and resolvable on all CECs in the resource pool.
189
Table 28. Customization of the VIOS settings for the discovered DCM objects and the System p VIOS configuration for the CEC server objects (continued) Property Name VIOS.SET.SAN Description An array property that enables defining multiple VIOS Sets on a CEC. It defines a VIOS Set used exclusively by storage. Each entry in the array is composed of 3 values which are separated by a semicolon (;) : v The first value is a symbolic name. v The second value is the DCM name of the first VIOS in the VIOS Set. v The third value is the DCM name of the second VIOS in the VIOS Set. Optional for a single VIOS configuration. Example: testsan1;VIOS_5;VIOS_6. All defined VIO Sets symbolic names must be resolvable on all CECs in the resource pool. PMRDP.Net.TrunkPriority Defines the trunk priority used when virtual Ethernet devices are created. This value must be unique across the VIOS on a CEC.
Legacy network configuration: For legacy network configuration, with all pool components connected to one subnetwork, follow the instructions in this task. About this task Add the variable Cloud.Subnetwork to the Resource Pool to connect the Resource Pool with the management network VLAN ID: Procedure 1. Click Go To > Service Automation > Cloud Pool Administration. 2. Filter for the PowerVM cloud pool, and open it. 3. To open the resource pool configuration, in Resource Pool Name, open the detail menu, and select Go To Resource Pools. 4. Open the Variables tab. 5. Click New Row to add a new variable. 6. In Variable, type Cloud.Subnetwork. 7. In Value, type the name of the Tivoli Provisioning Manager subnetwork that corresponds to the management subnetwork.
190
Customizing a Tivoli Service Automation Manager cloud pool for KVM: A cloud pool needs to be configured prior to using it for provisioning virtual servers for KVM hypervisor. Before you begin You must have: v maxadmin role. v customized the following data center model (DCM) import templates: 00_Cloud_Global_Properties.xml, 10_Cloud_Global_NetworkSettings.xml, 14_Cloud_NetworkSettings_KVM.xml, 34_Cloud_Pool_KVM.xml. See Data Center Model (DCM) object templates on page 172 for more information. Procedure 1. Enter the Cloud Pool Administration application by clicking:Go To > Service Automation > Configuration > Cloud Server Pool Administration. 2. Import the customized data center model (DCM) templates: a. Click the Import DCM Objects... button. b. Browse for and select the DCM import xml files you customized: 00_Cloud_Global_Properties.xml, 10_Cloud_Global_NetworkSettings.xml, 14_Cloud_NetworkSettings_KVM.xml, 34_Cloud_Pool_KVM.xml Important: The templates must be imported according to their prefix number, from the lowest to the highest. 3. Create a new cloud pool for hypervisor type KVM: New Cloud Server Pool in the task bar. The Cloud Server Pool a. Click Details tab will display. b. Enter a Cloud Server Pool Name. c. Select a Hypervisor Type of KVM. d. Select a Resource Pool name in the Resource Pool Configuration tab. If you imported the default resource pool using the customized DCM files for KVM, the name is 'Bare Metal KVM Pool'. Note: As the imported cloud server pools have many parameters entered, it is recommended to use them instead of creating completely new ones. If you used the vrpool.properties to import the preconfigured KVM cloud pool, select it from the Cloud Pool Overview tab of the Cloud Server Pool Administration application. Save button to save your changes. e. Click the 4. Install the KVM boot server in the Boot Server Configuration and Image Discovery tab: a. Select the Target Computer by opening the detail menu and choosing 'Select Value'. b. Enter the Image Directory in which the new created server images will be stored. c. Click the Install Boot Server button. Refresh until the discovery finishes and a value is displayed in Status. 5. In the same tab, discover KVM images using the KVM Image Discovery section:
191
a. Select an Image Repository Host by opening the detail menu and choosing 'Select Value'. b. Click the KVM Image Discovery button. Refresh until the discovery finishes and a value is displayed in Status. 6. Optionally, define the file repository in the Additional Resources tab. 7. Configure the Save/Restore settings: a. Define the maximum number of virtual server images that can be created, or if an unlimited number of images is allowed. b. Specify whether the IP address which was assigned to the virtual server during provisioning should be blocked for the saved image and not used for new provisioning requests. c. Click the Define New Saved Image Repository button to create a new Saved Image Repository object. On the KVM Saved Image Repository panel, enter the name of the new repository, the computer that hosts the repository, and the path to which images will be saved. d. Click the Define New Instance Image Repository button to create a new Instance Image Repository object. On the KVM Instance Image Repository panel, enter the name of the new repository. 8. Create a KVM host using the Host Platform Configuration tab: a. Enter the IP address, MAC address, Network Mask, and Password for the KVM host. Save the changes. b. Click the Create KVM Host button. Refresh until the discovery finishes and a value is displayed in Status. 9. Validate and enable the cloud server pool: a. Select the Cloud Server Pool Details tab. b. Under the Cloud Server Pool Name and Type section, click the Validate and Enable Cloud Server Pool button. They system will verify that the necessary configuration parameters were set and that all workflows were run and completed successfully. Save button. c. Enable the cloud server pool by clicking the 10. Review the object references in the Resources Overview section and the variables in the Resource Pool tab. Note: The object references and variables are set during the 'Validate and Enable' action. Changes that you make in the cloud server pool configuration (for example, select a different Resource Pool, Hypervisor Manager, Image Repository Host, File Repository, or change the network configuration) will not become active until you click the Validate and Enable Cloud Server Pool button after the changes are made. Defining a new KVM resource pool: Use the Cloud Server Pool Administration application to define a new resource pool for the KVM hypervisor. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. In the Cloud Server Pool Details tab, create a new cloud server pool of the KVM type.
192
3. Click Define New Resource Pool. A Define New KVM Resource Pool window is displayed. 4. Enter the name of the new resource pool in the Resource Pool Name field and specify the path of the VM image in theVM Images Location field. 5. Click OK. Results A message is displayed that informs you about successful creation of the new resource pool. The name of the newly created resource pool is displayed in the Resource Pool Name field in the Cloud Server Pool Administration application. What to do next Perform this task. Defining a new KVM image server: Use the Cloud Server Pool Administration application to define a new image server for the KVM hypervisor. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the Image Template Discovery tab. 3. Click Define New KVM Image Server. A Define New KVM Image Server window is displayed. 4. Enter the required information about KVM Image Server Properties, KVM Image Server IP Details, KVM Image Server SSH Login Details, and KVM Image Server SCP Login Details in the fields. 5. Click OK. Results A message is displayed that informs you about successful creation of the KVM image server. The name of the newly created image server is displayed in the Image Repository Host field in the Cloud Server Pool Administration application. What to do next Perform this task. Defining a new KVM file repository: After you have successfully defined a KVM image server, use the Cloud Server Pool Administration application to define a new file repository for the KVM hypervisor. Procedure 1. To open the Cloud Server Pool Administration application, log on to the administrative user interface and click Go To > Service Automation > Cloud Server Pool Administration. 2. Open the Additional Resources tab.
193
3. Click Define New File Repository. A Define New KVM File Repository window is displayed. 4. Enter the required information about KVM File Repository Details and KVM File Repository IP Details in the fields. 5. Click OK. Results A message is displayed that informs you about successful creation of the file repository. The name of the newly created file repository is displayed in the File Repository Name field in the Cloud Server Pool Administration application. Customizing a Tivoli Service Automation Manager cloud pool for IBM Systems Director VMControl: Before you can use a cloud pool to provision virtual servers for the IBM Systems Director VMControl hypervisor, the cloud pool must be configured. Before you begin To configure the cloud pool, you must have the maxadmin role. Also, customize the following data center model (DCM) import templates: 10_Cloud_Global_NetworkSettings.xml. See Data Center Model (DCM) object templates on page 172 for more information. About this task You use this task to add the VMControl server certificate to WebSphere Application Server. Procedure 1. Log on as tioadmin and run tio.sh stop to stop Tivoli Provisioning Manager. 2. Copy the keystore file to the Tivoli Provisioning Manager server, for example to the path /tmp/SSL/. VMControl server: /opt/ibm/director/lwi/security/keystore/ibmjsse2.jks 3. To import the certificates: a. Log on to the management server as root and set up the $JAV A_HOME variable as follows:
# export JAVA_HOME=/WAS_HOME/IBM/WebSphere/AppServer/java/
b. Update the PATH environment variable so that it includes the $JAVA_HOME/jre/bin directory to ensure that the proper keytool command is run.
# export PATH=$JAVA_HOME/jre/bin:$PATH
c. Change directories to:

# cd $JAVA_HOME/jre/lib/security
d. Run the following command and when prompted, answer "yes" to the question "Trust this certificate?"
194
keytool -export -alias lwiks -storepass ibmpassw0rd -file client.cer -keystore <location of ibmjsse2.jks in TPM server> keytool -import -v -trustcacerts -alias lwiks -file client.cer -storepass changeit -keystore cacerts
4. As tioadmin, run tio.sh start to start Tivoli Provisioning Manager. The certificate is now imported and communication with VMControl is possible.
cd $TIO_HOME/tools ./tio.sh stop ./tio.sh start
5. Create a new VMControl Cloud Server Pool and execute all steps as described in chapter Manually configuring cloud server pools for VMControl on page 168.
Configuring PowerVM SAN disks for VIOS support using MPIO

Both single and dual Virtual I/O server (VIOS) environments can be configured on System p.
About this task

Note: System p Blade environment has one integrated virtual management console (IVM) for each blade which is a part of a single VIO server. Multi path I/O (MPIO) is only possible on Fibre Channel adapter cards. Important: If you want to use SAN storage in a System p environment, first install the SDDPCM driver with equivalent version on all involved VIO servers and purge all LPARs to enable PVID identification of the configured disks. Install the SDDPCM driver version 2.5 or greater. This is done independently if SAN Volume Controller is used to map the SAN storage volumes as disks. The interface to query storage capabilities is not standardized and even the returned values are different. Therefore, the disks to be used by Tivoli Service Automation Manager have to be connected to the VIO Server by using the SDDPCM driver.
Planning for SAN storage

By configuring pre-allocated SAN disks you can connect to a virtual I/O server (VIOS) and be storage vendor independent. You need to define the size of the pre-allocated disks as only the root volume group (rootVG) will be created on a single SAN disk. The size must encompass the operating system itself, swap space and additional space for typical applications to located in the rootVG. Check your AIX master image sizes and requirements to determine disk size requirements. SAN disks must be mapped to all VIOS sets (each of which can consist of one or two VIO-servers) or selected VIOS sets defined by a unique alias. The alias is a symbolic name for the group to be served by a selected VIOS set. Ensure that you have reservation_policy=no_reserve while backing the SAN disks to the VIOSs. If more than one host platform (the pFrame or System p CEC) are part of a resource pool and sharing a SAN disk in a storage pool, none of the host platforms should be assigned to a different resource pool through shared disks, as the storage volume identifiers are unique and cannot exist in different storage pools. To enable VIOS grouping using an alias, the user interface needs to be extended to pass the variable PMRDP.Systemp.VIOS.SET.alias as a key with the user interface selected value to PMRDPVSTPARM. See the "REST API reference" section for more
195
information. The SAN disk used to connect to VIOS sets with an alias must not be connected to other VIOS sets dependent on a different alias group. Tip: In cases where more disk space is required by an additional SAN disk for other data usage, the post user exit can be used to map such additional disks to the provisioned LPAR. To identify whether storage volumes in the storage pool are available, the physical volume identifier (PVID) is used. During discovery, each storage volume disk is assigned a PVID if it is not already allocated. Note: For SAN disk attachments that can be reached via different access paths (multi path IO), Tivoli Service Automation Manager configures each access path to a particular SAN disk with a default value 1. If a particular SAN environment requires a different setup, the local administrator must ensure proper configuration, for example by use of AIX first boot scripts.
Enabling VIOS support

Set the variable PMRDP.Systemp.dual.VIOS.support to true in the Cloud Server Pool Administration application to enable VIOS support.
Before you begin

All pre-system setup steps should be performed. Note: Some configurations described here may have already been set through the import of pre-configured DCM XML files or the Cloud Pool Administration application.
Procedure
1. Click: Go To > Service Automation > Configuration > Cloud Server Pool Administration. 2. Select the System p cloud server pool for which you want to enable VIOS support. 3. Switch to the tab Host Platform and VIOS Configuration. 4. Mark the check box SAN Storage / Multiple VIOS Mode.
What to do next
Configure the VIOS sets for storage mapping.
Configuring cloud networks

Configure your network by performing this sequence of tasks.
Before you begin

Familiarize yourself with the Planning the network configuration on page 110 section of this documentation and make sure that you know which network scenario you want to implement. Important: For VMware, if you make any changes in the virtual center, you must run the Tivoli Service Automation Manager virtual center discovery again so that all the networking changes can happen in Tivoli Provisioning Manager Data Center Model. If you change the switch names, you must also update the switch
196
names in the virtual switch templates in which the old switch names were used.
Setting up the network related Data Center Model (DCM) objects

Learn how to create two types of DCM objects.
Procedure
Create two types of DCM objects necessary for network configuration: v Subnetwork: Defines Layer 3 configuration of a network interface within the deployed operating system. v Switch: Defines Layer 2 connectivity of the network adapter within a virtual machine to the hypervisor virtual switches. A set of sample DCM import files for hypervisors and resources is provided with Tivoli Service Automation Manager:
Table 29. Sample Data Center Model import files. 10_Cloud_Global_NetworkSettings.xml Defines subnetworks for the management and customer network. 11_Cloud_NetworkSettings_VMware.xml Virtual switch template for VMware. 12_Cloud_NetworkSettings_Systemp.xml Virtual switch template for System p. 13_Cloud_NetworkSettings_zVM.xml Virtual switch template for z/VM. 14_Cloud_NetworkSettings_KVM.xml Virtual switch template for KVM. 15_Cloud_NetworkSettings_XEN.xml Virtual switch template for XEN.
For a subnetwork For a switch
Important: These DCM files are just templates. Modify them for your environment before you import them. Related concepts Definitions for DCM objects on page 134 Lists the definitions for DCM objects involved in the network support configuration.
Defining network segment usage values

By defining network segment usage values, you can map network segments onto resource pools and specific images, and distinguish between network interfaces of the same kind.
About this task

Network segment usage values are customer-definable attributes. The following list contains the scenarios that you can realize: v Mapping network segments onto resource pools. v Mapping network segments onto specific images.
197
v Distinguishing between network interfaces of the same kind.
Procedure
1. Log on to the administrative user interface. 2. Select Go To > System configuration > Platform configuration > Domains to access the application that helps you to create and modify network segment usage values. 3. Modify the PMZHBNETSEGUSAGE domain and save the changes.
What to do next
The following section contains example scenarios that show how you can use network segment usage values.
Network segment usage values

Network segment usage values can be modified and added using the Domains application, by modifying the PMZHBNETSEGUSAGE domain. Values entered in this domain are displayed in the self-service user interface after saving and performing a refresh. Note: You must enter network segment usage values before you import the network template that is using them. The values are used in: v Network segment definition v Image registration With network segment usage values, you can further restrict the results of the image to network configuration resolution during the Create Project and Add Server requests. The following algorithm is used during network configuration: v For each network interface defined on the deployable image, the algorithm checks whether network segments of the same type are available. If they are available, a network segment is displayed on the list of network segments possible for the given network interface of the image. v If a network usage value is defined on the image, only those network segments are displayed that have at least one of the usage values of the image. Three kinds of scenarios can be realized on the basis of the algorithm. Choose which scenario you want to implement.
Relating an image to a hypervisor-specific network configuration

Perform these steps to map an image onto a hypervisor-specific network configuration resource pool.
Procedure
1. Define a usage value and name it after the resource pool that you want to use. An example of such a value is ESXPool. 2. During image registration, select the usage value you have defined for each required network interface. 3. In the network template, define a set of network segments that contain the Usage tag with your chosen value. When the image is deployed, only those network segments are shown in the self-service user interface that have the defined usage tag.
198
Defining a specific network configuration for a class of images

Follow these steps to map a network configuration to a set of images.
Procedure
1. Define a usage value and name it after the operating system type of the image. An example of such a value is Windows. 2. During image registration, select the usage value you have defined for each required network interface. 3. In the network template, define a set of network segments that contain the Usage tag with your chosen value. When the image is deployed, only those network segments are shown in the self-service user interface that contain the defined usage tag.
Distinguishing between network interfaces of the same type

Follow these steps to map two customer networks onto different network segments. This scenario is helpful if you have multiple customer networks that have some special meaning in your setup.
Procedure
1. Define two usage values, for example FrontendNetwork and BackendNetwork. 2. Select the FrontendNetwork value for the first customer network interface. 3. Select the BackendNetwork value for the second customer network interface. 4. In the network template, define the network segments that contain the Usage tag specified with your chosen value. When the image is deployed, only those network segments are shown in the self-service user interface that contain the defined usage tag. With this approach, you can distinguish between multiple network segments that have the same type (for example Customer) but have different meanings in your setup.
Results
When the virtual machine is provisioned, both customer network interfaces have different network configurations.
Creating a network template

Learn how to create network templates so that you can assign network resources to customers.
About this task

A network template is the main network artifact that enables you to assign network resources to customers. It is an XML document that conforms to the Tivoli Service Automation Manager schema. A set of sample network templates and a network template schema are available on the installation media in the following location: \install\files\ NetworkConfigurations:
199
Table 30. Sample network templates and network template schema. XML schema file Sample network templates
PMZHB_SingleNicNetworkTemplate.xml PMZHB_NetworkConfiguration.xsd This file validates This network template defines a single Network network Interface Card (NIC) scenario with one management templates. network. It uses the DCM definitions provided with the product. PMZHB_DualNicNetworkTemplate.xml This network template defines a dual NIC scenario with one management network and one customer network. It uses the DCM definitions provided with the product.
Note: Both examples are bound to the subnetwork definitions provided in the DCM network samples. The templates have sample data for the DNS configuration. Modify the DNS section and update the DNS configuration before you import the network template. To create a network template:
Procedure
1. Create a network configuration section. 2. Define at least one network segment that contains one subnetwork definition. 3. Define a DNS configuration with one server IP address and one domain entry. An example for such configuration is SingleNicNetworkTemplate.xml. Note: Network template schemas contain additional data types and entities that are available for extensibility scenarios. It is not necessary to set them for a standard Tivoli Service Automation Manager network configuration. The following sections of a network segment are optional: v Define a DNS configuration with one server IP address and with one domain entry v Additional subnetwork definitions The network template schema contains additional data types and entities which are available for extensibility scenarios. If you use network segment usage values in the network template XML file, enter them in the domain (PMZHBNETSEGUSAGE) before you import the network template. Otherwise, an error message is displayed saying that the network segment usage values could not be found. Remember: v Network segment names must be unique within a network template. v Subnetwork names must be unique within a network segment. v If network segment usage values are used, they must be registered in the PMZHBNETSEGUSAGE domain. v If DCM references are specified, check if the referenced DCM object exists once. remember to check the following references: Subnet maps to the DCM subnetwork VLAN to the DCM VLAN Gateway and DNS maps to the provisioning computer system (server)
200
Related concepts Network templates on page 111 A network template defines the network resources that are available to a customer. Network schema on page 357 The network schema is an xsd file that defines the XML tags and the values supported for these tags that can appear in network configuration XML files.
Creating a customer and assigning a network template

Create a customer using the Create Customer offering.
About this task

The Create Customer offering is the only time during the customer on-boarding process when you can specify a network template for the customer. When running this offering, you can use a menu to select a single active network template and assign it to the customer that is created. A network template must be selected at this time. During the Create Customer workflow, a customer network instance is created. The Cloud Network Administration application shows these instances and helps you to modify them for an individual customer. Perform the following steps to create a new customer:
Procedure
1. Log on to the administrative user interface. 2. Click Go to > Service Automation > Configuration > Cloud Customer Administration to open the Cloud Customer Administration application. 3. Click New Customer on the toolbar and specify the required information.
Configuring distributed virtual switches

Use the distributed virtual switch feature available in VMware vSphere 4 to create port groups and connect the virtual machines to them during the provisioning process.
Before you begin

VMware distributed virtual switches (vDS) provide additional features over the earlier virtual standard switches, for example private VLANs. In some cases it is also easier to use and maintain distributed virtual switches than virtual standard switches. After you provide the correct input in the configuration DCM files, Tivoli Service Automation Manager creates a port group based on the configuration present in the associated switch templates. Before setting up this kind of configuration, make sure that: v The VMware cluster used for the resource pool is configured and compatible with the distributed virtual switches feature. v The VMware backend environment is configured accordingly with the distributed virtual switches. v The VMware switch template objects in the administrative user interface, for example VMSwitchTemplate1, are updated according to the new distributed
201
virtual switches parameters or that the 11_Cloud_NetworkSettings_VMware.xml DCM XML file is edited for the same purpose. For more information about the file, see Customizing Data Center Model (DCM) items for VMware on page 176. v The names used for the virtual standard switches are not reused in the distributed virtual switches. Use different bridge name prefix values. To prevent this kind of configuration error, a suffix is added to the generated distributed virtual switch name, in addition to the prefix. The configuration can be performed in two different ways.
Procedure
v Modify the virtual switch template object already created and configured for VMware in the administrative user interface. 1. Log on to the administrative user interface. 2. Click Go To > IT Infrastructure > Provisioning Inventory > Switches. 3. Click the Variables tab. 4. Add the new distributed virtual switches parameter with the correct values, as mentioned in the 11_Cloud_NetworkSettings_VMware.xml DCM XML file. Save Switch. 5. Click v Edit the 11_Cloud_NetworkSettings_VMware.xml DCM XML file. A new section of properties is added in the file:
                    
1. According to your needs, enable the properties by removing the comment tags  where necessary. 2. Save the file. 3. Import the file during the configuration procedure. You can do it in two ways: using the Cloud Network Administration application (recommended) using the Cloud Server Pool Administration application When you run the Create project request or the Add server request, you can see a successful provisioning of the virtual machines connected to port groups created on the distributed virtual switch. If the port group on the distributed virtual switch is not present, a new port group is created for the virtual machine to connect to.
202
Configuring cloud storage pools

After the cloud server pools are already defined, use the Cloud Storage Pool Administration application to create new cloud storage pools.
About this task

A Tivoli Service Automation Manager cloud storage pool is a collection of storage resources for additional disks. It is associated with a Tivoli Provisioning Manager storage pool. When creating a new project, you can select a server image and set only the size of the local disk. Cloud storage pools are a flexible solution to add additional storage to your provisioned servers. They can be customized for different environments individually. When adding additional storage to your servers, you have two main options: Add additional disks (mapped storage) In this type of cloud storage pool, an additional disk or disks are created on the virtual server in the form of logical units (LUNs). They are managed by hypervisors, they are associated with the virtual server, and their lifecycle depends on the server. Such disks can be added during provisioning of virtual servers. Note: Adding additional storage in form of an additional disk using a cloud storage pool is only supported for the System p hypervisor. Add additional file systems (mounted storage) In this type of cloud storage pool, additional file systems are created that are independent of the virtual server. One or more file systems can be shared between several virtual servers. The file system is mounted to the virtual server at the time of provisioning.
Configuring cloud storage resources

Create and configure new cloud storage pools to enable additional storage on your provisioned servers.
Before you begin

Log on to the administrative user interface. Open the Cloud Storage Administration application by clicking Go to > Service Automation > Configuration > Cloud Storage Pool Administration.
Procedure
1. Click the New Cloud Storage Pool toolbar button 2. Provide the required parameters for the new cloud storage pool: v Name v Description (optionally) v Storage manager type (LPAR is the only type supported by default. Other storage manager types are available as extensions.) v Storage type Use the Select Value icon to display a list of available storage types and storage extension types. The two available storage types are: v Mapped Additional Disks
203
v Mounted Disk Resources Note: The default storage type for LPAR is Mapped Additional Disks. Mounted storage is supported by storage extensions. 3. In the Associated TPM Storage Pools section, click New Assignment to create a storage pool table entry. Select one Tivoli Provisioning Manager storage allocation pool object. Note: If there are no storage allocation pools listed in the table, most probably storage discovery was not run. To run storage discovery, open the Cloud Server Pool Administration application, select an available System p cloud pool, and run the discovery from the Storage Discovery tab. 4. Switch to the Security Settings tab and specify the required information there. For more information, see Setting up purging options for storage disks on System p. 5. Click Validate and Enable Cloud Storage Pool. Note: After the cloud storage pool is enabled, the configuration input fields become greyed out and read-only. You must disable the cloud storage pool before performing any configuration tasks again.
Results
The cloud storage pool is created and ready to be assigned to a customer.
Setting up purging options for storage disks on System p

There are several ways in which you can purge the storage disks that you do not use any more.
About this task

When you create a new cloud storage pool in the Cloud Storage Pool Administration application, there are three possible choices for purging the disks to make them available for next usage.
Procedure
1. Log on to the administrative interface and click Go to > Service Automation > Configuration > Cloud Storage Pool Administration. 2. Switch to the Cloud Storage Pool Details section. In the Security Settings tab, you have the following disk purging options available: v No purging - Files in the additional disk are removed using the operating system functionality (rm -rf <mount point>) and the disk is returned to the storage pool immediately after the end of this operation. v Synchronous purging - Data on the additional disk is removed first and afterwards it is overwritten one time using dd if=/dev/zero of=/dev/rhdisk1 bs=1m. v Asynchronous purging - The same procedure is run as in the case of No purging and the disk is unmapped right after it, however it remains in the IN_USE state. A purge workflow purges the data as in the case of the Synchronous purging option and the storage volume state is set to AVAILABLE. With asynchronous purging, it is necessary that you define the LPAR to which all the data disks are mapped so that the storage volume that
204
is to be purged can be identified. This option removes the time constraint for the processes to delete, remove, or cancel because of the time consuming processing. Note: A dedicated disk purging host must be selected if the disk purging mode is set to Asynchronous. This host performs the purge operation after the project is cancelled and the storage is about to be returned. In the Synchronous mode, the provisioned server itself purges the disk. Note: Set Cloud pSeries HostPlatform Storage as the host platform device model in the Cloud Server Pool Administration application. This device model contains the definition of the additional capabilities in the form of the CloudStorage tcdriver (an automation package) that consists of workflows that handle operations such as adding and removing storage, creating volume groups, creating file systems, and purging disks. 3. Specify a timeout in minutes per GB to be erased. 4. Specify the storage identification type in the box. The selection defines how the storage resources are identified. They are identified by the Unique Device Identifier (the default option), by the IEEE Volume Name, or by the Physical Volume Identifier (PVID). Important: If an error occurs during purging and you choose the Ignore or Skip option, the disk remains in the state IN_USE and is not available for any other project. If the purging process fails because of an error, clean the storage volume manually and set it to state AVAILABLE.
Purging LPARs
A purging LPAR is a virtual server that makes the purging process more efficient. Purging of storage disks is a time-consuming task because it involves overwriting the disk content to make it invalid. To shift the purging effort from the servers in a resource pool, configure a server outside of the configured resource pool to run the asynchronous purging tasks. Such server is called a purging LPAR. It is built similarly to a VIO server and requires the following components: v A dedicated Fibre Channel adapter to enable SAN disk mapping. v An equivalent AIX level. v A storage driver (SDDPCM) of the same level as installed on the server pool VIOS version. Use SDDPCM driver version 2.5 or greater. Do not use the standard AIX commands because the returned values while finding the disk device identifier on different LPARs depend on the storage driver and the storage subsystem. For IBM storage systems, for example DS8000, Unique Device Identifier is used in this implementation. Other storage systems might use IEEE Volume Name or Physical Volume Identifier (PVID) to identify unique storage devices. Note: In the storage pools created by the storage pool discovery, the physical volume identifier (PVID) is used to discover the disk for MPIO. However, in this case only VIOS are in use to identify the disks that are to be mapped to the client LPAR. If disks are mapped directly to a client LPAR, as is the case with the purging server, PVID cannot be used to identify a unique disk device.
205
For performance reasons, each storage pool can have an individual purging LPAR configured.
Considerations for asynchronous purging

Purging of storage actually involves overwriting the whole disk with invalid content in order to make it impossible to reconstruct the file system content. In the additional storage for System p extension, a simple solution is used to achieve this result. A command is run that overwrites the whole disk with zeros. This method makes it difficult to restructure the file system content but cannot guarantee full security. Purging is a time-consuming process. For asynchronous purging, the processor and memory resources are given back quickly but the additional storage resources remain in the IN USE state until the operation is finished. If case of large amounts of disk space that is to be purged, it might be necessary to set a higher timeout value for the process. To save the purging effort, you can set up the operating system to encrypt data on additional storage and set purging to None. Such encryption reduces the I / O throughput to some extent but the time required for purging is saved and the storage resource can be quickly used again. As a System p user who uses the additional disk feature, you must judge all aspects like resource consumption, time, and level of security and decide which purging option is best in your case.
Changing the default purging configuration

Perform this task if you want to set up a purging process other than the default one.
About this task

Using a dedicated LPAR for the purging process is not always the optimal solution and depends on the used storage subsystem. Different storage subsystems might be able to purge storage space more efficiently. This is why you might want to overwrite the implementation of Hostplatform.FindStorageDevice and Hostplatform.PurgeStorage workflows in the CloudStorage automation package. The storage device can also offer better methods for the purging algorithm. Therefore, the implementation to identify the storage device is modeled as a logical device operation (LDO) implementation and can be changed for customer-specific reasons. The name of the logical device operation is Hostplatform.FindStorageDevice. The way in which different storage subsystems and different drivers are identified can be changed depending on what subsystems and storage drivers are used. For multi path I/O (MPIO) devices, a key is required to identify the disk device.
Procedure
1. Create a new Tivoli Provisioning Manager automation package that depends on the CloudStorage automation package (tcdriver). 2. Create your own implementation for Hostplatform.FindStorageDevice. Remember to check whether PMRDP.SAN.disk.identifier.attriubute property does not need a different identifier attribute. 3. Create your own implementation for HostPlatform.PurgeStorage.
206
4. Install your automation package. 5. Use the Cloud Server Pool Administration Application to associate the new device model to all host platforms in your server pool.
Storage resources
Remember about the following points when saving or restoring projects with additional storage attached to them. v During the Create Server Image workflow, only the boot disk data is saved. The additional data is not saved. v Similarly, during the Restore Server from Image workflow, only the boot disk data is restored. The additional data is not restored as it was not saved. v During the Create Project from Saved Image and Add Server from Saved Image workflows, only the boot disk data is restored. A new LUN is then attached to the virtual machine for additional disks that were attached to it during Save. For example, if a virtual machine had two additional disks of 20 GB and 30 GB attached to it when it was saved, then when the machine is recreated during the operations, two empty 20 GB and 30 GB LUNs are attached to it.
Configuring the service provider and customer features

Even if you are not planning to use the service provider functionality, you need to perform some basic configuration steps to make the default customer operational.
Assigning resources to the default customer

You need to assign at least the cloud server pool and a master image to the default customer PMRDPCUST to make this customer operational.
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 279. Network resources cannot be shared between customers.
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.
207
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 Go To Master Images. Detail Menu >
Detail Menu > Go To Software Stacks. b. Next to the software stack click 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. Return to return to the Cloud Customer Administration d. Click Application. e. In the Software Modules tab, assign the software stack corresponding to the image to the customer. f. Save the changes.
What to do next
When the resources are assigned to the default customer, you need to activate this customer in the self-service user interface. Proceed to Activating the default customer PMRDPCUST.
Activating the default customer PMRDPCUST

Even if you are not planning to use the service provider functionalities, at least one customer, the default PMRDPCUST must be activated. If you do not activate this customer, you are not able to access any offerings in the self-service user interface.
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 has been defined in the Cloud Network Administration application. v Master images have been discovered in the Image Library. v Server resources and master images have been assigned to the PMRDPCUST customer.
About this task

The first time you log in to the self-service user interface, you will only see one request available: Create Customer. You need to use this request to activate the already existing default customer PMRDPCUST.
208
Procedure
1. Log on to the self-service user interface as PMRDPCAUSR. 2. In the Home panel, click Request a New Service > Virtual Server Management > Manage Customers > Create Customer. 3. Specify the network template. 4. Click OK to submit the request. 5. Refresh the browser.
Results
You should now be able to see all offerings. You can register the images and then create new projects.
Configuring the interface to Workload Deployer

Learn how to configure IBM Workload Deployer to enable its use within Tivoli Service Automation Manager and provision projects based on Workload Deployer patterns.
Procedure
1. Define the Workload Deployer as a provisioning computer in Tivoli Provisioning Manager: a. Select Go To > IT Infrastructure > Provisioning Inventory > Provisioning Computers. b. Click the Add Computer icon, or select Add Computer in the Select Action menu. c. For Computer, specify the Workload Deployer host name, for example wcahostname.ibm.com. Click Save. 2. Create a network interface for the Workload Deployer: a. Click Hardware tab. b. Click New NIC Resource. c. Click Network Interface tab. d. Click New Network Interface. e. Specify the Network Interface name, for example WCA Network Interface. f. Specify the IP address of this interface, which must be the IP address of the Workload Deployer host name. g. Select the Management check box. A message box opens and asks whether changes are to be saved. Click Yes. 3. Specify credentials for surrogate user authentication at the Workload Deployer: a. Click the Credentials tab. b. Click Add Credentials. c. Select New Service Access Point. d. Specify the Service Access Point name: WCA HTTPS. e. In the Protocol Type list, select Network protocol IP. f. In the Application Protocol list, select HTTP Secure Access. g. Select Port if the default port 443 is not sufficient. h. Click New Password Credential. i. Specify Search Key as master.
209
j. Specify User Name. This user must be defined on the Workload Deployer with administrator privileges. k. Specify and confirm password. Click Save. l. Select the Default Credential check box and click Save. 4. In the Variables tab, add variable X-Cloudburst-API-Version and set its value to 2.0.0.2 5. Discover the Workload Deployer hardware. Workload Deployer patterns are deployed into cloud groups, which are pools of homogeneous servers hosting the virtual machines that belong to such a virtual system. Currently, a pool can consist of one or more ESX or ESXi hypervisors. A cloud group discovery is required to make Tivoli Provisioning Manager aware of the cloud groups defined on Workload Deployer. At the same time, all patterns on Workload Deployer are discovered. Images, software stacks, software resource templates, and virtual server template elements are created for them in Tivoli Provisioning Manager. Finally, patterns and their members are also registered with the Image Library. Repeat the discovery for cloud groups and patterns for any given Workload Deployer if they have been changed. The changes can occur when, for example, new hardware is added to the cloud group or a pattern is added or changed. Note: Workload Deployer patterns must have a description, otherwise discovery might fail. Discovery is accomplished as follows: a. Select Go To > Discovery > Provisioning Discovery > Discovery Configurations. b. Filter for WebSphere CloudBurst Appliance Discovery and select it. c. Click Run Discovery. d. Select Computers. e. Locate and select one or more entries representing Workload Deployer. Click OK, and then Submit. The discovery might take some time to run. 6. Select Go To > IT Infrastructure > Image Library > Image Repositories. 7. Open wcahostname.ibm.com and add the Repository Location: a. In the Repository Locations tab, click the New Repository Location button. b. In the New Repository Location window type: v For Directory, specify: WCA Directory v For Computer, select wcahostname.ibm.com (the name of the computer representing the Workload Deployer) c. Click OK and Save. 8. Select Go To > IT Infrastructure > Provisioning Inventory > Virtual Server Template. 9. Connect all Virtual Server Templates with Software Templates: a. Click the template to open it. b. In the Virtual Server Template tab that is displayed, click the Select Value button next to the Software Stack field. c. In the window that opens, select the software stack with the name that corresponds to the name of the template. Click Save. Repeat these steps for all Virtual Server Templates.
210
Results
Upon completion, new or modified patterns can be selected for deployment. You can do this by using the self-service user interface (creating a project based on a Workload Deployer pattern).
Configuring the managed environment to use the WebSphere Cluster Service

Learn how to configure the Tivoli Service Automation Manager managed environment so that it can use the 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 product. The managed environment can be one of the following: v a Linux on System z system. v an AIX (System p) system.
Procedure
1. Check that you fulfill the latest requirements for using the WebSphere Cluster service. You can find this information at http://publib.boulder.ibm.com/ infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ ae/ae/tins_prepare.html. 2. Verify that you have completed the tasks described in Configuring and running discovery on a Tivoli Provisioning Manager server on page 213. 3. Check that the time difference between the management server and the managed environment nodes is set to less than 15 minutes. This is a requirement for using the WebSphere Application Server. To modify the time on an AIX server, use the command smitty date. 4. Verify that the root user of the management server can open a Secure Shell (SSH) connection to the managed environments without any prompts. If prompts are issued, you have to add the public SSH keys of the management server to the authorized keys of the managed environments. To do so: a. Copy id_rsa.pub file to the managed environment. b. Extend the authorized_keys file by the new copy of id_rsa.pub file.
Configuring the DCM to use the WebSphere Cluster Service

The DCM is an abstract representation of physical and logical components managed by Tivoli Provisioning Manager. This task describes how to configure the Data Center Model (DCM) for Tivoli Provisioning Manager. After a successful installation, configure DCM for Tivoli Provisioning Manager before you provision a landscape that uses WebSphere Application Server.
Before you begin

Important: This task is relevant only if you have purchased and installed the Tivoli Service Automation Manager for WebSphere Application Server product. v Ensure that the Tivoli Provisioning Manager is running before you run the command to import data.
211
About this task

To prepare a WebSphere Application Server service, you must configure the DCM. The WebSphere Application Server provisioning workflow in Tivoli Provisioning Manager uses an installable file from a file repository server. Tivoli Service Automation Manager provides template XML files that you can customize. You then have to import these customized files into DCM by using an XML import tool (xmlimport.sh) provided in Tivoli Provisioning Manager. Note: There must be only one WebSphere 6.1 software module in the DCM. By default, the WebSphere Application Server 6.1 software module is installed. Delete this module to proceed with the procedure.
Procedure
1. Depending on the managed environment, ensure that the following WAS and HTTP Server installable files are available on the Tivoli Provisioning Manager server: v For System z: WebSphere Application Server Network Deployment V6.1 Linux on zSeries, 64-bit support (C88TKML). WebSphere Application Server Network Deployment V6.1 Supplements for Linux on zSeries, 64-bit Support (C88TQML). v For AIX: WebSphere Application Server Network Deployment V6.1 for AIX 5L 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.
212
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:
<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.
213
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. 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 31. Classification attributes for configuration items to be used by the WebSphere Cluster Service Classification Attribute COMPUTERSYSTEM_MEMORYSIZE Description Total RAM memory size for server. This attribute is used for filtering in the resource allocation records and can be adapted there. Fully qualified domain name of the server. This attribute is used in the Script Adapter to establish SSH connections to the server.
COMPUTERSYSTEM_FQDN
214
Table 31. Classification attributes for configuration items to be used by the WebSphere Cluster Service (continued) Classification Attribute COMPUTERSYSTEM_NAME Description 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. Name of the architecture for the server. This attribute is used for filtering in the resource allocation records and can be adapted there.
COMPUTERSYSTEM_ARCHITECTURE
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. New CI button. 3. Click the 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 31 on page 214.
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. 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.
215
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.
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.
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. Refer to theTivoli Monitoring information center to install the server for your OS and platform: http://publib.boulder.ibm.com/infocenter/tivihelp/ v15r1/index.jsp?topic=/com.ibm.itm.doc_6.2.1/welcome.htm 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.
216
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. 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.
217
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. 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
218
a. In the chosen DCM XML files, customize the section below according to your environment:
 <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>  <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. 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
219
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. 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.
220
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) PMRDP_0202A_72 PMRDP_0203A_72 PMRDP_0204A_72 PMRDP_0205A_72 PMRDP_0206A_72 VMControl) v PMRDP_0216A_72 VMControl) v v v v v a. b. c. d. (Create (Create (Create (Create (Create Project with POWER LPAR Servers) Project with Xen Servers) Project with z/VM Linux Servers) Project with KVM Servers) POWER LPAR Servers via IBM Systems Director
(Add POWER LPAR Servers via IBM Systems Director
Log on to the administrative user interface as PMSCADMUSR. Click Go To > Service Request Manager Catalog > Offerings Click on the offering to open it. 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. 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 Filter for Create Project from Saved Image offering and open it. From the Select Action menu, select Change Status. Change the status of the offering to PENDING and click OK. Click the Specification tab. In the Presentation subsection of the Default Presentation Details, filter for PMRDPCLSWS_MONITORING. 8. Deselect the Hidden check box and select the Mandatory box. 3. 4. 5. 6. 7. 9. Change the status of the offering to ACTIVE. 10. Click Save.
221
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.
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.
222
-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 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
223
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: 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.
224
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 # 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. Click Go To > System Configuration > Platform Configuration > Web Services Library. On the Select Action menu, select Create Web Service > Create WS from Standard Service. In the Create Web Service from a Standard Service Definition window, select source name PMZHBPWO and click Create. Select the PMZHBPWO Web service. On the Select Action menu, select Deploy Web Service and click OK.
b. c. d. e. f.
225
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.
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 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 v Deployment_Instance - the name of the deployment instance (project) the server is allocated to v Service_Definition - the name of the service definition used to create the deployment instance v Deployment_Owner - the user that requested the deployment instance v Account_Code - the identifier consisting 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 The CSR file contains three metrics for chargeback: v SERVHRS - time (in hours) the server has been 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 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.
226
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. 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 244 and perform the steps as described. 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 228. d. Define the location of the CSR file. See Defining the directory for CSR file generation on page 228. 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
227
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. 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 243). If reporting is already enabled, nothing else has to be configured, if not, the same steps as for report configuration have to be performed. Enabling CSR file generation: You need to define the escalation that enables generation of the CSR files for the Tivoli Usage and Accounting Manager interface. Before you begin The concept of escalations 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. 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:
228
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.
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 247. 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: 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 and CPUHRS. 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.
229
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 231 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 227 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 228. 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. The CSR file is transferred from the Tivoli Service Automation Manager management server by executing 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. 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. A customized job file might appear as follows:
230
<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"/>  <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:
Table 32. Account code structure Identifier Account_Code Length in characters 40 consisting of: <CUSTOMER> 12 <PROJECTACCOUNT> 20 <PERSONGROUP> 8 Description 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
231
Table 32. Account code structure (continued) Identifier Deployment_Owner Service_Definition Length in characters 30 4 Description The user that requested the project. First four characters of the service definition name, used to identify the service in a report. The name of the project the server is associated to.
Deployment_Instance
30
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:
232
<Process
id="TSAM" description="Process 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> &ltFile name="%ProcessFolder%/RDP_%LogDate_End%.txt"/> </Files> </Input> <Stage name="CreateIdentifierFromIdentifiers" active="true"> <Identifiers> <Identifier name="Account_Code"> <FromIdentifiers> <FromIdentifier name="Account_Code" offset="1" length="40" /> <FromIdentifier name="Deployment_Owner" offset="1" length="30" /> <FromIdentifier name="Service_Definition offset="1" length="4" /> <FromIdentifier name="Deployment_Instance" offset="1" length="30" /> </FromIdentifiers> </Identifier> </Identifiers> <Parameters> <Parameter keepLength="true"/> <Parameter modifyIfExists="true"/> </Parameters> </Stage> <Stage name="CSROutput" active="true"> <Files> <File name="%ProcessFolder%/AcctCSR.txt" /> </Files> </Stage> </Integrator> </Step> <Step id="Process" description="Standard Processing for Tivoli Service Automation Manager" type="Process" programName="Bill" programType="java" active="true"> <Bill> <Parameters> </Parameters> </Bill> </Step> <Step id="DatabaseLoad" description="Database Load for Tivoli Service Automation Manager" type="Process" programName="DBLoad" programType="java" active="true"> <DBLoad> <Parameters> </Parameters> </DBLoad> </Step> <Step id="Cleanup" description="Cleanup CSR Processing" type="Process" programName="Cleanup" programType="java" active="false"> <Parameters> <Parameter DaysToRetainFiles="45"/> <Parameter cleanSubfolders="true"/> </Parameters> </Step> </Steps> </Process>
233
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.
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.
234
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. 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.
235
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. 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
236
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. 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.
237
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.
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
238
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 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:
239
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. 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.
240
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. 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
241
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. 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.
242
Chapter 5. 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:
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 85 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 244.
243
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.
244
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: PMZHBSSVCD v Service Deployment Instances: PMZHBSSVCI 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 5. Administering
245
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.
246
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 226.
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 33. Account code structure Identifier Account_Code Length in characters 40 consisting of: <CUSTOMER> 12 <PROJECTACCOUNT> 20 <PERSONGROUP> 8 Description 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 Service_Definition 30 4 The user that requested the project. First four characters of the service definition name, used to identify the service in a report. The name of the project the server is associated to.
Deployment_Instance
30
247
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.
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 Working with reports in the IBM Tivoli Usage and Accounting Manager information 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.
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:
248
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. 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.
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.
249
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.
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 v v v Name and Description Associated Customer Usage Type: Customer Status of the network instance
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:
250
v v v v
Network segment name Segment type Description 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.
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
251
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. 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.
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.
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.
252
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.
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.
253
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.
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 v v v v Name and description Associated customer Service deployment instance Usage type: project Status of the project network configuration
You can navigate to the related service deployment instance and customer.
254
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.
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.
Managing virtual server resources

You can administer virtual servers for various host platforms.
255
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. 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.
Managing server images

This section describes the procedures for administering server and software images.
256
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 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 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 will be used for provisioning the target virtual machines. 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 29 Important: v Only virtual images without snapshots may be used. 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.
257
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 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 Web site. To perform a Windows customization, you must install the Sysprep tools either from your installation disc, or from the Microsoft download package. For detailed information on this topic please 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. For example, in the case of Windows XP: Windows XP Professional SP2 v Location: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\sysprep\xp v Download: http://www.microsoft.com/downloads/ details.aspx?familyid=3E90DC91-AC56-4665-949B-BEDA3080E0F6 &displaylang=en v Instructions: Open the CAB file download and copy the contents to the xp folder. Windows XP x64 v Location: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\sysprep\xp-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 xp-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. 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 and Vista, 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 install. Change to that directory.
258
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 f. Create the cloud_cygwin_install.zip compressed file with the contents of the\TEMP\CYGWIN directory. Note: You can also opt for a pre-installed Cygwin scenario. For more information, see Installing Cygwin on page 260. 8. Copy cloud_cygwin_install.zip to the Windows virtual machine under the root directory (C:\) 9. Unzip 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. Unzip 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. (XP, Vista, 2008) Disable the firewall: Control Panel > Administrative Tools > Services Important: The save/restore function has the capability to 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 end users, this feature should 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 have now created a Windows template. Important: If a VMware template that is already registered in Tivoli Service Automation Manager, and it needs to be modified, do not clone the virtual machine, because then you will not be able to use the modified VMware template. Instead, perform 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.
259
What to do next Now, you need 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 267. Note: Do not use VMware Infrastructure Client to provision a virtual machine from the created template. Virtual machines should be provisioned by means of 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. This is described in the Tivoli Provisioning Manager information center. (See Table 4: Hidden Parameters for VMware in Creating virtual servers.) Installing Cygwin: You can install Cygwin directly from the Internet or from a local directory. 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. 3. 4. 5. Go to http://www.cygwin.com. Click setup.exe and download the file. Run setup.exe from your computer. 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.
260
What to do next Complete the procedure described in Preparing a Windows image on page 257, starting from step 13. Preparing a Linux image: Configure the Linux image templates that are used for provisioning the target virtual machines. Before you begin Important: v Only virtual images without snapshots may be used. Existing snapshots have to be integrated before you convert the virtual image to a template. 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. 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 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. 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.
261
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 chconfig 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
262
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.
263
8. 9. 10. 11.
h. (Optional) If you have such an option within your menu, click VM > Guest > End Install VMware tools. i. Close the terminal. Once again verify the requirements described in Before you begin. Shut down the guest operating system and power off the virtual machine. From the VMware Infrastructure Client, right-click the virtual machine and select Template > Convert to Template. 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 need 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 267.
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 need 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 267.
264
Creating operating system image templates for KVM

The following sections describe the steps to configure the operating system image templates for KVM.
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. 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.
265
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 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.
266
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. What to do next Now, you need 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.
Preparing OS image templates for Tivoli Service Automation Manager

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. Run a Tivoli Provisioning Manager discovery 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. Click 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: VMware Discover image templates for VMware PowerVM Run the NIM discovery. 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.
267
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.
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 need to be canceled.
About this task

To remove an image:
Procedure
1. Log on to the self-service user interface and verify if any future projects are related to the image that is to be removed. If there are any: a. Click Request a New Service > Virtual Server Management > Cancel project to cancel all future reservations for the image to be removed. 2. To unregister the image, click Request a New Service > Virtual Server Management > Manage Image Library > Unregister Image. 3. Log on to the administrative user interface: a. Click Go To > IT infrastructure > Image Library > Master Images. b. Select the image that you want to remove. c. Click the Remove Master Image option from the dropdown menu.
268
Results
The image is deleted from Tivoli Provisioning Manager Image Library and can no longer be used to create new servers.
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.
269
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.
270
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 34. Roles and groups provided by Tivoli Service Automation Manager Role Description Service Administrator Service Definition Designer Service Definition Manager Service Deployment Instance Manager Service Deployment Instance Operator Service Resource Allocation Manager Person Group (8 chars) TSAMSADM TSAMSSDD TSAMSSDM TSAMSSIM TSAMSSIO TSAMSRAM Role (10 chars) PMZHBSADM PMZHBSSDD PMZHBSSDM PMZHBSSIM PMZHBSSIO PMZHBSRAM Security Group (must be created in LDAP) PMZHBSADM PMZHBSSDD PMZHBSSDM PMZHBSSIM PMZHBSSIO PMZHBSRAM
WebSphere Cluster Service Performance - AIX Administrators Performance - WAS Administrators Performance - Linux Administrators Performance Monitoring Administrator TSAMPAXA TSAMPWAS TSAMPLXA TSAMPPMA PMZHBPAIXA PMZHBPWASA PMZHBPLNXA PMZHBPPMA PMZHBPAIXA PMZHBPWASA PMZHBPLNXA PMZHBPPMA
Self-Service Virtual Server Provisioning component Tivoli Service Automation Manager Administrator (for Self-Service Virtual Server Provisioning) PMSCADMUSR Not applicable 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.
271
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.
272
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. Each user is 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 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, and they can access the information and resources for this exact customer only. 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 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 on page 274.
273
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 285.
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 v v v v Create customers based on customer templates and delete them Modify their own information Register and unregister software images Allow resource allocations and changes within the whole cloud Check the status of projects and monitor the servers for all users
v Approve or deny provisioning requests made by cloud customer administrators Cloud customer administrator Users in this role are administrators dedicated to individual customers. 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 customer v Check the status of projects and monitor the servers for their users v Approve or deny provisioning requests made by team administrators Cloud manager Users in this role are the read-only administrators of the cloud. They can perform the following tasks: v On cloud level, check the status of projects and monitor the virtual servers for any team
274
v On customer level, check the status of projects and monitor the virtual servers assigned to the customer 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 35. Access to requests depending on the security group
Cloud Administrator Create project Create project from saved image Add server Add server from saved image Modify reservation Cancel project Modify server resources Reset server password Start, stop, or restart server Install software Remove server Create server image Restore server from image Remove saved images Register image Unregister image Create user Modify user v v v v Cloud Manager Team Administrator v v v v Team User Cloud Customer Administrator v v v v Approver Security Administrator -
v v v v v v v v v v v v v v
v v v v v v v v v v v
v v v v v v v v v v v v
v v
275
Table 35. Access to requests depending on the security group (continued)

Cloud Administrator Remove user Create team Modify team Remove team Create customer Remove customer Approve and reject requests View requests View projects View servers v v v v v v v v v v Cloud Manager v v v v Team Administrator v v v v Team User v v v Cloud Customer Administrator v v v v v v v v Approver v v v v Security Administrator v -
Data segregation for service providers

In Tivoli Service Automation Manager 7.2.2, you can use the multi-customer support feature to segregate data. Starting with version 7.2.2, each 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. 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 7.2.2, there are two predefined levels of visibility: cloud level and cloud customer level. Users on cloud level policy have unrestricted visibility: v v v v They They They They are assigned to the global customer PMRDPCUST. can see all resources within the cloud. can switch to a specific customer to work for only this customer. 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 Each user is assigned to exactly one customer. v Users can access only the objects associated with that customer. v Security group and team assignment impose further restrictions.
276
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.
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).
277
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 279. Network resources cannot be shared between customers.
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 Go To Master Images. Detail Menu >
Detail Menu > Go To Software Stacks. b. Next to the software stack click 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. Return to return to the Cloud Customer Administration d. Click Application.
278
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 281. 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 280.
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.
279
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.
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. New Customer in the toolbar. 2. Click 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 toolbar, and select ACTIVE from the New Status list. Change Status in the
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. Save. 6. Click 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.
280
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. 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 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 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.
281
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 36. Types of quotas and limits
Quota Type Limit Type COMPUTERSYSTEM_MEMORYSIZE Cloud server pool COMPUTERSYSTEM_PROCESSCAPACITYUNITS COMPUTERSYSTEM_NUMCPUS FILESYSTEM_CAPACITY Cloud storage pool FILESYSTEM_CAPACITY Limit Type Description Amount of memory 10th of physical CPU Number of virtual CPUs Amount of default disk space Amount of storage on additional disks GB GB Measure Unit GB
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. View Details. b. Select limit type and click c. In the Details section, fill in 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 on page 283
282
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.
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 37. Tivoli Service Automation Manager communication templates Template PMRDPAFREJA PMRDPNOTAS PMRDPNOTCP PMRDPNOTDETAIL PMRDPNOTMS PMRDPNOTRP PMRDPNOTRS Event that triggers notification A service request approval was rejected; the submitting user is notified. A server has been added; the user is notified. A deployment has been created; the user is notified. A successful execution triggers a detailed notification to the service requester. A server has been modified; the user is notified. A deployment has been canceled; the user is notified. A server has been removed; the user is notified.
283
Table 37. Tivoli Service Automation Manager communication templates (continued) Template PMRDPNOTSAVE PMRDPNOTSTARTS PMRDPNOTSTOPS PMRDPRBREJ PMRDPSRAF PMRDPSROK PMRDPSRRB PMRDPIMRR PMRDPIMDL PMRDPIMSV PMRDPNOTDPAT PMRDPNOTPEND PMRDPNOTPENDPR PMRDPNOTPRP PMRDPNOTREMPATT PMRDPNOTRES PMRDPNOTSERVEROP PMRDPNOTAPP PMRDPIMUPG PMRDPNOTCHPW PMRDPNOTSWI PMRDPSRFAIL PMRDPAPRREQ Event that triggers notification A virtual server image has been saved; the user is notified. A server has been started; the user is notified. A server has been stopped; the user is notified. A service request approval was rejected; the submitting user is notified. A service request approval is required; the affected user is notified. A service request was automatically approved; the submitting user is notified. A service request approval is required; the user who reported the request is notified. A virtual server was restored. A virtual server image was deleted. A virtual server image was created. A Workload Deployer pattern project was created. Removal of a server is pending due to an expired reservation. Removal of a project is pending due to an expired reservation. Removal of a Workload Deployer pattern is pending. A Workload Deployer pattern deployment was canceled. The project reservation time was modified. A server operation was carried out. Approval is required. Upgrade of service instance completed. A virtual server password was changed. Software was successfully installed. A service request failed. 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. The following roles are defined in Tivoli Service Automation Manager communication templates to receive email notifications:
Table 38. Roles for email notifications Role PMRDPNOTRQ PMRDPNOTSO Definition User that issued a provisioning request. Owner of the project, that is a user who created the project.
284
Table 38. Roles for email notifications (continued) Role PMRDPNOTUG Definition 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.
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.
285
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. 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.
286
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.
Live Refresh. 6. Click 7. In the Live Refresh window, filter for pmrdp.enable.delegation or use the green arrows to navigate to it, and click OK.
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 Operating systems must have the swType variable defined, with value OS. v Software installation feature is independent of hypervisor at the backend. If a server fulfills the requirements of the selected software module then that software module is listed as installable on it.
Before you begin

You need to be the Tivoli Service Automation Manager administrator (maxadmin) to perform this task.
287
Procedure
1. Create new software definition. See the Provisioning User Guide in the Tivoli Provisioning Manager Information Center, and follow the steps as described in Manually defining software products. 2. Define the exposetotivsam and swType properties: 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. If required, select swType, and in the Value field, specify OS. e. Click Save. 3. Add a new installation workflow: 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 278. 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 Go To Master Images. Detail Menu >
Detail Menu > Go To Software Stacks. b. Next to the software stack click 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. Return to return to the Cloud Customer Administration d. Click Application. e. In the Software Modules tab, assign the software stack corresponding to the image to the customer. f. Save the changes.
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.
288
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.2/sbin/idsdiradm I idsccmdb /opt/IBM/ldap/V6.2/sbin/idsslapd I idsccmdb /opt/IBM/ldap/V6.2/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: 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:
289
$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
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:
290
$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
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). 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.
291
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 : 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):
Linux
ln ln ln ln ln
-s -s -s -s -s
/etc/init.d/tsam_middleware.sh /etc/init.d/tsam_middleware.sh /etc/init.d/tsam_middleware.sh /etc/init.d/tsam_middleware.sh /etc/init.d/tsam_middleware.sh
/etc/rc.d/rc2.d/S99tsam_middleware /etc/rc.d/rc2.d/K01tsam_middleware /etc/rc.d/rc3.d/S99tsam_middleware /etc/rc.d/rc3.d/K01tsam_middleware /etc/rc.d/rc6.d/K01tsam_middleware
: a. Copy the script to /etc/rc.d/init.d.

AIX
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
292
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 290. 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 289.
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.
293
Defining global password policy

You can define a global password policy for Tivoli Service Automation Manager.
About this task

The passwords for the following users must be excluded from the policy, because when they expire, they render Tivoli Service Automation Manager unusable: v maxadmin v maxreg v mxintadm v wasadmin
Procedure
1. To define a global password policy, run the following commands, modifying the values as required:
# cd /opt/IBM/ldap/V6.2/bin # ./idsldapmodify -D cn=root -w <ldap_admin_password> -k dn: cn=pwdpolicy,cn=ibmPolicies ibm-pwdPolicy: true ibm-pwdGroupAndIndividualEnabled:true pwdMaxAge: 600 pwdMinLength: 4 pwdlockout: true pwdMaxFailure: 4 pwdAllowUserChange: true
2. Exclude the users maxadmin, maxreg, mxintadm, and wasadmin from this policy to make sure that the passwords for these users do not expire. Run the following commands for maxadmin user:
# ./idsldapadd -D cn=root -w <ldap_admin_password> dn:cn=excludedusers_pwd_policy,cn=ibmPolicies objectclass: container objectclass: pwdPolicy objectclass: ibm-pwdPolicyExt objectclass: top cn:excludedusers_pwd_policy pwdAttribute: userPassword pwdMaxAge: 0 pwdLockout: false pwdAllowUserChange: true pwdMustChange: false ibm-pwdpolicy: true # ./idsldapmodify -D cn=root -w <ldap_admin_password> -k dn:uid=maxadmin,ou=users,ou=SWG,o=IBM,c=US changetype:modify add:ibm-pwdIndividualPolicyDN ibm-pwdIndividualPolicyDN:cn=excludedusers_pwd_policy,cn=ibmPolicies
Repeat these commands for users maxreg, mxintadm, and wasadmin, changing the values as required.
294
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 a. Type b. Type c. Type Tivoli Provisioning Manager processes: su tioadmin cd $TIO_HOME/tools ./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: a. Type cd /opt/IBM/ldap/V6.2/sbin b. Type ./ibmslapd I idsccmdb 4. Verify that the Tivoli Directory Server is running: a. b. c. 5. As a. b. c. Type su - idsccmdb Type cd /opt/IBM/ldap/V6.2/bin Type ./ibmdirctl D cn=root w password status idsccmdb, verify database connection using the new password: Type db2 list db directory Type db2 connect to security user idsccmdb using <new password> Type db2 connect to ldapdb2b user idsccmdb using <new password>
6. Log in as root, and start Tivoli Provisioning Manager:

295
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.
Change in Tivoli Change in Provisioning Tivoli Directory Manager Server Yes Yes No No No No No No No No No No No No No No Change in WebSphere Application Server Yes No No No No No No No
OS user ID maximo tioadmin ctginst1 dasusr1 db2fenc1 virtuser root idsldap (not used)
Changed in OS Yes Yes Yes Yes Yes Yes Yes Yes
The following is the list of LDAP user IDs and where the passwords must be changed.
Change in Tivoli Change in Provisioning Tivoli Directory Manager Server No No No Yes Yes No Change in WebSphere Application Server Yes No No
LDAP user ID wasadmin maxadmin PMSCADMUSR
Changed in OS No No No
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:
296
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:
./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
297
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 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. 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>
298
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:
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 changePassword command in the Tivoli Provisioning Manager Information 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
299
must first assign a temporary password to the user, then log on with the user name and assign a permanent password.
Change maximo.properties
Procedure
1. Log on as root and change the maximo.properties file by doing the following: 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>. 3. Save the file. 4. 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/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>. 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.
300
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.
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 /opt/IBM/WebSphere/AppServer/java/bin/jar -xf /opt/IBM/WebSphere/ AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/ properties.jar maximo.properties v /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>. 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 /opt/IBM/WebSphere/AppServer/java/bin/jar -uf /opt/IBM/WebSphere/ AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/ properties.jar maximo.properties v /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:
301
BMXAA6451I BMXAA6385I BMXAA6388I BMXAA6390I BMXAA6391I BMXAA6453I
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. The database manager is psdi.server.DBManager@43164316 Connecting to the database at: jdbc:db2://vm-tpm-s122.torolab.ibm.com:50005/maxdb71 Database product: DB2/NT BMXAA6389I - Database product version: SQL09053 -- 9.5 Database driver: IBM DB2 JDBC Universal Driver Architecture Database driver version: 3.53.70 Connection pool initialized with 8 free connections. 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: 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 v v v v tioadmin ctginst1 dasusr1 db2fenc1 virtuser
Procedure
1. As the root user, enter the following command: echo "userid:<new password>" | chpasswd where:
302
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 OS password for root

After you change passwords for other users, update the root password by running the applicable command and changing the SSH Server credentials for the Tivoli Provisioning Manager Data Center Model (DCM) object.
Procedure
1. As the root user, enter the following command: echo "root:<new password>" | chpasswd where <new password> is the new password for root. 2. Log on to the Tivoli Service Automation Manager administrative user interface. 3. Click Go To > Deployment > Provisioning Computers. 4. Select the Credentials tab and go to the Service Access Points section. 5. From the list, select SSH-Server entry and go to the Details tab. 6. From the list, select the entry where the search key is master and the user name is root. 7. Enter and confirm the new password.
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 5. Log out of the Tivoli Service Automation Manager user interface, then log on again as PMRDPCAUSR and enter the new password.
303
Using virtual servers for SAP landscapes

This section describes the procedures for preparing a Tivoli Service Automation Manager virtual server for use as a supplementary SAP dialog instance (DI).
About this task

The Tivoli Service Automation Manager and CloudBurst products are an ideal way to complement your heterogeneous SAP workload in a cloud computing environment. This section describes how to set up your SAP IT landscape to achieve maximum flexibility. Setting up your SAP landscape according this description provides: v flexibility v cost reduction v integrated metering All of these benefits can be achieved by simply installing SAP Dialog Instances (DIs) for your SAP systems that need more flexibility. You then deploy a DI on a virtual machine only when it is needed at a specific point in time. When the DI is no longer needed, you can save the image and free up the resources. If there is a requirement for additional capacity of your SAP system, you can redeploy the image on an appropriately sized server. Creating the SAP Dialog Instance image: First, you have to set up your master image according the CloudBurst/Tivoli Service Automation Manager documentation. Because the SAP Installation might have additional requirements, refer also to the corresponding SAP PAM and SAP Notes such as: v 1122388 - Linux: VMware ESX 3.x or vSphere configuration v 1122387 - Linux: SAP Support in virtualized environments v 171356 - SAP software on Linux: Essential information The SAP Dialog Instance should then be installed according the underlying SAP Installation Guide, for example SAP NetWeaver 7.0 SR3 ABAP on Linux : Oracle Note: For the Installation you have to use a virtual hostname. This is the basis for a later deployment on different virtual machines. For details, refer to the SAP documentation and SAP Notes. Post-deployment support: To optimize the SAP DI image on a virtual machine with a larger or smaller capacity, it might be necessary to adjust the SAP profile parameters such as the number of work processes and shared memory areas. For adjusting these profile parameters, IBM supplies a simple post-processing script. The script, which is run on the Tivoli Service Automation Manager management server, saves the original instance profile to <old_instance_profile_name>.old and creates a new one according the specified parameters. The script is:
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/ITSAM_payload/scripts/SAP/modifySAPprofile.sh
304
It requires an input parameter file. A sample input file is also provided in this directory:
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/ITSAM_payload/scripts/SAP/modifySAPprofile.conf
To modify the instance profile after deployment of the SAP DI, do the following: 1. Copy the sample file to a temporary directory and modify at least one value in the parameter section. The file has two sections: v the management section, which describes the target system v the instance profile section, which contains the parameters that can be modified. Management section: The management section is structured as follows:
Table 39. Management section of the input parameter file Parameter name SAPSystemTargetHost working_directory Sample belchen18 /tmp Default None /tmp Description Host name of the SAP DI Directory to which the script, the configuration files, and the output will be copied. SAP instance number SAP instance name
SAP_Instance_number SAP_sid sap-instance_profile_name
20 GA1 GA1_D20_belchen18
None None
<sap_sid>_ Name of the instance D<SAP_Instance_number>_ profile. <target_host_name>
Instance profile section: The instance profile section is structured as follows:

Table 40. Instance profile section of the input parameter file Parameter name rdisp_no_wp_dia rdisp_no_wp_btc rdisp_no_wp_vb rdisp_no_wp_vb2 rdisp_no_wp_spo ipc_shm_psize_10 ipc_shm_psize_40 Sample 10 10 10 10 10 144000000 200000000 Default None None None None None None None Description Number of SAP dialog processes Number of SAP batch processes Number of SAP vb processes Number of SAP vb2 processes Number of SAP spool processes Number of bytes for pool 10 Number of bytes for pool 40
2. Support is provided for changing any of the parameters listed in the sample profile. If a parameter should not be modified, remove the line from the input profile.
305
Assume the sample instance profile has been copied to /tmp/sample.conf on the management server and that the profile appears as follows after editing:
SAPSystemTargetHost=belchen18 working_directory=/tmp SAP_Instance_number=20 SAP_sid=GA1 # rdisp_no_wp_dia=10
3. Invoke the profile modification as follows:

/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/installedApps/ctgCell01/MAXIMO.ear/ITSAM_payload/scripts/SAP/modifySAPprofile.sh /tmp/sample.conf
The script does the following: v creates a temporary directory

/tmp/<random_number>
v copies all of the required files to the directory /tmp on the target system belchen18 v creates a backup copy of the current instance profile .old (the assumption is that the name of the profile is GA1_D10_belchen18 because no instance name is specified) v modifies only the number of SAP Dialog processes v copies the new instance profile back to the management server, in the working directory: /tmp/<random_number> 4. Stop, start, or restart the SAP dialog instance if the optional start/stop commands are specified in the configuration file. The SAP dialog instance must be reachable from the management server with Secure Shell (ssh).
Using the Admin Mode

The administrative user interface can be run in the Admin Mode. In this mode, you can configure the database configuration changes without having to shut down the Maximo server.
About this task

When you enter the Admin Mode, no other users are connected to the server and all other system configuration work is suspended. Users cannot log on unless they have specific admin privileges.
Procedure
1. Click Go To > System Configuration > Platform Configuration > Database Configuration. 2. In the Select Action menu, click Manage Admin Mode. 3. Click Turn Admin Mode ON.
What to do next
Once the changes are complete, remember to turn the Admin Mode off.
306
Chapter 6. Reliability, availability, and serviceability functions

Learn about the functions offered within reliability, availability, and serviceability (RAS). The following RAS functions are available in Tivoli Service Automation Manager version 7.2.2: Delete Data Center Model (DCM) virtual servers on a given host platform Cleans a host platform in DCM from any hosted virtual servers. It supports Tivoli Service Automation Manager approved hypervisors. List virtual servers on given host platform Retrieves a list of hosted virtual server names directly from the hypervisor manager. List virtual servers on a given host platform and in DCM Compares a list of hosted virtual server names retrieved directly from the hypervisor manager with a list of virtual server names collected from DCM. Restriction: This function is available only for VMware, KVM, and Power managed via HMC, not via VMControl. Force cleanup of Tivoli Service Automation Manager service deployment instance Cleans the Tivoli Service Automation Manager and Tivoli Provisioning Manager data model from all project related artifacts. This function can be called when a project is not functioning properly and cannot be reverted to a functional state using other methods. Note: Ensure that no service requests are running when force cleanup is called. All the service requests associated with the project are also removed from the data model. List Tivoli Service Automation Manager service deployment instance backend resources Lists all backend resources associated with a service deployment instance, so that whenever the administrator needs to perform force cleanup he can find out the resources and configuration that needs to be cleaned manually. List Tivoli Service Automation Manager service deployment instance data model inconsistencies Checks the Tivoli Service Automation Manager service deployment instance topology tree and validates its nodes with DCM and other internal structures. The function gathers inconsistencies between the internal structures and returns a list of discovered problems. Provide service request current status Provides the current service request status. If the service request does not exist, the function returns a specific status, for example, UNKNOWN. Otherwise, the status stored in the TPAe data model is returned.
307
REST API reference for RAS

This section provides reference information about the REST APIs delivered for the RAS functionality. Response format Currently, RAS REST APIs use XML encoded with UTF-8 as the only response format. Security constraints RAS REST APIs are meant to be used by cloud administrators, so that each function call is guarded with a security check. The signature options for the REST services are as follows: v RAS_DELETE_VMS RAS Delete all virtual servers available on given hostplatform from DCM v RAS_LIST_VMS RAS List all virtual servers available on given hostplatform (hypervisor view) v RAS_COMPARE_VMS RAS List all virtual servers available on given hostplatform (hypervisor and DCM view) v RAS_FORCE_CLEANUP RAS Remove all Service Deployment Instance related data v RAS_LIST_SDIRES RAS List all Service Deployment Instance backend resources v RAS_VALIDATE RAS Validate Service Deployment Instance data consistency v RAS_SR_STATUS RAS Get Service Request current status By default, only users belonging to PMRDPCA and MAXADMIN security groups have the required privileges to call the functions. The signature options need to be associated with PMRDPWEB20 TPAe application.
Delete DCM virtual servers on given host platform

Use this function to remove hosted virtual servers and templates from a host platform in Data Center Model. This function supports any hypervisor approved by Tivoli Service Automation Manager.
URL:
https://[hostname]:[port]/maxrest/rest/deleteVMs/ [hp_id]?timeOut=[number_of_seconds] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v hp_id a numerical value for the host platform ID in Tivoli Service Automation Manager. v number_of_seconds indicates how much time the core logic waits for the internal workflow to complete. The default value is 500.
308
HTTP error codes:

Error code 200 Description Successful invocation with XML response: <result> <successful>true</successful> </result> 400 system#[error message] problem with workflow invocation or workflow has failed (see Provisioning workflow logs for more details) system#timeout the timeout for workflow execution is passed and the workflow is still running system#invalidParameter invalid or missing parameter 401 access#deleteVMsOnHost user has not been granted the privilege required to call the function Internal system errors
500
Important: DeleteVMsOnHost removes all virtual machines and templates from a given host platform. After running the DeleteVMsOnHost workflow, the status of the host platform is automatically changed to failed and the host platform is locked. Unlock the host platform, remove all templates from the requested host platform from the Master Images application, and execute the host platform discovery: 1. Log on to the administrative interface. 2. Navigate to Go To > Administration > Provisioning > Resource Pools. 3. Filter for and select the locked host platform. 4. Clear the Is Failed checkbox. Save Resource Pool. 5. Click 6. Navigate to Go To > IT Infrastructure > Image Library > Master Images. 7. In the Master Images section, remove all templates. Save Master Image. 8. Click 9. Execute the host platform discovery.
List virtual servers on given host platform

Use this function to directly go to the hypervisor manager and retrieve a list of the names of the hosted virtual servers.
URL:
https://[hostname]:[port]/maxrest/rest/listVMs/ [hp_id]?timeOut=[number_of_seconds] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443.
309
v hp_id a numerical value for the host platform ID in Tivoli Service Automation Manager. v number_of_seconds indicates how much time the core logic waits for the internal workflow to complete. The default value is 500.
HTTP error codes:

Error code 200 Description Successful invocation with XML response of the following format: <virtualServerList> - XML root element <virtualServer> - for each Virtual Server found on the hypervisor <name>Virtual Server</name> </virtualServer> </virtualServerList> 400 system#[error message] problem with workflow invocation or workflow has failed (see Provisioning workflow logs for more details) system#timeout the timeout for workflow execution is passed and the workflow is still running system#invalidParameter invalid or missing parameter 401 500 access#listVMs user has not been granted the privilege required to call the function Internal system errors
List virtual servers on given host platform and in DCM

This function compares a list of hosted virtual server names retrieved from the hypervisor manager with a list of virtual server names collected from DCM.
URL:
You can compare a list of the hosted virtual server names from the hypervisor manager with a list of virtual server names from DCM. As a result, you can have the hypervisor and DCM view of virtual servers without going to the hypervisor manager/console. Restriction: This function is available only for VMware, KVM, and Power managed via HMC, not via VMControl. https://[hostname]:[port]/maxrest/rest/compareVMs/ [hp_id]?timeOut=[number_of_seconds] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v hp_id a numerical value for the host platform ID in Tivoli Service Automation Manager. v number_of_seconds indicates how much time the core logic waits for the internal workflow to complete. The default value is 500.
310
HTTP error codes:

Error code 200 Description Successful invocation with XML response of the following format: <virtualServerList> - XML root element <dcmVirtualServer> - for each virtual server present in DCM for given hostplatform <name>Virtual Server 1</name> </dcmVirtualServer> <hypervisorVirtualServer> - for each virtual server present on the hypervisor <name>Virtual Server 1</name> </hypervisorVirtualServer> </virtualServerList> 400 system#[error message] problem with workflow invocation or workflow has failed (see Provisioning workflow logs for more details) system#timeout the timeout for workflow execution has passed and the workflow is still running system#invalidParameter invalid or missing parameter 401 500 access#compareVMs user has not been granted the privilege required to call the function Internal system errors
Force cleanup of service deployment instance

This function cleans the Tivoli Service Automation Manager or the Tivoli Provisioning Manager data model from all data related with a project, including TPAe artifacts and DCM objects. The cleanup is performed on the project level and not on the service request level.
URL:
The force cleanup function is to be called when the project is not functioning properly and cannot be reverted to a functional one. Important: When force cleanup is called, ensure that no service requests are running, as all the associated service requests are also removed from the data model. https://[hostname]:[port]/maxrest/rest/forceCleanup/[sdi_id] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numeric value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v sdi_id a numeric value for the service deployment instance ID in Tivoli Service Automation Manager.
HTTP error codes:

Error code 200 Description Successful invocation with XML response: <result> <successful>true</successful> </result> 400 system#invalidParameter invalid or missing parameter
311
Error code 401
Description access#forceCleanup user has not been granted the correct privilege to call the function system#unknownobject given service deployment instance ID does not exist Internal system errors
404 500
List service deployment instance backend resources

You can use this function to list all the resources allocated at the hypervisor level and associated with a service deployment instance, so that whenever you need to perform force cleanup you can find the resources and configuration that need to be cleaned manually.
URL:
https://[hostname]:[port]/maxrest/rest/listBackendResources/[sdi_id] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v sdi_id a numerical value for the service deployment instance ID in Tivoli Service Automation Manager.
312
HTTP error codes:

Error code 200 Description Successful invocation with XML response: <backendResourceReport> - XML root element <serverResources> - for each virtual server associated with a service deployment instance <diskBackendResources> - disk information associated with a virtual server <diskName>Disk name</diskName> <groupName>Disk group name</groupName> <reservedSize>Reserved disk size in GB</reservedSize> <parameters> <parameterName>[SERVER_PARAMETER_NAME]</parameterName> <parameterValue>[SERVER_PARAMETER_VALUE]</parameterValue> </parameters> </diskBackendResources> <hostPlatformResource> - host platform information for a virtual server <hostPlatformId>Host platform DCM ID</hostPlatformId> <hostPlatformName>Host platform name</hostPlatformName> <hostPlatformType>Host platform type</hostPlatformType> </hostPlatformResource> <networkBackendResources> - network information for a virtual server <managementNIC>Is NIC management - Yes/No</managementNIC> <netmask>Network netmask</netmask> <networkInterfaceId>Network interface DCM ID</networkInterfaceId> <networkIpAddress>Network IP Address</networkIpAddress> <nicId>Network Interface Controller DCM ID</nicId> <nicName>NIC name</nicName> <subnetworkId>Subnetwork DCM ID</subnetworkId> <subnetworkName>Subnetwork name</subnetworkName> <vlanId>Virtual local area network ID</vlanId> </networkBackendResources> <serverHostName>Virtual server hostname</serverHostName> <serverId>Virtual server DCM ID</serverId> <serverName>Virtual server name</serverName> </serverResources> <storageResources> - for each storage node associated with a service deployment instance <parameters> <parameterName>[STORAGE_PARAMETER_NAME]</parameterName> <parameterValue>[STORAGE_PARAMETER_VALUE]</parameterValue> </parameters> </storageResources> </backendResourceReport> For detailed information on the XML parameters, see Values for the XML parameters. For an example response, see XML response example for backend resource report on page 314. 400 401 404 500 system#invalidParameter invalid or missing parameter access#listBackendResource user has not been granted the privilege required to call the function system#unknownobject given service deployment instance ID does not exist Internal system errors
Values for the XML parameters

The XML response contains the following parameters: v SERVER_PARAMETER_NAME - contains the following variables from the disk object, which vary depending on the configuration of the hypervisor: For VMware: disk.datastore_name: Disk datastore name disk.size disk: Disk size in bytes
313
disk.datastore_url: Disk datastore URL For Power: vio.server: Virtual input/output server that is responsible for the disk For VMC: Location: Location of the disk v SERVER_PARAMETER_VALUE - contains the value assigned to SERVER_PARAMETER_NAME, if the value is available v STORAGE_PARAMETER_NAME - contains the following variables from the storage node: Storage node ID DCM ID of the storage Storage name name of the storage Storage CIFS mount path full CIFS mount path including CIFS hostname Extended storage data to be used by extensions to store own extended data Storage Storage Storage Storage Storage file system file system used for additional storage mount path full mount path of the storage on the target machine NFS mount path full NFS mount path including the NFS hostname NFS export name name of the NFS export sequence sequence in which the storage has been mounted
Storage pool name name of the storage pool from which the storage is allocated Storage size size of the storage in GB Storage type type of the storage (mounted or mapped) Storage visibility visibility of the storage (team, user, or both) Storage volume group name of the volume group Storage volume name name of the storage volume v STORAGE_PARAMETER_VALUE - contains the value assigned to STORAGE_PARAMETER_NAME, if the value is available
XML response example for backend resource report

<backendResourceReport> <serverResources> <diskBackendResources> <diskName>vm_disk11</diskName> <groupName>vm-fs-vm_disk11</groupName> <parameters> <parameterName>disk.size</parameterName> <parameterValue>630018015232</parameterValue> </parameters> <reservedSize>12.0</reservedSize> </diskBackendResources> <hostPlatformResource> <hostPlatformId>9840</hostPlatformId> <hostPlatformName>cloudburst-esxi2.cloudburst.net</hostPlatformName> </hostPlatformResource> <networkBackendResources> <managementNIC>yes</managementNIC> <netmask>255.255.0.0</netmask> <networkInterfaceId>11122</networkInterfaceId> <networkIpAddress>10.180.5.211</networkIpAddress> <nicId>11122</nicId> <nicName>vNIC</nicName> <subnetworkId>9802</subnetworkId> <subnetworkName>Management Network</subnetworkName> <vlanId>100</vlanId>
314
</networkBackendResources> <serverHostName>vmw010180005211</serverHostName> <serverId>11075</serverId> <serverName>vmw010180005211</serverName> </serverResources> </backendResourceReport>
List service deployment instance data model inconsistencies

This function checks the Tivoli Service Automation Manager service deployment instance topology tree and validates its nodes with DCM and other internal structures.
URL:
The function gathers inconsistencies between the internal structures and returns a list of discovered problems. https://[hostname]:[port]/maxrest/rest/validate/[sdi_id] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v sdi_id a numerical value for the service deployment instance ID in Tivoli Service Automation Manager.
Http error codes:

Error code 200 Description Successful invocation with XML response: <errors> <error> <code>[ERROR_CODE]</code> <type>[ERROR_TYPE]</type> <objectName>[OBJECT_NAME]</objectName> <value>[VALUE]</value> <objectType>[OBJECT_TYPE]</objectType> <expectedValue>[EXPECTED_VALUE]</expectedValue> </error> </errors> For detailed information about the XML variables, see Values for the XML response variables. For an example response, see XML response example. 400 401 404 500 system#invalidParameter invalid or missing parameter access#validate user has not been granted the correct privilege to call the function system#unknownobject given service deployment instance ID does not exist Internal system errors
Values for the XML response variables

The XML response contains the following variables: v ERROR_CODE
315
Table 41. ERROR_CODE values Value MISSING_OBJECT INVALID_OBJECT_TYPE INVALID_OBJECT_VALUE Description Object reference cannot be found Object reference points to invalid object type Object value is improper
v ERROR_TYPE
Table 42. ERROR_TYPE values Value TOPO_VS_DCM Description Validation of the service deployment instance topology node against Data Center Model Validation of the service deployment instance and its topology against the service specification (CLOUD.PROJECT database table) Validation of the service specification against Data Center Model
TOPO_VS_BC
BC_VS_DCM
The ERROR_TYPE values are returned, based on the validation checks that are performed. v OBJECT_NAME - The name of the validated object for which an inconsistence has been detected v OBJECT_TYPE - The type of the validated object v VALUE - Current detected value v EXPECTED_VALUE - The value the check was performed against for error types: INVALID_OBJECT_TYPE, INVALID_OBJECT_VALUE, or both
XML response example

<error> <code>INVALID_OBJECT_VALUE</code> <type>TOPO_VS_DCM</type> <objectName>vmw010180005206</objectName> <value>120</value> <objectType>PMRDPCLCVS_STORAGE_SIZE</objectType> <expectedValue>12</expectedValue> </error>
The error describes an invalid value of the attribute PMRDPCLCVS_STORAGE_SIZE of Tivoli Service Automation Manager topology node called vmw010180005206. The node attribute value is set to 120, whereas DCM points to value 12. The inconsistence might be caused by the change of the storage size for the virtual server, done without using Tivoli Service Automation Manager.
Validation checks
Based on what is validated during the check, one of the three values for ERROR_TYPE are assigned.
316
TOPO_VS_DCM validation checks: This topic lists the validation checks that return the TOPO_VS_DCM value. See your validation response to locate the inconsistencies in the topology nodes and Data Center Model. The following validation checks are performed: v Project topology node PMRDPCLCPR classification Validate attribute PMRDPCLCRP_APPLID if it is set and points to an existing DCM application object (MISSING_OBJECT or INVALID_OBJECT_TYPE, PMRDPCLCRP_APPLID) v Software stack topology node PMRDPCLCSWS classification Check if attribute PMRDPCLSWS_IMAGEID is set and points to an existing DCM software stack object (MISSING_OBJECT or INVALID_OBJECT_TYPE, PMRDPCLSWS_IMAGEID) v Virtual server node PMRDPCLCVS classification Validate attribute PMRDPCLCVS_TPMDCMID_VSERVER if it is set and points to an existing DCM virtual server object (MISSING_OBJECT or INVALID_OBJECT_TYPE, PMRDPCLCVS_TPMDCMID_VSERVER) v For an existing virtual server node: If the value of PMRDPCLCVS_STORAGE_SIZE topology node attribute is the same as the value of the resource allocation in DCM (MISSING_OBJECT or INVALID_OBJECT_VALUE, PMRDPCLCVS_STORAGE_SIZE) If the value of PMRDPCLCVS_MEMORY topology node attribute is the same as the value of the resource allocation in DCM (MISSING_OBJECT or INVALID_OBJECT_VALUE, PMRDPCLCVS_MEMORY) If the value of PMRDPCLCVS_NUMBER_CPUS topology node attribute is the same as the value of the resource allocation in DCM (MISSING_OBJECT or INVALID_OBJECT_VALUE, PMRDPCLCVS_NUMBER_CPUS) If the value of PMRDPCLCVS_NUMBER_PCPUS topology node attribute is the same as the value of the resource allocation in DCM (MISSING_OBJECT or INVALID_OBJECT_VALUE, PMRDPCLCVS_NUMBER_PCPUS) If the value of PMRDPCL_SWAP_SIZE topology node attribute is the same as the value of the DCM server property parameterswapSizeMB (MISSING_OBJECT or INVALID_OBJECT_VALUE, PMRDPCL_SWAP_SIZE) If the value of PMZHB_NETWORK_INTERFACE_IP_ADDRESS topology node attribute is the same as the value of the IP address list stored in DCM (MISSING_OBJECT orINVALID_OBJECT_VALUE, PMZHB_NETWORK_INTERFACE_IP_ADDRESS) TOPO_VS_BC validation checks: Validation checks that return the TOPO_VS_BC value. v Validate if the status of the service deployment instance corresponds to the status stored in the service specification (MISSING_OBJECT or INVALID_OBJECT_VALUE, STATUS) v Validate if the topology of the service deployment instance contains the same number of virtual server nodes as the service specification (INVALID_OBJECT_VALUE, SERVERS_SIZE) v Validate if the virtual server nodes of the service deployment instance point to the same DCM IDs as the virtual servers stored in the service specification (MISSING_OBJECT, VIRTUAL_SERVER_NODE)
317
v Validate if the virtual servers of the service specification point to the same DCM IDs as the virtual servers stored as topology nodes (MISSING_OBJECT, SERVER) v Validate if the end date of the service deployment instance is correct, based on current status (MISSING_OBJECT, END_DATE) v Validate if the end dates of the service deployment instance and the service specification match together (INVALID_OBJECT_VALUE, END_DATE) v Validate if the start date of the service deployment instance is correct, based on current status (MISSING_OBJECT, START_DATE) v Validate if the start dates of service deployment instance and service specification match together (INVALID_OBJECT_VALUE, START_DATE) v Validate if the start time of the service specification matches the start time of the reservation (INVALID_OBJECT_VALUE, Start time) v Validate if the end time of the service specification matches the end time of the reservation (INVALID_OBJECT_VALUE, End time) v Validate if service specification state is correct against reservation dates (INVALID_OBJECT_VALUE, Reservation) BC_VS_DCM validation checks: This topic lists the validation checks that return the BC_VS_DCM value. See your validation response to locate the inconsistencies in the cloud subsystem and Data Center Model. v Validate if service specification servers contain the same IP addresses list as in the related DCM virtual server (INVALID_OBJECT_VALUE, NETWORKS_SIZE), (MISSING_OBJECT_ERROR, IP_ADDRESS) v Validate if the template of the DCM virtual server contains a valid pointer to a DCM cluster (MISSING_OBJECT, Cluster) v Validate the disk size of the service specification server against the disk size of the DCM virtual server (INVALID_OBJECT_VALUE, Storage) v Validate the physical CPU number of the service specification server against the physical CPU number of the DCM virtual server (INVALID_OBJECT_VALUE, PCpu) v Validate the virtual CPU number of the service specification server against the virtual cpu number of the DCM virtual server (INVALID_OBJECT_VALUE, VCpu) v Validate the memory size of the service specification server against the memory size of the DCM virtual server (INVALID_OBJECT_VALUE, Memory) v Validate the cluster pointer of the service specification server against the cluster property of the DCM virtual server (INVALID_OBJECT_VALUE, cloud-cluster-id) v Validate the swap memory size of the service specification server against the swap memory size property of the DCM virtual server (INVALID_OBJECT_VALUE, swapSizeMB) v Validate the software image pointer of the service specification server against the image ID property of the DCM virtual server (INVALID_OBJECT_VALUE, VM_IMAGE_SW_INST_ID)
318
Provide service request current status

You can use this function to receive the current service request status.
URL:
If the service request does not exist, the function returns a specific status, for example, UNKNOWN. Otherwise, the status stored in the TPAe data model is returned. https://[hostname]:[port]/maxrest/rest/requestStatus/[sr_id] v hostname the IP address or the name of the computer on which Tivoli Service Automation Manager is installed. v port a numerical value for the port, based on the value indicated during the Tivoli Service Automation Manager installation. The default port value is 9443. v sr_id a numerical value for the service request ID in Tivoli Service Automation Manager.
Http error codes:

Error code 200 Description Successful invocation with XML response: <serviceRequestStatus> <status>[CURRENT_STATUS]</status> </serviceRequestStatus> If the sr_id parameter points to a service request that cannot be found in the data model, UNKNOWN status is returned to the caller. 400 401 system#invalidParameter invalid or missing parameter access#getServiceRequestStatus user has not been granted the privilege required to call the function Internal system errors
500
BIRT reports
BIRT (Business Intelligence and Reporting Tools) reports are available for some of the RAS functions. For information about how to generate automation reports, refer to Working with the service automation reports on page 243. Three types of BIRT reports can be generated: Virtual server synchronization report This report is based on the List virtual servers on given host platform and in DCM function and lists virtual servers and their status. Service deployment instance inconsistencies report This report is based on the List Tivoli Service Automation Manager service deployment instance data model inconsistencies function and lists all discovered problems.
319
Ticket related objects report This report is based on data model queries and gathers all DCM objects modified during service request processing.
Virtual server synchronization report

The report shows the list of virtual servers based on the List virtual servers on a given host platform and in DCM function and lists virtual servers and their status. Two parameters must be specified for the report: hostplatform id The DCM ID of the host platform that represents the hypervisor. timeout The number of seconds the core logic waits for, until the internal workflow that gathers virtual server names from hypervisor is finished. The report consists of three columns: Virtual server on host Server name retrieved from the hypervisor. Virtual server in Data Center Model Server name retrieved from DCM. Status Servers existing only on the hypervisor are marked as phantom servers, while servers existing only in DCM are marked as orphan servers. If the server is correctly located on the hypervisor and in DCM, the status is OK. Otherwise, delete the server existing on the hypervisor or in DCM and repeat the server allocation procedure. For more information about the related function, refer to List virtual servers on given host platform on page 309.
Service deployment instance inconsistencies report

The report is based on the List Tivoli Service Automation Manager service deployment instance data model inconsistencies function and displays all discovered problems. One parameter must be specified for this report: name The name of the service deployment instance. Ensure that every server has different name to avoid name conflicts.
Errors are grouped into 3 categories depending on which area of the inconsistency: v Topology - Service Specification v Topology - DCM Object v Service Specification - DCM Object These categories correspond to the ERROR_TYPE values described in Values for the XML response variables on page 315. Each inconsistency is described using the following columns: v Object name v Object type name v Value v Error codes (Invalid object value, Invalid type value, Missing object)
320
v Expected value (in case of invalid object or invalid type value) For the description of these columns refer to the XML variables described in Values for the XML response variables on page 315. For more information about the related function, refer to List service deployment instance data model inconsistencies on page 315.
Ticket related objects report

The report is based on data model queries and gathers all DCM objects modified during ticket (service request) processing. The report accepts a service request ID as a parameter and queries for all deployment requests and activity plans triggered by a given ticket fulfillment process and all DCM objects affected by those actions. To successfully generate this report, add the DCM.object.track.changes variable in the administrative user interface: 1. Log on to the administrative user interface. 2. Navigate to Go To > Administration > Provisioning > Provisioning Global Settings. 3. Select the Variables tab. 4. Click New Row and enter: v Variable: DCM.object.track.changes v Value: True 5. Accept by clicking New Row button. One parameters must be specified for the report: ticket id The main report lists activity plans and deployment requests started within the context of given ticket ID. The report consists of five columns: Name The name of the activity plan or the deployment request retrieved from the hypervisor. Description The description of the activity plan or the deployment request. Reference ID The numerical ID of the activity plan or the deployment request. Reference type Either the activity plan or the deployment request. Modification time The time when the activity plan or the deployment request was started. When selecting a specific deployment request ID from the list, another reports can be displayed: DCM object modifications Lists DCM objects modified by deployment requests hierarchy, starting from provided deployment request ID.
321
Objects are grouped by specific deployment requests. Each modification entry contains a DCM object ID, which is a hyperlink that displays the report of Data Center Model object properties. If the DCM object doesn't contain any properties, the link is inactive. Data Center Model object properties Lists properties of DCM object, based on the DCM object ID. The properties are listed according to the property key and its value.
Best practices for using reliability, availability, and serviceability functions

Learn how to improve the functionality within reliability, availability, and serviceability (RAS).
Rolling back the resource workflow modification process

Every deployment request or activity plan that is started within the Tivoli Service Automation Manager service request flags the affected DCM objects and the type of the operation performed. Therefore, it is possible to roll back the resource workflow by comparing the DCM data model and the resources of the virtual server on the hypervisor.
Procedure
1. Generate a Ticket related objects BIRT report. 2. Check the ID of the server that is being modified by the workflow. 3. Compare the resources in the DCM data model with those in the virtual servers. a. With the ID of the virtual server that is being modified, check the DCM data and name of the virtual server on the administrative user interface. To do this, select Provisioning Computers in the Automation Development Applications tab. b. Use the name of the virtual server, check the resources of the virtual server on the hypervisor. 4. Depending on the status of the DCM data and the resources on the hypervisor: v If the DCM data and the resources on the hypervisor are identical: If the resources have been modified, change the workflow status to Resolved. If the resources have not been modified, change the workflow status to Canceled. v If the DCM data and the resources on the hypervisor are different: a. Check the workflow process. b. Modify the virtual server using the system script command from the workflow process. c. When DCM data and resources are consistent, change the status depending on the status of the resources before or after modification to either Resolved or Canceled. Related concepts BIRT reports on page 319 BIRT (Business Intelligence and Reporting Tools) reports are available for some of the RAS functions.
322
Removing a host platform

You can delete a host platform from the Tivoli Service Automation Manager data model if it is no longer in use.
Procedure
1. If hosts exist on the host platform, run deleteVMs rest call to remove the virtual machines and templates. 2. Remove the host platform from the DCM: a. Log on to the administrative user interface. b. In the Start Center, in the Automation Development Applications tab, click Virtualization Management. c. Select the host platform. d. From the Select Action list at the top of the administrative user interface, select Delete Host Platform.
Tracking VM Provisioning request by DCM objects

The Ticket related objects BIRT report improves the process of tracking objects affected by the provisioning request.
Procedure
1. Log on to the administrative user interface. 2. Navigate to Go To > Service Automation > Service Deployment Instances. 3. Click the Service Requests tab. 4. In the Service Requests section, retrieve the service request ID. 5. Use the ID to generate the Ticket related objects BIRT report as described in BIRT reports on page 319.
Checking the service request status

The service deployment instance can be scheduled to be performed at a specific time. You can check the service request status, especially if the system fails before provisioning is resolved.
Procedure
1. Open the browser. 2. Invoke the requestStatus rest call using the ID of the service request you want to check. Related reference Provide service request current status on page 319 You can use this function to receive the current service request status.
323
Unlocking hanging requests

The Resource_Master workflow can stop for a considerable amount of time while trying to modify a DCM object.
Procedure
1. Generate the Ticked related objects BIRT report to verify if the Resource_Master workflow is stopped. 2. Log on to the administrative user interface. 3. Navigate to Go To > Service Automation > Configuration > Cloud Properties. 4. Select the Provisioning Global Settings tab. 5. Set a value for Cloud.MAX_CONCURRENT_SERVER_OPERATIONS, depending on the number of workflows. 6. Click Save Properties. The workflows resume automatically.
Insufficient resources on the Tivoli Service Automation Manager self-service user interface
The self-service user interface can show that there are insufficient resources despite the hypervisor management console showing that resources are available. This problem can be caused either by phantom servers or by resource allocation to deprecated or inconsistent projects, or by both the phantom servers and the resource allocation. Phantom servers Servers that are present in the Data Center Model (DCM) but not on the hypervisor are marked as phantoms. These servers are still considered valid by the Tivoli Service Automation Manager resource checking engine and are taken into consideration during capacity checking. Phantom servers are removed by deleting virtual servers from the data model. Resources locked to deprecated or inconsistent projects The existing reservation records can block resources for invalid, inconsistent, or expired projects, although these resources are not booked or used.
Removing phantom servers

Learn how to remove phantom servers from the data model to free resources on the Tivoli Service Automation Manager self-service user interface.
Procedure
1. Find inconsistent data between the Tivoli Service Automation Manager data model and virtual servers on the host platform by running Virtual server synchronization BIRT report. For more information, see Virtual server synchronization report on page 320. 2. If a project or service deployment instance contains: v Only phantom servers or servers to be removed, delete the servers using hypervisor management console or Tivoli Service Automation Manager applications. Run the Force cleanup of service deployment instance function, providing the service deployment instance ID as an input. The service deployment instance ID is listed in the MAXIMO.PMZHBSSVCI database table. For more information, see Force cleanup of service deployment instance on page 311.
324
v Both valid and phantom servers, delete the phantom ones using the Tivoli Provisioning Manager Provisioning Computers application. 3. After deleting all phantom servers, run the Virtual server synchronization report to make sure that the data model no longer contains phantom servers.
Freeing resources locked to deprecated or inconsistent projects

Learn how to remove projects that are no longer in use.
Procedure
1. Find all invalid projects that point to a valid reference. These projects can include projects for which decommissioning has failed or project with an invalid general status. For more information, seeList service deployment instance data model inconsistencies on page 315. 2. If a project is no longer used and can be removed, run List service deployment instance backend resources and Force cleanup of service deployment instance functions. For more information, see List service deployment instance backend resources on page 312 and Force cleanup of service deployment instance on page 311.
325
326
Chapter 7. REST API reference

This section provides reference information about the REST APIs delivered with Tivoli Service Automation Manager.
Structure of the REST URLs used for the 'query' request

Use the REST URL for the 'query' type of request. The REST queries can have different URL content. An example URL is http://localhost:9080/maxrest/rest/os/osname/id?_sattr&attr1=x&attr2=y. It consists of the following elements: v http://localhost:9080 is dependent on the host and the security protocol chosen v /maxrest/rest is a fixed element that addresses the REST servlet v /os is the prefix for object structure query v /osname specifies the name of the object structure as defined in the Tivoli Process Automation Engine object structure application v /id specifies the unique ID of the top level MBO (Maximo Business Object) v ? is the delimiter to the passed attributes v _sattr are all the REST-specific system attributes that modify the request. Refer to the REST reserved attributes section below for the list of these attributes. v Attr1=x,attr2=y are the QBE query attributes. Refer to the Restricting resource sets of a query to specified elements section below for the list of these attributes. The layout of the response document is based on the definition of the object structure. Note: http://localhost:9080/maxrest/rest/os/SRM_SR This REST request shows the service request that exists in the current system.
Restricting resource sets of a query to specified elements (QBE filtering)

The Tivoli Process Automation Engine REST enablement provides a query language to filter the REST queries. This language is called Query by Example (QBE). The supported syntax is Attribute=Operator Value: v = value. Attribute is like value. v =~eq~ value. Attribute equals value. v =~neq~ value. Attribute does not equal value. v =~gt~ value. Attribute is greater than value.
327
v v v v v
=~gteq~ value. Attribute is greater or equals value. =~lt~ value. Attribute is less than value. =~lteq~ value. Attribute is less or equals value. =~ew~ value. Attribute ends with value. =~sw~ value. Attribute starts with value.
Note: Relationship.Attribute operator value: The relationship must exist on the main MBO and the attribute must exist on the MBO he relationship refers to. All operators from the list above are supported. Note: You can specify multiple attributes by combining these statements using &. Example: Sample ID=10&NAME=TEST&COLOR=~sw~RED.
REST reserved attributes

This is a set of REST reserved attributes that are a part of the REST URL. All of them start with an underscore. v _format - specifies the format of the response. By default, the two supported values are json and xml. v _dropnulls - a Boolean value. Set it to true or 1 to drop all null-valued attributes from the response. The default is 1. v _rootonly - a Boolean value. Set it to true to serialize only the root (primary) object of the object structure. This attribute is valid only for the "os" resource type. The default is 0. v _locale - a Boolean value. Set it to true to add the user's locale-specific text version of the MBO attribute to the strong-typed value. v _keys - a Boolean value. Set it to true to serialize only the key attributes of the MBO and drop all other attributes from the response. The default is 0. v _rsStart - a numeric value. It indicates the start index of the MBO in the MBOSet resource that is serialized as part of the response for the resource request. v _maxItems - a numeric value. It indicates the maximum number of MBOs that are serialized in the MBOSet resource that is serialized as part of the response for the resource request. In conjunction with the _rsStart, this attribute can be used for paging the response when the response is too big. v _includecols - a comma-separated list of MBO attributes that are included as part of the response. All other attributes are dropped. This attribute is valid only for the "MBO" resource type as the "os" resource type has the include/exclude value predefined in the object structure configuration. v _excludecols - a comma-separated list of MBO attributes that are excluded as part of the response. This attribute is valid only for the "MBO" resource type as the "os" resource type has the include/exclude value predefined in the object structure configuration. v _lid / _lpwd - the login ID and password. This attribute is used primarily for testing purposes as the credentials passed around as the part of the URL query string potentially create security hazards. This attribute is valid only when the Maximo authentication is used. The preferred way is to use the MAXAUTH header that contains the base64 encoded "userid : password" for the Maximo authentication. Since the server side maintains the session, this value only needs to be provided only on the first request. For j2ee-based authentication, use the basic authentication header. v _exactmatch- a Boolean value. If it is set to 1, it uses the QBE values as an exact match instead of performing a "like" operation. The default is 0.
328
v _orderbyasc / _orderbydesc - a comma-separated list of MBO attributes that are used for the order by clause when performing a query. v _generic - a Boolean value. Set it to 1 to serialize the resource (response) in a generic format. Valid only for the "json" format. v _md - a Boolean value. Set it to 1 to serialize the resource (response) including the metadata information for each attribute. Example: ResourceId, Hidden, Read-only. v _compact - a Boolean value. Set it to 1 to serialize the resource (response) in a very compact JSON format. In addition, the attribute sets _md to 0 and _generic to 0 and is only valid for the JSON format. v _opmodeor - a Boolean value. Set it to 1 to pair together the attribute operator values used for filtering the query. v _fd - specifies the table domain that filters the main object. The table domain is used to filter the main object in the REST query. The object must be the same as the main object to query. Set this attribute to true to use the list with the clause and the QBE is used to retrieve the result set. This list can only contain plain SQL. There is one addition, the ":user" attribute that contains the name of the user that is currently logged on. A table domain can contain different definitions based on site and og values. These two values are specified by the _fdsite and _fdorg attributes. v _fdsite - specifies the site value for the _fd query. v _fdorg - specifies the org value for the _fd query.
Tivoli Process Automation engine base object queries

This section provides information about the Tivoli Process Automation engine base objects queries.
Get domain definitions (MAXDOMAIN)

Retrieves a list of defined domain definitions. A domain can be one of several different types. The object structure returns the union of all possible domains, and should be used with filtering based on the domainid attribute. It returns the union of all possible maxdomain types. The return data structure depends on the type of the selected domain (e.g. ALNDOMAIN, SYNONYMDOMAIN). Object structure name: MBS_MAXDOMAIN Sample URL: http://localhost:9080/maxrest/rest/os/MBS_MAXDOMAIN?_lid=bill &_lpwd=maxadmin&DOMAINID=SRSTATUS Retrieve SR status list: http://localhost:9080/maxrest/rest/os/ MBS_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin&_exactmatch=1 &DOMAINID=SRSTATUS Retrieve PMSCMR status list: http://localhost:9080/maxrest/rest/os/ MBS_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin&_exactmatch=1 &DOMAINID=MRSTATUS
329
Retrieve Service Instance status list: http://localhost:9080/maxrest/rest/os/ MBS_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin&_exactmatch=1 &DOMAINID=PMZHBSISTATUS Retrieve Locale list: http://localhost:9080/maxrest/rest/os/ MBS_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin&_exactmatch=1 &DOMAINID=LOCALE Retrieve Timezone list: http://localhost:9080/maxrest/rest/os/ MBS_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin&_exactmatch=1 &DOMAINID=TIMEZONE
Object structure definition

Table 43. Object structure definition for MBS_MAXDOMAIN Object MAXDOMAIN ALNDOMAIN MAXTABLEDOMAIN CROSSOVERDOMAIN MAXDOMAIN MAXDOMAIN MAXTABLEDOMAIN Parent Object Object Location Path MAXDOMAIN MAXDOMAIN/ ALNDOMAIN MAXDOMAIN/ MAXTABLEDOMAIN MAXDOMAIN/ MAXTABLEDOMAIN/ CROSSOVERDOMAIN MAXDOMAIN/ NUMERICDOMAIN ALNDOMAINVALUE MAXTABLEDOMAIN CROSSOVERDOMAIN Relationship
NUMERICDOMAIN
MAXDOMAIN
NUMDOMAINVALUE
Query output
<QueryMBS_MAXDOMAINResponse <?xml version="1.0" encoding="UTF-8" ?> <querymbs_maxdomainresponse creationdatetime="2010-06-24T15:10:32+02:00" translanguage="EN" baselanguage="EN" messageid="1277385032688483723" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_maxdomainset> <maxdomain> <description>SRSTATUS</description> <domainid>SRSTATUS</domainid> <domaintype>SYNONYM</domaintype> <internal>0</internal> <length>10</length> <maxdomainid>89</maxdomainid> <maxtype>UPPER</maxtype> <scale>0</scale> <synonymdomain> <defaults>1</defaults> <description>Approved by Fulfillment Manager</description> <maxvalue>APPFM</maxvalue>
330
<orgid /> <pluspcustomer /> <siteid /> <synonymdomainid>1943</synonymdomainid> <value>APPFM</value> <valueid>SRSTATUS|APPFM</valueid> </synonymdomain> <maxdomvalcond> <conditionnum>PMSCSHOWCR</conditionnum> <maxdomvalcondid>23</maxdomvalcondid> <objectname>SR</objectname> <valueid>SRSTATUS|APPR</valueid> </maxdomvalcond> </maxdomain> </mbs_maxdomainset> </querymbs_maxdomainresponse>
Get list of installed and enabled languages (LANGUAGE)

Returns the language information that will be used by create user. The structure must be filtered by ENABLED=1 because only enabled languages are displayed. Object structure name: MBS_LANGUAGE Sample URL: http://localhost:9080/maxrest/rest/os/MBS_LANGUAGE?_lid=maxadmin &_lpwd=maxadmin&ENABLED=1

Table 44. Object structure definition for MBS_LANGUAGE Object LANGUAGE Parent Object Object Location Path Relationship LANGUAGE
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_languageresponse creationdatetime="2010-06-24T15:13:27+02:00" translanguage="EN" baselanguage="EN" messageid="1277385207188435934" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_languageset> <language> <enabled>1</enabled> <languageid>180208</languageid> <languagename>English</languagename> <maxlangcode>EN</maxlangcode> <oralangabrv>US</oralangabrv> <userdefined>0</userdefined> </language> </mbs_languageset> </querymbs_languageresponse>
331
Get list of person groups (PERSONGROUP)

Returns the list of all person groups in the system. Object structure name: MBS_PERSONGROUP Sample URL: http://localhost:9080/maxrest/rest/os/ MBS_PERSONGROUP?_lid=maxadmin&_lpwd=maxadmin

Table 45. Object structure definition for MBS_PERSONGROUP Object PERSONGROUP Parent Object Object Location Path Relationship PERSONGROUP
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_persongroupresponse creationdatetime="2010-06-24T15:15:32+02:00" translanguage="EN" baselanguage="EN" messageid="1277385332407424466" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_persongroupset> <persongroup> <cloudteam>1</cloudteam> <description>MYTEAM1 Description</description> <persongroup>MYTEAM1</persongroup> <persongroupid>73</persongroupid> <pmrdpprojectaccount>SCHATZKISTE</pmrdpprojectaccount> </persongroup> </mbs_persongroupset> </querymbs_persongroupresponse>
Get person group details (PERSONGROUPDET)

Returns details about a person group, including the persons in the group. Object structure name: MBS_PERSONGROUPDET Sample URL: http://localhost:9080/maxrest/rest/os/ MBS_PERSONGRPDET?_lid=maxadmin&_lpwd=maxadmin Get details for a specific person group: http://localhost:9080/maxrest/rest/os/ MBS_PERSONGRPDET?_lid=maxadmin&_lpwd=maxadmin &_exactmatch=1&PERSONGROUP=SAFETY
332

Table 46. Object structure definition for MBS_PERSONGROUPDET Object PERSONGROUP PERSON PERSONGROUP Parent Object Object Location Path PERSONGROUP PERSONGROUP/PERSON ALLPEOPLEINPERSONGROUP Relationship
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_persongroupdetresponse creationdatetime="2010-06-24T15:18:10+02:00" translanguage="EN" baselanguage="EN" messageid="1277385490282502418" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_persongroupdetset> <persongroup> <cloudteam>1</cloudteam> <description>MYTEAM1 Description</description> <persongroup>MYTEAM1</persongroup> <persongroupid>73</persongroupid> <pmrdpprojectaccount>SCHATZKISTE</pmrdpprojectaccount> <person> <displayname>TSAM CloudAdmin</displayname> <firstname>TSAM</firstname> <lastname>CloudAdmin</lastname> <personid>PMRDPCAUSR</personid> <pluspcompanyorgid /> <pluspcustomer /> <pluspcustvendor /> <pluspcustvndtype>INTERNAL</pluspcustvndtype> <searchlanguage /> <status>ACTIVE</status> <vip xsi:nil="true" /> </person> </persongroup> </mbs_persongroupdetset> </querymbs_persongroupdetresponse>
Get list of users (MAXUSER)

Returns a list of all users in the system. Object structure name: MBS_MAXUSER Sample URL: http://localhost:9080/maxrest/rest/os/MBS_MAXUSER?_lid=maxadmin &_lpwd=maxadmin

Table 47. Object structure definition for MBS_MAXUSER Object MAXUSER Parent Object Object Location Path Relationship MAXUSER
333
Table 47. Object structure definition for MBS_MAXUSER (continued) Object PERSON Parent Object MAXUSER Object Location Path Relationship MAXUSER/PERSON PERSON
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_maxuserresponse creationdatetime="2010-06-24T15:20:40+02:00" translanguage="EN" baselanguage="EN" messageid="1277385640548319385" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_maxuserset> <maxuser> <maxuserid>103</maxuserid> <personid>PMRDPCAUSR</personid> <status>ACTIVE</status> <userid>PMRDPCAUSR</userid> <person> <displayname>TSAM CloudAdmin</displayname> <firstname>TSAM</firstname> <lastname>CloudAdmin</lastname> <personid>PMRDPCAUSR</personid> <pluspcompanyorgid /> <pluspcustomer /> <pluspcustvendor /> <pluspcustvndtype>INTERNAL</pluspcustvndtype> <searchlanguage /> <status>ACTIVE</status> </person> </maxuser> </mbs_maxuserset> </querymbs_maxuserresponse>
Get list of user details (MAXUSERDET)

Returns a list of all users in the system with some associated personal information. Object structure name: MBS_MAXUSERDET Sample URL: http://localhost:9080/maxrest/rest/os/ MBS_MAXUSERDET?_lid=maxadmin&_lpwd=maxadmin

Table 48. Object structure definition for MBS_MAXUSERDET Object MAXUSER PERSON EMAIL MAXUSER PERSON Parent Object Object Location Path Relationship MAXUSER MAXUSER/PERSON PERSON MAXUSER/ PERSON/EMAIL PRIMARYEMAIL
334
Table 48. Object structure definition for MBS_MAXUSERDET (continued) Object PHONE SITE Parent Object PERSON MAXUSER Object Location Path Relationship MAXUSER/ PERSON/PHONE MAXUSER/SITE PHONE DEFSITE
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_maxuserdetresponse creationdatetime="2010-06-24T15:22:35+02:00" translanguage="EN" baselanguage="EN" messageid="1277385755173382105" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_maxuserdetset> <maxuser> <defstoreroom /> <loginid>PMRDPCAUSR</loginid> <maxuserid>103</maxuserid> <memo /> <personid>PMRDPCAUSR</personid> <pwhintquestion /> <status>ACTIVE</status> <storeroomsite /> <userid>PMRDPCAUSR</userid> <person> <addressline1 /> <addressline2 /> <addressline3 /> <city /> <country /> <county /> <delegate /> <delegatetodate xsi:nil="true" /> <department /> <displayname>TSAM CloudAdmin</displayname> <firstname>TSAM</firstname> <langcode>EN</langcode> <language>EN</language> <lastname>CloudAdmin</lastname> <locale>en</locale> <location /> <locationsite /> <personid>PMRDPCAUSR</personid> <personuid>178</personuid> <pluspcompanyorgid /> <pluspcustomer /> <pluspcustvendor /> <pluspcustvndtype>INTERNAL</pluspcustvndtype> <postalcode /> <primaryemail>pmrdpcausr@localhost</primaryemail> <primaryphone /> <searchlanguage /> <stateprovince /> <status>ACTIVE</status> <statusdate>2009-10-08T15:56:11+02:00</statusdate> <supervisor />
335
<timezone /> <title /> <vip xsi:nil="true" /> <email> <emailaddress>pmrdpcausr@localhost</emailaddress> <isprimary>1</isprimary> <type /> </email> </person> <site> <active>1</active> <description>PMSCRTP MA Site of PMSC Inc. North America</description> <orgid>PMSCIBM</orgid> <siteid>PMSCRTP</siteid> </site> </maxuser> </mbs_maxuserdetset> </querymbs_maxuserdetresponse>
Get list of security groups (MAXGROUP)

Returns a list of security groups in the system. Object structure name: MBS_MAXGROUP Sample URL: http://localhost:9080/maxrest/rest/os/MBS_MAXGROUP?_lid=maxadmin &_lpwd=maxadmin

Table 49. Object structure definition for MBS_MAXGROUP Object MAXGROUP LONGDESCRIPTION MAXGROUP Parent Object Object Location Path Relationship MAXGROUP MAXGROUP/ LONGDESC LONGDESCRIPTION
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_maxgroupresponse creationdatetime="2010-06-24T15:26:56+02:00" translanguage="EN" baselanguage="EN" messageid="1277386016313582240" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_maxgroupset> <maxgroup> <description>TSAM - Cloud Administrator User Group</description> <groupname>PMRDPCA</groupname> <independent>1</independent> <maxgroupid>163</maxgroupid> <pluspauthallcust>0</pluspauthallcust> <pluspauthcustvnd>0</pluspauthcustvnd> <pluspauthgrplst>0</pluspauthgrplst> <pluspauthnoncust>0</pluspauthnoncust> <pluspauthperslst>0</pluspauthperslst>
336
<plusprestrictopt /> <pmsccreatedatarestrict>0</pmsccreatedatarestrict> <sctemplateid>74</sctemplateid> </maxgroup> </mbs_maxgroupset> </querymbs_maxgroupresponse>
Get security group users (GROUPUSER)

Returns the maxuser to groupuser relationship. Object structure name: MBS_GROUPUSER Sample URL: http://localhost:9080/maxrest/rest/os/ MBS_GROUPUSER?_lid=maxadmin&_lpwd=maxadmin

Table 50. Object structure definition for MBS_GROUPUSER Object GROUPUSER Parent Object Object Location Path Relationship GROUPUSER
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_groupuserresponse creationdatetime="2010-06-24T15:33:43+02:00" translanguage="EN" baselanguage="EN" messageid="1277386423782822646" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_groupuserset> <groupuser> <groupname>PMRDPCA</groupname> <groupuserid>838</groupuserid> <userid>PMRDPCAUSR</userid> </groupuser> </mbs_groupuserset> </querymbs_groupuserresponse>
Get Images (IMGLIB)

Returns image library entries. Each record describes an icon on the screen. Object structure name: MBS_IMGLIB Sample URL: http://localhost:9080/maxrest/rest/os/MBS_IMGLIB?_lid=maxadmin &_lpwd=maxadmin
337

Table 51. Object structure definition for MBS_IMGLIB Object IMGLIB Parent Object Object Location Path Relationship IMGLIB
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_imglibresponse creationdatetime="2010-06-24T15:04:34+02:00" translanguage="EN" baselanguage="EN" messageid="1277384674610911329" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_imglibset> <imglib> <image>R0lGODlhZABkAPf/AP///8DDusvU2aSzx/6tENXay5uVdf//3Pn6/P/hTP/ njI6S0KSWjKebav/ka+fmuNLb6XOcyWN5p7q3+rjFyNrh7Onr5f//+aanmcC+oMDAs8rU4cjJ6niFl+ jpx4mLVYyLiJaUi/j5++bX/JaEeLe4p5WmuMPL2/z8/bjH2f//9ert6srKo9bV++Tm2/+dBZaowvT2+ drfyPvLb9zE/v//8fb4+va4TNW5/py5yHKIqHyXtJealqWrp/v7/Ozw9omEff7+/v///Kq2vEhkkv/// vLZjYWoyeXq8tvh23t4df//7aqn/o6hvIqUl8rI//7+////6f/ WJ6nEyv72ysnMytnb23uhyefq4vHy7NPUtFlynIZ5dfP1+Pr7/NLZ0ra31tbRmP//4 ZaMgPuuMM7ezfDy9tDS0nWCjP//5ayhbuvh/Onu9KSjU9jScPLp/3d3bLa3nNi9erC7xfb29f+/ GZe60rqzesjDlKao1La7trOc1fb59YqatbnPzKy70MLFwIJrZv/ eNYKMlYKVtPDssreo1KiutPL03Pj59eHi47KpdNLNkniOsYqdvHF9iKigea62ru7v6MvCiayr69vd1GqBqI97cvHz1IZybdPa38G +//n67nhpZP/MIW13gdvYpvj58aKjxb24he3q+ra16/X28rKu+/Lz4vn66ebo3vThqLOqhufp7eHO/ MG309nHg4OdtMPIxIWYuVFrl5yjpenq02x+noyx0c3QzK7A1vb47N/l7urt26+qouHg/ vL09YKs0fn64Z2vu9+5Z8XPzfHvwsHTxfr65+Pfhp+gmcS25Zye1mxqabOwZOTp08bZy/ v89bCdluHn8MDEzMjMxf39/sDWzIWYr/X448rPvPr2//v8+WVyffr95d7m1Kakj66wnURhkPP08Pv6/ 9DUxO7wz/r88WB5oPn77Pz9/O/x8/Hw/kJfjpCwyfT32cvM9HqPqvv+6tTY2sDVz4CBfb++8MjHz+ DhwPDz9/fx/3ZkX8XBXszMsd/g2v///yH5BAEAAP8ALAAAAABkAGQAAAj/ AP8VGSikoJALCFUorMGwxpKGDBWqQHjBoJCBRf5p3Mixo8ePIEOKBInRIEWJDZeoXKmyoUKKFjGOnEmz5kyCBU8udKgyis +fKyNORBhTps2jSEcWMZlQBcOePtNIneqzZQ2JRA1izJi0q9d/TC/shJpGjNmzYqRWfYi1olajX+ PSZDp2SRSpZw8UonLgbJq1V4e6LQhXrmGQOcU6dRjV7IHHB8jMgOw3SsuXWQkPPMzZ48GmPO86hnzgxQ3SfcUAxjy4cGfOOkOXFYNawYsXsMLo1s1oku9Rd +4sGq6muJoGyJMrX7789UzQjGejpvKiDgEyu3f3njQKuHDixRsc/2dOXvkPM2byqe/ CvkuM9zbi2xBBH4F9L158oNhvrb+1 IABCAYBGoNkVxWik3UCAFFK8MIMHEEaIDz4yyFBAAeWUk8uGVXTo4YcgfohcK+ ipl0977sEnH30i2IcAfvrtp45/ AQpI4EI9IQjZDC8wKIUnL6xiDiZEvvMOItlks0sq50QTDTfcqKOOFwjYEEM+ ZvzwAxtIIDENLxWEWUUDBpCY3nrtvReDfPHVd19++6Hg339BQGHjP4pFp+ MBRvQoiCAJCALkKkRiYuQ7SaaSTpNOSimlFyLE0AWWW3L5JZgVVGFAA3QA4OmnoIYq6qikDojnYnaVhRqPniSQgAMOuP9ah4O2eGCMOR6YY8uuvLrg66 /+BFvJsF8Ue4YVvICZiwFllogme2qyyaKL+ cWIwoz91Wgqjo1BRgUZPbqqgAPjxgrkDYzwhgce3bHiLiTwQkIms/ TWa4AGly7b7Jknpqniii3e54O12NJZJxQacXugGFQocMMLCwJKrgIUxyqIFAS8QMwk2siixxRDDGOCCbE0EUssO6CM8g4sq3zvNF /qa6aJKEYLcMAvDhznnNom7JSBZoFbHYMSK7BKxYH+ mLHGU0yRw9PuuHPEEVdcEcHVWGNd9b1eTnMGs52WKvbYovrMk3RU8EiAJ0VTPG6gQBIgxzHHUNB0DsNITbU7VWf /rfXWGnTpNbMzP5vimjdTq7OMNAa47c+p0mZW2i+0CmvFsc4qxzV0H+ PH3XboXbXVfvt9L5dIfL0vzf4i3qabL8LJX+N1mirWU6Kh1mcdrsLqasZalFEGNNBc87nToU9N9RVH+ N1EE6SPEQAbXH4xhgFIONsvtP/OBzuMOzdup+0K77lK5YAGOmvwwxPvx/ E5hI5LMMGQjvUOHTzyCDZbT0+9AAYYQ9jIRkCx3Wgx3UINMSonBUHMahLCi2Dx3tc0O9gBF/PDRd8iEA /9oUF/gzCB9LTEhnlcbxrOAkbNuuc9asnuWrS7U4ES+Jh3sOBhP3qBEVgQweEZ73gWxOD8/4 JxhFgQAg1o6MAg0PCJT3QDDdLLh5a+ AIIxFG57h5PW917IM8cRKE96og1kWMACAljnBvjgoQTp8b4cDOBpFrQgDAbxiG48YhCDUCId6xgCQEwqH5oYQwiw8AMTYdFmr8NZteJUMADV7ot5gspob MiCPr2ACmmUQQTpQQ8K4G0YoByAHQZgAhCgoRufeAQSVYnHQTiBB9WwUgySwAMeDLCAuAyVRj4TyciJkYzmMM0B0rhGP +gBA7WohTKU4QtfMIAL0AzEJ5CIBjw6wZVOCEcB+ MDNJIQDAysAhjgNh8jXuZBg4rtTYnopGjFQ0hw3mEwav/GNJJThGCUIwRiAwP/ PMYyBAZcIRCAyQVBrOqEHPYhEQsNRjmjw4Ry9CEcJJGGKiqKIe64zp8Cs1cXx7TIxdYmKMDKQAXP0ZZgZeMY3ZKCNODDAn / wEQgikMQaBChQIJADBQREaiUhoIxL9eIY3htqLfpQAFbvYhSnoQAdJYVSLiuRiDE1lkaZAzifCiEMGbCEGb4hBBnGQQTlcyoAABhCnJGAACQTKBX3yQBk9KIFc +9E PbUBDFsUQgCY08QVtaEEYlnkIUYqQSwJqZCl0qYswwhGHZ6TBG1EYqzZ8YQASWNayl8BsZscAgrcyc679KEcxNnCC0qYgBbrQxR8GMABdFAARwkBGKjjBh6b /lnNab+LoVA+L2HXupAbewEA4niEPeaShHBJV62Uze4lMXKK5JPAsBkqggX5ooRonSMEJNvCFAkzoVt/ gxQZSMAAYDIACsEUGbfkgS6iek5G7FQhOfLuQVGAAA9+Qh0q0cV9wGOAS/ kxrTfexj0zUgwe18EU4NKCFclDjtN2dED4e8IBboWIc6yDFCDhQXhicIbbpCAV72eS9qKIzW17kbW95KZFdvDUJDamGZ0NQDyBwNgQ84EInOsEFEDBTA yW4bmqLUYAKTYjChTAGJi5MCg2PwBX2gEET5iCMNFylIIUlFUdKEhaxuJgHSXBKNGTMgxCEAA71SHM9QGBZILSV /7 oMpsAfdHGGC8lAwki2MDBIsYYnu4IGOMiDI4aBCGSkIxEjTqTidItij255vry8wC6c4IQkOCkasnCCmUEAByXIFARKYABAucCDEvQDH3No7TyKVeQ7I znJmMhChvv8ZxzYWtAwKDQnEuHe3MK30Xd69Io /YwpKJ4EPTqKAE0AAAiA0oxlAqMUhGCCNalM7A/1ItS42IAABFMvIE34ArGVNaxoA2tY4KAUhTIAIb+ w6cb5mHIof2ZGtWKQgocCjJujAh0RQYBAhYHYzOs0DQPii2tUmqR6Gse0NcHvVrQ43rMfB5yef29bmzsMO5pCGJVSEsFn +1EfsbRFT4HEDpv/oAh/+zWxQK6EetQCEHkogamlMAhSiGIDDd+7 t7rpa3MZAhBk0XGt0m9sVI2hCI75g6ESIoMTvlTedHO2RrfSWDkrcgBnEOYcOqLkZnwBCDwChAQ0AZxJGGAIMTgABCOz84a3OMyrW0WdzG90VSB9BCxr RB2Ec2um4jR2jDRbsqlu9CFjvwAbWsQ4zdL0eSuABEOAABF9owA2Yd4MRwtCEP7S97Tz3dpHxAQpQ4KMSirA4uvE +ghGsYQ1vAIMOiuGNcwB+i4PvmUisnvgTsEFLj69HCMIBDnCEYxT8cEMylj+EJmwAAmH6PLe5/ QVAkBQPLKgGNQyxDIzTAOmvf8P/G/ RBCh0QIgo1qEjIPWUTxHfgFr6n3gA6AAfKg0O44XCGM5SfjFU4YgDQlyzR53YbIHORUAIZgH338AqGsAd7gAM00HqwN376sA3kMACW8A1 /F3iLNDvzVngzQQe3AH9dwgYDcAtw8AEq+AFtoH/ OMAmMAAoZMAu6AH2KADNhUgFudwiHcIAJyAIL6ICGYAiuMIEVSA5yggKaYAlDwCS3F3UwBGymUhMieAspMA1dcoIryIIt6Ax3MArp0gOxoIPJIjgCSAFD
338
MAAJVQKRkIYNOISvcA9vYIHWgALcgGgVZQmEgAyhkAgI8D2LIyfpNIU0UYUpkCzToIUr2AaM2ILA / xEG2OB8FdAKrVApXaIJFDAHc3AIwyBlUuYIohCHZ3AGrXCHdGAK45AFqigJfSABgiUE63cUhlgByXKCqkRNSDQICBYJerADMECLk5geWfIDAkAN1ICGz9MEn /h/Z5ALVZALWSAJ0mgB1GgBWDAMElAJffiHihSIHQWCI9EFI5gCOfgHhIANs9AH6qiOTTAMA+ AHgNAIf0CLNsAGZhAfknIGVXAP9yBlndd2MDALsxAAgBAAAeACqpCQv+ Irw4AO89CHHPhCjZRiVCgBt1CDOYiIJfh7+ WADfOANSSCPYRID1rIfoziKTeAINdh2KbADhDAEGhAAGlAJv6IKWIAF1P9oAujwBYnwhPEWhYRHiCF4CxKwkhnJC1iIBByZD3yQDkmgAwOQAhDQBeRQle SAANswiidwD47gCFLJkoTwkgYZAJWQkAlZjVhACOhgBRMBiyEnixJQlKk1l3RJlynAbWWgAzDAC9D3A +zwl+ xACgv4CmDgCLOgkql1BI3QCARpkAiZkDcZmSawBV9ge9wIhd8olCNBB3HZmZ75mRJgCY0wMrKglxywAWHyC032C7 / AAWBgCIJGCDuwmLRpArIACLgZmZFZjdhAmbvGgd44iHAJmsQZmnw3AEMQD41wAi0AAS3QAqz5Cy3AAXmQB8ywAAugnLSJDbh5m19AjbpZjTr /sAXq5YeAeGJBORKESAeKYAXu+Z7wCZ/zECyq0AtNYAnwkALQyZrP+ QRPkAfYuQCiIAom0AR9cAjdKQuygJPV2KAWgA6WsAQTAXJZpp4cYQMWoAgauqEb6g/vOQ/ z4J4u8AxzYAkDAA/ w8Jwt4J9PMAGnEKCioAcBcAYFSZCAIAtJsAI66qAWMAe0YALI0JMRiZ66VxPWIAJMlaRJKk6Mtw5s0ApIoKOS8A0S4AgckKIsugkuygRMwAwDqgeAcAayM JaAkKM6uqMrYAFpSgi0UAyHxiLdSKQUmRSeYidBYA3q4ANVIin5AAzjMA7ZgA0SYA /wkKVbygSnUAp5IAoE/3kG1SCTsuAPanqmlLoCxbAF5PmbQ/ prUweONVFARSAWS1AM6MAMpfAEm6Clp8ClTFAKE8ABdZYL/lAsZcmglXqmfUALQyChF7F+mvmp/2A nUAAgeIoCVPJ0MXCKuyAM8YAOpZCqh4qo9mAPHGAFOIkC42ABqoCQOHmrKyAAmCoJbwp1P5mZcQEAwkqs6rAffxgfdJBUX7AFjTAB0XoKE0CtHKAIWCAJ2Co J22qT3VqpOkAEc5AKQqpRgsepjuSpn1qndnqndainT +eRu4AMw7AFC7CqXGqv+DoPqmAB/GoKkoAFj2mrZzoARKAD7uZ0ilau8fUVBLQUThEF47kAG// rqtQKD1bwsZKgDiJrAb5ik9Woo3NABLSACunXq776q0cBKg/bH/ txrIkQCqmACDpACwtACadACR2rrxaQBT6bBdpast1atLRgBSHGa/ CWsFJXpDD7KQ97p1H7h4nACZxgtVibB1xLrfOgr5IwDupAB2K7rdx6k01gtJWQCiJGYpvqgZ3KtBsBuZE7IA5LrBErtVSLCvFABFmbB9SqCTxrCoEbjST7mN SADuJwC5UQYiPmOsCZewcjuc6xFLezBHOwBZybBxwAupKQBXSgDnwQjUDrAtRgCeIgDiaAtG0pu87BGbR7AQ5hn0RABFuADRRAAfPwu4kwDlZAAX2wBeK70A46kAQSShTM27ycAQA5 MbMWoJPiML3ve7zh2w7tQAvYQL5X4Rbni77p +7yoggUUMAw6MMADbAJDgL/5Sxj7y7/pCwCIBRo/4xCBgRkKzMAWHBKe0lsUscEbrBXsd8Eg/ BGfAmn3NhAfHMIojMGgQqEnnMIu/MIwHMMyPMM0XMM2fMM4nMM6vMM83MM+/ MNAHMRCPMREXMRGfMRInMRKvMRM3MRO/MRQHMVSPMVUXMVWfMVYnMVaDBIBAQA7</image> <imagename>services_PMSC_0001A.gif</imagename> <imglibid>1</imglibid> <mimetype>image/gif</mimetype> </imglib> </mbs_imglibset> </querymbs_imglibresponse>
Get system property values (MAXPROPVALUE)

Returns the MAXPROVALUES defined on the server. Object structure name: MBS_ MAXPROPVALUE Sample URL: http://localhost:9080/maxrest/rest/os/ MBS_MAXPROPVALUE?_lid=maxadmin&_lpwd=maxadmin &PROPNAME=mail.smtp.host

Table 52. Object structure definition for MBS_ MAXPROPVALUE Object MAXPROPVALUE Parent Object Object Location Path Relationship MAXPROPVALUE
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querymbs_maxpropvalueresponse creationdatetime="2010-06-24T14:52:00+02:00" translanguage="EN" baselanguage="EN" messageid="1277383920298798937" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <mbs_maxpropvalueset> <maxpropvalue> <propname>mail.smtp.host</propname>
339
<propvalue>localhost</propvalue> <serverhost /> <servername>COMMON</servername> </maxpropvalue> </mbs_maxpropvalueset> </querymbs_maxpropvalueresponse>
Tivoli Service Automation Manager based or modified object queries

This section provides information about Tivoli Service Automation Manager based or modified object queries.
(DEPRECATED) Get list of projects and servers (PMRDPSIVIEW)

Returns project and server information. The PMRDPSIVIEW view is no longer active in version 7.2.2, but it can be reactivated if required, as described in Reactivating the view to show projects and provisioned servers on page 104. Object structure name: PMZHBR1_PMRDPSIVIEW Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin &_exactmatch=1&SERVICEOWNER=PMSCADMUSR &REQUESTOR=PMSCADMUSR Filtered by Service instance id: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin &_exactmatch=1&PMZHBSSVCIID=2 Show me all projects: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin &_exactmatch=1&CLASSSTRUCTUREID=PMRDPCLCPR Show me all servers: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin &_exactmatch=1&CLASSSTRUCTUREID=PMRDPCLCVS

Table 53. Object structure definition for PMZHBR1_PMRDPSIVIEW Object PMRDPSIVIEW Parent Object Object Location Path Relationship PMRDPSIVIEW
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querypmzhbr1_pmrdpsiviewresponse creationdatetime="2010-06-24T14:48:19+02:00"
340
translanguage="EN" baselanguage="EN" messageid="1277383699860249925" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="4" rstotal="4" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <pmzhbr1_pmrdpsiviewset> <pmrdpsiview> <classstructureid>PMRDPCLCVS</classstructureid> <description>go test 02 project vmware</description> <name>gotest02</name> <persongroup>MYTEAM1</persongroup> <pmzhbssvciid>2</pmzhbssvciid> <pmzhbwtnid>52</pmzhbwtnid> <projectaccount /> <projendtime>2010-07-08T14:46:00+02:00</projendtime> <projstarttime>2010-06-24T14:41:59+02:00</projstarttime> <serviceowner>PMRDPCAUSR</serviceowner> <status>OPERATION</status> <statusdate>2010-06-24T14:44:12+02:00</statusdate> <type>RDP</type> <vscpu>1.0</vscpu> <vserverdcmid>server1</vserverdcmid> <vsimgcreatedate xsi:nil="true" /> <vsimgcreator /> <vsimgdesc /> <vsimgname /> <vsmemory>256.0</vsmemory> <vsmonitoring /> <vsname>BackendlessTestServer0</vsname> <vspcpu>1.0</vspcpu> <vsresgrpname /> <vsresgrpnum>/cloud/rest/pools/3/</vsresgrpnum> <vsstatus>CREATED</vsstatus> <vsstoragesize>2.0</vsstoragesize> <vsswapsize>0.0</vsswapsize> <vsswstack>5405.0000000000</vsswstack> <vsswstackdesc>5405.0000000000</vsswstackdesc> <vstype>VMware</vstype> </pmrdpsiview> </pmzhbr1_pmrdpsiviewset> </querypmzhbr1_pmrdpsiviewresponse>
Get project-related data (PMZHBR1_PMRDPPRJVIEW)

Returns project-related information. Object structure name: PMZHBR1_PMRDPPRJVIEW Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPPRJVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_compact=1 Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPPRJVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&SERVICEOWNER=PMSCADMUSR &REQUESTOR=PMSCADMUSR&_compact=1
341
Filtered by Service instance ID: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPPRJVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&PMZHBSSVCIID=2&_compact=1 Show me all projects: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPPRJVIEW?_format=json &PLUSPCUSTOMER=PMRDPCUST&_orderbydesc=STATUSDATE &_maxItems=20&_compact=1&_exactmatch=1

Table 54. Object structure definition for PMZHBR1_PMRDPPRJVIEW Object PMRDPPRJVIEW Parent Object Object Location Path Relationship PMRDPPRJVIEW
342
Query output
{ "QueryPMZHBR1_PMRDPSRVVIEWResponse": { "rsStart": 0, "rsCount": 2, "rsTotal": 2, "PMZHBR1_PMRDPSRVVIEWSet": { "PMRDPSRVVIEW": [ { "DESCRIPTION": "test", "NAME": "ITM test", "OBJID": 75, "PARTNAME": "MNg010222254181", "PERSONGROUP": "TEAM33", "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBSSVCIID": 4, "PROJENDTIME": "2011-07-26T20:04:00+05:30", "PROJSTARTTIME": "2011-07-12T20:05:07+05:30", "SDIID": 4, "SERVICEOWNER": "PMRDPCAUSR", "STATUS": "OPERATION", "STATUSDATE": "2011-07-13T01:30:39+05:30", "TYPE": "RDP", "VSCPU": 1.0, "VSERVERDCMID": "12223", "VSIDENTITY": "33e9fcea-df9c-46d5-b661-593d709556e8", "VSMEMORY": 512.0, "VSMONITORING": "on", "VSNAME": "MNg010222254181", "VSPCPU": 1.0, "VSRESGRPNUM": "\/cloud\/rest\/pools\/0\/", "VSSTATUS": "CREATED", "VSSTORAGESIZE": 21.0, "VSSWAPSIZE": 1.0, "VSSWSTACK": 11944.0, "VSSWSTACKDESC": 11944.0, "VSTYPE": "VMware" }, { "DESCRIPTION": "M1", "NAME": "M1", "OBJID": 106, "PARTNAME": "CNg010222045183", "PERSONGROUP": "TEAM34", "PLUSPCUSTOMER": "MADHUMITA", "PMZHBSSVCIID": 7, "PROJENDTIME": "2011-07-27T12:46:00+05:30", "PROJSTARTTIME": "2011-07-13T12:47:12+05:30", "SDIID": 7, "SERVICEOWNER": "MTA", "STATUS": "OPERATION", "STATUSDATE": "2011-07-13T18:32:03+05:30", "TYPE": "RDP", "VSCPU": 1.0, "VSERVERDCMID": "12434", "VSIDENTITY": "a38a8375-fb81-469f-baae-8e888cb38e52", "VSMEMORY": 800.0, "VSMONITORING": "off", "VSNAME": "CNg010222045183", "VSPCPU": 1.0, "VSRESGRPNUM": "\/cloud\/rest\/pools\/0\/", "VSSTATUS": "CREATED", "VSSTORAGESIZE": 20.0, "VSSWAPSIZE": 0.0, "VSSWSTACK": 11970.0, "VSSWSTACKDESC": 11970.0, "VSTYPE": "VMware" } ] } }
343
Get server-related data (PMZHBR1_PMRDPSRVVIEW)

Returns server-related information. Object structure name: PMZHBR1_PMRDPSRVVIEW Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSRVVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_compact=1 Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSRVVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&SERVICEOWNER=PMSCADMUSR &REQUESTOR=PMSCADMUSR&_compact=1 Filtered by Service instance ID: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSRVVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&PMZHBSSVCIID=2&_compact=1 Show me all servers: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSRVVIEW?_format=json &PLUSPCUSTOMER=PMRDPCUST&_compact=1&_exactmatch=1

Table 55. Object structure definition for PMZHBR1_PMRDPSRVVIEW Object PMRDPSRVVIEW Parent Object Object Location Path Relationship PMRDPSRVVIEW
344
Query output
{ "QueryPMZHBR1_PMRDPSRVVIEWResponse": { "rsStart": 0, "rsCount": 2, "rsTotal": 2, "PMZHBR1_PMRDPSRVVIEWSet": { "PMRDPSRVVIEW": [ { "DESCRIPTION": "test", "NAME": "ITM test", "OBJID": 75, "PARTNAME": "MNg010222254181", "PERSONGROUP": "TEAM33", "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBSSVCIID": 4, "PROJENDTIME": "2011-07-26T20:04:00+05:30", "PROJSTARTTIME": "2011-07-12T20:05:07+05:30", "SDIID": 4, "SERVICEOWNER": "PMRDPCAUSR", "STATUS": "OPERATION", "STATUSDATE": "2011-07-13T01:30:39+05:30", "TYPE": "RDP", "VSCPU": 1.0, "VSERVERDCMID": "12223", "VSIDENTITY": "33e9fcea-df9c-46d5-b661-593d709556e8", "VSMEMORY": 512.0, "VSMONITORING": "on", "VSNAME": "MNg010222254181", "VSPCPU": 1.0, "VSRESGRPNUM": "\/cloud\/rest\/pools\/0\/", "VSSTATUS": "CREATED", "VSSTORAGESIZE": 21.0, "VSSWAPSIZE": 1.0, "VSSWSTACK": 11944.0, "VSSWSTACKDESC": 11944.0, "VSTYPE": "VMware" }, { "DESCRIPTION": "M1", "NAME": "M1", "OBJID": 106, "PARTNAME": "CNg010222045183", "PERSONGROUP": "TEAM34", "PLUSPCUSTOMER": "MADHUMITA", "PMZHBSSVCIID": 7, "PROJENDTIME": "2011-07-27T12:46:00+05:30", "PROJSTARTTIME": "2011-07-13T12:47:12+05:30", "SDIID": 7, "SERVICEOWNER": "MTA", "STATUS": "OPERATION", "STATUSDATE": "2011-07-13T18:32:03+05:30", "TYPE": "RDP", "VSCPU": 1.0, "VSERVERDCMID": "12434", "VSIDENTITY": "a38a8375-fb81-469f-baae-8e888cb38e52", "VSMEMORY": 800.0, "VSMONITORING": "off", "VSNAME": "CNg010222045183", "VSPCPU": 1.0, "VSRESGRPNUM": "\/cloud\/rest\/pools\/0\/", "VSSTATUS": "CREATED", "VSSTORAGESIZE": 20.0, "VSSWAPSIZE": 0.0, "VSSWSTACK": 11970.0, "VSSWSTACKDESC": 11970.0, "VSTYPE": "VMware" } ] } }
345
Get storage-related data (PMZHBR1_PMRDPSTGVIEW)

Put your short description here; used for first paragraph and abstract. Object structure name: PMZHBR1_PMRDPSTGVIEW Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSTGVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_compact=1 Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSTGVIEW?_format=json&_lid=PMRDPCAUSR &_compact=1&_lid=PMRDPCAUSR_lpwd=maxadmin&_exactmatch=1 &SERVICEOWNER=PMSCADMUSR&REQUESTOR=PMSCADMUSR Filtered by Service instance id: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSTGVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&PMZHBSSVCIID=2&_compact=1

Table 56. Object structure definition for PMZHBR1_PMRDPSTGVIEW Object PMRDPSTGVIEW Parent Object Object Location Path Relationship PMRDPSTGVIEW
346
Query output
{ "QueryPMZHBR1_PMRDPSTGVIEWResponse": { "rsStart": 0, "rsCount": 18, "rsTotal": 18, "PMZHBR1_PMRDPSTGVIEWSet": { "PMRDPSTGVIEW": [ { "ASSETATTRID": "PMRDPCLSTG_FILE_SYSTEM", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179, "VALUE": "jfs2" }, { "ASSETATTRID": "PMRDPCLSTG_MOUNT_PATH", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179, "VALUE": "miksMount09" }, { "ASSETATTRID": "PMRDPCLSTG_POOL_NAME", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179, "VALUE": "MiksStoragePool" }, { "ASSETATTRID": "PMRDPCLSTG_SEQ", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179 }, { "ASSETATTRID": "PMRDPCLSTG_SIZE", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179, "VALUE": "32212254720.0000000000 }, { "ASSETATTRID": "PMRDPCLSTG_TYPE", "OBJID": 176, "PLUSPCUSTOMER": "PMRDPCUST", "PMZHBWTNID": 179, "VALUE": "storage_type_mapped" } ] } } }
"
Get the current defined offerings (PMRDPOFFVIEW)

Returns the information related with the current defined offerings. Object structure name: PMZHBR1_PMRDPOFFVIEW Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPOFFVIEW_format=json&_lid=PMRDPCAUSR &_compact=1&_lpwd=maxadmin&_exactmatch=1 &_fd=PMRDPCUSTINITOFV Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/
347
PMZHBR1_PMRDPOFFVIEW?_format=json&_lid=PMRDPCAUSR &_compact=1&_lid=PMRDPCAUSR_lpwd=maxadmin&_exactmatch=1 &SERVICEOWNER=PMSCADMUSR&REQUESTOR=PMSCADMUSR Filtered by Service instance ID: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPOFFVIEW?_format=json&_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&PMZHBSSVCIID=2&_compact=1

Table 57. Object structure definition for PMZHBR1_PMRDPOFFVIEW Object PMRDPOFFVIEW Parent Object Object Location Path Relationship PMRDPOFFVIEW
Query output
{ "QueryPMZHBR1_PMRDPOFFVIEWResponse": { "rsStart": 0, "rsCount": 1, "rsTotal": 1, "PMZHBR1_PMRDPOFFVIEWSet": { "PMRDPOFFVIEW": [ { "DESCRIPTION": "Create Customer", "ITEMID": 518, "ITEMNUM": "PMRDP_0500A_72", "ITEMSETID": "PMSCS1", "CLASSSTRUCTURE": [ { "CLASSIFICATIONID": "PMRDP_SR_VS_MTG", "CLASSSTRUCTUREUID": 1156, "DESCRIPTION": "Virtual Server Management" }, { "CLASSIFICATIONID": "PMRDP_SR_MANAGE_CUSTOMER", "CLASSSTRUCTUREUID": 1222, "DESCRIPTION": "Manage Customers" } ], "IMGLIB": [ { "IMAGENAME": "ge64_customer_create_24.gif" } ], "PMSCCATALOGOFFMAP": [ { } ] } ] } } }
348
Get person to group mapping (PERSONGROUPTEAM)

Returns a list of person to group mappings. Object structure name: PMZHBR1_PERSGRPTM Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PERSGRPTM?_lid=maxadmin&_lpwd=maxadmin &RESPPARTY=BILL

Table 58. Object structure definition for PMZHBR1_PERSGRPTM Object PERSONGROUPTEAM Parent Object Object Location Path PERSONGROUPTEAM Relationship
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querypmzhbr1_persgrptmresponse creationdatetime="2010-06-24T15:37:12+02:00" translanguage="EN" baselanguage="EN" messageid="1277386632094328481" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="2" rstotal="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <pmzhbr1_persgrptmset> <persongroupteam> <persongroup>MYTEAM1</persongroup> <respparty>PMSCADMUSR</respparty> <resppartygroup>PMSCADMUSR</resppartygroup> <usefororg /> <useforsite /> </persongroupteam> <persongroupteam> <persongroup>MYTEAM1</persongroup> <respparty>PMRDPCAUSR</respparty> <resppartygroup>PMRDPCAUSR</resppartygroup> <usefororg /> <useforsite /> </persongroupteam> </pmzhbr1_persgrptmset> </querypmzhbr1_persgrptmresponse>
Get person to group mapping details (PERSGRPTMDET)

Returns a list of person to persongroup relationship details. Object structure name: PMZHBR1_PERSGRPTMDET Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PERSGRPTMDET?_lid=maxadmin&_lpwd=maxadmin
349

Table 59. Object structure definition for PMZHBR1_PERSGRPTMDET Object PERSONGROUPTEAM Parent Object Object Location Path PERSONGROUPTEAM Relationship
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querypmzhbr1_persgrptmdetresponse creationdatetime="2010-06-24T15:43:23+02:00" translanguage="EN" baselanguage="EN" messageid="127738700390726304" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="2" rstotal="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <pmzhbr1_persgrptmdetset> <persongroupteam> <calnum /> <groupdefault>1</groupdefault> <orgdefault>0</orgdefault> <persongroup>MYTEAM1</persongroup> <persongroupteamid>108</persongroupteamid> <respparty>PMSCADMUSR</respparty> <resppartygroup>PMSCADMUSR</resppartygroup> <resppartygroupseq>1</resppartygroupseq> <resppartyseq>1</resppartyseq> <shiftnum /> <sitedefault>0</sitedefault> <usefororg /> <useforsite /> </persongroupteam> </pmzhbr1_persgrptmdetset> </querypmzhbr1_persgrptmdetresponse>
Get person groups with person not yet in team (PMZHBR1_PERSNTINTEAM)

Returns a list of person groups with persons that are not yet in a team. Object structure name: PMZHBR1_PERSNTINTEAM Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_PERSNTINTEAM?_lid=maxadmin&_lpwd=maxadmin &CLOUDTEAM=1&PERSONGROUP=MYCLTEAM

Table 60. Object structure definition for PMZHBR1_PERSNTINTEAM Object PERSONGROUP PERSON PERSONGROUP Parent Object Object Location Path PERSONGROUP PERSONGROUP/PERSON CLOUDUSERNOTINTEAM Relationship
350
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querypmzhbr1_persntinteamresponse creationdatetime="2010-06-24T15:56:50+02:00" translanguage="EN" baselanguage="EN" messageid="127738781073545180" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <pmzhbr1_persntinteamset> <persongroup> <cloudteam>1</cloudteam> <description>MYTEAM1 Description</description> <persongroup>MYTEAM1</persongroup> <persongroupid>73</persongroupid> <pmrdpprojectaccount>SCHATZKISTE</pmrdpprojectaccount> </persongroup> </pmzhbr1_persntinteamset> </querypmzhbr1_persntinteamresponse>
Information to calculate user request frequency (PMZHBR1_FREQUENTREQ)

Returns the base data to calculate a user's request frequency. This object structure is highly optimized to return only the required parameters that are used in the user interface. It is not intended to retrieve the total list of requests. The current user interface implementation filters for a logged-on user and a maximum of the last 30 requests. Object structure name: PMZHBR1_FREQUENTREQ Sample URL: http://localhost:9080/maxrest/rest/os/ PMZHBR1_FREQUENTREQ?_lid=maxadmin&_lpwd=maxadmin

Table 61. Object structure definition for PMZHBR1_PERSNTINTEAM Object PMSCCR SR PMSCCR Parent Object Object Location Path Relationship PMSCCR PMSCCR/SR SR
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querypmzhbr1_frequentreqresponse creationdatetime="2010-06-24T15:59:24+02:00" translanguage="EN" baselanguage="EN" messageid="1277387964094474052" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
351
xmlns="http://www.ibm.com/maximo" > <pmzhbr1_frequentreqset> <sr> <class>SR</class> <pmscitemnum>PMRDP_0201A_72</pmscitemnum> <ticketid>1152</ticketid> </sr> </pmzhbr1_frequentreqset> </querypmzhbr1_frequentreqresponse>
Network configuration API

This section describes the functions, extension nodes, methods, and classes available as part of the network configuration API. You can use the network configuration API to perform a set of tasks: v Obtain the network configuration instances on customer level and on project level v Save a modification to the persistent store v Provide a set of JAXB classes generated by the schema compiler to access and modify the network configuration data (for more details about JAXB access classes, see this topic. The API is implemented using the NetCfgClient class and the following methods are available: v NetCfgClient v getNetCfg v setNetCfg After the extension points are run use the network configuration application to verify if the modifications done with the API were successful and as expected.
Get network template

Use this REST request to get the available network templates in the ACTIVE status. The REST call returns the response in JSON format. URL http://<host>:<port>/maxrest/rest/pmzhbnetcfg/ getNetCfgTemplates?_lid=<userid>&_lpwd=<password> v <host>: This parameter specifies the host name on which the Tivoli Service Automation Manager server is running. v <port>: This parameter specifies the port of the REST service. The default ports are 9080 for http and 9443 for https. v <userid>: This parameter specifies the user ID for the request. It is only available if the system runs without WebSphere Application Server security. v password>: This parameter specifies the password for the request. It is only available if the system runs without WebSphere Application Server security. If the security is on, the user is prompted for logon credentials.
Parameters
352
Example JSON return structure

[ { "id": 1, "name": "test02", "description": "test02" }, { "id": 8, "name": "test02", "description": "test02" }, { "id": 10, "name": "test03", "description": "test03" } ]
The response consists of the following elements: v id: This element is the ID of the network template. v name: This element is the name of the network template. v description: This element is the description of the network template. This request is used to populate the network template box during customer creation.
Get matching network segments

Use these REST request to retrieve the network segments that match an image based on either the customer or the project configuration. You must have a valid network configuration set up for this REST call to work. To retrieve the matching network segments based on the customer configuration, you can perform this operation after the customer is made operational (after the Create Customer offering is run successfully). To retrieve the matching network segments based on the project configuration, you can perform this operation after the Create Project or Add Server offering is run successfully. Get network segments matching the customer configuration: Use this REST request to retrieve the possible network segments for the given image and customer. The REST call returns the response in JSON format. URL http://<host>:<port>/maxrest/rest/pmzhbnetcfg/ getNetCfgForImage?_lid=<userid>&_lpwd=<password> &imageId=<imageid>&customer=<customer>
Parameters v <host>: This parameter specifies the host name on which Tivoli Service Automation Manager is running. v <port>: This parameter specifies the port of the REST service. The default ports are 9080 for http and 9443 for https. v <userid>: This parameter specifies the user ID for the request. It is only available if the system runs without WebSphere Application Server security. If the security is on, you are prompted for logon credentials.
353
v <password>: This parameter specifies the password for the request. It is only available if the system runs without WebSphere Application Server security. If the security is on, you are prompted for logon credentials. v <imageid>: This parameter specifies the master image library entry (DCM ID) of the image that is to be used for matching. v <customer>: This parameter specifies the customer for this request. The customer value triggers which network configuration is used for matching. Example of the JSON return structure:
[ {"IfName":1, "networkSegments": [{ "SegmentName":"Management Segment VMware", "Description":"Management Segment TSAM Test VMware", "Type":"Management","Usage":"VMware" }] }, {"IfName":2, "networkSegments": [{ "SegmentName":"Customer Segment VMware", "Description":"Customer Network Segment TSAM Test VMware", "Type":"Customer","Usage":"VMware" }] } ]
The response consists of a two-dimensional array where on the first level is the list of network interfaces and on the second level is the returned list of matching network segments. The following elements are returned for each network segment: v Segment name: This is the name of the network segment. v Description: This is the description if the network segment. v Type: This is one of the predefined Tivoli Service Automation Manager values. v Usage: These are the customer-defined usage values related to this network segment. It is a comma-separated list of values. v This request is used to populate the network selection wizard panel in the Create Project and Add Server offerings in the self-service user interface. Get network segments matching the project configuration: Use this REST request to retrieve the possible network segments for the given image, customer, and project. The REST call returns the response in JSON format. URL http://<host>:<port>/maxrest/rest/pmzhbnetcfg/ getNetCfgForImage?_lid=<userid>&_lpwd=<password> &imageId=<imageid>&customer=<customer>&projectId=<projectid>
Parameters v <host>: This parameter specifies the host name on which Tivoli Service Automation Manager is running.
354
v <port>: This parameter specifies the port of the REST service. The default ports are 9080 for http and 9443 for https. v <userid>: This parameter specifies the user ID for the request. It is only available if the system runs without WebSphere Application Server security. If the security is on, you are prompted for logon credentials. v <password>: This parameter specifies the password for the request. It is only available if the system runs without WebSphere Application Server security. If the security is on, you are prompted for logon credentials. v <imageid>: This parameter specifies the master image library entry (DCM ID) of the image that is to be used for matching. v <customer>: This parameter specifies the customer for this request. v <projectid>: This parameter specifies the service instance ID of the project. The combination of customer and project ID defines which network configuration is used for matching. Example of the JSON return structure:
[ {"IfName":1, "networkSegments": [{ "SegmentName":"Management Segment VMware", "Description":"Management Segment TSAM Test VMware", "Type":"Management","Usage":"VMware" }] }, {"IfName":2, "networkSegments": [{ "SegmentName":"Customer Segment VMware", "Description":"Customer Network Segment TSAM Test VMware", "Type":"Customer","Usage":"VMware" }] } ]
The response consists of a two-dimensional array where on the first level is the list of network interfaces and on the second level is the returned list of matching network segments. The following elements are returned for each network segment: v Segment name: This is the name of the network segment. v Description: This is the description if the network segment. v Type: This is one of the predefined Tivoli Service Automation Manager values. v Usage: These are the customer-defined usage values related to this network segment. It is a comma-separated list of values. v This request is used to populate the network selection wizard panel in the Add Server offering in the self-service user interface.
355
Constructor for the network API client

This topic describes the parameters of the NetCfgClient API client method and offers a sample of the API invocation. This method is the constructor of the API client. Use it in all cases when the API is started in a management plan task within an extension node:
public NetCfgClient( NetCfgServiceRemote service, TicketRemote SR, String customer, String usage, String svciId )
The following parameters are used: NetCfgServiceRemote service This parameter is a reference to the network configuration service (PMZHBNETCFG). TicketRemote SR This parameter is a service request MBO of the current request. String customer This parameter is the name of the customer SR.getString(PLUSPCUSTOMER), where SR is the service request MBO. String usage The usage of the network configuration MBO. It can be either a customer or a project. Use the predefined constants USAGETYPE.CUSTOMER.toString() or USAGETYPE.PROJECT.toString(). String svciId This parameter delivers the service deployment instance ID or is null if the usage is defined by USAGETYPE.CUSTOMER.toString(). Sample invocation of the API call to get access to the customer network instance related to the given service request:
MXServer mxServer = MXServer.getMXServer(); NetCfgServiceRemote Service=(NetCfgServiceRemote)mxServer.lookup("PMZHBNETCFG"); NetCfgClient client=new NetCfgClient( service, SR, SR.getString("PLUSPCUSTOMER"), USAGETYPE.CUSTOMER.toString(), null);
The Get Network configuration method

This topic describes the Get network configuration method and offers an example of its usage. public NetworkConfiguration getNetCfg() This method returns the JAXB root handleto the network configuration. It is the base to access and manipulate the network configuration data. Sample code to get the network configuration root handle:
NetworkConfiguration netCfg=client.getNetCfg();
356
The Set Network configuration method

This topic describes the Set Network configuration method and offers an example of its usage. public void setNetCfg(NetworkConfiguration netCfg) This method persists the given network configuration. During the call, a validation of the provided network configuration is performed. The parameter of the method is the JAXB root handle returned from the getNetCfg method call. Sample code to invoke the setNetCfg method:
client.setNetCfg(netCfg);
Network schema
The network schema is an xsd file that defines the XML tags and the values supported for these tags that can appear in network configuration XML files. Tivoli Service Automation Manager network configuration is based on XML configuration files. The two sample network configuration files provided with Tivoli Service Automation Manager are PMZHB_SingleNicNetworkTemplate.xml PMZHB_SingleNicNetworkTemplate.xml. The XML network template file consists of a single network configuration entity that must conform to the schema defined by Tivoli Service Automation Manager. The tags and values used in these files must conform to the schema defined in the PMZHB_NetworkConfiguration.xsd schema file. This file and the sample network configuration files are available on the installation media in the following location: \install\files\NetworkConfigurations. There are several types that make up the network configuration schema: v DNS v Gateway v NetworkConfiguration v NetworkSegment v Reference v Route v Routes v Subnet v VlanId v VrfId
357
Complex type NetworkConfiguration: A Tivoli Service Automation Manager network template consists of a single network configuration entity. Purpose The entity defines: v The current version v A list of network segments v Any section that supports extensibility Content Details Version this is the current version of the schema. Value must be 1.0 for this release. NetworkSegments This is the main entity in the Tivoli Service Automation Manager network configuration. It is a list of network segments. Source
<complexType name="NetworkConfiguration"> <sequence> <element name="Version" minOccurs="1" maxOccurs="1"> <simpleType> <restriction base="string"> <enumeration value="1.0"/> </restriction> </simpleType> </element> <element name="NetworkSegments"> <complexType> <sequence> <element name="NetworkSegment" type="tns:NetworkSegment" minOccurs="1" maxOccurs="unbounded"> </element> </sequence> </complexType> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type DNS: This type defines the DNS configuration parameter. Purpose The values are used for the Layer 3 network configuration of the operating system. DNS is optional. If configured, it is used to set up the DNS of the guest operating system. Content Details Name This is the name of the DNS configuration. Description This is the optional description of the DNS configuration.
358
Reference This is an optional reference to an implementation object. Currently only DCM is supported. If it is used, it must be of type DCM and pointing to a computer system. The expression must contain the DCM name of the computer system. ServerIP This is a comma-separated list of DNS server IP addresses. By default, Tivoli Service Automation Manager uses this value to configure the DNS of the provisioned virtual machine operating system. Suffix This is a comma-separated list of DNS server suffixes. By default, Tivoli Service Automation Manager uses this value to configure the DNS of the provisioned virtual machine operating system. Source
<complexType name="DNS"> <sequence> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Reference" type="tns:Reference" minOccurs="0" maxOccurs="1"> </element> <element name="ServerIP" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Suffix" type="string" minOccurs="1" maxOccurs="1"> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type Gateway: A gateway provides the capabilities to define intelligent nodes within network segments. Purpose Use this type to define a DHCP server, a firewall, or an IP-based storage box. Gateways are optional elements and currently are not supported by Tivoli Service Automation Manager by default. Content Details Type This required attribute defines the type of the gateway. An enumeration defines the valid values. Name This required attribute defines the name of the gateway. Description This optional attribute defines the description of the gateway. Reference This optional attribute defines a reference to an implementation object. Currently the type DCM is supported. If this parameter is used, it must point
359
to a DCM computer system. Import code in Tivoli Service Automation Manager verifies this reference if it is used during import. Source
<complexType name="Gateway"> <sequence> <element name="Type"> <simpleType> <restriction base="string"> <enumeration value="VPN"> </enumeration> <enumeration value="Firewall"> </enumeration> <enumeration value="WAN"> </enumeration> <enumeration value="DHCP"> </enumeration> <enumeration value="NIM"> </enumeration> <enumeration value="PXE"> </enumeration> <enumeration value="LoadBalancer"> </enumeration> <enumeration value="Internet"> </enumeration> <enumeration value="Storage"> </enumeration> </restriction> </simpleType> </element> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Reference" type="tns:Reference" minOccurs="0" maxOccurs="1"> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type NetworkSegment: The network segment is the main entity in the Tivoli Service Automation Manager network configuration. Purpose You must define at least 1 network segment of the Management type. The required values for network segments are: v Name v Type v At least a single subnet definition v A single DNS definition The other values are optional and available for customer extensions.
360
Content Details Name This is the name of the network segment. The attribute is required because it is later displayed in the self-service user interface during the Create Project and Add Server workflows. Description This is the description of the network segment. The value is optional. Usage The usage value is optional. If set, it must contain a comma-separated list of values. The used values must be registered in the Tivoli Process Automation Engine domain: PMZHBNETSEGUSAGE. Type This is the type of the network segment. The values come from an enumeration. Only these values are supported. VrfId A network segment can be related to a single VRF. This is an optional field and by default it is not required by Tivoli Service Automation Manager. VlanId A network segment can be related to a list of VLAN IDs. This is an optional field and by default it is not required by Tivoli Service Automation Manager. Subnets Gateways A network segment can be related to a list of gateway definitions. This is an optional field and by default it is not required by Tivoli Service Automation Manager. DNS A network segment must have a single DNS definition. If a network segment is a part of a network definition of an image that has the Hostname Resolve flag marked, then this DNS definition is used to customize the DNS configuration of the operating system.
361
Source
<complexType name="NetworkSegment"> <sequence> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Usage" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Type" minOccurs="1" maxOccurs="1"> <simpleType> <restriction base="string"> <enumeration value="Management"> </enumeration> <enumeration value="Customer"> </enumeration> <enumeration value="Storage"> </enumeration> <enumeration value="BackupRestore"> </enumeration> </restriction> </simpleType> </element> <element name="VrfId" type="tns:VrfId" minOccurs="0" maxOccurs="1"> </element> <element name="VlanId" type="tns:VlanId" minOccurs="0" maxOccurs="unbounded"> </element> <element name="Subnets" type="tns:Subnet" minOccurs="1" maxOccurs="unbounded"> </element> <element name="Gateways" type="tns:Gateway" minOccurs="0" maxOccurs="unbounded"> </element> <element name="DNS" type="tns:DNS" minOccurs="1" maxOccurs="1"> </element>
<any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Related reference Complex type VrfId on page 366 This type allows to model a VRF ID. Complex type VlanId on page 365 This type allows to model a VLAN ID. Complex type Subnet on page 364 This type defines a subnet. It is primarily a link to a subnet implementation object. Complex type Gateway on page 359 A gateway provides the capabilities to define intelligent nodes within network segments. Complex type DNS on page 358 This type defines the DNS configuration parameter.
362
Complex type Reference: This type defines a reference to an implementation object. Purpose Currently, only DCM references are supported so the expression contains the DCM name of the referenced object. Content Details Expression The expression defines the referenced implementation object. It is dependent on the referenced type. In case of DCM, it is the name of the referenced DCM object. The exploiting object in the XML schema defines for which kind of DCM object the reference is valid. Checking for the existence of this object is done by code that is separate from the schema. Source
<complexType name="Reference"> <sequence> <element name="Expression" type="string" minOccurs="1" maxOccurs="1"> </element> </sequence> <attribute name="RefType" use="required"> <simpleType> <restriction base="string"> <enumeration value="DCM"> </enumeration> <enumeration value="None"/> </restriction> </simpleType> </attribute> </complexType>
Complex type Route: This type allows to model routing entities. This type is optional and not used by Tivoli Service Automation Manager by default. Content Details Destination This is a required element. It defines the routing destination. Netmask This is a required element. It defines the netmask of the route. Metric This is an optional element. It defines the metric of the route.
363
Source
<complexType name="Route"> <sequence> <element name="Destination" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Netmask" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Metric" type="string" minOccurs="0" maxOccurs="1"> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type Routes: This type allows to model a list of routing entities. This type is optional and not used by Tivoli Service Automation Manager by default. Content Details Routes This parameter implements an open list of routing entries. If it is used, the lsit must contain at least a single element. Source
<complexType name="Routes"> <sequence> <element name="Routes" type="tns:Route" minOccurs="1" maxOccurs="unbounded"> </element> </sequence> </complexType>
Complex type Subnet: This type defines a subnet. It is primarily a link to a subnet implementation object. Content Details Name This is a required attribute that defines the name of the subnet. Description This is an optional attribute that defines the description of the subnet. Reference This is a required attribute that defines the reference to the implementation object for the subnet. Currently, only a reference to a DCM subnetwork is supported. By default, Tivoli Service Automation Manager requires this DCM object for provisioning and defines a set of properties and references to virtual switch templates to exit. This definition is required to exit prior to provisioning. The parameter can be set to None in the template but prior to provisioning it must point to a valid DCM subnetwork definition.
364
NumberOfIPAddresses This is an optional attribute that can be used in a template use case to define the number of IP addresses which the reference implementation object will have. Routes This is an optional value that can point to a set of routing entries which are used for this subnet. The attribute is available for extensibility purposes and not used by default. Source
<complexType name="Subnet"> <sequence> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Reference" type="tns:Reference" minOccurs="1" maxOccurs="1"> </element> <element name="NumberOfIPAddresses" type="int" minOccurs="0" maxOccurs="1"> </element> <element name="Routes" type="tns:Routes" minOccurs="0" maxOccurs="1"> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type VlanId: This type allows to model a VLAN ID. Purpose This type is used for extensibility purposes and it is not used by default. Content Details Name This is a required attribute that defines the name of the VLAN. Description This is an optional attribute that defines the description of the VLAN. Reference This is an optional attribute that defines the reference to the VLAN implementation object. Currently, only referencing to DCM objects is supported. If this attribute is used, it must point to a DCM object of a VLAN kind and the expression of the reference must contain the name of the DCM object. VlanId [1..1]
365
Source
<complexType name="VlanId"> <sequence> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="Reference" type="tns:Reference" minOccurs="0" maxOccurs="1"> </element> <element name="VlanId" type="string" minOccurs="1" maxOccurs="1"/> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Complex type VrfId: This type allows to model a VRF ID. Purpose This type is used for extensibility purposes and it is not used by default. Content Details Name This is a required attribute that defines the name of the VRF. Description This is an optional attribute that defines the description of the VRF. VrfId This is a required attribute that defines the VRFID. Source
<complexType name="VrfId"> <sequence> <element name="Name" type="string" minOccurs="1" maxOccurs="1"> </element> <element name="Description" type="string" minOccurs="0" maxOccurs="1"> </element> <element name="VrfId" type="string" minOccurs="1" maxOccurs="1"> </element> <any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> </any> </sequence> </complexType>
Simple type Type: This type defines the network segment type. Allowable Values Management This value defines a network segment as type Management. By default, Tivoli Service Automation Manager requires that exactly one network interface of a virtual machine has this type. Provisioning and modification to the virtual machine are done through this interface. Network addresses used on such an interface must be globally unique.
366
Customer This type is provided to define a network segment as type Customer. This attribute is not required by default and is used to separate the management network from other networks. Storage This type is provided to define a network segment as type Storage. This attribute is not required by default and is used to separate the management network from other networks. BackupRestore This type is provided to define a network segment as type BackupRestore. This attribute is not required by default and is used to separate the management network from other networks. Source
<simpleType> <restriction base="string"> <enumeration value="Management"> </enumeration> <enumeration value="Customer"> </enumeration> <enumeration value="Storage"> </enumeration> <enumeration value="BackupRestore"> </enumeration> </restriction> </simpleType>
Simple type Version: This type defines the version of your network configuration. Allowable Values 1.0 1.0 is the only allowable value. Source
<simpleType> <restriction base="string"> <enumeration value="1.0"/> </restriction> </simpleType>
JAXB access classes

See this topic for a list of classes available within the JAXB schema complier. The JAXB schema compiler based on the network template schema (PMZHB_NetworkConfiguration.xsd) is responsible for generating the second part of the network configuration API. The set of classes described in this topic is available in: com.ibm.xmlns.prod.ism.pmzhb.networkconfiguration.jar. The following classes are available: v DNS v Gateway v NetworkConfiguration
367
v v v v v
NetworkSegment ObjectFactory Reference Route Routes
v Subnet v VlanId v VrfId The classes have the necessary getter and setter methods to access the XML-based data. The exception to this rule is the ObjectFactory class which is used to create new typed classes for the XML elements that are defined in PMZHB_NetworkConfiguration.xsd. This is an example for the getter and setter methods available in the NetworkSegment class for the type attribute:
/** * Gets the value of the type property. * * @return * possible object is * {@link String } * */ public String getType() /** * Sets the value of the type property. * * @param value * allowed object is * {@link String } * */ public void setType(String value)
See the schema description to find the attributes available for each type defined in the schema.
The ANY attributes available in the schema

This topic describes the method used to access the ANY attributes and offers examples. The current schema provides extensibility points for each type defined, by using the ANY element. This allows for placing any user-defined type into the XML. The following method is available to access the ANY elements: v <class>.getAny(), where <class> is one of the types listed in JAXB access classes on page 367. This method returns a list of elements filled with ANY section in the XML. This is an example code to get the ANY attributes for the network configuration. It gets the ANY elements defined in the XML for the network configuration and iterates over the child nodes.
368
List<Element> els=netCfg.getAny(); for(Element e : els) { NodeList nodes=e.getChildNodes(); int len=nodes.getLength(); for(int i=0; i<len; i++) { Node n=nodes.item(i); } }
This is an example XML section used with the name space:

xmlns:cust="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <cust:note> <cust:to>Tove</cust:to> <cust:from>Jani</cust:from> <cust:heading>Reminder</cust:heading> <cust:body>Dont forget me this weekend!</cust:body> </cust:note>
Tivoli Service Request Manager based object queries

This section provides information about the Tivoli Service Request Manager based object queries.
Get list of service requests (SR)

Returns a service request overview. This object structure is not intended to be used without any filtering. If filtering for status is used, the possible status values should be queried first via the maxdomain object structure and the SRSTATUS filter. The most useful scenarios are filtering by: v Logged-on user v Affected person v Status v Classification id Object structure name: SRM_SR Sample URL: http://localhost:9080/maxrest/rest/os/SRM_SR?_lid=maxadmin &_lpwd=maxadmin Filtered by logged-on user: http://localhost:9080/maxrest/rest/os/SRM_SR?_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&REPORTEDBY=PMSCADMUSR Filtered by affected person: http://localhost:9080/maxrest/rest/os/SRM_SR?_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1 &AFFECTEDPERSON=PMSCADMUSR Filtered by status: http://localhost:9080/maxrest/rest/os/SRM_SR?_lid=maxadmin &_lpwd=maxadmin&_exactmatch=1&STATUS=RESOLVED
369

Table 62. Object structure definition for SRM_SR Object SR Parent Object Object Location Path Relationship SR
Query output
<QuerySRM_SRResponse creationDateTime="2009-10-22T16:51:03+02:00" transLanguage="EN" baseLanguage="EN" messageID="1256223063015952946" maximoVersion="7 1 20090627-0754 V7115-149" rsStart="0" rsCount="1" rsTotal="1"> <SRM_SRSet> <SR> <ACTUALFINISH>2009-10-22T13:08:23+02:00</ACTUALFINISH> <ACTUALSTART>2009-10-22T13:07:05+02:00</ACTUALSTART> <AFFECTEDDATE>2009-10-22T13:06:34+02:00</AFFECTEDDATE> <AFFECTEDPERSON>BILL</AFFECTEDPERSON> <CLASS maxvalue="SR">SR</CLASS> <CLASSIFICATIONID>PMRDP_SR_CREATE_PROJECT_VMWARE_SERVER</CLASSIFICATIONID> <CLASSSTRUCTUREID>8100210</CLASSSTRUCTUREID> <CREATEDBY>BILL</CREATEDBY> <CREATIONDATE>2009-10-22T13:06:48+02:00</CREATIONDATE> <DESCRIPTION>Create Project with VMware Servers PRJ001</DESCRIPTION> <DESCRIPTION_LONGDESCRIPTION> Provision one or more VMware virtual machines containing a software image. </DESCRIPTION_LONGDESCRIPTION> <FAILURECODE/> <INDICATEDPRIORITY xsi:nil="true"/> <ORGID/> <OWNER/> <OWNERGROUP/> <PMCOMTYPE/> <PROBLEMCODE/> <REPORTDATE>2009-10-22T13:06:34+02:00</REPORTDATE> <REPORTEDBY>BILL</REPORTEDBY> <REPORTEDPRIORITY>1</REPORTEDPRIORITY> <SITEID/> <SOLUTION/> <STATUS maxvalue="RESOLVED">RESOLVED</STATUS> <STATUSDATE>2009-10-22T13:08:23+02:00</STATUSDATE> <SUPERVISOR/> <TARGETFINISH>2009-11-04T08:00:00+01:00</TARGETFINISH> <TARGETSTART>2009-10-22T13:06:48+02:00</TARGETSTART> <TICKETID>1149</TICKETID> <TICKETUID>286</TICKETUID> <URGENCY xsi:nil="true"/> </SR> </SRM_SRSet> </QuerySRM_SRResponse>
370
Get service request details (SRDET)

Returns service request details. This object structure is not intended to be used without any filtering. It returns the SR, classification attributes, and domain information. The most useful scenario is to filter by Specific id (TICKETUID), which can be retrieved from the overview request. This object structure is used to build the My Request view in the Web 2.0 User Interface. It is the base to show all the request content and Meta data. In addition, it returns the relationship and data to the PMSCMR and the offering meta data. It is one of the most complex objects and should not be called without filtering as it returns a large amount of data. Object structure name: SRM_SRDET Sample URL: http://localhost:9080/maxrest/rest/os/SRM_SRDET?_lid=maxadmin &_lpwd=maxadmin Filtered by Specific id: http://localhost:9080/maxrest/rest/os/SRM_SRDET/283?_lid=maxadmin &_lpwd=maxadmin

Table 63. Object structure definition for SRM_SRDET Object SR TICKETSPEC ASSETATTRIBUTE COMMLOG LONGDESCRIPTION SR TICKETSPEC SR SR Parent Object Object Location Path SR SR/TICKETSPEC SR/TICKETSPEC/ ASSETATTRIBUTE SR/COMMLOG SR/LONGDESCRIPTION PMZHB_SRSPECCLASS ASSETATTRIBUTE COMMLOG SRSOLUTION Relationship
Query output
<?xml version="1.0" encoding="UTF-8" ?> <QuerySRM_SRDETResponse creationDateTime="2010-06-24T13:38:26+02:00" transLanguage="EN" baseLanguage="EN" messageID="1277379506344815695" maximoVersion="7 1 20091208-1415 V7116-173" rsStart="0" rsCount="1" rsTotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <SRM_SRDETSet> <SR> <AFFECTEDEMAIL>pmrdpcausr@localhost</AFFECTEDEMAIL> <CHANGEBY>PMRDPCAUSR</CHANGEBY> <CHANGEDATE>2010-06-21T16:59:50+02:00</CHANGEDATE> <CLASS>SR</CLASS> <CORRELATIONATTRS /> <CREATEDBY>PMRDPCAUSR</CREATEDBY>
371
<CREATIONDATE>2010-06-21T16:59:46+02:00</CREATIONDATE> <DESCRIPTION>VS Provisioning: Create Team</DESCRIPTION> <HASSOLUTION>0</HASSOLUTION> <PMSCCRID>1025</PMSCCRID> <STATUS>RESOLVED</STATUS> <SUPERVISOR /> <TARGETFINISH xsi:nil="true" /> <TARGETSTART>2010-06-21T16:59:47+02:00</TARGETSTART> <TICKETID>1149</TICKETID> <TICKETUID>286</TICKETUID> <TICKETSPEC> <ALNVALUE>MYTEAM1</ALNVALUE> <ASSETATTRID>PMRDPCLCUSR_TEAM_NAME</ASSETATTRID> <DISPLAYSEQUENCE>1</DISPLAYSEQUENCE> <MANDATORY>0</MANDATORY> <MEASUREUNITID /> <NUMVALUE xsi:nil="true" /> <SECTION /> <TABLEVALUE /> <ASSETATTRIBUTE> <ASSETATTRIBUTEID>832</ASSETATTRIBUTEID> <DATATYPE>ALN</DATATYPE> <DESCRIPTION>Name</DESCRIPTION> <MEASUREUNITID /> <ORGID /> <SITEID /> </ASSETATTRIBUTE> </TICKETSPEC> </SR> </SRM_SRDETSet> </QuerySRM_SRDETResponse>
Get shopping cart (CART)

Returns Tivoli Service Request Manager shopping cart information. Object structure name: SRM_CART Sample URL: http://localhost:9080/maxrest/rest/os/SRM_CART?_lid=maxadmin &_lpwd=maxadmin

Table 64. Object structure definition for SRM_CART Object PMSCCR SR PMSCCR Parent Object Object Location Path Relationship PMSCCR PMSCCR/SR SR
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_cartresponse creationdatetime="2010-06-24T13:49:03+02:00" translanguage="EN" baselanguage="EN" messageid="1277380143719643757" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="2" rstotal="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo"
372
> <srm_cartset> <pmsccr> <changedate>2010-03-16T15:13:48+01:00</changedate> <description /> <pmsccrid>1</pmsccrid> <pmsccrnum>PMRDPCR</pmsccrnum> <requestedfor>PMSCADMUSR</requestedfor> </pmsccr> <pmsccr> <changedate>2010-06-21T16:59:46+02:00</changedate> <description /> <pmsccrid>2</pmsccrid> <pmsccrnum>1025</pmsccrnum> <requestedfor>PMRDPCAUSR</requestedfor> <sr> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-21T16:59:50+02:00</changedate> <createdby>PMRDPCAUSR</createdby> <description>VS Provisioning: Create Team</description> <pmscquantity xsi:nil="true" /> <ticketid>1149</ticketid> <ticketuid>286</ticketuid> </sr> </pmsccr> </srm_cartset> </querysrm_cartresponse>
Get user details (MAXUSERDET)

Returns the user details structure. Object structure name: SRM_MAXUSERDET Sample URL: http://localhost:9080/maxrest/rest/os/ SRM_MAXUSERDET?_lid=maxadmin&_lpwd=maxadmin

Table 65. Object structure definition for SRM_MAXUSERDET Object MAXUSER PERSON EMAIL PHONE SITE MAXUSER PERSON PERSON MAXUSER Parent Object Object Location Path Relationship MAXUSER MAXUSER/PERSON PERSON MAXUSER/ PERSON/EMAIL MAXUSER/ PERSON/PHONE MAXUSER/SITE PRIMARYEMAIL PHONE DEFSITE
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_maxuserdetresponse creationdatetime="2010-06-24T13:52:14+02:00" translanguage="EN" baselanguage="EN" messageid="1277380334751363506" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1"
373
rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_maxuserdetset> <maxuser> <defstoreroom /> <loginid>granger</loginid> <maxuserid>1</maxuserid> <memo /> <personid>GRANGER</personid> <pwhintquestion /> <status>ACTIVE</status> <storeroomsite>BEDFORD</storeroomsite> <sysuser>0</sysuser> <type>TYPE 1</type> <userid>GRANGER</userid> <person> <addressline1>9898 South Street</addressline1> <addressline2 /> <addressline3 /> <langcode>EN</langcode> <language /> <locale /> <personid>GRANGER</personid> <personuid>26</personuid> <pluspcompanyorgid /> <pluspcustomer /> <pluspcustvendor /> <pluspcustvndtype>INTERNAL</pluspcustvndtype> <status>ACTIVE</status> <supervisor>HUNTER</supervisor> <email> <emailaddress>lou.granger@helwig.com</emailaddress> <isprimary>1</isprimary> <type>WORK</type> </email> <phone> <isprimary>1</isprimary> <phoneid>145860</phoneid> <phonenum>617-675-0987</phonenum> <type>WORK</type> </phone> </person> <site> <active>1</active> <description>Bedford MA Site of EAGLE Inc. North America</description> <orgid>EAGLENA</orgid> <siteid>BEDFORD</siteid> <siteuid>1</siteuid> </site> </maxuser> </srm_maxuserdetset> </querysrm_maxuserdetresponse>
374
Get offering information (OFFERING)

Retrieves Tivoli Service Request Manager offering information. Object structure name: SRM_OFFERING Sample URL: http://localhost:9080/maxrest/rest/os/SRM_OFFERING?_lid=maxadmin &_lpwd=maxadmin

Table 66. Object structure definition for SRM_OFFERING Object PMSCOFFERING CLASSSTRUCTURE IMGLIB PMSCCATALOGOFFMAP PMSCOFFERING PMSCOFFERING PMSCOFFERING Parent Object Object Location Path PMSCOFFERING PMSCOFFERING/ CLASSSTRUCTURE PMSCOFFERING/IMGLIB PMSCOFFERING/ PMSCCATALOGOFFMAP CLASSHIERARCHY IMGLIB PMSCCATALOGOFFMAP Relationship
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_offeringresponse creationdatetime="2010-06-24T13:55:36+02:00" translanguage="EN" baselanguage="EN" messageid="1277380536376307547" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_offeringset> <pmscoffering> <description>Create Project with VMware Servers</description> <description_longdescription>Provision one or more VMware virtual machines containing a software image.</description_longdescription> <itemid>463</itemid> <itemnum>PMRDP_0201A_72</itemnum> <itemsetid>PMSCS1</itemsetid> <classstructure> <classificationid>PMRDP_SR_VS_MTG</classificationid> <classstructureuid>1156</classstructureuid> <description>Virtual Server Management</description> </classstructure> <imglib> <imagename>rs50_cloud_create.gif</imagename> </imglib> <pmsccatalogoffmap /> <pmsccatalogoffmap /> </pmscoffering> </srm_offeringset> </querysrm_offeringresponse>
375
Get offering details (OFFERINGDET)

Retrieves detailed Tivoli Service Request Manager offering information. Object structure name: SRM_OFFERINGDET Sample URL: http://localhost:9080/maxrest/rest/os/ SRM_OFFERINGDET?_lid=maxadmin&_lpwd=maxadmin

Table 67. Object structure definition for SRM_OFFERINGDET Object PMSCOFFERING LONGDESCRIPTION PMSCOFFERING CLASSSTRUCTURE IMGLIB PMSCITEMSPEC PMSCOFFERING PMSCOFFERING PMSCOFFERING Parent Object Object Location Path Relationship PMSCOFFERING PMSCOFFERING/ LONGDESCRIPTION LONGDESCRIPTION PMSCOFFERING/ CLASSSTRUCTURE PMSCOFFERING/ IMGLIB PMSCOFFERING/ PMSCITEMSPEC CLASSHIERARCHY IMGLIB PMSCITEMSPEC
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_offeringdetresponse creationdatetime="2010-06-24T13:57:44+02:00" translanguage="EN" baselanguage="EN" messageid="1277380664110433982" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="1" rstotal="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_offeringdetset> <pmscoffering> <classstructureid>8100210</classstructureid> <commodity>VSERVER</commodity> <commoditygroup>SRVAUTOM</commoditygroup> <description>Create Project with VMware Servers</description> <itemid>463</itemid> <itemnum>PMRDP_0201A_72</itemnum> <itemsetid>PMSCS1</itemsetid> <status>ACTIVE</status> <longdescription> <langcode>EN</langcode> <ldkey>463</ldkey> <ldownercol>DESCRIPTION</ldownercol> <ldownertable>ITEM</ldownertable> <ldtext>Provision one or more VMware virtual machines containing a software image.</ldtext> </longdescription> <classstructure> <classificationid>PMRDP_SR_VS_MTG</classificationid> <classstructureid>8100200</classstructureid> <classstructureuid>1156</classstructureuid>
376
<description>Virtual Server Management</description> </classstructure> <imglib> <imagename>rs50_cloud_create.gif</imagename> <imglibid>23</imglibid> </imglib> <pmscitemspec> <alnvalue /> <assetattrid>PMRDPCLCPR_DESCRIPTION</assetattrid> <classstructureid>8100210</classstructureid> <displaysequence>7</displaysequence> <itemspecid>265</itemspecid> <mandatory>0</mandatory> <numvalue xsi:nil="true" /> <section /> <tablevalue /> <assetattribute> <assetattributeid>730</assetattributeid> <datatype>ALN</datatype> <description>Project Description</description> <orgid /> <siteid /> </assetattribute> </pmscitemspec> <pmscoffdialog> <hidden>0</hidden> <mandatory>0</mandatory> <offeringattr>PMRDPCLCPR_DESCRIPTION</offeringattr> <readonly>0</readonly> </pmscoffdialog> </pmscoffering> </srm_offeringdetset> </querysrm_offeringdetresponse>
Create service request (SRCREATE)

Use via a post call to create a service request structure. This object structure is used to create a service request (SR) and an empty classification. The creation of an SR is a 2 stage process. In the first post request the core SR data is set and an empty classification is created. The Create response is used to build an update request that fills in the values for the classification attributes - performed via a REST update request. Object structure name: SRM_SRCREATE

Table 68. Object structure definition for SRM_SRCREATE Object SR TICKETSPEC ASSETATTRIBUTE PMRDPVSRPARM SR TICKETSPEC SR Parent Object Object Location Path Relationship SR SR/TICKETSPEC SR/TICKETSPEC/ ASSETATTRIBUTE SR/ PMRDPVSRPARM SRSPECCLASS ASSETATTRIBUTE PMRDPVSRPARM
377
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_srcreateresponse creationdatetime="2010-06-24T14:06:10+02:00" translanguage="EN" baselanguage="EN" messageid="1277381170266107276" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="116" rstotal="116" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_srcreateset> <sr> <accumulatedholdtime xsi:nil="true" /> <actualcontactdate xsi:nil="true" /> <actualfinish>2010-06-21T16:59:50+02:00</actualfinish> <actualstart xsi:nil="true" /> <adjustedtargetcontacttime xsi:nil="true" /> <adjustedtargetresolutiontime xsi:nil="true" /> <adjustedtargetresponsetime xsi:nil="true" /> <affecteddate>2010-06-21T16:59:46+02:00</affecteddate> <affectedemail>pmrdpcausr@localhost</affectedemail> <affectedperson>PMRDPCAUSR</affectedperson> <affectedphone /> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-21T16:59:50+02:00</changedate> <class>SR</class> <classificationid>PMRDP_SR_CREATE_TEAM</classificationid> <classstructureid>8100255</classstructureid> <commodity>VSERVER</commodity> <commoditygroup>SRVAUTOM</commoditygroup> <correlationattrs /> <createdby>PMRDPCAUSR</createdby> <creationdate>2010-06-21T16:59:46+02:00</creationdate> <description>VS Provisioning: Create Team</description> <descsrvid /> <externalrecid /> <externalsystem /> <externalsystem_ticketid /> <failurecode /> <fr1code /> <fr2code /> <globalticketclass /> <globalticketid /> <hassolution>0</hassolution> <impact xsi:nil="true" /> <indicatedpriority xsi:nil="true" /> <internalpriority xsi:nil="true" /> <isknownerror>0</isknownerror> <isknownerrordate xsi:nil="true" /> <location /> <orgid /> <origrecordclass /> <origrecordid>1025</origrecordid> <origrecorgid /> <origrecsiteid /> <owner>PMRDPCAUSR</owner> <ownergroup /> <pluspaddressline2 /> <pluspaddressline3 /> <pluspagreement /> <pluspbblinenum xsi:nil="true" /> <pluspbillbatch /> <pluspcalccalnum />
378
<pluspcalcorgid /> <pluspcalcshift /> <pluspcity /> <pluspcostcenter /> <pluspcountry /> <pluspcounty /> <pluspcustchacct /> <pluspcustomer /> <pluspcustponum /> <pluspdirections /> <pluspgeocode /> <plusplatitude xsi:nil="true" /> <plusplongitude xsi:nil="true" /> <pluspmaxprice xsi:nil="true" /> <plusppostalcode /> <plusppricesched /> <pluspquotedprice xsi:nil="true" /> <pluspquotetype /> <plusprefpoint /> <pluspregiondistr /> <pluspresponseplan /> <plusprevnum xsi:nil="true" /> <pluspstaddrdirprfx /> <pluspstaddrdirsfx /> <pluspstaddrnumber /> <pluspstaddrstreet /> <pluspstaddrsttype /> <pluspstaddrunitnum /> <pluspstateprovince /> <pluspstreetaddress /> <plusptimezone /> <pmcomresolution /> <pmcomtype /> <pmsccrid>1025</pmsccrid> <pmscitemnum>PMRDP_0235A_72</pmscitemnum> <pmscoffsummary /> <pmscquantity xsi:nil="true" /> <problemcode /> <reportdate>2010-06-21T16:59:46+02:00</reportdate> <reportedby>PMRDPCAUSR</reportedby> <reportedemail>pmrdpcausr@localhost</reportedemail> <reportedphone /> <reportedpriority xsi:nil="true" /> <searchsource /> <selfservsolaccess>0</selfservsolaccess> <siteid /> <solution /> <source /> <status>RESOLVED</status> <supervisor /> <targetcontactdate xsi:nil="true" /> <targetdesc /> <targetfinish xsi:nil="true" /> <targetstart>2010-06-21T16:59:47+02:00</targetstart> <templateid /> <ticketid>1149</ticketid> <ticketuid>286</ticketuid> <urgency xsi:nil="true" /> <vendor /> <ticketspec> <alnvalue>MYTEAM1</alnvalue> <assetattrid>PMRDPCLCUSR_TEAM_NAME</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-21T16:59:49+02:00</changedate> <classspecid>1808</classspecid> <classstructureid>8100255</classstructureid> <displaysequence>1</displaysequence>
379
<linkedtoattribute /> <linkedtosection /> <mandatory>0</mandatory> <measureunitid /> <numvalue xsi:nil="true" /> <orgid /> <refobjectid>286</refobjectid> <refobjectname>SR</refobjectname> <section /> <siteid /> <tablevalue /> <ticketspecid>7</ticketspecid> <assetattribute> <assetattributeid>832</assetattributeid> <attrdescprefix /> <datatype>ALN</datatype> <description>Name</description> <domainid /> <measureunitid /> <orgid /> <siteid /> </assetattribute> </ticketspec> </sr> </srm_srcreateset> </querysrm_srcreateresponse>
Create a shopping cart (CARDCREATE)

Use via a post call to create a PMSCCR structure. This object structure is used to create a shopping cart (PMSCCR). The shopping cart can combine multiple service requests (SRs) into a single request. Tivoli Service Automation Manager 7.2.1 does not exploit this, as its requests have a single PMSCCR together with a single SR for each of the Service Requests. The PMSCCR and SR are linked together via a special attribute in the SR data structure called PMSCCRID. It is a 2 stage process to link an SR to the PMSCCR. First the PMSCCR is created via a post request. The SR is created and the link attribute (PMSCCRID) is set with the pmsccrid attribute of the PMSCCR. Object structure name: SRM_CARDCREATE

Table 69. Object structure definition for SRM_CARDCREATE Object PMSCCR Parent Object Object Location Path Relationship PMSCCR
Query output
<?xml version="1.0" encoding="UTF-8" ?> <querysrm_cardcreateresponse creationdatetime="2010-06-24T14:10:22+02:00" translanguage="EN" baselanguage="EN" messageid="1277381422719623142" maximoversion="7 1 20091208-1415 V7116-173" rsstart="0" rscount="2"
380
rstotal="2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo"> <srm_cardcreateset> <pmsccr> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-21T16:59:46+02:00</changedate> <description /> <droppoint /> <historyflag>0</historyflag> <location /> <orgid>PMSCIBM</orgid> <origrecordclass /> <origrecordid /> <pluspcustomer /> <pmsccrid>2</pmsccrid> <pmsccrnum>1025</pmsccrnum> <priority xsi:nil="true" /> <requestedby>PMRDPCAUSR</requestedby> <requesteddate>2010-06-21T16:59:46+02:00</requesteddate> <requestedfor>PMRDPCAUSR</requestedfor> <shipto /> <siteid>PMSCRTP</siteid> <status>RESOLVED</status> <statusdate>2010-06-21T16:59:51+02:00</statusdate> </pmsccr> </srm_cardcreateset> </querysrm_cardcreateresponse>
Create interfaces via REST

This section provides information on how to create interfaces via REST.
REST POST-style requests - 'create', 'update', and 'delete'

These REST requests are based on POST style syntax and can be easily executed using an HTML form. For the POST requests, the attributes are encoded and flattened in the following way: v Attribute = value if the attribute is in the main MBO (Maximo Business Object) v MBO.1.Attribute = value if the attribute is below the main MBO v A 'create' request example (HMTL form based):
<form name="input" action="http://localhost:9080/maxrest/rest/os/SRM_SRCREATE? _lid=userid&_lpwd=pwd" method="POST"> PMSCCRID <input name="PMSCCRID" value="6" type="text"> <p/> DESCRIPTION <input name="DESCRIPTION" value="Create Project 01" type="text"> <p/> 1.DESCRIPTION <input name="PMRDPVSRPARM.1.DESCRIPTION" value="Network hostname" type="text"><p/> 1.SRCTOKEN <input name="PMRDPVSRPARM.1.SRCTOKEN" value="0" type="text"><p/> 1.SRCTYPE <input name="PMRDPVSRPARM.1.SRCTYPE" value="VST" type="text"><p/> 1.SRCATTRNAME <input name="PMRDPVSRPARM.1.SRCATTRNAME" value="PMRDP.NET.HOSTNAME" type="text"><p/> 1.SRCATTRVAL <input name="PMRDPVSRPARM.1.SRCATTRVAL" value=MyTestHost" type=text"><p/> 2.DESCRIPTION <input name="PMRDPVSRPARM.2.DESCRIPTION" value=NIC Count" type="text"><p/> 2.SRCTOKEN <input name="PMRDPVSRPARM.2.SRCTOKEN" value="0" type="text"><p/> 2.SRCTYPE <input name="PMRDPVSRPARM.2.SRCTYPE" value="VST" type="text"><p/> 2.SRCATTRNAME <input name="PMRDPVSRPARM.2.SRCATTRNAME" value="PMRDP.Net.NicCount " type="text"><p/> 2.SRCATTRVAL <input name="PMRDPVSRPARM.2.SRCATTRVAL" value=2" type=text"><p/> <input type="submit" value="Submit"> </form>
v An 'update' request example (HTML form based):

381
<form name="input" action="http://localhost:9080/maxrest/rest/os/SRM_SRCREATE/1010? _lid=userid&_lpwd=pwd" method="POST"> PMSCCRID <input name="PMSCCRID" value="6" type="text"> <p/> TICKETID <input name="TICKETID" value="1010" type="text"> <p/> <input type="submit" value="Submit"> </form>
Remember: Remember to specify the following in your requests: v In the 'update' request, the instance ID of the main MBO (1010 in the example) v The unique key of the MBO (ticketid in the example) v The attribute that is to be modified (PMSCCRID in the example)
Special POST system attribute

The _action attribute specifies the type of the POST request and can take one of the following values: v v v v v Add - creates a new entry Change - modifies an existing entry Replace - replaces an existing entry Delete - deletes an existing entry AddChange - creates a new entry if it does not exist, or modifies it if it exists
Create catalog requests (PMSCCR)

Use the SRM_CARDCREATE and SRM_SRCREATE object structures to create catalog requests. Object structure name: SRM_CARDCREATE, SRM_SRCREATE The SRM_CARDCREATE and SRM_SRCREATE are the only object structures which are used for create in the TSAM REST interface. The following assumptions apply to this object structure: v It is a 3 stage process to completely create a PMSCCR request ( Shopping Cart Request). v The first request creates a PMSCCR. The return information is used to link the SR against the PMSCCR. v The metadata for SR (create) is based on the offering details and the logged-on user. v The metadata for TICKETSPEC (modify) is based on the return data from the create SR stage. In this step, the classification attribute values are filled with data. v The complete request is passed to the REST implementation via a post request. Therefore, it would be possible to use an html post for testing. v The pmrdpvsparam MBO would be used to transport the dynamic parameter list for the offerings which require a dynamic set of input parameters. The 3 stage process allows to consistently update the values in the newly created PMSCCR until the user presses the submit button in the UI. First, the PMSCCR is created:
382
HTML form for the create PMSCCR stage

<form name="input" action="http://localhost:9080/maxrest/rest/os/SRM_CARDCREATE?_lid=PMRDPCAUSR&_lpwd=maxadmin" method="POST"> CHANGEBY <input name="CHANGEBY" value="PMRDPCAUSR" type="text"> <p/> CREATEDBY <input name="CREATEDBY" value="PMRDPCAUSR" type="text"> <p/> REPORTEDBY <input name="REPORTEDBY" value="PMRDPCAUSR" type="text"> <p/> SITEID ORGID <input name="SITEID" value="PMSCRTP" type="text"> <input name="ORGID" value="PMSCIBM" type="text"> <p/> <p/> <p/>
DESCRIPTION <input name="DESCRIPTION" value="PMSCCR GO1" type="text"> <input type="submit" value="Submit"> </form>
Output of the PMSCCR create request

<?xml version="1.0" encoding="UTF-8" ?> <createsrm_cardcreateresponse creationdatetime="2010-06-24T16:07:05+02:00" translanguage="EN" baselanguage="EN" messageid="1277388425954438821" maximoversion="7 1 20091208-1415 V7116-173" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_cardcreateset> <pmsccr> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:07:05+02:00</changedate> <description>PMSCCR GO1</description> <historyflag>0</historyflag> <orgid>PMSCIBM</orgid> <pmsccrid>6</pmsccrid> <pmsccrnum>1029</pmsccrnum> <requestedby>PMRDPCAUSR</requestedby> <requesteddate>2010-06-24T16:07:05+02:00</requesteddate> <requestedfor>PMRDPCAUSR</requestedfor> <siteid>PMSCRTP</siteid> <status>DRAFT</status> <statusdate>2010-06-24T16:07:05+02:00</statusdate> </pmsccr> </srm_cardcreateset> </createsrm_cardcreateresponse>
Second the SR is created and linked to the PMSCCR. The kind of request depends on the offering that should be run. The offering can be queried via REST. See the SRM_OFFERINGDET request for details. The following values are used from this request: v ITEMNUM v CLASSSTRUCTUREID v COMMODITYGROUP v COMMODITY The CREATEDBY and REPORTEDBY come from the logged on user. The PMSCCRID comes from the pmsccrnum attribute of the first request (PMSCCR). The PMRDPVSPARM value can be set during the SR creation. The following 5 lines together set a single attribute in the PMRDPVSRPARM MBO. The 1 in the name has to be incremented for each attribute by one. So the second block will contain 2 at this place and so on:
383
<input <input <input <input <input
name="PMRDPVSRPARM.1.DESCRIPTION" value="Network hostname" type="text"> name="PMRDPVSRPARM.1.SRCTOKEN" value="0" type="text"> name="PMRDPVSRPARM.1.SRCTYPE" value="VST" type="text"> name="PMRDPVSRPARM.1.SRCATTRNAME" value="PMRDP.NET.HOSTNAME" type="text"> name="PMRDPVSRPARM.1.SRCATTRVAL" value="0" type="mytesthost">
v v v v
DESCRIPTION is a free text field to document the parameter. SRCTOKEN has to be set to 0. SRCTYPE could be either VST or SRT. SRCATTRNAME is the attribute name which should be set.
v SRCATTRVAL is the value which should be set for the attribute.
HTML form for the create SR stage

<form name="input" action="http://localhost:9080/maxrest/rest/os/SRM_SRCREATE?_lid=PMRDPCAUSR&_lpwd=maxadmin" method="POST">  CREATEDBY <input name="CREATEDBY" value="PMRDPCAUSR" type="text"> <p/>
 REPORTEDBY <input name="REPORTEDBY" value="PMRDPCAUSR" type="text"> <p/>  CLASS <input name="CLASS" value="SR" type="text"> <p/>
 PMSCCRID <input name="PMSCCRID" value="6" type="text"> <p/>  DESCRIPTION <input name="DESCRIPTION" value="Create Project 01" type="text"> <p/>    PMSCITEMNUM <input name="PMSCITEMNUM" value="PMRDP_0201A_72" type="text"> <p/>  CLASSSTRUCTUREID<input name="CLASSSTRUCTUREID" value="8100210" type="text"> <p/>  COMMODITYGROUP <input name="COMMODITYGROUP" value="SRVAUTOM" type="text"> <p/>  COMMODITY <input name="COMMODITY" value="VSERVER" type="text"> <p/>
 CUSTOMER <input name="PLUSPCUSTOMER" value="PMRDPCUST" type="text"> <p/>   VSRPARM.1.DESCRIPTION<input name="PMRDPVSRPARM.1.DESCRIPTION" value="Network hostname" 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.NET.HOSTNAME" type="text"><p/> VSRPARM.1.SRCATTRVAL <input name="PMRDPVSRPARM.1.SRCATTRVAL" value="0" type="mytesthost"><p/>  VSRPARM.2.DESCRIPTION<input name="PMRDPVSRPARM.2.DESCRIPTION" value="Network Nic Num" type="text"><p/> VSRPARM.2.SRCTOKEN <input name="PMRDPVSRPARM.2.SRCTOKEN" value="0" type="text"><p/> VSRPARM.2.SRCTYPE <input name="PMRDPVSRPARM.2.SRCTYPE" value="VST" type="text"><p/> VSRPARM.2.SRCATTRNAME<input name="PMRDPVSRPARM.2.SRCATTRNAME" value="PMRDP.NET.NicNum" type="text"><p/> VSRPARM.2.SRCATTRVAL <input name="PMRDPVSRPARM.2.SRCATTRVAL" value="3" type="text"><p/> <input type="submit" value="Submit"> </form>
Starting with Tivoli Service Automation Manager 7.2.2, service provider enablement is active. Service requests have an additional mandatory field PLUSPCUSTOMER. As cloud administrator, when you are creating a service request you can set this field to any on-boarded customer. These are Customers which are created via the create customer offering or PMRDPCUST, which is the default
384
customer supplied by Tivoli Service Automation Manager 7.2.2. If you have customer scope privilege, you have to set the field to the customer you are belonging to. Note: If this attribute is not set according to the rules, the service provider enablement refuses to create the service request.
Output of the SR create request

<?xml version="1.0" encoding="UTF-8" ?> <createsrm_srcreateresponse creationdatetime="2010-06-24T16:31:48+02:00" translanguage="EN" baselanguage="EN" messageid="1277389908735681658" maximoversion="7 1 20091208-1415 V7116-173" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_srcreateset> <sr> <affecteddate>2010-06-24T16:31:47+02:00</affecteddate> <affectedemail>pmrdpcausr@localhost</affectedemail> <affectedperson>PMRDPCAUSR</affectedperson> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <class>SR</class> <classificationid>PMRDP_SR_CREATE_PROJECT_VMWARE_SERVER</classificationid> <classstructureid>8100210</classstructureid> <commodity>VSERVER</commodity> <commoditygroup>SRVAUTOM</commoditygroup> <createdby>PMRDPCAUSR</createdby> <creationdate>2010-06-24T16:31:47+02:00</creationdate> <description>Create Project 01</description> <hassolution>0</hassolution> <isknownerror>0</isknownerror> <pluspcustomer>PMRDPCUST</pluspcustomer> <pmsccrid>6</pmsccrid> <pmscitemnum>PMRDP_0201A_72</pmscitemnum> <reportdate>2010-06-24T16:31:47+02:00</reportdate> <reportedby>PMRDPCAUSR</reportedby> <reportedemail>pmrdpcausr@localhost</reportedemail> <selfservsolaccess>0</selfservsolaccess> <status>NEW</status> <ticketid>1153</ticketid> <ticketuid>290</ticketuid> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEINSTANCEID</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1478</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>1</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>98</ticketspecid> <assetattribute> <assetattributeid>735</assetattributeid> <datatype>NUMERIC</datatype> <description>Service Deployment Instance ID</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEDEFINITIONREVISION</assetattrid> <changeby>PMRDPCAUSR</changeby>
385
<changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1477</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>2</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>99</ticketspecid> <assetattribute> <assetattributeid>770</assetattributeid> <datatype>NUMERIC</datatype> <description>Service Definition Revision</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEDEFINITIONNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1476</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>3</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>100</ticketspecid> <assetattribute> <assetattributeid>734</assetattributeid> <datatype>ALN</datatype> <description>Service Definition Number</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLVSRV_MPNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1491</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>4</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>101</ticketspecid> <assetattribute> <assetattributeid>771</assetattributeid> <datatype>ALN</datatype> <description>Management Plan</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_PROJECTNAME</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1474</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>5</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>102</ticketspecid> <assetattribute> <assetattributeid>732</assetattributeid> <datatype>ALN</datatype> <description>Project Name</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_PROJECTID</assetattrid>
386
<changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1473</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>6</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>103</ticketspecid> <assetattribute> <assetattributeid>801</assetattributeid> <datatype>ALN</datatype> <description>Project Identifier</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_DESCRIPTION</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1470</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>7</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>104</ticketspecid> <assetattribute> <assetattributeid>730</assetattributeid> <datatype>ALN</datatype> <description>Project Description</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVERQTY</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1475</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>8</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>105</ticketspecid> <assetattribute> <assetattributeid>733</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Servers to be Provisioned</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_MEMORY</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1479</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>9</displaysequence> <mandatory>0</mandatory> <measureunitid>MBYTE</measureunitid> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>106</ticketspecid> <assetattribute> <assetattributeid>739</assetattributeid> <datatype>NUMERIC</datatype> <description>Amount of Memory (in MBs)</description> <measureunitid>MBYTE</measureunitid> </assetattribute>
387
</ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_NUMBER_CPUS</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1480</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>10</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>107</ticketspecid> <assetattribute> <assetattributeid>741</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Virtual CPUs</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_NUMBER_PCPUS</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1481</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>11</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>108</ticketspecid> <assetattribute> <assetattributeid>802</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Tenths of Physical CPUs</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_STORAGE_SIZE</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1484</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>12</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>109</ticketspecid> <assetattribute> <assetattributeid>803</assetattributeid> <datatype>NUMERIC</datatype> <description>Disk Space Size (in GBs)</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLSWS_IMAGEID</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1487</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>13</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>110</ticketspecid> <assetattribute> <assetattributeid>804</assetattributeid> <datatype>NUMERIC</datatype> <description>Image to be Deployed</description>
388
</assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_SWAP_SIZE</assetattrid> <changeby>PMRDPCAUSR</changeby>
The result of this request contains all the classification attributes created with empty values. Third request fills the asset attributes with the real values which should be passed to the service request. It is the requirement of the third stage to lookup the classification attributes and produce the third stage post document (modify document). To successfully do this the result of the second stage has to be parsed. The following data types are supported: v ALNVALUE v NUMVALUE v TABLEVALUE The third stage has to set the correct type field in the ticketspec entry. Note: Starting with Tivoli Service Automation Manager 7.2.2 attributes are validated using table domains. Therefore, some attributes have changed to the data type tablevalue. Make sure that you update the attributes according to their data type. If you set the wrong data type value, the request does not pass the request validation and fails. You can find the data type of the attribute by looking at the response from the stage 2 request, for example:
<ticketspec> <assetattrid>PMRDPCLCVS_STORAGE_SIZE</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1484</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>12</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>109</ticketspecid> <assetattribute> <assetattributeid>803</assetattributeid> <datatype>NUMERIC</datatype> <description>Disk Space Size (in GBs)</description> </assetattribute> </ticketspec>
In this example, the attribute PMRDPCLCVS_STORAGE_SIZE has the data type NUMERIC. To set this property to a value you have to update NUMVALUE of this attribute in the third request. Use this algorithm to determine the data type of the asset attribute. This reduces the migration effort in future releases. The source attribute in the service request indicates that the request is complete and ready for processing. Setting this attribute to TSAMWEBUI starts the processing of the request.
SOURCE<input name="SOURCE" value="TSAMWEBUI" type="text">
SOURCE must be set to TSAMWEBUI. Each asset attribute in the ticketspec has to be filled which such a block of 5 attributes in the post:
389
<input <input <input <input <input or <input or <input
name="TICKETSPEC.1.REFOBJECTID" value="290" type="text"> name="TICKETSPEC.1.ASSETATTRID" value="PMRDPCLCPR_SERVICEINSTANCEID" type="text"> name="TICKETSPEC.1.TICKETSPECID" value="98" type="text"> name="TICKETSPEC.1.SECTION" value="" type="text"> name="TICKETSPEC.1.NUMVALUE" value="10" type="text"> name="TICKETSPEC.1.ALNVALUE" value="10" type="text"> name="TICKETSPEC.1.TABLEVALUE" value="10" type="text">
v REFOBJECTID has to be set to the refobjectid of the assetattribute which should be set. The value can be retrieved by parsing the second response document. v ASSETATTRID has to be set to the name of the assetattribute which should be changed. v TICKETSPECID has to be set to the ticketspecid of the assetattribute which should be set. The value can be retrieved by parsing the second response document. v SECTION has to be set to an empty string. It is required that this parameter has to be set. v ALNVALUE, NUMVALUE, TABLEVALUE: one of these three attributes must be set depending on the data type of the asset attribute that must be set. The value can be retrieved by parsing the second response document and looking for the assetattribute.datatype value of the asset attribute that must be changed. Do not statically code the data type but instead use the dynamic approach by parsing the response from the second request. This will reduce the migration effort it the data types must be changed due to validation requirements.
HTML form for the modify the ticket spec stage

<form name="input" action="http://localhost:9080/maxrest/rest/os/SRM_SRCREATE/290?_lid=maxadmin&_lpwd=maxadmin" method="POST">  TICKETID<input name="TICKETID" value="1153" type="text"><p/>  SOURCE<input name="SOURCE" value="TSAMWEBUI" type="text"><p/>   TICKETSPEC.1.REFOBJECTID<input name="TICKETSPEC.1.REFOBJECTID" value="290" type="text"><p/>  TICKETSPEC.1.ASSETATTRID<input name="TICKETSPEC.1.ASSETATTRID" value="PMRDPCLCPR_SERVICEINSTANCEID" type="text"><p/>  TICKETSPEC.1.TICKETSPECID<input name="TICKETSPEC.1.TICKETSPECID" value="98" type="text"><p/>  TICKETSPEC.1.SECTION<input name="TICKETSPEC.1.SECTION" value="" type="text"><p/>     TICKETSPEC.1.NUMVALUE<input name="TICKETSPEC.1.NUMVALUE" value="10" type="text"> <p/>   TICKETSPEC.2.REFOBJECTID<input name="TICKETSPEC.2.REFOBJECTID" value="290" type="text"><p/>  TICKETSPEC.2.ASSETATTRID<input name="TICKETSPEC.2.ASSETATTRID" value="PMRDPCLCPR_PROJECTNAME" type="text"><p/>  TICKETSPEC.2.TICKETSPECID<input name="TICKETSPEC.2.TICKETSPECID" value="102" type="text"><p/>  TICKETSPEC.2.SECTION<input name="TICKETSPEC.2.SECTION" value="" type="text"><p/>     TICKETSPEC.2.NUMVALUE<input name="TICKETSPEC.2.ALNVALUE" value="myproject" type="text"> <p/> <input type="submit" value="Submit"> </form>
Output of the modify ticket spec attribute request

<?xml version="1.0" encoding="UTF-8" ?> <syncsrm_srcreateresponse creationdatetime="2010-06-24T16:53:20+02:00"
390
translanguage="EN" baselanguage="EN" messageid="1277391200563916099" maximoversion="7 1 20091208-1415 V7116-173" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.ibm.com/maximo" > <srm_srcreateset> <sr> <affecteddate>2010-06-24T16:31:47+02:00</affecteddate> <affectedemail>pmrdpcausr@localhost</affectedemail> <affectedperson>PMRDPCAUSR</affectedperson> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <class>SR</class> <classificationid>PMRDP_SR_CREATE_PROJECT_VMWARE_SERVER</classificationid> <classstructureid>8100210</classstructureid> <commodity>VSERVER</commodity> <commoditygroup>SRVAUTOM</commoditygroup> <createdby>PMRDPCAUSR</createdby> <creationdate>2010-06-24T16:31:47+02:00</creationdate> <description>Create Project 01</description> <hassolution>0</hassolution> <isknownerror>0</isknownerror> <pmsccrid>6</pmsccrid> <pmscitemnum>PMRDP_0201A_72</pmscitemnum> <reportdate>2010-06-24T16:31:47+02:00</reportdate> <reportedby>PMRDPCAUSR</reportedby> <reportedemail>pmrdpcausr@localhost</reportedemail> <selfservsolaccess>0</selfservsolaccess> <status>NEW</status> <source>TSAMWEBUI</source>source> <ticketid>1153</ticketid> <ticketuid>290</ticketuid> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEINSTANCEID</assetattrid> <changeby>MAXADMIN</changeby> <changedate>2010-06-24T16:53:20+02:00</changedate> <classspecid>1478</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>1</displaysequence> <mandatory>0</mandatory>  <numvalue>10.0</numvalue> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>98</ticketspecid> <assetattribute> <assetattributeid>735</assetattributeid> <datatype>NUMERIC</datatype> <description>Service Deployment Instance ID</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEDEFINITIONREVISION</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1477</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>2</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>99</ticketspecid> <assetattribute> <assetattributeid>770</assetattributeid> <datatype>NUMERIC</datatype>
391
<description>Service Definition Revision</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVICEDEFINITIONNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1476</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>3</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>100</ticketspecid> <assetattribute> <assetattributeid>734</assetattributeid> <datatype>ALN</datatype> <description>Service Definition Number</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLVSRV_MPNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1491</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>4</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>101</ticketspecid> <assetattribute> <assetattributeid>771</assetattributeid> <datatype>ALN</datatype> <description>Management Plan</description> </assetattribute> </ticketspec> <ticketspec>  <alnvalue>myproject</alnvalue> <assetattrid>PMRDPCLCPR_PROJECTNAME</assetattrid> <changeby>MAXADMIN</changeby> <changedate>2010-06-24T16:53:20+02:00</changedate> <classspecid>1474</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>5</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>102</ticketspecid> <assetattribute> <assetattributeid>732</assetattributeid> <datatype>ALN</datatype> <description>Project Name</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_PROJECTID</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1473</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>6</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>103</ticketspecid>
392
<assetattribute> <assetattributeid>801</assetattributeid> <datatype>ALN</datatype> <description>Project Identifier</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_DESCRIPTION</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1470</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>7</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>104</ticketspecid> <assetattribute> <assetattributeid>730</assetattributeid> <datatype>ALN</datatype> <description>Project Description</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_SERVERQTY</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1475</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>8</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>105</ticketspecid> <assetattribute> <assetattributeid>733</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Servers to be Provisioned</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_MEMORY</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1479</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>9</displaysequence> <mandatory>0</mandatory> <measureunitid>MBYTE</measureunitid> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>106</ticketspecid> <assetattribute> <assetattributeid>739</assetattributeid> <datatype>NUMERIC</datatype> <description>Amount of Memory (in MBs)</description> <measureunitid>MBYTE</measureunitid> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_NUMBER_CPUS</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1480</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>10</displaysequence> <mandatory>0</mandatory>
393
<refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>107</ticketspecid> <assetattribute> <assetattributeid>741</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Virtual CPUs</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_NUMBER_PCPUS</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1481</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>11</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>108</ticketspecid> <assetattribute> <assetattributeid>802</assetattributeid> <datatype>NUMERIC</datatype> <description>Number of Tenths of Physical CPUs</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_STORAGE_SIZE</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1484</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>12</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>109</ticketspecid> <assetattribute> <assetattributeid>803</assetattributeid> <datatype>NUMERIC</datatype> <description>Disk Space Size (in GBs)</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLSWS_IMAGEID</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1487</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>13</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>110</ticketspecid> <assetattribute> <assetattributeid>804</assetattributeid> <datatype>NUMERIC</datatype> <description>Image to be Deployed</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_SWAP_SIZE</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1485</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>14</displaysequence>
394
<mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>111</ticketspecid> <assetattribute> <assetattributeid>805</assetattributeid> <datatype>NUMERIC</datatype> <description>Swap Size</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLSWS_MONITORING</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1488</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>15</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>112</ticketspecid> <assetattribute> <assetattributeid>806</assetattributeid> <datatype>ALN</datatype> <description>Monitoring Agent to be Installed</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_RESGRPNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1483</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>16</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>113</ticketspecid> <assetattribute> <assetattributeid>777</assetattributeid> <datatype>ALN</datatype> <description>Resource Group Used to Reserve Resources</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLSWS_SWIDS</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:47+02:00</changedate> <classspecid>1489</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>17</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>114</ticketspecid> <assetattribute> <assetattributeid>807</assetattributeid> <datatype>ALN</datatype> <description>Software Identifiers</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_PERSONGROUP</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1471</classspecid> <classstructureid>8100210</classstructureid>
395
<displaysequence>18</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>115</ticketspecid> <assetattribute> <assetattributeid>731</assetattributeid> <datatype>ALN</datatype> <description>Team to Grant Access</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_TYPE</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1486</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>19</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>116</ticketspecid> <assetattribute> <assetattributeid>748</assetattributeid> <datatype>ALN</datatype> <description>Virtual Server Type</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLVSRV_NOTIFY_MPNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1492</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>20</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>117</ticketspecid> <assetattribute> <assetattributeid>808</assetattributeid> <datatype>ALN</datatype> <description>Management Plan for Notify</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLVSRV_DELETE_MPNUM</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1490</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>21</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>118</ticketspecid> <assetattribute> <assetattributeid>809</assetattributeid> <datatype>ALN</datatype> <description>Management Plan for Delete</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCPR_PROJECTACCOUNT</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1472</classspecid>
396
<classstructureid>8100210</classstructureid> <displaysequence>22</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>119</ticketspecid> <assetattribute> <assetattributeid>810</assetattributeid> <datatype>ALN</datatype> <description>Project Account</description> </assetattribute> </ticketspec> <ticketspec> <assetattrid>PMRDPCLCVS_RESGRPNAME</assetattrid> <changeby>PMRDPCAUSR</changeby> <changedate>2010-06-24T16:31:48+02:00</changedate> <classspecid>1482</classspecid> <classstructureid>8100210</classstructureid> <displaysequence>23</displaysequence> <mandatory>0</mandatory> <refobjectid>290</refobjectid> <refobjectname>SR</refobjectname> <ticketspecid>120</ticketspecid> <assetattribute> <assetattributeid>880</assetattributeid> <datatype>ALN</datatype> <description>Name of the Resource Group</description> </assetattribute> </ticketspec> <pmrdpvsrparm> <description>Network Nic Num</description> <pmrdpvsrparmid>1</pmrdpvsrparmid> <srcattrname>PMRDP.NET.NicNum</srcattrname> <srcattrval>3</srcattrval> <srctoken>0</srctoken> <srctype>VST</srctype> <srid>290</srid> </pmrdpvsrparm> <pmrdpvsrparm> <description>Network hostname</description> <pmrdpvsrparmid>2</pmrdpvsrparmid> <srcattrname>PMRDP.NET.HOSTNAME</srcattrname> <srcattrval>0</srcattrval> <srctoken>0</srctoken> <srctype>VST</srctype> <srid>290</srid> </pmrdpvsrparm> </sr> </srm_srcreateset> </syncsrm_srcreateresponse>
Interfaces via Web services (PMRDPBCAPI)

The Web Services methods in this section are implemented within the PMRDPBCAPI service. They are exposed via the Integration framework standard services functionality.
Before you begin

You must create and deploy the Web Service prior to usage.
About this task

The WSDL for the Web Services can be retrieved using the following method:
397
Note: The Maximo Integration Guide describes a Web URL that can be used to retrieve the WSDL for a service.
Procedure
1. 2. 3. 4. 5. Click Go To > Integration > Web Services Library. Change to the Web Services Library tab. Click the Generate Schema/View XML button. Change to the List tab. Select the Web Service from the list.
6. Set the mxe.int.globaldir system property to an existing directory.
pmrdpbcapigetAvailableCapacityData Method
Use this request to retrieve available capacity data. The request has the following input parameters: vrpoolId The poolid as retrieved via the pmrdpbcapigetAvailablePoolList call. startTime Specifies the start time when the resource should be available. endTime Specifies the end time when the resource should be released. CPU Specifies the CPU share that should be used.
memMB Specifies the RAM memory that should be used. stgGB Specifies the disk storage that should be used. The request returns the following values. One record for each attribute type (cpu,memory,storage, servernum) is returned. This is the response structure: v CIRCAPACITYVIEW is the base return structure for each attribute type. CINUM specifies the CI, which is currently empty. ASSETATTRID could be one of the following: - PMRDPCLCVS_MEMORY - PMRDPCLCVS_STORAGE_SIZE - PMRDPCLCVS_NUMBER_PCPUS - PMRDPCLCPR_SERVERQTY SECTION is empty. MEASUREUNITID is empty. NUMVALUE contains the amount of the given type.
Request data structure

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailableCapacityData xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:vrpoolId>string</max:vrpoolId> <max:startTime>2006-09-19T01:18:33</max:startTime>
398
<max:endTime>2014-08-19T19:27:14+02:00</max:endTime> <max:cpu>3</max:cpu> <max:memMB>3</max:memMB> <max:stgGB>3</max:stgGB> </max:pmrdpbcapigetAvailableCapacityData>
Response data structure

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailableCapacityDataResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:CIRCAPACITYVIEWMboSet> <max:CIRCAPACITYVIEW action="Delete"> <max:CINUM changed="true">string</max:CINUM> <max:ASSETATTRID changed="true">string</max:ASSETATTRID> <max:SECTION changed="true">string</max:SECTION> <max:MEASUREUNITID changed="false">string</max:MEASUREUNITID> <max:NUMVALUE changed="false">1.051732E7</max:NUMVALUE> </max:CIRCAPACITYVIEW> </max:CIRCAPACITYVIEWMboSet> </max:pmrdpbcapigetAvailableCapacityDataResponse>
Sample request
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:q0="http://www.ibm.com/maximo" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <q0:pmrdpbcapigetAvailableCapacityData> <q0:vrpoolId>/cloud/rest/pools/3/</q0:vrpoolId> <q0:startTime>2006-09-19T01:18:33</q0:startTime> <q0:endTime>2008-09-19T01:18:33</q0:endTime> <q0:cpu>2</q0:cpu> <q0:memMB>1024</q0:memMB> <q0:stgGB>20</q0:stgGB> </q0:pmrdpbcapigetAvailableCapacityData> </soapenv:Body> </soapenv:Envelope>
Sample response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <pmrdpbcapigetAvailableCapacityDataResponse xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" baseLanguage="EN" creationDateTime="2009-10-26T10:21:21+01:00" messageID="1256548881155199001" transLanguage="EN"> <CIRCAPACITYVIEWMboSet> <CIRCAPACITYVIEW> <CINUM /> <ASSETATTRID>PMRDPCLCVS_MEMORY</ASSETATTRID> <SECTION /> <MEASUREUNITID /> <NUMVALUE>250.0</NUMVALUE> </CIRCAPACITYVIEW> <CIRCAPACITYVIEW> <CINUM />
399
<ASSETATTRID>PMRDPCLCVS_STORAGE_SIZE</ASSETATTRID> <SECTION /> <MEASUREUNITID /> <NUMVALUE>40.0</NUMVALUE> </CIRCAPACITYVIEW> <CIRCAPACITYVIEW> <CINUM /> <ASSETATTRID>PMRDPCLCVS_NUMBER_PCPUS</ASSETATTRID> <SECTION /> <MEASUREUNITID /> <NUMVALUE>44.0</NUMVALUE> </CIRCAPACITYVIEW> <CIRCAPACITYVIEW> <CINUM /> <ASSETATTRID>PMRDPCLCPR_SERVERQTY</ASSETATTRID> <SECTION /> <MEASUREUNITID /> <NUMVALUE>50.0</NUMVALUE> </CIRCAPACITYVIEW> </CIRCAPACITYVIEWMboSet> </pmrdpbcapigetAvailableCapacityDataResponse> </soapenv:Body> </soapenv:Envelope>
pmrdpbcapigetAvailablePoolList Method
Retrieves the currently available pools in the system. The following structure is returned: v PMRDPBCPOOLS structure is returned for each pool, which is currently available. NAME specifies the name of the pool. ID specifies the id of the pool which is used in subsequent calls. PLATFORMTYPE specifies the hypervisor types.

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailablePoolList xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string" />

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailablePoolListResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:PMRDPBCPOOLSMboSet> <max:PMRDPBCPOOLS action="Delete"> <max:NAME changed="true">string</max:NAME> <max:ID changed="true">string</max:ID> <max:PLATFORMTYPE changed="true">string</max:PLATFORMTYPE> </max:PMRDPBCPOOLS> </max:PMRDPBCPOOLSMboSet> </max:pmrdpbcapigetAvailablePoolListResponse>
400
Sample request
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:q0="http://www.ibm.com/maximo" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <q0:pmrdpbcapigetAvailablePoolList /> </soapenv:Body> </soapenv:Envelope>
Sample response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <pmrdpbcapigetAvailablePoolListResponse xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" baseLanguage="EN" creationDateTime="2009-10-26T10:09:21+01:00" messageID="125654816190585702" transLanguage="EN"> <PMRDPBCPOOLSMboSet> <PMRDPBCPOOLS> <NAME>VMware</NAME> <ID>/cloud/rest/pools/3/</ID> <PLATFORMTYPE>VMware</PLATFORMTYPE> </PMRDPBCPOOLS> <PMRDPBCPOOLS> <NAME>LPAR</NAME> <ID>/cloud/rest/pools/1/</ID> <PLATFORMTYPE>LPAR</PLATFORMTYPE> </PMRDPBCPOOLS> <PMRDPBCPOOLS> <NAME>Xen</NAME> <ID>/cloud/rest/pools/2/</ID> <PLATFORMTYPE>Xen</PLATFORMTYPE> </PMRDPBCPOOLS> <PMRDPBCPOOLS> <NAME>KVM</NAME> <ID>/cloud/rest/pools/4/</ID> <PLATFORMTYPE>KVM</PLATFORMTYPE> </PMRDPBCPOOLS> <PMRDPBCPOOLS> <NAME>zVM</NAME> <ID>/cloud/rest/pools/5/</ID> <PLATFORMTYPE>zVM</PLATFORMTYPE> </PMRDPBCPOOLS> </PMRDPBCPOOLSMboSet> </pmrdpbcapigetAvailablePoolListResponse> </soapenv:Body> </soapenv:Envelope>
401
pmrdpbcapigetAvailableCapacityForPools Method
Retrieves the available capacity for each available pool in the system. For each attribute in each pool, there is one return record in the response. The capacity is returned based on the time values specified in the request. The following attributes are part of the request: startTime Specifies the start time. endTime Specifies the end time. This return data structure is as follows: v CIRCAPACITYVIEW is the base return structure for each attribute type. CINUM specifies the poolid. ASSETATTRID could be one of the following: - PMRDPCLCVS_MEMORY - PMRDPCLCVS_STORAGE_SIZE - PMRDPCLCVS_NUMBER_PCPUS SECTION is SINGLESR MEASUREUNITID is empty NUMVALUE contains the amount of the given type

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailableCapacityForPools xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:startTime>2014-09-19T01:18:33</max:startTime> <max:endTime>2006-08-19T19:27:14+02:00</max:endTime> </max:pmrdpbcapigetAvailableCapacityForPools>

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetAvailableCapacityForPoolsResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:CIRCAPACITYVIEWMboSet> <max:CIRCAPACITYVIEW action="Delete"> <max:CINUM changed="true">string</max:CINUM> <max:ASSETATTRID changed="true">string</max:ASSETATTRID> <max:SECTION changed="true">string</max:SECTION> <max:MEASUREUNITID changed="false">string</max:MEASUREUNITID> <max:NUMVALUE changed="false">1.051732E7</max:NUMVALUE> </max:CIRCAPACITYVIEW> </max:CIRCAPACITYVIEWMboSet> </max:pmrdpbcapigetAvailableCapacityForPoolsResponse>
402
Sample request
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:q0="http://www.ibm.com/maximo" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <q0:pmrdpbcapigetAvailableCapacityForPools> <q0:startTime>2008-09-19T01:18:33</q0:startTime> <q0:endTime>2009-09-19T01:18:33</q0:endTime> </q0:pmrdpbcapigetAvailableCapacityForPools> </soapenv:Body> </soapenv:Envelope>
Sample response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <pmrdpbcapigetAvailableCapacityForPoolsResponse xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" baseLanguage="EN" creationDateTime="2009-10-26T10:31:29+01:00" messageID="1256549489468784835" transLanguage="EN"> <CIRCAPACITYVIEWMboSet> <CIRCAPACITYVIEW> <CINUM>/CLOUD/REST/POOLS/3/</CINUM> <ASSETATTRID>PMRDPCLCVS_MEMORY</ASSETATTRID> <SECTION>SINGLESER</SECTION> <MEASUREUNITID /> <NUMVALUE>250.0</NUMVALUE> </CIRCAPACITYVIEW> <CIRCAPACITYVIEW> <CINUM>/CLOUD/REST/POOLS/3/</CINUM> <ASSETATTRID>PMRDPCLCVS_STORAGE_SIZE</ASSETATTRID> <SECTION>SINGLESER</SECTION> <MEASUREUNITID /> <NUMVALUE>40.0</NUMVALUE> </CIRCAPACITYVIEW> <CIRCAPACITYVIEW> <CINUM>/CLOUD/REST/POOLS/3/</CINUM> <ASSETATTRID>PMRDPCLCVS_NUMBER_PCPUS</ASSETATTRID> <SECTION>SINGLESER</SECTION> <MEASUREUNITID /> <NUMVALUE>44.0</NUMVALUE> </CIRCAPACITYVIEW> </CIRCAPACITYVIEWMboSet> </pmrdpbcapigetAvailableCapacityForPoolsResponse> </soapenv:Body> </soapenv:Envelope>
pmrdpbcapigetBCRealSysResMonitoringData Method
Retrieves the real time measurement data for a server if the IBM Tivoli Monitoring support was deployed during the creation of the project and server. The request expects two values, which identify the server for which the real time data should be retrieved: vrProjectId Specifies the project id where the server belongs to. ServerId Specifies the server id for which the real time data should be retrieved.
403
There will be one server monitor record for each available assetattribute in the response data. v SERVERMONITOR ASSETATTRID - PMRDPCLCVS_MEMORY - PMRDPCLCVS_STORAGE_SIZE - PMRDPCLCVS_NUMBER_PCPUS - PMRDPCLCVS_STATE of the server CINUM is empty MEASUREUNITID is empty NUMVALUE contains the value of the assetattribute STATE contains the state returned for PMRDPCLCVS_STATE otherwise empty

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetBCRealSysResMonitoringData xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:vrProjectId>string</max:vrProjectId> <max:vrServerId>string</max:vrServerId> </max:pmrdpbcapigetBCRealSysResMonitoringData>

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapigetBCRealSysResMonitoringDataResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:SERVERMONITORMboSet> <max:SERVERMONITOR action="Delete"> <max:ASSETATTRID changed="true">string</max:ASSETATTRID> <max:CINUM changed="true">string</max:CINUM> <max:MEASUREUNITID changed="true">string</max:MEASUREUNITID> <max:NUMVALUE changed="false">1.051732E7</max:NUMVALUE> <max:STATE changed="false">string</max:STATE> </max:SERVERMONITOR> </max:SERVERMONITORMboSet> </max:pmrdpbcapigetBCRealSysResMonitoringDataResponse>
Sample request
<?xml version="1.0" encoding="UTF-8" ?> <soapenv:Envelope xmlns:q0="http://www.ibm.com/maximo" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <q0:pmrdpbcapigetBCRealSysResMonitoringData> <q0:vrProjectId>1</q0:vrProjectId> <q0:vrServerId>1</q0:vrServerId> </q0:pmrdpbcapigetBCRealSysResMonitoringData> </soapenv:Body> </soapenv:Envelope>
404
Sample response
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <pmrdpbcapigetBCRealSysResMonitoringDataResponse xmlns="http://www.ibm.com/maximo" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" baseLanguage="EN" creationDateTime="2009-10-26T10:41:31+01:00" messageID="125655009103075017" transLanguage="EN"> <SERVERMONITORMboSet> <SERVERMONITOR> <ASSETATTRID>PMRDPCLCVS_MEMORY</ASSETATTRID> <CINUM /> <MEASUREUNITID /> <NUMVALUE>250.0</NUMVALUE> <STATE /> </SERVERMONITOR> <SERVERMONITOR> <ASSETATTRID>PMRDPCLCVS_STORAGE_SIZE</ASSETATTRID> <CINUM /> <MEASUREUNITID /> <NUMVALUE>40.0</NUMVALUE> <STATE /> </SERVERMONITOR> <SERVERMONITOR> <ASSETATTRID>PMRDPCLCVS_NUMBER_PCPUS</ASSETATTRID> <CINUM /> <MEASUREUNITID /> <NUMVALUE>44.0</NUMVALUE> <STATE /> </SERVERMONITOR> <SERVERMONITOR> <ASSETATTRID>PMRDPCLCVS_STATE</ASSETATTRID> <CINUM /> <MEASUREUNITID /> <NUMVALUE xsi:nil="true" /> <STATE>ONLINE</STATE> </SERVERMONITOR> </SERVERMONITORMboSet> </pmrdpbcapigetBCRealSysResMonitoringDataResponse> </soapenv:Body> </soapenv:Envelope>
pmrdpbcapiReassignWfAssignment Method
Enables reassigning the WfAssignment. The following parameters are required: wfassignId ID of the wfassignment. Assignee Person to whom the wfassignment should be reassigned. Taskdesc Optional string which describes the reason. The message throws an exception from the underlying implementation in failure situations and produces log statements.
405

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapiReassignWfAssignment xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:wfassignId>3</max:wfassignId> <max:assignee>string</max:assignee> <max:memo>string</max:memo> <max:taskdesc>string</max:taskdesc> </max:pmrdpbcapiReassignWfAssignment>

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapiReassignWfAssignmentResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string" />
pmrdpbcapiChangeWfAssignment Method
Enables accepting or rejecting a WfAssignment. The method has the following assumptions: v There is a task assignment which has only 2 out connectors in the workflow. A positive and a negative one. v The invoker passes the accept value as either true or false which has to match the 2 outgoing connectors in the workflow. The method requires the following parameters: wfassignId ID of the wfassignment. accept Can be either true or false. memo Optional text that is stored with the assignment record. The message throws an exception from the underlying implementation in failure situations and produces log statements.

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapiChangeWfAssignment xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string"> <max:accept>true</max:accept> <max:wfassignId>3</max:wfassignId> <max:memo>string</max:memo> </max:pmrdpbcapiChangeWfAssignment>

<?xml version="1.0" encoding="UTF-8"?> <max:pmrdpbcapiChangeWfAssignmentResponse xmlns:max="http://www.ibm.com/maximo" creationDateTime="2008-09-29T03:49:45" baseLanguage="string" transLanguage="string" messageID="string" maximoVersion="string" /> nv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
Additional relationships
Relationships were introduced with the object structures that simplify or compact the output results or are required to implement new behavior.
406
GETDOMAIN Relationship
Get the associated domain definition for a asset attribute. Parent Object ASSETATTRIBUTE Child Object MAXDOMAIN SQL Where Clause domainid=:domainid
PMZHB_SRSPECCLASS Relationship
Filters ticketspec attributes by a blacklist. Parent Object SR Child Object TICKETSPEC SQL Where Clause
refobjectid=:ticketuid and refobjectname=SR and classstructureid=:classstructureid and assetattrid not in ( PMRDPCLCUSR_PASSWORD, PMRDPREGIMG_ADMINPWD, PMRDPREGIMG_ROOTPWD, PMRDPCLCVS_PASSWORD, PMZHB_WAS_ADMIN_PWD, PMZHB_IHS_ADMIN_PWD, PMRDPREGIMG_USERNAME, PMRDPREGIMG_PRODUCT_KEY )
Additional filter domains

Several filter domains were introduced with the object structures.
PMZHBT_CLUSERROLE Filter Domain

Returns the cloud roles of a user. Domain Name PMZHBT_CLUSERROLE Object GROUPUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_GROUPUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_CLUSERROLE SQL Query
groupname in ) ( select value from synonymdomain where domainid =PMRDPCLOUDROLES
407
PMZHBT_CLOUDUSER Filter Domain

Lists all valid cloud users. Domain Name PMZHBT_CLOUDUSER Object MAXUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_MAXUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_CLOUDUSER SQL Query
userid in ( select userid from groupuser where groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) and status in ( select value from synonymdomain where domainid = MAXUSERSTATUS and maxvalue = ACTIVE )
PMZHBT_CLUSERROLE Filter Domain

Returns the cloud roles of a user. Domain Name PMZHBT_CLUSERROLE Object GROUPUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_GROUPUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_CLUSERROLE SQL Query
groupname in ) ( select value from synonymdomain where domainid =PMRDPCLOUDROLES
PMZHBT_LOGGEDONUSR Filter Domain

Returns the logged-on user. Domain Name PMZHBT_LOGGEDONUSR Object MAXUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_MAXUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_LOGGEDONUSR
408
SQL Query
userid = :user and status in ( select value from synonymdomain where domainid = MAXUSERSTATUS and maxvalue = ACTIVE )
PMZHBT_MODCLUSER Filter Domain

Returns the Cloud Users the logged-on user can modify. The query returns the data based on the role the current logged-on user has. Domain Name PMZHBT_MODCLUSER Object MAXUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_MAXUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_MODCLUSER SQL Query
userid in ( select userid from maxuser where userid in ( select userid from groupuser where groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) and status in ( select value from synonymdomain where domainid = MAXUSERSTATUS and maxvalue in (ACTIVE,INACTIVE)) and exists ( select groupname from groupuser where groupname = PMRDPCA and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) ) union select userid from maxuser where userid in ( select distinct respparty from persongroupteam where persongroup in ( select persongroup from persongroupteam where respparty = :user ) ) and status in ( select value from synonymdomain where domainid = MAXUSERSTATUS and maxvalue in (ACTIVE,INACTIVE) ) and exists ( select groupname from groupuser where groupname = PMRDPTA and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) union select userid from maxuser where userid = :user and
409
status in ( select value from synonymdomain where domainid = MAXUSERSTATUS and maxvalue in (ACTIVE,INACTIVE) ) and exists ( select groupname from groupuser where groupname in (PMRDPTU,PMRDPCM) and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) )
PMZHBT_REASSIGNLST Filter Domain

Returns the approval reassignment list and all cloud administrators. Domain Name PMZHBT_REASSIGNLST Object MAXUSER Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_MAXUSER?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_REASSIGNLST SQL Query
personid in ( select mu.personid from maxuser mu, groupuser gu where mu.userid=gu.userid and gu.groupname=PMRDPCA )
PMZHBT_SRAPPRLIST Filter Domain

Gets the Service Requests the current logged-on user can see for approval. The list is returned based on the logged-on user's role. Domain Name PMZHBT_SRAPPRLIST Object SR Sample URL http://localhost:9080/maxrest/rest/os/PMZHBR1_SR?_lid=maxadmin &_lpwd=maxadmin&_fd=PMZHBT_SRAPPRLIST SQL Query
ticketid in ( select sr.ticketid from SR sr where sr.commodity=VSERVER and sr.commoditygroup=SRVAUTOM and status in ( select value from synonymdomain where domainid = SRSTATUS and maxvalue = NEW ) and exists ( select groupname from groupuser where groupname in (PMRDPCA,PMRDPCM) and
410
userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) )
PMZHBT_SRUSRLIST Filter Domain

Gets the Service Requests the current logged-on user can see. This query returns the value based on the logged-on user's role. Domain Name PMZHBT_SRUSRLIST Object SR Sample URL http://localhost:9080/maxrest/rest/os/SRM_SRDET?_lid=maxadmin &_lpwd=maxadmin&_fd=PMZHBT_SRUSRLIST SQL Query
ticketid in ( select sr.ticketid from SR sr where sr.commodity=VSERVER and sr.commoditygroup=SRVAUTOM and sr.source = TSAMWEBUI and exists ( select groupname from groupuser where groupname in (PMRDPCA,PMRDPCM) and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) union select sr.ticketid from SR sr, ticketspec ts where sr.commodity=VSERVER and sr.commoditygroup=SRVAUTOM and sr.source = TSAMWEBUI and ts.class=SR and sr.ticketid = ts.ticketid and ts.assetattrid=PMRDPCLCPR_PERSONGROUP and ts.alnvalue in ( select persongroup from persongroupteam where respparty = :user and persongroup in ( select persongroup from persongroup where cloudteam=1 ) and exists ( select groupname from groupuser where groupname in (PMRDPTA,PMRDPTU) and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) ) union select sr.ticketid from SR where source = TSAMWEBUI and createdby = :user and exists ( select groupname from groupuser where groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES
411
) and userid =:user ) )
PMZHBT_SRVPRJLUSER Filter Domain

Returns the projects and servers the logged-on user can act on. Domain Name PMZHBT_SRVPRJLUSER Object PMRDPSIVIEW Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_PMRDPSIVIEW?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_SRVPRJLUSER SQL Query
persongroup in ( select persongroup from persongroup where cloudteam=1 and exists ( select groupname from groupuser where groupname in (PMRDPCA,PMRDPCM) and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) union select persongroup from persongroupteam where respparty = :user and persongroup in ( select persongroup from persongroup where cloudteam=1 ) and exists ( select groupname from groupuser where groupname in (PMRDPTA,PMRDPTU) and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) )
PMZHBT_USERSTEAM Filter Domain

Returns the Teams the logged-on user can modify. Domain Name PMZHBT_USERSTEAM Object PERSONGROUP Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_PERSONGROUP?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_USERSTEAM
412
SQL Query
persongroup in ( select persongroup from persongroup where cloudteam=1 and exists ( select groupname from groupuser where groupname = PMRDPCA and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) union select persongroup from persongroupteam where respparty = :user and persongroup in ( select persongroup from persongroup where cloudteam=1 ) and exists ( select groupname from groupuser where groupname = PMRDPTA and userid = :user and groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) ) )
PMZHBT_USERTEAMS Filter Domain

Returns the cloud teams a user is member of. Domain Name PMZHBT_USERTEAMS Object PERSONGROUPTEAM Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_PERSGRPTM?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_USERTEAMS SQL Query
persongroup in ( select persongroup from persongroup where cloudteam=1 )
PMZHBT_USRROLELIST Filter Domain

Lists the valid role a user can give. Domain Name PMZHBT_USRROLELIST Object MAXDOMAIN Sample URL http://localhost:9080/maxrest/rest/os/ PMZHBR1_MAXDOMAIN?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_USRROLELIST
413
SQL Query
domainid = PMRDPSEC_ CONCAT ( select groupname from groupuser where groupname in ( select value from synonymdomain where domainid =PMRDPCLOUDROLES ) and userid=:user )
PMZHBT_IMGNOSRV Filter Domain

Returns a list of all saved images that have no provisioned virtual server. Domain Name PMZHBT_IMGNOSRV Object TPILCLONEIMAGEENTRY Sample URL http://localhost:9080/maxrest/rest/os/ TPV02IMGLIBENTRYSAVE?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_IMGNOSRV SQL Query
ID in ( select DCM_OBJECT_ID from PROPERTIES p where KEY_NAME=TSAM_IMAGE_COLLECTIONID and not exists ( select ALNVALUE from PMZHBWTNSPEC where ASSETATTRID=PMRDPCLCVS_IDENTITY and p.value=ALNVALUE ) ) and ID in ( select DCM_OBJECT_ID from PROPERTIES where KEY_NAME=TSAM_IMAGE_USER and VALUE=:USER )
PMZHBT_SWMODULE Filter Domain

Returns software modules for registered images, software qualified to install. Domain Name PMZHBT_SWMODULE Object TPSOFTWAREMODULE Sample URL http://localhost:9080/maxrest/rest/os/ TPV02SOFTWAREMODULE?_lid=maxadmin&_lpwd=maxadmin&_fd= PMZHBT_SWMODULE SQL Query
ID IN ( SELECT DCM_OBJECT_ID FROM PROPERTIES WHERE (KEY_NAME = exposetotivsam OR KEY_NAME = swType) )
414
PMZHBT_ILMSTRIMG Filter Domain

Shows Image Library master images that are not composite images. Domain Name PMZHBT_ILMSTRIMG Object TPILMASTERIMAGEENTRY Sample URL http://localhost:9080/maxrest/rest/os/ TPV02IMGLIBENTRYMSTR?_lid=maxadmin&_lpwd=maxadmin &_fd=PMZHBT_ILMSTRIMG SQL Query
ID IN ( SELECT IL_MASTER_IMAGE_ENTRY_ID FROM IL_MASTER_IMAGE_ENTRY WHERE IL_MASTER_IMAGE_ENTRY_ID NOT IN ( SELECT PARENT_IL_ENTRY_ID FROM IL_COLLECTION_MEMBERSHIP ) AND IL_MASTER_IMAGE_ENTRY_ID NOT IN ( SELECT CHILD_IL_ENTRY_ID FROM IL_COLLECTION_MEMBERSHIP ) )
REST API troubleshooting

This section describes selected error situations within the REST APIs delivered with Tivoli Service Automation Manager and recommended procedures to resolve them.
Common omissions and user errors

This section lists the most common omissions and user error situations within the REST APIs delivered with Tivoli Service Automation Manager. v v v v v Parameters required for Maximo business object are missing. The field validations of an attribute fail because of invalid values. A relationship does not return the expected values. The user is not authorized to execute a particular request. The object structure does not exist.
v Site and organization values are missing. v The default site has not been customized for the user that wants to create an object. v The user does not have access to a particular site. v In many cases, the maxadmin rights are not enough to execute a REST request. v There are differences in the attributes of Maximo business objects, depending on the language installed.
415
Debugging REST requests with loggers

This section describes how to set the loggers that help diagnose problems concerning REST requests.
About this task

Modify the loggers with use of the Tivoli Process Automation engine logging application:
Procedure
1. Click Go To > System Configuration > Platform Configuration > Logging. 2. Modify the integration logger: a. Set the log level to DEBUG. b. Check the box to activate the logger. 3. Create the rest logger: a. Click New Row. b. In the Logger field, type rest. c. Set the log level to DEBUG. d. Check the box to activate the logger. 4. Optional: Modify the sql logger: a. Set the log level to DEBUG. b. Define the logger to debug the Maximo business object queried or modified during a REST request. c. Check the box to activate the logger. Note: The sql logger produces a lot of debug information in the WebSphere logs. Therefore it should be modified only for a specific Maximo business object, and not in general.
416
Chapter 8. Troubleshooting and error recovery

This section describes selected error situations and recommended procedures to resolve them.
Trace logging
Trace logs capture information about the operating environment when component software fails to operate as intended. v Tivoli Provisioning Manager To provide a consistent mechanism for locating serviceability information, Tivoli products and applications have implemented the Tivoli Common Directory. The Tivoli Common Directory represents a central location on systems running Tivoli software for storing serviceability-related files. The location of the message logs and trace logs for Tivoli Provisioning Manager follow the Tivoli Common Directory standard. To learn how to access the log files, see the Log locations topic in the Tivoli Provisioning Manager information center at http://publib.boulder.ibm.com/infocenter/tivihelp/v38r1/index.jsp. v Tivoli Service Automation Manager Post-configuration logs for Tivoli Service Automation Manager can be found in /opt/IBM/tsam/logs.
417
Common problems and solutions

This section shows you how solve typical problems that might arise with any installation of Tivoli Service Automation Manager.
Table 70. Problems and solutions for common problems Problem Windows 2008 R2 provisioning fails for non-English OS templates Potential solution Perform the following steps: 1. If the built-in "Administrator" user and "Administrators" group in non-English Windows image templates is localized, then rename them to English "Administrator" and "Administrators". (Languages affected: Russian, French, Italian, Spanish and other.) 2. Add the localized "Administrator" user and "Administrators " group to the template and make this localized user also part of the English Administrator group. 3. Copy the endpoint_keys file (in /home/tioadmin) from the management server to the C:/temp folder created on the template. 4. Add a new template parameter endpoint-keys-present and with value "true" in the discovered software stack of the image template: a. Click Go To > IT Infrastructure > Software Catalog > Software Stacks. b. Select the VMware template from the list, for example, MyVMwareTemplate and display its details. c. In the Template Parameters section, add a new parameter named endpoint-keys-present. d. In the Value field assign the value true. e. Click Save. Windows 2003 provisioning fails with error COPCOM123E (A shell command error occurred: Exit code=1, Error stream="", Output stream=). Build and version numbers missing on About screen in Xen environments. Provide a provisioning request with minimum 1 GB of RAM and edit the value of "bootTimeout" variable in the RP.CheckBootStatus workflow to 45 minutes. Clear your Web browser cache.
418
Table 70. Problems and solutions for common problems (continued) Problem The live refresh in the Cloud Properties application (Go To > Service Automation > Cloud Properties) does not function. Potential solution Only use the General Settings tab in the Cloud Properties application to display the properties already defined during installation. There are two ways to perform modifications: v exclusively through the Maximo System Properties application; v by modifying and saving them using the Cloud Properties application and then performing a live refresh using the Maximo System Properties application. Request New Service is grayed out when using self-service user interface in Simple Chinese. Enable self-service user interface by connecting to the database and running the following SQL command: update SYNONYMDOMAIN set VALUE = DESCRIPTION where domainid = ITEMSTATUS; When preparing a Windows image, the virtual machine returns the error The Recycle Bin on C:\ is corrupted. Do you want to empty the Recycle Bin for this drive? Do the following: 1. Add the line rd /s /q C:\$Recycle.bin at the end of the postInstallAfter.bat script placed in the c:/temp dir of the template. 2. Remove the script z99.cleanupTempSpace.bat file from c:/temp/postAfter.d directory. On Windows 7, do the following: 1. Right click Recycle Bin and then click Properties. 2. Select Don't move files to Recycle Bin. 3. Clear the Display delete confirmation Dialog check box. 4. Click Apply, then OK to save changes. Linux guest provisioning fails with a No Operating System error message. Do the following: v Verify that GRUB is the bootloader. v Make sure that GRUB is installed in the Master Boot Record (MBR) and not in the partitions. It is the most typical cause for the "no operating system" problem. You can use YaST to move the bootloader to the Master Boot Record: 1. Convert the template to a VM. 2. Boot the VM and use YaST to write the boot loader to the MBR. 3. Remove the SSH hot keys and udev rules (see template creation instructions for more details). 4. Shut down the image. 5. Convert the template.
419
Table 70. Problems and solutions for common problems (continued) Problem After the logon screen customization, if incorrect user name or password is provided, the logon page does not show the customization implemented with the user interface extensibility API. Potential solution For logon customization the error.jsp is not editable or customizable.
Application server is unresponsive, there are Increase the Java heap size for MXServer OutOfMemoryError exceptions in server logs. using Integrated Solutions Console: 1. Open Integrated Solutions Console. Default URL is https://hostname:9043/ ibm/console. 2. Navigate to Servers > Application Servers > MXServer > Java and Process Management > Process Definition > Java Virtual Machine. 3. Increase the Maximum Heap Size value. 4. Restart MXServer. 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 cannot be avoided because it is a result of a race condition. It 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.
Troubleshooting installation problems

This section describes how to recover from Tivoli Service Automation Manager installation problems.
Unable to log on to the administrative user interface after Tivoli Provisioning Manager installation
About this task
Error condition:
HTTP Error Code: 500 Error Message: JSPG0227E: Exception caught while translating /webclient/components/page.jsp: java.lang.reflect.InvocationTargetException
Background: Before the Tivoli Provisioning ManagerWeb components are installed, the deployment manager (DMgr) and node agent are installed and running as root. Due to the recommendation to log on after each step, the user will probably have done that after the base services installation, where WebSphere runs as root. During this login, some Java server pages (JSP) are compiled and placed into the directory
/opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/temp
After the Tivoli Provisioning Manager Web components are installed, WebSphere typically runs under tioadmin. Therefore, if this directory exists (because the user
420
logged in before), in some situations the owner of this directory is root and WebSphere can no longer access the directory. Resolution:
Procedure
1. Do the following on the management server after the Tivoli Provisioning Manager Web components have been installed:
cd /opt/IBM/WebSphere/AppServer/profiles/ctgAppSrv01/ chown -R tioadmin:tioadmin temp
2. Log on again.
Service Request Manager fix pack installation terminates with error

Error condition: Service Request Manager fix pack installation terminates with an error and logon to the administrative user interface is not possible.
About this task

Resolution:
Procedure
1. Log on to the database server as the Maximo DB2 instance user (default: ctginst1) 2. 2. Enter the following commands (each on a single line):
db2 db2 => connect to maxdb71 db2 => set schema=maximo db2 => select objectname from maxobject where siteorgtype not in (select value from synonymdomain where domainid = SITEORGTYPE)
This should result in a list of one or values, for example "PMSCMR". 3. For each value in the list: a. Enter
db2 => select SITEORGTYPE from maxobject where objectname = <VALUE>
b. Note the returned value, designated here as <SITEORG_VALUE> c. Enter

db2 => update maxobject set siteorgtype = (select value from synonymdomain where domainid = SITEORGTYPE and maxvalue = <SITEORG_VALUE>) where objectname = <VALUE>
421
Release Process Manager installation fails

The installation of Release Process Manager 7.1.2 fails during the operation of database update. Exception occurs when executing an SQL statement resulting in SQLCODE=-803, SQLSTATE=23505, DRIVER=3.59.81. Solution: Refer to the technote at
https://www.ibm.com/support/docview.wss?mynp=OCSS5HFZ&mync=R&uid=swg21432134&myns=swgtiv
OutOfMemoryError when installing automation packages

If you experience an OutOfMemoryError when performing the launchpad step Install the automation packages for Tivoli Service Automation Manager, you must increase the heap size for tc-driver-manager.
Procedure
1. Log on to the management server as user tioadmin. 2. Change to directory $TIO_HOME/tools. 3. Edit the file tc-driver-manager.sh and search for the following line:
$JAVA_HOME/bin/java -Xmx1024M
4. Increase the heap size to, for example, 2048M:

$JAVA_HOME/bin/java -Xmx2048M
5. Perform the step Install the automation packages for Tivoli Service Automation Manager again.
Troubleshooting upgrade and migration

This section describes how to recover from problems that occur when Tivoli Service Automation Manager is upgraded to a newer version or migrated.
Creating a project from a saved image fails

The Create Project from Saved Image request fails after upgrade or migration, when the network configuration changed. If a project was provisioned in Tivoli Service Automation Manager 7.2 level and is then migrated to Tivoli Service Automation Manager 7.2.x level with a modified network configuration (multi-NIC networking model), or if the image of this project was migrated, the project is no longer operational. Modifying server settings for network is not supported.
Upgrade fails with VMWare_MigrateDCM_7_3_0_0 workflow errors

When upgrading Tivoli Service Automation Manager 7.2.1 to 7.2.2 ensure that the migration workflow has completed successfully before running the VirtualCenter discovery.
Procedure
1. Check for errors in the execution of workflow VMWare_MigrateDCM_7_3_0_0. 2. Correct the errors and run the workflow again. 3. When the migration is finished with success, run the VirtualCenter discovery again.
422
Provisioning problems
This section describes how to recover from provisioning problems.
Cleaning up after a provisioning failure

Exceeding available resources can lead to major problems in the add server provisioning flow that need to be resolved manually.
Before you begin

You must be a maxadmin user or a member of the group.
Procedure
1. Log on to the administrative user interface. 2. Select the Process Management Requestor tab in the Start Center. You will see an inbox assignment 'A workflow failed' with a route workflow icon next to it. 3. Click on the inbox assignment to open the Topology Work Order application, which provides details and messages on the failed request. There are several tabs to assist you in analyzing the problem and performing corrective actions: v Requests tab - Requests and work orders with their status. v Parameters tab - Input and output parameters for the work order. v Messages tab - Messages that occurred during the processing of the work order. v Related Records tab - Related work orders and tickets. v Specifications tab - Attributes of the work order and their values. 4. Click on the Route workflow action and select to retry or ignore the current step and run the remaining steps of the management plan or to cancel the entire work order. 5. Click OK to continue processing.
Provisioning fails on System p

Error condition: While you are using Tivoli Provisioning Manager to carry out an LPAR virtual server deployment on System p, the Tivoli Provisioning Manager workflow fails. Resolution: The Tivoli Provisioning Manager log contains several entries regarding transition state 5 checking; the log also references the nim_ckstatus_lpar_name.sh file. Check this file.
Procedure
1. Run the following command from the Network Installation Manager (NIM) server to check the state: lsnim Z a Cstate_result a Cstate a Mstate a info lpar_name 2. Manually clean up all of the NIM objects that are related to the failed LPAR deployment. After you clean up the NIM objects, retry the operation. To clean up the NIM objects, run the following commands, in the specified order, from the NIM server: a. b. c. d. nim -Fo reset lpar_name nim -Fo deallocate -a subclass=all lpar_name nim -o remove lpar_name nim -o remove lpar_name_epp_bid
423
Virtual server on System p is not created

Error condition: When you create a System p LPAR virtual server and check the status of the create operation, the status check indicates that the server was not created.
About this task

The following Tivoli Provisioning Manager error is displayed:
COPDEX031E The system cannot evaluate a Jython expression. Jython error message: "Traceback (innermost last): File "", line 1, in ? AttributeError: None object has no attribute strip "
In addition, a Tivoli Provisioning Manager stack trace similar to the following is generated:
Check_LPAR_State(line:100, column:7) LPAR_On_Off(line:91, column:7) Deactivate_pSeries_LPAR(line:27, column:4) FindMacaddress(line:62, column:17) HMC_Create_Virtual_Server(line:218, column:1) pSeries_Create_Virtual_Server(line:82, column:1) HostPlatform.CreateVirtualServer(line:30, column:3) RDP_Provision_Virtual_Server(line:121, column:25)
Resolution: You must manually remove the LPAR virtual server. To manually remove the LPAR server, perform the following steps:
Procedure
1. In the search field in the upper left corner of the Tivoli Provisioning Manager user interface, enter RDP_Remove_Virtual_Server. 2. Run the workflow using the Tivoli Provisioning Manager ID of the LPAR server that you are removing. To locate the Tivoli Provisioning Manager ID of the server, type the LPAR name in the search box, and hover your mouse over the name to display the ID.
Provisioning fails with HWADDR line in /etc/sysconfig/ network-scripts/ifcfg-eth0

Error condition: Virtual machine deployment fails with HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth0. Resolution: A deployment of a virtual machine with the Red Hat Enterprise Linux operating system fails if there is a HWADDR entry in the VMware template.
Procedure
1. Manually edit the /etc/sysconfig/network-scripts/ifcfg-eth0 file and remove the HWADDR entry. To make this change, you must convert the VMware template back to a virtual machine. The contents of /etc/sysconfig/network-scripts/ifcfg-eth0 might look something like this:
DEVICE=eth0 BOOTPROTO=dhcp HWADDR=00:50:56:A8:3A:84 ONBOOT=yes TYPE=Ethernet DHCP_HOSTNAME=RH4-8G
2. Delete the HWADDR line and save the file.
424
3. Shut down the computer, and convert the virtual machine to a VMware template.
Provisioning a VMware project with increased memory size fails

Error condition: When using VMware VirtualCenter 2.5, provisioning a VMware project with memory size twice the size in the original template or more fails.
About this task

Tivoli Service Automation Manager sets the reservation during provisioning for all the virtual machines as requested in the self-service user interface. Memory reservation should not be set on the template. Verify whether the VMware template has a memory reservation set, and if it does, modify this setting:
Procedure
1. Select the template in VMware Virtual Infrastructure Client. 2. Convert it to a virtual machine. 3. Click Edit settings for this VM. 4. On the Edit Settings panel, click the Resources tab and select Memory. 5. Enter 0 for the reservation value or use the slider to change the current value to 0.
Provisioning VMware fails with timeout error

Error condition: Provisioning VMware projects fails occasionally with timeout errors.
Execute_Local_Command(line:28) RP$CheckBootStatus(line:55) RP$VMwareVirtualMachineInstall(line:123)
About this task

If during provisioning the VMware backend is heavily loaded or slow, the default timeout of 30 minutes might not be enough. To avoid such timeout errors, set the global variable Cloud.BOOT_TIMEOUT with a suitable value must be set.
Procedure
1. In the administrative user interface click Go To > Administration > Provisionig > Provisioning Global Settings 2. In the Variables tab, click New Row, and specify the following values: Variable: Cloud.BOOT_TIMEOUT Value: Specify, in milliseconds, a value greater than 30 minutes, for example 2 hours, that is 7200000. 3. Click Save.
425
Provisioning fails when using Xen image

When you provision the servers using the registered image of Xen, the provisioning fails. The problem occurs because the default values of some image variables get overwritten when you register the image in the Image Library. After registering the image, you need to use the Tivoli Service Automation Manager administrative interface to change the values for recCpu and minCpu manually.
About this task

To manually change the values, so that the image can be used for provisioning:
Procedure
1. Log in to the administrative interface at https:/host_name/:9443/maximo 2. Select Go to > IT Infrastructure > Software Catalog > Software Stacks 3. Click the name of the image that you registered in Tivoli Service Automation Manager. 4. In the Installable Files section, click the arrow on the left side to view the details of the image. 5. In the expanded section, click the Variables tab. 6. Use the arrow next to the minCpu variable to edit it. 7. Set the value to 1.0. 8. Repeat the same steps for the recCpu variable. 9. Click the Save Software Stack button at the top of the page to save the changes.
Results
You can now provision the servers using this image.
Provisioning fails because of wrong configuration of default gateways

Error condition: Provisioning fails because of wrong configuration of default gateways.
About this task

When configuring the default gateways for your subnets, remember not to define more than one default gateway for the subnets that NICs belong to. For example, if the PMRDP.Net.DefaultRoute.Destination variable is not set, the value set for PMRDP.Net.Gateway is considered as default gateway. Having the PMRDP.Net.Gateway variable set in all available subnetworks leads to provisioning failure since there is no static route defined and all gateways are treated as default gateways.
426
Available resources are not listed properly

If the available resources are not listed properly (for example, because additional disks were added, servers were added or removed from outside of the TPAe system, the list of free IP addresses has been changed), you can update that list by running the Hardware Management Console (HMC) discovery.
About this task

To run the discovery:
Procedure
1. Log on to the administrative interface. 2. Click Go To > Discovery > Provisioning Discovery > Discovery Configurations. 3. Search for Cloud_p5_Discovery. 4. In the Central Electronics Complex (CEC) field type in the name of the CEC that you want to scan, or leave that field empty to scan through all CECs. 5. Click Run Discovery. 6. Click Submit.
Modifying disk size fails on Red Hat Enterprise Linux server

If you are unable to modify disk size on a virtual server with Red Hat Enterprise Linux, ensure that you have the required version of the resize2fs installed.
About this task

For Red Hat Enterprise Linux VMware templates, the resize2fs executable file version 1.39 or higher must be installed to use the disk resize functionality. This level check is performed by the Cloud_Linux_Online_Configure_Disks workflow. If the provisioned server has resize2fs version 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), modifying disk size will not be possible on that server.
Resources not updated when creating a project

If projects are being created by multiple users, or multiple projects are being scheduled by the same user, the resources are not updated for projects that are in the queued or new status. This may allow a user to create projects for which there are not enough resources.
About this task

This behavior is due to a delay between the time in which TPAe layer processes the request and when the actual layer responsible for interfacing the hypervisor gets notified.
427
Resource pool is not available

A resource pool configured in the administrative user interface is not available in the self-service user interface.
About this task

Verify the following settings in the administrative interface:: 1. Ensure that the Admin Mode is disabled: a. Click Go To > System Configuration > Platform Configuration > Database Configuration. b. In the Select Action menu, click Manage Admin Mode. The Admin Mode should be disabled. 2. Click Go To > Integration > Web Services, and ensure that PMRDPBCAPI Web Service is deployed. 3. Verify that the PMRDPRBC End Point is configured correctly: a. Click Go To > Integration > End Points. b. Ensure that the PMRDPRBC End Point has the host name of the management server. c. Ensure that the user name and password are the same as for the MAXADMIN user. Note: You may need to update the password on PMRDPRBC End Point if you have switched to Active Directory authentication.
Setting automatic logon for Windows

During the provisioning of Windows templates, Tivoli Service Automation Manager starts the system preparation tool (sysprep) on the deployed Windows virtual machines in order to customize them. The automatic logon (autologon) count is also set then. You can control the autologon count by assigning appropriate values to these two global properties: PMRDP.VMware.Windows.AutoLogOnCount This global property is used during provisioning. Set the value to 1 or higher. 1 is the default value. PMRDP.VMware.Windows.ResizeAutoLogOnCount This global property is used during disk resize. Set the value to 1 or higher. 1 is the default value.
Setting a specific timezone on a Windows endpoint

To set a specific timezone on a Windows endpoint, add a template parameter timezone with a numeric value in the default Service Request Tool (SRT) on the Windows template software stack object in Data Center Model. The following table presents the example values:
Table 71. Timezones and their numeric values Index 000 001 Zone Int'l Dateline Samoa Index 090 095 Zone GMT Greenwich Central Europe Index 200 201 Zone Sri Lanka N. Central Asia
428
Table 71. Timezones and their numeric values (continued) Index 002 003 004 010 015 020 025 030 033 035 040 045 050 055 056 060 065 070 073 075 080 083 085 Zone Hawaii Alaskan Pacific Mountain (U.S. and Canada) U.S. Mountain: Arizona Central (U.S. and Canada) Canada Central Mexico Central America Eastern (U.S. and Canada) U.S. Eastern: Indiana (East) S.A. Pacific Index 100 105 110 113 115 120 125 130 135 140 145 150 Zone Index Zone Myanmar: Rangoon S.E. Asia N. Asia China Singapore Taipei W. Australia N. Asia East Korea: Seoul Tokyo Sakha Yakutsk A.U.S. Central: Darwin Central Australia A.U.S. Eastern E. Australia Tasmania Vladivostok W. Pacific Central Pacific Fiji New Zealand Tonga
Central European 203 Romance W. Europe W. Central Africa E. Europe Egypt EET (Helsinki, Riga, Tallinn) EET (Athens, Istanbul, Minsk) Israel: Jerusalem S. Africa: Harare, Pretoria Russian Arab E. Africa Iran Arabian 205 207 210 215 220 225 227 230 235 240 245 250 255 260
Atlantic (Canada) 155 S.A. Western Pacific S.A. Newfoundland E. South America S.A. Eastern Greenland Mid-Atlantic Azores Cape Verde Islands GMT (Greenwich Mean Time) 160 165 170 175 180 185 190 193 195
Caucasus Pacific 265 (U.S. and Canada) Afghanistan Russia Yekaterinburg W. Asia India Nepal Central Asia 270 275 280 285 290 300
429
Cleaning up after unexpected stoppage of the Provisioning Manager engines

When the Tivoli Provisioning Manager engine stops unexpectedly while the provisioning workflows are is in progress, manual clean-up steps must be performed before the engine is restarted.
Procedure
1. Stop Tivoli Provisioning Manager and WebSphere Application Server. 2. Run the clean-up-deployment-requests script:
# su - tioadmin # $TIO_HOME/tools/clean-up-deployment-requests.sh # exit
3. Start Tivoli Provisioning Manager and WebSphere Application Server.
Manually changing the status of a service request

You may need to change the request state manually, for example, when the request is "in progress", or if you need to omit the approval stage.
About this task

To manually change the state of a service request:
Procedure
1. Log on to the administrative interface. 2. Click Go To > Service Desk > Service Requests. 3. Select the request that you want to change. You can filter them by status or name to facilitate browsing. 4. From the Select Action menu, select Change Status. 5. Select the new status from the list. 6. Click OK.
Troubleshooting when using IBM Systems Director VMControl

This section describes how to troubleshoot errors in an environment where POWER LPAR machines are provisioned via VMControl.
Creating an image template for VMControl fails

In order to successfully provision an image using Tivoli Service Automation Manager and IBM Systems Director VMControl, the OVF of the image must not contain the hostname property. Its presence causes image deployment to fail.
About this task

To recover from this error:
Procedure
1. Update the appropriate OVF through some editor and remove the hostname property. 2. Launch the Systems Director user interface.
430
3. On the Welcome screen, select the Manage tab, and then, VMControl Enterprise Edition from the list. 4. Click the Basics tab. 5. In the Common Tasks section, click Discover virtual appliances.
Deployment of more than 10 servers fails

When you request deployment of more than 10 servers at the same time, provisioning fails for some of the requests.
About this task

The problem may be caused by the incorrect value for the Cloud.HOST_TRANSACTION_NUMBER_LIMIT parameter. The recommended value for this parameter is 5. If you have already imported the XML file with the incorrect value, perform the following steps:
Procedure
1. In the administrative interface, click Go To > Service Automation > Cloud Properties. 2. Open the Provisioning Global Settings tab. 3. Search for Cloud.HOST_TRANSACTION_NUMBER_LIMIT variable, and change its value to 5. 4. Click Save.
Removing hardware resources via VMControl

If you are planning to remove a hardware machine or reduce its hardware resources via IBM Systems Director VMControl, you need to perform some steps in Tivoli Service Automation Manager, and then synchronize the changes.
Procedure
1. Log on to the administrative user interface. 2. Click Go To > IT Infrastructure > Provisioning Inventory > Virtualization Management 3. Search for all virtual servers deployed on the hardware resource that is to be removed. v If the virtual servers can be moved to another machine then migrate them. v If the virtual servers cannot be migrated: a. Log on to the self-service user interface. b. Select Manage Servers from My Projects window. c. Select the servers and click Remove. Wait until the virtual servers are deleted from the hypervisor. 4. Using VMControl, remove the required hardware resource. 5. Synchronize the hardware information in Tivoli Service Automation Manager DCM: a. Click Go To > Service Automation > Cloud Pool Administration. b. Select the VMControl cloud pool. c. In the VMControl Inventory Discovery section, select the hypervisor manager (the computer where VMControl is installed). d. Click VMControl Inventory Discovery.
431
Results
Hardware information is updated in Tivoli Service Automation Manager.
Recovering after unexpected hardware removal or failure

In case of unpredictable resource failure or if hardware was removed outside IBM Systems Director VMControl, you need to manually clean up the environment and synchronize the information in VMControl and Tivoli Service Automation Manager.
About this task

When a hardware resource is removed unexpectedly: v IBM Systems Director puts the managed endpoint (MEP) into the not available state v VMControl puts any associated workload into the not available state v Tivoli Provisioning Manager marks the state of the virtual server as not available
Procedure
1. Perform manual steps to remove the unavailable MEP from IBM Systems Director. When the Director database is updated, the deletion will cascade through VMControl and Tivoli Provisioning Manager as they run discovery. 2. Verify if the servers are present in DCM. v If the server is present: a. In the administrative user interface, destroy the server manually. b. In the self-service user interface, remove the server from the project. v If the server is not present: In the self-service interface, remove the server from the project.
Removing an orphan virtual server

If IBM Systems Director VMControl shows an orphan virtual server and this server is not associated with any project in Tivoli Service Automation Manager, you need to remove that server manually, and synchronize the changes. In VMControl, such servers are called unencapsulated servers and they are not removed automatically.
About this task

To remove the orphan server that is listed in VMControl:
Procedure
1. In VMControl, remove the virtual server along with associated storage. 2. Synchronize the changes with the Tivoli Provisioning Manager data model: a. Click Go To > Service Automation > Cloud Pool Administration. b. Select the VMControl cloud pool. c. In the VMControl Inventory Discovery section, select the hypervisor manager (the computer where VMControl is installed). d. Click VMControl Inventory Discovery.
432
Server cannot be removed in the self-service interface

When a recovery is performed in VMControl, servers may be assigned new OIDs, that will be different from the OIDs stored in Tivoli Service Automation Manager. The server must be removed from both applications, and the changes synchronized.
About this task

If a server is present in Tivoli Service Automation Manager and in VMControl, but it cannot be removed in the self-service user interface:
Procedure
1. Perform the steps to remove the server in VMControl, and synchronize the changes, as described in the task above (Removing an orphan virtual server on page 432). 2. Log on to the self-service user interface and, in the My Projects section, click Manage Servers. 3. Select the server, and click Remove Server.
Troubleshooting when using VMware

Learn about the common problems and limitations when using VMware. Problem: It is impossible to run discovery due to SSH handshake error. Resolution: Import the virtual center certificate on the management server. Problem: VirtualCenter discovery fails when active host or cluster is moved from one VirtualCenter to another, or when an active host is moved from one cluster to another cluster in the same VirtualCenter. Resolution: The host or cluster must not be moved or renamed during the configuration process or while they are used by Tivoli Service Automation Manager. Problem: Credentials for the VirtualCenter user have changed in VMware. Resolution: Update the credentials in VirtualCenter DCM object in the administrative user interface. Limitation: 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. For example, the following structures inside a Virtual Center are not supported: --DataCenter | --Folder | --Cluster
-- Folder |
433
-- DataCenter | -- Cluster
CDSException messages issued for inactive CDS application

Error condition: Tivoli Provisioning Manager repeatedly issues the 'CDSException' message 'DCD Management Center is not alive' if the CDS application is not running. This application is not required for Tivoli Service Automation Manager.
About this task

Resolution: Set the Tivoli Provisioning Manager global parameter SDI.Comp.Status.Check to 'false' (see the Tivoli Provisioning Manager documentation for details):
Procedure
1. In the Tivoli Provisioning Manager user interface, Go To > Administration >Provisioning > Provisioning Global Settings 2. Select the Variables tab. 3. Click on New Row. 4. Enter SDI.Comp.Status.Check as the variable name and 'false' as the value (without quotes). 5. Save the changes.
Configuring extensibility for Workload Deployer fails

Workload Deployer discovery fails with an error. When you run Workload Deployer discovery from Go To > Discovery > Provisioning Discovery > Discovery Configurations it fails with the following error (it can be found in Start Center > Provisioning Workflow Status):
Error Code: COPDEX040EunexpectedDeploymentEngineError Error Detail: WebSphere_CloudBurst_Appliance_Pattern_Discovery(line:43, column:10) WebSphere_CloudBurst_Appliance_Discovery(line:25, column:1) Discovery.OnDevice(line:33, column:3) com.ibm.tivoli.orchestrator.de.engine.InvokeJavaException: COPDEX040E An unexpected deployment engine exception occurred: imagelibrary#UnableToRetrieveWCAResource. at com.ibm.tivoli.orchestrator.de.instruction.impl.InvokeJavaHelper.evaluate(InvokeJavaHelper.java:111) at com.ibm.tivoli.orchestrator.de.instruction.impl.INVOKE_JAVA.execute(INVOKE_JAVA.java:106) at com.ibm.tivoli.orchestrator.de.instruction.impl.AbstractInstructionExecutor.execute(AbstractInstructionExecutor.java:90) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.executeWorkflow(DeploymentWorker.java:392) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.executeWorkflow(DeploymentWorker.java:279) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.execute(DeploymentWorker.java:560) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.run(DeploymentWorker.java:522) Caused by: com.ibm.tivoli.imagelibrary.ImageLibraryException: imagelibrary#UnableToRetrieveWCAResource at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:237) at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:119) at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveJSONArray(WCAConnection.java:102) at com.ibm.tivoli.imagelibrary.repository.wca.WCARepository.synchronizeImages(WCARepository.java:163) at com.ibm.tivoli.imagelibrary.helper.ImageLibraryHelper.synchronizeRepository(ImageLibraryHelper.java:1150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at com.ibm.tivoli.tpm.common.reflect.ReflectionHelper.evaluate(ReflectionHelper.java:158) at com.ibm.tivoli.tpm.common.reflect.ReflectionHelper.evaluate(ReflectionHelper.java:126) at com.ibm.tivoli.orchestrator.de.instruction.impl.InvokeJavaHelper.evaluate(InvokeJavaHelper.java:81) ... 6 more Caused by: java.lang.NullPointerException
434
at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:223) ... 17 moreWorkflow line: 43 com.ibm.tivoli.orchestrator.de.engine.InvokeJavaException: COPDEX040E An unexpected deployment engine exception occurred: imagelibrary#UnableToRetrieveWCAResource. at com.ibm.tivoli.orchestrator.de.instruction.impl.InvokeJavaHelper.evaluate(InvokeJavaHelper.java:111) at com.ibm.tivoli.orchestrator.de.instruction.impl.INVOKE_JAVA.execute(INVOKE_JAVA.java:106) at com.ibm.tivoli.orchestrator.de.instruction.impl.AbstractInstructionExecutor.execute(AbstractInstructionExecutor.java:90) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.executeWorkflow(DeploymentWorker.java:392) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.executeWorkflow(DeploymentWorker.java:279) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.execute(DeploymentWorker.java:560) at com.ibm.tivoli.orchestrator.de.engine.DeploymentWorker.run(DeploymentWorker.java:522) Caused by: com.ibm.tivoli.imagelibrary.ImageLibraryException: imagelibrary#UnableToRetrieveWCAResource at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:237) at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:119) at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveJSONArray(WCAConnection.java:102) at com.ibm.tivoli.imagelibrary.repository.wca.WCARepository.synchronizeImages(WCARepository.java:163) at com.ibm.tivoli.imagelibrary.helper.ImageLibraryHelper.synchronizeRepository(ImageLibraryHelper.java:1150) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) at com.ibm.tivoli.tpm.common.reflect.ReflectionHelper.evaluate(ReflectionHelper.java:158) at com.ibm.tivoli.tpm.common.reflect.ReflectionHelper.evaluate(ReflectionHelper.java:126) at com.ibm.tivoli.orchestrator.de.instruction.impl.InvokeJavaHelper.evaluate(InvokeJavaHelper.java:81) ... 6 more Caused by: java.lang.NullPointerException at com.ibm.tivoli.imagelibrary.wca.WCAConnection.retrieveString(WCAConnection.java:223) ... 17 more
Solution: Check the Workload Deployer version: if you are using Tivoli Service Automation Manager 7.2.0, only WebSphere CloudBurst Appliance version is 1.0 is supported
Passwords expired for administrative users when using global password policy
Error condition: If a global password policy is specified, the passwords for users maxadmin, maxreg, mxintadm, and wasadmin may expire at some time, which makes the system unusable. Solution: If you specify a global password policy, ensure that you exclude the users maxadmin, maxreg, mxintadm, and wasadmin from this policy so that the passwords for these users do not expire. For more information see Defining global password policy on page 294.
435
436
Appendix. Accessibility features

Accessibility features help a user who has a physical disability, such as restricted mobility or limited vision, to use software products successfully. The major accessibility features of Tivoli Service Automation Manager are described in this topic.
Accessibility features
User documentation provided in HTML and PDF format. Descriptive text is provided for all documentation images. The IT Service Management Information Center, and its related publications, are accessibility-enabled.
Related accessibility information

You can view the publications for Tivoli Service Automation Manager in Adobe Portable Document Format (PDF) using the Adobe Reader. PDF versions of the documentation are available in the information center.
IBM and accessibility

See the IBM Human Ability and Accessibility Center for more information about the commitment that IBM has to accessibility.
437
438
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.
439
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurements may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. If you are viewing this information softcopy, the photographs and color illustrations may not appear.
440
Glossary
This glossary includes terms and definitions for Tivoli Service Automation Manager. The following cross-references are used in this glossary: v See refers you from a term to a preferred synonym, or from an acronym or abbreviation to the defined full form. v See also refers you to a related or contrasting term. To view glossaries for other IBM products, go to www.ibm.com/software/globalization/ terminology. user ID and password are credentials that allow access to network and system resources.
E
escalation A course of action that runs when a task is not completed satisfactorily within a specific period of time.
H A
administrative system The hardware component of Tivoli Service Automation Manager from which software is installed on the management server and other administrative actions are taken. agent A process that performs an action on behalf of a user or other program without user intervention or on a regular schedule, and reports the results back to the user or program. hypervisor A program or a portion of Licensed Internal Code that allows multiple instances of operating systems to run simultaneously on the same hardware.
J
job plan A detailed description of work to be performed for a work order. A job plan typically includes required tasks and lists of estimated labor, materials, services, and tools needed to complete the work. job task An individual step in a job plan. Each job task triggers a specific workflow appropriate to that task.
application One or more computer programs or software components that provide a function in direct support of a specific business process or processes.
C
cardinality The number of elements in a set. configuration item Any component of an information technology infrastructure that is under the control of configuration management. credential Information acquired during authentication that describes a user, group associations, or other security-related identity attributes, and that is used to perform services such as authorization, auditing, or delegation. For example, a
M
managed environment An environment where services, such as transaction demarcation, security, and connections to Enterprise Information Systems (EISs), are managed on behalf of the running application. Examples of managed environments are the Web and Enterprise JavaBeans (EJB) containers. managed node A node that is federated to a deployment manager and contains a node agent and can contain managed servers.
441
management plan A set of tasks that modify a service deployment instance. management server The hardware component of Tivoli Service Automation Manager on which the product and its prerequisite middleware reside. Maximo business object A standardized data entity within Maximo. MBO See Maximo business object.
service topology In the context of a service definition, the set of physical IT components (such as hardware and software) that are available for inclusion in services based on that definition. On instantiation, the service topology is the actual set of these components in operation on behalf of the service deployment instance. service topology node In the context of a service definition, one element of the service topology to which resources can be allocated based on that definition. On instantiation, the service topology is the actual set of these components in operation on behalf of the service deployment instance. software definition The deployment configuration that describes how to install one or more installable software dependencies. It includes a list of installable files, software prerequisites, and advanced attributes. subnet See subnetwork. subnetwork A network that is divided into smaller independent subgroups, which still are interconnected.
middleware Software that acts as an intermediate layer between applications or between client and server. It is used most often to support complex, distributed applications in heterogeneous environments.
P
platform The combination of an operating system and hardware that makes up the operating environment in which a program runs. portlet A reusable component that is part of a Web application that provides specific information or services to be presented in the context of a portal.
T
TEMS See Tivoli Enterprise Monitoring Server. TEPS See Tivoli Enterprise Portal Server.
R
reservation The preallocation of configuration items for future deployments.
S
server image A file that contains the content and state of a virtual server, which can be saved and restored. service definition A set of data that provides the framework for deploying an IT landscape. service deployment instance An actual IT landscape derived from deploying a service definition.
Tivoli Enterprise Monitoring Server The monitoring server is the collection and control point for the performance and availability data and alerts received from monitoring agents. This server also manages the connection status of the agents and is responsible for tracking the online or offline status of the agents. Tivoli Enterprise Portal Server A Tivoli Monitoring server that provides the core presentation layer for retrieval, manipulation, analysis, and pre-formatting of data. The portal server receives data from the hub monitoring server in response to user actions at the portal client, and sends the data back to the portal client for presentation.
442
V
virtual server A server that shares its resources with other servers to support applications. VMware A commercially available, proprietary virtualization environment for System x and similar platforms.
W
WO See work order. workflow 1. The sequence of activities performed in accordance with the business processes of an enterprise. 2. The structured sequence of activities and tasks that are used to implement a specific change, release, or other process, including automatic routing and tracking of records for approval and other tasks. work order A record that contains information about work that must be performed for an asset, location, configuration item (CI), and so on.
X
Xen A open-source virtualization environment for System x and similar platforms.
Glossary
443
444
Trademarks and Service Marks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol ( 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. Other company, product, and service names may be trademarks or service marks of others.
445
446
Index A
accessibility features 437 account code 247 Admin Mode managing 306 administering Tivoli Service Automation Manager 243 administrative server AIX 62 Linux on System x 62 preparation for Tivoli Service Automation Manager installation 61 Windows 61 administrative user interface applications 3 applications Co-Location Editor 7 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 7 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 7 Service Topology Node Operation 7 Situation Analysis 5 Topology Customization 7 approval delegation disabling 286 enabling 286 disabling 286 enabling 286 configuration (continued) network artifacts 248 network segment usage values 197, 198, 199 network template 199, 201 overview 107 provisioning 215 purging 204, 205, 206 restore 269 SAN storage 195, 196 storage pool 203 storage resources 203, 207 configuring Tivoli Provisioning Manager DCM for WebSphere Cluster Service 211 CSR enabling generation 228 CSR files defining directory location 228 customer activating 208 administering 277 assigning resources 278 creating template 280 defining limits 282 defining quotas 282 initial setup 207 migrating 97 returning resources 280 upgrading 97 customer support contact xvii customer template creating 280
H
hardware requirements 29 administrative system 31 management system 30 System z environment 38
I
IBM Software Support submitting a problem xviii IBM Support Assistant xvi image removing 268 installation 84 additional configuration files 80 automation packages 81 Base Services 69 default values and settings 65 middleware 67 overview 26 preparing for 39 SRM 72 Tivoli Provisioning Manager core 70 Tivoli Service Automation Manager 25, 63 Tivoli Service Automation Manager Base component 79 Tivoli Service Automation Manager license 67 Tivoli Service Automation Manager WAS 82 web components 71 Installation Launchpad overview 2 integrating Tivoli Service Automation Manager with other Tivoli products 216 integration CCMDB 234, 236, 237, 238, 239, 240, 241, 242 Tivoli Monitoring 216, 217, 218, 222, 224 Tivoli Usage and Accounting Manager 226, 227, 228, 229, 230, 231 Internet, search for problem resolution xv Internet, searching for problem resolution xvi
D
DCM for Tivoli Provisioning Manager, configure to enable WebSphere Cluster service 211 delegation of approval disabling 286 enabling 286 Discovery, configuring 213
E
education see Tivoli technical training xv
C
cloud server pool 159 communication templates 283 managing 285 components overview 2 configuration 159 cloud server pool 158 DCM objects 197 network 196 Copyright IBM Corp. 2008, 2011
F
fixes, obtaining xvi
K
knowledge bases, searching xv KVM image server setup 152 KVM setup KVM server setup 152
G
glossary 441
447
L
limit activating 283 deactivating 283 defining 282
quota (continued) defining 282
R
ras 322 reporting overview 19 Reporting function configuring 214 reports 256, 304 Tivoli Service Automation Manager 243 authorizing users 245 configuring 244 generating 246 generating request pages 244 scheduling 246 table auditing 244 viewing 246 types 19 usage and accounting 247 generating 248 resources assigning to all customers 279 assigning to customer 278 defining limits 282 defining quotas 282 returning 280 restrictions 43
M
managed environment WebSphere Cluster service 211 management plans 12 management server AIX 44, 46, 51 Linux 54, 56, 60 starting 289 stopping 290 middleware controlling with a script 291 starting 289 stopping 289, 290 middleware requirements base services requirements 36 components 36 Tivoli Monitoring 36 Tivoli Provisioning Manager 35 Tivoli Remote Execution and Access 36 Monitoring function configuring 222
software products adding 287 configuring 287 software requirements Service Request Manager 36 Software Support contact xvii describing problem for IBM Software Support xviii determining business impact for IBM Software Support xviii SSH command end point for Tivoli Monitoring information 224 support information xv System z requirements 38
T
Tivoli Provisioning Manager running Discovery 213 Tivoli Provisioning Manager Discovery 213 Tivoli Service Automation Manager components 2 installing 25 RXA setup for Tivoli Usage and Accounting Manager interface 227 Tivoli Service Automation Manager events for monitoring, setting up 222 Tivoli Service Automation Manager security, setting up 270 Tivoli technical training xv Tivoli Usage and Accounting Manager enabling table auditing 228 RXA setup for Tivoli Service Automation Manager interface 227 topology WebSphere 10 topology node attributes 13 training, Tivoli technical xv troubleshooting 322, 417
N
notifications managing 285
S
security 270 CCMDB 270 person groups 270 roles 270 security groups 270 self-service user interface 273 Self-Service Virtual Server Management 270 security groups 274 migrating 98 upgrading 98 self-service user interface communication templates 283 security 273 settings 283 Self-Service Virtual Server Management overview 2 requirements 37 Tivoli Provisioning Manager integration 3 server image management overview 22 service provider configuring 207 service structure 17 services Self-Service Virtual Server Management 2 WebSphere Cluster Service 9 software modules adding 287 configuring 287
O
operating system requirements administrative system 31 management system 30 System z environment 38 29
P
performance monitoring 15, 222 Performance Monitoring function configuring 222 PMRDPCUST activating 208 post-installation steps 83 problem determination describing problem for IBM Software Support xviii determining business impact for IBM Software Support xviii submitting a problem to IBM Software xviii project account 247
U
usage and accounting function configuring 226 configuring server to process CSR 229 configuring Tivoli Service Automation Manager 227 generating reports 248 overview 20 user access managing 270 user interface 3 user roles See security groups users migrating 98 upgrading 98
Q
quota activating 283 deactivating 283
V
verify the installation verifying 84 84
448
VMControl error recovery 430 hardware failure 432 orphan servers removing 432 removing hardware 431
W
WebSphere 10 WebSphere Cluster service configuring managed environment 211 Workload Deployer configuring 209 overview 23
Index
449
450
Product Number: 5724-W78
Printed in USA
SC34-2657-00

Tsam Admin Book

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tsam Admin Book

Transféré par

Droits d'auteur :

Formats disponibles

Tivoli Service Automation Manager

Installation and Administration Guide

Tivoli Service Automation Manager

Installation and Administration Guide

Chapter 2. Installing Tivoli Service Automation Manager. . . . . . . . . 25

Chapter 1. Tivoli Service Automation Manager overview . . . . . . . . . . 1

. 99 . 100 . 100 . 101 . . . . . 102 102 103 103 104

Chapter 4. Configuring Tivoli Service Automation Manager . . . . . . . . 107

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

194 195 195 196 196 197 197

218 221 222

224 224 226 226

227 228 228 228 229

Chapter 5. Administering Tivoli Service Automation Manager. . . . . 243

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Freeing resources locked to deprecated or inconsistent projects . . . . . . . .

Chapter 7. REST API reference . . . . 327

Chapter 6. Reliability, availability, and serviceability functions . . . . . . . 307

Appendix. Accessibility features . . . 437 Notices . . . . . . . . . . . . . . 439 Glossary . . . . . . . . . . . . . 441

Chapter 8. Troubleshooting and error recovery . . . . . . . . . . . . . 417

. 420 . 421 . 422

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

442 442 443 443 443

Trademarks and Service Marks . . . . 445 Index . . . . . . . . . . . . . . . 447

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

29. 30. 31.

Copyright IBM Corp. 2008, 2011

66. 67. 68.

for . . for . . for . .

69. . . . . . . . . . . . . . 375 . 376 . 377 70. 71.

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Who should read this information

What's new in this release

IBM Tivoli Directory Server, version 6.3

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Documentation URL http://publib.boulder.ibm.com/infocenter/ db2luw/v9r5/topic/com.ibm.db2.luw.doc/ welcome.html http://publib.boulder.ibm.com/infocenter/ wasinfo/v6r1/topic/ com.ibm.websphere.base.doc/info/aes/ae/ welcome_base61.html

IBM WebSphere Application Server Network Deployment, version 6.1

Getting technical training

Searching knowledge bases

Searching the Internet

Using IBM Support Assistant

Finding product fixes

About this task

Getting email notification of product fixes

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Contacting IBM Software Support

About this task

Setting up a software maintenance contract

Determine the business impact

Severity 2 Severity 3 Severity 4

Describe the problem and gather background information

Submit the problem to IBM Software Support

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Chapter 1. Tivoli Service Automation Manager overview

Copyright IBM Corp. 2008, 2011

Tivoli Service Automation Manager Installation Launchpad

Self-Service Virtual Server Management

Tivoli Service Automation Manager V7.2.2 Installation and Administration Guide

Applications in the administrative user interface

Chapter 1. Product overview

Service Definitions application

Service Deployment Instances application

Resource Allocation applications