System Director Sg248141

Front cover
IBM Systems Director 6.3

Best Practices
Provides additional guidance beyond
standard instructions
Covers basic and advanced
features
Learn from the experts in the
field
Rufus Credle
Srikanth Aithal
Nicolas Bour
Stephane Bourdeaud
Tomi Mannikainen
Olaf Menke
Juan P Fernandez Sabate
ibm.com/redbooks
International Technical Support Organization

IBM Systems Director 6.3 Best Practices
November 2013
SG24-8141-00
Note: Before using this information and the product it supports, read the information in Notices on
page ix.
First Edition (November 2013)

This edition applies to IBM Systems Director V6.3 Express, Standard, and Enterprise Edition.
Copyright International Business Machines Corporation 2013. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Chapter 1. Positioning IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Description of IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Functionality of IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Positioning of IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 IBM Systems Director and IBM Flex Systems Manager . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2
3
4
5
Chapter 2. Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 System resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 IBM Systems Workload Estimator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Best Practice for planning endpoint management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Firewall ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6 IBM Systems Director Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Architectural decisions and recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7.1 Determine which agent to use to manage your systems . . . . . . . . . . . . . . . . . . . 26
2.7.2 Determine how to deploy your agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.3 Determine if you should run Systems Director server in a virtual machine. . . . . . 30
2.7.4 Determine what type of database to use with Systems Director server . . . . . . . . 31
2.7.5 Determine the networks that your server should be connected to . . . . . . . . . . . . 31
2.7.6 Determine how to make your solution highly available . . . . . . . . . . . . . . . . . . . . . 32
2.7.7 Determine how to deal with distributed environments. . . . . . . . . . . . . . . . . . . . . . 32
2.8 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 3. Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Installation of IBM Systems Director server on an x86 platform . . . . . . . . . . . . . . . . . .
3.1.1 Supported operating systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Installation of Linux on x86 systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Installation on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.4 Post Installation Validation tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.5 Starting IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Installing IBM Systems Director server on an AIX platform. . . . . . . . . . . . . . . . . . . . . .
3.2.1 Downloading the software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 DB2 settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 Initial login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.6 Installing the IBM Systems Director license . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Installation of IBM Systems Director server for a Linux on Power platform . . . . . . . . .
3.3.1 Downloading the software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Copyright IBM Corp. 2013. All rights reserved.
35
36
36
38
44
52
55
57
57
58
60
62
65
67
68
68
iii
3.3.2 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Installing the IBM Systems Director server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Installation of the IBM Systems Director agent on Linux x86 . . . . . . . . . . . . . . . . . . . .
3.5 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
71
73
76
Chapter 4. Basic management tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.1 Discovery profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.2 BladeCenter discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.1.3 Best practices for discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.1 Inventory data and collection profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.2.2 Collecting inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.3 Viewing inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.4 Exporting inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.2.5 Best practices for inventory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.3 Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3.2 What can be updated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.3.3 Settings for Update Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.3.4 Update Manager with Internet connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.3.5 Update Manager with no Internet connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.3.6 Compliance check. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.7 Update process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.3.8 Updating systems that run AIX and Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.3.9 Updating the Systems Director server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.3.10 Downloading and staging updates manually. . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.3.11 Command-line tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.3.12 Best practices for Update Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.4 Event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.4.1 Light path diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.4.2 Hardware logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.4.3 Event logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.4.4 Automation Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.4.5 Best practice for event management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
4.5 Hardware Management Console and AIX Launch-in-Context . . . . . . . . . . . . . . . . . . 194
4.5.1 Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.5.2 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
4.5.3 Best practices for HMC management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
4.6.1 Users and groups for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
4.6.2 Authorizing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
4.6.3 Access managed systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.6.4 Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
4.6.5 Lightweight Directory Access Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
4.6.6 Using command-line tools for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
4.6.7 Best practices for security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.7 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.7.1 Backup Q&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
4.7.2 Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
4.7.3 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
4.7.4 Best practices for backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
iv
Chapter 5. VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 About VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Understanding the components of a VMControl environment . . . . . . . . . . . . . . . . . .
5.2.1 Platform managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Virtual servers or virtual machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Guest-operating-systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Virtual farms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.6 Virtual appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.7 Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.8 System pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Managing KVM on Red Hat Enterprise Linux with VMControl . . . . . . . . . . . . . . . . . .
5.3.1 VMControl supported tasks and limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 KVM virtual environment considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3 KVM on Red Hat Enterprise Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Managing VMware vSphere with VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 VMControl support for VMware vSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5 Managing Microsoft Hyper-V with VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5.1 Best practices for managing Microsoft Hyper-V with VMControl . . . . . . . . . . . .
5.6 Using IBM SmartCloud Entry with VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.1 IBM SmartCloud Entry hypervisor support . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.2 IBM SmartCloud Entry and VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.3 IBM SmartCloud Entry and VMware virtualization . . . . . . . . . . . . . . . . . . . . . . .
5.7 Managing PowerVM with VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1 VMControl supported features on PowerVM. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.2 Supported Power virtualization environments. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.3 How to activate IBM Systems Director VMControl . . . . . . . . . . . . . . . . . . . . . . .
5.7.4 Preparing the PowerVM environment for VMControl . . . . . . . . . . . . . . . . . . . . .
5.7.5 Storage allocation supported by IBM Systems Director VMControl . . . . . . . . . .
5.7.6 Managing virtual servers with VMControl Express Edition . . . . . . . . . . . . . . . . .
5.7.7 Managing a virtual appliance with VMControl Standard Edition . . . . . . . . . . . . .
5.7.8 Managing server system pools with VMControl Enterprise Edition. . . . . . . . . . .
5.7.9 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
247
248
249
249
250
250
250
251
251
251
251
251
253
254
255
282
284
286
289
290
290
291
297
298
299
300
304
305
309
310
325
329
344
Chapter 6. Active Energy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.1 Active Energy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Terms to know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Introduction to Active Energy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 AEM features: No-charge versus charged . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Requirements for installing AEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Learn which devices are supported for monitoring . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Learn which devices are supported for power management . . . . . . . . . . . . . . .
6.3 Learn how to start using Active Energy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Accessing Active Energy Manager resources. . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Monitoring features that are available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Viewing trend data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 Calculating energy cost and energy savings. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.3 Viewing energy events and energy properties . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.4 Viewing supported monitors and setting thresholds . . . . . . . . . . . . . . . . . . . . . .
6.4.5 Configuring metering and cooling devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.6 Facility Software integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.7 Automatic notification upon UPS status change . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Management features that are available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
345
346
346
346
347
347
348
349
349
352
356
356
359
361
363
363
363
364
364
Contents
vi
6.5.1 Working with power cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.5.2 Working with power save . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3 Working with power policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Active Energy Manager: smcli references. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.7 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
365
367
369
370
373
Chapter 7. AIX Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.1 AIX Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 AIX Profile Manager: Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2 Before implementing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 AIX Profile Manager: System compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Profiles from AIX Runtime Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Event automation plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
375
376
377
377
379
380
383
383
395
401
Chapter 8. Workload Partition Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.1 WPAR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Install IBM WPAR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Accessing WPAR Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Managing WPARs infrastructure with WPAR Manager . . . . . . . . . . . . . . . . . . . . . . .
8.4.1 WPARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.2 Relocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.3 Patches and upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.4 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.6 Additional documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
403
404
404
404
405
405
407
407
411
414
415
416
416
Chapter 9. Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9.1 Overview of Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Planning for Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Discovering and managing virtual networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Discovering and managing IBM Systems Networking switches . . . . . . . . . . . . . . . . .
9.5 Discovering and managing the IBM Systems Networking 5000V . . . . . . . . . . . . . . . .
9.6 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
419
420
422
424
426
428
431
Chapter 10. Service and Support Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10.1 Service and Support Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Launch Service and Support Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Connectivity to IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 Enabling systems for service and support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.5 Serviceable event processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.6 Managing support files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.7 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
433
434
437
445
446
447
448
450
Chapter 11. Storage Management solutions and Storage Control. . . . . . . . . . . . . . .

11.1 Storage management solutions in IBM Systems Director . . . . . . . . . . . . . . . . . . . . .
11.1.1 Terms to know . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.1.2 Storage device support and management . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2 Base edition: IBM Systems Director Storage Manager . . . . . . . . . . . . . . . . . . . . . . .
11.2.1 Planning for storage management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
451
452
452
452
457
458
11.2.2 SMI-S provider installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

11.2.3 IBM Systems Director Platform Agent installation. . . . . . . . . . . . . . . . . . . . . . .
11.2.4 IBM Systems Director Storage Manager: Discovery. . . . . . . . . . . . . . . . . . . . .
11.2.5 IBM Systems Director Storage Manager: Inventory collection . . . . . . . . . . . . .
11.2.6 IBM Systems Director Storage Manager: Managing storage . . . . . . . . . . . . . .
11.3 Advanced edition: IBM Systems Director Storage Control . . . . . . . . . . . . . . . . . . . .
11.3.1 Planning for Storage Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.2 Installation of Storage Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.3 IBM Systems Director Storage Control lifecycle operations . . . . . . . . . . . . . . .
11.3.4 Discovering storage devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.5 Discovering Fibre Channel fabric in IBM Systems Director . . . . . . . . . . . . . . .
11.3.6 Inventory collection on Storage Control-managed devices. . . . . . . . . . . . . . . .
11.3.7 IBM Systems Director Storage Control: Allocating storage volumes
to virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.3.8 Removing Storage Control-managed devices . . . . . . . . . . . . . . . . . . . . . . . . .
11.4 Storage management: smcli references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.5 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
459
460
461
464
465
469
469
470
472
473
478
480
Chapter 12. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12.1 Troubleshooting the installation of IBM Systems Director components . . . . . . . . . .
12.1.1 Pre-installation check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.2 Post Installation Validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.3 IBM Systems Director messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.1.4 IBM Systems Director log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2 Troubleshooting security-related issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.1 Restoring local OS authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.2.2 Additional information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3 Troubleshooting VMControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3.1 KVM troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3.2 VMware vSphere troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.3.3 PowerVM troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.4 Troubleshooting AIX Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5 Troubleshooting Workload Partition Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.1 WPAR-capable system does not appear in WPAR Manager console . . . . . . .
12.5.2 Remove WPAR from Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.3 Creating WPARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.5.4 WPAR logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.6 Troubleshooting Storage Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.6.1 Runtime log locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.6.2 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
493
494
494
494
497
499
500
501
501
502
502
506
507
509
509
509
510
511
511
512
512
513
Appendix A. Technical articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1 Information center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Social media and support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.4 Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.5 YouTube channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.6 My Notifications email announcements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.7 Education and training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.8 Integrated education modules in IBM Systems Director . . . . . . . . . . . . . . . . . . . . . . .
A.9 Education courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.10 Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.11 Other useful links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
517
518
518
518
519
520
520
521
522
525
525
526
Contents
481
487
489
490
vii
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
529
529
529
531
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.
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 websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
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.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
ix
Trademarks
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. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US
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
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Active Memory
AIX 5L
AIX
BladeCenter
DB2
Domino
DS4000
DS6000
DS8000
Electronic Service Agent
EnergyScale
Global Technology Services
i5/OS
IBM Flex System
IBM Flex System Manager
IBM SmartCloud
IBM Systems Director Active Energy
Manager
IBM
Lotus
Power Systems
POWER6
POWER7
PowerPC
PowerSC
PowerVM
POWER
PureFlex
PureSystems
Redbooks
Redpapers
Redbooks (logo)
Storwize
System i
System p
System Storage
System x
System z
Systems Director VMControl
Tivoli
WebSphere
XIV
z/VM
zEnterprise
The following terms are trademarks of other companies:

Intel Xeon, Intel, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks
of Intel Corporation or its subsidiaries in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
Java, and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its
affiliates.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
Preface
This IBM Redbooks publication describes the positioning of the IBM Systems Director in
the complete management range. It also compares the IBM Systems Director with the IBM
Flex Systems Manager (FSM) and describes the environments for which each tool is best
suited.
This publication helps you plan, install, tailor, and configure the IBM Systems Director on
different platforms. It contains information about required system resources and which
network ports are used. It shows how to use the Workload Estimator to select the appropriate
hardware for IBM Systems Director server and provides information about the IBM Systems
Director Editions.
Best practices are covered for the basic management tasks that are available in IBM Systems
Director, including how to perform discovery; how to collect inventory on discovered
resources; how to deploy agent, driver, and firmware updates; how to manage hardware
events; and other miscellaneous tasks.
An overview of best practices is provided for using IBM Systems Director VMControl.
Systems Director VMControl is a cross-platform product that assists you in rapidly deploying
virtual appliances to create virtual servers that are configured with the operating system and
software applications that you want. It also enables you to group resources into system pools,
which enable you to centrally manage and control the different workloads in your
environment.
The following plug-in offerings are described:
Energy monitoring and management features offered by IBM Systems Director Active
Energy Manager along with the best practice, which needs to be followed in using the
IBM Systems Director Active Energy Manager.
The IBM AIX Profile Manager is a tool that can help implement and monitor the security
of all AIX servers in a production environment but also implement and monitor the system
compliance of those AIX servers.
Best practices and the most important questions to ask before creating Workload Partition
Manager (WPAR) and WPAR Manager infrastructure. In addition, how you can manage
and relocate WPARs using WPAR Manager graphical interface and the command-line
interface.
Network Control basic functionalities and how to plan for Network Control deployments
and also a number of common scenarios with best practices.
The IBM Systems Director Service and Support Manager describes how to set up and
how to handle serviceable events.
Best practices for the Storage Monitoring and Management capabilities offered by IBM
Systems Director server.
This book is for IBM IT specialists and IT architects, IBM Business Partners, and clients, who
are utilizing or considering implementing IBM Systems Director.
xi
Authors
This book was produced by a team of specialists from around the world working at the IBM
International Technical Support Organization (ITSO), Raleigh Center.
Rufus Credle is a Certified Consulting IT Specialist at the

ITSO, Raleigh Center. In his role as Project Leader, he
conducts residencies and develops IBM Redbooks and IBM
Redpapers publications. Subjects include network operating
systems, enterprise resource planning (ERP) solutions, voice
technology, high availability, clustering solutions, web
application servers, pervasive computing, IBM and OEM
e-business applications, IBM WebSphere Commerce, IBM
industry technology, IBM System x, and IBM BladeCenter.
Rufus' various positions during his IBM career include
assignments in administration and asset management,
systems engineering, sales and marketing, and IT services. He
has a BS degree in Business Management from Saint
Augustine's College. Rufus has been employed at IBM for 33
years.
Follow Rufus on Twitter: http://twitter.com/rcredle1906
Join Rufus network on LinkedIn:
http://www.linkedin.com/pub/rufus-p-credle-jr/1/b/926
Srikanth Aithal is a Senior Systems Management Test
Engineer in the IBM Systems and Technology Group. He is
based in Bengaluru, India. He holds a degree in Computer
Science from the Visvesvaraya Technological University in
Karnataka. Srikanth has worked at IBM since 2007 and is
currently working for Cloud Systems Software group. He
focuses primarily on virtualization management on IBM Power
servers and IBM Systems management stack. He also has
expertise on IBM System x and IBM BladeCenter systems and
has delivered many client trainings around IBM BladeCenter
and IBM systems management.
Join Srikanths network on LinkedIn:
http://in.linkedin.com/pub/srikanth-aithal/13/922/6b8
xii
Nicolas Bour is a UNIX Systems Administrator in Switzerland.

He has 11 years of experience in the AIX field. His areas of
expertise include IBM AIX, IBM Power Systems, IBM
Systems Director, Security, and Linux Red Hat. He is an IBM
Certified Advanced System Expert (Power5) and Red Hat
Certified Systems Administrator.
Join Nicolas network on LinkedIn:
http://ch.linkedin.com/pub/nicolas-bour/11/378/729
Stephane Bourdeaud is a Certified Infrastructure Architect for
the IBM Global Technology Services Delivery organization.
He is based in Aubire, France. Stephane has over 15 years of
experience in the IT industry and focuses primarily on
virtualization technologies on Intel platforms. He works for the
Global Technology Services Delivery Technology and
Engineering organization, where he is a member of the core
team for the Virtualization and Distributed Server Management
Specialty Area. He is a VMware Certified Professional and
teaches a class on virtualization at the Institut Suprieur
dInformatique de Modlisation et de leurs Applications
(ISIMA), an engineering school in Clermont Ferrand, France.
Stephane is also a contributor to the IBM Expert Integrated
System Blog (http://expertintegratedsystemsblog.com).
Follow Stephane on Twitter: https://twitter.com/BourdeaudS
Join Stephanes network on LinkedIn:
http://fr.linkedin.com/pub/stephane-bourdeaud/57/4b8/168
Tomi Mannikainen is an IBM PureSystems Client Technical
Specialist for IBM Systems and Technology Group. He is based
in Helsinki, Finland. He has 17 years of experience in the IT
industry with a focus on service provider environments,
networking, virtualization, and cloud provisioning technologies.
Tomi is a contributor in the PureHeat community and he
actively participates in beta and iiCap programs. He is a Flex
Systems Manager black belt. He holds a Masters degree in
Business Administration.
Join Tomis network on LinkedIn:
http://fi.linkedin.com/pub/tomi-mannikainen/5/a20/449
Preface
xiii
Olaf Menke is a Consultant and Subject Matter Expert for

systems management. He has worked in the IBM Technical
Support Services (TSS) Software Service in IBM Germany for
the past two years. Prior to this position, he was a Systems
Engineer and IBM System x and BladeCenter specialist in the
System x Pre-Sales team in Germany. He has over 16 years of
experience in support of computer systems and software. He
holds a degree in Information Technology from the Technische
Universitaet in Dresden. His areas of expertise include
System x, BladeCenter, IBM PureFlex, Systems Director,
and management hardware. He is an IBM Certified Specialist
for PureFlex and IBM Certified Expert for IBM System x and
BladeCenter.
Join Olafs network on LinkedIn:
http://www.linkedin.com/pub/olaf-menke/5/48a/9aa
Juan P Fernandez Sabate is a Delivery Technology and
Engineering Architect for the IBM Delivery Center that is
located in Argentina. He holds a degree in Computer
Engineering from the National University of Tucuman in
Argentina. He has over eight years of experience in IT and has
been working for IBM for last six years. His areas of expertise
include IBM System i, IBM Tivoli products, and IBM
Systems Director. He focuses primarily on providing
Automation and Monitoring solutions.
Join Juan Pablos network on LinkedIn:
http://www.linkedin.com/pub/juan-pablo-fernandez-sabate
/4/527/b36
Thanks to the following people for their contributions to this project:
Tamikia Lee
IBM International Technical Support Organization, Raleigh Center
Venkata s Amulothu (Kishore), Larry Bailey, Elodie Bourdeaud, Stephen Boyte, Deanna
Brown, Kimberly K Button, Steven M Hancock, David Kasberg, Jay Kidambi, Uday K
Kumbhari, Achuth Maniyedath, John McGinn, Ranjith Rajagopalan Nair, Brian Noordyke,
Christian Ovsenik, Pushkar Patil, Lee Prissel, Rahul B Rege, Hector L. Sanchez, Chris Seyer,
Jin Ming Shang, Barb Smith, and Liyan Zhang.
IBM
Now you can become a published author, too!

Heres an opportunity to spotlight your skills, grow your career, and become a published
authorall at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
xiv
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about this book or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
Send your comments in an email to:
[email protected]
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Stay connected to IBM Redbooks

Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on Twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Preface
xv
xvi
Chapter 1.
Positioning IBM Systems

Director
This chapter describes the positioning of the IBM Systems Director in the complete
management range. It also compares the IBM Systems Director with the IBM Flex Systems
Manager (FSM) and describes the environments for which each tool is best suited.
This chapter contains the following topics:
1.1, Description of IBM Systems Director on page 2

1.2, Functionality of IBM Systems Director on page 2
1.3, Positioning of IBM Systems Director on page 3
1.4, IBM Systems Director and IBM Flex Systems Manager on page 4
1.5, Best practices on page 5
1.1 Description of IBM Systems Director

IBM Systems Director is a platform management tool with enhanced functionality for
managing both physical and virtual resources in a heterogeneous environment. IBM Systems
Director uses industry standards to support multiple operating systems and virtualization
technologies across IBM platforms and non-IBM x86 platforms.
IBM Systems Director provides tools for managing, monitoring, and handling your
heterogeneous environment including System x, Power Systems, IBM System z, Storage,
and networking components as physical or virtual systems.
IBM Systems Director provides administrators with a single vantage point through its web
interface or command line tool (SMCLI) and reduces IT management complexity and costs.
1.2 Functionality of IBM Systems Director

IBM Systems Director consists of a basic IBM Systems Director server. It includes all
necessary functions to manage the different platforms and plug-ins or Advanced Managers,
which enhance the functionality of the IBM Systems Director server.
The following basic functions are provided at no charge on IBM hardware with IBM Systems
Director:
Discovery of systems that brings the systems into the IBM Systems Director server and
allows access to the systems.
Inventory of systems for hardware and software inventory that is stored in the IBM
Systems Director Database.
Event management that handles incoming events, Event Action Plans, and monitoring with
thresholds.
Update management that downloads the latest update information; runs a compliance
check; updates the firmware, drivers, and IBM Systems Director server and agents, and
rollout of agents.
Platform management that includes specific management tasks for the different IBM
platforms such as Power Systems, System z, System x, and BladeCenter.
Detailed information about these basic functions can be found in this IBM Redbooks
publication in Chapter 4, Basic management tasks on page 77.
To expand the functionality, there are plug-ins or the Advanced Manager available. These are:
VMControl is a tool for handling, monitoring, and management of virtual environments
across brands (VMware vSphere, Kernel-based Virtual Machine (KVM), IBM PowerVM).
See Chapter 5, VMControl on page 247 for detailed information.
Active Energy Manager is a tool that includes monitoring of power usage (at no charge)
and management of power usage (fee based) that includes power safe and power capping
functionality for servers and infrastructure components. See Chapter 6, Active Energy
Manager on page 345 for detailed information.
AIX Profile Manager is used to implement and monitor security standards (IBM LLS,
MLS, and HLS models; and PCI, SOX, Dod, Hippa standard models). It is also used to
implement and control system settings on all AIX and VIO servers against a client
predefined standard. See Chapter 7, AIX Profile Manager on page 375 for detailed
information.
AIX PowerVM Workload Partition Manager is used to manage all the workload partition
(WPAR) infrastructure, which includes all kinds of WPARs and all global environment. See
Chapter 8, Workload Partition Manager on page 403 for detailed information.
Network Control is used for management of top of rack (ToR) switches and switches in
BladeCenter and Flex systems. See Chapter 9, Network Control on page 419 for
detailed information.
Service and Support Manager is a call home tool to automatically create hardware defect
calls to IBM. See Chapter 10, Service and Support Manager on page 433 for detailed
information.
Storage Control is a tool for the management of different storage devices such as the IBM
Storwize V7000, SAN Volume Controller (SVC), DS3/4/5000, IBM DS8000, and
third-party devices from EMC and Hitachi. See Chapter 11, Storage Management
solutions and Storage Control on page 451 for detailed information.
1.3 Positioning of IBM Systems Director

IBM Systems Director is a platform management tool. The Upward Integration modules from
IBM Systems Director provide an integration into enterprise management tools, such as
Tivoli, HP OpenView, CA Unicenter, and the Microsoft Systems Management Server family.
As shown in Figure 1-1, IBM Systems Director is positioned below the enterprise tools.
Additionally, IBM Systems Director can manage all of the platforms, service processors, and
platform-specific tools in one common program and console. This helps administrators focus
on their work without the need to connect to different consoles.
Figure 1-1 Positioning IBM Systems Director
As a platform management tool, IBM Systems Director supports the management of IBM and
non-IBM hardware and drives common tasks through the following platform-specific
manager:
IBM Power Systems management
HMC, IVM, and VIOS appliances
Power Systems server, Power Blade server
AIX, IBM i, and Linux on Power operating systems
Chapter 1. Positioning IBM Systems Director
IBM BladeCenter chassis management

IBM BladeCenter chassis components such as switches and blades
VMware virtual server inside a BladeCenter
IBM System x Management
System x and BladeCenter server systems
Windows and Linux operating systems
System z management
IBM z/VM hypervisor
Linux on z installed on z/VM virtual server and also on partitions without z/VM
IBM System Storage Management
Integrated RAID Adapter (such as LSI) and ServeRaid Adapter family
Network Storage, such as IBM DS3000, IBM DS4000, IBM DS5000, IBM DS6000
Storage switches (SAS, Fibre Channel, and Converged Network (CN) switches) such
as IBM BladeCenter SAS, IBM Systems Networking CN switches, and switches from
Brocade, QLogic, Nortel, and Cisco.
IBM Flex System hardware
No FSM installed
x86 compute nodes only
1.4 IBM Systems Director and IBM Flex Systems Manager

IBM Systems Director and Flex Systems Manager (FSM) are based on the same basic code
modules (the FSM reuses the IBM Systems Director code and some of its advanced
managers) but they are enhanced with specific elements for each of them. They are both
platform management tools. However, they have different specifications and support different
types of hardware:
IBM Systems Director is for general, universal use.
This means that IBM Systems Director can manage rack, tower, and blade servers across
brands. IBM Systems Director can also manage Flex Systems, but only when there is no
FSM installed in the Flex Chassis and only for x86 compute nodes. IBM Systems Director
supports third-party hardware. IBM Systems Director must be manually installed. There is
no pre-installation option.
Flex Systems Manager (FSM) is for specialized use.
FSM is optimized for managing the Flex and PureFlex systems. FSM brings a new user
interface (UI), the Flex Explorer. It contains additional functionality through the graphical
view to the components in the Flex Chassis such as an operating system provisioning
engine and configuration patterns for Flex System components. The Flex Systems
Manager is a completely pre-installed appliance on a specialized compute node for the
Flex and PureFlex systems. The FSM brings a deeper integration with hypervisors and
system patterns for the configuration of the environment on the Flex Chassis.
Figure 1-2 on page 5 shows a comparison of the two tools.
Figure 1-2 IBM Systems Director versus Flex Systems Manager
Note: If you have both Flex System and System x or BladeCenter hardware in your
infrastructure, you can have an FSM and IBM Systems Director server running side by
side. You cannot manage Flex System components from both the FSM and
IBM Systems Director. The components can be managed only on the FSM. There is
currently no available solution to manage both IBM Systems Director and FSM from the
same console.
1.5 Best practices

The following list describes the best practices for positioning and usage of IBM Systems
Director:
Use IBM Systems Director for all of your cross brand systems, including Flex Enterprise
chassis without FSM installed.
Prefer Flex Systems Manager for managing all systems inside a Flex or PureFlex system
because it has additional functionalities.
Use IBM Systems Director only as a platform management tool.
Start using IBM Systems Director with the basic tasks. When you get experienced with the
basic tasks and the handling of IBM Systems Director, you can expand the functionality by
installing the plug-ins or Advanced Managers.
Plan the installation and usage of IBM Systems Director carefully, using the requirements
and architectural decisions in the following chapters.
Chapter 1. Positioning IBM Systems Director
Chapter 2.
Planning
This chapter describes the planning requirements for IBM Systems Director. It contains
information about required system resources and which network ports are used. It shows how
to use the IBM Systems Workload Estimator to select the right hardware for IBM Systems
Director server and provides information about the IBM Systems Director Editions.
This chapter also addresses some of the most common architectural decisions you will be
faced with when planning for an IBM Systems Director deployment.
2.1, System resources on page 8

2.2, IBM Systems Workload Estimator on page 9
2.3, Before you begin on page 15
2.4, Best Practice for planning endpoint management on page 18
2.5, Firewall ports on page 19
2.6, IBM Systems Director Editions on page 24
2.7, Architectural decisions and recommendations on page 26
2.1 System resources

Table 2-1 is a guide for the installation of IBM Systems Director. Use Table 2-1 to estimate the
system resources to allocate to the logical partition (LPAR), virtual, or physical machine on
which the IBM Systems Director server will be installed.
Table 2-1 IBM Systems Director hardware requirements for medium to large environments
Operating system
Processor
Memory
Disk storage
AIX/Linux
Four processors, POWER5, IBM

POWER6, or POWER7:
Entitlement = 4
Uncapped
Virtual processor = 8
Weight = default
16 GB
30 GB
Microsoft Windows
Four processor cores (two

dual-core processors or
one quad-core processor)
16 GB
30 GB plus space for

Update Manager files
Linux on x86
Four processor cores (two

dual-core processors or one
quad-core processor)
16 GB

Guest OS on virtualized
environment on x86
Four vCPUs
16 GB

Recommendations are based on 64-bit Java virtual machine (JVM).

Recommendations are based on POWER6, Intel Xeon processor numbers for x86.
I/O requirements: SCSI/serial-attached SCSI (SAS) adapters and multiple 10 K - 15 K rpm disks.
Suggested: Two processors minimum and 8-GB memory minimum.
Disk storage depends on advanced managers, the used database (local/remote), and the
number of systems models for the Update Manager repository size.
Advanced manager might require more memory (for performance).
Table 2-1 references a medium-to-large environment. In a small environment, the amount for
memory and CPU usage can be smaller. But for performance reasons, you should also use
the size that is described for small environments
Installation sizes are summarized in Table 2-2.
Table 2-2 Definitions for small, medium, and large installations
Configuration size
Managed systems
Small
< 500 managed systems
Medium
500 > managed systems < 1000
Large
> 1000 managed systems
The installation media for the IBM Systems Director server includes an integrated IBM DB2
database. Use the integrated DB2 database as the default database to simplify the
installation and reduce the need for a database administrator. If you plan to use Storage
Control, a DB/2 database (local or remote) is required.
The components in Figure 2-1 show points to consider when you design and implement the
IBM Systems Director server from a loading viewpoint.
System 2
Console running in a
browser on a separate
system
Web
console
Director server
machine needs enough
processing power and
memory
System 1
Director server
Advanced
managers
Database speed is
critical
System 1
Local database
Database
server
Disk (possibly
network attached)
Fast disk subsystem
Figure 2-1 Systems Director components
2.2 IBM Systems Workload Estimator

IBM Systems Workload Estimator for Systems Director 6.3 is a web-based tool that can size
hardware for systems that run the Systems Director server. The tool is presented in a Q&A
format and requests user input.
The tool provides information about physical systems but it can also be used to get figures for
a virtual environment (for example, running IBM Systems Director in a VM). In this case, use
the information to get the physical system and transform this into a virtual environment. For
example, if the physical server should have four cores you should use four vCPUs instead for
a virtual server running the IBM Systems Director server.
Use the following steps to launch and use the IBM Systems Workload Estimator.
1. Launch the IBM Systems Workload Estimator for Systems Director 6.3 from this URL:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.dire
ctor.plan.helps.doc%2Fwle.html
2. When the web page displays, click WLE for IBM Systems Director 6.3 to start Workload
Estimator.
Chapter 2. Planning
3. You might be asked to enter user demographic information, as shown in Figure 2-2. Enter
the appropriate information about this page and then click Continue.
Figure 2-2 User Demographic Information window
10
4. If you are not asked for demographic information, the window shown in Figure 2-3 is
displayed, which shows the platform, database, and plug-in type. The Active Energy
Manager plug-in is listed due to the additional I/O, network traffic, and processor utilization
activity that results from collecting data from your energy consumption. Click Continue.
Figure 2-3 Platform choice
Chapter 2. Planning
11
5. Figure 2-4 requests information about the operating system on which you chose to install
the Systems Director server, the estimated number of physical systems and operating
systems with the managed environment, and the number of concurrent console users.
Enter the appropriate information and click Continue.
Figure 2-4 Operating system and physical system information usage
12
6. The estimator provides guidance for the number of required disk drives for internal or
external storage (Figure 2-5). Enter the appropriate information and click Continue.
Figure 2-5 Disk and storage information
Chapter 2. Planning
13
After entering all of your system information, the Workload Estimator provides two estimated
outputs. One estimate is for an immediate solution and the other estimate is for a growth
solution (Figure 2-6).
Figure 2-6 Workload Estimator proposed solution
You can further modify the configuration by reviewing the selected system and by using the
modify section to change the configuration, as shown in Figure 2-7.
Figure 2-7 Modify the Workload Estimator selection
14
This output does not imply that you acquire new hardware. However, this output can be used
as a guide to place a system in an environment that has available resources.
2.3 Before you begin

Before the installation, review the requirements that are applicable to the operating system
that you use for the installation and the current hardware environment.
Management server: Carefully plan the hardware and virtualization environment to be
managed by the management server.
Hardware requirements are listed in the Information Center at the following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.plan.hel
ps.doc/fqm0_r_hardware_requirements.html
The supported operating systems are listed in the Information Center at the following site:
ctor.plan.helps.doc%2Ffqm0_r_supported_operating_systems.html
Security features and considerations are documented in the Information Center at the
following site:
ctor.security.helps.doc%2Ffqm0_c_security.html
Perform the following primary tasks:
Install the Systems Director server. (Chapter 3, Installation on page 35)
Start the Systems Director server. (3.1.5, Starting IBM Systems Director on page 55)
Update the Systems Director server. (4.3.9, Updating the Systems Director server on
page 134)
File system requirements that are needed for the installation are documented at the following
website:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.directo
r.plan.helps.doc%2Ffqm0_r_hardware_requirements_servers_running_aix.html
The installation of the Systems Director server is not the only step during the setup phase.
Figure 2-8 on page 16 illustrates the interaction within Systems Director and the interactions
among the components of the server:
Command-line interface (CLI) interaction

Operating system and hardware
Network speed
Disk subsystem
Database activity
Concurrent users
Managed systems
Chapter 2. Planning
15
Rate of CLI and REST

requests
Operating system,
Hardware
configuration,
Director tuning
Options.
REST clients
Web
console
CLI scripts
Network speed
Director server
Network storage speed

(throughput rate and
latency.
Advanced
managers
Disk
Number of processors
and processor speeds;
64-bit processor
assumed.
Number of advanced
functions that are
running and how often
they are running. For
example, polling
intervals, scheduled
jobs, and inventory.
Disk speed
CPU
Memory
Disk
Memory size
Database
server
Network speed
Disk subsystem
configuration.data
collected.
Number of console
users
Amount of inventory
data collected and
frequency of collection.
Network speed
Managed
endpoints
Polling rates, etc., for

monitoring endpoints.
Amount of active
resource monitoring.
Figure 2-8 Systems Director interaction
When it comes to placement of the IBM Systems Director server, network connectivity is
critical, including DMZ and network firewalls. If firewalls are placed between the management
server and the systems to be managed, changes must be made to allow for the required
information flow.
A list of all TCP/IP ports that are used by IBM Systems Director are listed at the following site:
r.plan.helps.doc%2Ffqm0_r_all_available_ports.html
16
Figure 2-9 displays a flow from the IBM Systems Director server to a discovered Hardware
Management Console (HMC) and AIX operating systems.
Network
HMC
IP address
access ID
ssh 22, slp 427, cim 5988 & 5989
IBM Systems Director Server

IP address
Operating System
access ID
Power Server 1
Firmware
Virtual Server
Operating System CAS
Ports
9510,9514,9515
Operating System CAS
Ports
9510,9514,9515
Virtual Server
Virtual Server
Power Server 1
Firmware
Virtual Server
Virtual Server
Virtual Server
Figure 2-9 Sample connectivity for Power Systems
Before installing IBM Systems Director server, ensure that no server ports are in use by using
the netstat and rmsock commands. Figure 2-10 lists examples of the netstat command for
active ports.
-bash-3.2# netstat -Aan | egrep "951(0|4|5)| grep LISTEN"
f1000e00110173b8 tcp
0
0 *.9510
*.*
LISTEN
f1000e000142d3b8 tcp4
0
0 127.0.0.1.9514
*.*
LISTEN
f1000e0003b883b8 tcp4
0
0 127.0.0.1.9515
*.*
LISTEN
-bash-3.2# rmsock f1000e00110173b8 tcpcb
The socket 0xf1000e0011017008 is being held by proccess 23134290 (java).
-bash-3.2# ps -ef | grep 23134290
root 23134290 35455054
0 Oct 22
- 8:51
/var/opt/tivoli/ep/_jvm/jre/bin/java -Xmx384m -Xminf0.01 -Xmaxf0.4
-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
-Xbootclasspath/a:/var/opt/tivoli/ep/runtime/core/eclipse/plugins/com.ibm.rcp.base_6.2.3
.20110824-0615/rcpbootcp.jar:/var
Figure 2-10 The netstat -Aan and rmsock commands
By using the netstat and rmsock commands, you can see which process is holding the port
and take corrective action to free the port before the IBM Systems Director server installation.
An alternate to the netstat and rmsock commands is to use the lsof command to list open
files. You can download lsof from this link as part of the AIX Expansion Pack:
http://www-03.ibm.com/systems/power/software/aix/expansionpack/index.html
Chapter 2. Planning
17
The netcat command is an option for both Transmission Control Protocol (TCP) and User
Datagram Protocol (UDP) to check connectivity between machines, as shown in Figure 2-11.
-bash-3.2# netcat -zv 9.42.171.23 389
xs-2120rhelppc.itso.ral.ibm.com [9.42.171.23] 389 (ldap) open
-bash-3.2# netcat -zv 9.42.171.23 9510
xs-2120rhelppc.itso.ral.ibm.com [9.42.171.23] 9510 (?) open
-bash-3.2#
Figure 2-11 The netcat command
2.4 Best Practice for planning endpoint management

IBM Systems Director has multiple methods to manage different endpoints. The method
depends on the type of equipment that you plan to manage. Servers are the most common
endpoints.
Complete these prerequisites to manage endpoints by using Systems Director:
Verify that the Domain Name System (DNS) functions correctly for both forward and
reverse lookup.
Systems Director uses standard networking technologies, such as DNS, to identify and
communicate with the endpoints.
Open the necessary firewall ports.
Systems Director uses several ports to communicate with various endpoints that need to
be open. Each type of device requires a group of ports. Determining which ports to open
depends on what you plan to manage. See section 2.5, Firewall ports on page 19 for a
list by function.
For more information about ports that are used by the Systems Director server, managed
systems, and important port considerations, go to the following site:
ctor.plan.helps.doc%2Ffqm0_r_all_available_ports.html
Determine how you want to manage your systems.
You can choose agentless, Platform Agent, or Common Agent. For more information, see
section 2.7.1, Determine which agent to use to manage your systems on page 26.
18
2.5 Firewall ports

Table 2-3 through Table 2-20 on page 24 list the TCP and UDP ports that need to be open for
specific Systems Director functions to work correctly.
Table 2-3 BladeCenter advanced management module (AMM) (out-of-band)
Protocol
Description
IBM Systems
Director server
port
Managed endpoint port
Service Location
Protocol (SLP)
Discovery
427, TCP, UDP

Inbound,
Outbound
427, TCP, UDP

Inbound,
Outbound
SLP
Communication and
discovery
14252,a TCP,
UDP
Inbound,
Outbound
14252, TCP, UDP

Inbound, Outbound
TCP Command Mode
Ongoing communication
and management
6090, TCP
Outbound
6090, TCP
Inbound
UDP
Native events
13991, UDP
Inbound
13991, UDP
Outbound
Simple Network
Management
Protocol (SNMP)
SNMP
communication/traps
162, TCP, UDP

Inbound,
Outbound
162, TCP, UDP

Inbound,
Outbound
Trivial File Transfer

Protocol
(TFTP)/SNMPv3
Updating AMM firmware
69, UDP
Inbound;
121, UDP
Inbound,
Outbound
69, UDP Outbound;

121, UDP
Outbound,
Inbound
a. On both the server and the MEP, the source port plus the next 25 ports (or 75 when more
systems are discovered concurrently) must be open. The source port can be changed in the
slp.prop files.
Table 2-4 Integrated management module 1 (IMM1) and IMM2 (out-of-band rack servers)
Protocol
Description
IBM Systems
Director server port
SLP
Discovery
427, TCP, UDP

Inbound,
Outbound
427, TCP, UDP

Inbound,
Outbound
UDP
Native events
13991, UDP
Inbound
13991, UDP
Outbound
SLP
Communication
and discovery
14252,a TCP, UDP

Inbound, Outbound
14252, TCP, UDP

Inbound, Outbound
systems are discovered concurrently) must be open. The source port can be changed in the
slp.prop files.
Chapter 2. Planning
19
Table 2-5 Management module (MM), Remote Supervisor Adapter (RSA 1/2)
Protocol
Description
IBM Systems
SLP
Discovery
427, TCP, UDP

Inbound,
Outbound
427, TCP, UDP

Inbound,
Outbound
SLP
Communication and discovery
14252,a TCP, UDP

Inbound, Outbound
14252, TCP, UDP

Inbound, Outbound
CIM
Ongoing communication and

management
5988 or 15988b, TCP

Inbound,
Outbound (unsecure);
5989 or 15988b , TCP
Inbound,
Outbound (secure)
5988 or15988b , TCP

Inbound,
5989 or 15988b TCP
Inbound,
Outbound (secure)
TFTP
Updates for System x/Flex servers

that run ESXi
69, UDP
Outbound
69, UDP
Inbound
systems are discovered and managed concurrently) must be open. The source port can be
changed in the slp.prop files.
b. CIM Server for SUSE Linux Enterprise Server.
Table 2-6 Flex Chassis Management Module (CMM)
Protocol
Description
IBM Systems
SLP
Discovery
427, TCP, UDP

Inbound,
Outbound
427, TCP, UDP

Inbound,
Outbound
SLP
Communication and discovery
14252,a TCP, UDP

Inbound, Outbound
14252, TCP, UDP

Inbound, Outbound
CIM

management
5988 or 15988b, TCP

Inbound,
5989 or 15988b , TCP
Inbound,
Outbound (secure)
5988 or 15988b , TCP

Inbound,
5989 or 15988b , TCP
Inbound,
Outbound (secure)
SFTP
Update CMM firmware
9520, TCP
Outbound
9520, TCP
Inbound
systems are discovered and managed concurrently) must be open. The source port can be
changed in the slp.prop files.
b. CIM Server for SUSE Linux Enterprise Server.
20
Table 2-7 Hardware Management Console (HMC)

Protocol
Description
IBM Systems
Director server
port
SSH
Ongoing communication with

limited management
22, TCP
Outbound
22, TCP
Inbound
CIM

management
5989, TCP
Inbound,
Outbound (secure)
5989, TCP
Inbound,
Outbound (secure)
Table 2-8 Windows agentless

Protocol
Description
IBM Systems Director server

port
DCOM
Ongoing
communication
with limited
management
135, TCP, UDP

Outbound (software
installation);
137 - 139, TCP, UDP
Outbound;
445, TCP, UDP
Outbound
135, TCP, UDP

Inbound (software
installation);
137 - 139, TCP, UDP
Inbound;
445, TCP, UDP
Inbound
Table 2-9 Linux agentless

Protocol
Description
IBM Systems
Director server
port
SSH
Ongoing communication with limited

management
22, TCP
Outbound
22, TCP
Inbound
Table 2-10 AIX agentless

Protocol
Description
IBM Systems
Director server
port
SSH
Ongoing communication with limited

management
22, TCP
Outbound
22, TCP
Inbound
Table 2-11 VMWare ESXi

Protocol
Description
IBM Systems
SLP
Discovery
427, TCP, UDP

Inbound,
Outbound
427, TCP, UDP

Inbound,
Outbound
CIM

management
5988, TCP
Inbound,
5989, TCP
Inbound,
Outbound (secure)
5988, TCP
Inbound,
5989, TCP
Inbound,
Outbound (secure)
Chapter 2. Planning
21
Table 2-12 IBM Systems Director Platform Agent

Protocol
Description
IBM Systems
SLP
Discovery
427, TCP, UDP

Inbound, Outbound
427, TCP, UDP

Inbound, Outbound
CIM

management
5988 or 15988a, TCP

Inbound,
5989 or 15988a , TCP
Inbound,
Outbound (secure)
5988, 15988a TCP

Inbound,
5989, 15988a TCP
Inbound,
Outbound (secure)
a. CIM Server for SUSE Linux Enterprise Server

Table 2-13 IBM Systems Director Common Agent (CAS)
Protocol
Description
IBM Systems
Director server
port
SLP
Discovery
14252, TCP,
UDP
Inbound,
Outbound
14252, TCP, UDP

Inbound,
Outbound
CAS
All ongoing communication and

management
9510, TCP
Inbound,
Outbound;
9511 - 9513,
TCP
Inbound;
20000, TCP
Inbound
9510, TCP
Inbound;
9511 - 9513, TCP
Outbound;
20000, TCP
Outbound
Table 2-14 I/O modules
22
Protocol
Description
IBM Systems
Director server
port
SSH
Ongoing communication with

limited management
22, TCP
Outbound
22, TCP
Inbound
SNMP
Monitoring
162, TCP, UDP

Inbound,
Outbound
162, TCP, UDP

Inbound,
Outbound
TFTP/SFTP/FTP
Firmware updates
FTP 20 - 21
TCP
Inbound;
SFTP 9520
TCP
Inbound;
TFTP 69
UDP
Inbound
FTP 20 - 21
TCP
Outbound;
SFTP 9520
TCP
Outbound;
TFTP 69
UDP
Outbound
Table 2-15 SNMP Devices

Protocol
Description
IBM Systems
Director server
port
SNMP
SNMP communication/traps
162, TCP, UDP

Inbound,
Outbound
162, TCP, UDP

Inbound,
Outbound
Table 2-16 IBM Systems Director server Service and Support Manager
Protocol
Description
IBM Systems
Director server
port
HTTPS
Communication with IBM
443, TCP
Outbound
N/A
FTP
Service log upload
21, TCP
Outbound
N/A
Table 2-17 IBM Systems Director server Update Manager

Protocol
Description
IBM Systems Director

server port
HTTP
Check for updates,

Download updates
80, TCP, Outbound
N/A
HTTPS
Check for updates,

Download updates
443, TCP, Outbound
N/A
Table 2-18 IBM Systems Director server web interface

Protocol
Description
IBM Systems
Director server
port
HTTP
HTTP communication with IBM

Systems Director web interface (auto
redirects to HTTPS)
8421, TCP,
Inbound
N/A
HTTPS
HTTPS communication with IBM

Systems Director web interface
8422, TCP,
Inbound
N/A
Table 2-19 Default Managed DB2 database on IBM Systems Director server
Protocol
Description
IBM Systems
Director server
port
FCM
Database communication
50010, TCP
Inbound,
Outbound
N/A
Chapter 2. Planning
23
Table 2-20 IBM Systems Director CLI (smcli)

Protocol
Description
IBM Systems
Director server
port
TCP
Command-line interface
(CLI)
2044, TCP
Inbound,
Outbound
N/A
2.6 IBM Systems Director Editions

When you want to install IBM Systems Director server, you can select either to download the
Director installation package from the download site or you can select an IBM Systems
Director Edition.
The IBM Systems Director Editions provide a bundle of IBM Systems Director, Advanced
Managers, and Service and Support.
There are different versions of editions available, depending on your requirements and the
operating system on which the IBM Systems Director will be installed. The following versions
are available:
Express (available for System x and Power Systems)
This version includes management tools that can reduce operational complexity and
provide the ability to remotely discover, monitor, configure, and update your systems.
Standard (Available for System x, Power Systems, and System z)
This version includes all of the capabilities of the Express Edition and adds advanced
deployment, monitoring, and control features under the same console. It also includes
features for optimized energy usage and capacity.
Enterprise (available for Power Systems)
This version includes all of the capabilities of the Express and Standard Editions plus
features to enable automated resource provisioning and balancing that are required for a
dynamic infrastructure. It also provides enterprise management tools for advanced
troubleshooting, capacity analysis, and reporting.
Table 2-21 provides an overview of the features of the IBM Systems Director Editions by
platform. This helps you to find the right IBM Systems Director Edition for your requirements.
Table 2-21 IBM Systems Director Editions v6.3.2
IBM System Director Editions
System xa
Products
Express
Power Systems
Standard
Express
Standard
System z
Enterprise
Standard
IBM Systems Director v6.3.2
IBM Systems Director Service

and Support Manager v6.3.2
IBM Systems Director Active

Energy Manager - Monitoring
v4.4.2
24
IBM System Director Editions

System x
Products
Express
VMControl Express v 2.4.2
Power Systems
Standard
x
Express
x
Standard
System z
Enterprise
Standard
IBM Systems Director Active

Energy Manager - Monitoring
v4.4.2
IBM Systems Director Network

Control v1.4.0 (with license
restrictionsb)

VMControl Standard Edition Image Management v2.4.2
xc

VMControl Standard Edition System Pools v2.4.2
IBM Systems Director Storage

Control v 4.2.1.1
Tivoli content (AIX only)

IBM Tivoli Monitoring (ITM) v6.3
IBM Tivoli Common Reporting

v3.1
Platform-unique functions
IBM Upward Integration for
Microsoft System Center 4.0
IBM Upward Integration Module

for VMware (ISV) v 1.3
IBM Tivoli Provisioning

Manager for OS Deployment
v7.1.1d
IBM Systems Director Agent for

z/BX Power and x86 Blades
v6.3.2
IBM Virtual Media Key (IMMv1)
or IBM Integrated Management
Module (IMMv2) Advanced
Upgrade
xe
a. Also supports Flex Systems (x86 compute node, without FSM only).
b. License includes the ability to perform network device management (discovery, inventory, monitoring status) and
to use network diagnostics. All other features of network control (including topology view, interface to vendor
configuration tools, and configuration of host VLANs) require a full-use license of network control.
c. Kernel-based Virtual Machine (KVM) support only.
d. TPMfOSD is a separate installation. It is not integrated into the IBM Systems Director console or managed through
the IBM Systems Director.
e. Edition can be ordered with or without this feature.
Chapter 2. Planning
25
The Advanced Manager, which is part of the IBM Systems Director editions can be licensed
separately for installations of the IBM Systems Director. The editions that are listed above are
not used.
Service and Support is included in the IBM Systems Director Editions. If you need service
and support for your IBM Systems Director installation and have no use of an IBM Systems
Director Edition, contact your IBM representative and ask for service offerings for the IBM
Systems Director.
Tivoli Provisioning Manager for OS Deployment IBM Systems Director Edition (TPMfOSD ISD
Edition) is a separate installation, which is not integrated into IBM Systems Director Console.
The TPMfOSD is a tool for bare metal installations for IBM System x servers (for Windows,
Linux, and VMWare OS) and IBM PowerPC Systems (for AIX and Linux). There is no
support for the IBM Power Systems server in this product version.
For more information about this tool, the installation process, and usage, see the Tivoli
information center at the following link:
http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli.tp
m.osd.doc/welcome/osdhome.html
2.7 Architectural decisions and recommendations

This section contains recommendations on some of the architectural decisions that you will
have to make when planning for an IBM Systems Director server deployment. For each
decision, all possible alternatives are described, as well as the benefits and disadvantages for
each decision. Some of the recommendations might not apply to your environment, based on
your requirements and constraints.
2.7.1 Determine which agent to use to manage your systems

IBM Systems Director performance and scalability are intrinsically linked to the allocated
resources, the number of discovered systems, and the associated management type. One of
the key decisions that you will have to make is which agent, if any, you will use to manage
your endpoints.
The following server platforms are available:
Agentless
Platform Agent
Common Agent
Agentless
Agentless management provides hardware alerting out-of-band either through the IMM or
AMM. With agentless management, you can inventory your systems by using the distributed
component object model (DCOM) for Windows or Secure Shell (SSH) for Linux.
For more information about agentless systems, see the following site:
r.install.helps.doc%2Ffqm0_t_preparing_agentless_managed_systems.html
If you think agentless monitoring is right for you, consider the following factors:
To get accurate hardware event information, your system requires a management module.
You should also discover this management module out-of-band (meaning that you should
26
discover it directly by using the management module IP address) because functionality,

such as launch-in-context remote control or power operations, are only available when the
management module has been discovered out of band.
Agentless hardware monitoring might not include certain event types from internal devices
such as Redundant Array of Independent Disks (RAID) adapters or Peripheral Component
Interconnect (PCI) controllers. These require additional CIM modules, which are included
only with the Platform Agent (the Common Agent includes the Platform Agent).
Unless you have a requirement to monitor operating system resources and processes with
IBM Systems Director, and you do not have a requirement to get extended events from
certain internal devices such as RAID controllers and PCI cards, and if you are not
planning on using VMControl with your Microsoft Hyper-V or Linux KVM hosts, agentless
is probably the best option to start with for Windows and Linux servers.
Agentless is your only option for managing VMware vSphere ESXi hosts. You should not
attempt to discover ESXi hosts directly. Instead, you need to discover your vCenter Server
endpoint as described in section 5.4, Managing VMware vSphere with VMControl on
page 282.
On Linux, agentless access can be configured with the sudo utility, as shown at the
following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.install.
helps.doc/fqm0_t_setting_up_access_to_agentless_systems.html
If the credentials that you used to unlock access for your agentless endpoint change (for
example, when your password expires or is changed), you have to manually update those
credentials in IBM Systems Director to recover access to your agentless endpoints. Go to
Actions Security Configure Access to do this action.
Inventory after an agentless discovery creates a server MEP object. This should not be
confused with the management module, which requires out-of-band discovery.
Platform Agent
Platform Agent is the lightweight agent that is installed on Windows or Linux systems that
provides everything that agentless management provides. Platform Agent also provides
additional operating system level monitoring.
For more information about Platform Agent systems, go to the following site:
r.main.helps.doc%2Ffqm0_c_platform_agent.html
The following scenarios should be considered when you think the Platform Agent is right for
you:
If you have Microsoft Hyper-V or Linux KVM hosts that you are planning to manage with
IBM Systems Director VMControl, the Platform Agent is required.
If you need to monitor operating system processes or resource utilization using operating
system performance library objects, the Platform Agent is also required. See Table 2-22
on page 29 for a list of supported operating system monitors for the Platform Agent.
The Platform Agent includes additional CIM providers that include additional hardware
events from components such as internal RAID adapters or PCI cards.
Note: Previous versions of IBM Systems Director require the installation of a separate
RAID management software. CIM providers for IBM hardware RAID controllers are now
included with the Platform Agent.
Chapter 2. Planning
27
If the credentials that are used to unlock access to the Platform Agent change, you have to
request access again to unlock the CIM protocol. Until you do that, managed endpoints
show only partial access.
The Platform Agent is required if you are planning on using Storage Management with
your managed endpoints.
Common Agent
The Common Agent provides everything that the Platform Agent offers (it includes the
Platform Agent code) and adds functionality. It can monitor the operating system
performance, services, and processes.
For more information about Common Agent systems, go to the following site:
r.main.helps.doc%2Ffqm0_c_common_agent.html
Consider the following factors when you think the Common Agent is right for you:
The Common Agent uses more hardware resources than the Platform Agent and has a
larger footprint. This might not be an issue for most environments where physical servers
are under-utilized, but it is nevertheless something to keep in mind. If you are concerned
with resource utilization, ensure that you plan for benchmarking to determine the exact
impact that the Common Agent will have in your environment.
Systems running the Common Agent can be managed only by a single Common Agent
server. This means that an endpoint running the Common Agent can be managed only by
a single IBM Systems Director server.
You can install the Common Agent on top of the platform agent by using IBM Systems
Director release management capabilities.
You should manage AIX systems using the Common Agent.
You should avoid using the Common Agent when you are already using the IBM Tivoli
Monitoring agent because a Common Agent can be managed only by one Common Agent
server. If you must use both Common Agents (Tivoli and IBM Systems Director), it might
require special configuration, as documented at the following site:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W3e8d1c9
56c32_416f_a604_4633cd375569/page/Coexistence+of+Director+V6+CAS+Agent+with+oth
er+Tivoli+CAS+Agents
Using the Common Agent on non-IBM hardware requires additional licensing (IBM
Systems Director server comes with 20 licenses only for non IBM hardware). For more
information, go to the following site:
helps.doc/fqm0_t_obtaining_licenses.html
If you need to monitor operating system processes or resource utilization using operating
system performance library objects, the Platform Agent is also required. See Table 2-22
on page 29 for a list of supported operating system monitors for the Common Agent.
The Manage Processes and Process Monitors actions are only available with the Common
Agent.
The Common Agent is not affected if the credentials used to unlock the endpoint change.
This is because the Common Agent uses its own credentials after the endpoint has been
initially unlocked.
28
Agent capabilities
The IBM Systems Director Information Center helps you choose the level of agent capabilities
to deploy on managed systems:
r.plan.helps.doc%2Ffqm0_t_agent_tiers.html
The preceding link also contains additional links that show, per platform, what type of
functionality each agent provides.
Table 2-22 shows the agent capabilities for the Windows platform.
Table 2-22 List of available Windows Server 2008 R2 monitors by agent type
Monitor
Agentless
Platform Agent
Common Agent
CPU% Utilization
No
Yes
Yes
Disk Space Remaining
No
Yes
Yes
Memory Usage
No
Yes
Yes
Primary File System

Percent Space
Available
No
Yes
Yes
Process Count
No
Yes
Yes
Disk Workload
No
No
Yes
Disk Space Used
No
No
Yes
IP Packets Received
with Errors/sec
No
No
Yes
IP Packets
Received/sec
No
No
Yes
IP Packets Sent/sec
No
No
Yes
Locked Memory
No
No
Yes
Primary File System

Percent Space Used
No
No
Yes
TCP Connections
No
No
Yes
UDP Datagrams
Received/sec
No
No
Yes
UDP Datagrams
Sent/sec
No
No
Yes
If you are still unsure which agent you need, list your requirements and then plan to test
functionality starting from agentless and working your way up to the Platform Agent and then
the Common Agent.
Chapter 2. Planning
29
2.7.2 Determine how to deploy your agents

After you have decided which type of agent to use on your systems, you need to select the
best way to install the agents.
The following options are available to install the agents:
Install the platform or Common Agent manually on your systems using binary packages,
then register them on your IBM Systems Director server. This is desirable when you have
multiple distributed locations with limited wide area network (WAN) capabilities.
The main downside of deploying agents in this manner is that it requires additional labor
because agent installation has to be performed endpoint by endpoint. In addition,
installation packages have to be manually copied to each endpoint.
Include the Platform or Common Agent that is installed in your gold image and register
them later on your IBM Systems Director server.
Again, this may be the best choice in distributed environments. Cloning pre-installed IBM
Systems Director agent instances requires additional steps as documented in the
Information Center:
ctor.discovery.helps.doc%2Ffqm0_t_discovering_systems_mirrored_image.html
The main disadvantage of doing this is that it requires additional configuration and
therefore additional labor. Also, the agent version may quickly become outdated, requiring
an update of the gold image.
Discover all of your systems that are agentless, then use the Release Management and
Agent Installation wizard from your IBM Systems Director console.
This is the preferred method because it helps ensure that up-to-date agents are properly
deployed, configured, and registered. You can also do it on multiple systems concurrently,
if your local or wide area network can handle the load.
This method can also be used to upgrade a Platform Agent to a Common Agent. You
cannot use central management to uninstall agents.
2.7.3 Determine if you should run Systems Director server in a virtual machine
Keep in mind the following factors when selecting a server platform for running your IBM
Systems Director server instance:
The best way to run IBM Systems Director server is in a virtual machine. If your virtual
machine is correctly sized (see 2.1, System resources on page 8), running IBM Systems
Director in a virtual machine will not affect overall performance or functionality.
There is no real high-availability solution for IBM Systems Director server. If you run it on a
physical server platform, it might be more difficult to restore service quickly, whereas
virtual infrastructure usually includes automated protection against hardware failure.
If you run IBM Systems Director in a virtual machine, keep in mind that the license
agreement requires that the underlying physical server that runs the hypervisor must be
IBM server hardware. For example, if you have a multivendor cluster, this might require
that you implement host affinity rules.
30
Always plan to install the IBM Systems Director server instance into its own file system (as
opposed to installing it in the same file system partition as the operating system). It is
difficult to predict file growth with IBM Systems Director, especially when problems occur
and multiple Java core dumps or log files are generated. Although this happens less
frequently than with previous releases, it is still a potential risk and thus an IBM Systems
Director instance should be isolated from other applications file systems.
2.7.4 Determine what type of database to use with Systems Director server
IBM Systems Director server 6.3.2 comes with an embedded full unlimited version of IBM
DB2 for exclusive use by IBM Systems Director. This means that there is no reason to
consider using an external database. For more information about database selection, go to
the following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.plan.helps.
doc/fqm0_t_selecting_the_ibm_director_database_application.html
Note: If you are planning on using Storage Control, you cannot use Microsoft SQL Server
or Oracle as your database management system (DBMS) for IBM Systems Director. The
embedded DB2 or an external DB2 server are your only options.
2.7.5 Determine the networks that your server should be connected to

Depending on the type of traffic, some environments might require network separation. For
example, your company policy may require separate networks for out-of-band management
modules (such IMM or AMM), system management traffic (such as remote connections or
monitoring), and production data (where applications and user traffic are located).
In these types of environments, where should you place the IBM Systems Director server
primary network interface?
The answer depends on how you manage your infrastructure. For example, if you are
planning on managing your hardware using only out-of-band management modules, it might
be better to install your IBM Systems Director server in the management module network
segment.
In most cases, your Systems Director has its primary interface in the administration network
segment and also requires connectivity to the management module network segment (either
directly via a secondary interface, which is the preferred method, or through a firewall).
Warning: Service Location Protocol (SLP) discovery through firewalls can be tricky and
requires special configuration, as documented at the following site:
ps.doc/fqm0_r_ports_considerations.html
In general, your IBM Systems Director should not require network connectivity to the
production network because it should be considered as a system management platform.
However, if you need to restrict IBM Systems Director traffic to a single network interface, this
is only supported on Windows and requires specific configuration, as documented at the
following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.agent.helps
.doc/fqm0_t_binding_pa_specific_ip_addresses.html
Chapter 2. Planning
31
Finally, if you are planning on using the Update Manager functionality of IBM Systems
Director (which enables firmware updates for your managed endpoints), Internet connectivity
(either direct or through a proxy server) is highly desirable because you would otherwise have
to manually import all applicable updates.
2.7.6 Determine how to make your solution highly available

There is no specific solution for making IBM Systems Director highly available. The best
strategy to enhance availability is to take advantage of your infrastructure capabilities (such
as HA and DRS clusters if you run your IBM Systems Director server in a VMware virtual
machine) to protect the IBM Systems Director instance from hardware failure.
In addition, you should have a backup strategy for your IBM Systems Director server as
highlighted in 4.7, Backup on page 233.
2.7.7 Determine how to deal with distributed environments

Previous versions of IBM Systems Director had a hierarchical management server (HMS)
functionality built-in because it was not reliable enough and did not scale well. Support for
HMS has been dropped from the product.
This means that if you have a large distributed environment (for example, you are a retailer
with hundreds of remote stores that have servers you want to be able to monitor and update),
consider the following factors:
If you have a few managed endpoints (less than 10) in each location and you are not
planning on using Update Manager (for firmware or agent updates) for your remote
locations, even a modest wide area network bandwidth may be enough to support basic
hardware monitoring functions from a central IBM Systems Director server instance in
your data center.
If you are planning on using Update Manager, plan to have at least 10 Mbps of network
bandwidth because some of the update packages can be fairly large (several hundred MB).
If you have many managed endpoints and are planning to use Update Manager and do
not have 10 Mbps or more of network bandwidth, have a local IBM Systems Director
server instance, which will have to be managed on its own.
Note: Most firmware updates and agent update packages can also be distributed because
any other software packages using an alternative software distribution solution might be
more suitable to distributed environments.
2.8 Best practices

To summarize, consider the following best practices when planning for IBM Systems Director:
If it covers your requirements, prefer agentless systems because they prevent you from
having to keep agents up to date. This recommendation is only applicable if you have a
System x server without any internal storage with configured out-of-band management
modules.
Plan to use privileged credentials with a non-expiring password for agentless endpoints.
Otherwise, you have to manually update all existing credentials endpoint by endpoint
every time that the password is changed or when it expires.
32
If you cannot use non-expiring privileged credentials, use domain credentials. When the
domain credentials change, revoke access to all managed endpoints by using those
credentials, then request access and enter the new credentials.
Whenever possible, deploy agents centrally from the IBM Systems Director server
console. This ensures that you have registered properly and have up-to-date endpoints.
Run IBM Systems Director server in a virtual machine. This helps enhance availability of
the service.
Use +16 GB RAM and four CPU cores or four vCPUs as best practice or for performance
of the IBM Systems Director server.
Use the embedded DB2 database because it has no limitations (as opposed to previous
versions of IBM Systems Director). A local database helps with overall performance and
reduces complexity.
Always discover management modules out of band, even if they have already been
discovered in band because this unlocks key functionality.
Plan for Internet connectivity for your IBM Systems Director server so that it can retrieve
updates directly from the web.
For distributed environments, plan to use IBM Systems Director only for hardware
monitoring and leverage your existing software distribution solution to push agent and
firmware updates.
Use the Workload Estimator to get basic figures for the system running Systems Director.
When possible, use one of the more advanced IBM Systems Director Editions. This
provides, in addition to the IBM Systems Director and the Advanced Manager software, a
Service and Support offering (SWMA) for one or three years. Choose the edition that best
suits your requirements and your environment.
Open the necessary firewall ports in your environment for IBM Systems Director server
and managed endpoints.
Verify that the Domain Name System (DNS) functions correctly for both forward and
reverse lookup.
Chapter 2. Planning
33
34
Chapter 3.
Installation
This chapter provides information and best practices for installing IBM Systems Director
server on different platforms.
The following topics are covered:
3.1, Installation of IBM Systems Director server on an x86 platform on page 36
3.2, Installing IBM Systems Director server on an AIX platform on page 57
3.3, Installation of IBM Systems Director server for a Linux on Power platform on
page 68
3.4, Installation of the IBM Systems Director agent on Linux x86 on page 73
35
3.1 Installation of IBM Systems Director server on an x86

platform
The IBM Systems Director server runs on a Windows or Linux platform on x86 systems, but
only on hardware that is branded IBM (a license requirement). The IBM Systems Director
Information Center has a complete list of all supported hardware at the following site:
r.plan.helps.doc%2Ffqm0_r_hardware_compatibility.html
One way to use IBM Systems Director on x86 is to install the IBM Systems Director server on
a virtual machine under the control of a hypervisor, such as VMware ESX or Linux
Kernel-based Virtual Machine (KVM). A virtual machine offers advantages that make it a
useful installation method:
Hardware independence of certain components and drivers.
Simple extensibility of resources (memory and processor allocation).
The ability to perform snapshots before the installation of plug-ins and advanced
managers.
When you use a virtual machine, configure four vCPUs and 16 GB or more of memory. The
disk drive size depends on the number of systems and the database that is used for the IBM
Systems Director installation.
3.1.1 Supported operating systems

The IBM Systems Director server is supported on the following operating system versions
that run on IBM x86 servers (the values with an * indicate enhancements that are coming with
IBM Systems Director Version 6.3.3):
Linux 32-bit:
Red Hat Enterprise Linux Advanced Platform, Version 5.0 (supports Updates 1, 2, 3, 4,
5, 6, 7, 8, and 9*)
Red Hat Enterprise Linux, Version 5.0 (supports Updates 1, 2, 3, 4, 5, 6, 7, 8, and 9*)
Red Hat Enterprise Linux Advanced Platform, Version 6.0 (supports Updates 1, 2, 3,
and 4*)
Red Hat Enterprise Linux, Version 6.0 (supports Updates 1, 2, 3, and 4*)
SUSE Linux Enterprise Server 10 for x86 (supports Service Packs 1, 2, 3, and 4)
SUSE Linux Enterprise Server 11 for x86 (supports Service Packs 1 and 2)
Linux 64-bit:
Red Hat Enterprise Linux Advanced Platform, Version 5.0, for AMD64 and EM64T
(supports Updates1, 2, 3, 4, 5, 6, 7, 8, and 9*)
Red Hat Enterprise Linux, Version 5.0, for AMD64 and EM64T (supports Updates 1, 2,
3, 4, 5, 6, 7, 8, and 9*)
Red Hat Enterprise Linux Advanced Platform, Version 6.0, for AMD64 and EM64T
(supports Updates 1, 2, 3, and 4*)
Red Hat Enterprise Linux, Version 6.0, for AMD64 and EM64T (supports Updates 1, 2,
3, and 4*)
SUSE Linux Enterprise Server 10 for AMD64 and EM64T (supports Service Pack 1, 2,
3, and 4)
36
SUSE Linux Enterprise Server 11 for AMD64 and EM64T (supports Service Packs 1
and 2)
Windows 32-bit:
Windows Server 2003, Enterprise, and Standard Editions, Release 2 (supports SP 2)
Windows Server 2003, Enterprise, and Standard Editions (supports SP 2)
Windows Server 2008, Enterprise, and Standard Editions (supports SP 1 and SP 2)
Windows 64-bit:
Windows Server 2003, Enterprise, and Standard x64 Editions, Release 2 (supports
SP 2)
Windows Server 2003, Enterprise, and Standard x64 Editions (supports SP 2)
Windows Server 2008, Enterprise, and Standard x64 Editions (supports SP 1 and
SP 2)
Windows Server 2008, Enterprise, and Standard x64 Editions, Release 2 (with or
without SP 1)
A detailed list of supported operating systems for the IBM Systems Director server and
agents is available at the following site:
r.plan.helps.doc%2Ffqm0_r_os_supported_by_ibm_director_631.html
You can install IBM Systems Director on a guest OS that runs on a virtualized environment.
The supported guest operating systems are supported by both IBM Systems Director and the
hypervisor. The following conditions must be true:
The OS platform is supported by IBM Systems Director.
The OS platform is supported as a guest OS by a hypervisor.
The hypervisor is supported by IBM Systems Director.
With these three conditions, IBM Systems Directors support of the OS platform extends to
running it as a guest OS on that hypervisor. See the hypervisor product documentation for a
list of supported operating systems.
The following hypervisors for the x86 environment are supported:
VMware ESX 4.0.x and 4.1.x

VMware ESXi 4.0.x and 4.1.x (under the control of VMware vCenter)
VMware vSphere 5.0.x and 5.1.x (under the control of VMware vCenter)
Linux KVM
Windows Server 2012 and Windows Server 2008 and 2008R2, Enterprise, Standard, and
Datacenter x64 Editions with Hyper-V role-enabled
Required resources: The IBM Systems Director server is only supported on hardware
that is branded IBM. Therefore, the hypervisor must run on IBM hardware to meet the
license requirements.
Resources that are required for running the IBM Systems Director server are referenced in
section 2.1, System resources on page 8; 2.2, IBM Systems Workload Estimator on
page 9; and section 2.3, Before you begin on page 15.
Chapter 3. Installation
37
If you run firewalls in your environment, ensure that the necessary ports for the IBM Systems
Director server are open. A list of the TCP/IP ports that are used by the IBM Systems Director
server can be found at the following site:
r.plan.helps.doc%2Ffqm0_r_ports_for_the_management_server.html
3.1.2 Installation of Linux on x86 systems

For the installation, complete the following checks before the installation of IBM Systems
Director. These checks can be completed in any order:
Sizing
The IBM Systems Workload Estimator for IBM Systems Director 6.3 is a web-based tool.
This tool provides hardware sizing suggestions for systems that run the IBM Systems
Director server. Launch the Workload Estimator from the following site:
Required libraries and packages for Linux on System x
Table 3-1 lists the required libraries to install IBM Systems Director 6.3.2 on Linux.
Tip: SLES11 installs all required packages and libraries, by default.
Table 3-1 Required libraries for Linux on x86
38
Linux distribution
Management server
Common Agent
Platform Agent
RHEL
openssh
libstdc++.so.5
libm.so.6
libgcc_s.so.1
libc.so.6
libdl.so.2
libpthread.so.0
unzip
libaio
libcrypt.so.1
libnsl.so.1
libpam.so.0
librt.so.1
bind-utils
net-tools
libstdc++.so.6
libuuid.so.1
libexpat.so.0
libcrypt.so.1
libc.so.6
libdl.so.2
libstdc++.so.5
libgcc_s.so.1
libm.so.6
libnsl.so.1
libpam.so.0
libpthread.so.0
librt.so.1
unzip
bind-utils
net-tools
libstdc++.so.6
libuuid.so.1
libexpat.so.0
libstdc++.so.5
bind-utils
net-tools
libpam.so.0
libstdc++.so.6
libuuid.so.1
libcrypt.so.1
unzip
libexpat.so.0
Linux distribution
Management server
Common Agent
Platform Agent
SLES10
SLES11
openssh
libstdc++.so.5
libm.so.6
libgcc_s.so.1
libc.so.6
libdl.so.2
libpthread.so.0
unzip
libaio
libcrypt.so.1
libnsl.so.1
libpam.so.0
librt.so.1
bind-utils
net-tools
libstdc++.so.6
libuuid.so.1
libexpat.so.1
libcrypt.so.1
libc.so.6
libdl.so.2
libstdc++.so.5
libgcc_s.so.1
libm.so.6
libnsl.so.1
libpam.so.0
libpthread.so.0
librt.so.1
unzip
bind-utils
net-tools
libstdc++.so.6
libuuid.so.1
libexpat.so.1
libstdc++.so.5
bind-utils
net-tools
libpam.so.0
libstdc++.so.6
libuuid.so.1
libcrypt.so.1
unzip
libexpat.so.1
The libraries that are listed in Table 3-1 on page 38 can be installed in RedHat Linux by
installing the following packages:
compat-libstdc++-33.i686
libstdc++-4.4.6-4.el6.i686
zlib-1.2.3-27.el6.i686
pam-1.1.1-10.el6_2.1.i686
compat-expat1-1.95.8-8.el6.i686
In addition, fulfill the following steps on your RedHat installation:

1. Disable SE Linux:
# vi /etc/selinux/config
SELINUX=DISABLED
2. Disable IP tables:
# service iptables stop
# chkconfig --level 0123456 iptables off
As a best practice, disable the local firewall (iptables) to avoid heavy configuration with
iptables. But if your security standards require that you have iptables up and running,
configure it with all of the ports that are listed in section 2.5, Firewall ports on page 19.
Detailed steps for installation on Linux for x86

Use the following steps to install the IBM Systems Director server on Linux on x86:
1. Download the installation package from the IBM Systems Director downloads, which are
available at the following website:
http://ibm.com/systems/software/director/downloads/mgmtservers.html
2. Extract the contents of the installation package with the following command:
tar -zxvf package_name
The package_name is the file name of the download packages. Alternatively, you can mount
the DVD image to your system.
39
3. Change to the directory of the installation script. Use the following command to run the
pre-installation check:
../checkds/./checkds.sh
Reports are generated and results are displayed in the command window or the default
browser. For more information, see the /checkds/readme.txt file.
When the result shows no errors (return code= 0) or you can explain the error message
that is displayed, continue with the installation.
In this example, an error code/return code of 34 was returned. The IBM Systems Director
server is installed on a virtual system. No baseboard management controller (BMC) or
Intelligent Peripheral Management Interface (IPMI) driver is installed. Figure 3-1 on
page 41 shows the output from the pre-installation check in the browser.
40
Figure 3-1 Pre-installation check result
41
If you run your system from the command line, the report is in text format and looks similar
to the output in Figure 3-2.
Java:
/isd632/standard_linux_x86_Director_base/server/checkds/jvm/xlinux/bin/java
Starting IBM Systems Director Pre-Installation Utility...
Finished analysing system
Creating reports...
Install Readiness Text report being written to
/tmp/checkds/reports/checkDS_Text_20121214_174936.txt
Install Readiness Error Text report being written to
/tmp/checkds/reports/checkDS_Error.txt
Install Readiness Detailed HTML report being written to
/tmp/checkds/reports/checkDS_Detailed_20121214_174936.html
Install Readiness Summary HTML report being written to
/tmp/checkds/reports/checkDS_Summary_20121214_174937.html
Your system is currently showing warnings for 1 of 21 checks.

WARN Check 10 IPMI Status
IPMI status could not be determined; error returned from native environment request.
The system you are installing may not have the IPMI (Intelligent Platform Management
Interface) kernel modules or maynot have a BMC (Baseboard Management Controller).
You may not receive certain hardware events.
Overall Report Return Code: 34
Figure 3-2 Text output from the pre-installation utility
If recommendations or errors exist, you must address them before you can continue the
installation. For information about the problems, see the report. After the problems are
fixed, run the pre-installation check again.
4. To install the IBM Systems Director server, from within the directory of the installation
script, use one of the following commands:
To accept the default settings, enter this command:
./dirinstall.server
To use the response file, enter this command:
./dirinstall.server -r /directory/response.rsp
The directory is the local directory to which you copied the response file and
response.rsp is the name of the response file.
To force a clean installation, regardless of the existing data, enter this command:
./dirinstall.server -g
42
Tip: If you previously installed IBM Systems Director on this system, data is saved in
the /var/tmp/director_save_630 directory, by default. The data is not removed even
if you uninstall the previous installation. If you want a clean installation, use
./dirinstall.server -g to ensure that you do not inadvertently migrate this data.
IBM Systems Director 6.3.x installs cleanly and the data from the previous
installation is preserved.
5. The installation runs now with the default setting or with the settings from the response file.
If you use the default integrated DB2 database, the installation automatically creates the
settings to use DB2. If you use another supported database, you must configure the
database for use with IBM Systems Director.
For information about how to configure these databases, go to the following site:
ctor.configdir.helps.doc%2Ffqm0_t_config_database_application_cfgdbcmd.html
6. When the license agreement displays, confirm that you accept this agreement by entering
1. The Pre-Installation Utility runs. In Figure 3-3, return code 34 is returned, indicating that
no IPMI driver is installed. However, because the installation occurs in a virtual
environment, this is not a problem. Enter 1 to continue as shown in Figure 3-3.
Sles11:/ # ./tmp/isd632/server/dirinstall.server
Agree to product licence?
[1-Agree | o-Disagree]: 1
IBM Systems Director 6.3.2 installation
.....
Starting IBM Systems Director Pre-Installation Utillity ...
.....
Overall Report return Code:34
For more detaiuls see the files under /tmp/checkds
[1-Continue | 0-Abort]: 1
....
Figure 3-3 Running dirinstall.server script
7. The Director server, components, features, and embedded DB2 database are installed.
When the installation completes, a message appears similar to the message shown in
Figure 3-4.
...
Installation of the IBM Systems Director Server 6.3.2 succeeded
To start the server manually, run /opt/ibm/director/bin/smstart
To see the status, run /opt/ibm/director/bin/smstatus [-r]
Sles11:/ #
Figure 3-4 Completing the IBM Systems Director installation
8. After the installation completes, configure the Agent Manager and then start the IBM
Systems Director.
Important: Do not start the IBM Systems Director before you configure the Agent
Manager.
43
9. To configure the Agent Manager (if you did not configure it during the installation process),
run the following command:
install_root/bin/configAgtMgr.sh
10.Respond to the configAgtMgr.sh script prompts:
Agent Manager
Enter 1 to use the Agent Manager that is installed with this server (suggested), or enter
0 to use an existing Agent Manager (advanced).
Resource Manager
Enter the Resource Manager user ID that you want to set for the Agent Manager. The
user ID does not need to be an operating system user ID. Remember this user ID. If
you want to use the same Agent Manager with another system, you need this user ID.
Enter and verify the Resource Manager password to set for the Agent Manager.
Agent Registration password
Enter and verify the Agent Registration password to set for your Agent Manager. This
password can be the same password for the Agent Manager. This password is used to
register the Common Agents with Agent Manager.
IP address and port for Agent Manager:
Enter the IP address for the existing Agent Manager.

If you selected 0 (use an existing Agent Manager), you must provide the IP address
of the existing Agent Manager.
Enter the port number for the existing Agent Manager.

If you selected 0 (use an existing Agent Manager), you must provide the port
number of the existing Agent Manager. The port number must be a valid number
0 - 65535.
11.Start IBM Systems Director processes on the management servers by running the
smstart command:
install_root/bin/smstart
12.To check the status of the IBM Systems Director, run the following command:
install_root/bin/smstatus -r
When this command returns a value of Active, the server is started and active.
3.1.3 Installation on Windows

Use the following steps to install the IBM Systems Director server on a Windows server:
1. Download the installation package from the following link and decompress it:
http://ibm.com/systems/software/director/downloads/mgmtservers.html
2. Double-click the IBMSystemsDirectorServerSetup64.exe file to start the installation
process.
44
3. The pre-installation check runs. If the check runs successfully, a green mark and the No
warnings or errors were found message displays (Figure 3-5). Click Next to continue. If
problem and error messages appear, fix them, return to this window, and run the
installation program again.
Figure 3-5 Welcome to the InstallShield wizard for IBM Systems Director server 6.3.2
4. Agree to the license agreement and click Next to continue.

5. Specify the folder where you want to install the software (Figure 3-6) and click Next to
continue.
Figure 3-6 Feature and installation directory selection
45
6. In the next window (Figure 3-7), select the installation type. Two types are available:
Click Basic to use the embedded database and default ports and install the Common
Agent Services (CAS) server with the Director installation. You type the user ID and
password only one time. The installation program uses the user ID and password for all
settings.
Click Advanced if you want to use a database other than the embedded, managed
DB2. Also, if you install a second IBM Systems Director server in your environment,
use the Advanced setup to select the existing CAS server. With the Advanced setup,
you can define a different user ID and password for the CAS server. With the Advanced
setup, you can use different default ports for the IBM Systems Director server.
This installation uses the Basic setup type. Click Next to continue.
Figure 3-7 Setup type
46
7. Type in the credentials that you want to use for the IBM Systems Director server: computer
name, user name, and password (Figure 3-8). Click Next to continue.
Figure 3-8 User credentials
8. When you are ready to begin the installation process, click Install (Figure 3-9).
Figure 3-9 Ready to Install the Program window
47
9. The IBM Systems Director server database is installed. You can see the progress of the
installation process (Figure 3-10).
Figure 3-10 Installing the IBM Systems Director server
48
10.The IBM Systems Director Common Agent is installed next (Figure 3-11).
Figure 3-11 Install Common Agent and Common Agent services
49
11.The IBM Systems Director Platform Agent packages are installed (Figure 3-12).
Figure 3-12 Platform Agent installation
12.The files for the IBM Systems Director server are installed (Figure 3-13).
Figure 3-13 Installing the IBM Systems Director server
50
13.Additional features and plug-ins are installed (Figure 3-14).
Figure 3-14 Installing features and plug-ins
14.The Agent Manager (CAS server) is installed (Figure 3-15).
Figure 3-15 Installing Agent Manager
51
15.When the installation completes, the InstallShield Wizard Completed window displays
(Figure 3-16). You can view the Windows Installer log. Complete the installation by clicking
Finish.
Figure 3-16 InstallShield Wizard Completed window
After the installation is finished, the IBM Systems Director server starts automatically. You can
check the status of the IBM Systems Director server through the status icon or by using the
smstatus -r command. When the status icon shows a green circle or the status shows as
active, the IBM Systems Director server is up and running.
3.1.4 Post Installation Validation tool

With IBM Systems Director 6.3.2, IBM provides the new Post Installation Validation (PIV) tool.
This tool can be run after the installation process to check the installation for completeness
and errors. The tool is in the /piv folder in the installation medium or directory.
The PIV analyzes the installation logs for errors and checks for services, ports, Agent
Manager configuration, and database configuration. The PIV also checks whether the server
is active by using the smstatus command.
The PIV tool is small (less than 5 MB). The PIV tool is written in Python and includes a small
Python interpreter. (Python must be installed on the system to run PIV.) PIV is not a health
checker for a running IBM Systems Director; it is only a tool to verify the installation.
The tool is a command-line tool and is run in the following way:
Linux on x86:
<Install_directory>\bin\piv> .\PostInstallValidator_xLin.sh
Windows:
<Install_directory>\bin\piv> .\PostInstallValidator_Win.exe
Command options are available. You can see the full list of command-line options by using
the -h option.
52
The following command options are the most important options:

-o
-c
-s
-r
-j
-d
-w
or --output
Specify the location of the installation report
or --config
Specify the location of the configuration file
or --silent
Run the tool silently
or --report
Open the text report on completion (Windows only)
or --nohtmlreport Do not create an HTML report
or --detailed
Include detailed information in the report
or --wait
Wait to return until the installation is completed
The tool generates a report. If a graphical user interface (GUI) is available, you receive an
HTML report (if not, clear by using the -j option). If only a command-line environment is
available, you receive a text report.
The reports are in the following directories, by default:
Linux/AIX reports are in the /tmp directory.
Windows reports are in the %temp% directory.
The PIV HTML report looks similar to the example of the installation in Windows Server 2008
R2 x64 (Figure 3-17 on page 54).
53
Figure 3-17 PIV HTML report
54
The text report looks similar to the report shown in Figure 3-18.
Figure 3-18 PIV text report
3.1.5 Starting IBM Systems Director

The IBM Systems Director automatically starts after the installation. No reboot of the system
is necessary. You can start and stop the IBM Systems Director server using the command
line. The command line is the best method because all necessary services are started and
stopped in the correct sequence.
Use the following commands to start or stop IBM Systems Director:
Linux:
smstart to start the IBM Systems Director server
smstop to stop the IBM Systems Director server
Windows
net start dirserver to start the IBM Systems Director server
net stop dirserver to stop the IBM Systems Director server
Initial logon
After the IBM Systems Director server is in the active status, use the following steps to log on
to the IBM Systems Director web interface.
1. Open your browser and type in the following address:
http://hostname_or_IP_address:8421/ibm/console/logon.jsp
or
https://hostname_or_IP_sddress:8422/ibm/console/logon.jsp
55
2. At the first access, a window opens to show you that the connection is untrusted
(Figure 3-19). Click Add Exception.
Figure 3-19 Untrusted connection
3. A new window opens (Figure 3-20). Click Confirm Security Exception.
Figure 3-20 Confirm security exception
56
4. The login window displays (Figure 3-21). Enter your user ID and password and click Log
in.
Figure 3-21 Logon window
3.2 Installing IBM Systems Director server on an AIX platform

Useful information is provided about the process of installing IBM Systems Director on an AIX
platform. Resources that are required for running the IBM Systems Director server are
referenced in section 2.1, System resources on page 8, and section 2.2, IBM Systems
Workload Estimator on page 9.
For the installation of IBM Systems Director on AIX, go to the following site:
http://publib.boulder.ibm.com/infocenter/director/pubs/topic/com.ibm.director.inst
all.helps.doc/fqm0_t_installing.html
The IBM Systems Director Management Server code can be sourced from this site:
http://www-03.ibm.com/systems/software/director/downloads/mgmtservers.html
3.2.1 Downloading the software

The IBM Systems Director source can be downloaded in two formats: an .iso file or a GZIP
(.gz) file. Download your preferred file type and place it in a temporary file system on the AIX
server using one of the following commands:
ISO:
loopmount -i express_aix_Director_base.iso -o -V cdrfs -o rw -m /mnt
GZIP:
gunzip -c express_aix_Director_base.tar.gz | tar -xvf -
57
The installation of the IBM Systems Director server comes with an embedded pre-installation
check utility. This option is enabled, by default, and is referenced in the dirserv.rsp file. The
suggestion is to leave the pre-installation check enabled, which is the default (Figure 3-22).
Variables will be used during the installation:
PRE_INSTALL_CHECKS : 1
Figure 3-22 Pre-installation checks are enabled by default in the dirserv.rsp file
The preferred practice is to also run the checkds utility before you run dirinstall.server.
The checkds.sh script is in the server folder:
/mnt/server/checkds/checkds.sh
On successful completion of the checkds script, proceed with the installation.
3.2.2 Prerequisites
For the installation, complete the following checks in any order before the installation of IBM
Systems Director.
Yellow pages
Ensure that the yellow pages group is not running and is in an inoperative state (Figure 3-23).
Otherwise, the embedded DB2 for the IBM Systems Director server does not install
successfully.
-bash-3.2# lssrc -s ypbind
Subsystem
Group
ypbind
yp
PID
Status
inoperative
Figure 3-23 Yellow pages
OS level
Check that the OS level of the AIX server is supported:
http://publib.boulder.ibm.com/infocenter/director/pubs/topic/com.ibm.director.plan
.helps.doc/fqm0_t_planning_to_install_ibm_director_server.html
ulimits
Ensure that the fsize setting is set to unlimited because fsize determines the maximum
allowable file size. See Figure 3-24.
vi /etc/security/limits
default:
fsize = -1
Figure 3-24 ulimits
The IBM Systems Director installation file is larger than 2 GB. Log out of the terminal session
to activate the fsize changes.
58
Required installation files

Ensure that the filesets for AIX are installed for Secure Shell (ssh) and Secure Sockets Layer
(ssl) at the following level or greater. See Figure 3-25.
-bash-3.2# lslpp -L | egrep "ssh|ssl"
openssh.base.client
5.0.0.5302
openssh.base.server
5.0.0.5302
openssh.license
5.0.0.5302
openssl.base
0.9.8.801
openssl.man.en_US
0.9.8.1800
-bash-3.2#
C
C
C
C
C
F
F
F
F
F
Open
Open
Open
Open
Open
Secure
Secure
Secure
Secure
Secure
Shell Commands
Shell Server
Shell License
Socket Layer
Socket Layer
Figure 3-25 ssh/ssl filesets
Check that no previous installation of IBM Systems Director exists (Figure 3-26). If a previous
installation exists, uninstall it.
lslpp -l | egrep -i directorserver|directorcomm|directorplat|cimserver|cas
Figure 3-26 lslpp check
If file sets from a previous installation are returned or for the file sets that are listed in
Figure 3-25, remove the associated files (Figure 3-27).
installp -ug DirectorServer DirectorCommonAgent DirectorPlatformAgent cas.rte
sysmgt.cimserver.pegasus.rte
Figure 3-27 installp -ug
If a service is locked and cannot be removed, use the lsof or rmsock command to determine
which port or file prevents the removal of the associated files. Then, remove the file systems
that are associated to the files (Figure 3-28).
rm -rf /opt/ibm/director
rm -rf /opt/ibm/icc
rm -rf /opt/ibm/tivoli
Figure 3-28 folder removal
Note: It is not compulsory to remove the file sets that are referenced with the -ug option.
However, by removing these file sets, you eliminate any issues with previous installations
for agents or the server, which leads to a smoother installation.
Volume groups
The suggestion is to leave root volume group (rootvg) primarily for the operating system.
Create a separate volume group for the additional storage that is required for IBM Systems
Director on an alternate disk. By keeping rootvg lean and clean, you can recover more easily.
The IBM Systems Director server recovery is described in 4.7, Backup on page 233.
59
Because the DB2 installation is restricted, the DB2 installation path is also restricted
(Figure 3-29).
/home/dirinst1
/opt/ibm/director/db2
Figure 3-29 DB2 default paths
Changing this path to an alternate path for the system backup and restoration of rootvg is
beneficial (Figure 3-30).
mklv -y isddb2 -t jfs2 rootvg 10G
crfs -v jfs2 -d isddb2 -m /isddb2 -A yes
mount /isddb2
Figure 3-30 Changing the path
Tip: This installation has only one disk. It is advisable to have n+1 and to mirror the volume
groups that are associated to the disks. Repeat the commands in Figure 3-30 for
/opt/ibm/director on the alternate volume group if you want.
The checkds script looks for 3 GB or greater of paging space (Figure 3-31).
-bash-3.2#
Page Space
hd6 hdisk0
-bash-3.2#
-bash-3.2#
Page Space
Chksum
hd6
lsps -a
Physical Volume
Volume Group
Size %Used Active Auto Type Chksum
rootvg
1024MB
2
yes
yes
lv
0
chps -s 2 hd6
lsps -a
Physical Volume Volume Group
Size %Used Active Auto Type
hdisk0
rootvg
3072MB
yes
yes
lv
Figure 3-31 Paging space
3.2.3 Installation
Because the iso file is mounted on /mnt, we changed the path to /mnt/server/, which is the
location of the dirinstall.server executable script. Before you run the installation script,
change the default DB2 path of the database. Because the media is mounted in read-only
mode, copy the file to a temporary directory. Edit the dirserv.rsp file with a text editor.
Figure 3-32 shows the database path that we chose for the installation. It is referenced by the
DB_DATAPATH variable.
# Used to specify where the managed DB2 database will be stored when
# managed DB2 database is selected. If not specified the default path will be
# /home/dirinst1. If the path does not exist, it will be created.
DB_DATAPATH=/isddb2
Figure 3-32 dirserv.rsp
60
When you start the installation for IBM Systems Director, name the executable the name that
is shown in Figure 3-33 to point to the changed response file.
-bash-3.2# ./dirinstall.server -r /tmp/dirserv.rsp
+=============================================================================+
Start of product installation on SA-W217-1AIX
+=============================================================================+
Variables will be used during the installation:
PRE_INSTALL_CHECKS : 0
PortNumber : 8421
SecurePortNumber : 8422
AGENT_MANAGER_PORT : 20000
MIGRATE_DATA : 1
UPDATES_PATH : /mnt/server/packages/updates
-Managed DB2 is supported and its prerequisites are met.
DB_INST_TYPE : 1
DB_DATAPATH : /isddb2
DB_PWD : default.
DB_INSTANCEPATH : .
DB_SERVER : localhost
DB_PORT : default
+=============================================================================+
Figure 3-33 Specifying a response file
Successful installation is similar to Figure 3-34.

Attempting to install features.........done
Stopping the server runtime...done
Configuring database......done
Finished processing all filesets. (Total time:
Finished processing all filesets. (Total time:
45 mins 48 secs).
45 mins 51 secs).
+-------------------------------------------------------------------------+
Summaries:
+-------------------------------------------------------------------------+
Installation Summary
-------------------Name
Level
Part
Event
Result
--------------------------------------------------------------------------DirectorServer
6.3.0.0
USR
APPLY
SUCCESS
DirectorServer
6.3.0.0
ROOT
APPLY
SUCCESS
Installation of IBM Systems Director Server completed successfully.
This installation log file can be found in /var/log/dirinst.log.
You must configure the agent manager prior to starting the server.
To configure the agent manager, run
/opt/ibm/director/bin/configAgtMgr.sh
To start the server manually, run
/opt/ibm/director/bin/smstart
Figure 3-34 Successful installation
The Agent Manager provides authentication and authorization services for managed systems
that have common installed agents here:
r.cli.helps.doc%2Ffqm0_r_cli_configAgtMgr.html
61
As shown in Figure 3-34 on page 61, the Agent Manager must be configured before you start
the IBM Systems Director server. See Figure 3-35.
/opt/ibm/director/bin/configAgtMgr.sh
-bash-3.2# /opt/ibm/director/bin/configAgtMgr.sh
Enter 1 to use the Agent Manager installed with this server (recommended)
Enter 0 to use an existing Agent Manager (advanced) : 1
Enter Resource Manager username : itso
Enter Resource Manager password :isd4itso
Re-Enter Resource Manager password :
Enter Agent Registration password :
Re-Enter Agent Registration password :
[Add] [Element]: AgentManagerUserID [Value]: itso
[Add] [Element]: AgentManagerPassword [Value]:
{aes:3C5SnKQL63SjkEy44Gs+vHE6nQzC+Dil1NzNvSiAzk=}fFn7zXZpwvH3wYuP1yCIw==
[Add] [Element]: ManagerRegistrationPassword [Value]:
{aes:3C5SnKQL63SjkEy44Gs+vHE6nQzC+Dil1NzNvSiAzk=}fFn7zXZpwvH3wYuP1yCIw==
DataSourceConfig.sh=0
DataStoreInstall.sh=0
GenerateCertificates.sh=0
EncryptAMProps.sh=0
WebConfig.sh=0
usmi-cas-setup.sh=0
-bash-3.2#
Figure 3-35 Agent Manager configuration
The return codes of all called scripts must be 0. Because all tasks are now successfully
completed, we start IBM Systems Director (Figure 3-36).
-bash-3.2# export /opt/ibm/director/bin
-bash-3.2# export PATH=$PATH:/opt/ibm/director/bin
-bash-3.2# smstart
Starting IBM Director...
The starting process may take a while. Please use smstatus to check if the server is
active.
-bash-3.2# smstatus -r
Starting
Active
Figure 3-36 Starting IBM Systems Director
Figure 3-36 confirms that the server returned an Active state. Now, you can change the DB2
parameters that relate to the system setup, if necessary.
3.2.4 DB2 settings

Disabling remote access for the DB2 user is not required. However, it helps to prevent issues
with user IDs and in-house AIX security policies:
http://www-01.ibm.com/support/docview.wss?uid=isg1IC83082
62
Stop IBM Systems Director and make the following changes:

1. Stop the IBM Systems Director server (Figure 3-37).
-bash-3.2# smstop
Shutting down IBM Director...
Figure 3-37 Stopping IBM Systems Director
2. Edit the user file (Figure 3-38).

-bash-3.2#vi /etc/security/user
dirinst1:
admin = false
rlogin=false
Figure 3-38 Edit the user properties file
3. Edit the sshd_config file (Figure 3-39).

vi /etc/ssh/sshd_config
# Added to restrict remote access
DenyUsers
dirinst1
Figure 3-39 Edit the sshd_config file
4. Restart sshd (Figure 3-40).

-bash-3.2# stopsrc -s sshd
0513-044 The sshd Subsystem was requested to stop.
-bash-3.2# startsrc -s sshd
0513-059 The sshd Subsystem has been started. Subsystem PID is 16973974.
-bash-3.2#1
Figure 3-40 Restart sshd
5. Restart IBM Systems Director (Figure 3-41).

-bash-3.2# smstart
active.
Figure 3-41 Restart IBM Systems Director
Because the response file for the DB2 installation is customized, check whether the database
path is configured as requested in the response file. Figure 3-42 shows file system usage.
df -g
-bash-3.2# df -g /home/dirinst1 /isddb2
Filesystem
GB blocks
Free %Used
/dev/hd1
2.00
1.95
3%
/dev/isddb2
10.00
9.31
7%
Iused %Iused Mounted on

211
1% /home
104
1% /isddb2
Figure 3-42 File system usage
63
By using db2 commands, query the database parameters to confirm the path within DB2
(Figure 3-43).
-bash-3.2# su - dirinst1
$ db2 get dbm config | grep "database pa"
Default database path
$
(DFTDBPATH) = /isddb2
Figure 3-43 DB2 path
Note: During the installation, you might not edit the dirserv.rsp file. You can change the
default database path after the installation by using the db2relocatedb command. This
command does not require a backup and restore. For more information, go to the following
site:
http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.lu
w.admin.cmd.doc%2Fdoc%2Fr0004500.html
Because IBM Systems Director is installed and no endpoint discoveries or additional tasks
are complete, back up IBM Systems Director in its current state. Before you complete the
save, create another lv, fs, and mount. Or, use the smsave command.
Optionally, create another mount point to point the smsave to an alternate directory
(Figure 3-44).
mklv -y "isdbkup" -t jfs2 rootvg 10G
crfs -v jfs2 -d isdbkup -m /isdbkup -A yes
mount /isdbkup
Figure 3-44 Back up lv and fs
After you create another mount point, run smsave with options (Figure 3-45).
-bash-3.2# smstop;smsave -targetDir /isdbkup
Command is running. Monitor live status and results in /opt/ibm/director/log/smsave.log
ALR1325I: The lightweight runtime has started.
com.ibm.net.SocketKeepAliveParameters
Command completed successfully
Figure 3-45 The smsave command with options
64
Figure 3-46 shows the smsave command with no options.

-bash-3.2# smstop;smsave;smstart
Command is running. Monitor live status and results in /opt/ibm/director/log/smsave.log
active.
-bash-3.2# smstatus
Active
Figure 3-46 smsave with no options
Figure 3-47 shows the location of both backups.

-bash-3.2# ls -al /isdbkup
total 8
drwxr-xr-x
4 root
system
256
drwxr-xr-x
26 root
system
4096
drwxr-xr-x
8 root
system
256
drwxr-xr-x
2 root
system
256
-bash-3.2# ls -al /opt/ibm/director/backup
total 8
drwxr-xr-x
3 root
system
256
drwxr-xr-x
30 root
system
4096
drwxr-xr-x
8 root
system
256
-bash-3.2#
Nov
Nov
Nov
Nov
07
07
07
07
11:27
10:40
11:30
10:40
.
..
2012_11_7_11.27.1
lost+found
Nov 07 11:30 .
Oct 22 14:30 ..
Oct 22 14:32 2012_10_22_14.29.29
Figure 3-47 Location of backups
IBM Systems Director backups are discussed in 4.7, Backup on page 233.
3.2.5 Initial login

After you successfully start IBM Systems Director, log in to the server through the user
interface (UI), as shown in Figure 3-48 on page 66.
In this example, SA-W217-1AIX.itso.ral.ibm.com is the host name of the server where IBM
Systems Director is installed. Or, you can use the native IP address of the server. This
example uses the following URL:
https://SA-W217-1AIX.itso.ral.ibm.com:8422/ibm/console/logon.jsp
65
Figure 3-48 IBM Systems Director login page
After you log in to IBM Systems Director, select the Plug-ins tab. Select IBM Systems
Director server to get an overview of the server and associated properties (Figure 3-49).
Figure 3-49 IBM Systems Director server
66
3.2.6 Installing the IBM Systems Director license

The IBM Systems Director license is on the root path of the ISO or GZIP file that you
transferred to the installation server. The license key can be imported by using the command
line. Or, use the UI for a license key that is stored locally on the computer that is used to
access the UI (Figure 3-50).
Figure 3-50 UI license import
Figure 3-51 shows an example of importing the license key from the server installation code.
-bash-3.2# importkey ISD_express_edition_power.lpsa
International Program License Agreement
Part 1 - General Terms
BY DOWNLOADING, INSTALLING, COPYING, ACCESSING, CLICKING ON
AN "ACCEPT" BUTTON, OR OTHERWISE USING THE PROGRAM,
LICENSEE AGREES TO THE TERMS OF THIS AGREEMENT. IF YOU ARE
ACCEPTING THESE TERMS ON BEHALF OF LICENSEE, YOU REPRESENT
AND WARRANT THAT YOU HAVE FULL AUTHORITY TO BIND LICENSEE
TO THESE TERMS. IF YOU DO NOT AGREE TO THESE TERMS,
- DO NOT DOWNLOAD, INSTALL, COPY, ACCESS, CLICK ON AN
"ACCEPT" BUTTON, OR USE THE PROGRAM; AND
- PROMPTLY RETURN THE UNUSED MEDIA, DOCUMENTATION, AND
PROOF OF ENTITLEMENT TO THE PARTY FROM WHOM IT WAS OBTAINED
Press Enter to continue viewing the license agreement, or
enter "1" to accept the agreement, "2" to decline it, "3"
to print it, or "99" to go back to the previous screen.
1
Importing license keys.
IBM Systems Director Express Edition
All keys imported successfully.
Figure 3-51 CLI license import
67
For more information about the license, go to the following site:

r.editions.doc%2Feditions_power_express_license.html
3.3 Installation of IBM Systems Director server for a Linux on

Power platform
Useful information is described about the process of installing IBM Systems Director for a
Linux on Power platform. For the installation of IBM Systems Director for Linux on Power, go
to the following site:
http://publib.boulder.ibm.com/infocenter/director/pubs/topic/com.ibm.director.inst
all.helps.doc/fqm0_t_installing.html
3.3.1 Downloading the software

The IBM Systems Director management server code can be sourced from the following site:
http://www-03.ibm.com/systems/software/director/downloads/mgmtservers.html
Place the code on the Linux on Power system by using a file transfer method of your choice.
After the code is on the Linux system, use this command to extract the installation files:
tar -zxf express_Power_Linux_Director_base.tar.gz
3.3.2 Prerequisites
To determine whether the Linux distribution fulfills the software requirements, change to the
/server/checkds directory. Each Linux distribution that is supported has additional Red Hat
Package Manager (RPM) packages that need to be installed. Look for the checkds.sh script
in the checkds folder. This script checks the state of the server and whether the server is
supported for the IBM Systems Director server. If all the required RPM packages are
installed, look for a return code of 0.
The checkds script invokes a /checkds/checklists/lin-server-chklist.properties
checklist file. This file is unique for each supported OS on which the IBM Systems Director
server is installed.
Before the installation of IBM Systems Director for Linux on Power, review Table 3-2 on
page 69. Use the links in the footnotes to source the additional required RPM packages.
68
Table 3-2 Software requirements for Linux on Power

Installation scenario
Required RPM packages on the Agent
Required RPM packages on the server
Red Hat Enterprise

Linux Advanced
Platform,
version 5.x on IBM
Power Systems
compat-libstdc++-<version>.ppc.rpma
servicelog-0.2.9-0.ppc64.rpmb
openssl097a-0.9.7a-9.<version>.ppc.rpmc
librtas-1.3.4-0.ppc64.rpmb
vacpp.rted e
Required RPM packages on Agent
Red Hat Enterprise

Linux Advanced
Platform, version 6.* on
IBM Power Systems
compat-libstdc++-33.ppca
libstdc++-4.4.4-13.el6.ppc.rpma
pam-1.1.1-4.el6.ppc.rpma
servicelog-1.1.7-2.el6.ppc64a
librtas-1.3.4-2.el6.ppca
libservicelog-1.1.9-4.el6.ppca
expat-2.0.1-9.1.el6.ppca
compat-expat1-1.95.8-8.el6.ppca
vacpp.rted e
SUSE Linux Enterprise

Server 10 on IBM Power
Systems
compat-libstdc++-<version>.ppc.rpma
libservicelog-1.1.9-1.ppc.rpmb
servicelog-1.1.7-1.ppc.rpmb
lsvpd-0.16.0-1.ppc.rpmb
librtas-1.3.5-1.ppc.rpmb
vacpp.rted e

Server 11 on IBM Power
Systems
libstdc++33-3.3.3-11.9.ppc64.rpma
librtas-1.3.5-1.ppc.rpmb
pam-32bit-1.0.2-20.1.ppc64.rpma
vacpp.rted e
gcc-4.3-62.198.ppc64.rpm
gcc-c++-4.3-62.198.ppc64.rpm
libstdc++43-devel-4.3.3_20081022-11.18
.ppc64.rpm
gcc43-c++-4.3.3_20081022-11.18.ppc64
.rpm
glibc-devel-2.11.1-0.17.4.ppc64.rpm
linux-kernel-headers-2.6.32-1.4.13.noarc
h.rpm

Server 11 SP2 on IBM
Power Systems
libstdc++33-3.3.3-11.9.ppc64.rpma
librtas-32bit-1.3.6-010.1.ppc64.rpma
ppc64-diag-2.4.2-0.14.12.ppc64.rpma
libvpd2-2.1.3-0.9.1.ppc64.rpma
pam-32bit-1.0.2-20.1.ppc64.rpma
pam-modules-32bit-11-1.22.1.ppc64.rpma
a. Obtain this RPM package from the operating system distribution media. There might be minor version variations from
the versions that are listed, which are acceptable.
b. Obtain this RPM package from IBM Service and productivity tools for Linux on Power Systems at:
https://www14.software.ibm.com/webapp/set2/sas/f/lopdiags/home.html. Select your Linux distribution and then
select the appropriate tab for your version. Follow any special instructions for each RPM package. For RHEL5, if the
listed RPM version is not available on the website, get it from the RHEL4 tab.
c. Obtain this RPM package from the operating system distribution media in addition to openssl 0.9.8, which is installed
by default.
d. Server only.
e. Obtain the tar.gz package from https://www-304.ibm.com/support/docview.wss?uid=swg24030460. Untar and
install the three included RPM packages. This action applies for all platforms.
69
Note: The 64-bit RPM package file names include ppc64. The 32-bit RPM package file
names include ppc. If the listed RPM package shows ppc, you need the 32-bit version. The
Platform Agent does not install if you show the 64-bit version only.
For software requirements, see the following site:
http://www.ibm.com/developerworks/wikis/display/WikiPtype/Software+requirements+fo
r+Director+6.3+on+Linux+on+Power
Run the checkds.sh script (Figure 3-52). Check for the return code 0. If the return code is not
0, review, fix, and run again.
[root@xs-2120rhelppc checkds]# ./checkds.sh
Java: /root/ISD632/server/checkds/jvm/plinux/bin/java
Starting IBM Systems Director Pre-Installation Utility...
Finished analysing system
Creating reports...
Install Readiness Text report being written to
/tmp/checkds/reports/checkDS_Text_20121022_134508.txt
Install Readiness Error Text report being written to
/tmp/checkds/reports/checkDS_Error.txt
Install Readiness Detailed HTML report being written to
/tmp/checkds/reports/checkDS_Detailed_20121022_134509.html
Install Readiness Summary HTML report being written to
/tmp/checkds/reports/checkDS_Summary_20121022_134510.html
Unable to launch the default browser, please view the text or summary HTML report
manually.
Overall Report Return Code: 0
Figure 3-52 Running the checkds script
70
3.3.3 Installing the IBM Systems Director server

After you see the return code 0 from the checkds script (Figure 3-52 on page 70), proceed
with the installation (Figure 3-53).
[root@xs-2120rhelppc server]# ./dirinstall.server
Agree to product license?
[1-Agree|0-Disagree]:1
..../....
Enter 1 to use the Agent Manager installed with this server (recommended)
Enter 0 to use an existing Agent Manager (advanced) : 1
Enter Resource Manager username : isd4itso
Enter Resource Manager password :
Re-Enter Resource Manager password :
Enter Agent Registration password :
[Add] [Element]: AgentManagerUserID [Value]: isd4itso
[Add] [Element]: AgentManagerPassword [Value]:
{aes:3C5SnKQL63SjkEy44Gs+vHF6nQzC+Dil1NzNvSiAzzk=}fFn7zXZpwvsH3wYuP1yCIw==
[Add] [Element]: ManagerRegistrationPassword [Value]:
{aes:3C5SnKQL63SjkEy44Gs+vHF6nQzC+Dil1NzNvSiAzzk=}fFn7zXZpwvsH3wYuP1yCIw==
DataSourceConfig.sh=0
DataStoreInstall.sh=0
GenerateCertificates.sh=0
EncryptAMProps.sh=0
WebConfig.sh=0
usmi-cas-setup.sh=0
Installation of the IBM Systems Director Server 6.3.2 succeeded.
To start the server manually, run /opt/ibm/director/bin/smstart.
To see the status, run /opt/ibm/director/bin/smstatus [-r].
Figure 3-53 Summary output of dirinstall.server
After the installation completes successfully, start IBM Systems Director for Linux on Power
(Figure 3-54).
[root@xs-2120rhelppc server]# /opt/ibm/director/bin/smstart
Starting IBM Director...The starting process may take a while. Please use smstatus to
check if the server is active.
[root@xs-2120rhelppc server]# /opt/ibm/director/bin/smstatus -r
Starting
Active
Figure 3-54 Starting IBM Systems Director for Linux on Power
71
After the IBM Systems Director server returns an Active status (Figure 3-54 on page 71), go
to the login page (Figure 3-55).
Figure 3-55 IBM Systems Director login page
72
After you log in, select the Plug-ins tab and select IBM Systems Director server to see an
overview of the server and associated properties (Figure 3-56).
Figure 3-56 IBM Systems Director server
3.4 Installation of the IBM Systems Director agent on Linux x86

Because the Information Center does not explain how you can install the IBM Systems
Director Platform or Common Agent without disabling SELinux and iptables, we cover those
steps here because this is a common requirement.
Use the following steps to deploy the Platform or Common Agent on a Linux operating system
MEP running on x86 without disabling SELinux or the iptables service.
1. Ensure that you have prepared your Linux system as documented at the following site:
helps.doc/fqm0_t_preparing_to_install_core_on_xseries.html
Tip: At the time of writing, on a default installation of RHEL 6.3, you need to install the
commands shown in Example 3-1 to satisfy dependencies for the Platform Agent. You
can find those packages on the RHEL 6.3 installation media, which can be added to
your yum repository by running the vim /etc/yum.repos.d/rhel-dvd.repo command
and following the instructions in the text shown in Example 3-2 on page 74.
Example 3-1 Packages to install on default RHEL 6.3
yum
yum
yum
yum
yum
install
install
install
install
install
compat-libstdc++-33.i686
compat-expat1.i686
pam-1.1.1.i686
libstdc++.i686
libuuid.i686
73
Example 3-2 Content of /etc/yum.repos.d/rhel-dvd.repo
[rhel-dvd]
name=Red Hat Enterprise Linux $releasever - $basearch - DVD
baseurl=file:///<path where you have mounted your RHEL installation media>/Server/
enabled=1
gpgcheck=1
gpgkey=file:///<path where you have mounted your RHEL installation
media>/RPM-GPG-KEY-redhat-release
2. Discover the operating system MEP by running a System Discovery and unlock it with root.
Note: You can use sudo to unlock access to your MEPs, as documented at the
following link:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.secur
ity.helps.doc/fqm0_t_access_agentless_with_sudo_and_keypair_authentification
.html?resultof=%22%73%75%64%6f%22%20
However, until the agent is installed, try not to use sudo access because this prevents
the agent installation from completing successfully. After the agent is deployed, you can
revoke access and reconfigure it with sudo.
3. Run a full inventory on the MEP by selecting it and going to Actions Inventory
Collect Inventory in the Resource Explorer view.
4. On the Linux system, edit the iptables configuration to open necessary ports:
a. Use the iptables -nL --line-numbers command to list existing rules and note the line
number of the -A INPUT -j REJECT --reject-with icmp-host-prohibited rule, as
shown in red in Example 3-3.
Example 3-3 Showing the active rules in iptables
[root@SBvmrhel1 tmp]# iptables -nL --line-numbers

Chain INPUT (policy ACCEPT)
num target
prot opt source
destination
1
ACCEPT
all -- 0.0.0.0/0
0.0.0.0/0
RELATED,ESTABLISHED
2
ACCEPT
icmp -- 0.0.0.0/0
0.0.0.0/0
3
ACCEPT
all -- 0.0.0.0/0
0.0.0.0/0
4
ACCEPT
tcp -- 0.0.0.0/0
0.0.0.0/0
tcp dpt:22
5 REJECT
all -- 0.0.0.0/0
0.0.0.0/0
Chain FORWARD (policy ACCEPT)

num target
prot opt source
1
REJECT
all -- 0.0.0.0/0
reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target
prot opt source
state
state NEW
reject-with icmp-host-prohibited
destination
0.0.0.0/0
destination
b. If you see that line (normally applies only to RHEL), you need to delete it before adding
new rules. To delete it, use the iptables -D INPUT n command where n is the line
number (in Example 3-3, it is line 5).
74
c. Add the required firewall rules by running the commands that are shown in
Example 3-4.
Example 3-4 Adding required rules in iptables
iptables
iptables
iptables
iptables
iptables
iptables
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-p
-p
-p
-p
-p
-p
tcp
udp
tcp
tcp
udp
udp
--dport
--dport
--dport
--dport
--dport
--dport
427 -j ACCEPT
427 -j ACCEPT
15988 -j ACCEPT
15989 -j ACCEPT
161 -j ACCEPT
162 -j ACCEPT
d. Optionally, add the Virtual Network Computing (VNC) ports if you are deploying to a
virtual server managed by VMControl and want to enable remote console access by
running this command:
iptables -A INPUT -p tcp --dport 5900:5950 -j ACCEPT
e. Add the reject rule back by running this command:
iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
f. Save the rules by running this command:
/sbin/service iptables save
Tip: If you are using a default installation of Novell SLES, you do not need to add
firewall rules because there are none that are defined by default, which means that
all network traffic is allowed.
5. You can now deploy the platform agent on your Linux operating system MEP by
right-clicking the MEP and selecting Release Management Install Agent.
6. Collect inventory again as explained in step 4 on page 74 now that the agent has been
deployed.
75
3.5 Best practices

To summarize, keep in mind the following best practices when installing IBM Systems
Director:
Prepare your system carefully. Check the prerequisite (see Chapter 2, Planning on
page 7 for this).
Run the pre-check before starting the installation. Fix all shown problems.
Follow the installation steps, read the instruction for each of the steps, and put in the
requested information.
Use a technical user (with local admin rights) as credential for installing the IBM Systems
Director.
To avoid problems, the user name that is used for the IBM Systems Director installation
should not contain ibm in the name.
Select the embedded DB2 database as the IBM Systems Director database. This makes
the installation and configuration easier.
After finishing the installation, run the Post Installation Validator to check that the
installation runs and finishes successfully.
76
Chapter 4.
Basic management tasks

This chapter covers best practices for the basic management tasks that are available in IBM
Systems Director. These tasks include how to perform discovery; how to collect inventory on
discovered resources; how to deploy agent, driver, and firmware updates; how to manage
hardware events and other miscellaneous tasks.
4.1, Discovery on page 78

4.2, Inventory on page 86
4.3, Updates on page 104
4.4, Event management on page 143
4.5, Hardware Management Console and AIX Launch-in-Context on page 194
4.6, Security on page 208
4.7, Backup on page 233
77
4.1 Discovery
Systems Director 6.3.2 can discover various types of endpoints. For multiple discovery
options and multiple resource types to discover, see the Discovery section of the web
interface.
For more information about the discovery and inventory processes of Systems Director, see
the Systems Director Discovery Information Center:
r.discovery.helps.doc%2Ffqm0_t_discovering_and_inventorying_resources.html
Figure 4-1 displays the available options to specify the endpoints that need to be discovered.
You can limit the discovery process to a single address or range of sequential addresses. Or,
you can use a discovery profile.
Figure 4-1 Discovery options
78
Figure 4-2 shows the resource options that are available to discover. Use resource types to
limit the discovery process to protocols that are based on the resource type to discover.
Figure 4-2 Resource options
Tip: IBM Systems Director will not discover Windows Server 2012 systems unless you
prepare those systems as documented in the information center:
ctor.install.helps.doc%2Ffqm0_t_preparing_windows_server_2012_managed_systems.h
tml
4.1.1 Discovery profiles

Using discovery profiles is the best way to efficiently and effectively perform a discovery within
Systems Director. Figure 4-3 displays the Advanced Tasks section, which gives you the
options to manage discovery profiles.
Figure 4-3 Advanced Tasks page
Chapter 4. Basic management tasks
79
Figure 4-4 shows an example of creating a discovery profile for a BladeCenter chassis.
Figure 4-4 Profile Properties page
Figure 4-5 is the Protocol Selection page. If the chosen resource type supports additional
discovery protocols, the protocols are listed.
Figure 4-5 Protocol Selection page
80
Figure 4-6 shows where you configure how to discover your endpoints. Depending on the
network, Unicast, Multicast, and Broadcast can be used. For best results, the use of Unicast
is advised. With this option, you can specify an IP address or sequential range of IP
addresses of endpoints. You also can import a group of nonsequential IP addresses by
importing a text file or a CSV file that contains one IP address per line.
Figure 4-6 SLP Configuration page
In Figure 4-7, you can enter credentials that automatically request access to the endpoint
after the discovery.
Figure 4-7 Access Request page
81
Figure 4-8 displays the new Discovery Profile wizard summary.
Figure 4-8 Summary
Figure 4-9 displays how to choose the profile that you created, which can be run immediately
or scheduled.
Figure 4-9 Selecting a discovery profile
4.1.2 BladeCenter discovery

To successfully discover a BladeCenter advanced management module (AMM), you must set
several AMM prerequisites:
Increase the TCP command mode protocol to at least 10 connections.
Systems Director needs several concurrent connections to successfully communicate with
a BladeCenter AMM.
82
Figure 4-10 shows the AMM page where the TCP command mode protocol is listed.
Figure 4-10 TCP Command Mode Protocol page
Enable SNMPv1 and SNMPv3.

Set the trap destination to the IP address of the Systems Director server. Set the Access
Type to Get or greater.
By enabling SNMPv1 and SNMPv3, Systems Director uses the connection to collect a
more comprehensive inventory. Figure 4-11 on page 84 shows the AMM SNMPv1 and
SNMPv3 settings page. Both the AMM SNMPv1 and SNMPv3 agents need to be enabled.
83
Figure 4-11 Simple Network Management Protocol (SNMP) configuration
SNMPv3 needs a user profile that is associated to it. Set the Access type to Set
(Figure 4-12).
The user profile that is associated to SNMPv3 is used when you request access from the
AMM.
Figure 4-12 SNMPv3 User Profile page
Tip: Reboot AMM after these changes.
84
4.1.3 Best practices for discovery

Following are the best practices to use the discovery task efficiently:
Discover only the systems that you intend to manage.
Limiting discoveries to systems that you intend to manage speeds up the discovery
process. You eliminate discovering other devices that might support the discovery
protocols.
Keep the IP address ranges as small as possible.
Limiting the number of addresses in a single request can improve the reliability of the
discovery.
Specify the types of resources to discover (avoid the use of All).
Systems Director can skip discovery protocols that are inappropriate for your resources.
Skipping inappropriate discovery protocols results in shorter discovery time.
Schedule the discovery of large numbers of systems during off-hours.
Scheduling large discovery jobs off-hours improves the reliability of the discovery process
and helps with the additional network traffic.
Where possible, use discovery profiles and specify individual IP addresses or use Service
Location Protocol (SLP) Directory Agents.
Making the profile as specific as possible minimizes discovery time because Systems
Director runs only the protocols that are configured.
SLP Directory Agents reduce network traffic and increase discovery speed.
Prepare your hardware for discovery.
85
4.2 Inventory
Inventory is one of the most important tasks. Inventory needs to be run on all systems that are
managed by the Systems Director server. Inventory information provides the basis for much
of the functionality in Systems Director.
The following elements are good examples of functionality that depends on inventory:
Update Manager
Compliance checks
Dynamic groups
Inventory data for systems that are managed by Systems Director is stored in a database that
is created and controlled by Systems Director. Since version 6.3, the default database format
is IBM DB2.
Optionally, you can use external databases, such as IBM DB2, Oracle, and Microsoft SQL
Server (the latter is for Windows platforms only). It is a preferred practice to use the built-in
(local) IBM DB2 database, which is created and controlled by Systems Director at installation.
When a system is discovered by the Systems Director, a basic inventory scan runs for this
system. This scan includes IP address, host name, OS, and if an agent is installed, the agent
version. For additional information beyond these properties, the Systems Director needs full
authorized access to the system.
When a system has access, run an inventory scan for this system to collect the complete
inventory information. The complete inventory information includes hardware, software, and
driver information from the system.
The following topics are described:
4.2.1, Inventory data and collection profiles on page 86

4.2.2, Collecting inventory on page 93
4.2.3, Viewing inventory on page 96
4.2.4, Exporting inventory on page 99
4.2.1 Inventory data and collection profiles

Systems Director uses inventory collection profiles to collect inventory data from discovered
resources.
Systems Director uses profiles to manage the inventory collection tasks that you create and
run. An inventory collection profile is a group of settings that are saved on the Systems
Director server. The settings indicate the type of resources that are collected during the
collection process.
By default, Systems Director includes the following inventory collection profiles:
All Inventory
This profile collects inventory from all resources and encompasses all the other inventory
collection profiles.
All inventory: The All Inventory profile is required if you intend to use Update Manager.
86
All Hardware Inventory

This profile collects inventory from physical and virtual devices.
All Software Inventory
This profile collects inventory from software resources.
Basic System Information
This profile collects inventory from system resources.
These predefined inventory profiles are read-only and cannot be deleted or edited. However,
you can use these existing profiles to create your own profiles.
The use of inventory discovery profiles provides a predefined template to collect the inventory
information that you need. This template is useful when you want to use the inventory
information that Systems Director collects from the system for asset tools. Or, this template is
useful if you need specific information from the system without going through all of the
available inventory information.
To create your own inventory discovery profile, follow these steps:
1. Start on the View and Collect Inventory page. Select Manage Profiles next to the profile
selection (Figure 4-13).
Figure 4-13 Manage inventory discovery profiles
2. Select either to create a profile or copy an existing profile. When a function is selected, the
Create Inventory Profile wizard opens. In our example, we create a profile. The first
window is the Welcome page (Figure 4-14). Click Next at the bottom of the page (not
shown) to continue.
Figure 4-14 Inventory Discovery Profile wizard: Welcome panel
87
3. In Figure 4-15, give your profile a name. If you chose to copy an existing profile, the default
name is copy_of_profilename. In our example, we name the profile book as shown in
Figure 4-15. A description is optional. Click Next to continue.
Figure 4-15 Inventory Discovery Profile wizard profile name
4. In Figure 4-16, select which inventory resources to collect with your profile. To select an
inventory resource, expand the resource groups on the left, make your selection, and click
Add to copy your selection to the selected resources. You cannot copy complete resource
groups. Instead, you must select each resource in a resource group to select the complete
group. Click Next to continue.
Figure 4-16 Inventory Discovery Profile wizard: Inventory Selection page
88
5. In Figure 4-17, select the inventory service. You can either let the system select the
inventory service or you can manually configure the discovery service.
If you select Let the system choose the discovery services, click Next to see the option
window as described in step 7 on page 91.
If you select Let me manually configure the discovery services and click Next, you see
what is shown in Figure 4-18. Go through the definition of the discovery services. In this
window, you can select the available inventory profiles.
In most cases, letting the system choose the discovery service is easier. With this method,
no configuration mismatches occur and you include all necessary functions.
Figure 4-17 Select Discovery Service page
The example that is displayed in Figure 4-18 shows the available functions of this wizard. We
choose the manual configuration. In the example, only one discovery service is available, the
CIT Software Discovery module, which we select.
Select the modules (if more than one service is available) that you want to use and click Next.
Figure 4-18 Module Selection page
6. In our example, the option menu for the CIT Software Discovery module opens
(Figure 4-20 on page 90). You can select whether you want to use the registry, the catalog,
or both for the inventory collection. In our example, we select Use both.
If you select the registry, the registry information from the system is used to collect
software inventory information. If you select the catalog, the internal software catalog is
used to collect software inventory information. When you choose both options for the
software inventory collection, the CIT Software Discovery module checks the registry and
the catalog to collect software information.
89
The default software signature file is the softwaresignature.xml file (Figure 4-19).
<!-Licensed Materials - Property of IBM
(C) Copyright IBM Corp. 2010, 2011 All Rights Reserved
US Government Users Restricted Rights - Use, duplicate or disclosure
restricted by GSA ADP Schedule Contract with IBM Corp.
-->

Figure 4-19 softwaresignature.xml file
If other modules are available, you see the option menus for these modules. Make your
selection and click Next. Figure 4-20 shows the process of selecting the inventory
collection method.
Figure 4-20 CIT Software Discovery options page
90
7. In the Options panel, Figure 4-21, you can define the timeout period and the number of
simultaneous collections.
Timeout period describes the length of time to wait for a response to inventory collection
communications that are sent to systems. If the timeout value elapses before the response
is received from the destination, no inventory data is collected from that target.
Maximum simultaneous collections describe the maximum number of agents from which
the Systems Director server can simultaneously collect inventory. To help reduce network
traffic, specify the lowest possible number of agents.
A check box asks whether you want to try failed agents again. If you select this function,
Systems Director automatically tries again after failed collection attempts.
Click Next to continue.
Figure 4-21 Options panel
91
8. The summary window for the wizard opens (Figure 4-22). This view is where you can
verify the settings that you entered. Click Finish at the bottom of the window (not shown)
to save the Inventory Discovery profile that you created.
Figure 4-22 Summary view
9. The list of available profiles for the inventory collection displays, including the profile that
you created (Figure 4-23). In this window, you can edit or delete existing profiles.
Figure 4-23 Inventory discovery profiles
92
4.2.2 Collecting inventory

Before you can view inventory for a resource, you must discover that resource by using
discovery.
Inventory collection uses inventory collection profiles. You can use an existing profile to collect
inventory for a system. If the inventory collection profile does not exist for the inventory data
type that you want to collect, first create the inventory collection profile. Ensure that the
inventory collection profile contains the appropriate settings.
Follow these steps to perform an inventory collection:
1. Launch View and Collect Inventory. Systems Director offers you various ways to initiate
this task:
On the home page, on the Initial Setup tab, click Collect Inventory, as shown in
Figure 4-24.
Figure 4-24 Inventory collection from the Initial Setup tab
93
On the left-most tasks panel, click Inventory View and Collect Inventory, as
shown in Figure 4-25.
Figure 4-25 Select the View and Collect Inventory option from the left pane
From the Systems Director home page, click the Plug-ins tab and under Discovery
Manager, click View and Collect Inventory, as shown in Figure 4-26.
Figure 4-26 View and Collect Inventory from home page
94
In Resource Explorer, right-click a group or system. Then, from the menu, click
Inventory View and Collect Inventory (Figure 4-27).
Figure 4-27 View and Collect Inventory from the Resource Explorer page
2. The inventory task then launches (Figure 4-28). If not preselected, select the system or
group for which you want to run the inventory collection. Then, you can select an inventory
discovery profile. We describe how to create a profile in 4.2.1, Inventory data and
collection profiles on page 86. Click Collect Inventory to start the process.
Figure 4-28 Inventory collection
95
3. A scheduler window opens (Figure 4-29). Select Run Now or specify a time to run the
inventory collection.
Figure 4-29 Scheduler example for weekly, Sunday 12:22 a.m. setting
Schedule an inventory collection once a week. Schedule this inventory collection in

off-hours so that the inventory collection does not affect your daily business. Also, run an
inventory scan when you plan to update systems or install agents on the system.
4. After the schedule is defined or you select Run Now, click OK.
5. You can see the status of the task in the left pane under Task Management Active and
Scheduled Task.
4.2.3 Viewing inventory

After the inventory task completes, you can view the results. The following examples show
different profiles.
Tip: When you select a single system, a summary shows at the top of the inventory
information. If you select a group of systems, no summary is shown.
96
In our examples, we used the All Systems group to discover the inventory:
Basic file system information (Figure 4-30)
Figure 4-30 Basic file system information
All software inventory (Figure 4-31)
Figure 4-31 All software inventory
All hardware inventory (Figure 4-32)
Figure 4-32 All hardware inventory
97
All inventory (Figure 4-33)
Figure 4-33 All inventory
If you select a single system, a system summary shows at the top of the inventory
information. This summary provides an overview of the system information:
98
Operating system summary

Network configuration summary
Systems Director Agent version that is installed on the system
Access state
Supported protocols
Firmware information
In Figure 4-34, we show a system that runs SLES11. The Systems Director server 6.3.2 is
installed. The system runs on a virtual machine that is hosted by VMware ESXi.
Figure 4-34 Inventory summary view (only available for a single system selection)
4.2.4 Exporting inventory

To use the inventory information outside the Systems Director, you can export the inventory
information for a system or group. This function might be useful to perform asset
management tasks that are external to Systems Director. Or, this function can be useful if you
want to print the inventory report for documentation.
99
Follow these steps to export the inventory data:

1. From the View and Collect Inventory page, click Export All (Figure 4-35).
Figure 4-35 Select Export All to export inventory data
2. Choose the format to which to export the inventory data (Figure 4-36). Various formats are
available to export your data:
Hypertext Markup Language (HTML)
Extensible Markup Language (XML)
Comma Separated Variable (CSV)
Figure 4-36 Select the format for export
100
3. After you select the format in which you want to export the inventory data, click OK.
If the HTML or XML format is selected, a web page that contains the data opens in your
browser. You can save this data to a file or print the data, as needed. In this example, we
use HTML as the file format (Figure 4-37).
Figure 4-37 HTML export
101
If the CSV format is selected, you can save or open the data with available applications as
detected by your browser (Figure 4-38).
Figure 4-38 Save the CSV file
The CSV file can be used, for example, to import this data into an Excel worksheet
(Figure 4-39).
Figure 4-39 Imported inventory information into an Excel worksheet by using the CSV file
102
4.2.5 Best practices for inventory

These are the best practices to use the inventory task efficiently:
Use the embedded DB2 database.
This database is managed by the IBM Systems Director. It is a full enterprise database.
Collect inventory as often as possible, and at a minimum once a week.
Inventory data is important for many functions in the IBM Systems Director. Only actual
data keeps this function up to date and running.
If there are updates in your environment, run afterwards the inventory for these systems.
Inventory information about the installed driver and firmware are the basis for the
compliance check. These checks can work successfully only if the inventory data is actual.
Run inventory collection scans in off-hours.
If you have many systems, schedule the inventory collection in off-hours to prevent
problems in the network utilization in your environment.
Use the export function to save inventory data for reports.
103
4.3 Updates
With Update Manager, a component of Systems Director, you keep the servers on your
network at the software or firmware update levels that you want. Update Manager
automatically checks for available updates and identifies which systems need attention.
Update Manager also provides you with the ability to monitor your systems for needed
updates. With Update Manager, you can schedule the updates at times that are convenient
for you and your users.
Update Manager compares the update information that is loaded into it with the inventories of
specified systems to determine whether updates are needed.
4.3.1 Prerequisites
Before you can start to use Update Manager to update your systems, ensure that an
inventory of your system is performed. You can automate the collection of the inventory
information as described in 4.2, Inventory on page 86.
To update your systems, the systems must be online and accessible. Therefore, you must
have full access to the systems from the Systems Director server. The access state must be
set to OK. Update Manager can be used to update agentless systems and systems with
Platform Agent and Common Agent installed.
To update the BladeCenter AMM and server with Integrated Management Module I (IMMv1),
you must configure a Trivial File Transfer Protocol (TFTP) server. Systems Director includes a
TFTP server. See 4.3.3, Settings for Update Manager on page 106.
The best way to check whether your system is up-to-date or needs an update is to use the
Compliance Check function, which is described in 4.3.6, Compliance check on page 114.
4.3.2 What can be updated

The following list shows the supported updates and the systems to which updates can be
applied. Unless otherwise noted, the systems can be agentless-managed systems, Common
Agent-managed systems, and Platform Agent-managed systems.
The following list shows the supported updates and systems:
Systems Director:
6.3.x (Common Agent, Platform Agent, and the Systems Director server)
6.2.x and 6.1.x (Common Agent and Platform Agent)
IBM Director V5.20.x (IBM Director Agent version 5.20 and IBM Director Core Services
version 5.20)
Technology levels (TLs) and service packs (SPs):
AIX 5.3 TL6 SP5 and later (the Systems Director server or Common Agent only)
AIX 6.1 (the Systems Director server or Common Agent only)
SUSE Linux
Red Hat Enterprise Linux
Cumulative program temporary fix (PTF) packages and PTF groups for IBM i (formerly
IBM i5/OS) 5.4 and later
104
Hardware Management Console (HMC) systems at V7.3.3 SP2 or later

Power Systems firmware for all systems that meet at least one of the following criteria:
Inband stand-alone (not managed by HMC or Integrated Virtualization Manager) Power
Systems target systems that run AIX or Linux
Required: These systems must have the Common Agent installed.
Out-of-band (managed by HMC) target systems
No Common Agent: No Common Agent is required in this case because Secure
Shell (SSH) performs the update.
Power Systems target systems that are managed by Integrated Virtualization Manager
and that run Virtual I/O Server (VIOS) version 1.5.2.1 - Fix Pack (FP) 11.1 or later
No Common Agent: No Common Agent is required in this case because SSH
performs the update.
Migration, FPs, SPs, and interim fixes for VIOS version 1.5.2.1 - FP11.1 or later
Device driver and firmware updates, or UpdateXpress System Pack updates, for System x
servers that run Linux or Windows
Support is provided for servers that run all available agent and agentless levels. No
support is available for updating IMM V2 systems that run IBM Director Agent 5.x.
Note: Using IBM Systems Director Update Manager on IBM System x or Flex System
servers requires that you enable LAN over USB on the management processor. This is
normally enabled by default and you can change the configuration by using the
management processor web interface or by using the Advanced Settings Utility (ASU)
for your operating system.
Update Manager can update drivers only if devices have been properly discovered and
installed in the operating system. For example, it will not install any adapter driver for
adapters that are shown as unknown devices in the Windows device manager.
IBM BladeCenter I/O module firmware
Update to I/O modules must be installed from a TFTP or FTP server. The IBM Systems
Director server can work as a TFTP server. (Need port 69 UDP inbound opened)
Note: The SAS RAID Controller Module needs to be discovered by using the Storage
Management Initiative Specification (SMI-S) provider to communicate with the module.
IBM BladeCenter Management Modules, AMMs, and Pass-Thru Modules
Updates to MMs, AMMs, and Pass-Thru Modules requires a TFTP or FTP server. The IBM
Systems Director can work as a TFTP server (need port 69 UDP inbound opened)
Note: The SNMP agent must be enabled in the BladeCenter Management Module
(MM, AMM). The SNMP access type needs to set to SET.
105
Update Manager does not perform the following tasks:

Installing new software products.
Installing Systems Director agents on systems that currently do not have an agent.
Instead, install Systems Director agents with the Agent Manager plug-in of Systems
Director.
Migrating to any version of Systems Director from any version of IBM Director.
Performing actions on systems that are not accessible.
You can perform update actions on those systems that are accessible only. To check
whether the system is accessible, go to Resource Manager and check the access column.
If there is a green circle icon, the access state is OK. If there is another icon (red, yellow, or
gray), check the access state and return the system to the OK state.
Uninstalling updates and rolling back updates are not supported.
Check several system-specific considerations before you use the Update Manager:
r.updates.helps.doc%2Ffqm0_c_um_platform_extensions.html
4.3.3 Settings for Update Manager

Before you start to use Update Manager, configure all of the necessary settings:
1. On the Update Manager page, click Configure settings as shown in Figure 4-40.
Figure 4-40 Update Manager: Configure settings
A new window opens. Adjust these settings:

Connection to the Internet (if the Systems Director accessed the Internet)
Location for the local repository
106
Settings that are specific to System x and BladeCenter servers

Settings that are specific to AIX and VIOS systems
2. Select the Connection tab (Figure 4-41). You can configure a direct connection to the
Internet or connect through an HTTP proxy server. After you make your selection, you can
test the Internet connection by selecting Test Internet Connection.
Figure 4-41 Connection tab
3. Select the Location tab (Figure 4-42). Define the size and location on disk of the local
repository. The defaults are shown in Figure 4-42. The size might need to be increased.
The size depends on the number of managed systems and the kinds of update packages
that you want to deploy with the Systems Director server. The maximum size is 126 GB.
Figure 4-42 Location tab
107
4. In the System x and BladeCenter tab (Figure 4-43), you can define the use of a TFTP or
FTP server for updates. This definition is necessary for updating the AMM and also for
updating systems with IMMv1.
For systems with IMMv2, this setting is not necessary. The service processor has enough
internal memory to hold the update packages for updates to Unified Extensible Firmware
Interface (UEFI), IMM, and preboot Dynamic System Analysis (pDSA).
The Systems Director server can be used as a TFTP server, as indicated in Figure 4-43.
Therefore, you do not need to install an external TFTP or FTP server.
Figure 4-43 System x and BladeCenter: TFTP and FTP selection
If you wanted to use another TFTP or FTP server already in your infrastructure, you would
have to discover, unlock, and inventory that operating system first before you can use it
here.
108
5. The UXSPi tab, Figure 4-44, shows the installed UpdateXpress System Pack Installer
(UXSPI) packages. Click Import USXPi to import these packages to Systems Director to
deploy them.
Figure 4-44 UXSPi tab: Show version or import UXSPI
To import the UXSPI packages, you need the Subsystem Device Driver (SDD) file for each
package. If the file is missing, you are prompted that the file is needed before you can
continue.
109
6. The AIX tab (Figure 4-45) shows the selection for the AIX Network Installation
Management (NIM) master. This NIM master is used for updates on AIX systems. Click
Browse to select the AIX NIM master in your network. You must first discover, unlock, and
inventory that system before you can use it here.
Figure 4-45 AIX: Define the AIX NIM master
7. The VIOS tab (Figure 4-46) shows the selection for the VIOS NIM master. This VIOS NIM
master is used for a VIOS upgrade (migration). Before you can select a system here, you
must have discovered, unlocked, and inventoried it.
Figure 4-46 VIOS: Define the VIOS NIM master
4.3.4 Update Manager with Internet connection

When Systems Director connects to the Internet, use Update Manager to check automatically
and download the update information from a central IBM repository. Section 4.3.3, Settings
for Update Manager on page 106 explains how to set up and verify the Internet connection.
110
Perform these steps to retrieve updates directly from the Internet:

1. On the Update Manager home page, click Acquire updates, as shown in Figure 4-47.
Figure 4-47 Update Manager: Acquire updates
2. In the Acquire Updates window (Figure 4-48), click Check for updates (Internet
connection required).
Figure 4-48 Selection for Internet or import
111
3. The window then expands as shown in Figure 4-49. A selection window opens where you
select the update that the Update Manager looks for in the IBM repository.
4. Expand Available update types on the left. Select the update types that you want and
click Add.
Figure 4-49 Select the updates for checking
5. After you select the updates that you want, click OK.
6. A scheduler window opens. Download the updates one time or define a recurring
schedule. The best practice is that you perform the updates on a recurring schedule, such
as once a week. The best time to update is off-hours (for example, weekend nights) so
that this download traffic does not affect your daily business.
4.3.5 Update Manager with no Internet connection

If your Systems Director server does not connect to the Internet, you can use the Update
Manager to import update packages. Download these update packages in advance from the
IBM Fix Central website or another source for IBM updates.
IBM Fix Central is at the following link:
http://ibm.com/support/fixcentral
You can obtain single updates (latest updates) or you can also use the UXSPI packages for
your system. UXSPI packages contain updates for your system that are tested and work
together. The types of updates include updates for UEFI, IMM, drivers, or firmware.
112
UXSPI packages are easier to download. You do not need to locate a download for each
update package for each component in your system separately.
Follow these steps to apply the updates that you previously downloaded to Update Manager:
1. On the Update Manager startup page, select Acquire updates, as shown in Figure 4-50.
Figure 4-50 Acquire updates
2. Click Import updates from the file system, as shown in Figure 4-51.
Figure 4-51 Acquire Updates selection window
113
3. When you select to import the updates, the window expands (Figure 4-52). Select the
directory where you downloaded the updates previously. This directory must be on or
accessible from the management server.
Figure 4-52 Import updates from the file system
4. After you select the directory, click OK. The updates are imported into the Systems
Director server.
4.3.6 Compliance check

A compliance check compares information in the local repository of Systems Director with the
inventory information that Systems Director collected from the managed systems. The
compliance check process is a background process. After you define it, it runs automatically
for each new update or for each new collection of system inventory information.
If the compliance check identifies new updates for a system, the system is marked as
noncompliant by a status of information, warning, or critical. This status depends on the
level of the system and the level of the available updates. This status can change if newer
updates appear.
For the best results, schedule a regular download or import of the newest available updates
and perform regular inventories for the available systems. You can automate this inventory
collection for your systems as described in 4.2, Inventory on page 86.
You can set up a compliance check against a single system or a group of systems. If you use
groups, define groups that contain systems of the same type or that share properties.
114
Follow these steps to set up the compliance check:

1. From the Update Manager main page, click Optional: Create and configure compliance
policies, as shown in Figure 4-53.
Figure 4-53 Select, create, and configure compliance policies
115
2. In Figure 4-54, select systems or a group for which you want to create the compliance
check. After you select these systems or a group, click OK.
Figure 4-54 Select systems or a group for the compliance check
116
If the group or systems that you select have no available inventory information, you see a
message (Figure 4-55). The message states that no inventory is available and you need to
perform an inventory collection by clicking Collect Inventory. After the inventory starts,
click Close Message.
Figure 4-55 Warning message that no inventory is available
117
3. After the inventory run completes, a message appears and you can add a compliance
policy for the systems or group that you selected before. Click Add (Figure 4-56).
Figure 4-56 After you collect the inventory, select Add
118
4. In Figure 4-57, select the update group and click Add. This group defines the type of
updates for which your system runs the compliance check. In our example, we selected
All Critical IBM System x and BladeCenter Updates and All IBM Systems Director 6.3
Updates. After you finish your selections, click OK.
Figure 4-57 Select the update groups for the compliance check
119
5. You return to the previous window. The compliance policies that are defined for your
systems are shown as seen in Figure 4-58. To finish the definition of the compliance
policies, click Save.
Figure 4-58 Selected update groups for the systems
120
6. You return to the Update Manager home page where you see the Update Compliance
section (Figure 4-59). You can see the compliance status of the systems that you
specified.
Figure 4-59 Update Manager with defined compliance check
4.3.7 Update process

The Update Manager is configured and you have the required updates (either from the
Internet or imported from a local directory to the Systems Director repository). Start the
update process.
We describe two methods:
Using Update Manager: Show and install updates on page 122
Using the compliance check to update on page 129
121
Using Update Manager: Show and install updates

You can check whether updates are available to install for systems or a group of systems:
1. From Update Manager, click Show and install updates, as shown in Figure 4-60.
Figure 4-60 Update Manager: Show and install updates
2. Select the system or the group of systems for which you want to update. In our example,
we select the Chassis group as shown in Figure 4-61. Click Show and Install Updates.
Figure 4-61 Show and Install Updates: System selection
122
3. The window expands to show the available updates for the systems that you selected. A
message appears if no inventory is available for these systems. You can select to start the
inventory collection.
In our example, the inventory was run before and one update is available for the group,
Chassis, which affects two systems (Figure 4-62).
Figure 4-62 Show and Install Updates window: Available update for selected systems
4. Multiple methods are available to install this update:

Click the check box next to the update package and click Install. This method is
easiest and, in our example, updates two chassis.
But, because the update is available for two systems, you might want to know which
system you are updating. Perhaps, you cannot update all systems at the same time for
business reasons. You can click 2 systems in the System column, as shown in
Figure 4-62.
123
A new window opens where the two systems are listed, as shown in Figure 4-63.
Figure 4-63 Updates for systems
Check the individual system or systems that you want to update and click Actions
Release Management Show and install updates. This action returns you to the
window that is shown in Figure 4-64. Click the check box next to the update and then
click Install to start the upgrade installation process.
Figure 4-64 Select Install to start the installation process
124
5. For either method, the Install Wizard window opens (Figure 4-65). On the Welcome panel,
click Next to proceed with the installation process.
Figure 4-65 Install wizard: Welcome panel
125
6. On Figure 4-66, you see the selected system. By default, the update process
automatically restarts the systems, if needed. The specific systems to update are listed,
and whether a restart is required is listed. If you clear the check box, the update is
installed. However, you get an error message that the system is not restarted if a restart is
required by the update process. You need to restart the system manually before the
update takes effect. Click Next to continue.
Figure 4-66 Install wizard: Restarts panel
126
7. A Summary window opens. Check the settings and the information of the update package.
Click Finish to start the installation upgrade (Figure 4-67).
Figure 4-67 Install wizard: Summary panel
127
8. The Schedule tab opens. Select whether to run the update now or at a defined time
(Figure 4-68).
Figure 4-68 Schedule tab
9. If you select Run Now, a window opens where you can see that the job is created and
started, as shown in Figure 4-69.
Figure 4-69 Job created and started
128
10.Click Display Properties to display the job properties where you can check the status and
the log for the job (Figure 4-70). You can see that if the update was not downloaded before
or imported, a download for the update package is started.
Figure 4-70 Active and Scheduled Jobs (Properties) panel: Job Steps tab to download updates
Using the compliance check to update

Compliance checks are described in 4.3.6, Compliance check on page 114). If you set up a
compliance check and a system is noncompliant, start here to update your system.
129
Follow these steps to update systems from the compliance check:

1. Click the link beside the red, yellow (in this example), or blue icon from the compliance
check that is shown in Figure 4-71.
Figure 4-71 Compliance check: Select a system with a problem
130
2. In the Navigate Resources window, you can see all the updates for the selected severity.
Our example shows five systems with minor severity compliance issues (Figure 4-72).
Click the check box next to the systems that you want to update. Then, click Actions
Release Management Show and Install updates.
Figure 4-72 Compliance check: Systems with minor severity updates
3. The Install wizard opens. The remaining steps are the same as described in Using
Update Manager: Show and install updates on page 122, starting with step 5 on
page 125.
Another way to update systems with compliance issues is to select the number beside the
icon in the status bar on top of the Systems Director home page, as shown in Figure 4-73.
Figure 4-73 Status bar: Compliance status
131
The Active Status window opens (Figure 4-74) to show the systems with a compliance issue.
This window differs from the window that you see when you select the compliance check from
Update Manager (Figure 4-71 on page 130).
Figure 4-74 System with minor severity compliance issues (example)
But, in our example, when you click the Minor link in the Severity column, you see the same
window as shown before. The way to update is the same as described earlier.
4.3.8 Updating systems that run AIX and Linux

How to update AIX and Linux systems is described.
Updating Linux systems

Systems Director can update the Linux operating system with the latest patches from either
Red Hat or SUSE. To use Update Manager in the Systems Director server for these updates,
the system that you want to update must be registered with the provider.
To download the updates from the provider, follow steps 1 - 3 in 4.3.4, Update Manager with
Internet connection on page 110.
132
In step 3, select the Red Hat and SUSE/Novell Linux updates in Update Manager that you
need for your systems, as shown in Figure 4-75.
Figure 4-75 Select updates for Linux OS
You can also set a compliance check for your system for Linux updates. If the system
discovers new Linux updates, use the same process for all other updates as described in
4.3.7, Update process on page 121.
Updating a system that runs AIX

The following page in the information center explains the requirements for updating AIX
Systems:
r.updates.helps.doc%2Ffqm0_c_um_considerations_for_updating_aix_systems.html
AIX updates can be downloaded automatically from within Systems Director or manually from
Fix Central:
http://www.ibm.com/support/fixcentral
When you download AIX fixes, ensure that you review your download options. This step is
critical to ensure that you select Include informational files, and files required by Systems
Director for installation. These files are needed to manually import AIX updates to Systems
Director from the command line.
The syntax for importing AIX updates is shown in Figure 4-76.
#smcli importupd -vr /tmp/updates/aix/7100-01-06-1241
Figure 4-76 Importing AIX updates
For updates for AIX, Update Manager is the focal point for centralized management, and
updates are performed by using NIM. Standard NIM troubleshooting procedures can be used,
as needed.
133
Tip: If you import updates from a Network File System (NFS) mount, be careful with
Secure Hash Algorithm (SHA). If the NFS mount is restricted, copy it locally to a temporary
position on the Systems Director server and import to eliminate SHA warnings.
4.3.9 Updating the Systems Director server

If you want to update the Systems Director server, use the Update IBM Systems Director
task. This task lets Update Manager use the defaults and run the update tasks for you
automatically.
This task is accessible from the Systems Director home page (Figure 4-77) and also from the
Update Manager page (Figure 4-78 on page 135).
Figure 4-77 Launching the Update IBM Systems Director task from the home page
134
Figure 4-78 Launching the Update IBM Systems Director task from the Update Manager page
When you launch the update task, the system checks for available updates as shown in
Figure 4-79.
Figure 4-79 Update status for Systems Director update
If no new updates are available, you see a message that is similar to Figure 4-80.
Figure 4-80 No updates are available
135
If new updates are available for your Systems Director server, you see a window similar to
Figure 4-81.
Figure 4-81 Update Systems Director
Follow these steps to install the updates:

1. Click Download and Install, as shown in Figure 4-81. You are reminded to back up your
server (Figure 4-82). We explain how to perform a backup in 4.7, Backup on page 233.
Figure 4-82 Information window about backup
2. Click OK to proceed to the Schedule window. Select Run Now and the updates are
downloaded and installed. Or, you can schedule the update to be performed in off-hours.
The status of the task is under Task Management Active and Scheduled Jobs.
3. After the upgrade completes, the Systems Director server must be restarted. The best
method is to use one of the following command-line commands:
Windows:
net stop dirserver Stop the Systems Director server.
net start dirserver Start the Systems Director server.
Linux and AIX:
smstop
smstart
Stop the Systems Director server.

Start the Systems Director server.
4. To check the status of the Systems Director, use the following command:
Windows:
The status icon is on the Windows panel. Use the smstatus.bat (-r) command to see
the status and the update of the status.
Linux and AIX:
Use the smstatus (-r) command to see the status.
After the Systems Director server restarts, check whether the new version is installed and
running. Check the version beside each manager on the home page. Or, check the
version.srv file in the directory where the Systems Director server is installed.
136
4.3.10 Downloading and staging updates manually

When planning for maintenance on your servers, you usually want to keep the change
window as small as possible so that your business does not have to suffer long service
outages.
Some driver and firmware updates can be fairly large, which means that unless you have
already installed them once, the night of the change, IBM Systems Director Update Manager
will require additional time to fetch those update packages from IBM Fix Central.
One way to work around this issue is to manually download the updates ahead of time so that
they are already available on your IBM Systems Director server when you need them:
1. First, figure out which updates you will require and, which are already downloaded. To do
so, select the server that you want to update in the resource explorer, right-click it, and
select Related Resources Updates, as shown in Figure 4-83.
Figure 4-83 Finding out which updates might be required on a given server
137
2. Review the list of applicable updates and whether they are already downloaded or not, as
Figure 4-84 Reviewing applicable updates
3. You can then select updates that have not been downloaded yet, click the Actions menu,
and select Download, as shown in Figure 4-85.
Figure 4-85 Downloading updates
138
Alternatively, if you already know which updates you need and want to simply select them to
download them, you can do so from the Update Groups view. This option is selectable from
the Update Manager main window, as shown in Figure 4-86.
Figure 4-86 The Update Manager main window
From this view, you are able to select and download all the updates that you want.
In addition to downloading updates, you can also pre-stage updates on a given server. This is
useful if the server you want to update is in a remote location and you also want to cut the
transfer time from the IBM Systems Director server to the managed endpoint.
To pre-stage updates, perform the following steps:
1. Discover applicable updates on your server by running an inventory and then navigating to
the Release Management Show and Install Updates view.
2. Select the updates that you want to stage and select Installation Staging from the
Actions menu.
3. Follow the wizard to the end to start scheduling the staging job. The updates will be copied
over to the managed endpoint and will be ready for installation.
Alternatively, you can select updates from the Update Groups view that is shown in
Figure 4-86 and select Installation Staging from the Actions menu to stage them on
multiple servers at once.
4.3.11 Command-line tools

Command-line tools are available for Update Manager as listed in Table 4-1.
Table 4-1 Command-line tools for Update Manager
Command
Description
checkupd
Check changed and superseding updates.
cleanupd
Clean (that is, delete) update files and information in the local update library.
importupd
Import updates into the update library on the management server. This
command is used if no Internet access is available.
139
Command
Description
installneeded
Update the Systems Director server and agents or use this command to install
other types of updates.
installupd
Install one or more updates to one or more systems.
lsupd
List the available updates and their attributes.
lsver
List the current version and, if you updated the product, the previous version of
Systems Director that is installed on the system.
uninstallupd
Use to uninstall (roll back) an update on a specific system if the update package
supports the rollback.
For detailed information about all the smcli command-line commands that are used for the
Update Manager and their options, see the information center:
r.cli.helps.doc%2Ffqm0_r_cli_update_cmds.html
Certain functions are only available by using the command line. One example is cleaning or
deleting the local update library. Use this function if multiple downloaded updates are not
used or if you are running out of storage. After you clean the library, run a check for updates to
fill the library with new update information. The information from the library is used for the
compliance check.
In Example 4-1, we clean up the library and then start a check for new updates from the
command line. You can also run the check for new updates in the browser interface as
described in 4.3.4, Update Manager with Internet connection on page 110.
In Example 4-1, we first list the updates that are downloaded to the local update library with
the smcli lsupd command. For brevity in this example, some output lines are not displayed
(200 packages are available).
Example 4-1 smcli lsupd command
PS C:\Windows\system32> smcli lsupd
SysDir6_3_1_Platform_Agent_Windows
SysDir6_3_1_Platform_Agent_xLinux
SysDir6_3_Platform_Agent_AIX
SysDir6_3_Platform_Agent_Windows
SysDir6_3_Platform_Agent_pLinux
SysDir6_3_Platform_Agent_xLinux
SysDir6_3_Platform_Agent_zLinux
agentmanager.feature_6.3.1
bnt_fw_bcsw_110gup-6.3.1.1_anyos_noarch
bnt_fw_bcsw_24-10g-6.9.1.0_anyos_noarch
bnt_fw_torsw_g8264-6.8.4.0_anyos_noarch
bnt_fw_torsw_g8316-6.8.4.0_anyos_noarch
brcd_fw_6.3.1-dcb2_anyos_noarch
brcd_fw_bcsw_sansm-505a_anyos_noarch
cigesm-i6q4l2-tar.121-22.ea13
com.ibm.aem.common_4.4.1
com.ibm.aem.console_4.4.1
.....
140
Then, we clean up the library by using the smcli cleanupd -am command, as listed in
Example 4-2. This command needs time to delete all packages and remove the index file.
After running the cleaning of the local library (smcli cleanupd -am), we check with the smcli
lsupd command whether update packages are still available. You can see in the example that
after cleaning, no installation package is available.
You can clean up only one or some of the installation packages that are in the local library.
Use -w %packagename% instead of the -am option.
Example 4-2 smcli cleanupd -am command
PS C:\Windows\system32> smcli cleanupd -am
PS C:\Windows\system32>
We start to download new packages by using the smcli checkupd -a command, which
checks the IBM repository for all updates. You can also use other options, such as the -N
groupname, to check only for updates for a member of a defined group (Example 4-3).
Example 4-3 smcli checkupd -a command
PS C:\Windows\system32> smcli checkupd -a
PS C:\Windows\system32>
The -a option needs a long time to finish. No output is listed during the download process if it
is run on the command line. You can see that the command is finished only when a new
command prompt is visible.
When the command is finished, check which updates are downloaded by running the smcli
lsupd command (Example 4-4). You can see examples from the listing to show the different
types of updates that are downloaded. In this example, over 500 update packages are
available (for Linux, AIX, firmware, driver, Director, and VIOS).
Example 4-4 smcli lsupd command with examples for different downloads
01AF743_100_100
01AF743_105_100
....
032512EE02F845008725779E00509382_AIX
032512EE02F845008725779E00509382_LNX
03F50ADC70A9CEA9872577B200727962_AIX
....
MH01084
MH01097
MH01101
MH01102
....
U823341
U824377
U824378
....
VIOS_2.2.1.3-FP25-SP01
VIOS_2.2.1.4-FP25-SP02
VIOS_2.2.2.1-FP26
....
agentmanager.feature_6.3.1
....
141
.....
com.ibm.aem.common_4.4.1
com.ibm.aem.console_4.4.1
com.ibm.aem.discovery_4.4.1
....
com.ibm.director.storage.storagecontrol.member.AIX_4.2.2.build-00119
com.ibm.director.storage.storagecontrol.member.Linux_4.2.2.build-00095-20120516-iFix
....
csco_fw_bcio_12.2.50se1_anyos_noarch
ibm_fw_amm_bpet62t_anyos_noarch
ibm_fw_bcio_N4K_4.1.2.E1.1i_anyos_noarch
ibm_utl_uxspi_9.21_rhel5_32-64
ibm_utl_uxspi_9.21_sles11_32-64
ibm_utl_uxspi_9.21_winsrvr_32-64
4.3.12 Best practices for Update Manager

The following best practices enable you to use the Update Manager task efficiently:
Make all necessary configurations for the Update Manager before using it.
Set up the Internet connection, the settings for the local repository, and necessary settings
for the BladeCenter, AIX, or VIOS to prevent problems during the installation process.
Test the Internet connection (when available).

The Internet connection is necessary for the download of the latest information about
available updates.
Configure the Update Manager for scheduled checks for new updates, at minimum once a
week.
This helps to stay up-to-date with the update information and is necessary for the
compliance check.
Set the scheduled download in off-hours.

Prevent the environment from high network utilization and when the director download
begins only update information.
Be aware that the inventory is up-to-date.

This is necessary for the compliance check as part of the Update Manager. The
compliance check works as a background process and compares the information from the
repository with the inventory information of the systems (see best practices for inventory).
Hold the IBM Systems Director up-to-date by using the IBM Systems Director update task.
For the IBM System x server and Flex System compute nodes, ensure that you leave
LAN over USB enabled in the management processor configuration.
Download manually your updates ahead of time and consider staging updates to keep
your maintenance window as small as possible.
Configure the compliance check that fits your requirements.
142
4.4 Event management

This section explains what type of events are collected by IBM Systems Director and covers
best practices on how to integrate with your existing event management system.
To assist the system administrator, IBM Systems Director provides the Event Automation Plan
wizard as a quick and easy way to create event automation plans that meet most system
management needs.
By using the Event Automation Plan wizard, you can create plans that monitor for the most
typical situations in systems management environments, including, but not limited to, the
following examples:
Critical hardware events from all systems in your environment.
Processor (CPU) utilization in a specific group of systems, such as all servers running
Linux.
All Common Agent-managed systems to determine if Common Agent goes offline.
The status of updates that are underway.
Disk space usage in systems, such as those that store database data.
You can then configure actions to be performed based on the situation. For example, actions
could send a page or email message, or start a program on a system.
4.4.1 Light path diagnostics

IBM x86 servers provide a diagnostic tool called light path diagnostics (LPDs) as an easy
way to find hardware problems on the systems when they occur. LPDs consist of three
components:
A system warning LED on the front of the server.
A panel of LEDs in a pop-out panel (or a panel inside or outside the server for some
systems). This panel shows the status of major subsystems, for example, memory.
Individual LEDs beside each component in the system, for example, each memory dual
inline memory module (DIMM).
For information about the LPD LEDs that are available on your System x, BladeCenter, or
Flex System hardware, see the server documentation.
IBM Systems Director can read this LPD information. This information is provided by the
service processors that are integrated in the server:
Integrated management module (IMM)

IMMv2
Advanced management module (AMM)
Chassis management module (CMM)
You can view LPD status information from the Systems Director user interface (UI) or the
command-line interface (CLI).
There are multiple ways to select the detailed LPD information:
From the health summary, click LED status in the scoreboard.
From the Resource Explorer window, in the LED Status column, click the red, yellow, or
blue icon.
143
From the right-click menu of a system, go to System status and health Lightpath.
From a command-line prompt, use the smcli lsled command.
Each method is described in the following sections.
LED status in the scoreboard

On the home page of Systems Director, the health summary scoreboard shows a summary of
systems with LPD alerts under the name LED Status. Figure 4-87 shows an example.
Figure 4-87 Scoreboard that shows the LED status
When you click LED Status, a window opens that shows systems with alerts, as shown in
Figure 4-88.
Figure 4-88 Systems with problems
If you click the LED status of the individual systems, you see the specific alert details as
reported in the lightpath view, as shown in Figure 4-89.
Figure 4-89 Lightpath detailed view
144
LED status in the Resource Explorer

To view the LPD status and information, first add a column for LED status to the Resource
Explorer view for a group. When you are in a group in the Resource Explorer window, click
Actions Columns, as shown in Figure 4-90.
Figure 4-90 Select to add columns to the group view
In Figure 4-91, select LED Status from the Available Columns list on the left. Click Add to
add LED Status to the Selected Columns list. Use Up and Down to change the relative
position of the column. Click OK to save the changes. See Figure 4-91.
Figure 4-91 Select LED Status to add a column to the Resource Explorer view
145
Now, the new LED Status column is displayed in the Resource Explorer window as shown in
Figure 4-92.
If a critical, warning, or informational status message from a managed system exists on the
LPD panel, you see the status. The status displays as a red, yellow, or blue icon in the LED
Status column. See Figure 4-92.
Figure 4-92 LED Status column in Resource Explorer
After you add the column, you can click the status to see the detailed view (Figure 4-89 on
page 144).
LED Status from the menu of a system

To see the LED status and detailed information for a single system, right-click the system and
click System Status and Health Lightpath. See Figure 4-93 on page 147. The window
that opens is similar to the window from our example that is shown in Figure 4-89 on
page 144.
146
Figure 4-93 Lightpath menu for a single system
SMCLI command-line interface

You can also use the smcli lsled CLI command to see the LED status for a system. The
results of our example are shown in Example 4-5.
Example 4-5 is the output from the command for a BladeCenter chassis that shows the status
of all LEDs. This output shows that the Information and Fault LEDs for this system are on. The
output also shows that the LEDs are on the front panel of the system.
Example 4-5 smcli lsled CLI command
PS C:\Windows\system32> smcli lsled -s all -i 9.42.171.73
----------------------------------------------------------------System Name: BC5AMM---------------------------------------------Name
State
Color
Location
Over Temp
Off
Orange
FrontPanel
Information
On
Orange
FrontPanel
Location
Off
Blue
FrontPanel
Fault
On
Orange
FrontPanel
-----------------------------------------------------------------
147
If you want to see only the LEDs that are on or flashing, use the -s all, -s on, or -s flash
option for this command. Or, use -s on, flash to see all LEDs that are on and blinking. In this
example, we use the following command to make the LED on a remote server blink:
smcli runtask -i 9.42.171.173 "LED Flash"
Then, we run the smcli lsled command with the -s flash option again. Example 4-6 shows
the result.
Example 4-6 smcli lsled -s flash option
PS C:\Windows\system32> smcli lsled -s flash -i 9.42.171.73
----------------------------------------------------------------System Name: BC5AMM----------------------------------------------
Name
State
Color
Location
Location
Blinking
Blue
FrontPanel
-----------------------------------------------------------------
For detailed information about the options for the smcli lsled command, see the information
center:
r.cli.helps.doc%2Ffqm0_r_cli_lsled.html
4.4.2 Hardware logs

Hardware log information is provided by the service processors from the systems. The
following service processors and management modules provide the hardware log information
to the Systems Director:
Baseboard management controller (BMC)
Remote Supervisor Adapter II (RSA II)
Remote Supervisor Adapter (RSA)
Management module (MM)
Integrated management module (IMMv1 and IMMv2)
Power Systems: LPD information for Power Systems is not accessible, except for IBM
POWER based servers in the BladeCenter and Flex System.
The information is provided by using an inband communication or out-of-band
communication. The access path depends on the system hardware and configuration. See
Table 4-2.
Table 4-2 Service processor hardware log access path
Systems
Service processor
Hardware log access path
BladeCenter
MM
Out-of-band communication
BladeCenter
AMM
Flex System
CMM
Out-of-band communication, only if no Flex System

Manager (FSM) is installed and used
148
Systems
Service processor
Hardware log access path
System x
RSA
System x
RSA II
System x
BladeCenter
BMC
Out-of-band communication. Inband communication that

uses Common Agent or Platform Agent
System x
IMMv1 or IMMv2 in rack or tower server
Out-of-band communication. Inband communication that

uses Common Agent or Platform Agent
BladeCenter
Flex System
Flex System and BladeCenter IMMv1 or

IMMv2 in server
Out-of-band communication over AMM/CMM only.

Inband communication that uses Common Agent or
Platform Agent
Inband communication means that Systems Director accesses the agent on the system. This
agent can read the hardware log information from the service processor (RSA, RSA II, IMM,
IMMv2, or BMC) of the system. The agent uses a driver or other communication channels
inside the system.
Out-of-band communication means that a direct connection exists from the Systems Director
to the service processor over a TCP/IP communication. This communication is independent
from the system state (power on/off). This communication is also independent from the
operating system (running, starting, stopped). The minimum requirement is that the system
has power and the Systems Director can access the service processor.
To access the hardware log information inband, you must have full access to the system and
the system must be online. If you obtain the hardware log out-of-band, you can also access it
from the System x server when this server is powered off. In Table 4-3, you can see which
resource you must select to access the hardware log information.
Table 4-3 Selection of system resources for accessing the hardware log
Option
Description
Inband communication
Select the system that represents the Common Agent or Platform

Agent.
with a system
Click the system, then select service processors or select the

server.
with a BladeCenter chassis
Select the chassis.
149
Follow these steps to access the log information:

1. From the Resource Explorer window, right-click the system and click Systems Status and
Health Hardware Log (Figure 4-94).
Figure 4-94 Select hardware log
150
2. The window in Figure 4-95 opens to show the log entries that the Systems Director reads
from the service processor.
Figure 4-95 Hardware Log window
3. You can refresh the view, clear the entire log, or filter the view by using the Search
function. You can also sort the view by clicking any of the column headings. From the
Actions menu (Figure 4-96), you can export the log for problem determination. You can
send the exported log information to IBM Support, if requested. The information is saved
in CSV format.
Figure 4-96 Save hardware log
151
4.4.3 Event logs

You can work with the event logs that the Systems Director stores on the server. One
predefined event action plan is available with the action Log All Events. This event action
plan writes all events of the Systems Director server to a local event log.
Settings
Configure the settings for the event log in the left pane of the Systems Director web interface
by clicking Settings Event Log Preferences (Figure 4-97).
In the Settings window (Figure 4-97), you can select the time range that is reflected in the
event log listings. Set a time range for hours, days, or weeks.
Figure 4-97 Settings for event log preferences
You can set the number of event log entries to retrieve. The maximum number for the server is
10,000 entries. If you set more than 10,000 entries, you see an error message (Figure 4-98).
Figure 4-98 Error message when the number of entries exceeds the maximum number of 10,000
The default settings are 24 hours and 500 entries for the event log. You can go back to the
default values by clicking Restore Defaults.
152
Launching the event log

You can access the Systems Director event log in a number of ways:
From the left pane, click System Status and Health Event Log (event log for All
Systems).
From the Resource Explorer menu, right-click a group (event log for the complete group)
or a single system (event log for this system). Click System Status and Health Event
Log (Figure 4-99).
Also, from the Resource Explorer, select the group or system and click Actions
System Status and Health Event Log to access the event log.
Figure 4-99 Event log access
153
Also, from the Resource Explorer, double-click a single system to see the properties of the
system. Select the Event Log tab to access the event log for this system, as shown in
Figure 4-100.
Figure 4-100 Event Log access for a single system
Viewing the event log

When you elect to view the event logs of multiple systems, a new window opens that shows
the event log (Figure 4-101 on page 155). All events are listed for the selected time range.
Events are listed up to the maximum number that is set for the event log.
154
The event filter is at the top of the window (Figure 4-101). The use of the event filter is
described in Using event filters on page 156. You can sort the events by date and time
(default), by severity, or by source and category. Select the column and click the arrow in the
top cell of the column. You can also use the search function to find specific events.
Figure 4-101 Event Log window
155
Using event filters

You can use the event filter to select specific events. With filters, you can easily display only
the event log entries that are important to you. With filters, you can easily export log entries
for documentation.
The available filters are the same filters that are available in the event filter for the event
automation plan. Any filters that you create for event automation plans are also visible and
usable in this list. Figure 4-102 shows the filter list.
Figure 4-102 Filter list
In our example, we select the critical events as a filter for the event log viewer. The result is
shown in Figure 4-103 on page 157. You can see the critical events that are available in the
event log of the Systems Director server.
156
You might see some events with HIST: in front, as indicated in Figure 4-103. These events are
historical events. Historical events come from system logs from systems that are based on a
time range before the actual Systems Director is active.
Figure 4-103 Critical event filter is used on the event log
Creating a filter by using an event from the event log

With Systems Director, you can create an event filter that is based on an existing event. This
event filter can help you identify all of the events of the same type (for export, as an example).
157
To create a filter, go to an event and use the following steps:

1. From an existing event, right-click the event and in the pull-down menu, select Create
Filter. Or, select the event by clicking the adjacent check box and click Action Create
Filter. See Figure 4-104.
Figure 4-104 Select event to create a filter
158
2. Enter a name and a short description for the filter (Figure 4-105). Click OK to create the
event filter that is based on the selected event. The definition for this event is at the bottom
of the window.
Figure 4-105 Creating a filter from an event
3. A message appears that the event filter is created successfully (Figure 4-106).
If there are problems, you see an error message instead. Fix the problem and create the
event filter after you fix the problem.
Figure 4-106 Creation of filter successful
Hardware event filters

If you are planning to use IBM Systems Director to perform hardware monitoring and you
want to integrate it with an event management tool, there is a list below of recommended
filters to configure your event filter from your automation plan. After it is configured, you can
add or remove filters that are based on your needs:
Managed Resource.Managed System Resource.Physical Resource
Managed Resource.Managed System Resource.Logical Resource:
Service Access Point
System
Service
Logical Device:
Processor
Logical Module
Logical Port
Unknown
Sensor
159
160
Storage Extent
Battery
Controller
Media Access Device.OpticalDevice
Media Access Device.Physical Volume
Media Access Device.Disk Drive (RAID Subsystem Drive Bad Block:
FullReassigned)
Media Access Device.Disk Drive (RAID Subsystem Drive Synchronization:
DetectedFailedCompletedStopped)
Media Access Device.Disk Drive (Disk Drive Mounting Events: Mount as Global
SpareUnmount Global SpareMount as Local SpareUnmount Local Spare)
Media Access Device.Disk Drive (RAID Subsystem Drive Clear:
DetectedFailedCompletedStoppedStartedProgressAborted)
Media Access Device.Disk Drive (RAID Subsystem Drive Verify:
DetectedFailedCompleted)
Media Access Device.Disk Drive (Life Cycle: RemovedAdded)
Media Access Device.Disk Drive (RAID Subsystem Drive Format:
StartedCompleted)
Media Access Device.Disk Drive (Operation: ActivatedDeactivated)
Media Access Device.Disk Drive (RAID Subsystem Global Hot Spare:
CreatedDeactivatedNot CoveringCommissioned)
Media Access Device.Disk Drive (RAID Subsystem Hot-Spare Drive:
AddedRemovedFailed)
Media Access Device.Disk Drive (RAID Subsystem Drive Patrol Read:
ProgressError)
Media Access Device.Disk Drive (Operational Condition: CRC ErrorParity
ErrorConfiguration ErrorFailedPredictive Failure Analysis (PFA))
Media Access Device.Disk Drive (RAID Subsystem Life Cycle:
RemovedAddedError)
Media Access Device.Disk Drive (Power: OnOff)
Media Access Device.Disk Drive (RAID Subsystem Configuration: Unsupported
DriveDrive Too SmallDrives Missing)
Media Access Device.Disk Drive (RAID Subsystem Microcode Update:
DetectedFailedCompletedStopped)
Media Access Device.Disk Drive (RAID Subsystem Drive Redundant Path:
BrokenRestoredUnabled Accessed)
Media Access Device.Disk Drive (RAID Subsystem Copyback:
DetectedFailedCompletedStoppedProgress)
Media Access Device.Disk Drive (RAID Subsystem Operational Condition:
Predictive Failure Analysis (PFA)StatusInitialization CompletedInitialization
StartedInitialization FailedFailed)
Media Access Device.Disk Drive (RAID Subsystem Drive Security:
ActivatedDeactivatedFailed)
Media Access Device.Disk Drive (RAID Subsystem Dedicated Hot Spare:
CreatedDeactivatedNot UsefulImported)
Media Access Device.Disk Drive (RAID Subsystem Drive Security Key:
CreatedBacked UpVerifiedChangedFailedInvalidDestroyed)
Media Access Device.Disk Drive (RAID Subsystem SAS Port: Lost LinkRestored
LinkError)
Media Access Device.Disk Drive (Updates: InstallationTask Failed)
Fan (Operational Condition: Power Predictive Error)
Fan (Operational Condition: Power Unrecoverable Error)
Fan (Operational Condition: Predictive Failure Analysis (PFA))
Fan (Operational Condition: Configuration Error)
Fan (Operational Condition: Returned To OK)
Fan (Operational Condition: Degraded)

Fan (Operational Condition: Speed)
Fan (Operational Condition: Failed)
Fan (Operational Condition: No Error or Informational)
Fan (Operational Condition: Non-Serviceable)
Fan (Operational Condition: Power Diagnostics Test)
Fan (Operational Condition: Redundancy)
Power Supply
Figure 4-107 Create a customized event filter
Note: Multipath monitoring (MPIO) should be performed from the switch devices, not from
IBM Systems Director.
Command-line tools
The following command-line commands are available to work with the Systems Director event
log:
smcli evtlog
smcli lsevtlog
smcli rmevtlog
Set parameter for event log

List event log
Delete entries or complete event log
Example 4-7 shows the following information:

The actual size with the -s option. Our example shows 791 entries in the event log.
The setting for the maximum value with the smcli evtlog -m command.
The command to set the maximum to a new value, in our example, 9500 with the -M 9500
option.
Example 4-7 Example for the smcli evtlog
SLES11:/opt/ibm/director/bin #./smcli evtlog -s

791
SLES11:/opt/ibm/director/bin #./smcli evtlog -m
161
10000
SLES11:/opt/ibm/director/bin #./smcli evtlog -M 9500
SLES11:/opt/ibm/director/bin #./smcli evtlog -m
9500
SLES11:/opt/ibm/director/bin #
You can use the smcli lsevtlog command to read the event log. The following options are
useful:
-e EventFilter_name
Show events only for this event filter
-s
Present a summary view of the event
-T
Filter for a time range (value in hours)
-o
Display the unique IDs that are associated with the event-log
entries in addition to other information
-t
Filter on a system type, such as operating system
In Example 4-8, we use the -e CriticalEvents -T 192 -o parameters. These parameters

list all critical events in the last 192 hours and the object identifiers (OIDs) for the events.
Example 4-8 shows one critical event in the specified time range. The OID for this event
(0x2ab) is listed.
Example 4-8 smcli lsevtlog command
SLES11:/opt/ibm/director/bin #./smcli lsevtlog -e Critical Events -T 192 -o

11/17/12 12:01 PM, One or more blade servers are isolated from the management
bus., SN#YK168387X1TB (0x175b), Managed Resource.Managed System Resource.Physical
Resource.Physical Package.Physical Frame.Chassis (OperationalCondition: CommBus),
Critical-Alert, 0x2ab
Example 4-9 shows how to delete an event from the event log with the smcli rmevtlog
command.
Use this command if many events of the same type are in the log and you want to clean up
the log. Or, you generated test log entries that you want to delete from the log.
You can use the -a option to delete the complete log or use the -e %event_oid% option to
delete specific events. In our example, we use the -e option to delete the event that is listed in
Example 4-8. After we remove the event from the log with the 0x2ab OID, we run the smcli
lsevtlog command to list the event, as shown in Example 4-9. The example shows that this
event does not exist anymore.
Example 4-9 Example for the smcli rmevtlog command
SLES11:/opt/ibm/director/bin
#./smcli rmevtlog -e 0x2ab

#
#./smcli lsevtlog -e Critical Events -T 192 -o
#
For detailed information about the commands in our example, see the Systems Director
Information Center:
r.cli.helps.doc%2Ffqm0_r_cli_event_log_and_history_cmds.html
162
4.4.4 Automation Manager

Use Automation Manager to create and use event automation plans.
The event automation plan consists of two parts:
Event filter
Event action
You can create and assign the event automation plan, event filter, and event action through
the graphical user interface (GUI) or through the command line.
The following topics are described:
Creating an event automation plan on page 163

Creating an event filter on page 174
Creating an event action on page 184
Using the CLI for event automation plans on page 190
Creating an event automation plan

To view and create the event automation plan, go to the Systems Director web interface.
Select either Automation Event Automation Plans on the left pane or the Event
Automation Plans link under the Automation Manager, as shown in Figure 4-108.
Figure 4-108 Launching Automation Manager
You can see the existing event automation plans, the targets to which they are assigned, the
status of the plan, the time range that is defined for the plan, and a description, if available.
163
You can edit an existing event automation plan, create an event automation plan that is based
on an existing event automation plan, or create an event automation plan.
In our example, we create an event automation plan that is named book-EAP:
1. In the Event Automation Plans window, click Create (Figure 4-109).
Figure 4-109 Event Automation Plans window
2. The Create Event Automation Plan wizard opens at the Welcome window (Figure 4-110).
Figure 4-110 Create Event Automation Plan wizard: Welcome panel
164
3. In the Name and Description step (Figure 4-111), give your event automation plan a name
and suitable description. In our example, we name the event automation plan that we
created, book-EAP. Click Next to continue.
Figure 4-111 Create Event Automation Plan wizard: Name and Description
165
4. In the next window (Figure 4-112), define the targets for which this event automation plan
works. You can select groups or an individual system as the target for this event
automation plan.
Selecting groups can be helpful when you have different administrative or management
groups. In our example, we select All Systems. To select systems or a group, select the
system or group in the left column and then click Add. When finished, click Next.
Figure 4-112 Create Event Automation Plan wizard: Target selection
166
5. In the Events window (Figure 4-113), select the filter for events.
Various filter types are available:
Common event filters are predefined filters that monitor for common functions, such as
hardware events. Examples are fan failures or processor usage (Figure 4-113). The
common event filters are predefined and cannot be changed or enhanced. If you need
more complex criteria, select Advanced Event Filters. You can select some of the
common event filters to use in an event automation plan.
Figure 4-113 Create an event automation plan: Common filter
167
Advanced event filters are used for monitoring specific events, single system events, or
events that are based on severity (Figure 4-114). Predefined common event filters are
available, but you can edit or enhance the advanced event filter. Only one advanced
event filter can be selected for an event automation plan.
Figure 4-114 Create Event Automation Plan wizard: Advanced event filter
When you select the advanced event filter, you can use predefined filters or create your
own. How to create your own filter is described in Creating an event filter on page 174.
In our example, we created the event filter named Filter for book. When you select the
filter that you want to use, click Next.
168
6. In Figure 4-115, specify the event action for the event automation plan to perform on the
target systems when the filter criteria is met. By default, Systems Director comes with only
one predefined event action, which is named Add to the event log. Select an existing
event action or create an event action. Creating an event action is described in Creating
an event action on page 184.
In our example, we use the created event action named Mail to book (Figure 4-115). You
can select more than one action for an event automation plan. All of the selected actions
run if the event that is monitored and filtered occurs.
After you select the action that you want to use, click Next.
Figure 4-115 Create Event Automation Plan wizard: Event Actions selection
169
7. On the next window, specify when the event automation plan can be activated. This
time-range constraint can be helpful if you use one event automation plan for work days
and another event automation plan for the weekend. You can create the event automation
plan that works from Monday to Friday. And, you can create another event automation plan
that works from Saturday to Sunday (Figure 4-116).
In our example, we choose All the time (24x7). But if you want, you can change it later by
editing the created event automation plan. After you select the time range, click Next.
Figure 4-116 Create Event Automation Plan wizard: Define a time range
170
8. In the next window (Figure 4-117), you see the summary for the event automation plan
that you defined. Specify whether to activate the event automation plan by selecting the
check box (default) after you click Finish.
Figure 4-117 Create Event Automation Plan wizard: Summary view
171
9. Now, you are back on the Event Automation Plans window. You can see the new event
automation plan that you created (Figure 4-118).
Figure 4-118 Event Automation Plans window
The event automation plan is active and works for the defined systems and executes within its
stated time period.
You can create as many event automation plans as you want, but keep the number of event
automation plans to a minimum. If you have too many event automation plans, it can get
confusing and you might get multiple alerts for each event.
172
You can use the GUI to export the event automation plan as a CSV file to use for
documentation. On the Event Automation Plans window, select the plans that you want to
export by clicking the associated check box. Then, select Actions Export, as shown in
Figure 4-119.
Figure 4-119 Export the event automation plans
A window opens so that you can select the directory where you want to save the event
automation plan (Figure 4-120). The name of the file is Event_Automation_Plans.csv.
Figure 4-120 Save the Event_Automation_Plans.csv file
173
If you want to export the event automation plan for use on another system or for backup and
recovery, use the smcli command line. The use of the smcli command line is described in
Exporting systems and settings on page 239, and in Importing systems and settings on
page 242.
Creating an event filter

You can create an event filter from within the Create Event Automation Plan wizard. Or, select
Automation Event Filters on the left tab of the Systems Director home page, as shown in
Figure 4-121.
Figure 4-121 Selecting event filters
174
From this link, you are taken to the Event Filters page (Figure 4-122). Figure 4-122 shows the
same list of filters in the Create Event Automation Plan wizard (Figure 4-114 on page 168).
Follow these steps to create an event filter:
1. As shown in Figure 4-122, click Create to create an event filter.
Figure 4-122 Listing of the event filters
175
2. The Create Event Filter wizard starts and displays the Welcome page (Figure 4-123). Click
Next to continue.
Figure 4-123 Create Event Filter wizard: Welcome window
3. In the Filter Name window (Figure 4-124), enter the name and the description for the filter.
In our example, we use the name Filter for book. You can also add a short description
for the filter. Click Next to continue.
Figure 4-124 Create Event Filter wizard: Filter Name window
176
4. In the Filter Type window (Figure 4-125), select the type of filter that you want to create.
We select Simple event filter for our example.
Figure 4-125 Create Event Filter wizard: Filter Type window
The following types of filters are available. Select the filter type and click Next.
Simple event filter: Use the general-purpose filter to create your own filter.
Recurring event filter: Use this filter to trigger only when the included event meets the
filter criteria more than one time in the defined time range.
Duplication event filter: Use this filter to ignore duplicate events.
Exclusion event filter: Use this filter to exclude a specific event type from a larger list of
event types that you included in the event.
177
5. In the Event Type window, Figure 4-126, select the filter type and define the filter type that
you want use. The following event types are available:
Default: Include all events except IBM System i message queue events, which can be
selected by clicking the check box, and Windows specific events. If you need to select
the Windows specific events, use the Custom type.
Common: Include events that are often used in the custom environment. The custom
environment events include general events, such as information about updates or user
security events. General events also include hardware events, such as power, storage,
fan, or processor events. You can add the system message events.
Custom: Include events of a certain category, type, or value. The available events
depend on the system types, operating systems, or protocols that you use in your
Systems Director environment.
Our example that is shown in Figure 4-126 uses the default events. We select the Default
filter type, which includes all events. Click Next to continue.
Figure 4-126 Create Event Filter wizard: Event Type selection
178
6. In the Severity and Category window (Figure 4-127), select the severity and category for
the filter. Various severities are available for events in Systems Director:
Fatal
Critical
Minor
Warning
Informational
Unknown
Two event categories are available:

Alert
Resolution
In our example, we use the Fatal, Critical, and Warning severities and the Alert category,
as shown in Figure 4-127. Click Next to continue.
Figure 4-127 Create Event Filter wizard: Severity and Category selection
179
7. In the Event Sender window (Figure 4-128), select the system that you want to include in
this filter:
Default: Includes all systems that Systems Director discovered or can access.
Custom: Select individual systems or groups to include in this filter.
If you select Custom, the window expands (see Figure 4-128). On the left, you see a box
to enter additional systems and a list of systems. Select the systems and click Add to add
these systems to the Selected senders list. The filter works for only these systems.
In our example, we use Default to select all systems because we use the filter in the
event automation plan. In the event automation plan, you can also select the systems for
which the event automation plan works. If you select specific systems on this window and
different systems in the event automation plan, no events are handled through the event
automation plan. Therefore, if you plan to use the filter in an event automation plan, leave
the selection that is shown in Figure 4-128 as Default. Use Custom when you want to
use the filter for event capture only. Do not use Custom in an event automation plan with
event actions that use it.
Figure 4-128 Create Event Filter wizard: Event Sender selection
180
8. In the Event Text window (Figure 4-129), select the event text. Two selections are possible:
Default: Include all event text.
Custom: Filter for specific event text. You might be interested in this option if you want
only specific events from systems. Select Custom to specify a word, separate words, or
a phrase that you want to include in the filter. The filter is triggered by only those events
that you include in the filter that also contains the specified text.
In our example, we leave the selection on Default. Therefore, we want to get all alerts from
the alert type that we chose earlier. Click Next to continue.
Figure 4-129 Create Event Filter wizard: Event Text selection
181
9. In the Time Range window (Figure 4-130), select a time range for the filter. You can either
select All (the default), which is 24x7, or Custom. If you select Custom, you can define
the days or hours that the filter works.
In our example, we use the filter that is in the event automation plan; therefore, we keep
the All setting on Figure 4-130. We also can set a time range in the Event Automation Plan
wizard. We do not want a conflict between the settings in the filter and the settings in the
event automation plan. The setting in Figure 4-130 is used if you use a filter only to
capture events and not with an action.
Figure 4-130 Create Event Filter wizard: Time Range selection
182
10.The last window of the wizard shows the summary view for the filter that you defined
(Figure 4-131). Check the settings and information and click Finish to create this filter.
Figure 4-131 Create Event Filter wizard: Summary view
The filter is created. The filter is available in the list of the filters and can be used in event
automation plans.
183
Creating an event action

You can create event actions in the Create Event Automation Plans wizard or select the Event
Actions link on the left panel of the Systems Director home page (Figure 4-132).
Figure 4-132 Selecting event actions
184
From this link, you are taken to the Event Actions page (Figure 4-133). This list shows the
same actions in the Create Event Automation Plans wizard (Figure 4-115 on page 169).
Figure 4-133 Event Actions
Follow these steps to create an event action:

1. Click Create (see Figure 4-133) to create an event action. Or, select an existing action and
click Edit to change an existing action.
185
2. Figure 4-134 opens with the available event actions.
Figure 4-134 Create Action window (Page 1 of 2)
186
Page 2 of the list of available actions is shown in Figure 4-135.
Figure 4-135 Create Action window (Page 2 of 2)
187
3. Select an action and click OK. In our example, we choose Send an e-mail (Internet
SMTP), as shown in Figure 4-136.
Figure 4-136 Select an action to configure
188
4. The configuration window opens for your selected action. The content of the window
varies depending on the action that you select. Our example shows the settings for the
Send an e-mail (Internet SMTP) action (Figure 4-137).
Figure 4-137 Configuration window for the Send an e-mail (internet SMTP) action
Set the following information for this example:

Type a name for the action. In our example, we type Mail to book.
Optional: Type a description for the action. We enter Mail for demo purpose.
Enter the send-to email address. We enter [email protected].
You must enter a Reply-to email address. This email address is listed as the sender of the
email. This email address must be in the correct format but the email address does not
need to exist. For example, you can use [email protected]. We use
[email protected].
Enter the Simple Mail Transfer Protocol (SMTP) server that is used in your environment.
We use smtp.itso.ral.ibm.com.
189
Enter the port that is used by the SMTP server. The standard port for SMTP is port 25.
The next entry is for the subject of the message. The default subject line is &date &system,
which prints the actual date and the system name that sent the event. You can add
additional variables or write your own text. The complete list of variables is at this website:
ctor.automation.helps.doc%2Ffqm0_c_ea_event_data_substitution_variables.html
As an alternative to typing the variables, the window also includes two list boxes, Event
variable and Target text field. Click Insert to insert the variable for you.
Type the body of the message. The default is &text (the event text). In our example, we
use a combination of text and variables:
&date &time message from &system
message: &text
The last two fields specify the language and the time zone. Our example uses English and
EST- Eastern Standard Time- EST.
Test the event action to confirm that the settings are valid. You can view the resulting email by
clicking Test. The email that we received from our test is shown in Figure 4-138.
Figure 4-138 Test email from an event action
After you confirm that the event action works correctly, click OK to save the changes. The
action is then shown in the list of available actions.
Using the CLI for event automation plans

There are several available smcli commands that you can use to work with event automation
plans (Table 4-4).
Table 4-4 Command-line tools for event automation
Command
Purpose
For event automation plans
190
lsevtautopln
List information about an event automation plan.
mkevtautopln
Create an event automation plan.
rmevtautopln
Delete one or more event automation plans.
evtautopln
Apply one or more event automation plans to a system or a group. Use this
command to remove systems or groups from an event automation plan or activate
or deactivate an event automation plan.
chevtautopln
Change an existing event automation plan.
Command
Purpose
For event filters

lsevtfltr
Display information about an event filter or list all available event filters.
lsevttype
List the event types.
mkevtfltr
Import event filters.
rmevtfltr
Remove event filter.
For event actions

lsevtact
Display information about available event actions or export event actions to an XML
file.
mkevtact
Import event actions.
mkevtactemail
Create a customized event action that sends email over an SMTP server.
mkevtactstpgm
Create a customized action that starts a program.
mkevtacttask
Create a customized action that starts a non-interactive task.
rmevtact
Remove a customized event action.
testevtact
Test a customized event action.
For detailed information about these commands and the options for these commands, see the
information center:
r.cli.helps.doc%2Ffqm0_r_cli_automation_cmds.html
Example 4-10 creates the e-mail for test event action. Example 4-11 on page 192 creates
the Email for Critical Events event automation plan that is used for critical events.
First, we list the available event action on our Systems Director server with the smcli lsevtact
command. Then, we create an email event action with the smcli mkevtactemail command.
Example 4-10 Create action: Send an email
SLES11:/opt/ibm/director/bin#./smcli lsevtact
Add to the event log
Mail to book
eMail
eMail to admin
SLES11:/opt/ibm/director/bin#./smcli mkevtactemail -I -p 25 -s "&date &system" -m
"&date &time message form &system : &text "email for test" [email protected]
[email protected] smtp.itso.ral.ibm.com
SLES11:/opt/ibm/director/bin#./smcli testevtact email for test
DNZEAP1073I: <informational> The test or the event action was successfully started
SLES11:/opt/ibm/director/bin#
SLES11:/opt/ibm/director/bin#./smcli lsevtact
Add to event log
Mail to book
eMail
eMail to admin
email for test
191
We create our email for critical events event automation plan by using the smcli
evtautopln command. First, we list the available event automation plans. Then, we create an
event automation plan by using the Critical Events filter. Then, we create the email for
test event action. We assign the new EAP to the All Systems group. After these steps, we
list the event automation plans that are available now. You can see that the newly created
event automation plan is in the list (Example 4-11).
Example 4-11 Create the event automation plan named email for critical events
SLES11:/opt/ibm/director/bin#./smcli lsevtautopln
Log All Events
book-EAP
Send eMail to Admin
Test
SLES11:/opt/ibm/director/bin# ./smcli mkevtautopln -D "Test" -e "Critical Events"
-x "email for test" -N "All Systems" email for critical events
SLES11:/opt/ibm/director/bin#./smcli lsevtautopln
Log All Events
book-EAP
Send eMail to Admin
Test
email for critical events
If you want to see the details or status for an event automation plan, use the smcli
lsevtautopln -l %EAP-Name% command. Example 4-12 lists the detailed information for our
newly created email for critical events event automation plan.
Example 4-12 List details for the email for critical events event automation plan
SLES11:/opt/ibm/director/bin# ./smcli lsevtautopln -l email for critical events

Name: email for critical events
Description: Test
Status: Active
Event Filter: Critical Events
Time Ranges:
All the time (24x7)
Actions:
email for test
Targets:
Group Name: All Systems
4.4.5 Best practice for event management

These are the best practices to use the event management efficiently:
Use the health status to check your environment and to check the events.
Create at minimum one event action plan, which contains an event action and an event
filter.
192
Use the appropriate action for your environment, which fits your requirements (like email
notification). Define the settings for the event action carefully and test the action.
Select the appropriate event filter or define your own filter that fits in your requirements.
Assign the event automation plan to single systems or specific groups instead of all
systems. This helps to get the right events for the right systems.
193
4.5 Hardware Management Console and AIX Launch-in-Context

Information about the discovery of a Hardware Management Console (HMC) and the HMC
managed resources is described. The HMC Launch-in-Context (LiC) capability and extended
tasks are shown.
The Systems Director server can be used for a wide range of tasks on systems that are under
the control of a managed HMC:
Creating virtual servers

Editing virtual server resources
Views
Topology
Discovering an HMC by using the Systems Director server offers a single-pane-of-glass view
to monitoring and supporting Power Systems hardware. Some dynamic logical partition
(LPAR) (DLPAR) functions are embedded in the Systems Director UI, and other functions can
be initiated by using LiC.
4.5.1 Before you begin

Before the discovery of the HMC, carefully determine what level of access is passed to the
Systems Director server. This determination relates to the tasks that are required to manage
the HMC.
Use the following links to the information center to set up:
Setting up user access to the HMC:
ctor.vim.helps.doc%2Feica7_t_setting_up_user_access_hmc.html
Configuring the HMC:
ctor.vim.helps.doc%2Feica7_t_configuring_hmc.html
Managing systems that are controlled by HMC LiC:
ctor.power.helps.doc%2Ffqm0_t_managing_hmc_ivm.html
Preparing the HMC for discovery:
ctor.install.helps.doc%2Ffqm0_t_preparing_hmc_for_discovery.html
4.5.2 Discovery
Discovery of the HMC is performed by way of the normal discovery process. Resources are
discovered by either an IP address or host name.
194
The following steps show the discovery process:

1. From the UI on Systems Director, select Inventory System Discovery (Figure 4-139).
Figure 4-139 Discovered appliances
2. Authenticate with the HMC by using a user ID, as shown in Figure 4-140.
Figure 4-140 Request Access panel
3. If the HMC user access is set up correctly and the correct settings are enabled on the
HMC network settings, the access column displays OK.
4. To view the recently discovered HMC and associated Power Systems, use the Systems
Director UI and click Inventory Views Platform Managers and Members.
Terminology: For a list of the terminology that is used in Systems Director for Power
Systems users, see this website:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.d
irector.power.helps.doc%2Ffqm0_c_power_new_terms.html
195
5. The view is automatically populated with the resources that are visible to the user ID on
the HMC (Figure 4-141).
Figure 4-141 Platform Managers and Members panel
6. From the Systems Director UI, see an expanded view for Power Systems servers by
clicking Inventory Views Virtual Servers and Hosts, as shown in Figure 4-142.
Figure 4-142 Virtual Servers and Hosts panel
196
7. Because the HMC is discovered, we get visibility to the HMC menu by Launch-in-Context,
as shown in Figure 4-143.
Figure 4-143 HMC menu
8. If we select the Welcome Page from the HMC menu, it does not launch (Figure 4-144). We
still do not have full authentication to use the HMC and need to configure single sign-on
(SSO).
Figure 4-144 Configure SSO
197
9. Click Create. The Welcome wizard opens to enter valid SSO credentials (Figure 4-145).
Figure 4-145 Create and edit SSO
10.Enter a user ID and password. Then, click Next.

11.Assign to IBM Systems Director User, as shown in Figure 4-146.
Figure 4-146 Assign to IBM Systems Director User
12.At the end of the wizard, click Finish.
198
13.Because the SSO for the HMC that you selected is configured, reattempt
Launch-in-Context (Figure 4-143 on page 197). The HMC does not launch and you are
brought to the requested page (Figure 4-147).
Figure 4-147 View Console Events panel
You can create a partition from the UI in two ways:

Use LiC and launch the HMC UI (Figure 4-148 on page 200)
Use the embedded view from the UI (Figure 4-150 on page 202)
By using LiC, you can also label the profile and assign these properties:
Minimum processing units and memory

Processing units and memory that you want
Maximum processing units and memory
Weighting for processing units
By using the standard LiC functionality, you can add virtual adapters while you build the
virtual server. Depending on the complexity of the virtual server that you create, LiC gives you
greater choice.
199
To create a virtual server by using LiC, follow these steps:

1. Right-click the server and click Extended Management Configuration Create
Logical Partition. You can select to create an AIX or Linux partition, or an IBM i partition,
Figure 4-148 LiC virtual server creation
200
2. The HMC wizard opens in context (Figure 4-149).
Figure 4-149 HMC LiC
201
Using the embedded menu simplifies the creation of the virtual server because you do not
leave the UI, as shown in Figure 4-150. Follow these steps:
1. Right-click the server and click System Configuration Create Virtual Server.
Figure 4-150 Virtual server creation embedded
2. The Create Virtual Server wizard starts. As shown in Figure 4-151, specify properties,
such as name and source (AIX or Linux, and processors).
Figure 4-151 Create Virtual Server wizard
202
3. Specify the memory size as required, as shown in Figure 4-152.
Figure 4-152 Memory
4. Disks depend on storage visibility or whether disks are already mapped to the Virtual I/O
Server (VIOS) (Figure 4-153). Disks can be virtual or physical system service processors
(SSPs) or N-Port ID Virtualization (NPIV) volumes.
Figure 4-153 Disks
5. Network definitions are shown in Figure 4-154.
Figure 4-154 Networks
6. For devices, use the normal practices that you use for a regular HMC LPAR creation
(Figure 4-155).
Figure 4-155 itso-aix99 completed
203
7. After the creation of a virtual server, additional networks can be added and CPU priority
can be changed (Figure 4-156). Use this syntax:
smcli chvs -A "networks=+Discovered-XX-0" -n itso-aix99
# smcli chvs -A "cpupriority=128" -n itso-aix99
Edit virtual server operation completed successfully.
Figure 4-156 chvs cpupriority
8. You can increase or decrease memory within the virtual server minimum and maximum
range (Figure 4-157 and Figure 4-158).
# smcli chvs -A "memsize=8192" itso-aix00
Edit virtual server operation completed successfully.
#
Figure 4-157 chvs memsize
# while true
> do
> lsattr -El sys0 -a realmem
> sleep 2
> done
realmem 7340032 Amount of usable
Figure 4-158 chvs memsize output
204
physical
physical
physical
physical
physical
memory
memory
memory
memory
memory
in
in
in
in
in
Kbytes
Kbytes
Kbytes
Kbytes
Kbytes
False
False
False
False
False
9. Memory, processor, and priority can be changed from the UI dynamically one time within
the virtual server minimum and maximum range (Figure 4-159).
Figure 4-159 Edit Virtual Server option
205
10.Select the required tab and change the Assigned value (Figure 4-160). Click OK.
Figure 4-160 Edit virtual server memory
11.On the submitted job, click Display Properties. Click Complete (view log) to view the
output of the job. See Figure 4-161.
Figure 4-161 Job properties
206
12.Figure 4-162 shows the virtual server job output.
Figure 4-162 Edit virtual server job output
13.Under the Systems Director UI, the Inventory Views Virtual Servers and Hosts
view displays the changed memory value (Figure 4-163).
Figure 4-163 Updated server configuration
4.5.3 Best practices for HMC management

These are the best practices to use the HMC LiC efficiently:
Properly configure user, access, and rights on the HMC for IBM Systems Director servers:
Read documentation
Discover the HMC
Create user and sufficient rights on the HMC
Configure access and single sign-on on IBM Systems Director servers to access the HMC
Run an inventory on the HMC
207
4.6 Security
Systems Director security is controlled by two interdependent processes: authentication and
authorization.
Authentication is used to determine who can access the Systems Director server.
Authorization determines the resources to which the user has access. Systems Director uses
role-based access control (RBAC) where the administrator assigns roles and permissions to
an authenticated user. On that basis, the user can work on resources that are based on the
RBAC to which the user is assigned.
The security features of Systems Director enable an administrator to perform the following
functions:
Manage auditing
View and manage authorized users and groups
Assign roles and resources to users
Manage user properties
Create and modify roles
Manage permissions that are grouped within a role
Use roles to control access to a system
Request access to a system
Manage credentials and their associated mappings
The following flow allows a user to access or manage a system:

1. User must be authenticated.
2. User must be authorized to perform a task on the selected resource.
4.6.1 Users and groups for authentication

In Systems Director, users and user groups are based on users and groups that are defined
in the configured registry. The registry is associated with either the operating system,
directory services, such as Lightweight Directory Access Protocol (LDAP), or the domain
controller. Systems Director uses the user and group information for authentication and
authorization.
Access to particular resources or tasks is governed by restrictions. The restrictions are based
on the user ID or user group membership and the roles that are defined for each user. For a
user to access the Systems Director server, one of the following conditions must exist:
The user is a member of a user group that is authorized for the Systems Director server.
The user has administrator privileges on the Windows management server or Windows
domain.
The user is a root user on the AIX or Linux management server.
In a default Systems Director server installation scenario that uses the local operating system
registry, four Systems Director user groups are automatically created. The user groups are
created at the operating system level on the management server.
208
Table 4-5 lists the user groups, which are used for different access permissions to the
Table 4-5 Default groups
Default groups
Role
Description
smadmin
SMAdministrator
Administrator group. Users in this group have administrative

access to Systems Director and can perform all administrative
tasks. These members can define the available privileges for
the smmgr, smmon, smuser, and groupread groups. The
privileges that are available to members of the smadmin group
cannot be restricted.
smmgr
SMManager
Manager group. The supported operations are a subset of the

SMAdministrator group. The members of this group have all
rights except the rights to create or change user permissions
and authorizations.
smmon
SMMonitor
Monitor group. This group supports some administrative

functions, such as monitoring. The members of this group are
restricted to read-only functionality.
smuser
SMUser
User group. Members of this group have, by default, no rights

and no access to any system or functions.
Members of the root and Administrator group are authorized for all operations on all
resources.
The only role that is automatically assigned is to the administrator user ID that installed
Systems Director. So, initially, no other user is associated with a role.
If you want to use LDAP or another directory service that the user registry supports, you
might need to manually create all the user groups and assign users to them.
The users for Systems Director must be added to one of the groups to get access to the
Systems Director GUI.
Authenticating a local user

Systems Director can authenticate user login requests to the registry for the configured
operating system. Systems Director uses the local operating system user registry by default.
Follow these steps to create a local operating system user account:
1. Create a user account in the user registry that is associated with the management server.
The way that you create the user account depends on the operating system that you use.
2. Add the user as a member of one of the user groups that are defined for Systems Director
at the user registry level. You can either use one of the predefined groups or create your
own groups. If you create a custom group on the Systems Director server, you must
authorize it. (Log in as a member of the smadmin group and then go to Security
Users Authorize Groups. Or, use the smcli authusergp command).
3. Log in to the Systems Director web interface as a member of the smadmin group and go to
Security Users. The users that you configured in the previous steps are displayed in
the list.
After users are authenticated to Systems Director, you can configure the authorizations for
each user to Systems Director tasks and resources.
209
Authenticating a domain user

Systems Director can authenticate a user from an Active Directory domain to access the
Systems Director GUI. Use the following steps to generate the access for the domain user:
1. Create a user account in the Active Directory user registry. For instructions about creating
a user account in the domain server user registry, see the Active Directory documentation.
2. Add the Active Directory user to a defined Active Directory global security group. You must
create your own Active Directory group if a suitable group does not exist.
3. Add the global group to an authorized local group of the Systems Director server, such as
smadmin, smmgr, smmon, or smuser.
Systems Director works best with Active Directory when its users are placed in global
groups. Those global groups are then placed in the local groups of the Systems Director
server.
For preferred practices, do not add Active Directory users directly to the local groups of
any Systems Director servers.
4. Log in to the Systems Director web interface as an administrator and go to Security
Users. Active Directory users that are managed as a group do not appear in the list.
However, you see the group. Users that are local to the Systems Director server show on
this list because they are managed as individuals.
You can now assign additional roles to users to access specific Systems Director tasks and
resources.
Authenticating LDAP users

Systems Director can authenticate user login requests to an LDAP server. In section 4.6.5,
Lightweight Directory Access Protocol on page 221, you can see an example of how to use
LDAP for Systems Director.
4.6.2 Authorizing users

User authorization occurs when an authenticated user uses Systems Director to perform a
task on a resource. The authorization mechanism compares the user account, or the group to
which the user belongs, to the RBAC settings for that user or group. If a role exists that
contains the necessary authorizations to complete that task on that specified resource, the
task proceeds.
Users can access only the applications, tasks, and resources that their user accounts are
authorized to access. The authorities that you grant to a user determine the console and
resource information that the user can access, and the tasks that the user can perform on
those resources.
Roles
You can assign roles to Systems Director users to control their access to resources and limit
the tasks that they can perform on those resources. The authorities that you configure for a
role determine the level of access that is granted to each user who is assigned to that role. All
users or groups of users that access Systems Director must have a user role assignment.
The Systems Director server uses an RBAC service with which an administrator can create
custom sets of permissions. The administrator assigns these sets of permissions, which are
known as roles, to individual users or groups. An authorization role is a set of tasks, CLI
commands, and application permissions that is applied to one or more resources. Each role
can be applied to many users, and each user can have many roles. Regulating user roles is
210
an effective way to control security for your system. By regulating user roles, you can control
access to every task and CLI command.
The following roles are available in the Systems Director server by default:
SMAdministrator (Administrator role)
The SMAdministrator role has full authority to perform all tasks and functions and full
control over permissions. A user that is assigned to this role can perform all tasks
(including security administration, product installation, and configuration) with any
resource.
SMManager (Manager role)
The SMManager role can perform management operations, which are a subset of the
functions that a member of the SMAdministrator role can perform. Typically, system
administration, system health management, and system configuration tasks are available.
This role cannot perform security administration or security configuration tasks. However,
this role has full access to all the Systems Director functions that are included in a
functional manager or feature.
SMMonitor (Monitor role)
The SMMonitor role can access the administrative functions that provide read-only
access, such as monitoring, notification, and status. With this role, a user can complete
tasks, such as monitoring a process, viewing and collecting inventory, and viewing
hardware status.
SMUser (User role)
The SMUser role includes any authenticated user and includes the ability to perform only
basic operations, such as viewing resources and properties.
GroupRead (Group role)
The GroupRead role has a single permission, which is known as group read, that defines
the groups that are visible to each user. The administrator that assigns this role to a user
can assign the groups that the user can view. The user then has access to see the groups
but not necessarily the group contents.
These default user roles correspond directly with the groups that Systems Director installs at
the operating system level. You cannot delete these roles and you cannot modify the
permissions that are associated with them. However, you can add users and other groups to
the system-defined roles as needed. You also can copy the system-defined roles or create
new roles for your business needs.
Assigning a role to a user or user group

The roles that are assigned to a user or user group determine the tasks that the user has
permission to access. From the Users page, you can assign one or more roles to a user or
user group. When you assign a role, you also associate the specific resource groups to which
that role applies to the selected user.
Before you can assign a role to a user, each user or group of users must have a valid user ID
or group ID in the local operating system user registry on the management server. Also,
ensure that the role that you want to assign to a user exists. If the role does not exist, you can
create a role from the Roles page.
211
To assign a role to a user or group, complete the following steps:

1. In the Systems Director web interface navigation area, click Security Users and
Groups. Or, select Manage Users on the Home page Plug-ins tab. See Figure 4-164.
Figure 4-164 Security Users and Groups or Manage Users
2. From the Users tab, select the user or group to which you want to assign a role. In our
example, we select the user smtest (Figure 4-165).
Figure 4-165 Select user for assigning role
212
3. Click Assign Role. The Welcome page for the Assign Role wizard opens (Figure 4-166).
Click Next.
Figure 4-166 Welcome panel
4. The wizard lists the roles that are created. In our example, we select the SMMonitor role for
the user smtest (Figure 4-167).
Figure 4-167 Assigning roles and resource groups
213
5. Select the role that you want to assign and click Add.
6. Select the resource groups that you want to associate with the role and the user. In our
example, we select All resource groups.
Parent groups: Selecting a parent group does not automatically assign access to its
children.
7. Click Next. The Summary page opens (Figure 4-168). Click Finish.
Figure 4-168 Summary page
Working with roles

Use Systems Director to work with roles and assign individual users and user groups to those
roles. From the Roles page (Figure 4-169 on page 215), you can view, copy, edit, or delete a
role. To view, copy, edit, or delete a role, the role must exist. You can also use the Roles page
to create a role that you can then manage.
214
Follow these steps to create a role:

1. In the navigation area, click Security Roles (Figure 4-169).
Figure 4-169 Select Roles from the Security section
2. On the Roles tab, click Create (Figure 4-170).
Figure 4-170 Create a role

215
3. The Create Role wizard Welcome page opens. Click Next.

4. The Name page opens (Figure 4-171). In the Name field, type a name for the role that you
want to create. In our example, we named the new role book-Test. In the Description field,
type an optional brief description for the role. Click Next.
Figure 4-171 Naming the new role
5. The Permissions page opens (Figure 4-172 on page 217). In the Available permissions
list, select a permission that you want to add to the user role and then click Add. The
selected permission is added to the Selected permissions list. Continue to add
permissions until you add all permissions that are required for the role.
In our example, we select Inventory and Task Management as permissions for the new
role.
216
Figure 4-172 Select permissions
6. Click Next. The Summary page opens (Figure 4-173). Click Finish.
217
4.6.3 Access managed systems

Use Systems Director to configure credentials that are used to access managed systems.
These credentials enable Systems Director to authenticate to and manage target systems by
using the available protocols and access points on the managed system.
You can request access to and configure access options for systems in your environment by
using these tasks:
Request access task
Configure access task
Configure system credentials task
You can also revoke access to an accessed system.
Security protocols
Depending on the managed system, the following communication protocols are supported
(Figure 4-6).
Encrypted protocols: Not all protocols are encrypted as indicated in the table.
Table 4-6 Supported communication protocols
Managed system type
Communication protocol
Encrypted
Encryption algorithm
Agentless-managed system
Distributed component
object model (DCOM)
Yes
RC2
SNMP v1 and v2
No
None
Secure Shell (SSH)
Yes
Encrypted algorithm is negotiated
Agentless
Yes
Supports the communication

protocols and encryption algorithms
that are listed for the
agentless-managed system
Common Information
Model (CIM)
Yes
If configured, encryption is enabled by

default by using Secure Sockets Layer
(SSL)
IBM Director 5.x

interprocess
communication (IPC)
Yes
AES, DES, or 3DES
Tivoli Common Agent

Services 6.x
Yes
SSL
Service Location Protocol

(SLP)
No
None
Platform Agent-managed system
Common Agent-managed system
Other
Access secured systems

Use the Request Access page to request access to a secured system if the management
server to which you connect is not yet authenticated to the system. You must be able to
access the system before you can perform tasks or remotely access the system.
Ensure that you have the correct authorization to access the secured system.
218
Secured systems are displayed in the Systems Director web interface with a padlock icon in
the Access field or column of the system details (Figure 4-174). After a system is accessed,
the padlock disappears and additional tasks and status information are available.
The Access attribute for each resource shows the current access status. You cannot request
access to the resources with the following types of access status:
Offline: Use verify access instead.
OK: No further action is required. You already have access to these resources.
To request access to secured managed systems, complete the following steps:
1. In the Systems Director web interface, click Resource Explorer.
2. Navigate to the system that you want to access.
3. Right-click the system for which you want to request access and click Security
Request Access.
Figure 4-174 Request Access option
Tip: Alternatively, you can click Security Configure Access and then click Request
Access on the Configure Access page.
219
4. On the Request Access page, type the user ID and password of a user that belongs to the
system group (Figure 4-175). Only certain user accounts can be used to request access.
Figure 4-175 Request Access panel
The following list shows the detailed requirements of the user accounts that can be used
to request access for various types of agent systems:
Common Agent:
Linux/AIX: Root or user in the system group

Windows: Administrator or user in the administrator group
Platform Agent:
Linux/AIX: Root or user in the system group

Agentless systems:
Linux/AIX: Root or user in the system group. User that is configured with the sudo
command.

Tip: To configure sudo and SSL keys for UNIX agentless systems, follow the
procedure that is at the following link:
http://pic.dhe.ibm.com/infocenter/director/v6r2x/index.jsp?topic=/com.ibm
.director.install.helps.doc/fqm0_c_sample_sudo_configuration_file.html
Click Request Access (Figure 4-175). Credentials are created and authenticated to the
managed system in an attempt to access it. If the access request is successful, the access
status for the managed system changes to OK.
If the access status changes to Partial Access, the access request was unsuccessful for
at least one protocol. Click Configure Access to see the list of available protocols for the
system and their access states. If necessary, to create additional credentials, click an
access point that does not have an access state of OK and repeat this procedure.
For information about accessing systems by using credentials, configuring access, or
accessing CIM systems by using the x509 certificate, see the information center:
r.security.helps.doc%2Ffqm0_t_managing_access.html
220
4.6.4 Credentials
The Systems Director server uses credentials to implement SSO authentication. By using
SSO with this authentication process, a user can access more than one system or application
by entering a single user ID and password. The Systems Director server maps web interface
user credentials to the necessary user credentials for authenticating to the target managed
system. These credentials are saved in registries.
It is a preferred practice to use SSO because users are not required to type the user ID and
password for the target system or resource each time that they or tasks access it. The
Systems Director server automatically logs on as needed by retrieving the necessary
credentials.
There are two types of credentials:
Shared credentials
Shared credentials are those credentials that exist in an authentication registry that is not
specific to an access point.
Targeted credentials
Targeted credentials are each assigned to only one remote-service agent access point
and are in an authentication registry that is specific to that access point.
For more information about credentials, see the Systems Director Information Center:
r.security.helps.doc%2Ffqm0_c_credentials.html
4.6.5 Lightweight Directory Access Protocol

The Systems Director server can authenticate users that are defined in the LDAP directory.
Many benefits are possible if you use LDAP as the preferred authentication method:
Ease of management
Central administration
Cross-platform synergies
The following LDAP servers are supported by Systems Director:
Microsoft Active Directory

IBM Lotus Domino
IBM Tivoli Director Server
Sun One
OpenLDAP
IBM Secure Way Server
Novell eDirectory
221
Configuring OpenLDAP
We configure OpenLDAP on Red Hat Enterprise Linux Server 5.6. Install the Red Hat
Package Manager (RPM) packages that are shown in Figure 4-176.
[root@xs-2120rhelppc ~]# rpm -qa | grep openld
compat-openldap-2.3.43_2.2.29-12.el5_5.3
openldap-devel-2.3.43-12.el5_5.3
openldap-2.3.43-12.el5_5.3
openldap-clients-2.3.43-12.el5_5.3
openldap-servers-2.3.43-12.el5_5.3
openldap-2.3.43-12.el5_5.3
openldap-devel-2.3.43-12.el5_5.3
[root@xs-2120rhelppc ~]
Figure 4-176 OpenLDAP RPM packages
Discuss the properties that need to be edited in the securityLDAP.properties file with your
LDAP administrator. For more information about LDAP, see the information center at the
following link:
r.security.helps.doc%2Ffqm0_t_ldap_authentication.html
File name change: Rename the security.ldap file to the securityLDAP.properties file
after you change the properties. If you use LDAP, Systems Director looks for the
securityLDAP.properties file.
Table 4-7 shows the properties to be referenced or changed in the securityLDAP.properties
file.
Table 4-7 OpenLDAP securityLDAP.properties file properties to change
Property
Value
Description
com.ibm.lwi.LDAPHost
IP or host name
Address of LDAP server
com.ibm.lwi.LDAPAdminPassword
Encrypted password
Read-only password for binding
com.ibm.lwi.LDAPBase
dc=itso,dc=ibm
Base distinguished name (DN)

for LDAP server
com.ibm.lwi.searchfilter
(&(uid=%v)(objectclass=inetOrgPerson))
The user search filter for the

LDAP server
com.ibm.lwi.rolemanager.ldap.
filters.usergroup
(objectclass=posixGroup)
Authorized groups for the

Systems Director server
filters.users
(|(objectClass=inetOrgPerson)(objectClass=pos
ixAccount))
Group objects search
names.memberAttribute
uid
Member attribute role object
names.loginName
uid
Name of login attribute of user
names.groupID
gidNumber
Name of the group ID attribute

of the group object
names.userPrimaryGroupID
gidNumber
Name of the group ID attribute

of the group object
222
Property
Value
Description
filters.usersByGroupId
(&(gidNumber={0})(|(objectClass=inetOrgPerso
n)(objectClass=posixAccount)))
Users by gidNumber or
member
filters.groupsByMembers
(&(|(gidNumber={0})(memberUid={1}))(objectcla
ss=posixGroup))
Groups by gidNumber or
posixGroup
names.memberAttribute.isDN
false
Specific to openLDAP
For information about the OpenLDAP slapd server configuration, see the following Red Hat
web page:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Ref
erence_Guide/s1-ldap-quickstart.html#s2-ldap-files-slapd-conf
After you successfully install the required RPM packages, configure the sldap.conf file and
encrypt the rootpw password by using the slappasswd command, as shown in Figure 4-177.
[root@xs-2120rhelppc openldap]# slappasswd
New password:
Re-enter new password:
{SSHA}4eb+Hf7KScesth8vftJ/Fdw8jKXV+mRL
Figure 4-177 slappasswd
The following configuration changes for the slapd.conf file are shown in Figure 4-178:
suffix
rootdn
rootpw
database
bdb
suffix
"dc=itso,dc=ibm"
rootdn
"cn=root,dc=itso,dc=ibm"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw
secret
rootpw {SSHA}4eb+Hf7KScesth8vftJ/Fdw8jKXV+mRL
Figure 4-178 slapd.conf file configuration changes
From the command line, start the LDAP service and add an entry to start the service
automatically on boot by using chkconfig, as shown in Figure 4-179.
[root@xs-2120rhelppc openldap]# service ldap start
Checking configuration files for slapd: config file testing succeeded
[ OK ]
Starting slapd:
[ OK ]
[root@xs-2120rhelppc openldap]# chkconfig ldap on
[root@xs-2120rhelppc openldap]# chkconfig --list | grep ldap
ldap
0:off 1:off
2:on
3:on
4:on
5:on
6:off
[root@xs-2120rhelppc openldap]#
Figure 4-179 Service start: chkconfig check
223
Importing groups and users

From the LDAP server command line, import the ldif files for users and groups. To complete
this task, we create a ldif file for importing. Create a groups.ldif file as shown in
Figure 4-180.
dn: cn=smadmin,dc=itso,dc=ibm
cn: smadmin
objectClass: top
objectClass: posixGroup
gidNumber: 100
memberUid: root
memberUid: uid=root,cn=smadmin,dc=itso,dc=ibm
dn: uid=root,cn=smadmin,dc=itso,dc=ibm
cn: root
sn: root
uid: root
objectClass: top
objectClass: inetOrgPerson
objectClass: posixAccount
uidNumber: 100
gidNumber: 100
homeDirectory: /root
userPassword: operah09se
dn: cn=smmon,dc=itso,dc=ibm
cn: smmon
objectClass: top
gidNumber: 101
memberUid: isduser
memberUid: uid=isduser,cn=smmon,dc=itso,dc=ibm
dn: cn=smmgr,dc=itso,dc=ibm
description: smmgr
cn: smmgr
objectClass: top
gidNumber: 102
memberUid: uid=isdmgr,cn=smmgr,dc=itso,dc=ibm
memberUid: uid=isdmgr0,cn=smmgr,dc=itso,dc=ibm
dn: cn=smuser,dc=itso,dc=ibm
description: smuser
cn: smuser
objectClass: top
gidNumber: 103
Figure 4-180 groups.ldif file
224
Create a users.ldif file as shown in Figure 4-181.

dn: uid=isduser,cn=smmon,dc=itso,dc=ibm
cn: isduser
sn: isduser
objectClass: top
uid: isduser
uidNumber: 101
gidNumber: 101
homeDirectory: /home/isduser
userPassword: @Pa22w0rd
dn: uid=isdmgr0,cn=smmgr,dc=itso,dc=ibm
cn: isdmgr0
sn: isdmgr0
uid: isdmgr0
objectClass: top
uidNumber: 102
gidNumber: 102
homeDirectory: /home/isdmgr0
dn: uid=isdmgr1,cn=smmgr,dc=itso,dc=ibm
cn: isdmgr1
sn: isdmgr1
uid: isdmgr1
objectClass: top
uidNumber: 103
gidNumber: 102
homeDirectory: /home/isdmgr1
Figure 4-181 users.ldif file
225
The two ldif files are imported by using the ldapadd file as shown in Figure 4-182.
[root@xs-2120rhelppc ldapFiles]# ldapadd -H ldap://127.0.0.1 -x -D
"cn=root,dc=itso,dc=ibm" -f ~/ldapFiles/groups.ldif -w @Pa22w0rd
adding new entry "cn=smadmin,dc=itso,dc=ibm"
adding new entry "uid=root,cn=smadmin,dc=itso,dc=ibm"
adding new entry "cn=smmon,dc=itso,dc=ibm"
adding new entry "cn=smmgr,dc=itso,dc=ibm"
adding new entry "cn=smuser,dc=itso,dc=ibm"
"cn=root,dc=itso,dc=ibm" -f ~/ldapFiles/users.ldif -w @Pa22w0rd
adding new entry "uid=isduser,cn=smmon,dc=itso,dc=ibm"
adding new entry "uid=isdmgr0,cn=smmgr,dc=itso,dc=ibm"
adding new entry "uid=isdmgr1,cn=smmgr,dc=itso,dc=ibm"
Figure 4-182 ldapadd file
226
To view the LDAP server, we use the LDAP command line (Figure 4-183).
[root@xs-2120rhelppc openldap]#ldapsearch -x -b 'dc=itso,dc=ibm'
# extended LDIF
#
# LDAPv3
# base <dc=itso,dc=ibm> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# itso.ibm
dn: dc=itso,dc=ibm
dc: itso
o: itso
objectClass: organization
objectClass: dcObject
# smadmin, itso.ibm
dn: cn=smadmin,dc=itso,dc=ibm
cn: smadmin
objectClass: top
gidNumber: 100
memberUid: root
memberUid: uid=root,cn=smadmin,dc=itso,dc=ibm
# root, smadmin, itso.ibm
dn: uid=root,cn=smadmin,dc=itso,dc=ibm
cn: root
sn: root
uid: root
objectClass: top
uidNumber: 100
gidNumber: 100
homeDirectory: /root
userPassword:: b3BlcmFoMDlzZQ==
# smmon, itso.ibm
dn: cn=smmon,dc=itso,dc=ibm
cn: smmon
objectClass: top
gidNumber: 101
memberUid: isduser
# smmgr, itso.ibm
dn: cn=smmgr,dc=itso,dc=ibm
description: smmgr
cn: smmgr
objectClass: top
gidNumber: 102
memberUid: uid=isdmgr,cn=smmgr,dc=itso,dc=ibm
Figure 4-183 ldapsearch
227
The LDAP server is now ready. The groups are defined. The users are defined. And, the
securityLDAP.properties file is configured.
Therefore, we can make the last changes to the Systems Director server so that we can start
to use LDAP as its authentication method (Figure 4-184). You need run the following
commands on the IBM Systems Director server.
-bash-3.2#
-bash-3.2#
-bash-3.2#
-bash-3.2#
cd /opt/ibm/director/lwi/conf/overrides/
mv security.ldap securityLDAP.properties
mv security.properties security.properties.old
smstop;smstart;smstatus -r
Figure 4-184 File changes
From the Systems Director server home page, click Plug-ins and then IBM Systems
Director server. A summary window opens and the authentication type is listed
(Figure 4-185). The configuration is successful.
Figure 4-185 Confirming that LDAP is successfully configured
We now use OpenLDAP as the authentication type.

Important: This example is a basic setup of openLDAP. Ensure that you take additional
security measures with your configuration to further secure the openLDAP server and
LDAP administration.
Authenticating users and groups

Additional groups and their associated users can be authorized to Systems Director. This
authorization can be set up for new groups or groups that exist in the LDAP domain.
228
The following example imports a new Systems Director group with users to the OpenLDAP
server by using the ldapadd command. This group is called the isdgroup (Figure 4-186).
"cn=root,dc=itso,dc=ibm" -f ~/ldapFiles/addgroup.ldif -w operah09se
adding new entry "cn=isdgroup,dc=itso,dc=ibm"
"cn=root,dc=itso,dc=ibm" -f ~/ldapFiles/adduser.ldif -w operah09se
adding new entry "uid=user0,cn=isdgroup,dc=itso,dc=ibm"
adding new entry "uid=user1,cn=isdgroup,dc=itso,dc=ibm"
Figure 4-186 Authorizing an additional group
Now that the group is added, we add the additional users because this task is an incremental
installation. Then, we need to authorize the group to Systems Director. Follow these steps:
1. From the Systems Director home page, click Security Users and Groups Groups.
Then, click Authorize Groups. The Authorize User Groups wizard starts.
2. On the Welcome page, click Next.
3. Figure 4-187 appears. The group that was imported to LDAP by using the ldapadd
command is displayed. Place a check mark next to the group and click Next.
Figure 4-187 Authorize User Groups window
4. Click Finish to authorize the isdgroup user group and complete the wizard.
Figure 4-188 Authorize the isdgroup user group
5. We still need to assign a role to the group that is authorized. The group can be assigned to
a custom role or one of the default roles:
SMAdministrator
229
SMManager
SMMonitor
SMUser
6. Select the group that we authorized (note that the Roles entry is empty for the isdgroup
group in Figure 4-189) and click Assign Role.
Figure 4-189 Assign Role task
7. For this group, we assign an SMAdministrator role to the group. The Assign Role wizard
starts. Click Next.
8. Then, on the Assign Role window (Figure 4-190), choose SMAdministrator from the
pull-down menu that is highlighted in Figure 4-190 and Add.
Figure 4-190 Assign Role window
9. On completion, click Next and Finish.

230
10.Now, the isdgroup group and its associated users have SMAdministrator access to all
resources.
11.From the home page, click Security Users and Groups Users (Figure 4-191).
Figure 4-191 User listing
You can now successfully log on as a user that is listed in the isdgroup.
Tip: When you use the wizard to authorize groups, only the first 10 groups are returned in
Figure 4-190 on page 230. If your group is not listed, type the name. If the typed name
does not return the group, check your filters in the securityLDAP.properties file.
4.6.6 Using command-line tools for security

There are many available smcli command-line tools for security settings, as listed in
Table 4-8.
Table 4-8 Command-line tools for security
Command
Description
authusergp
Authorize an existing user group to access the Systems Director server.
cfgaccess
Configure access for systems that are managed by Systems Director.
cfgappcred
Change the password that Systems Director uses to access particular associated
applications.
cfgcertpolicy
View or configure the trust management certificate policy that IBM Systems
Director uses.
cfgcred
Configure credentials for systems that are managed by Systems Director.
cfgpwdpolicy
Manage the password policies of users that Systems Director creates or manages.
chaudit
Modify audit settings.
chcred
Change credentials for systems that are managed by Systems Director.
chrole
Change the properties of a role.
chuser
Modify the properties of a user.
chusergp
Change attributes and access privileges for a user group.
231
Command
Description
exportcert
Export a certificate from a Systems Director keystore or truststore to a .pem file.
importcert
Import certificates into a Systems Director keystore or truststore.
lsaudit
List audit settings and categories.
lsauditlogs
List a specific number of audit log messages for one or more audit categories.
lscert
List the certificates in a Systems Director keystore or truststore.
scred
List credentials for systems that are managed by Systems Director.
lsperm
List the permissions.
lsrole
List the roles in Systems Director.
lsuser
List users.
lsusergp
List the Systems Director user groups.
mkrole
Create roles that contain a list of permissions for authorization to access Systems
Director.
revokecert
Invalidate certificates in a Systems Director keystore or truststore.
rmauditlogs
Remove the audit log for one or more audit categories.
rmcert
Remove certificates from a Systems Director keystore or truststore.
rmcred
Remove credentials for systems that are managed by Systems Director.
rmrole
Delete roles.
rmusergp
Remove the access authorization for a user group or remove a user group.
unrevokecert
Revalidate revoked certificates in a Systems Director keystore or truststore.
For detailed information about the commands and all options for these commands, see the
information center:
r.security.helps.doc%2Ffqm0_r_roles_required_to_run_commands.html
Accessing command-line tools by role/group

The command-line tools are restricted by the permissions. Table 4-9 lists which commands
can be accessed by the roles.
Table 4-9 Command-line tools by role/group
Group
Restricted
Specifics
SMAdmin
Unrestricted
All commands
SMManager
Restricted
All commands except the security and system commands
SMMonitor
Restricted
All commands with list functions, such as lscfgplan, lsinv, lsled,

lsstatus, lsresmonlsps, and lsevtfltr
Also, commands such as checkupd and lsupd, or commands for SNMP,
such as get, walk, and getnext
SMUser
232
Restricted
Only support for the following commands: lssys, lsgp, lsjob,

lsjobhistory, lstask, runjob, and runtask
For a complete list of commands, see this website:

r.security.helps.doc%2Ffqm0_r_roles_required_to_run_commands.html
4.6.7 Best practices for security

These are the best practices to use the security setting in IBM Systems Director efficiently:
Manage users that will connect to the IBM Systems Director console:
Define who can access the console.
Define authorization and roles for these users into IBM Systems Director.
Define method of authentication on IBM Systems Director server (LDAP, AD, or local).
For a UNIX agentless server, configure SSL keys and sudo configuration to avoid root
utilization.
When Using LDAP or Active Directory, configure the settings carefully.
4.7 Backup
Why you should back up IBM Systems Director server and how to recover from a Systems
Director failure are described.
The following topics are included:
4.7.1, Backup Q&A on page 233
4.7.2, Backup and recovery on page 234
4.7.3, Migration on page 238
4.7.1 Backup Q&A

You might ask the following backup questions:
Why back up?
Backing up the Systems Director, including all data and settings, makes it easier to
recover from a Systems Director server crash. Systems Director provides command-line
tools to perform both the backup and the recovery. These tools are explained in section
4.7.2, Backup and recovery on page 234.
When do I back up?
The preferred practice is to back up your Systems Director server after installation and
initial configuration. Also, back up after discovery and inventory but before you first install
any updates. Then, you can quickly recover back to a fresh installation, if necessary.
Always back up after you make any updates to the Systems Director server.
How often do I back up?
We suggest that you back up before you install plug-ins or advanced managers. We also
recommend that you back up regularly, such as once a month.
What information is backed up?
The Systems Director backup routine creates a backup image of Systems Director
persistent data. Persistent data includes file system data, which is also called master data,
and database data:
Information about discovered systems and their access state
All event automation plans
233
All groups
All inventory data that is stored in the Systems Director database
Event logs
The backup also includes data in the local repository, such as updates that you
downloaded.
What can the backup not be used for?
Do not use the backup procedures to migrate to a new version or to switch over to another
system with another version of Systems Director or another database. For a migration, use
other tools that are described in section 4.7.3, Migration on page 238.
4.7.2 Backup and recovery

To protect your Systems Director 6.3.x data from a disaster, back up and restore your data.
Use commands that are provided by Systems Director.
The following command-line tools are used for backup and recovery:
smsave (backup)
smrestore (restore)
smreset (reset)
Systems Director backup

Use the smsave command to save a backup image of the Systems Director server. The
command is in the install_root\bin\ directory, where install_root is the root directory of
your Systems Director installation.
Tip: The Systems Director server must be stopped before you run the smsave command.
A description of the options for the smsave command is at this website:
r.cli.helps.doc%2Ffqm0_r_cli_smsave.html
The backup image that is created by the smsave command is saved in the
install_root\backup\time_stamp directory, unless you otherwise specified the output
directory in the command.
The smsave command creates a backup image of Systems Director persistent data. Persistent
data includes file system data (also called master data) and database data. The master data
set contains information about the location of the database data set and uses that stored
location when you run the restore operation. The database backup image is saved in the
format that is specific to the database type. Backups cannot be moved from one database
type and version to another database type or version.
When you run the command, the execution log is saved to install_root\log\smave.log and
all status is updated in real time in that file. No output is posted to the command prompt.
Figure 4-192 on page 235 shows an example of using the smsave command on a Microsoft
Windows 2008 R2 System.
First, you see that if the Systems Director server is not stopped before you run the smsave
command, an information error is displayed. Stop the Systems Director server before you run
the command by running the net stop dirserver command on Windows. For Linux, use the
smstop command instead.
234
After you stop the Systems Director server, you can run the smsave command. Figure 4-192
shows the messages that you see during the procedure.
PS C:\Program Files\IBM\Director\bin> smsave
The Director Server is currently active.
command.
Please stop the server before running this
PS C:\Program Files\IBM\Director\bin> net stop dirserver

The IBM Systems Director Server service is stopping...............
The IBM Systems Director Server service was stopped successfully.
PS C:\Program Files\IBM\Director\bin> smsave
Command is running. Monitor live status and results in C:\Program
Files\IBM\Director\log/smsave.log
1 file(s) copied.
1 file(s) moved.
PS C:\Program Files\IBM\Director\bin>
Figure 4-192 smsave command
235
The log file, which is created during the backup process, is in the install_root\log directory.
Figure 4-193 shows part of an example log file.
Command Execution for: Fri Oct 19 20:57:34 CEST 2012
Starting execution of Save Operation
Execution: Operation is save to the following location C:\Program
Files\IBM\Director\backup\2012_10_19_20.57.34
Execution: Loading aem.ext
Execution: Loading AgentFile.ext
Execution: Loading BaseFile.ext
Execution: Loading console.ext
Execution: Wildcard expression not matched to anything
-->lwi\runtime\isc\loginMessage\loginMessage*.properties
Execution: Loading database.ext
Execution: Loading databaseMigration.ext
Execution: Loading defaults.ext
Execution: Loading discovery.ext
Execution: Loading EventMapping.ext
Execution: Loading HMS.ext
Execution: Loading LegacyTablesExtension.ext
Execution: Loading LRTMMigration.ext
Execution: Loading MetricsMigration.ext
Execution: Loading security.ext
Execution: Loading skm.ext
Execution: Loading ssm.ext
Execution: Loading ssm_reset.ext
Execution: Loading StartAgentFile.ext
Execution: Loading StopAgentFile.ext
Execution: Loading StorageControlExt.ext
Execution: Loading ThresholdMigration.ext
Execution: Loading updates.ext
Execution: Loading vsm.ext
Execution: Loading Workflow.ext
Execution: Executing Extensions
Execution(20:57:34): Starting extension StopAgentFile.ext
Execution(20:58:48): Completed extension StopAgentFile.ext
Execution(20:58:48): Starting extension BaseFile.ext
BaseFileExt: save C:\Program Files\IBM\Director\version.srv to C:\Program
Files\IBM\Director\backup\2012_10_19_20.57.34\version.srv
BaseFileExt: save C:\Program Files\IBM\Director\data to C:\Program
Files\IBM\Director\backup\2012_10_19_20.57.34\data
....
Figure 4-193 smsave.log file
The data from the backup process is saved to the install_root\backup directory. The size
depends on several components:
Number of systems that are discovered

Inventory that is collected
Update packages that are downloaded
All other settings
In our simple lab tests, the initial backup that we performed after installation and an inventory
run is about 60 MB in size.
236
Systems Director restore

Use the smrestore command to restore the persistent data, including file system (master)
data and databases, from a backup image.
You can run the smrestore command locally from the management server. Or, run the
command remotely by accessing the management server by using a remote access utility,
such as SSH or Telnet.
To run the smrestore command, go to the install_root\bin directory, where install_root is
the root directory of your Systems Director installation. The Systems Director server must be
stopped before you run the smrestore command.
A description of the options for the smrestore command is at this website:
r.cli.helps.doc%2Ffqm0_r_cli_smrestore.html
You can restore saved persistent data only on a management server with the same
characteristics:
Same operating system
Same version of the Systems Director server from which the data was backed up
Same database type and version
In addition, the Systems Director server and the database that you restore must be the same
as the saved installation instances.
When you run the command, the execution log is recorded in the
install_root\log\smrestore.log file, and all status is updated in real time in that file. Little
information is posted to the command prompt.
Figure 4-194 shows the output from the command.
PS C:\Program Files\IBM\Director\bin> smrestore -sourceDir 'C:\Program
Files\IBM\Director\backup\201
2_10_19_20.57.34'
This operation will replace all current data with the specified backup set.
To continue, type "1" for yes or "0" for no.
1
Command is running. Monitor live status and results in C:\Program
Files\IBM\Director\log/smrestore.log
1 file(s) copied.
1 file(s) moved.
Figure 4-194 smrestore command
Systems Director reset

The smreset command reinitializes the databases and clears all persistent data. The smreset
command deletes local data on the file system where Systems Director is installed. The
237
smreset command deletes and rebuilds all database tables that are used by Systems
Director.
A description of the options for the smreset command is at this website:
r.cli.helps.doc%2Ffqm0_r_cli_smreset.html
Use the smreset command to return the Systems Director server to its installation default
values. This command must also be run immediately after you run the cfgdbcmd command to
change to a new database. For example, run the smreset command when you upgrade from a
managed IBM DB2 database to an enterprise database such as Oracle Database. Run the
smreset command only when the Systems Director server is stopped.
The smreset command does not delete or reset Agent Manager information. The smreset
command deletes the following data:
Discovered resource data (except for 6.x Common Agents that were previously accessed)
Inventory data
Event data (event log, custom event filters, custom event actions, and custom event plans)
Monitoring data
Update data
Status data
Configuration templates
Security configurations
All other data that is associated with running and configuring Systems Director after the
installation
The smreset command creates two log files, smreset.log and reset.log, which are in the
install_root\log directory.
Figure 4-195 shows the output from the smreset command.
PS C:\Program Files\IBM\Director\bin> smreset.bat
This operation will revert the IBM Systems Director database and server to the installed
state. To c
ontinue, type "1" for yes or "0" for no.
1
1 file(s) copied.
1 file(s) moved.
Figure 4-195 smreset command
4.7.3 Migration
The tools that can be used to migrate from one version of a Systems Director to a newer
version or to another system are described.
A backup and restore process can be used only if the management server, where a backup is
restored, runs the same operating system. And the version of the Systems Director server
must be the same as the version from which the data was saved. The database type and
238
version must be the same. In addition, the Systems Director server and the database that you
restore must be the same as the saved installation instances.
You can switch to another operating system, another system, or another database and take
the settings from the former Systems Director server with you. Use the commands in
Table 4-10 to export and import settings and managed endpoints.
Table 4-10 Command-line tools for migration
Command
Description
dircli lsmoa
List managed objects - replaced by smcli lssys.
dircli mkmoa
Make managed objects.
smcli lsevtautopln
List information about event automation plans. You can also export one or
more event automation plans to a file.
smcli mkevtautopln
Create an event automation plan or import one or more existing event

automation plans.
a. Before you use this command, issue the set CLILEGACY=1 command.
For the complete list of the smcli commands and a description for each command, see the
Systems Director Information Center:
r.cli.helps.doc%2Ffqm0_r_cli_smcli.html
Exporting systems and settings

How to export the systems and settings (for example, event automation plans) from an
existing Systems Director server by using command-line tools is described.
Exporting systems
Use the following command for exporting the existing systems to a file. This information can
be used later on a new Systems Director server to import the systems without discovery:
./smcli lssys -t "OperatingSystem" -d ";" -A
"Displayname,IPv4Address,Hostname,ManagementSoftware" >>OS.txt
239
In our lab example, the contents of the file that is created are shown in Figure 4-196.
9.42.171.194: 9.42.171.194;{ '9.42.171.194' };{ };{ '' }
9.42.171.195: 9.42.171.195;{ '9.42.171.195' };{ };{ '' }
9.42.171.196: 9.42.171.196;{ '9.42.171.196' };{ };{ '' }
9.42.171.197: 9.42.171.197;{ '9.42.171.197' };{ };{ '' }
9.42.171.198: 9.42.171.198;{ '9.42.171.198' };{ };{ '' }
9.42.171.199: 9.42.171.199;{ '9.42.171.199' };{ };{ '' }
9.42.171.203: 9.42.171.203;{ '9.42.171.203' };{ };{ '' }
9.42.171.22: 9.42.171.22;{ '9.42.171.22' };{ };{ '' }
9.42.171.23: 9.42.171.23;{ '9.42.171.23' };{ };{ 'IBM-IBM Director Agent-v6.3.2',
'IBM-IBM Director Platform Agent-v6.3.2' }
9.42.171.232: 9.42.171.232;{ '9.42.171.249', '9.42.171.232' };{ };{ ''}
9.42.171.244: 9.42.171.244;{ '9.42.171.244' };{ };{ '' }
9.42.171.25: 9.42.171.25;{ '9.42.171.25' };{ };{ '' }
9.42.171.254: 9.42.171.254;{ '9.42.171.254' };{ };{ '' }
9.42.171.26: 9.42.171.26;{ '9.42.171.32', '9.42.171.26', '9.42.171.29', '9.42.171.30',
'9.42.171.31', '9.42.171.33', '9.42.171.34' };{ };{ '' }
9.42.171.27: 9.42.171.27;{ '9.42.171.27' };{ };{ '' }
9.42.171.28: 9.42.171.28;{ '9.42.171.28' };{ };{ '' }
9.42.171.40: 9.42.171.40;{ '9.42.171.40' };{ };{ '' }
9.42.171.54: 9.42.171.54;{ '9.42.171.55', '9.42.171.54', '9.42.171.56' };{ };{ '' }
9.42.171.60: 9.42.171.60;{ '9.42.171.60' };{ };{ '' }
9.42.171.62: 9.42.171.62;{ '9.42.171.62' };{ };{ '' }
9.42.171.82: 9.42.171.82;{ '9.42.171.82' };{ };{ '' }
9.42.171.97: 9.42.171.97;{ '9.42.171.97' };{ };{ 'IBM-IBM Director Core
Services-v6.2.1.2', 'IBM-IBM Director Agent-v6.2.1' }
'IBM-IBM Director Core Services-v6.3.2' }
SLES11: SLES11;{ '9.42.171.84' };{ 'SLES11' };{ 'IBM-IBM Director Agent-v6.3.2',
Figure 4-196 Output of the smcli lssys command
Exporting settings
Use the Systems Director command-line tools to export settings, such as event automation
plans and groups. You can export settings in two ways:
Use the smcli command line, for example, to export event automation plans (Figure 4-197
on page 241).
Use export functions in the Systems Director web interface (exporting groups as shown in
Figure 4-198 on page 241).
240
To export the event automation plan, use the smcli lsevtautopln command. In our lab
example, Figure 4-197, we exported the Send eMail to Admin event automation plan to the
EAPexport.xml file. Use the -o attribute for an easier export because you can use the object
identifier (OID) instead of the complete name.
SLES11:/opt/ibm/director/bin # ./smcli lsevtautopln
Log All Events
Send eMail to Admin
SLES11:/opt/ibm/director/bin # ./smcli lsevtautopln -o
Log All Events, 0x11
Send email to Admin, 0x11
SLES11:/opt/ibm/director/bin # ./smcli lsevtautopln -F xml 0x11 /tmp/EAPexport.xml
Figure 4-197 Export event automation plan
To export groups, you can use the Systems Director web interface. Start from the Resource
Explorer Groups view and select the group that you want to export (Figure 4-198).
Figure 4-198 Groups in the Resource Explorer view
241
With the group selected, click Actions Export Group.

The window that is shown in Figure 4-199 opens. In this view, you can select to which
directory you want to save the data. The file is named group _%username%.xml. The username
is the user that is logged on and creates the export file.
Figure 4-199 Save group data
You can use the file to import the group and the members of the group to another Systems
Director server or use the file for recovery options.
Importing systems and settings

With Systems Director, you can use command-line tools to import systems and to request
access to those systems. The command to import systems is smcli mkmo (dircli mkmo).
Prerequisite: Before you run the smcli mkmo (dircli mkmo) command, issue the following
command:
set CLILEGACY=1
Use the smcli mkmo command to create a managed object for the server and systems. The
server represents the hardware service processor and the systems represent the operating
system and agent.
242
In Figure 4-200, we first check whether the system is available. Then, we remove the system
and check again whether the system exists. Then, we show the settings for mkmo and add the
system to the Systems Director server again with the smcli mkmo command. We check again
whether the system exists.
SLES11:/opt/ibm/director/bin # ./smcli lssys 9.42.171.196
9.42.171.196
SLES11:/opt/ibm/director/bin # ./smcli rmmo 9.42.171.196
DNCZCLI0239E : (Run-tinme error) The system named 9.42.171.196 was not found
use the smcli lssys command to view all the valid system names
SLES11:/opt/ibm/director/bin # ./smcli mkmo
Server:
type=Server
name=<Specify Name> (Optional)
ip=<Specify IP Address>
Systems:
type=Systems
name=<Specify Name> (Optional)
ip=<Specify Network Address>
network=<Specify Network Protocol>
Available Protocols: TCPIP
(Optional)
SLES11:/opt/ibm/director/bin # ./smcli mkmo type=Systems ip=9.42.171.196

9.42.171.196
Figure 4-200 smcli mkmo command
You can also run the smcli mkmo command in a script. With a script, you can add many
systems to the new Systems Director at the same time.
243
If you saved groups, you can import them to a new system. From the Resource Explorer view,
follow these steps:
1. Click Actions Import Groups, as shown in Figure 4-201.
Figure 4-201 Import Groups selection
2. Figure 4-202 opens where you can browse for the XML file that contains the group
information.
Figure 4-202 Select the file with the group information
244
3. The imported groups show under Groups Personal Groups, as shown in

Figure 4-203.
Figure 4-203 Groups: Personal Groups view
To import a saved event automation plan, run the smcli mkevtautopln /tmp/EAPexport.xml
command, as listed in Figure 4-204. In our example, we use the event automation plan that
we exported before to the EAPexport.xml file.
SLES11:/opt/ibm/director/bin # ./smcli mkevtautopln /tmp/EAPexport.xml
Warning Number: 1
DNZEAP2068W: (Run-time warning)
The IP address or host name 'smtp.itso.ral.ibm.com' is not accessible.
Action name: eMail to Admin
Element name: EmailSmtpServer
Element value: smtp.itso.ral.ibm.com
Warning Number: 2
DNZEAP2059W: (Run-time warning)
The event filter named 'Critical Events' has the same name and definition as an existing
filter in the system.
The filter will be not be created again.
Filter name: Critical Events
Total number of warnings: 2
DNZEAP2064I: (Informational)
'Send eMail to Admin'.
Created event action 'eMail to Admin'.

Created event automation plan 'Send eMail to Admin'.
Targets 'All Systems', applied to event automation plan
#
Figure 4-204 Importing an event automation plan
245
During the import process, the event automation plan is checked. Warnings display if
incorrect settings exist in the event automation plan or if event actions or filters exist on the
system. The existing filter or event action is not created again. You can see that the event
Action plan Send eMail to Admin is created. All systems, predefined in the event automation
plan that we exported, are assigned to this event automation plan.
4.7.4 Best practices for backup

Keep in mind the following when managing IBM Systems Director backups:
Define a backup policy and configure it on your server. The smsave command must be
used when the IBM Systems Director server is down (smstop command).
Before each backup, you should have a clean and recent inventory.
If you need to reset the IBM Systems Director server by using the smreset command,
you should make a backup before doing the reset.
If you need to restore, use the smrestore command. The smrestore works only if the
server has the same configuration, which has been taken by the smsave command
(same operating system, same database, same version of IBM System Director).
246
Chapter 5.
VMControl
This chapter provides an overview of best practices when using IBM Systems Director
VMControl. IBM Systems Director VMControl is a cross-platform product that assists you in
rapidly deploying virtual appliances to create virtual servers that are configured with the
operating system and software applications that you want. It also enables you to group
resources into system pools, which enable you to centrally manage and control the different
workloads in your environment.
5.1, About VMControl on page 248

5.2, Understanding the components of a VMControl environment on page 249
5.3, Managing KVM on Red Hat Enterprise Linux with VMControl on page 251
5.4, Managing VMware vSphere with VMControl on page 282
5.5, Managing Microsoft Hyper-V with VMControl on page 286
5.6, Using IBM SmartCloud Entry with VMControl on page 290
5.7, Managing PowerVM with VMControl on page 298
247
5.1 About VMControl

To implement IBM Systems Director VMControl, you need to plan where you are going to use
it and what purpose it should fill.
IBM Systems Director VMControl gives you the opportunity to control multi-hypervisor
environments. However, some IBM components on upper layers of management stack give
more advanced control features to hypervisors and especially deployment-related tasks. IBM
Systems Director VMControl Enterprise version provides the most advanced features for
Kernel-based Virtual Machine (KVM) on Red Hat Enterprise Linux (RHEL) and for IBM
PowerVM hypervisor platforms.
Figure 5-1 shows a configuration with IBM Systems Director and IBM Systems Director
VMControl where IBM Systems Director VMControl has control in all architectures and
hypervisors.

VM Control
vCenter
VMware
Rhel KVM
MS Hyper-V
x86 architecture
PowerVM
z/VM
p architecture
z architecture
Figure 5-1 IBM Systems Director VMControl and hypervisors
Use this configuration when there is no need for self-service portal or advanced
hypervisor-specific virtual machine deployment features.
Figure 5-2 on page 249 shows a configuration with IBM Systems Director, IBM Systems
Director VMControl, and IBM SmartCloud Entry (SCE). SCE communicates with IBM
Systems Director VMControl and also manages VMware through IBM Systems Director
VMControl (VMC) or vCenter application programming interface (API).
248
IBM SmartCloud Entry provides extra features like self service portal for end users, IP
address pools, billing, and metering. When managing VMware in a cloud environment, it is a
good practice to use SCE to communicate directly with vCenter API, as shown in Figure 5-2.
IBM Smart Cloud Entry

VMC driver
vCenter driver

VM Control
vCenter
VMware
Rhel KVM
MS Hyper-V
x86 architecture
PowerVM
z/VM
p architecture
z architecture
Figure 5-2 IBM Systems Director, VMControl, and IBM SmartCloud Entry
For more information about IBM SmartCloud Entry, see:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/W21ed5ba0f4a
9_46f4_9626_24cbbb86fbb9/page/Documentation
5.2 Understanding the components of a VMControl

environment
IBM Systems Director VMControl allows you to manage various components in your
virtualization environment. VMControl has several components that need to be clarified
before the KVM environment can be designed and configured. The following sections
describe these components.
5.2.1 Platform managers

A platform manager manages one or more host systems and their associated virtual servers
and operating systems. Examples of platform managers include:
Hardware Management Console (HMC)

Integrated Virtualization Manager (IVM)
VMware vCenter
IBM Systems Director does not recognize a managed system as a platform manager until the
managed system has been unlocked. (The padlock icon in the Access column for a managed
system indicates that it is secured.) To request access to the managed system, right-click the
Chapter 5. VMControl
249
managed system and click Request Access. By providing a valid user name that has local
administrative rights to that managed system and its password, you can unlock and access
the system. In a KVM environment, IBM Systems Director VMControl behaves as a platform
manager.
5.2.2 Hosts
In an IBM Systems Director environment, a host is a system that contains resources from
which virtual servers are constructed. Hosts can be any of the following systems that are
configured for the IBM Systems Director environment:
A BladeCenter chassis
IBM Flex System Enterprise Chassis
An RHEL 6.0, 6.1, 6.2, or 6.3 server that has KVM virtualization support enabled
IBM Power Systems that are under the control of an IBM HMC
An IBM Power Systems server that is under the control of IBM IVM
A system running VMware ESX Server or VMware ESXi that is under the control of
VMware vCenter
Windows Server 2008, Enterprise, Standard, and Datacenter x64 Editions with Hyper-V
role enabled, Release 2
A System z logical partition (LPAR) running z/VM hypervisor
A Power Systems compute node
A host can manage multiple virtual servers and their guest operating systems.
5.2.3 Virtual servers or virtual machines

A virtual server is associated with a host system. The host must be part of a virtualization
environment that is supported in IBM Systems Director. An operating system and other
software can be installed on a virtual server. In a Power Systems environment, a virtual
server is called a logical partition or partition. In z/VM and VMware environments, virtual
servers are often called virtual machines.
A virtual server is the logical equivalent of a physical platform. After IBM Systems Director
discovers a host, it continues the discovery process for all the virtual servers that are
associated with the host. After virtual servers are discovered, they can be powered on and
turned off through IBM Systems Director. In addition, you can edit resources that are
assigned to virtual servers, and in some virtualization environments, you can relocate a
virtual server from one host to another. You can also create additional virtual servers to meet
your needs.
5.2.4 Guest-operating-systems
A guest-operating-system represents an operating system that is running on a virtual server
on which Common Agent is installed or it has been discovered as agentless. A
guest-operating-system is a particular type of managed system. The standard IBM Systems
Director discovery process for managed systems can discover guest operating systems.
However, if a guest operating system is not running Common Agent, it is not recognized as an
agentless guest-operating-system object in IBM Systems Director.
250
5.2.5 Virtual farms

A virtual farm logically groups like-hosts and facilitates the relocation task moving a virtual
server from one host to another host within the virtual farm. A virtual farm can contain multiple
hosts and their associated virtual servers. A virtual farm can contain only hosts of the same
type. For example, a virtual farm that begins with a KVM host can contain only other KVM hosts.
When a virtual farm is configured, you can relocate virtual servers between hosts in the farm.
You use the Create Virtual Farm wizard to group hosts together and enable specialized
capabilities for the virtual servers running on the hosts. You can enable capabilities such as
high availability, workload management, live relocation, and static relocation. Not all
capabilities are supported on all platforms.
5.2.6 Virtual appliances

A virtual appliance is a ready-to-deploy operating system and software package that is stored
by IBM Systems Director VMControl. A virtual appliance contains an image of a full operating
system, and can contain software applications and middleware. A virtual appliance also
contains metadata describing the virtual server that the image requires.
5.2.7 Workloads
A workload represents one or more virtual servers that can be monitored and managed as a
single entity. For example, you can manage a workload that might contain both a web server
and a database server. You can start and stop a workload, and thus the virtual servers it
contains, as one entity. You can monitor the overall state and status of the workload by
viewing the Workloads dashboard. A workload is automatically created when you deploy a
virtual appliance. You can also create a workload by grouping one or more virtual servers that
are not already part of an existing workload.
5.2.8 System pools

System pools group similar resources so that you can manage the resources within the
system pool as a single unit. You can create storage system pools and server system pools.
You can perform basic tasks such as creating and deleting system pools and adding and
removing resources from the system pools. Additional system pool functions like Networking
Pools are available, depending on the type of system pool that you created.
5.3 Managing KVM on Red Hat Enterprise Linux with VMControl

This section provides an overview of best practices when using IBM Systems Director
VMControl with KVM on Red Hat Enterprise Linux.
There are two ways to use KVM on Red Hat Enterprise Linux with IBM Systems Director:
Use a Network File System (NFS) storage-based solution.
Use a storage area network (SAN) storage-based solution.
For information about installing an environment by using the NFS storage-based solution, see
the following site:
http://publib.boulder.ibm.com/infocenter/flexsys/information/index.jsp?topic=%2Fco
m.ibm.director.vim.helps.doc%2Ffsd0_vim_r_kvm.html
251
The best practice is to use a SAN storage-based solution. Although this configuration looks
more complex than the NFS solution, the block storage-based model offers better
performance, as well as more functionality and flexibility.
Figure 5-3 shows the vital components of IBM Systems Director and KVM on a Red Hat
Enterprise Linux platform.
Figure 5-3 SAN storage-based KVM and VMControl environment
The details of KVM on Red Hat Enterprise Linux and IBM Systems Director Components are:
IBM Systems Director server 6.3.2 or higher is installed on a supported server. This is the
management server, which controls the KVM environment and behaves as the platform
manager.
If you are using Storage Control to manage the SAN storage, then a supported version of
Storage Control 4.2.1 or higher must also be installed.
IBM Systems Director VMControl 2.4 or greater is activated.
Fibre Channel network for storage is in place. KVM virtualization with VMControl supports
only SAN storage over Fibre Channel. It has to be correctly cabled and configured with the
appropriate Fibre Channel switches. Typically, one of the fabric switches is configured with
the zoning information. Additionally, VMControl requires that the Fibre Channel network
has hard zoning enabled.
One or more RHEL KVM hosts are set up and available. Ensure that the RHEL KVM host
is connected to the Fibre Channel network with a supported adapter. The Platform Agent
for KVM is downloaded and installed.
252
KVM hosts are discovered, accessed, and inventoried from your IBM Systems Director
server.
The SAN storage controllers (also called storage subsystems) are configured and storage
pools are set up with the storage space and Redundant Array of Independent Disks
(RAID) levels that you want for virtual disk images. VMControl and Storage Control does
not provision these RAID storage pools for you. Best practice is to use IBM SAN Volume
Controller (SVC) or IBM Storwize v7000 for Fibre Channel-based SAN storage
subsystems.
For information about the supported storage controllers with VMControl and KVM, see:
ctor.vim.helps.doc%2Ffsd0_vim_c_learnmore_repositories_kvm.html
A Fibre Channel switch provider is configured in the environment. This role can be
handled by the Brocade SMI-S Agent or the Brocade Network Advisor.
Storage subsystems, storage pools, and the Fibre Channel switch fabric are discovered
and inventoried by IBM Systems Director for shared access from endpoints in the KVM
environment. These endpoints include KVM hosts and image repository servers. The
image repository is used for storing and deploying virtual appliances.
The physical server with Red Hat Enterprise Linux with Common Agent with a storage
subagent is installed as an image repository server and is connected to the Fibre Channel
network with a supported Fibre Channel host bus adapter (HBA).
Note: Skip this step if the IBM Systems Director server is running RHEL, is connected
to the SAN Fibre Channel network, and will be used as the management server and for
the repository server. However, the best practice is to use an external physical server
when IBM Systems Director server can be virtualized itself.
The image repository server is discovered and inventory is collected on it.
The image repository is created from VMControl.
All hosts have static IP-addresses and functional Domain Name System (DNS) services.
KVM hosts have network interfaces for virtual servers and networks have been built inside
to all hosts.
5.3.1 VMControl supported tasks and limitations

VMControl provides in KVM environments the most wide scale of tasks, which are available
for hypervisor and virtual server management in IBM Systems Director VMControl.
VMControl provides the following supported tasks in a KVM environment:
Create and delete NFS storage pools on a host.
Create and delete NFS or SAN virtual disks.
Suspend or resume virtual servers and workloads (without release of resources).
Create, edit, and delete virtual servers.
Power operations for virtual servers.
Relocate virtual servers.
Turn maintenance mode on and off for hosts that are in server system pools.
Import a virtual appliance package that contains one or more raw disk images.
253
Capture a workload or virtual server into a virtual appliance.

Deploy a virtual appliance package to a new virtual server with hardware and product
customizations.
Deploy a virtual appliance package to an existing virtual server with adequate resources.
Start, stop, and edit a workload.
Create, edit, and delete server system pools.
Create, edit, and delete network system pools (if you are using IBM Systems Director
Network Control with VMControl).
Adjust the virtualization monitor polling interval for KVM by using the
KvmPlatformPollingInterval parameter.
VMControl supports the following network configurations in a KVM environment:
Virtual Ethernet Bridging (VEB).
Virtual Ethernet Port Aggregator (VEPA) network (Requires IBM Systems Director
Network Control and that the host is in a network system pool).
The following limitations apply when using KVM on Red Hat Enterprise Linux.
The following limitations and restrictions apply to using the KVM virtualization environment:
Restrictions when you manage IBM BladeCenter or System x systems.
The following templates cannot be used to configure the operating system:
SNMP Agent Configuration template
Asset ID template
A user account cannot be copied and used to create a user. Asset information cannot be
configured for a managed system.
Do not use the RHEL Virtual Machine Manager or other means to create virtual servers or
to manage them directly on a KVM managed system. IBM Systems Director server does
not receive events when operations are performed outside of VMControl in these cases.
Results might vary if these external interfaces are used.
Only NFS version 3 mounts are supported by VMControl. If both your NFS server and
NFS client (hosting image repository) support version 4, you might need to either use the
nfsvers=3 mount option to downgrade the mount or configure your NFS server to give only
version 3 mounts.
Red Hat Enterprise Linux Version 5.5 is not supported for the image repository server that
hosts SAN repositories.
Limited support for KVM hypervisor networks.
5.3.2 KVM virtual environment considerations

When creating an IBM Systems Director VMControl KVM virtual environment, the following
factors need to be considered:
Network design. Plan your network carefully because network design is one of the
important things that needs to be set up properly:
Reserve enough physical network interfaces and size them correctly. Plan for the
amount and speed of network interface needed by the network types and services.
If planning an environment that requires isolated networks, use the proper technology
to provide not only hypervisor isolation, but also isolation that is done inside the switch.
254
Is there a need to implement VEB features?

Is there a need to implement VEPA features?
Use Virtio and e1000 model configurations for virtual network server adapters.
KVM virtualized environments must run on System x servers, blades, or an IBM Flex
System.
You must use the following Linux versions for the KVM virtualization environment: Red Hat
Enterprise Linux version 6.0, 6.1, 6.2, or 6.3 with KVM virtualization installed.
Use para-virtualized (Virtio) drivers for enhanced performance.
5.3.3 KVM on Red Hat Enterprise Linux

This section provides information for installing KVM on Red Hat Enterprise Linux, including
the basic steps that need to be performed to prepare virtual hosts and the image repository
for IBM Systems Director VMControl.
To manage the KVM on a Red Hat Enterprise Linux host from IBM Systems Director
VMControl, you must manually install the RHEL KVM Platform Agent. Always use the latest
available packet. For successful installation, you need a minimum of three physical servers to
create one KVM cluster and one image repository server for image management, in addition
to IBM Systems Director with the VMControl Standard or Enterprise Edition activated.
Preparation
Install and configure RHEL 6.3 on the compute node using the Virtualization Host role. RHEL
installation is not described in this book.
Notes:
Red Hat installation steps and information can be found at the following site:
https://access.redhat.com/site/documentation//en-US/Red_Hat_Enterprise_Linux
/index.html
When using SAN storage, remember to configure Red Hat multipathing, as discussed
at the following site:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/
6/html/DM_Multipath/mpio_setup.html
After installing Red Hat Enterprise Linux, the host needs to be prepared for the RHEL KVM
Platform Agent. Perform the following steps to allow installation and communication between
IBM Systems Director and the KVM Platform Agent.
1. Change SELINUX=enforcing to SELINUX=disabled to disable SELinux, as shown in
Example 5-1.
Example 5-1 Disable SELinux
[root@node11229 ~]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#
enforcing - SELinux security policy is enforced.
#
permissive - SELinux prints warnings instead of enforcing.
#
disabled - SELinux is fully disabled.
SELINUX=disabled
# SELINUXTYPE= type of policy in use. Possible values are:
255
#
targeted - Only targeted network daemons are protected.
#
strict - Full SELinux protection.
SELINUXTYPE=targeted
Tip: You can also configure SELinux in permissive mode if required for security
reasons.
2. Configure the iptables, as shown in Example 5-2.
Example 5-2 Configure iptables so that it saves the iptables settings
[root@TPMfImages ~]# cp /etc/sysconfig/iptables-config
/etc/sysconfig/iptables-config.old
[root@TPMfImages ~]# rm -f /etc/sysconfig/iptables-config
[root@TPMfImages ~]# echo 'IPTABLES_MODULES=""
> IPTABLES_MODULES_UNLOAD="yes"
> IPTABLES_SAVE_ON_STOP="yes"
> IPTABLES_SAVE_ON_RESTART="yes"
> IPTABLES_SAVE_COUNTER="no"
> IPTABLES_STATUS_NUMERIC="yes"
> IPTABLES_STATUS_VERBOSE="no"
> IPTABLES_STATUS_LINENUMBERS="yes"' > /etc/sysconfig/iptables-config
[root@TPMfImages ~]# cat /etc/sysconfig/iptables-config
IPTABLES_MODULES=""
IPTABLES_MODULES_UNLOAD="yes"
IPTABLES_SAVE_ON_STOP="yes"
IPTABLES_SAVE_ON_RESTART="yes"
IPTABLES_SAVE_COUNTER="no"
IPTABLES_STATUS_NUMERIC="yes"
IPTABLES_STATUS_VERBOSE="no"
IPTABLES_STATUS_LINENUMBERS="yes"
[root@TPMfImages ~]#
3. Open the required TCP/UDP ports on the hosts, as shown in Example 5-3.
Example 5-3 Open ports
[root@ISDNode1 ~]# iptables -A INPUT -p udp --dport 427 -j ACCEPT

iptables -A INPUT -p tcp --dport 15989 -j ACCEPT
[root@ISDNode1 ~]# iptables -A INPUT -p tcp --dport 22 -j ACCEPT
[root@ISDNode1 ~]# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
Note: Configuring iptables is needed because you might face some issues during the
inventory collection. You can also temporarily disable iptables for troubleshooting
purposes.
256
4. Configure Yum on your Red Hat Enterprise Linux system and upgrade. See Example 5-4.
For more information about how to configure Yum, see the following site:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Gu
ide/sec-Configuring_Yum_and_Yum_Repositories.html
Tips:
Configure Yum on your system because during the KVM Platform Agent installation,
you might face RPM dependency requirements. You can save time if Yum is
configured.
When registering the RHEL subscription, ensure that only limited updates are
available. Then, upgrade RHEL with Yum. Otherwise, Yum will upgrade RHEL to the
newest version, which might not yet be supported by the IBM Systems Director KVM
Platform Agent.
Example 5-4 Upgrade environment with yum
[root@ISDNode1 network-scripts]#sudo yum upgrade

--setopt=protected_multilib=false --skip-broken
This upgrade prevents the most common problems with dependencies.
5. Check that the date on your KVM node is the same as the other KVM hosts and the IBM
Systems Director, as shown in Example 5-5.
Example 5-5 Check date on the KVM host and IBM Systems Director host
[root@node7391 network-scripts]# date

Thu Apr 18 18:25:05 EEST 2013
Tip: Remember to check the time difference between the IBM Systems Director server
and KVM hosts.
Generally, the time difference between the agents and IBM Systems Director, when
adjusted for the time zone, should not be more than one hour. Ensure that the system
clocks remain synchronized on the systems that contain IBM Systems Director and
agents.
6. Remove any unnecessary packages by using the command that is shown in Example 5-6.
If packages exist, agent installation will fail.
Example 5-6 Remove unnecessary packages
[root@ISDNode1 ~]# yum -y erase tog-pegasus libcmpiutil libvirt-cim

sblim-cmpi-nfsv3 sblim-cmpi-fsvol sblim-gather-provider sblim-gather
sblim-cmpi-base openslp
7. Create the required data networks for virtual servers in all hosts that are part of the KVM
server pool. See Example 5-7 on page 258.
Note: The server that acts as the image repository does not need bridging. You can
skip this step when configuring the image repository host.
257
Example 5-7 shows an example of a bridge network file. You can create this file by copying
the ifcfg-eth0 file to create the ifcfg-br0 file and after copying, edit it by using the vi
editor. This example has been created for one of the Ethernet devices.
Example 5-7 How a bridge configuration file should look after modifying it
[root@ISDNode1 network-scripts]# cat ifcfg-br0

DEVICE=br0
BOOTPROTO=static
IPADDR=10.31.21.100
NETMASK=255.255.192.0
IPV6INIT=yes
MTU=1500
ONBOOT=yes
TYPE=Bridge
DELAY=0
UUID=c15c6764-f14c-426e-960e-3e7cfb1d65f3
Example 5-8 shows the file after it has been modified.
Example 5-8 Ethernet config file after modifying
[root@ISDNode1 network-scripts]# cat ifcfg-eth0

DEVICE="eth0"
HWADDR="34:40:B5:BE:79:60"
ONBOOT="yes"
BRIDGE="br0"
8. Restart the network-related services on the host. See Example 5-9.
Example 5-9 Restart network services
[root@ISDNode1 network-scripts]# service network restart

Note: The Secure Shell (SSH) service must be configured and running on the KVM
host. This configuration ensures that an SSH remote service access point for port 22
gets created for each host in addition to the Common Information Model (CIM) RSAP
on ports 15988 and 15989.
KVM Platform Agent installation

Perform the following steps to install the KVM Platform Agent:
1. Download the latest KVM Platform Agent from the following IBM website:
https://www14.software.ibm.com/webapp/iwm/web/reg/download.do?source=dmp&S_PKG=
dir_63_x86_MDagents&lang=en_US&cp=UTF-8
2. Install the KVM Platform Agent prerequisites. See Example 5-10.
Example 5-10 Install required packages
[root@TPMfImages ~]# yum install -y libconfig.x86_64 libsysfs.x86_64

libsysfs.i686 libicu.x86_64 lm_sensors-libs net-snmp.x86_64
net-snmp-libs.x86_64 redhat-lsb.x86_64
3. Place the downloaded agent in the /tmp folder of your KVM host by using Secure Copy
Protocol (SCP) and an SCP tool. Uncompress the archive after transfer. Then, start the
KVM Platform Agent installation.
258
Tip: You might receive error messages that are related to dependencies even though you
have performed the upgrade. Use Yum to solve the dependencies issue and restart the
KVM platform agent installation.
When your KVM Platform Agent installation is completed, repeat these steps in all hosts that
are part of the KVM virtual host environment as hypervisors.
Note: A comprehensive step by step guide for installing the KVM Platform Agent can be
found in the following IBM Redbooks publication:
http://www.redbooks.ibm.com/redbooks/pdfs/sg248060.pdf
This publication is written for the IBM Flex System Manager, but the tasks in section 8.2
are also suitable for KVM Platform Agent installation for IBM Systems Director
environments.
Installing KVM image repository

One physical server is needed to act as an image repository. This server handles, for
example, all ISO volumes, which enable virtual server installation from disk images. This
server also tracks where captured appliances are. See Figure 5-4.
1 Set up SAN storage

Management
server
VMControl image repository
2 Install agent software
3 Collect inventory
RHEL
server
Image
Image
Agent
SAN
Image
4 Create image repository
Storage
pool
Figure 5-4 Procedure to create a SAN-based image repository
Installing the Common Agent

Perform the following steps to install the KVM Common Agent:
1. Download the latest Common Agent from the following IBM website:
https://www14.software.ibm.com/webapp/iwm/web/reg/download.do?source=dmp&S_PKG=
dir_63_x86_MDagents&lang=en_US&cp=UTF-8&&dlmethod=dd
2. Install the Common Agent prerequisites. See Example 5-11.
Example 5-11 Install required packages
[root@TPMfImages ~]# yum -y install libcrypt.so.1 libc.so.6 libdl.so.2

libstdc++.so.5 libgcc_s.so.1 libm.so.6 libnsl.so.1 libpam.so.0 libpthread.so.0
librt.so.1 unzip bind-utils net-tools libstdc++.so.6 libuuid.so.1 libexpat.so.0
259
3. Turn off the iptables on the Common Agent host. See Example 5-12.
Installing the Common Agent Services (CAS) agent correctly has been a problem in the
past. More troubleshooting information for CAS agent problems is in section 12.1,
Troubleshooting the installation of IBM Systems Director components on page 494. See
Example 5-12.
Example 5-12 Turn iptables off before installing the CAS agent
[root@TPMfImages ~]# chkconfig iptables off

[root@TPMfImages ~]# service iptables stop
iptables: Saving firewall rules to /etc/sysconfig/iptables:[
iptables: Flushing firewall rules:
[
iptables: Setting chains to policy ACCEPT: filter
[
iptables: Unloading modules:
[
OK
OK
OK
OK
]
]
]
]
4. Place the downloaded agent in the /tmp folder of your KVM host by using the SCP
protocol and an SCP tool. Uncompress the archive after transfer. Then, start the Common
Agent installation.
Note: Common Agent is installed by default in unmanaged mode. When IBM Systems
Director server discovers an unmanaged agent, the agent becomes managed after
requesting access.
If you want the agent to start out in managed mode, for example, because the IBM Systems
Director server is configured with more than one agent manager and you want to choose the
agent manager with which the agent associates, you can do so by using one of the following
two methods:
Install the agent in managed mode.
To install the agent in managed mode, use the optional diragent.rsp file, as described in
the following steps.
Tip: More information about using the diragent.rsp file can be found at the following
site:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.d
irector.install.helps.doc%2Ffqm0_t_installing_agents.html
Configure the agent for managed mode after installation.

To configure the agent for managed mode after installation, run the following configure.sh
command:
/opt/ibm/director/agent/runtime/agent/toolkit/bin/configure.sh -amhost
agentmanager_ip -passwd agentregistration_password -force
Tip: You can use the configure.sh -unmanaged -force command to return the agent to
unmanaged mode.
The agent will also change to managed mode automatically after you discover it, and
request access to it through the IBM Systems Director server.
260
Note: A comprehensive step-by-step guide for installing Common Agent can be found at
the following site:
This IBM Redbooks publication is for the Flex System Manager, but all tasks in section 8.3
are also suitable for the Common Agent installation for IBM Systems Director
environments.
Install the Storage Subsystem Agent to the image repository server

Install the Storage Subsystem Agent from IBM Systems Director release management.
Instructions can be found at the following information Center:
r.install.helps.doc%2Ffqm0_t_installing_agents.html
Notes:
When installing, be sure to select the proper agent:
CommonAgentSubagent_VMControl_commonrepository-2.4.1
A comprehensive step-by-step guide for installing the Storage Subsystem Agent can be
found at the following site:
This IBM Redbooks publication is written for Flex System Manager, but all tasks in
section 8.3.3 are also suitable for Storage Subsystem Agent installation in IBM System
Director environments.
Tip:
If you are having problems with requesting access to the Common Agent server, check
troubleshooting steps in section 12.1, Troubleshooting the installation of IBM Systems
Director components on page 494.
Create image repository in VMControl

To be able to create an image repository, IBM Systems Director VMControl needs
connectivity to SAN storage and to Fibre Channel switches. A best practice is to use IBM
SAN volume controller and or the v7000. Information on how-to create data sources for IBM
Systems Director is found in Chapter 11, Storage Management solutions and Storage
Control on page 451. Data sources for storage and Fibre Channel switches need to be in
order before an image repository can be created.
Use the smcli dumpstcfg command to ensure that all is in place, as shown in Example 5-13.
Example 5-13 smcli dumpstcfg command
root@ISD632:~> smcli dumpstcfg
SAN Configuration
-----------------------------Switches
-------Name
OID
BRCD:32R1819-YK10UZ774015
BRCD:32R1819-ZK11LV57B013
10.31.54.204
10.31.54.203
18599 10.31.54.199
20681
7596
7585
Provider IP
Switch IP
WWPN
10.31.53.18
10.31.53.4
10.31.54.204
10.31.54.203
100000051E04FE7E
261
forum_even_B32
forum_odd_B32
Storage Subsystems
-----------------Name
Largest Slice(in GBs)
18598 10.31.54.199
18600 10.31.54.199
10.31.51.4
10.31.51.3
OID
Provider IP
Fast Copy enabled?
SVC-2145-forumsvc-IBM
247.25
Yes(SSH)
Storwize V7000-2076-forumv7000-IBM
1924.0
Yes(SSH)
100000051E03845B
100000051E03D8E5
Subsystem IP
18339 -
{ '10.31.51.9' }
17798 -
{ '10.31.51.20' }
Example 5-13 on page 261 shows the connected Fibre Channel switches and storage
subsystems. You can scroll down to see more results, such as the physical hosts that have
connectivity to storage through Fibre Channel network zonings.
When zoning information and data sources are correct, you should see the storage pools that
are available before creating the image repository, as shown in Example 5-14.
Example 5-14 Accessible storage subsystems and pools
Server Accessible Containers

---------------------------NAME: STORAGE SUBSYSTEM/POOL
ISDKVM-node4:
SVC-2145-forumsvc-IBM/NOPEA_DS4700_10k_R5
SVC-2145-forumsvc-IBM/FlashCopy target pool
SVC-2145-forumsvc-IBM/NORMAALI_DS4700_10k_R6
SVC-2145-forumsvc-IBM/NOPEIN_DS4700_15k_R5
SVC-2145-forumsvc-IBM/HIDAS_DS4700_SATA_R5
SVC-2145-forumsvc-IBM/MigrationPool_8192
Storwize V7000-2076-forumv7000-IBM/Tier2
Storwize V7000-2076-forumv7000-IBM/Hybrid_Pool
ISDKVM-Node3:
ISDKVM-Node2:
ImageRepository:
262
Example 5-14 on page 262 shows three KVM nodes and a host named as the image
repository that has connectivity to two separate subsystems: IBM SAN Volume Controller and
the IBM Storwize v7000.
Note: You can add an image repository to VMControl using the IBM Systems Director
server user interface. Instructions for doing this can be found at the following link:
This IBM Redbooks publication is written for the Flex System Manager, but all of the tasks
in section 8.3.7 are suitable when working with the KVM Platform Agent installation tasks
in IBM Systems Director environments.
Figure 5-5 shows the Image Repositories window in the VMControl user interface.
Figure 5-5 Image repositories listed in IBM Systems Director VMControl
Create server system pools for KVM hosts

After zoning information and storage information have been checked and image repositories
have been successfully created, you can create a server system pool.
Server system pools enable you to group similar hosts. With IBM Systems Director
VMControl, you can create a system pool of selected hosts, add and remove hosts from the
system pool, enter and exit maintenance mode for the hosts, and permanently delete a
system pool.
If you have IBM Systems Director Network Control installed and licensed, you can also set up
and manage network system pools (NSPs) to leverage automated network relocation and
logical network provisioning.
Use the following steps to create a server system pool:
1. From the IBM Systems Director VMControl summary page, click the System Pools tab,
ensure that the view is set to Server system pools, and click Create.
2. Follow the instructions in the Create Server System Pool wizard to create a server system
pool that is composed of selected hosts and attached shared storage.
263
Note: A comprehensive step-by-step guide for creating server system pools in VMControl
can be found at the following site:
This IBM Redbooks publication is written for the Flex System Manager, but all of the tasks
in section 8.5 are suitable when working with server system pools in IBM Systems Director
environments.
Server system pool optimization settings

When creating a server system pool, you can choose from two optimization choices:
Manual optimization
Automatic optimization
You can change the settings later or adjust the optimization interval. The difference between
the two settings is that when automatic optimization is chosen, IBM Systems Director can
relocate virtual servers automatically and choose the proper server automatically when new
workloads are being deployed. See Figure 5-6.
Figure 5-6 Optimization interval settings
Operating with VMControl in KVM in a Red Hat Enterprise Linux

environment
After creating previous tasks, the KVM environment is ready for operations. The following
tasks can be performed when you are operating in the KVM infrastructure:
Create a new image in the image repository
Create a virtual server
Create an appliance from the virtual server
264
Import an existing virtual appliance

Deploy a virtual appliance to new workload
Group virtual servers to run under one workload
Relocate virtual servers and workloads
Create a new image in the image repository

Creating an image inside the image repository is a simple task. However, the principles for
handling images are a little different from what users are use to doing with other virtualization
environments.
VMControl needs an image repository host to manage images. Images are placed in
individual SAN volumes, which are shown to a new virtual server as CD/DVD drives. So the
difference between other hypervisor management tools is that there is no large image
repository where to put all images. Every image is an individual disk, which can be mounted
to a new virtual machine.
Follow these steps to create a new image in the image repository:
1. Transfer your image (for example, rhel6.3.iso) using SCP to the /tmp folder in the image
repository host.
2. Create a new volume into the image repository for that ISO file.
When creating virtual servers through the VMControl, the servers must have access to an
ISO file. The best way to do this is to create a storage volume with an _ISO extension that
the VMControl can mount and use to emulate as a CD/DVD device.
3. Create an ISO volume to the storage system to use this volume with the operating system
(OS) installation on your first guest. In the Resource Explorer view, find and right-click the
ImageRepository server (Figure 5-7 on page 266).
Note: If you click the operating system, the Create Storage Volumes menu will not show.
You need to click the physical server.
265
Figure 5-7 Choose image repository host and select Create Storage Volumes
When zoning information and data sources are properly installed, all available SAN
storage systems are seen after clicking System Configuration and Create Storage
Volumes. Then, select the storage pool where you want to place the new image
(Figure 5-8).
Figure 5-8 Select storage pool where the new volume for the ISO image will be located
266
After selecting Storage Pool and clicking Next, it is important to give access to the rest of
the KVM hosts. You can see available hosts in the list. The host list becomes available
from gathered zoning information.
Name the volume with the appropriate naming convention for the ISO image. For RHEL
6.3, for example, use RHEL63_ISO.
Note: If the storage volume does not end with ISO, you are not able to use this as a
CD/DVD emulated disk.
Size the disk correctly. An appropriate size for RHEL 6.3 x86 64 is 4 Gb. When volume is
created, it is in a thick format. You cannot choose thin provisioned. If you want to use the
storage system feature like compression, you have to create and name that volume in the
storage system user interface and give access to all hosts through that user interface.
When creating a disk for image, you use the add existing disk option.
After creating the new volume, go to the image repository server. You should see the new
volume in the image repository disk list.
Note: Do not mount that disk on to your image repository server and do not format it.
Leave it as is.
4. Copy the .ISO file to a new ISO volume
Go to the image repository server and list all disks. Select Create disk by listing disks and
check which disk has been added as new into the inventory (Example 5-15).
Example 5-15 List disks to get device path
[root@ISDNode1 director]# fdisk -l |more
Disk /dev/sdc: 4294 MB, 4294967296 bytes
64 heads, 32 sectors/track, 4096 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x023b007b
Device Boot
/dev/sdc1
*
Start
1
End
3509
Blocks
3593216
Id
17
System
Hidden HPFS/NTFS
In this case, the new disk is mapped to /dev/sdc1. Next, copy the ISO image to that device.
See Example 5-16.
Example 5-16 Copy image to device by using the dd command
[root@node11229 director]# dd if=/iso/RHEL6.3-Server-x86_64-DVD1.iso of=/dev/sdc

After the copying is done, the image is available for use as a CD/DVD device when creating
the new virtual server.
Create a new virtual server

After creating CD/DVD devices, you can proceed to create a new virtual server. Creating a
new virtual server is done from the VMControl user interface. Go to the Virtual Servers and
Hosts tab. When all virtual servers and hosts are listed, select one of the KVM nodes.
267
Note: The new virtual server can be created only when the physical KVM host is selected,
not the operating system.
1. Right-click and select System configuration. Then, select Create Virtual Server on the
menu and type the name of the virtual server. See Figure 5-9, which involves naming the
virtual server.
Figure 5-9 Name virtual server
2. Click Next and select the Processor amount. See Figure 5-10. Select the appropriate
number of CPUs.
Figure 5-10 Assign processor count
268
3. Click Next and assign the memory amount. See Figure 5-11. Specify memory amount.
Figure 5-11 Specify an appropriate amount of memory to the new virtual server
4. Click Next to see the Disks and Devices page. See Figure 5-12.
Figure 5-12 Disks and Devices page
The virtual machine does not have any disks, so the list is empty. By clicking Add Existing
disks, you can use existing disks that are available in the storage pools. By clicking Create
New, you can create a new volume to the available storage pools.
269
When you are creating a new server, you must have the installation media or an existing
PXE boot server. When using installation media, you need to add one of the existing ISO
volumes. Otherwise, the server tries to locate the boot media from the PXE server. If the
PXE server does not exist in your environment, the boot fails. See Figure 5-13.
Figure 5-13 The page where you can select the right ISO volume to the virtual servers disk list
5. Select the appropriate ISO volume for the new operating system installation and press
OK.
For creating the new primary volume for the virtual server, you have two options:
Create a volume with VMControl
Create a volume in the storage system and use it when creating a virtual server
When creating a volume with VMControl, it is automatically created to a storage system
and mapped to selected hosts. This is the easiest way to assign new disks to the virtual
server.
When creating a disk in the VMControl user interface, the disk type will be thick, no matter
what features your storage system might be providing.
When creating a volume with the storage system, for example with the v7000 or SVC, you
can use the storage system features like thin provisioning and compression. When the
volume is created, it needs to be assigned to all hosts that are on the same server system
pool.
Creating disks for virtual servers in the storage system might be good when creating
virtual servers that require a lot of disk space; or, when you want to use advanced features
that are provided by that specific storage system.
Note: When capturing the created virtual server, which uses a thin provisioned disk, it
will be converted as a generic thick drive.
270
When creating a new virtual server, which will be used later as the virtual server
appliance, the best practice is to use the VMControl user interface. See Figure 5-14.
All available storage pools are shown in the list in Figure 5-14 from all storage systems
that are connected properly into the IBM Systems Director system.
Figure 5-14 Select a storage pool for a virtual server new disk
6. Select a storage pool for the new virtual machine and click Apply. For our example, select
Hybrid_Pool. See Figure 5-15 on page 272.
Note: When creating the virtual appliance, remember that all new deployments of this
appliance will be deployed to the same storage pool, which you select at this point.
271
Figure 5-15 Additional settings for new volume
When the storage pool has been selected, name the volume. Proper naming convention is
to not use spaces. Notice that the size is in MB, so if you want to have a disk size around
10 GB, put 10,000 in the Size text box.
After sizing the disk, select the virtual bus type. Select either VirtIO or integrated
development environment (IDE) virtual bus types for the disk communication.
VMControl can use KVM on Red Hat Enterprise Linux para-virtualized VirtIO drivers.
VirtIO is a common standard framework allowing guests to be more easily moved between
hypervisor platforms, which are supporting VirtIO.
VirtIO allows for increased I/O performance for both network and block devices, when
compared to regular emulated devices.
Tip: If using the VirtIO bus with the new virtual server and you face problems, you can
change it to use the IDE bus and problems should not occur.
7. After selecting parameters, click OK and you are returned to the disk page. Click Next.
This is where you can define the boot order (Figure 5-16 on page 273).
272
Figure 5-16 Specifying the boot order for a new virtual server
When creating a new virtual server without an operating system, the first boot device
should be an ISO device that was created and selected in previous tasks. The second
boot device is the primary disk for the virtual server that was previously selected and
created.
8. Click Next and see the Network page (Figure 5-17).
When creating or editing a KVM virtual server, specify the networks that you want to
assign to the virtual server. However, only networks that are existing on that specific host
are displayed in the list of networks. Be sure that the same networks in all hosts are
available.
Figure 5-17 Select the proper network for your new virtual server
You can create additional networks for use with KVM by using IBM Systems Director
Network Control or create them manually as shown in Preparation on page 255.
If you do not have Network Control installed, you can collect the inventory against the
server and the server system pools to identify any predefined or new bridges that might
exist.
273
As shown in the example in Figure 5-17 on page 273, these predefined bridges are listed
because they were built in the preparation phase. If there is a need for more networks,
they must be created either manually or through the IBM Systems Director.
After selecting the appropriate network connection for your new virtual server, click Next.
The last page is a basic summary page. You can check to verify that all parameters are
correct for the new virtual server.
9. After checking parameters, click Finish.
You can run the job now or schedule it to run later. After the Create Virtual Server job has
been executed, the virtual server is created and ready for the operating system
installation.
By checking the task log that is shown in Figure 5-18, you can see what steps are taken
when creating the new virtual server and whether the task completed successfully or not.
If there are errors during deployment, they will be shown in this log and are very helpful
when solving potential problems.
April 19, 2013 6:48:52
EEST" activated.
April 19, 2013 6:48:53
April 19, 2013 6:48:53
April 19, 2013 6:48:53
April 19, 2013 6:48:53
April 19, 2013 6:48:53
April 19, 2013 6:48:53
April 19, 2013 6:48:54
started.
April 19, 2013 6:49:51
successfully.
April 19, 2013 6:50:01
RedHat-6.3Rb
April 19, 2013 6:50:01
"Complete".
April 19, 2013 6:50:01
April 19, 2013 6:50:01
PM EEST-Level:1-MEID:0--MSG: Job "Create Virtual Server - April 19, 2013 6:48:47 PM

PM
PM
PM
PM
PM
PM
PM
EEST-Level:200-MEID:0--MSG: Subtask "Create Virtual Server" activated.

EEST-Level:200-MEID:0--MSG: Starting clients
EEST-Level:100-MEID:0--MSG: Clients started for task "Create Virtual Server"
EEST-Level:200-MEID:0--MSG: Subtask activation status changed to "Active".
EEST-Level:1-MEID:0--MSG: Job activation status changed to "Active".
EEST-Level:200-MEID:0--MSG: Subtask activation status changed to "Active".
EEST-Level:200-MEID:0--MSG: Create virtual server 'RedHat-6.3Rb' processing
PM EEST-Level:200-MEID:0--MSG: Create virtual server process flow has been completed

PM EEST-Level:200-MEID:0--MSG: A new virtual server has been created successfully:
PM EEST-Level:100-MEID:7344--MSG: ISDKVM-Node2 client job status changed to
PM EEST-Level:200-MEID:0--MSG: Subtask activation status changed to "Complete".
PM EEST-Level:1-MEID:0--MSG: Job activation status changed to "Complete".
Figure 5-18 Log for executing Create Virtual Server job
After executing the Create Virtual Server job, the new server can be seen in the list of virtual
servers, similar to what is shown in Figure 5-19.
Figure 5-19 Virtual Servers and Hosts view: New virtual server can be found if search field is used
274
Installing the operating system

After creating the new server, start the server from the Systems Director user interface and
install the operating system. You can use the image repository server virtual machine
manager console for first time installations. In the image repository server, open connect
virtual machine manager and connect that to KVM host. Then, open the host and see the
virtual machines running on this host.
Note: After installing the operating system, you can use the remote control virtual
machines directly from IBM Systems Director with Virtual Network Computing (VNC). You
must have the VNC viewer installed on your machine.
Creating an appliance from a new virtual server

Virtual appliance is the captured virtual server and it can be used as a template for new
virtual servers. All virtual appliances that can be deployed are shown in the VMControl virtual
appliances tab. To capture virtual servers, you need the VMControl Enterprise Edition.
To use the new virtual server as an appliance, it needs to be captured. To capture an existing
virtual server for appliance use, it requires executing a specific activation engine tool, which is
located in the IBM Systems Director server.
Activation engine files can be found from IBM Systems Director running on Linux or AIX from
the following path:
/opt/ibm/director/proddata/activation-engine/
Activation engine files can be found from IBM Systems Director running on Windows from the
following path:
<install root>\ibm\director\proddata\activation-engine\
Steps to run an activation engine in Linux virtual servers

Perform the following steps to run the activation engine in Linux virtual servers:
1. Copy vmc.vsae.tar from the IBM Systems Director server using SCP or WINSCP.
2. Copy vmc.vsae.tar and move it to a /temp directory on your new virtual server.
3. Take the SSH connection to your new virtual server and execute 'tar xvf
/temp/vmc.vsae.tar'
4. Execute '/temp/linux-install.sh'
When asked, if your new guest is running on a KVM host, answer yes and allow the
installation to complete. Move back to the IBM Systems Director and now run an inventory of
the new virtual server. See Figure 5-20 on page 276.
275
Once the inventory is completed, move back to the SSH session of the virtual server and
execute 'AE.sh --reset'. Now the virtual server should do a graceful shutdown. See the SSH
session in Figure 5-20.
Figure 5-20 Executing script for preparing image for capturing
Running the activation engine in Windows virtual servers

Perform the following steps to run the activation engine in Windows virtual servers:
1. Copy WinVSAE.zip from the IBM Systems Director server using the copy function.
2. Copy WinVSAE.zip and move it to a /temp directory on your new virtual server.
3. Take the remote desktop connection to your new virtual server and unpack WinVSAE.zip
into the c:\temp directory.
4. Execute
c:\temp\install-win-vsae.vbs command in command prompt window.
This command installs required components for capturing. When that script has
completed, run the AE.bat --reset command.
Note: Comprehensive material for uninstalling and modifying parameters can be found at
the following site:
ctor.vim.helps.doc%2Ffsd0_vim_r_kvm_capture_reqs.html
After running the activation engine, the virtual server must be powered off and can be
captured from the IBM Systems Director VMControl user interface.
276
Capturing the virtual server

Select the virtual server. It should be already powered off after executing the reset script.
Select System Configuration and Capture. See Figure 5-21.
Figure 5-21 Capturing a new appliance from an existing virtual server: select System Configuration and
Capture
Note: A comprehensive step-by-step guide with screen captures that describes how to
capture a virtual server and do operational tasks, such as relocating, is at the following site:
This IBM Redbooks publication is for the Flex System Manager, but all tasks are suitable
when working with VMControl in IBM Systems Director environments.
277
Capture-related restrictions: The following restrictions apply to the capturing process:

Only servers that are in the powered-off state can be captured.
If you are using full virtualization, that is the IDE virtual bus type, select at most three
disks to be captured. The fourth IDE disk slot is reserved for image activation with an
ISO environment file during deployment.
You cannot perform capture and relocation tasks concurrently for the same virtual
server. Wait until one of these tasks is complete before beginning another.
Virtual server information that is captured is limited to processors, memory, disks,
network interfaces, and product activation properties.
Other information such as consoles, input devices, and video devices are not captured
to the appliance. Instead, default values for these items are used when the appliance is
deployed and these defaults match how a virtual server is created through VMControl.
ISO disks are not captured from the virtual server.
Importing a virtual appliance

Virtual appliance packages are in the Open Virtualization Format (OVF), which is a platform
independent and open packaging and distribution format for virtual servers. You can import
the virtual appliance package from the Internet or from a system in your network. After
importing the virtual appliance package, you can quickly deploy it into your environment.
Figure 5-22 on page 279 shows how a virtual appliance package can be imported to create a
new virtual appliance:
A user selects a virtual appliance package to import: Virtual appliance package A. The
virtual appliance package can reside either on your IBM Systems Director or on a web
server that is accessible to your IBM Systems Director.
Importing Virtual appliance package A results in the virtual appliance, Virtual appliance
A, which is stored by VMControl.
Virtual appliance A contains the metadata that describes the virtual server, and a
reference to Image A. Image A contains a fully configured and tested operating system
and software applications for the virtual server. And, is stored in a VMControl image
repository.
After Virtual appliance A is imported, you can use VMControl to deploy the Virtual
appliance A one or more times into your environment. See Figure 5-22 on page 279.
278
Management server with

VMControl Standard or
Enterprise Edition
Virtual appliance A
Metadata
VMControl image
repository
Image C
Image B
Image A
reference
Image A
Import
Internet
Virtual appliance
package A
Metadata
Image A
Figure 5-22 Importing the appliance into IBM Systems Director
Note: A comprehensive step-by-step guide with screen captures, how to import a virtual
appliance, and relocate a virtual server is found at the following site:
This IBM Redbooks publication is for the Flex System Manager, but all tasks are suitable
Exporting a virtual appliance

This topic shares the best practice on how to export the created virtual appliance in the IBM
Systems Director VMControl. The virtual appliance export runs on KVM and on Red Hat
Enterprise Linux. Perform the following steps to export:
1. Map the virtual appliance volume from the storage GUI to the host, which will be used as
the appliance export host. See Example 5-17.
Example 5-17 You can see appliance volume name while executing capture
April 26, 2013 6:22:38 PM EEST-Level:150-MEID:0--MSG: DNZCIR346I New disk group:
DG_04.26.2013-18:21:43:396
April 26, 2013 6:22:38 PM EEST-Level:150-MEID:0--MSG: DNZCIR353I The virtual appliance is
using disk group DG_04.26.2013-18:21:43:396 with the following SAN volumes:
[va_CentOS62-Export_1].
279
April 26, 2013 6:22:38 PM EEST-Level:150-MEID:0--MSG: DNZCIR354I The virtual server is

using disk group DG_04.21.2013-23:10:42:048 with the following SAN volumes:
[60050768028100B4CC00000000000214+9+00000200A0402D33+0].
2. Use for example, the Storwize v7000 user interface to map the appliance volume to a host.
The selected host can be any host. But it is a good idea to select an existing image
repository host with Red Hat Enterprise Linux, so the commands shown in the example
will apply. See Figure 5-23.
Figure 5-23 Storwise v7000 user interface, where appliance va_CentOS62-Export1 volume is seen
Ensure that you have enough disk space to capture the appliance.
3. Copy the raw drive to your image repository host directory.
Use the dd command to capture the raw drive, for example, assuming that the virtual
appliance drive becomes /dev/sdk. Use the command dd if=/dev/sdk
of=/root/export/<some_name>.
Example 5-18 shows an example that you might use for a disk, centos.
Example 5-18 Using the dd command to copy the disk to directory
[root@ImageRep ~]# dd if=/dev/sdk of=/root/export/centos

10485760+0 records in
10485760+0 records out
5368709120 bytes (5.4 GB) copied, 63.2503 s, 84.9 MB/s
[root@ImageRep ~]#
4. Use the smcli lsva -o command from the IBM Systems Directory. Smcli identifies the
object identifier (OID) of the virtual appliance. See Example 5-19.
Example 5-19 smcli lsva -o command
USERID@PureFlex:~> smcli lsva -o

CentOS6.2_Template, 27599 (0x6bcf)
CentOS62-Export, 28032 (0x6d80)
USERID@PureFlex:~>
In this case, the output from smcli lsva -o, is CentOS6.2_Template, 27599 (0x6bcf) and
CentOS62-Export, 28032 (0x6d80).
5. After you know the ID for this appliance, use smcli nimGetOVF <vaOID> to get the OVF file.
Execute smcli nimGetOVF 28032 > CentOS62-Export.ovf. You will find the .ovf file from
that directory where you currently are.
6. Next, you need to edit the OVF file. See Example 5-20 on page 281.
Find the line from the .ovf file:
<ovf:File
ovf:href="sanvolume://00000200A0402D33/@/60050768028100B4CC00000000000222"
ovf:id="file1" ovf:size="10485760000"/>
280
Example 5-20 Part of .ovf file: What you need to edit
http://schemas.dmtf.org/ovf/envelope/1 dsp8023_1.0.0.xsd
http://www.ibm.com/xmlns/ovf/extension/vim/2/rasd ibm-vim2-rasd_2.1.0.xsd"
xml:lang="en-US">
<ovf:References>
<ovf:File
ovf:href="sanvolume://00000200A0402D33/@/60050768028100B4CC00000000000222"
ovf:id="file1" ovf:size="10485760000"/>
</ovf:References>
<ovf:DiskSection>
<ovf:Info>List of Virtual Disks used by this package</ovf:Info>
<ovf:Disk ovf:capacity="10485760000" ovf:capacityAllocationUnits="byte"
ovf:diskId="disk1" ovf:fileRef="file1"
ovf:format="http://www.ibm.com/xmlns/ovf/diskformat/qemu.raw"
ovf:populatedSize="10485760000"/>
</ovf:DiskSection>
Edit this .ovf file to reflect the name of the raw drive <CentOS62> made before to the
image repository host:
<ovf:File ovf:href="Centos" ovf:id="file1" ovf:size="10485760000"/>
7. After editing the file, you have to unmount the appliance disk from the image repository if
you intend to deploy more workloads from this exported appliance.
8. Copy the raw disk file and .ovf file to the host, which will be used as the repository for
exported appliances. Keep the .ovf file and disk file together.
Now you should have the raw drive file and the .ovf file in edited format. You can import them
using the IBM Systems Director UI. When importing, you have to know the full path and file
name of the .ovf file.
Note: A comprehensive step-by-step guide with screen captures on how to import the
virtual appliance and relocate the virtual server is found at the following website:
The IBM Redbooks publication is for the Flex System Manager, but all tasks are suitable
281
Best Practices:
VMControl provides a large selection of features that can be used with KVM hypervisor.
Get to know restrictions and limitations, so you can design the purpose of that
environment correctly.
Use SAN (Fibre Channel storage, switches) to create your KVM environment.
Plan your network carefully, draw a picture where you have all required network
interfaces, VLANs, and networks.
Build your network ready before deployment; reserve all required NICs to your servers.
Plan your storage, calculate how much disk space you need, and what kind of storage
you need.
Create zones for servers and storage.
Build data sources ready to IBM Systems Director for storage and Fibre Channel
switches.
Check that all is in order before installing Red Hat Enterprise Linux.
Use Red Hat Enterprise Linux version 6.3.
Follow instructions given in this Redbooks publication.
Use IBM SmartCloud Entry to provide a self-service portal to your environment.
5.4 Managing VMware vSphere with VMControl

This topic describes the supported tasks with the VMware virtualization environment. It also
describes basic requirements and support for the VMware virtualization environment with
IBM Systems Director VMControl. To work with the VMware virtualization environment, you
need IBM Systems Director VMControl Express version.
If there is a new or existing VMware and IBM Systems Director environment, before
implementing VMControl to that environment, it is important to know the main goals for this
integration, and what capabilities and restrictions it provides to your management
environment.
VMware vCenter Server is the central management component for VMware ESX/ESXi hosts.
vCenter is used in almost all VMware environments, and is required to use VMware cluster
features. IBM Systems Director uses its VMControl plug-in to interact with vCenter. IBM
Systems Director does not aim at replacing vCenter.
VMControl uses the robust and virtualization-specialized vCenter to run tasks that are
targeted at the VMware vSphere infrastructure components.
IBM Systems Director provides an essential collection of most commonly used tasks by a
privileged administrator. By using these tasks, an enterprise administrator with full privileges
can manage all platforms in your chassis from the single IBM Systems Director interface. In
addition, administrative and more advanced tasks can be performed also directly on vCenter.
Additionally, integrating IBM Systems Director with VMware allows you to correlate events
and automate tasks over the physical hardware through your hypervisor, clusters, and virtual
servers. It gives you a full picture of your infrastructure end to end. By using IBM Systems
Director, you can operate your system from a single pane of glass from both a hardware and
software perspective. See the infrastructure on Figure 5-24 on page 283.
282
VMControl
IP network
Management
server
ESX
Virtual
server
x86-compatible
system
ESXi
VMware vCenter
Virtual
server
Operating system
Figure 5-24 VMware virtualization environment with VMControl
The environment and requirements described at a high level:

IBM Systems Director server is installed on a supported server.
IBM Systems Director VMControl Express version is activated.
Note: To launch the VMware Infrastructure Client or the VMware vSphere Client from IBM
Systems Director VMControl, the client must be installed on the IBM Systems Director
server system and on any system that you use to log in to the IBM Systems Director web
interface.
VMware vCenter is installed on an x86-compatible system.
Note: IBM Systems Director and VMControl require that the OS that VMware vCenter is
running on is an x86-compatible system with a Microsoft Windows-based OS.
VMware ESXi exists to host virtual servers that you can manage using VMControl.
Note: VMware ESXi is managed by VMware vCenter.
The VMware vCenter system is discovered and the request access task has completed.
After the request access task completes, the Configure Access task shows the vCenter
protocol in an OK state.
283
Note: If you installed VMware vCenter with a non-default port number, you must create a
VMware vCenter Server Discovery profile using the Discovery Profile wizard. Specify the
unique port number in the profile that you create.
For more information about VMware requirements, see the following site:
ctor.vim.helps.doc%2Ffsd0_vim_r_vmware_vcenter.html
5.4.1 VMControl support for VMware vSphere

IBM Systems Director VMControl supports the following tasks with VMware vSphere:
Create, edit, and delete virtual servers

Create a data center or cluster using the Create Virtual Farm wizard
Add a host to a data center or cluster using the Add host to farm function
Remove a host from a data center or cluster using the Remove host from farm function
Relocate virtual servers
Put a host into maintenance mode
Remove a host from maintenance mode
As listed, IBM Systems Director supports many general tasks with VMware. But if there is a
need to use some advanced tasks that are not listed here, it is required to use vCenter for
those actions.
Note: A source to work with IBM Systems Director and VMware virtualization with
step-by-step screen captures can be found at the following site:
The IBM Redbooks publication is for the Flex System Manager, but all tasks related to
VMware are suitable when working with IBM Systems Director.
The following tasks are supported by IBM Systems Director when working with VMware
standard vSwitch and IBM Distributed Virtual Switch 5000V version 1.0.2:
Discovery
Tip: You only need to discover the vCenter Server operating system. You do not need to
discover the ESXi hosts directly because those will be added automatically during the
vCenter Server managed endpoint (MEP) inventory. However, it is recommended to
discover out-of-band management modules (such as IMM) manually for all your ESXi hosts
in order to get accurate hardware status from your hosts and in order to be able to perform
power operations out of band.
Inventory
Configuration management and automated logical network provisioning (ALNP)
Note: The management address for version 1.0.2 of the IBM System Networking
Distributed Virtual Switch 5000V can be set up only in an IPv4 format.
Configuration management and automated logical network provisioning

You can work with the VLAN configuration and protocol configuration of some devices by
using the IBM Systems Director Configuration Manager. Additionally, such devices can be
284
members of network system pools, which will then support the automatic provisioning of
logical network profiles, for VLAN settings, during virtual machine (VM) management.
For more information about automating logical network provisioning in a VMware
environment, see the topic Network Control.
Note: The Disabling Protocol configuration on devices that are supported by configuration
management will block communication between IBM Systems Director and the network
device. In general, Protocol configuration should not be disabled.
You can use launch-in-context to access vendor management application for some devices
directly from the IBM Systems Director interface. This function opens the vendor
management application for the device you were viewing in IBM Systems Director. Tasks can
then be completed from within the vendor management software.
Note: This IBM Systems Director Network Control task requires additional steps. See the
topic Set up IBM System Storage Data Center Fabric Manager (DCFM) to integrate with
IBM Systems Director Network Control for more information:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.sdnm.adv.helps.do
c/fnc0_director_network_ctrl.pdf
Using IBM SmartCloud Entry with IBM Systems Director and VMware
vSphere
If you want to publish your vCenter and VMware environment as a self-service portal, it is
good to implement both IBM Systems Director and IBM SmartCloud Entry (SCE). In
Figure 5-25 on page 286, IBM Systems Director, vCenter, and SCE components are shown,
along with their discussion paths.
285
In Figure 5-25, IBM Systems Director monitors hardware, hypervisors, and vCenter. vCenter
is connected to IBM SmartCloud Entry, which provides advanced deployment for virtual
machines in VMware environments.
IBM Systems Director has a very important role in preventing hardware outages caused by
service outages. IBM Systems Director commands vCenter to place the host in maintenance
mode, which automates virtual server relocating before hardware problems occur.

vCenter driver
VMC driver

vCenter
Esxi host
VM Control
HW monitoring
Esxi host
x86 architecture
Figure 5-25 Component communication between Systems Director, vCenter, and SCE (if implemented)
Note: How to set up predictive failure alerts to do automated relocation in VMware is

presented with step-by-step instructions in the following Redbooks publication:
Best Practice:
Use IBM Systems Director for hardware management and monitoring.
Use IBM Systems Director Predictive Failure Analysis (PFA) with VMWare to avoid
hardware-caused outages.
Use IBM SmartCloud Entry to provide a single-provisioning portal to create and
manage virtual machines.
5.5 Managing Microsoft Hyper-V with VMControl

The management functionality provided by VMControl for Microsoft Hyper-V environments is
limited to the most basic tasks, regardless of the VMControl edition you are using.
VMControl currently only supports Microsoft Windows Server 2008 R2 Hyper-V.
286
To understand the basic architecture of Hyper-V management with IBM Systems Director and
VMControl, see the following information center site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.vim.helps.d
oc/fsd0_vim_r_hyper_v.html
Hyper-V hosts that are managed by a Microsoft System Center Virtual Machine Manager
(SCVMM) can also be managed at the same time by VMControl. Because VMControl only
enables basic tasks, this might be appropriate for example when operators do not have
privileged access to the SCVMM console.
In order to be able to manage Hyper-V from IBM Systems Director, perform the following
steps:
1. Enable the VMControl plug-in in your IBM Systems Director server
2. Discover, unlock, and inventory the operating system of your Windows Server 2008 R2
server that has the Hyper-V role
3. Deploy the IBM Systems Director platform or common agent for Windows on your Hyper-V
server, run an inventory, and unlock the physical server managed endpoint (MEP) that is
discovered
Online Content: For a video demonstration of the preceding tasks, see the following
video:
http://youtu.be/VUwp5JD1mws
You can also scan the QR code that is displayed in the left margin to go directly to the
video.
After those basic requirements have been met, you will be able to use the Virtual Servers and
Hosts VMControl Inventory view and new basic actions will be added to the MEP actions
menu.
In addition, if the Microsoft Windows Server 2008 R2 Hyper-v MEP is hosting virtual
machines, those will be added to the IBM Systems Director resources when the host is
inventoried. You will then be able to edit, stop, start, and remove those virtual servers on the
host as well as view the relationships between hosts and virtual servers.
For more information about what tasks specifically are supported, refer to the following page
in the IBM Systems Director information center:
r.vim.helps.doc%2Ffsd0_vim_r_virtualization_environments.html
In addition to the information that is available in the information center, here is a detailed list of
supported operations on Hyper-v using VMControl:
1. Creating virtual servers: This action is performed on the Hyper-V physical server MEP or
the Hyper-V OS MEP by right-clicking the MEP and selecting System Configuration
Create Virtual Server. When creating virtual servers with IBM Systems Director
VMControl, you are limited to specifying the following information:
a. The virtual server name
b. The number of processors allocated to the virtual server
c. The amount of memory allocated to the virtual server
287
d. The amount of virtual disk storage allocated to the virtual server. You can specify only
one virtual disk. You cannot change the virtual disk location. It will use the Hyper-V
server virtual storage default location.
e. To which network will the virtual server be attached? You can configure only one virtual
network adapter. You will also not be able to specify a VLAN ID for that network
connection.
Note: Creating a virtual server only creates the virtual machine and does not install the
operating system in that virtual machine. Because you have no way of mounting ISO
images to the newly created virtual server in VMControl, you will have to switch to the
Hyper-V Manager management console in order to complete the virtual server
installation.
2. Editing virtual servers: This action is performed on the virtual server MEP by right-clicking
the MEP and selecting System Configuration Edit Virtual Server. It is only available
when the virtual server is powered off. You will be limited to changing the following
components:
a. The number of processors allocated to the virtual server
b. The amount of memory allocated to the virtual server
3. Removing virtual servers: This action is performed on the virtual server MEP by
right-clicking the MEP and selecting Permanently Delete Virtual Server. It is only
available when the virtual server is powered off. This action will give you the option to
delete the associated virtual disk storage, but it will not do so by default.
4. Viewing virtual servers and hosts relationship: You can view this relationship by selecting
the Virtual Servers and Hosts inventory view, as shown in Figure 5-26 on page 289. The
Hyper-V OS MEP where you installed the platform or common agent is only shown as an
association with its physical server MEP in that view and not as an independent object.
5. Viewing virtual servers resource utilization: You can view CPU resource utilization for
virtual servers from the Virtual Servers and Hosts inventory view, as shown in
Figure 5-26 on page 289. You can also view the CPU and memory allocation from that
window, but no other performance metric is supported.
6. Manage power operations on hosts and virtual servers: You can start, shut down, restart,
or suspend virtual servers as well as start, shut down, and restart hosts. Power actions
can be forced or performed cleanly, meaning that the operating system will gracefully shut
down before the server or virtual server is powered off or restarted. From the host server
MEP, you can force power off or start all virtual servers. If you need to gracefully shut down
or restart multiple virtual servers, simply select each one in the Virtual Servers and
Hosts inventory view (Figure 5-26 on page 289), then select Actions Power On/Off
Restart or Shutdown and power off.
Warning: The Power Off Now and Restart Now actions will not perform a graceful
shutdown and restart of the operating system (whereas the Restart and Shutdown
and power off actions will). Only use those actions when the operating system is not
installed or not responding.
288
Figure 5-26 The Virtual Servers and Hosts inventory view
Online content: In addition, for a video demo of the preceding tasks, see the following link:
http://youtu.be/0KGu0nGw7nY
You can also scan the QR code that is displayed in the left margin to go directly to the video.
5.5.1 Best practices for managing Microsoft Hyper-V with VMControl

The following list contains recommendations of what you should and should not do while
managing Microsoft Hyper-V with VMControl:
Always collect inventory on a Hyper-V server MEP before doing any action: This helps
ensure that you are not trying to take actions on objects that have been modified outside
of VMControl and for which the information in the IBM Systems Director inventory is not up
to date. Collecting up-to-date inventory on the virtual servers is not as critical because
actions are taken at the hypervisor layer and not at the guest layer.
Always configure your Hyper-V host before managing it from VMControl: If you cannot
create virtual machines on your Hyper-V host using the Microsoft Hyper-V Manager
console, VMControl will also not be able to create virtual servers for you.
Remember that the Platform or Common Agent is only required on the host, not in the
guests.
There is no need to discover Hyper-V virtual machines directly: They are discovered
automatically when you inventory the host MEP (that is, the virtual server MEP that is
being discovered, not the guest operating system MEP).
Always use the Virtual Servers and Hosts view because this is the only view that updates
dynamically. You can customize this view to add additional columns if it does not contain
the information you require by default. The view refreshes every 30 seconds. The first time
you access the view, it might take as long as 60 seconds to display current information.
289
Do not use Remove to delete virtual servers because this will only remove the MEP
from the IBM Systems Director inventory and leave the virtual machine on the Hyper-V
host.
5.6 Using IBM SmartCloud Entry with VMControl

This topic describes IBM SmartCloud Entry main functionalities with IBM Systems Director
VMControl. With IBM SmartCloud Entry 2.4, you can maintain control over the allocation of
resources with a web-based application.
IBM SmartCloud Entry is implemented as a lightweight web-based application that runs as an
Open Services Gateway initiative (OSGi) application.
You can perform with different hypervisors common public or private cloud operations, such
as:
Configuring multiple cloud support
Provisioning and de-provisioning servers
Drafting and cloning workloads
Capturing workloads
Starting and stopping servers as part of a workload
Resizing existing servers
Creating projects to give team-specific access to workloads
Providing network configurations, which set unique network properties to different
workloads
Billing, accounting, and metering support
Providing request and approval workflow support
5.6.1 IBM SmartCloud Entry hypervisor support

IBM SmartCloud Entry supports multiple hypervisors and multiple cloud connections. That
means that you can use the most cost-efficient platform to produce your virtualization
services.
Hardware, hypervisor, and hypervisor controller stack can then include multiple VMware
environments and multiple VMControl environments. In the future, there will also be support
for OpenStack driver for Microsoft Hyper-V. See Figure 5-27 on page 291.
290

OpenStack driver
MS Hyper-V
vCenter driver
vCenter driver
vCenter
vCenter
VMware
VMware
x86 architecture
VMC driver
VMC driver
VM Control
VM Control
Rhel KVM
PowerVM
Rhel KVM
p architecture x86 architecture
PowerVM
p architecture
Figure 5-27 IBM SmartCloud Entry with multiple cloud sources and connections
IBM SmartCloud Entry can be a provisioning portal from small customers to large service
providers that enables use of different cloud sources and a full view to the whole
infrastructure from a single view.
Multi-architecture, multi-hypervisor, and multi-cloud connection capabilities are important
features when calculating the total cost price for a virtual machine. Parameters should then
include for example, architecture cost, hypervisor cost, guest operating system, and
application cost.
These calculations are very useful for all and will guide future virtual server placements,
where to deploy what virtual servers. The cost structure of hypervisors, guest OSs, and
applications can be different when there is a shared infrastructure for multiple customers or it
is dedicated. Remarkable cost savings can also be achieved when using, for example,
different architecture with certain applications.
5.6.2 IBM SmartCloud Entry and VMControl

IBM SmartCloud Entry provides a web management portal for appliances that have been
created with VMControl. To see all those workloads or virtual appliances, you need to first
install IBM SmartCloud Entry and then configure a cloud connection to your VMControl
application programming interface (API).
Cloud source configuration

To configure IBM Systems Director VMControl API against IBM SmartCloud Entry, you need
to create a new cloud source from the administrator panel. Select a proper name for it and it is
important to select the right connection type. When configuring VMControl, use the
VMControl connection type.
The version is as important as the connection type. The version is dependent on which
version your VMControl is. If you have the latest version of VMControl, use it. See Figure 5-28
on page 292.
291
Figure 5-28 IBM SmartCloud Entry cloud configuration for VMControl
After configuring this cloud source, IBM SmartCloud Entry shows running workloads and
virtual appliances. Then, you can manage workloads and deploy new workloads through this
web-based user interface. See Figure 5-29.
Figure 5-29 IBM SmartCloud Entry and IBM Systems Director VMControl cloud source workloads
292
These two workloads are the same, which are running on the IBM Systems Director
VMControl environment. See Figure 5-30.
Figure 5-30 Workloads running on IBM Systems Director under VMControl
Deploying a new virtual server from an existing appliance

When you want to deploy a new workload from virtual appliances to deploy a new virtual
server, you will see those also in IBM SmartCloud Entry. See Figure 5-31.
Figure 5-31 Virtual appliances that are seen in IBM SmartCloud Entry
Virtual appliances come from the IBM Systems Director VMControl through an API. See
Figure 5-32 on page 294.
293
Figure 5-32 Appliances running under VMControl
Before deployment, you need to configure basic settings for the appliances. Configuration is
done by using the IBM SmartCloud Entry user interface, and you will need to feed the basic
parameters to each virtual appliance. Those parameters will guide the appliance, where, and
how this appliance is deployed into the IBM Systems Director VMControl environment. See
294
Figure 5-33 Capture of some parameters related to the VMControl appliance
IBM Systems Director VMControl appliance deployment can be done from the IBM
SmartCloud Entry user interface after configuring the appliance parameters.
You can give permissions from the IBM SmartCloud Entry configuration panels to gain access
for end users, who can request new workloads and the administrator approves, rejects, or
changes some deployment parameters. IBM SmartCloud Entry does have its own view for
end users and administrators, and it supports approvals and different project views.
After placing parameters for a virtual appliance, to deploy a new server you need to choose
the proper appliance and click Deploy. See Figure 5-34 on page 296.
295
Figure 5-34 At the deployment phase, you can still adjust multiple parameters
When you have deployed a new workload from an existing appliance and the administrator
has approved it, the new workload is displayed in VMControl. See Figure 5-35 on page 297.
296
Figure 5-35 The new virtual server is displayed in VMControl after deployment
5.6.3 IBM SmartCloud Entry and VMware virtualization

This topic describes what extensions that the IBM SmartCloud Entry provides when working
in VMware virtualization environments.
First, all basic features that are shown in the previous IBM SmartCloud Entry topic and IBM
SmartCloud introduction chapter will apply also in the VMware environment. IBM SmartCloud
Entry uses VMware vCenter API to communicate with the VMware environment. vCenter API
brings more rich features to virtual server configurations such as resource pools, datastores,
networks, or cluster selections.
Therefore, you can define very accurately where to deploy new workloads and what
capabilities they have. See Figure 5-36 on page 298.
297
Figure 5-36 IBM SmartCloud Entry VMware template parameters
After configuring the appliances, they are ready for deployment as explained in previous
IBM SmartCloud Entry chapters.
Note: More information about IBM SmartCloud Entry can be found at the following site:
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W21ed5ba
0f4a9_46f4_9626_24cbbb86fbb9
5.7 Managing PowerVM with VMControl

PowerVM provides the industrial-strength virtualization solution for IBM Power Systems
servers and blades. This solution provides proven workload consolidation that helps clients
control costs and improves overall performance, availability, flexibility, and energy efficiency.
PowerVM is a combination of hardware enablement and value-added software.
There are three versions of PowerVM, suited for various purposes:
PowerVM Express Edition
It provides more advanced virtualization features at a highly affordable price.
PowerVM Standard Edition
298
It provides the most complete virtualization functionality for AIX, IBM i, and Linux OS.
PowerVM Enterprise Edition
It provides IBM Active Memory Sharing and Live Partitioning Mobility.
5.7.1 VMControl supported features on PowerVM

IBM Systems Director VMControl is a cross-platform product that assists you in rapidly
deploying virtual appliances to create virtual servers that are configured with the operating
system and software applications that you want. It also enables you to group resources into
system pools, which enable you to centrally manage and control the different workloads in
your environment.
Table 5-1 shows which tasks are supported in each virtualization environment on each
Systems Director edition.
Table 5-1 VMControl supported features
IBM
Systems
Director
edition
Supported Tasks
Express
Editions
Create, edit, and delete

virtual servers
Yes
Yes
Yes
Yes

virtual farms
Yes2
Yes
Yes
Yes
Yes
Yes
Put hosts into maintenance

mode and remove hosts from
maintenance mode
Yes
Yes
Yes
Import virtual appliance

packages
Yes
Yes
Capture virtual servers
Yes
Yes
Capture workloads
Yes
Yes
Deploy virtual appliances
Yes
Yes
Start, stop, and delete

workloads
Yes
Yes

workloads
Yes
Yes3

server system pools
Yes4
Yes

storage system pools
Yes
Standard
Edition
Enterprise
Edition
IBM Power
Systems in a
virtualized
environment1
VMware
vCenter and
VMware ESX
or ESXi,
managed by
VMware
vCenter
Windows
Server 2008,
Ent., Std., and
Datacenter x64
Editions with
Hyper-V role
enabled
Linux
kernel-based
virtual
machine
(KVM)
1. For systems that are managed by Hardware Management Console, IBM Flex System Manager, or Integrated
Virtualization Manager.
2. Not supported for IBM Flex System Manager.
299
3. This virtualization environment does not support encapsulating virtual servers into system pool management in
groups as workload.
4. For systems that are capable of PowerVM live partition mobility, with the Active Mobility property set to True.
5.7.2 Supported Power virtualization environments

Described in this section are the virtualization environments that are supported by IBM
Systems Director VMControl.
AIX using Network Installation Manager

Ensure that your environment satisfies the support and requirements for the components in a
Network Installation Manager (NIM)-based Power Systems virtualization environment,
including the management server, host, operating systems, and storage.
Figure 5-37 shows an example Power Systems virtualization environment for AIX virtual
appliances, virtual servers, and workloads that rely on NIM. In this example, the Power
Systems server is managed by the HMC.
Figure 5-37 NIM-based Power Systems virtualization environment diagram
Following are the required components for a PowerVM environment using NIM:
IBM Systems Director VMControl Standard Edition or IBM Systems Director VMControl
Enterprise Edition is activated.
At least one NIM master is available.
IBM Systems Director Common Agent and the VMControl NIM subagent are installed on
the NIM master.
Restriction: You must install the dsm.core file set on the NIM master before the NIM
subagent installs successfully.
300
IBM Systems Director server recognizes this NIM master as a VMControl image
repository. The /export/nim file system in which the virtual appliances are stored must not
be NFS mounted to the NIM master. The NIM master exports this file system itself, and
NFS does not support the export of a mounted file system.
Note: The image repository is shown as a stand-alone server in the diagram. However,
the image repository can also be on the same Power Systems server that hosts the AIX
virtual servers that you can capture from and deploy to using VMControl.
At least one Power Systems 5, 6, or 7 server or blade exists to host virtual servers that you
can capture from and deploy to using VMControl.
Notes: If you plan to use N-Port ID Virtualization (NPIV) with Fibre Channel storage,
the Power Systems server must be a POWER6 processor-based server, or higher.
If manual or automated virtual server relocation capabilities are needed, multiple Power
Systems 6 or 7 servers are required.
The Power Systems server can be managed by the HMC, as shown in Figure 5-37 on
page 300, or by IVM.
Note: For blades and low-end Power Systems servers, you can use IVM on the Virtual
I/O Server (VIOS) virtual server instead of the HMC.
The Power Systems server is typically attached to a SAN as shown in the diagram. The
SAN is used for the Fibre Channel storage or the virtual disks of the virtual servers that
are hosted by the Power Systems server. A SAN is required to use the following
capabilities:
VMControl Enterprise Edition server system pools
Relocation
NPIV
If you do not plan to use these capabilities, a SAN is not required. Alternately, you can use
disks that meet all of the following criteria:
Disks that are local to the Power Systems server
Disks that are virtualized by the VIOS
Though not shown in the diagram, multiple VIOS virtual servers and multi-path I/O (MPIO)
are supported.
For more information about supported AIX versions, firmware versions, and storage, see the
following site:
r.vim.helps.doc%2Ffsd0_vim_r_power_component_reqs.html
Supported tasks
In this environment, you can perform the following tasks:
Import a virtual appliance package containing an AIX mksysb image
301
Capture an AIX workload or virtual server, an AIX mksysb image file or NIM resource, or an
AIX lpp_source directory or NIM resource
Deploy an AIX mksysb or lpp_source virtual appliance
Group virtual servers to create a workload
Start, stop, and edit a workload
Create, edit, and delete system pools
AIX using Storage Copy Services

Ensure that your environment satisfies the support and requirements for the components in a
Storage Copy Services (SCS)-based Power Systems virtualization environment, including the
management server, host, operating systems, and storage.
Figure 5-38 shows an example Power Systems virtualization environment for AIX, IBM i, and
Linux virtual appliances, virtual servers, and workloads that rely on SCS. In this example, the
Power Systems server is managed by the HMC.
Figure 5-38 SCS-based Power Systems virtualization environment diagram
Following are the required components for a PowerVM environment using SCS:
IBM Systems Director VMControl Standard Edition or IBM Systems Director VMControl
Enterprise Edition is activated.
A VIOS virtual server exists on a Power Systems server. The VIOS virtual server hosts the
image repository used to store the raw disk images associated with your AIX, IBM i, and
Linux virtual appliances.
302
Note: You can have multiple repositories. However, for repositories that are on separate
Power Systems servers, the image repository virtual servers must have access through
a VIOS to the same shared SAN as the AIX, IBM i, and Linux virtual servers that they
capture and deploy.
The IBM Systems Director Common Agent and the VMControl Common Repository
subagent are installed on the VIOS that you want to use as an image repository.
At least one Power Systems 5, 6, or 7 server or blade exists to host virtual servers that you
can capture from and deploy to using VMControl. If you plan to use NPIV with Fibre
Channel storage, the Power Systems server must be a POWER6 processor-based server,
or higher.
The Power Systems server can be managed by the HMC as shown in Figure 5-38 on
page 302, or by IVM.
Note: For blades and low-end Power Systems servers, you can use IVM on the VIOS
virtual server instead of the HMC.
All AIX, IBM i, and Linux virtual servers to be captured from or deployed to using
VMControl:
Have their storage allocated from the SAN
Must use virtual Ethernet connections or Fibre Channel connections that are provided
through one or more VIOS virtual servers. The AIX, IBM i, and Linux virtual servers
must not have any physical devices allocated from the Power Systems server.
For VIOS Version 2.2.2.0, any images for virtual servers that you capture, and that are
using a shared storage pool, must be captured into a repository that uses the same
shared storage pool. Any virtual servers that you deploy must use the same shared
storage pool as the image repository in which you store the virtual appliance images.
For more information about supported operating systems and firmware versions, see the
following site:
oc/fsd0_vim_r_sb_aix_on_power_component_reqs.html
Supported tasks
In a Power Systems virtualization environment for AIX, IBM i, and Linux that relies on SCS,
you can perform the following tasks:

Import virtual appliance packages containing an AIX, IBM i, or Linux raw disk image
Capture an AIX, IBM i, or Linux workload or virtual server (logical partition)
Deploy an AIX, IBM i, or Linux raw disk image virtual appliance
Group virtual servers to create a workload
Start, stop, and edit a workload
In a Power Systems virtualization environment for AIX and Linux that relies on SCS, you can
perform the following additional tasks:
Create, edit, and delete system pools
303
Table 5-2 lists the virtualization tasks supported through HMC and IVM.
Table 5-2 Supported virtualization tasks through IVM and HMC
Virtualization tasks
IVM
Included in PowerVM
Yes
Manage Power Blades
Yes
Manage more than one server
HMC
Yes
Hardware monitoring
Yes
Yes
Service agent call home
Yes
Yes
Graphical interface
Yes
Yes
Requires a separate server to

run on
Yes
Advances PowerVM features
Yes
High-end servers
Yes
Low-end and midrange servers
Yes
Yes
Redundant setup
Yes
Yes
5.7.3 How to activate IBM Systems Director VMControl

You must activate IBM Systems Director VMControl before it can be used. VMControl comes
with an evaluation license, which enables use of the optional chargeable (fee-based)
management functions.
There are two ways to activate VMControl:
Activating VMControl using the IBM Systems Director web interface
1. From the IBM Systems Director home page, click the Plug-ins tab.
2. In the Additional plug-ins to activate section (Figure 5-39), click Activate now under the
IBM Systems Director VMControl heading.
Figure 5-39 Activate VMControl
304
3. When the activation has completed, the following message is displayed (Figure 5-40).
Then, restart IBM Systems Director server.
Figure 5-40 VMControl activated
Activating VMControl using the command-line interface

1. From a command-line prompt, type the following string, and then press Enter:
smcli activatemgrs VMControl
2. When the activation has completed, restart IBM Systems Director server.
VMControl permanent license key

When you activate IBM Systems Director VMControl Express Edition, you are granted an
evaluation period for IBM Systems Director VMControl Standard Edition and IBM Systems
Director VMControl Enterprise Edition. When the evaluation period expires, you must
purchase a license and install a license key to continue using these editions. You can install
this license key by using an installation wizard. More information about license keys is shown
at the following site:
r.vim.helps.doc%2Ffsd0_vim_t_installing.html
You can also install the license key silently by using a response file to specify information that
the installation program requires. See the following site:
r.vim.helps.doc%2Ffsd0_vim_t_installing_silent_perm.html
5.7.4 Preparing the PowerVM environment for VMControl

Before you can use IBM Systems Director VMControl Standard Edition and IBM Systems
Director VMControl Enterprise Edition, you must prepare your PowerVM environment, set up
an image repository, and install the appropriate VMControl agent or subagent on the system
that hosts the image repository.
Table 5-3 lists the AIX versions and firmware required for VMControl for each supported
environment.
Table 5-3 Supported AIX and firmware versions for VMControl
Network Installation Manager
(NIM)
Storage Copy Services (SCS)
IBM Systems
Director server
IBM Systems Director server V6.3.2

or later with IBM Systems Director
VMControl V2.4 activated.
IBM Systems Director server V6.3.2

or later with VMControl Standard
Edition or VMControl Enterprise
Edition V2.4 activated.
NIM master
AIX 6.1 TL03 or newer.
HMC
HMC V7R3.5 and all available updates.
305
Network Installation Manager

(NIM)
VIOS
Power Systems
firmware
Storage Copy Services (SCS)
POWER5 and POWER6: Use a minimum of VIOS 2.1.2.0 and all

available updates.
POWER7: Use a minimum of VIOS 2.2.1.0 and all available updates.
Operating systems
Virtual appliances
You can capture any AIX Version 5.3,

AIX Version 6.1, or AIX Version 7.1
virtual server or workload as a virtual
appliance, and you can import or
deploy any AIX Version 5.3, AIX
Version 6.1, or AIX Version 7.1 virtual
appliance.
EMC requirements
VIOS 2.2.1.4 or later on your Power

Systems hosts.
NPIV
POWER5 and POWER6 servers,

use a minimum of FW3.5 and all
available updates.
POWER7 processor-based
servers, use a minimum of
FW7.2 and all available updates.
AIX: AIX Version 5.3 TL9, or
later; AIX Version 6.1 TL2, or
later; or AIX Version 7.1.
Linux on Power Systems: SUSE
Linux Enterprise Server 10 SP3,
or later; or SUSE Linux
Enterprise Server 11.
IBM i: IBM i 7.1 TR3, or later.
NPIV is supported only if the following two conditions are met:

The network switch must be an IBM Flex System FC5022 16 Gb SAN
Scalable Switch.
The SAN storage must be virtualized by IBM System Storage SAN
Volume Controller (SVC) or the storage array is either an IBM Flex
System V7000 Storage Node or an IBM Storwize V7000 system.
You cannot manage the storage devices by using the SMI-S provider
through IBM Systems Director.
NPIV supports multi-disk virtual server disk attachment.
Each disk that is allocated to the operating system on the virtual server
must access its storage through a VIOS virtual Small Computer System
Interface (SCSI) path or a VIOS NPIV path.
Discovering your storage and switch provider

See Chapter 11, Storage Management solutions and Storage Control on page 451 for
detailed steps to run the discovery of the storage and the switch provider.
306
Discovering your Power Systems environment

Run the HMC discovery as a regular discovery operation. After the discovery, request access
to the HMC and collect inventory. Figure 5-41 shows an example of an HMC discovered and
inventoried.
Figure 5-41 Example of HMC discovered and inventoried
For more information about configuring HMC and IVM, see the following site:
r.vim.helps.doc%2Feica7_t_configuring_power_plat_managers.html
Note: Ensure that the ID that will be used to request access to the HMC has
hmcsuperadmin rights or hmcoperator rights.
Discover Virtual I/O Server

Before discovering your VIOS, check the following requisites:
Ensure that your VIOS servers are not managed by any other IBM Systems Director
instance. Check that there are no certificates in the following directory:
/opt/ibm/director/agent/runtime/agent/cert
Check if the CAS agent is running:
/opt/ibm/director/agent/runtime/agent/bin/endpoint.sh status
After the VIOS is discovered, request access and collect inventory (Figure 5-42).
Figure 5-42 VIOS discovered
Install IBM Systems Director VMControl NIM subagent

You can install a VMControl subagent by using the installation wizard or you can manually
install the subagent. Ensure that your system meets the following requirements:
AIX 6.1.3 or later
The following file set is installed: dsm.core
307
Secure shell is installed and configured

The systems must be configured as a NIM master system:
#lsnim -l master
Cstate = ready for a NIM operation
Ensure that your NIM server has password-less access to the HMC/IVM using the SSH
keys. For more information about how to configure your SSH keys, see the following site:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD101248
Ensure that the system clocks on the IBM Systems Director server and the target system
match as closely as possible. If the system clocks do not match closely enough,
installation of the Common Repository subagent might fail.
Check that tftpd and bootps are active on NIM:
#ps -ef | grep -i tftpd
#lssrc -t bootps
Service Command Description Status
bootps /usr/sbin/bootpd bootpd /etc/bootptab active
The NIM repository must require additional configuration if the NIM repository (NIM
master) connects to IBM Systems Director through one network adapter, and connects to
the virtual server where you plan to deploy a virtual appliance through a different network
adapter. For more details, see the following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.vim.help
s.doc/fsd0_vim_t_installing_agent_NIM.html
To install a VMControl subagent from the IBM Systems Director Release Management task,
follow these steps:
1. In the IBM Systems Director navigation pane, expand Release management.
2. Click Agents.
3. On the Agents page, click Common Agent Subagent Packages.
4. From the Common Agent Subagent Packages view, select the subagent that you want to
install.
5. Click Actions on the menu bar, and select Release Management Install Agent.
6. Follow the instructions in the installation wizard to install the subagent for your
virtualization environment.
7. When it is complete, the NIM server will be shown in IBM Systems Director (Figure 5-43).
Figure 5-43 NIM server discovered
For more information about VMControl agents and subagents, see the following site:
ctor.vim.helps.doc%2Ffsd0_vim_t_installing_agent.html
8. Collect the inventory from your NIM server.
9. Finally, your VMControl is ready to be used. See Figure 5-44 on page 309.
308
Figure 5-44 VMControl ready
5.7.5 Storage allocation supported by IBM Systems Director VMControl

VMControl supports different types of storage allocation: Virtual SCSI, NPIV, and shared
storage pool:
Virtual SCSI
Virtual Small Computer System Interface (SCSI) is used to refer to a virtualized
implementation of the SCSI protocol. Virtual SCSI requires POWER5 or later hardware
with the PowerVM feature activated. It provides virtual SCSI support for AIX, IBM i
(requires POWER6 or later), and supported versions of Linux.
Virtual SCSI is based on a client/server relationship. The Virtual I/O Server owns the
physical resources and acts as a server or, in SCSI terms, target device. The client logical
partitions access the virtual SCSI backing-storage devices provided by the Virtual I/O
Server as clients.
Three types of storage allocation that are supported by Systems Director can be grouped
under virtual SCSI: virtual disk, physical volumes, and shared storage pool.
NPIV or virtual Fibre Channel
N-Port ID Virtualization (NPIV) is also known as virtual Fibre Channel. NPIV allows an
NPIV-capable Fibre Channel adapter to be configured with multiple virtual world-wide port
names (WWPNs). It is similar to the virtual SCSI functionality. The main difference is that
the VIOS does not act as a SCSI emulator to its client partitions. It acts as a Fibre Channel
pass-through for the Fibre Channel protocol I/O traffic through the Power Hypervisor.
Shared storage pool
A shared storage pool is a server-based storage virtualization that is clustered and is an
extension of existing storage virtualization on the Virtual I/O Server.
Shared storage pools simplify the aggregation and tasks of large numbers of disks across
multiple VIOSs; it improves the utilization of the available storage.
309
After the physical volumes are allocated to a Virtual I/O Server in the shared storage pool
environment, the physical volume management tasks, such as capacity management or
an allocation of the volumes to a client partition, are performed by the Virtual I/O Server.
Figure 5-45 shows an abstract map of each storage implementation.
Figure 5-45 Virtual disks, NPIV, and shared storage pool supported by VMControl
For more information about storage virtualization on PowerVM, see the following Redbooks
publication: IBM PowerVM Virtualization Introduction and Configuration, SG24-7940.
http://www.redbooks.ibm.com/abstracts/sg247940.html
5.7.6 Managing virtual servers with VMControl Express Edition

With IBM Systems Director VMControl Express Edition, you can edit, delete, and relocate
virtual servers from one host to another. Also, it is possible to perform manual and automatic
relocation.
Creating a virtual server

For IBM Systems Director VMControl in a Power Systems environment, a virtual server
creation is tightly coupled with a virtual appliance creation or use. However, an empty virtual
server can be created without a virtual appliance creation or input, and no workload is
generated. The result is an empty virtual server into which the software image of the virtual
appliance can be installed later.
The information requested is specific to the virtualization environment on which the virtual
server is being created.
310
1. Go to VMControl and click the Virtual Servers/Hosts tab (Figure 5-46). You will see a list
of your Power Systems servers and all the VMs that each server contains.
Figure 5-46 VMControl: Virtual Servers/Hosts panel view
2. Right-click the Power Systems server where you want to create the VM, and select
System Configuration Create Virtual Server (Figure 5-47).
Figure 5-47 Creating a virtual server on your Power server
311
3. Type the name of your VM as shown in Figure 5-48.
Figure 5-48 Choose the name of the new VM
4. Select the operating system as shown in Figure 5-49.
Figure 5-49 Choose the OS that will run on the new VM
5. Configure the number of processors. This step allows you to assign your virtual
processors or use dedicated processors for your virtual server (Figure 5-50).
Figure 5-50 Number of processor assignation
6. Configure the amount of memory. This step (Figure 5-51 on page 313) allows you to set
up your memory size.
312
Figure 5-51 Memory size configuration
7. Select your disk configuration (Figure 5-52). You can add an existing storage or create a
new one. For this example, we will use an existing configuration.
Figure 5-52 Disk configuration
8. In the Physical Volumes window (Figure 5-53 on page 314), select a hdiskx available to be
used.
313
Figure 5-53 Adding existing disks
9. After the disk configuration is completed, a summary is shown (Figure 5-54).
Figure 5-54 Disk configuration summary
10.Select the Network interface that will be assigned to the virtual server (Figure 5-55 on
page 315).
314
Figure 5-55 Network configuration
11.Select the additional devices to assign to the virtual server (Figure 5-56).
Figure 5-56 Additional devices configuration
12.Configure Physical Slots to assign to the virtual server (Figure 5-57 on page 316).
315
Figure 5-57 Physical Slots configuration page
13.Once the VM creation wizard is complete, submit the job and check results. After it
finishes, your new VM will be created under your physical server. See Figure 5-58.
Figure 5-58 New VM created
Editing a virtual server

After you use IBM Systems Director VMControl to create or deploy a virtual server, you can
use IBM Systems Director to edit the virtual server. VMControl can be used to edit memory,
processor, virtual or physical I/O slots, virtual or physical disks assigned to the virtual server,
virtual Ethernet adapters, and optical devices. Most attributes can be changed only on a
powered-off virtual server. In a running virtual server, only memory and processor allocation
can be changed.
A running virtual server allows the changes to be either applied to the current running
operating system and saved to the LPAR profile in the HMC. Or, it can be only saved to the
LPAR profile in the HMC when it is activated after the next LPAR power cycle
(shutdown/activate). Below are the steps to edit host resources:
1. In the IBM Systems Director navigation area, click Resource Explorer to locate the host
that you want to edit.
2. On the Chassis Manager page, click Resource Explorer under General Actions.
3. Select the host, click Actions from the menu bar, and select System Configuration
Edit Virtual Server. The Edit Host Resources window opens.
316
4. After completing the changes you want to request, click OK.

5. In the scheduler window, click OK to run the task immediately. You also can schedule to
run this task later.
Deleting a virtual server

Removing a virtual server causes the LPAR to be removed permanently. To permanently
remove a virtual server, it needs to be powered off first and then removed.
Complete the following steps to delete a virtual server from its associated host:
1. In the IBM Systems Director navigation pane, click Resource Explorer to locate the
virtual server.
2. Select the virtual server and click Actions Permanently Delete Virtual Server from
the menu bar, as shown in Figure 5-59.
Figure 5-59 Permanently Delete Virtual Server task
3. In the scheduler window, click OK to run the task immediately. You also can schedule to
run this task later.
Relocation
IBM Systems Director VMControl allows you, depending on the virtualization environment
that you have and on the plug-ins you choose to install, to use virtual farms to enable either
static relocation or live relocation. With static relocation, if the virtual server is powered on,
the relocation operation powers off the virtual server at the beginning of the relocation
process and powers the virtual server on when the relocation is complete. With live
relocation, if the virtual server is powered on, the relocation occurs without powering the
server off.
317
Server system pools provide live relocation. With server system pools, you can choose from
three options for relocation:
You can manually relocate virtual servers at any time.
You can activate a resilience policy on your workload to relocate virtual servers
automatically to prevent predicted hardware failures from affecting the availability of the
workload.
You can create an automation plan to relocate the virtual servers when certain events
occur.
Best Practice: Use the HMC to validate if an LPAR can be relocated.
Relocating virtual servers manually

To relocate a server, a virtual farm must be created. Perform the following steps:
1. Go to VMControl Virtual Servers/Hosts view, and click Create virtual farm. See
Figure 5-60.
Figure 5-60 VMControl: Virtual Servers/Hosts tab
Note: To delete an existing virtual farm, first remove all the associated hosts.
2. Complete the Virtual Farm wizard. Ensure that you have enabled Live relocation, as
Figure 5-61 Virtual Farm wizard: Capabilities configuration
3. Select Initial Host, then Additional Hosts (Figure 5-62 on page 319).
318
Figure 5-62 Virtual Farm wizard summary
4. After the virtual farm is created, relocation is available. Go to the Virtual Server and Host
view and right-click a virtual server. Click Availability Relocate as shown in
Figure 5-63.
Figure 5-63 Relocate a virtual server
5. Complete the wizard steps. Review the summary (Figure 5-64 on page 320) and click
Finish.
319
Figure 5-64 Relocation wizard summary
6. The relocation process starts, as shown in Figure 5-65.
Figure 5-65 Relocating a virtual server
320
7. Finally, the selected virtual server was relocated to the target host. See Figure 5-66.
Figure 5-66 Virtual Servers and Hosts view
Relocating automatically a virtual server that is based on events

IBM Systems Director VMControl Express Edition allows you to create an automated plan to
relocate automatically a virtual server that is based on an event, for example when a
Predictive Failure event is triggered. Follow the steps below to create an automation plan that
can manage automatic relocation that is based on events.
1. Ensure that a virtual farm is created. This virtual farm must contain the source host and
the destination host where the virtual server will be moved.
2. Create a custom task using the command-line interface. Use the mkrelocatetask
command to create it on your IBM Systems Director server:
smcli mkrelocatetask [-v] {-d destination} {-s source} [-A attribute_list]
task_name
Example: Move LPAR: ip10-32-42-86 to pfm9253_9117_MMA
smcli mkrelocatetask -d pfm9253_9117_MMA -s ip10-32-42-86 -A Policy=Live -A
RunMode=Save Relocate_VS
For more information about this command, see the following site:
ctor.vim.helps.doc%2Ffqm0_r_cli_mkrelocatetask.html
321
3. Create your event filter to customize what events will trigger the relocation task.
Figure 5-67 shows an example.
Figure 5-67 Customized event filter
Best Practice: After creating an Event action, configure it to save history.

4. Create an automation plan that uses the event filter and the relocation task that were
created previously. See an example in Figure 5-68 on page 323.
322
Figure 5-68 New event automation plan
5. The automation plan is ready. For testing purposes, an event can be generated manually
by running the genevent command from the command line:
smcli genevent /text:"Hard drive PFA event" /compcat:"Managed Resource.Managed
System Resource.Logical Resource.Logical Device.Media Access D
ice" /comptype:"Disk Drive" /mode:ALERT /sev:0 /MEID:37388
6. Check the event on the Event Log view. See Figure 5-69.
Figure 5-69 Event Log filter
323
7. After the event is received, the relocating task is triggered automatically. From the Event
Actions view, check if the relocation task was launched, as shown in Figure 5-70.
Figure 5-70 Event Actions history
8. The status of the virtual server changes to Relocating. See Figure 5-71.
Figure 5-71 Relocation process started automatically
324
9. Finally, the virtual server has been relocated, as shown in Figure 5-72.
Figure 5-72 The virtual server has been relocated to the target host
For more information about relocating virtual servers, see the following site:
r.vim.helps.doc%2Ffsd0_vim_t_relocating_vs.html
5.7.7 Managing a virtual appliance with VMControl Standard Edition

There are two ways to manage virtual appliances in AIX: NIM image repositories, and VIOS
image repositories. You can set up your AIX environment with either type or with both types.
Creating and discovering NIM image repositories for AIX

Before working with virtual appliances that contain AIX mksysb and lpp_source images, you
must ensure that the NIM repository has been properly configured and the NIM subagent
installed.
Verify that the following prerequisites are met:
Ensure that the NIM OS has been discovered, accessed, and inventoried by your IBM
Systems Director server, and ensure that the IBM Systems Director 6.3 Common Agent
has been installed.
Ensure that the NIM server name is resolved.
325
Execute the following steps to discover your virtual appliances:

1. From the VMControl summary view, go to the Basics page and click Discover virtual
appliances (Figure 5-73) to discover your repositories and virtual appliances.
Virtual appliances already present in your repositories that have been imported or
captured using VMControl are detected by VMControl. Additional virtual appliances can
be added to your repositories by using the Capture and Import tasks in VMControl. See
Figure 5-73.
Figure 5-73 VMControl Basics page
2. Select the NIM server and run the job (Figure 5-74).
Figure 5-74 Discover virtual appliances
326
3. After the job is completed, go back to the Basics page. The virtual appliance that was
discovered is displayed under the Resources box, as shown in Figure 5-75.
Figure 5-75 VMControl summary page
Creating and discovering VIOS image repositories on Power Systems

Before setting up a VIOS image repository for virtual appliances containing AIX, IBM i, or
Linux on Power Systems raw images, ensure that all prerequisites are met:
A SAN storage pool has been configured and the VIOS has access to it.
Ensure that IBM Systems Director Common Agent is started on the VIOS.
Discover and request access to the storage and the operating system of the VIOS
mentioned.
To create an image repository, follow the steps below:
1. From the VMControl summary page, go to the Virtual Appliances tab and click Create
image repository (Figure 5-76).
Figure 5-76 IBM Systems Director VMControl: Virtual Appliances tab
327
2. Follow the instructions in the Create Image Repository wizard (Figure 5-77). Only systems
that satisfy the requirement for hosting an image repository will be available to select.
Figure 5-77 Select your VIOS
3. Select the storage to use for the image repository (Figure 5-78). Take note that this
storage was previously discovered and the inventory was collected.
Figure 5-78 Storage selection for VIOS image repository
328
4. Review the summary as shown in Figure 5-79.
Figure 5-79 New VIOS image repository summary
5. IBM Systems Director automatically discovers the image repository after it is created. See
Figure 5-80.
Figure 5-80 New VIOS image repository created
6. On the Virtual Appliances page, click the Image Repositories view (Figure 5-81).
Figure 5-81 Image Repositories view
You can add virtual appliances to your repositories by using the Capture and Import tasks in
VMControl. The metadata that is associated with the virtual appliance is stored in the image
repository, and the image is stored in the storage pool.
5.7.8 Managing server system pools with VMControl Enterprise Edition

As previously explained, IBM Systems Director VMControl Enterprise Edition can work with
server systems pools. A server system pool allows you to group similar hosts and define
329
specialized capabilities for the virtual servers running on the hosts. A server system pool has
potential for capabilities such as live relocation, static relocation, and automated network
relocation with network system pools (NSPs), if the hosts are enabled for these features.
Creation of storage system pools

A server system pool cannot be created without specifying the storage. In addition, hosts that
are not connected to the same shared storage as the server system pool cannot be added to
the pool. You can configure your SAN Storage Provider to be used with IBM Systems Director
VMControl Power Systems server system pools.
To create a storage system pool, perform the following steps:
1. Go to IBM Systems Director VMControl and click the System Pools page. Then, select
the Storage system pools view, and click Create. See Figure 5-82.
Figure 5-82 VMControl: System Pools view
2. Complete the wizard steps. Enter the storage system pool name. Then, select the storage
subsystem that will be used (Figure 5-83 on page 331).
Note: When selecting multiple storages, they must be in the same zone.
330
Figure 5-83 Create storage system pools
3. After the wizard is complete, the new storage system pool is listed, as shown in Figure 5-84.
Figure 5-84 VMControl: Storage system pools view
331
Creation of server system pools

After creating the storage system pool, a server system pool can be created. To create a
server system pool, do the following steps:
1. On the VMControl System Pools page, select the Server system pools view and click
Create (Figure 5-85).
Figure 5-85 VMControl: Server system pools view
2. Complete the name and the description. In the Pooling Criteria window (Figure 5-86),
ensure that the check box Only add hosts capable of live virtual server relocation is
checked to be sure that you will be grouping servers with relocation capabilities. If a
network system pool was previously configured, the Network deployment criteria check
box will be enabled to configure.
Figure 5-86 VMControl: Server system pools pooling criteria
332
Tip: The existing virtual servers on the host that are resilient capable can be grouped
as a workload to bring them under server system pool management.
3. Select your Initial Host (Figure 5-87). This host is used to find similar hosts that support
the required capabilities for this server system pool.
Figure 5-87 VMControl: Server system pools Initial Host configuration
4. Configure the Shared Storage (Figure 5-88). In the available shared storage, the storage
system pool previously created will be available to be selected.
Figure 5-88 VMControl: Server system pools Shared Storage configuration
5. Add additional hosts to your server system pool. Remember that only the ones that are
compatible with your initial selected host will be displayed (Figure 5-89).
Figure 5-89 VMControl: Add hosts to the server system pool
333
6. Configure the optimization settings (Figure 5-90); manual or automatic optimization can be
configured. Optimization enables the analysis and periodic performance improvement of
all virtual servers within your server system pool.
Figure 5-90 VMControl: Server system pool optimization settings
For more information about server system pool optimization, see the following site:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.vim.help
s.doc/fsd0_vim_c_learnmore_system_pool_optimization_settings.html
7. When the wizard is completed, the new server system pool is listed in the Server system
pools view, as shown in Figure 5-91.
Figure 5-91 VMControl: Server system pools view
Managing workloads in a server system pool environment

A workload is a deployed virtual appliance that allows you to monitor and manage one or
more virtual servers as a single entity. With IBM Systems Director VMControl Standard
Edition, you can capture, import, and deploy virtual appliances. Workloads are created by
deploying virtual appliances or by grouping existing virtual servers as a workload. The first
step in managing virtual appliances and workloads is creating an image repository.
334
Capture a virtual appliance using NIM

By capturing a virtual appliance, the operations result in a virtual appliance that you can
deploy to create a new virtual server. There are three types of sources that can be captured:
A virtual server (LPAR) or a workload
An existing mksysb image file
An existing NIM mksysb resource, lpp_source directory, or lpp_source resource on your
NIM master
Before capturing virtual appliances, check the requirements listed in the information center:
r.vim.helps.doc%2Ffsd0_vim_r_power_capture_reqs.html
To capture a running virtual server using NIM, execute the following steps:
1. Go to the VMControl Virtual Appliances page and click Capture (Figure 5-92).
Figure 5-92 VMControl: Virtual Appliances page
335
2. Enter the name, description, and search tags for the new virtual appliance, as shown in
Figure 5-93.
Figure 5-93 VMControl: Capture a virtual appliance
3. Select the source. In this case, select Virtual Server (Figure 5-94).
Figure 5-94 VMControl: Virtual appliance source configuration
4. Select the source Virtual Server that will be captured (Figure 5-95 on page 337).
336
Figure 5-95 VMControl: Virtual appliance Source Virtual Server selection
Note: The operating system on the virtual server that you want to capture must be
discovered, accessed, and inventoried with IBM Systems Director.
5. Select the repository to be used. In this step, decide whether to use NIM or SCS. In this
case, select your NIM server (Figure 5-96).
Figure 5-96 VMControl: Virtual appliance Repository configuration
337
6. Figure 5-97 shows the Network Mapping configuration. Specify a description to use for
each virtual network.
Figure 5-97 VMControl: Virtual appliance Network Mapping configuration
7. Select the version information for Version Control (Figure 5-98 on page 339). During any
tasks that involve virtual appliances (for example, capture, deploy, import), IBM Systems
Director VMControl automatically generates, maintains, and manages version information
for the virtual appliances.
For more information about virtual appliance versions, see the following site:
ctor.vim.helps.doc%2Ffsd0_vim_r_revisions.html
338
Figure 5-98 VMControl: Virtual Appliance version control configuration
8. Submit the job and check the results. See the example in Figure 5-99.
Figure 5-99 Capturing virtual appliance job logs
339
Capture a virtual appliance using Storage Copy Services

You can create a virtual appliance by capturing any of the following sources:
An IBM Power Systems virtual server (logical partition) or workload that contains a virtual
server that is running AIX 5.3 or newer.
server that is running IBM i v7.1 TR3 or newer.
server that is running SUSE Linux Enterprise Server (SLES) 10 SP3 or newer, or Red Hat
Enterprise Linux (RHEL) 5.4 or newer.
Note: When capturing a virtual appliance using SCS, the virtual server must be powered
off.
Check the requirements for capturing a virtual appliance using SCS by referring to the
information center at the following link:
oc/fsd0_vim_r_sb_aix_on_power_capture_reqs.html
Follow the same steps that are explained in the section, Capture a virtual appliance using
NIM on page 335, to capture a virtual appliance using SCS.
Deploy a virtual appliance using workloads

When you create your image repositories and capture a virtual appliance, you can start
working with virtual appliances and workloads in your environment.
1. Go to the VMControl Workloads page and click Deploy virtual appliance (Figure 5-100).
Figure 5-100 VMControl Workloads page
2. Select the virtual appliance that you want to deploy (Figure 5-101 on page 341).
340
Figure 5-101 VMControl Workloads: Deploy virtual appliance page
3. Select your server system pool (Figure 5-102) where you are planning to deploy your
virtual appliance. You can also override an existing virtual server.
Figure 5-102 VMControl Workloads: Virtual appliance target

341
4. Specify the setting for the virtual disks as shown in Figure 5-103.
Figure 5-103 VMControl Workloads: Virtual appliance disk configuration
5. Enter the name of your new workload as shown in Figure 5-104.
Figure 5-104 VMControl workloads: Workload Name page
6. Figure 5-105 shows the Network Mapping configuration. Select a virtual network for each
network that is defined for the appliance.
Figure 5-105 VMControl workloads: Networking Mapping configuration
342
7. Configure the new virtual server. Enter the new server name, the DNS domain name, the
DNS IP, and the default gateway IP. Also, enter the new IP address and the network mask,
Figure 5-106 VMControl workloads: Virtual server configuration
8. Submit the job and check the log. See the example in Figure 5-107.
Figure 5-107 Deploy virtual appliance job log
343
9. You can check the progress by opening the terminal from the HMC, as shown in
Figure 5-108.
Open in progress
Open Completed.
58
17
68% of mksysb data restored.
Figure 5-108 AIX terminal window
10.To run the initial configuration (Name and Network settings), VMControl creates a virtual
optical device (client SCSI) to save all the configuration on this device. This initial
configuration is applied during the first system startup. After one hour, this device is
automatically deleted. You can check this device on the HMC. See the example in
Figure 5-109.
Figure 5-109 HMC: Virtual server properties
5.7.9 Best practices

Listed in this section are the best practices for IBM Systems Director VMControl:
Before you start working with VMControl, ensure that your PowerVM environment is ready.
Before relocating a server, validate from the HMC if that server is able to be relocated.
When creating virtual farms, ensure that you check live relocation to leverage this
functionality.
When creating a server systems pool, select only the hosts that are capable of live virtual
server relocation.
If you are planning to use SCS to capture a virtual appliance, keep in mind that the source
must be powered off.
344
Chapter 6.
Active Energy Manager

This chapter describes the energy monitoring and management features that are offered by
IBM Systems Director Active Energy Manager along with the best practice, which needs to be
followed when using the IBM Systems Director Active Energy Manager.
6.1, Active Energy Manager on page 346

6.2, Requirements for installing AEM on page 347
6.3, Learn how to start using Active Energy Manager on page 349
6.4, Monitoring features that are available on page 356
6.5, Management features that are available on page 364
6.6, Active Energy Manager: smcli references on page 370
345
6.1 Active Energy Manager

In this section, we briefly introduce the Active Energy Manager (AEM) plug-in for IBM
Systems Director along with supported energy monitoring and management features.
The bulk of this chapter focuses on the best practices and the most important questions to
ask before using AEM. We also show how you can manage and monitor the energy usage by
using the AEM graphical interface and the command-line interface (CLI).
6.1.1 Terms to know

Before starting to read about IBM Systems Director energy management, it is important that
you familiarize yourself with some of the widely used AEM-specific terminologies:
Managed system
A system that is being controlled by a given system management application, for example,
a system managed by IBM Systems Director.
Metering device
A resource, such as a power distribution unit (PDU) or sensor that measures things such
as power use and thermal values of other objects.
Metered device
A resource, such as a server, that is associated with a metering device.
Metering interval
The interval, in minutes, that resources are polled for energy information.
Input power
The ac (alternating current) power that is supplied to the server power supply from the
external sources such as PDUs.
Output power
The dc (direct current) power that is consumed by the components inside the server.
6.1.2 Introduction to Active Energy Manager

Active Energy Manager (AEM) is an advanced plug-in to IBM Systems Director that helps
users to monitor the power usage of their IT equipment and facility equipment, as well as
manage the power usage of the supported managed resources.
Supported energy-related tasks that you can perform using Active Energy Manager, include:
Monitoring and trending power consumption as well as thermal data
Managing power, which includes:
Setting power savings options
Setting power caps
Creating and setting power policies
Monitoring uninterruptible power supply (UPS) units for current status and battery state,
and notify associated resources if there are any changes
Configuring metering devices, such as PDUs and sensors
Exporting the collected power and thermal trend data
346
Viewing events that are related to energy management

Calculating energy cost
Calculating estimated energy savings for selected IBM Power Systems servers
Setting thresholds on power and thermal monitors
Monitoring of power and cooling equipment that affect the IT resources
IBM Systems Director Active Energy Manager also integrates with the IBM Tivoli Monitoring
for Energy Management Agent to provide you with the capability to monitor Active Energy
Manager devices from IBM Tivoli Enterprise Portal workspace.
6.1.3 AEM features: No-charge versus charged

The IBM Systems Director Active Energy Manager plug-in offers a few no-charge features
and chargeable features. Table 6-1 gives information about what features are available at no
charge versus charged.
Table 6-1 No charge-based versus fee-based Active Energy Manager features
Active Energy Manager feature
Is the feature available at no charge?
Monitoring power consumption of IBM servers
Yes
Monitoring inlet and outlet temperatures of IBM

servers
Monitoring power consumption of non-IBM
servers and traditional IBM servers using
metering devices such as intelligent power
distribution units (iPDUs)
Facility equipment monitoring
Configuring metering and cooling devices
Energy-related event monitoring
Creating custom monitors and thresholds on
energy parameters
Setting power caps and power savings
No
Applying power policies

Check UPS status and notify associated IBM
Power Systems servers
6.2 Requirements for installing AEM

Starting with version 4.4, the Active Energy Manager full edition with a 90-day evaluation
period for power management features is installed along with the installation of IBM Systems
Director server.
However, AEM is in a deactivated state by default. You should activate Active Energy
Manager before the AEM features can be used. The evaluation period begins after you
activate Active Energy Manager.
Chapter 6. Active Energy Manager
347
Note: The 90-day evaluation period begins to count down after activating AEM for the first
time. It continues to run even if you deactivate Active Energy Manager thereafter.
Perform the following steps to activate Active Energy Manager:
1. Activate the Active Energy Manager plug-in by using either of the following two methods:
Activate by using the IBM Systems Director web interface
i. Log in to the IBM Systems Director server, go to the home page, and click the
Plug-ins tab.
ii. In the Additional Plug-ins to activate section, click Activate now under the Active
Energy Manager heading.
From the IBM Systems Director server command-line prompt, run the following
command:
smcli activatemgrs "Active Energy Manager"
2. After the activation has completed, restart the IBM Systems Director server by running the
following commands, and monitor the status:
smstop;smstart;smstatus -r
When the IBM Systems Director server status is Active, run the following command to
ensure that IBM Systems Director Active Energy Manager is activated:
smcli lsmgrs
On the IBM Systems Director web console, go to the Home Plug-ins page where
you see that the Active Energy Manager is activated with the evaluation period, as
Figure 6-1 Active Energy Manager plug-in activated
Visit the following information center link to understand more about the performance and
scalability considerations for AEM:
r.aem.helps.doc%2Ffrb0_t_performance_considerations.html
6.2.1 Learn which devices are supported for monitoring

IBM Systems Director Active Energy Manager can monitor the power usage as well as
receive power and cooling-related events on data center equipment:
IT equipment, includes
Servers
Network
Storage
Facility equipment, includes
IBM power distribution units (PDU+).
Non IBM facility equipment such as UPSs, PDUs, and computer room air conditioners,
on which are supplied by various facility equipment vendors.
348
In addition to doing power monitoring, AEM allows you to create logical relationships between
the facility equipment such as cooling units, UPSs, PDUs, and the IT servers, which allow the
event flow from the facility equipment to the associated IT servers. For more information and
directions, see section 6.4.5, Configuring metering and cooling devices on page 363.
For more information about supported firmware and software version requirements, see the
Supported hardware information center at the following link:
r.aem.helps.doc%2Ffrb0_r_supported_hardware.html
6.2.2 Learn which devices are supported for power management

IBM Systems Director AEM can be used to perform power management such as power
saving and power capping on the following servers:
IBM System x
IBM BladeCenter
IBM Power Systems
IBM System z
Not all of the supported servers have power save and power cap capabilities. See section 6.5,
Management features that are available on page 364 to get more information about the
management features.
AEM can be used to turn on, off, or reboot individual power outlets on the following supported
PDUs:
Eaton PowerWare Switched PDUs

Raritan Dominion PX PDUs
APC Switched Rack PDUs
Server Tech Switched or POPS PDUs
Some R-Series Geist PDUs
For more information about supported firmware and software version requirements, see the
information center:
r.aem.helps.doc%2Ffrb0_r_supported_hardware.html
6.3 Learn how to start using Active Energy Manager

The IBM Systems Director AEM communicates to the service processor or the platform
managers to retrieve and manage the power and thermal usage. Figure 6-2 on page 350
shows the components with which AEM communicates to retrieve the required data and
perform power management.
349
Active Energ y Manager
P DU+
zHMC
Syst em z
HMC
IV M
BMC/RSA
IM M
IBM
Syst em x
servers
IB M Power
Servers
AMM
IBM
Bl adeCenters
PDU and UP S
S ensors
Facility S of tware
Non-I BM Servers, legacy IBM Servers and other datacent er equipment
Managed objects
Figure 6-2 IBM Systems Director Active Energy Manager management domain
Note: AEM does not need any agents to be installed on the resources that it needs to
power monitor and power manage.
For AEM to start the power monitoring and management on supported endpoints, the
endpoints must be first discovered and unlocked in the IBM Systems Director server.
Table 6-2 shows the endpoint types that need to be discovered and the discovery method to
enable for energy monitoring and management.
Table 6-2 AEM endpoint types and methods of discovery
350
Managed resource
type
Managed by
Resource type to
select while
discovering
Discovery method
[Basic/Advanced]
Power distribution
units (PDUs) or
uninterruptible power
supplies (UPSs)
PDU/UPS itself
Power unit
Either
IBM Power Systems
HMC/IVM/FSP
Server
IBM System x servers
IMM/BMC/RSA II
Server
IBM BladeCenter
chassis and its
components
AMM/MM
IBM BladeCenter
chassis
Managed resource
type
Managed by
Resource type to
select while
discovering
Discovery method
[Basic/Advanced]
IBM System z servers

and IBM System z with
BladeCenter
Extensions
zHMC
Server
Advanced
Sensor devices
SynapSense SNMP
agent
Generic system
Sensatronics,
1-Wire
iButtonLink
Arch Rock sensor
networks
Rittal sensors and

power units
Facility Software
Emerson-Liebert
SiteScan instance
Eaton Power Xpert
Reporting
Database server
APC InfraStruXure
Central server
Operating system
Either
Power unit
Operating system
The following devices can also be power monitored by AEM if they are connected to any of
the supported PDU devices:
Storage devices
Switch devices
Non IBM hardware
Legacy IBM hardware
Other data center equipment
As of AEM version 4.4.2, energy monitoring and management of IBM Flex nodes are not
supported.
For more information about discovering managed resources for energy monitoring and
management, see the following site:
r.aem.helps.doc%2Ffrb0_t_adding_managed_objects.html
IBM Systems Director Active Energy Manager communicates to the managed endpoints
during the polling interval, which is set to default values initially, to get the energy-related
values. Table 6-3 on page 352 has the default polling intervals for the managed device types.
351
Table 6-3 Polling intervals

Managed resource type
Metering interval
supported by the
managed resource
AEM default global polling

interval
PDUs or UPSs
N/A
5 minutes
IBM Power Systems
N/A
5 minutes
IBM System x servers
30 seconds (IMMv2)
5 minutes
IBM BladeCenter chassis and its components
10 minutes
10 minutes
SynapSense sensors
5 minutes
5 minutes
Sensatronics
N/A
5 minutes
1-Wire
N/A
5 minutes
iButtonLink
N/A
5 minutes
Arch Rock sensor networks
N/A
5 minutes
Rittal sensors and power units
N/A
5 minutes
Eaton Power Xpert Reporting Database server
60 minutes
15 minutes
Emerson-Liebert SiteScan instance
N/A
5 minutes
APC InfraStruXure Central server
N/A*
5 minutes
Best practice: It is recommended not to set the AEM polling interval to a lesser value than
the polling interval supported by the managed resource.
6.3.1 Accessing Active Energy Manager resources

In IBM Systems Director server, there are two ways to access managed resources, which
also apply to AEM:
Steps to access managed resources using the resource explorer are as follows:
a. On the IBM Systems Director web console, go to Resource Explorer where you see
the default groups and any custom created groups. When you activate AEM, the Active
Energy Manager Groups group gets added to the Resource Explorer page, as shown
in Figure 6-3.
Figure 6-3 Resource Explorer page
352
b. Click the Active Energy Manager Groups group. Four default subgroups are
displayed, as shown in Figure 6-4.
Figure 6-4 Active Energy Manager Groups view
The subgroups are defined as follows:
Active Energy Managed Resources: This subgroup contains the managed

resources that are currently being monitored by AEM.
Candidate Energy Managed Resources: This subgroup contains the managed

resources that require a firmware upgrade or association with external metering
devices, such has PDUs, to enable AEM to monitor them.
Energy Managed Resources by Type: This subgroup contains the managed

resources by type.
Externally Metered Energy Managed Devices: This subgroup contains metering

devices such as PDUs that are currently being monitored by AEM.
c. Click Active Energy Managed Resources to take you to the page where you can
access all the energy managed resources, as shown in Figure 6-5.
Figure 6-5 All energy managed resources
353
d. Click Energy Managed Resources by Type and the energy managed resources by
type are shown, as in Figure 6-6.
Figure 6-6 Energy managed resources by type
The other way in which managed resources can be accessed is through the plug-ins
summary page. On the IBM Systems Director web console, go to the Home Plug-ins
page and click Active Energy Manager, which takes you to the AEM summary page, as
shown in Figure 6-7 on page 355.
354
Figure 6-7 AEM summary page
Under the Monitor section of the summary page, you find the same AEM groups that
were present on the Resource Explorer page. Go to the managed resources by clicking
the required group.
For more information about the AEM summary page, see the following information center
site:
ctor.aem.helps.doc%2Ffrb0_t_aem_summary_page.html
Further in this chapter, we demonstrate AEM tasks on the managed energy resources by
accessing them using the first method that is listed in section 6.3.1, Accessing Active Energy
Manager resources on page 352.
355
6.4 Monitoring features that are available

After you discovered the managed resources in AEM, the following operations can be
performed that are part of the monitoring feature:
Viewing AEM-managed resources and trend data

Calculating energy cost and energy savings
Viewing energy events and energy properties
Viewing supported monitors and setting thresholds
Configuring metering and cooling devices
Facility Software integration
Automatic notification upon UPS status change
6.4.1 Viewing trend data

Perform the following steps to view managed resources and trend data:
1. Log in to the IBM Systems Director web console and go to Resource Explorer Active
Energy Manager Groups (View Members) Energy Managed Resources by Type
(View Members). You are able to see the types of resources that are supported along with
the number indicating how many of those resources are already discovered by AEM, as
Figure 6-8 AEM resources grouped by type
2. Click any of the displayed resource type groups to see the group members (Figure 6-9)
that show the Energy Managed Power Systems group members.
Figure 6-9 AEM-managed IBM Power Systems server resource group
356
3. To view the collected trend data, right-click the managed resource and select Energy
Trend Data, as highlighted in Figure 6-10.
Figure 6-10 Viewing trend data
357
4. The Trend Data page is displayed as shown in Figure 6-11, where you can see the power
and thermal trend data for the selected AEM-managed resource that is based on the time
range. In this example, we selected an IBM Power 7 processor-based server, which would
also display information about the power management capabilities along with the energy
events reported for the server resource.
Figure 6-11 AEM Trend Data page
358
Power and thermal trend data can also be viewed in table format and can be exported to a
comma-separated values (CSV) file.
Active Energy Manager runs compression on the trend data that is older than seven days to
reduce the amount of storage space occupied. For the collected power and environmental
values older than seven days, each night at midnight, this data is compressed to one-hour
average values.
6.4.2 Calculating energy cost and energy savings

With AEM, you can calculate the cost that is incurred for running a managed resource over a
period of time. To get more accurate cost readings, you need to customize the AEM settings
before calculating the energy cost for any managed resources. Perform the following steps to
configure the energy cost settings:
1. On the IBM Systems Director web console, go to Energy Active Energy Manager. On
the Active Energy Manager summary page, click Settings, as shown Figure 6-12.
Figure 6-12 AEM global settings
359
2. Input the custom values for energy cost per kilowatt hour, cooling rate multiplier, and
currency type in the AEM settings page, which is shown in Figure 6-13.
Figure 6-13 AEM global settings
3. Click OK, which applies the settings. Exit the Settings page.
These settings when saved would be the global settings across the managed resources of
AEM. If you are monitoring resources across the geographical regions under the same AEM
instance, you can also set energy cost per kilowatt hour, the cooling rate multiplier, and
currency type per managed endpoint. The following equation explains how the cost would be
calculated by AEM:
Total cost = (metered power x time x energy price) + (metered power x time x
energy price x cooling rate multiplier)
See the following site to get steps to define cost settings per managed endpoint:
r.aem.helps.doc%2Ffrb0_t_calculating_energy_cost.html
AEM also lets users calculate the energy savings, both future and past, derived due to the
power savings. This feature is currently limited to support these IBM Power Systems servers:
IBM Power 750 (8233-E8B)
IBM Power 755 (8236-H8B)
For other supported servers, this feature shows the percentage of time that the Power
Savings mode was enabled.
For more information about energy savings calculations, see the following site:
r.aem.helps.doc%2Ffrb0_t_calculating_energy_savings.html
360
6.4.3 Viewing energy events and energy properties

When you have the Active Energy Manager plug-in in use, the events that are related to
power and thermal monitoring are logged in to the IBM Systems Director event log. You can
view the events related to AEM per managed system or across the managed systems. On the
IBM Systems Director web console, navigating to System Status and Health Event Log
and filtering the events by the Active Energy Manager events filter enables you to see only
the events reported from AEM, as shown in Figure 6-14.
Figure 6-14 AEM events in the event log of IBM Systems Director server
There are two default event filters created for IBM Systems Director Active Energy Manager,
namely:
Active Energy Critical Events: Displays only those events that are generated by AEM that
have a Critical severity
Active Energy Events: Displays only those events that are generated by AEM
These filters can be used in the event automation plans to carry out any event actions against
the reported events. For more information about event automation plans, refer to Creating an
event automation plan on page 163.
For more information about the type of events that are reported by AEM, see the following
information center site:
r.aem.helps.doc%2Ffrb0_r_events_trend_pane.html
When any devices that are also supported by AEM are discovered in IBM Systems Director,
AEM queries the properties that are related to energy parameters and stores them in the
device properties under the Active Energy section. To access the Active Energy properties
on the IBM Systems Director web console, go to Resource Explorer Groups Active
Energy Manager Groups Active Energy Managed Resources and right-click any
managed endpoint and select Properties Active Energy.
361
As an example, Figure 6-15 shows the Active Energy properties of an IBM Power Systems
server.
Figure 6-15 AEM properties for an IBM Power Systems server
For more information about the energy properties that are supported for each of the AEM
supported managed endpoints, see the following page in the information center:
r.aem.helps.doc%2Ffrb0_t_viewing_aem_properties.html
362
6.4.4 Viewing supported monitors and setting thresholds

Active Energy Manager when activated adds Active Energy monitors to the set of available
monitors under IBM Systems Director server. Following are the two default monitor groups
that are created by AEM:
Active Energy Common Monitors
Active Energy Monitors
You can set thresholds on the AEM monitors to generate event notifications that can then be
filtered to take appropriate actions by using the event automation plan.
6.4.5 Configuring metering and cooling devices

With Active Energy Manager, you can configure metering devices such as PDUs and
sensors, and the cooling devices like CRAC devices to associate them with other related
resources in the data center.
Configuration of metering and cooling devices enables the following features:
Monitoring and managing data (power, temperature, humidity, dew point) for resources
that are associated with the metering device.
Events to be generated for the associated resources whenever a severe event is received
for the metering device.
Viewing the data center power flow by using the Active Energy Power perspective.
Viewing all resources that are cooled by a cooling device and viewing all cooling devices
that cool a resource. This also facilitates the generation of events for cooled resources
when an associated cooling device experiences a severe event.
See the following information center sites to get steps to configure metering and cooling
devices:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.direct
or.aem.helps.doc%2Ffrb0_t_configure_metering_device.html
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.direct
or.aem.helps.doc%2Ffrb0_t_configure_cooling_device.html
6.4.6 Facility Software integration

Active Energy Manager extends the scope of energy monitoring and management by
integrating with various facility endpoints to enable a more complete view of energy
consumption within the data center. Integrating facility managers with IBM Active Energy
Manager enables IT administrators to be alerted about issues with facilities equipment such
as overheating, low battery power-on uninterruptible power supplies, or other conditions that
might keep IT equipment in a data center from running properly.
Currently, AEM can integrate and monitor the facility equipment when you have the supported
Facility Management Software that is installed in your data center as:
APC InfraStruXure Central server at version 5.1 or 6.0
Eaton Power Xpert Reporting versions V1.0 and V2.0
Emerson Liebert SiteScan (SSWEB) Version 3.0 or Version 4.0
363
To get step-by-step procedures on the discovery and monitoring of facility equipment

managed by the Facility Software Managers listed above, see Chapter 10 of the following IBM
Redbooks publication:
6.4.7 Automatic notification upon UPS status change

Active Energy Manager supports metering the current status and battery state of the following
uninterruptible power supply models and notifies associated resources of when the status
changes. This is a licensed feature:
IBM branded tower and rack uninterruptible power supplies
Eaton PowerWare uninterruptible power supplies that utilize a Web/SNMP card
The associated resources include IBM POWER7 models, with firmware level eFW7.4 or
greater, which support taking action upon notification of a change in the status of an
associated uninterruptible power supply. For example, with IBM POWER7 systems in the
case of a utility failure, each of the Power Systems software partitions starts a timer. If the
utility power is not restored before the timer expires, each partition shuts down gracefully.
When all partitions are shut down, the server powers off.
The requirements below should be taken care for sending automatic UPS status change
notifications to the associated IBM Power 7 servers:
The Configure Metering Device feature must be used to create an association between
the uninterruptible power supply and the resource to notify. This can be a direct
association between the uninterruptible power supply and the resource or it can be an
indirect association via a PDU.
The Notify on uninterruptible power supply changes property, for the resource to notify,
must indicate that notification should be sent.
The servers to be notified of the uninterruptible power supply status changes must be
discovered in IBM Systems Director by using a connection to the Flexible Server
Processor (FSP) of the server.
Best practices: When you are working with UPS state notification, consider the following
factors:
For the most timely notification, configure SNMP traps that are generated by the UPS to
be sent to the IBM Systems Director server.
The metering interval for the UPS should be set as short as possible to detect changes
sooner. To change a metering interval, go to the properties of the UPS resource and
edit the Metering interval property value.
6.5 Management features that are available

The following AEM operations are part of the management features:
Enabling and disabling power cap
Enabling and disabling power savings
Work with power policies
364
6.5.1 Working with power cap

In a normal and traditional scenario, the power budget for the data centers are calculated
based on the UL rating or the nameplate power of the equipment that the data center would
host in the future.
In the case of servers, the nameplate power or the UL rating is the amount of power
calculated considering the following factors:
The maximum configuration of that server
All the components, such as CPU, memory, disk, PCI cards, running the highest possible
workload under extreme environmental conditions
Redundancy of the power supply
If the nameplate power is taken as-is for calculating the amount of cooling that is required for
the data center, you end up over-sizing the cooling requirements, which results in energy
wastage as well as higher costs.
Actual power usage of a server will be far below the nameplate power rating. Trending power
usage of a server in Active Energy Manager for a period of time allows you to understand the
trend of power consumption of your servers.
When you understand the power trend, the power capping feature allows you to set a cap on
the power that is allocated for the servers, thereby releasing the extra amount of power that
you had allocated to the servers considering its name plate power value. This can help save
on data center infrastructure costs, and then potentially allow more servers to be put into an
existing infrastructure with the same power budget.
Depending on the existing configuration, the system firmware calculates the power cap range
[minimum input power cap, minimum guaranteed input power cap, and maximum input power
cap] between which the actual power cap can be set. AEM retrieves this range from the
server firmware and lets users activate the power cap on the managed servers.
The power cap feature is supported on the IBM x86, IBM Power Systems, and IBM System z
servers, but not all managed servers support the power cap feature. Refer to section 6.2.2,
Learn which devices are supported for power management on page 349 to determine the
support matrix.
There are two modes in which a power cap can be enforced from AEM, namely:
Hard power cap
This is a guaranteed power cap that is a value that is set between the minimum
guaranteed power cap and maximum input power cap. When this option is selected, if
the server tries to use more power than the power cap value, the processor speed is
throttled to retain the power usage below the power cap. The hard power cap can be set
between the minimum guaranteed power cap and maximum power cap value.
Soft power cap
In many scenarios, it was observed that the typical power consumption by the servers was
below the minimum guaranteed input power cap value. In order to give more flexibility to
users in allocating the power budget, the soft power cap was introduced, which allowed
users to set the power cap value below the minimum guaranteed input power cap. The
soft power cap can be set between the minimum input power cap and the maximum input
power cap. If the servers start to exceed the set soft power cap value, best efforts are
made to hold the power consumption under the soft power cap value that is set by
throttling the processor speed. If other components such as storage devices and memory
365
continue to consume more power, the soft power cap is lifted and the server is allowed to
consume the power that it needs.
To set the power cap on supported managed servers, perform the following steps:
1. On the IBM Systems Director server, go to Resource explorer Active Energy
Manager Groups Active Energy Managed Resources.
2. Right-click any managed system that supports power savings, and select Energy
Manage Power Power Capping. Figure 6-16 shows an example where the power
capping mode can be selected and is then enforced on the selected managed resources
when you click Save.
Figure 6-16 Power cap settings
In Figure 6-16, the power cap values can be read as follows:

Minimum input power cap value: 322W
Minimum guaranteed input power cap value: 1286W
Maximum input power cap value: 1491W
It is important to understand that no power capping or processor speed throttling occurs until
the power consumption of the server is below the power capping value set. It is a best
practice to enable hard power capping unless you have a need for accommodating more
servers within the given power budget that is not met by the [Minimum guaranteed input
power value - Maximum input power value] range.
Active Energy Manager allows the users to set power cap values on individual servers and
also groups of servers.
Note: If hot-swappable components are added to or removed from an IBM System x server
while it is powered on, the minimum input power cap and maximum input cap values that
are displayed by Active Energy Manager will not be updated until the next reboot of the
System x server.
See the following link for steps to enable and disable the power cap on managed resources:
r.aem.helps.doc%2Ffrb0_t_power_cap.html
366
6.5.2 Working with power save

Running a server with full capacity, such as processor and memory at 100% nominal
frequency all the time independent of the workload utilization, results in an inefficient usage of
the power.
Currently, the major component that can be power controlled within a server is the processor
and it is said to be one of the major power consumers inside a server. Running a processor at
a fixed frequency all the time independent of how many of the processor cycles are really
being utilized to run the business workload, results in inefficient power usage.
The power save feature of AEM allows you to use either of the following modes:
Static Power Save (SPS): Put the servers into low-power mode when the workload
utilization is less. In this mode, the jobs executed on the processor can take more time to
complete compared to executing the job on the processor running at nominal frequency.
Dynamic Power Save (DPS): Put the servers into a mode where processor frequency gets
varied dynamically depending on the workload utilization. This mode has two submodes,
namely:
DPS favor performance: Where the performance is not reduced at any time, but at the
same time, attempts to save the power are done whenever possible.
DPS favor power savings: Where the processor frequency gets reduced by a
predetermined value from its nominal frequency, depending on the model of the server,
to get constant power savings all the time. Within the remaining processor frequency
range, depending on the workload utilization, additional power savings can be
achieved.
The power save feature is supported on IBM Power Systems and IBM System z servers, but
not all of these servers support all power save modes. Refer to section 6.2.2, Learn which
devices are supported for power management on page 349 to determine the support matrix.
The power save feature does not apply to System x servers because power savings on
System x are provided by DBS on Intel and PowerNow on AMD, which is controlled by the
BIOS and controlled thereafter by the operating system.
On IBM Power Systems, AEM can be used to enable and disable the power save mode on
the following components:
Entire Power Systems server
Physical system processor pool
Individual partitions
IBM Power Systems servers, certain Power 7 processor-based servers, support enabling and
disabling the power save option per logical partition (LPAR) and physical system processor
pool. Following are the minimum requirements for performing power savings at the logical
partition level and system processor pool level:
IBM Power Systems server should support partition level and processor pool power
savings.
IBM Systems Director VMControl express edition, at the minimum, should be in activated
state.
Inventory should be collected on the platform managers, such as Hardware Management
Console (HMC), and the physical Power servers.
367
Limitations: As of AEM version 4.4.2:

AEM shows set power save modes on the LPAR, but not the mode actually in effect.
The actual mode in effect can depend on the following states:
Host power save state
System processor pool power save state
Power policies do not support partition-level power save option.
Power monitoring is not supported per logical partition.
Following are the states of power save in which a managed resource can be put in to at any
time:
No power savings: No power savings. The processor runs at high speed.
Static power savings: Reduces power usage by lowering processor speed.
Inherit host setting: In this state, the managed resource uses the same power savings as
that of the resource that hosts it. For example, when you put a partition or virtual server
into this state, it inherits the power save state from the Power Host server on which it is
residing.
Dynamic power savings: Automatically balances power usage and processor
performance:
Favor power
or
Favor performance
Component Level Control: Enables the power savings mode of component resources to
be set individually. This state is currently available only on the IBM System z server
BladeCenter extension.
To access and enable or disable the power savings options that are available for a supported
managed system, perform the following steps:
1. On the IBM Systems Director server, go to Resource explorer Active Energy
Manager Groups Active Energy Managed Resources.
2. Right-click any managed system that supports power savings, and select Energy
Manage Power Power Savings. Figure 6-17 shows an example of a list of options to
choose the power savings mode that you need, where you can enforce on the selected
managed resources that are displayed.
Figure 6-17 Power save settings
368
3. You can choose the right power savings mode dependent on the workload utilization on
that managed system and click Save.
Note: Although the power save enable/disable operation completes immediately after you
click Save, the state is not reflected in Active Energy Manager until the next polling
interval.
To get more information about the latest IBM EnergyScale features and power saving
modes that are supported on IBM Power 7 processor-based servers, see the following link:
ftp://public.dhe.ibm.com/common/ssi/ecm/en/pow03039usen/POW03039USEN.PDF
6.5.3 Working with power policies

The power management settings are set using steps that are provided in section 6.5.1,
Working with power cap on page 365 and 6.5.2, Working with power save on page 367.
The settings will not be monitored always by AEM, which means that AEM enforces the power
management settings once and will not guarantee those settings over a period of time. It can
be modified by other users.
Power policies provide a way to continuously monitor and manage the power settings on a
managed system or a group of systems. When you have power policies that are applied on
managed systems, at every polling interval, AEM checks if the power settings applied by the
policy hold good or not. If not, AEM re-enforces the power settings present in the policy on the
managed servers/group.
Some resource types like IBM zEnterprise 196 and zEnterprise BladeCenter Extension
support setting a power cap and the power savings mode, but a policy cannot be used to hold
the resource in that state.
Two types of power policies exist, namely:
System policy
This policy can be either a power save or a power cap setting that can be applied to
individual servers or a group of managed servers. When you apply this policy to group of
managed servers, the policy is applied individually to each server in that group.
Group policy
This policy applies only to a power cap setting, which can be applied only on a managed
systems group.
If a policy is in effect at the time the Active Energy Manager license expires, the policy is
deactivated and the power management function is deactivated from the system. When you
install the Active Energy Manager license, the power savings and power capping functions
become active again and the existing power values are used.
369
Best practices: When applying policies, consider the following factors:

Do not set system power capping or system power savings policies on both a slot and
on the blade in that slot.
Do not set group capping policies on two groups, where one group contains a slot and
the other group contains a blade in that slot.
Ensure that the resource against which you are applying power cap policy supports the
same power cap type (ac or dc).
To determine if a server supports input or output power capping, view the properties of
the server and select the Active Energy tab.
You can use the IBM Systems Director schedule job feature to schedule policy
application and de-application as wanted.
You can apply policy as an event action in response to an event using event automation
plans.
To get step-by-step details about creating, deleting, and editing power policies, see the
following information center link:
r.aem.helps.doc%2Ffrb0_t_work_with_power_policies.html
6.6 Active Energy Manager: smcli references

This section describes the smcli commands for most commonly used energy monitoring and
management scenarios:
List the power and thermal trend data
Syntax:
smcli lstrenddata [-v] [-d delimiter] [-t objectType] [-r timeinterval] [-o
option] {-a |-f file |-N group_list | -n object_list}
Example:
Retrieving the past hour power and thermal trend data:
smcli lstrenddata -n "p740"
Where: p740 is the display name of the power system
Retrieving power and thermal trend data from the specified date:
smcli lstrenddata -n p740 -r "5/6/13"
Where:
p740 is the display name of the power system
5/6/13 is the start date for AEM to retrieve the power and thermal data
Start and stop metering and list all devices that are currently being metered
Syntax:
smcli startcollect -n <display name of the resource>
smcli stopollect -n <display name of the resource>
smcli lscollect -a | -n <display name of the resource>
370
Example:
Enable metering for one of the AEM managed resources:
smcli startcollect -n "p740"
Where: p740 is the display name of the power system
Displaying metering status and interval for all of the AEM managed resource:
smcli lscollect -a
Enabling and disabling the power cap setting on AEM managed resource
Syntax:
smcli setpcap -p pcap_value [-v] [-d delimiter] [-t objectType] {-f file | -N
group_list | -n object_list}
Example:
Setting power cap for one of the AEM managed resource:
smcli setpcap -n "p740" -p 645 -T AC
Where:
645 is the power cap value
AC is the type of power cap
Disabling the power cap on one of the AEM managed resource:

smcli setpowercap -n "p740" -p -1
Where:
-1 used for disabling power cap feature
Enabling and disabling power save setting on AEM managed resource

Syntax:
smcli setpsaver -p psaver [-v] [-d delimiter] [-t objectType] {-f file | -N
group_list | -n object_list}
Example:
Setting static power save for one of the AEM managed resource:
smcli setpsaver -n "p740" -p static
Where:
static is the power save type
Setting dynamic power save favor performance for one of the AEM managed resources:
smcli setpsaver -n "p740" -p dynamic,favorperformance=1
Where:
dynamic,favorperformance=1 is the power save type
Disabling power save on one of the AEM managed resource:

smcli setpowercap -n "p740" -p 0
Where:
0 used for disabling power save feature

371
Create, edit, and delete power policies

Syntax:
smcli chpolicy [-v] [-d delimiter] [-r] [-p policy_target]
Example:
Creating power policy for group capping:
smcli chpolicy -p
Groupcappolicy,policytype=group,pcap=200,powertype=output
Where:
Groupcappolicy is the name provided for the new power policy
group is the power policy type; other types include saving and capping
200 is the power cap value to be used
output is the power cap type, which is dc; other type is input, which is ac
Creating power policy for power saving favoring performance:
smcli chpolicy -p
powersavepolicy,policytype=saving,psavertype=dynamic,favorperformance=on
Where:
powersavepolicy is the name provided for the new power policy
saving is the power policy type; other types include group and capping
dynamic is the power save type, which has favorperformance turned on; other
types include off and static
To update/edit a power policy to change the power cap value:

smcli chpolicy -p Groupcappolicy,pcap=350
Where:
Groupcappolicy is the name of the power policy
350 would be the new power cap value
To remove a policy:
smcli chpolicy -r -p Groupcappolicy
Where: Groupcappolicy is the name of the power policy
Applying power policies to managed AEM resources
Syntax:
smcli setpolicy [-v] [-d delimiter] [-t objectType] [-r] [-p policy_target] {-f
file | -N group_list | -n object_list}
Example:
Set power policy on a AEM managed resource:
smcli setpolicy -p "powersavepolicy" -n "p750"
Where:
372
powersavepolicy is the name of the power policy
p750 is the display name of the AEM managed resource
To remove the power policy from the AEM managed resource:

smcli setpolicy -p "powersavepolicy" -r -n "p750"
Where:
powersavepolicy is the name of the power policy
p750 is the display name of the AEM managed resource
See the following link to get all the commands supported by Active Energy Manager:
r.aem.helps.doc%2Ffrb0_r_ref_commands.html
6.7 Best practices

The following list provides best practices to be followed when using AEM:
Before activating AEM, plan for the list of things that you need to try and evaluate. The
90-day AEM evaluation period begins to count down after activating AEM for the first time
and it continues to run even if you deactivate Active Energy Manager later.
Plan for power monitoring on IBM Power Systems servers:
If you need to monitor I/O drawer power and use a licensed feature of AEM to receive
alerts from UPS, discover the FSP of the IBM Power Systems servers in IBM Systems
Director server.
If you need to power manage partitions of an IBM Power 7 server that is managed by
an HMC, IBM Systems Director VMControl must be active and the inventory of the
server that contains the partitions must be collected.
It is recommended not to set the AEM polling interval to a lesser value than the polling
interval that is supported by the managed resource.
For timely notification, configure SNMP traps that are generated by the UPS to be sent to
the IBM Systems Director server.
The metering interval for the UPS should be set as short as possible to detect changes
and notify the associated resources as early as possible.
Do not set system power capping or system power savings policies on both a slot and on
the blade in that slot.
Do not set group capping policies on two groups, where one group contains a slot and the
other group contains a blade in that slot.
Ensure that the resource against which you are applying the power cap policy supports
the same power cap type (ac or dc).
Make use of the base IBM Systems Director features such as Scheduling jobs, Event
automation plan, and Monitors and thresholds, along with AEM power monitoring to get
more advantages.
If a resource has both natively metered data and externally metered data, set the metering
interval for the metering device and the resource to the same value.
Use AEM power policies to enforce the power management settings to ensure that the
power savings value is continuously enforced.
Adding the same PDU to multiple IBM Systems Director servers could cause the PDUs
minimum and maximum power averages to be incorrect. Some PDUs such as LinkHub do
not support to be managed by multiple AEM instances. The best practice is to add a PDU
to a single IBM Systems Director instance.
373
For performing outlet switching on supported PDUs, always discover the PDU that is using
the SNMPv1 Read/Write community name or SNMPv3.
Study the power consumption trend and the CPU utilization of servers for a good amount
of time. Then, determine the time windows where you can enable the power savings
feature.
Enable hard power capping unless you have a need for accommodating more servers
within the given power budget that is not met by the [Minimum guaranteed input power
value - Maximum input power value] range.
374
Chapter 7.
AIX Profile Manager

This chapter provides a full description of AIX Profile Manager (APM). The AIX Profile
Manager is a tool that can help implement and monitor the security of all AIX servers in a
production environment, but also implement and monitor the system compliance of those AIX
servers.
7.1, AIX Profile Manager on page 376

7.2, AIX Profile Manager: Security on page 377
7.3, AIX Profile Manager: System compliance on page 383
7.4, Event automation plan on page 395
375
7.1 AIX Profile Manager

The AIX Profile Manager is an excellent tool that can help implement and monitor (from a
central location) the security of all AIX servers in a production environment. The tool can also
implement and monitor the system compliance of those AIX servers. System compliance is
the tuning and system settings, which must be the same on all servers like memory tuning
options and system dump settings.
The most important thing to understand is that the security and system compliance are quite
different to manage and implement into AIX Profile Manager. The common way is always to
create or use an existing profile, create or use an existing template from the profile, then
deploy the template on the servers.
Important: You can deploy a template to several servers but a server can have only one
template that is deployed.
The first part of this chapter covers the security implementation through examples. The
second part covers the system compliance monitoring and settings, which can be customized
to improve this compliance.
376
7.2 AIX Profile Manager: Security

APM is used for implementing and monitoring compliance security rules that are based on
predefined standards profiles on AIX and VIO servers.
To access the AIX Profile Manager interface through the IBM Systems Director home page
interface, select Plugins AIX Profile Manager, as shown in Figure 7-1.
Figure 7-1 AIX Profile Manager home page
The predefined standards that are available with AIX Profile Manager are listed in Table 7-1:
Table 7-1 AIX Profile Manager predefined standards
Security model in APM
Corresponds to:
ice_DLS
Default IBM Security model for AIX
ice_LLS
Low level of security defined by IBM for AIX
ice_MLS
Medium level of security defined by IBM for AIX
ice_HLS
High level of security defined by IBM for AIX
ice_DOD
Department of Defense (DoD) STIG compliance settings
ice_PCI
Payment card industry Data Security Standard compliance
ice_SOX
Sarbanes-Oxley Act and COBIT compliance
ice_Hipaa
Health Insurance Portability and Accountability Act (HIPAA)

compliance
7.2.1 Requirements
AIX Profile Manager is supported on every IBM system and operating system that is also
supported in IBM Systems Director 6.3.
Chapter 7. AIX Profile Manager
377
Following are the basic requirements to install and use AIX Profile Manager with IBM
Systems Director:
IBM PowerSC Express Edition must be installed on all servers to enable the use of all
policies.
For AIX 6.1: TL7 or higher is required.
For AIX 7.1: TL1 or higher is required.
The file set bos.ahafs.rte is required on all systems.
AIX Profile Manager plug-in must be installed on the IBM Systems Director server.
AIX servers must be discovered and inventoried before using APM.
To check if prerequisites are available, run the commands that are shown in Example 7-1:
Example 7-1 Commands to check if all prerequisites are installed (AIX 6.1 is used in this example)
oslevel -s
6100-07-XX-XXX
lslpp -l powerscExp.licence
Fileset
Level State
Description
---------------------------------------------------------------------------Path: /usr/lib/objrepos
powerscExp.license
6.1.6.15 COMMITTED PowerSC Express Edition
lslpp -l powerscExp.ice.cmds
Fileset
Level State
Description
powerscExp.ice.cmds
1.1.2.0 COMMITTED ICE Express Security Extension
Path: /etc/objrepos
powerscExp.ice.cmds
1.1.2.0
COMMITTED
ICE Express Security Extension
lslpp -l bos.ahafs
Fileset
Level State
Description
bos.ahafs
6.1.7.15 APPLIED
Aha File System
Path: /etc/objrepos
bos.ahafs
6.1.7.15
APPLIED
Aha File System
AIX 6.1 is used in the Example 7-1.

Important: The profiles that are available in AIX Profile Manager cannot be customized. If
you want your own model of security, either use AIX Security Expert (AIXPert) or create
your own profiles and templates from the artex command. More information about AIX
Runtime Expert (artex) commands is available further in this chapter. As a best practice, do
not edit the existing templates (PCI, SOX, DoD, and HIPAA; create your own.
Attention: The XML files from the aixpert commands cannot be imported into AIX Profile
Manager; this is not supported.
378
7.2.2 Before implementing

Before implementing on all servers to the desired security model, consider the following factors.
Choose the right security policy. A security policy that is too high can prevent any application
from working correctly and users from logging in. A security model that is too low could be a
serious risk. To check all available rules for policies in AIX Profile Manager, check the content
of the XML files in the /etc/security/aixpert/custom directory for each policy. To generate
XML files for DLS, LLS, MLS, and HLS profiles, run the aixpert command that is shown in
Example 7-2.
Example 7-2 Generate XML files from aixpert command
cd /etc/security/aixpert/custom
aixpert -l default -n -o security_default.xml
aixpert -l low -n -o security_low.xml
aixpert -l medium -n -o security_medium.xml
aixpert -l high -n -o security_high.xml
ls securit*
security_default.xml security_low.xml security_medium.xml security_high.xml
The files for PCI, SOX-COBIT, DoD, and HIPAA are already located in the directory if package
powerscExp.ice.cmds is installed on the operating system. You can check if it is installed by
running the command in Example 7-3.
Example 7-3 Run this command to check the other security XML files
lslpp -l powerscExp.ice.cmds
Fileset
Level State
Description
powerscExp.ice.cmds
1.1.2.0 COMMITTED ICE Express Security Extension
Path: /etc/objrepos
powerscExp.ice.cmds
1.1.2.0
COMMITTED
cd /etc/security/aixpert/custom
ls PCI.xml DoD.xml Hipaa.xml SOX-COBIT.xml
DoD.xml
Hipaa.xml
PCI.xml
ICE Express Security Extension
SOX-COBIT.xml
The format for each rule in an XML file is shown in Example 7-4.
Example 7-4 Example of a rule in an XML format
<AIXPertEntry name="pci_maxage" function="maxage">

<AIXPertRuleType type="PLS"/>
<AIXPertDescription>Implements PCI Section 8.5.9 for Maximum age for password:
Specifies the maximum number of weeks
(13 weeks, atleast 90 days) that a
password is
valid</AIXPertDescription>
<AIXPertPrereqList>bos.rte.date,bos.rte.commands,bos.rte.security,bos.rte.shell,bo
s.rte.ILS</AIXPertPrereqList>
<AIXPertCommand>/etc/security/aixpert/bin/chusrattr</AIXPertCommand>
<AIXPertArgs>maxage=13 ALL pci_maxage</AIXPertArgs>
<AIXPertGroup>Password policy rules</AIXPertGroup>
379
</AIXPertEntry>
In Example 7-4 on page 379, the most important lines are the following rules:
AIXPertEntry name: This is the name of the rule
AIXPertDescription: This is a description of the rule
AIXPertPrereqList: Contains a list of prerequisites to execute the command (list required
file sets here)
AIXPertCommand: This is the command that will be executed. In our example, this is the
chusrattr command
AIXPertArgs: This contains the arguments of the command
In Example 7-4 on page 379, the rule implements a maxage with a value of 13 weeks for all
users.
Attention: This rule could lead to password expiration if the maxage setting is not already
set in your environment. Remember to check the age of all passwords before implementing
this rule; otherwise, critical application users could be locked.
The following steps must be followed before implementing security rules on all systems:
1. Test the rules in a test environment before implementing the selected security model on all
systems.
2. When tested, apply the selected model step by step. For example:
a. Apply the security model on non-critical systems, then wait at least one or two weeks.
This could help to identify and solve all problems before implementing the security
model on critical systems. If there are too many problems, apply a rollback on the
systems or a lower security model.
b. Implement the model on the production systems and closely monitor those systems.
Tip: Do not implement the security levels on all productions at one time. Go step by
step, server by server.
7.2.3 Implementation
As an example in this subchapter, we work through the implementation procedure for the LLS
security model on an AIX server.
This example is simple because profiles and templates are already created in APM. This
example works for all security models that are available into APM:
1. From the AIX Profile Manager console, select View and Manage templates. In Figure 7-2
on page 381, you can see the default available templates in AIX Profile Manager.
380
Figure 7-2 Security templates available in AIX Profile Manager
2. Select ICE LLS Predefined template Deploy.

From this point, there are several options to select the targeted host and tabs for running
the deployment job.
To select the host, there are three options that are available in the Target tab in the Show
menu, which are All Targets, Groups, and Recent Targets, as shown in Figure 7-3.
Figure 7-3 Options that are available to find the targeted host
3. Select All Targets. Then, enter the name of the client in the Search field (Figure 7-4 on
page 382) and then click Search.
4. When the targeted host is found, click Select Add. For this example, the targeted host
is itso-cb-sys5.itso.ral.ibm.com.
381
Figure 7-4 Selecting the host where to deploy the security policy
The other tabs are Schedule, Notification, and Options. In theses tabs, there are options
for scheduling the jobs, managing notifications to send mails on events during the job, and
other options.
Note: In the Schedule tab for the Job Name, it is useful to insert the host name of the
targeted host at the beginning of the name of the job. This way, it is easier to find the job
in the Task Management of IBM Systems Director.
5. Click OK to run the job. To check the status of the job, click Display Properties and then
go to the Logs tab.
When the job has run successfully, the security model LLS is deployed on the target host.
382
7.3 AIX Profile Manager: System compliance

System compliance is quite different to implement and to manage compared with security
compliance.
First, no profiles are available by default into AIX Profile Manager. The reason is simple. The
system configuration must be taken from one server that is set as a standard and then, as a
best practice, use the artex commands to generate a new profile, which contains the system
settings of the standard server. Finally, import the profile into the AIX Profile Manager, create
a template, and deploy to additional servers.
Notice: You can create XML profiles from AIX Profile Manager console, but with AIX
Runtime Expert, you can manage the content of the XML files that you created. For
example, you can create a profile for the no options (network tuning options) from AIX
Profile Manager by retrieving values from a selected system. But this profile contains all
the no settings that are available. If you want to have only a few of these options in AIX
Profile Manager (tcp_sendspace and tcp_recvspace, as an example), it is not possible to
manage it with the graphical interface of AIX Profile Manager. Using AIX Runtime Expert
gives you the ability to manage your files as you want.
On the same way, if you want to merge several profiles, you will have a thousand settings
when creating the profile from AIX Profile Manager whereas you can decide which settings
you want in your XML with AIX Runtime Expert commands. In this document, we decided
to use AIX Runtime Expert commands as a best practice.
Online Content: At the following site, there is a demo that shows how to create profiles
from the AIX Profile Manager graphical interface:
http://youtu.be/h2CT7K0JM7c
video.
Before doing these steps, we explore AIX Runtime Expert, which is required to create and
manage profiles.
Complete documentation about AIX Runtime Expert can be found in the AIX Information
Center:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.baseadmn
%2Fdoc%2Fbaseadmndita%2Fartex_main.htm
7.3.1 Profiles from AIX Runtime Expert

This section shows how to use AIX Runtime Expert commands to create profiles, import them
into AIX Profile Manager, and then deploy them on the other systems.
Prerequisites
The AIX Runtime Manager is available for AIX 6.1 and AIX 7.1. Check if the following
packages are installed on the host, as shown in Example 7-5.
Example 7-5 Example for an AIX 6.1 server
lslpp -l |grep artex

artex.base.agent
6.1.7.15
APPLIED
AIX Runtime Expert CAS agent
383
artex.base.rte
artex.base.samples
artex.base.agent
artex.base.rte
artex.base.samples
6.1.7.15
6.1.7.0
6.1.7.15
6.1.7.15
6.1.7.0
APPLIED
APPLIED
APPLIED
APPLIED
APPLIED
AIX
AIX
AIX
AIX
AIX
Runtime
Runtime
Runtime
Runtime
Runtime
Expert
Expert sample
Expert CAS agent
Expert
Expert sample
Default profiles that are available

When the AIX Runtime Expert is installed on the AIX server, go to the
/etc/security/artex/samples directory, where you find the default profiles from artex.
Important: Do not modify the profile files. The process of modifying options is explained
later in this document. These files are just samples and do not contain any value.
To list the profiles that are available, use the artextlist command as shown in Example 7-6.
Example 7-6 List profiles that are known by AIX Runtime Expert
artexlist
/etc/security/artex/samples/acctctlProfile.xml
/etc/security/artex/samples/aixpertProfile.xml
/etc/security/artex/samples/all.xml
/etc/security/artex/samples/alogProfile.xml
/etc/security/artex/samples/authProfile.xml
/etc/security/artex/samples/authentProfile.xml
/etc/security/artex/samples/chconsProfile.xml
/etc/security/artex/samples/chdevProfile.xml
/etc/security/artex/samples/chlicenseProfile.xml
/etc/security/artex/samples/chservicesProfile.xml
/etc/security/artex/samples/chssysProfile.xml
/etc/security/artex/samples/chsubserverProfile.xml
/etc/security/artex/samples/chuserProfile.xml
/etc/security/artex/samples/classProfile.xml
/etc/security/artex/samples/coreProfile.xml
/etc/security/artex/samples/default.xml
/etc/security/artex/samples/dumpctrlProfile.xml
/etc/security/artex/samples/envProfile.xml
/etc/security/artex/samples/errdemonProfile.xml
/etc/security/artex/samples/ewlmProfile.xml
/etc/security/artex/samples/ffdcProfile.xml
/etc/security/artex/samples/filterProfile.xml
/etc/security/artex/samples/gencopyProfile.xml
/etc/security/artex/samples/iooProfile.xml
/etc/security/artex/samples/krecoveryProfile.xml
/etc/security/artex/samples/login.cfgProfile.xml
/etc/security/artex/samples/lvmoProfile.xml
/etc/security/artex/samples/mktcpipProfile.xml
/etc/security/artex/samples/mkuser.defaultProfile.xml
/etc/security/artex/samples/namerslvProfile.xml
/etc/security/artex/samples/nfsProfile.xml
/etc/security/artex/samples/nfsoProfile.xml
/etc/security/artex/samples/nisProfile.xml
/etc/security/artex/samples/noProfile.xml
/etc/security/artex/samples/probevueProfile.xml
/etc/security/artex/samples/rasoProfile.xml
384
/etc/security/artex/samples/roleProfile.xml
/etc/security/artex/samples/ruserProfile.xml
/etc/security/artex/samples/schedoProfile.xml
/etc/security/artex/samples/secattrProfile.xml
/etc/security/artex/samples/shconfProfile.xml
/etc/security/artex/samples/smtctlProfile.xml
/etc/security/artex/samples/syscorepathProfile.xml
/etc/security/artex/samples/sysdumpdevProfile.xml
/etc/security/artex/samples/trcctlProfile.xml
/etc/security/artex/samples/trustchkProfile.xml
/etc/security/artex/samples/tsdProfile.xml
/etc/security/artex/samples/viosdevattrProfile.xml
Each profile manages a category of settings for the system.
Create a profile
For example, to create a profile to manage and control the sysdumpdev configuration, follow
these steps:
1. On the standard system, run the command that is shown in Example 7-7.
Example 7-7 View configuration settings of the system with the artexget command
artexget -r /etc/security/artex/samples/sysdumpdevProfile.xml
<?xml version="1.0" encoding="UTF-8"?>
<Profile origin="get" version="2.0.1" date="2013-04-22T14:23:05Z">
<Catalog id="sysdumpdevParam" version="2.1">
<Parameter name="primary" value="/dev/lg_dumplv"/>
<Parameter name="secondary" value="/dev/sysdumpnull"/>
<Parameter name="copy_directory" value="/var/adm/ras"/>
<Parameter name="forced_copy_flag" value="1"/>
<Parameter name="always_allow_dump" value="0"/>
<Parameter name="type_of_dump" value="traditional" applyType="nextboot"
reboot="true"/>
<Parameter name="full_memory_dump"/>
</Catalog>
</Profile>
The result of this command is the values from the sysdump configuration of the standard
system that is displayed in XML format. This is the profile for the AIX Profile Manager.
2. Now, create the profile XML file by using the command that is shown in Example 7-8:
Example 7-8 Create the profile file in XML format
artexget -r /etc/security/artex/samples/sysdumpdevProfile.xml >

/tmp/sydumpdev_custom_profile.xml
The file that is created is now different from the sample file because it contains the values
of the current system configuration.
In this manner, the file can be fully controlled before being imported into AIX Profile
Manager. The file can be modified and customized.
Add the profile into AIX Profile Manager

In this example, the host where the template is deployed is the same location where we
created the template because of some limitations within our lab environment.
385
Perform the following steps to add created profiles into AIX Profile Manager:
1. From the AIX Profile Manager console, click View and manage profiles, as shown in
Figure 7-5.
Figure 7-5 Select from menu to manage profiles
2. Then, select Import Import from a system, select the standard host where the XML
file has been generated, and click OK.
3. Enter the name of the directory where the XML file is located and select View. Select the
file and click Add, as shown in Figure 7-6.
Figure 7-6 Import the XML file to AIX Profile Manager
4. Select OK to import the file.
386
The file is now integrated into the AIX Profile Manager, as shown in Figure 7-7.
Figure 7-7 List of profiles, which now contains the new profile
Note: It is also possible to import XML files by using the AIX Profile Manager menus, but
as a best practice, we recommend the usage of artex commands, which allow you to have
better control of the XML file content.
Create the template

Create a template that is based on the previously created profile to allow a deployment to
other systems:
1. From the AIX Profile Manager console, select View and Manage templates Create.
387
2. Select Operating System as the Template type. Select AIX Profile Manager as the
Configuration to create a template. Insert a name for the template and description of the
template and finish by selecting Continue, as shown in Figure 7-8.
Figure 7-8 Create a template
3. Select Browse to find the previously created profile. In the selection window, remove the
preselected profile name USMEveryoneRole and add the sysdumpdev_custom_profile
profile, as shown in Figure 7-9.
Figure 7-9 Adding the new profile into the template
388
4. Select OK. In our example, we did not change the default options in the Template Options.
See Figure 7-10.
Figure 7-10 Create new AIX Profile Manager template: sysdump_configuration_template
5. Click Save. The template is now ready to be deployed. As shown in Figure 7-11, we can
now see the template sysdump_configuration_template in the list.
Figure 7-11 List of templates, which now contains the new template
Deploy the template

To deploy the template, perform the following steps:
1. Select the previously created template name sysdump_configuration_template in the
example, and click Deploy.
2. Select the host where the template will be deployed (itso-cb-sys5.itso.ral.ibm.com in
the example). Then, in the Selected column, click OK.
3. Check on the deployed system that the sysdumpdev settings are correct by running the
sysdumpdev command, as shown in Example 7-9 on page 390.
389
Example 7-9 Result of the sysdumpdev command
sysdumpdev -l
primary
secondary
copy directory
forced copy flag
always allow dump
dump compression
type of dump
/dev/lg_dumplv
/dev/sysdumpnull
/var/adm/ras
TRUE
FALSE
ON
traditional
Monitor the configuration with AIX Profile Manager

Now, we change the sysdumpdev configuration on one of the deployed systems and run a
verification command to see what happens.
1. Run the sysdumpdev command as shown in Example 7-10.
Example 7-10 Change the primary device in the sysdumpdev configuration
sysdumpdev -p /dev/lv_dump
primary
/dev/lv_dump
secondary
/dev/sysdumpnull
copy directory
/var/adm/ras
forced copy flag
TRUE
always allow dump
FALSE
dump compression
ON
type of dump
traditional
2. From the AIX Profile Manager, select Schedule configuration status monitoring and
select the host that has been modified (for our example, the host is
itso-cb-sys5.itso.ral.ibm.com). Then, click OK. See Figure 7-12.
Figure 7-12 Manage Monitoring panel
390
3. Again, check the welcome page. The graphic should have changed depending of the
configuration threshold. It should look similar to what is shown in Figure 7-13.
Figure 7-13 The graphic indicates that an operating system is not compliant with our rule
4. In Figure 7-13, we click 1 systems with a % of differences between 10 and 50% to see
all settings that are detected as non-compliant, as shown in Figure 7-14.
Figure 7-14 Shows that the system is not compliant with defined rules (sysdumpdev)
5. Select the non-compliant host (itso-cb-sys5.itso.ral.ibm.com, shown in Figure 7-14)

and click View differences. The differences are shown in Figure 7-15 on page 392.
391
Figure 7-15 Settings that are not compliant with the defined standard (sysdumpdev)
Warning: If the Type column that is shown in Figure 7-15 is set to Dynamic, the value will
be changed online, but some tuning settings require a reboot of the system. The Type
column will be changed from Dynamic to Reboot.
6. From this point, it is possible to redeploy the template to correct the problem. Click
Redeploy OK, as shown in Figure 7-16.
Figure 7-16 Redeploy
7. After the deployment, the server is back to its normal situation as shown in Figure 7-17 on
page 393.
392
Figure 7-17 Profile differences for the host: itso-cb-sys5.itso.ral.ibm.com are shown at 0% compared to the deployed
profile: merge_profile.xml
This process could help to massively and quickly correct nonstandard settings on several AIX
servers.
Online content: For a video demonstration of the preceding tasks, see the following video:
http://youtu.be/SnRxIEgeti4
video.
Doing more with the AIX Profile Manager and artex commands
In the following example, we show how to merge several policies in only one XML file. We
take as an example the values of sysdumpdev profile and no profile and put them into a
new file. That last file is imported into AIX Profile Manager. This allows you to import only one
profile, which contains all the desired configuration values into AIX Profile Manager.
Important: At the time of writing, the existing option into AIX Profile Manager that allows
you to merge profiles, was not working correctly. That is why you should use the
command-line interface (CLI) and AIX Runtime Expert to create merged profiles.
Run the following examples to merge files from CLI on a first host, which is considered as
standard in your architecture:
1. We create an XML file that contains the sysdumpdev configuration value and another XML
file that contains the network settings that are managed by the no command, as shown in
Example 7-11.
Example 7-11 Create new XML files
artexget -r /etc/security/artex/samples/sysdumpdevProfile.xml >

/tmp/sysdumpdev.xml
artexget -r /etc/security/artex/samples/noProfile.xml > /tmp/no.xml
2. Merge the two files into one and edit the file to delete the non-required lines, as shown in
Example 7-12 on page 394.
393
Example 7-12 Merge the two files into a new one and remove the lines in red
cat sysdumpdev.xml no.xml >> /tmp/merge_profile.xml

vi /tmp/merge_profile.xml
<Catalog id="noParam" version="2.1">
<SubCat id="tcp_network">
<Parameter name="tcp_nagle_limit" value="65535"/>
<Parameter name="tcp_sendspace" value="16384"/>
</SubCat>
</Catalog>
<Parameter name="primary" value="/dev/lv_dump"/>
<Parameter name="type_of_dump" value="fw-assisted" applyType="nextboot"
reboot="true"/>
<Parameter name="full_memory_dump" value="disallow"/>
</Catalog>
</Profile>
<Parameter name="primary" value="/dev/lv_dump"/>
<Parameter name="type_of_dump" value="fw-assisted" applyType="nextboot"
reboot="true"/>
<Parameter name="full_memory_dump" value="disallow"/>
</Catalog>
</Profile>
...
<SubCat id="restricted">
<Parameter name="extendednetstats" value="0" applyType="nextboot"
readOnly="true" reboot="true"/>
<Parameter name="inet_stack_size" value="16" applyType="nextboot"
<Parameter name="net_malloc_police" value="0" readOnly="true"/>
<Parameter name="netm_affinity" value="0" applyType="nextboot"
<Parameter name="pseintrstack" value="24576" readOnly="true"/>
<Parameter name="use_isno" value="1" readOnly="true"/>
</SubCat>
</Catalog>
</Profile>
3. Save the new file.
394
4. Check the profile with the artexset command. Run the example that is shown in
Example 7-13.
Example 7-13 Check the correct format of the new file
artexset -t /tmp/merge_profile.xml
Profile correctness check successful.
5. Import the file into AIX Profile Manager, create a template, and deploy on a second server.
6. On this second server, change the value of the sysdumpdev primary device, change the
value of tcp_sendspace and tcp_nagle_limit, and then run a verification on the system.
The result should be similar to what is shown in Figure 7-18.
Figure 7-18 List of settings that are detected by APM as non-compliant with the default profile
Online Content: For a video demonstration of the preceding tasks, see the following
video:
http://youtu.be/g-BD_f36Aaw
video.
7.4 Event automation plan

In this chapter, we describe how to configure the IBM Systems Director and the AIX Profile
Manager to send email in case of a critical event.
395
To configure the event automation plan feature into IBM Systems Director, perform the
following steps:
1. From IBM Systems Director, click Event Automation Plans from the Automation menu,
Figure 7-19 Click Event Automation Plans
2. Click Create Next. Insert a name and description, and click Next as shown in
Figure 7-20.
Figure 7-20 Definition and description of the event automation plan
396
3. Define All Operating Systems as target, as shown in Figure 7-21, and click Next.
Figure 7-21 Select group All Operating Systems as target
4. Select Advanced Event Filters in Events. Select AIX Profile Manager events in the list,
as shown in Figure 7-22, and then click Next.
Figure 7-22 Select AIX Profile Manager events in the list
5. Click Create.
397
6. Select Send an e-mail (Internet SMTP), as shown in Figure 7-23.
Figure 7-23 Select Send an e-mail (Internet SMTP)
398
7. Complete the form as shown in Figure 7-24 with your desired settings to configure the
email, then click OK.
Figure 7-24 Complete the form for email configuration
399
8. Select the event action that has been created (in this example,
APM_mail_on_critical_event) and click Next, as shown in Figure 7-25.
Figure 7-25 Event Actions panel
9. Select All the time (24x7) and then click Next, as shown in Figure 7-26.
Figure 7-26 Select the time range
10.Check the summary and click Finish.
400
11.The event automation plan is now displayed in the IBM Systems Director console, as
Figure 7-27 Event automation plans
7.5 Best practices

Listed in this section are the best practices for AIX Profile Manager:
If your security standard is different from the models that are available in AIX Profile
Manager, use IBM Security AIXPert. More information about AIXPert can be found here:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.security/doc/secur
ity/security_pdf.pdf
You cannot import AIXPert XML files into AIX Profile Manager.
Do not hesitate to make tests before implementing the security model that you want.
Implement your security and system compliance step by step.
If using one of the non IBM models (PCI, SOX, HIPPA, or DoD), you must have PowerSC
installed on all systems.
Do not modify the PCI, SOX, Cobit, HIPAA, and DoD security models.
Use the artex commands to create your own profiles and then import them into AIX Profile
Manager.
Read the artex documentation before you start to use it:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/topic/com.ibm.aix.baseadmn/doc/basea
dmndita/artex_concepts.htm
Test your XML file with the artexset -t command to determine if the format is correct.
Create groups into IBM Systems Director. It is easier to manage AIX Profile Manager with
IBM Systems Director groups.
Create an event automation plan for AIX Profile Manager. You can configure either to send
email, to log a file, or to send SNMP messages to the monitoring server.
401
402
Chapter 8.
Workload Partition Manager

This chapter covers best practices and common questions to consider before implementing
workload partitions (WPARs) with WPAR Manager.
In the first part, we briefly introduce the WPAR Manager plug-in for IBM Systems Director and
cover the basics of installation.
The bulk of this chapter focuses on the best practices and the most important questions to
ask before creating a WPAR and WPAR Manager infrastructure. We also show how you can
manage and relocate WPARs using WPAR Manager graphical interface and the
command-line interface (CLI). This chapter does not cover the step-by-step implementation of
WPAR.
The end of this chapter includes recommended sites that you can read to get all the detailed
procedures to implement WPARs.
8.1, WPAR Manager on page 404

8.2, Install IBM WPAR Manager on page 404
8.3, Accessing WPAR Manager on page 405
8.4, Managing WPARs infrastructure with WPAR Manager on page 407
8.6, Additional documentation on page 416
403
8.1 WPAR Manager

WPAR Manager is an IBM Systems Director advanced manager that allows you to manage
multiple WPARs from a central location.
From a single access point, you can perform the following functions:
Discover WPARs
Create and delete WPARs
Back up and restore WPARs
Manage relocation domain groups and relocation policies
Modify dynamically WPAR CPU and processor provisioning
Move WPARs (Mobility)
Clone WPARs
Synchronize WPARs after an AIX upgrade
Manage LPARs that host the WPARs, which include event manager, performance reports,
compliance reports, and so on.
Information: With IBM Systems Director and WPAR Manager, the LPARs used to host
WPARs are called managed systems.
All these tasks can be done by using the graphical user interface of IBM Systems Director or
the command-line interface. With command-line interface, you can create scripts for added
flexibility.
Tip: To see the commands that are available in IBM Systems Director for managing
WPARs, use the smcli wparmgr help command.
With AIX 7.1, the following new features are supported:
Fibre Channel support with MPIO drivers for disk and sctape or atape drivers for tapes.
Trusted kernel extension support.
Capability to host AIX 5.2 versioned WPARs.
Tip: AIX 5.2 WPARs can be installed on an AIX 7.1 managed system only with an mksysb
backup file.
8.2 Install IBM WPAR Manager

IBM WPAR Manager can be installed on IBM Systems Director server, which runs on
Windows, Linux, or AIX operating systems. IBM WPAR Manager must be installed on the
same server as IBM Systems Director.
The binaries can be downloaded from the following link:
http://www-03.ibm.com/systems/software/director/downloads/plugins.html
8.2.1 Prerequisites
The following prerequisites are needed to install WPAR Manager:
At least 125 MB of free memory
5 MB in the root file system (/)
404
Minimum of 180 MB in/var

15 MB in/opt
For AIX and Linux, root privileges are required; and for Windows, administrative privileges
are required
The following requirements are needed to install the WPAR Manager agent:
AIX 6.1 or higher

mcr.rte file set is installed (installed by default with AIX 7.1)
200 MB free in/var
IBM Systems Director Common Agent installed
8.2.2 Installation
You can find the installation process of WPAR Manager at the following location:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.wparmgt.hel
ps.doc/wparlpp_pdf.pdf
Attention:
If you are in a production environment, do not specify an automatic restart of the IBM
Systems Director server while installing WPAR Manager. Restart IBM Systems Director
manually at the end of the installation by using the smstop and smstart commands.
Check that no jobs are running in the Tasks Management module before restarting it.
Remember to run discovery and inventory on the managed system after the WPAR
manager installation. Discovery must be run from the IBM Systems Director console
with the profile, Extended WPAR Inventory. Otherwise, IBM Systems Director will not
detect the managed system as a WPAR-capable system.
8.3 Accessing WPAR Manager

When installation is done, you can access WPAR Manager in two different ways:
1. You can log in through the graphical interface of IBM Systems Director server and then
click the Plug-ins tab and select WPAR Manager.
Chapter 8. Workload Partition Manager
405
Figure 8-1 shows the WPAR Manager welcome page.
Figure 8-1 Welcome page of WPAR Manager
2. You can use the command-line interface of the IBM Systems Director server. Run the
smcli wparmgr help command to display all available options, as shown in Example 8-1.
Example 8-1 List of available commands for the CLI
smcli wparmgr help

The following WPAR Manager commands are supported:
-
406
help - Display this help information

lswpar - List all WPARs, or properties of specific WPARs
mkwpar - Create a WPAR
rmwpar - Delete a WPAR
chwpar - Modify a WPAR
deploywpar - Deploy a WPAR definition
startwpar - Start a WPAR
stopwpar - Stop a WPAR
savewpar - Save a WPAR
restwpar - Restore a WPAR
movewpar - Relocate a WPAR
lswparcapablesys - List WPAR-capable systems, its WPARs, and device
information
lswparcompat - View compatibility results for a WPAR
syncwpar - Synchronize a WPAR
clonewpar - Clone a WPAR
lswparpolicy - View WPAR relocation policies
mkwparpolicy - Create a WPAR relocation policy
chwparpolicy - Modify a WPAR relocation policy
rmwparpolicy - Delete a WPAR relocation policy
lsrelocdomain - View a WPAR relocation domain
mkrelocdomain - Create a WPAR relocation domain
chrelocdomain - Modify a WPAR relocation domain
rmrelocdomain - Delete a WPAR relocation domain

lswparmgrsettings - Show WPAR Manager settings
chwparmgrsettings - Modify WPAR Manager settings
lswparmgrinfo - View WPAR Manager information (such as version and
license information)
Type "smcli <command_name> -h" to see the usage statement of the command.
Type "smcli <command_name> --help" for a full description of the command and
its usage
The command-line interface provides you the ability to create scripts to automate numerous
operations, such as massive deployment, backup operations, and relocations.
8.4 Managing WPARs infrastructure with WPAR Manager

All operations for managing WPARs with IBM WPAR Manager are described in the IBM
Redbooks document Exploiting IBM AIX Workload Partitions, SG24-7955, in section 4.5:
8.4.1 WPARs
In this chapter, we cover different scenarios to show that requirements and the overall
architecture can change a lot depending on what you want to achieve.
Creation of WPARs
Although the process to create a WPAR is simple, you still need to consider these questions
first:
Do you need a system WPAR or an application WPAR?
Do you need a private /usr and /opt?
Where will the file systems be located? Local? Network File System (NFS)? Storage area
network (SAN)?
Will you use relocation?
Will your WPAR have its private storage?
What about versioned WPARs?
Can you create a copy of an existing WPAR?
Depending on the answers to those questions, the way to install WPARs varies.
Do you need a system WPAR or an application WPAR?

Answering this question is easy if you consider the following factors:
Application WPAR: An application WPAR is generally used for one process or one job and
is a temporary WPAR. When the jobs or the script ends, the WPAR is automatically
removed from the managed system. It has no private file systems, users, or network
configuration. This kind of WPAR is used for High Computing Clusters.
System WPAR: The system WPAR can host your application, have its private file systems
and users, have a network configuration, and its own service such as cron. The system
WPAR uses more resources compared to the application WPAR.
407
Do you need private /usr and /opt?

Using read-only /usr and /opt is a good solution because it saves space and reduces the risk
of human error if someone tries to remove a file or directory in those file systems from a
WPAR. Many applications work without any problem in this case, but some application
requirements force you to reconsider this option, such as:
An application needs to write in /usr or /opt, or both
An application needs a specific file set that is not installed on the managed system
In those cases, you can perform the following functions:
Create a local file system in the WPAR for the application, such as /usr/local.
Grant write access to the file system (this solution is a risk because all other WPARs in the
same managed system will see the new files created in /usr).
Create the WPAR with its own /opt and /usr. This is the recommended solution. It will
solve the access problem but will increase the disk size (approximately 2 GB for private
/usr and /opt, compared to 450 MB for non-private /usr and /opt) and the WPAR will
also use more memory.
Tip: To create a system WPAR from the IBM Systems Director command line with private
/usr and /opt, use the smcli mkwpar command with the -l option (or --private_usr_opt).
Where will the file systems be located?

If you do not want to use relocation options, you can use standard shared file systems. They
will be created in the managed system volume group (VG).
If you want to use the relocation feature, select one of the following two options:
NFS
SAN
If you choose NFS, you need an NFS server that hosts all the file systems of your WPARs.
To create an NFS WPAR server, follow the instructions in section 8.8.1 of the IBM Redbooks
publication, Exploiting IBM AIX Workload Partitions, SG24-7955.
As a best practice, configure a dedicated NFS server. It also should not be located on the IBM
Systems Director server. This NFS server should have sufficient disk space (if WPARs have
private /usr and /opt), CPU, memory, and network resources to cover the performance
requirements. The more NFS WPARs that you have, the more hardware resources you will need.
Warning: WPARs that use IPv6 must use NFSv4.
Tip: If you want to relocate NFS WPARs, remember to enable access for all managed
servers to the NFS shares.
If you use SAN, there is no need to configure an additional server. The managed systems
should have the SAN disks configured with drivers and when creating the new WPARs, you
should then specify the disk name where you want to configure the WPAR.
Tip: If you want to relocate SAN WPARs, remember to configure all managed systems to
access the SAN disks.
408
Will you use relocation?

There are a couple of things to consider before using relocation:
Both managed systems (the current and the target) used for mobility must be in the same
network subnet.
The WPARs must have been created with the checkpointable feature.
Tip: Use the smcli lswpar -G -n WPAR_NAME command to see if the checkpointable
feature is active or not. The option to use when creating the WPAR is -c when using the
command-line interface.
The WPARs must be moved to a managed system with compatible hardware and
software.
NFS file systems or SAN disks must be accessible on both managed systems.
What about versioned WPARs?

If you want to use versioned WPARs, consider the following advice before implementing it.
Why should you use versioned WPARs?

Listed are some examples where versioned WPARs can be used:
An application that is installed on an AIX 5.2 or 5.3 cannot be migrated to AIX 6.1 or 7.1
Eliminate the old hardware and consolidate all old AIX servers into one managed system,
which hosts those old AIX in WPARs. This helps reduce the hardware maintenance cost
and reduce the electric and cooling costs.
Boost the performance of your old AIX 5.2 and AIX 5.3 servers by running them on new
hardware such as IBM Power7 processors.
Benefits from the latest Power7 and PowerVM features (AME, SMT4, and so on).
What are the basic requirements for versioned WPARs?

The requirements to host AIX 5.2 and 5.3 WPARs are shown in Table 8-1.
Table 8-1 Requirements for using IBM AIX 5L WPARs
AIX 5.2
AIX 5.3
Minimum level of AIX
TL10 SP8
TL 12 or higher
vwpar.images level
1.1.2
1.1.2
Managed system minimum

level
AIX 7.1
AIX 7.1 TL1
Hardware required
IBM Power7
IBM Power7
Tip: You need an mksysb backup to create versioned WPARs. The versioned WPAR
always owns its /usr and /opt file systems. You cannot use shared file systems. The
option that is used to indicate which mksysb to use in the smcli mkwpar command is -B
mksysb_image_name.
Important: A separate licensed program is required to run versioned WPARs in your

environment.
409
Versioned WPARs and Live Application Mobility

There are some prerequisites before using Live Application Mobility with versioned WPARs:
The WPARs must have the software vwpar.images 1.1.2 or higher installed.
On AIX 5.2, the following APARs must be installed:
APAR IZ72315
APAR IZ90201
On AIX 5.3, the following APAR must be installed: APAR IZ89583
More information about versioned WPARs requirements and limitations can be found at the
following site:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.wpar%2Fc
reconfig-create-wpar.htm
Will your WPAR have its own private storage?

For different reasons, you might want to configure and manage storage directly on the WPARs.
This is possible but there are some questions, limitations, and prerequisites to consider:
Attention: Storage allocation is not supported for application WPARs.
Will you configure the disks on the managed system and then export them to the WPAR?
The disks are configured on the managed systems, then exported to WPAR. Using this
method allows you to manage several disks for several WPARs while using a minimum of
Fibre Channel adapters. It also allows you to manage allocation of the disks directly from
the managed systems. You can also easily check the disk configuration of each WPAR by
using the lswpar -D command, which gives you a complete view of devices that are
allocated to WPARs.
Tip: Use the smcli chwpar command from the IBM Systems Director command line to
manage devices on WPARs. The smcli chwpar --help command provides information
about available options.
Will you directly configure the Fibre Channel adapter into the WPAR?
This method allows the WPAR administrator to manage its own disk configuration. The
disks are not viewed by the managed system.
This feature includes serious limitations:
The Fibre Channel adapter is not usable by other WPARs
Live Application Mobility is not supported
This method is not supported for versioned WPARs
Important: Only fiber-attached devices, FC adapters, and virtual SCSI (vSCSI) devices
are supported in WPARs. All disks that are managed by the MPIO subsystem and
supported by AIX are also supported on WPARs.
Is it possible to create WPAR from an existing one?

With WPAR Manager, you can create clones of existing WPARs. Data on external devices is
not copied (if external devices contain rootvg information, this data is copied to a specified
external device).
You can create a clone by using the graphical interface or the command line.
410
Tips:
You can clone local WPAR, NFS WPAR, RootVG WPAR, and versioned WPAR.
For your deployment, you can use the clone of a standard WPAR that you created and
then use it to deploy new WPARs.
8.4.2 Relocation
Warning: Live Application Mobility is not supported between hardware that is not from the
same processor family. For example, you cannot migrate a WPAR that is running on IBM
Power6 to an IBM Power7 server.
Do you want automatic relocation?

If you want to use the features of automatic relocation, WPAR Manager automatically
manages the relocation that is based on relocation domain groups that you created and on
relocation policies.
Relocation domain groups

You must create relocation domain groups in IBM Systems Director. A relocation domain
group restricts the number of servers to which WPARs can be moved automatically by WPAR
Manager.
As an example you can create the following groups:
IBM_PROD_P7, which contains the managed systems where critical WPARs are hosted.
IBM_DEV_P6, which contains the managed systems where your non-critical production is
hosted.
By creating these two groups, you can avoid a relocation of one of your critical WPARs on an
older IBM Power Systems server and avoid a performance issue.
You can manage the relocation domain groups with the IBM Systems Director command-line
interface for your scripts, as shown in Example 8-2.
Example 8-2 Commands to manage relocation domain groups
smcli mkrelocdomain -m itso-cb-sys5.itso.ral.ibm.com -n IBM_PROD_P7

Create relocation domain - IBM_PROD_P7
======================================
smcli lsrelocdomain -D
===================================
Relocation domain name: IBM_PROD_P7
===================================
Description: Membership: itso-cb-sys5.itso.ral.ibm.com
Relocation policy: -
411
Warnings:
A managed system can be in only one relocation domain group.
If you try to manually relocate a WPAR that is hosted in a managed system that is a part
of a relocation domain group, IBM Systems Director can again move the WPAR based
on the relocation policies.
Relocation policies
When you create relocation domains, you must configure relocation policies. These relocation
policies allow the WPAR Manager to know when it should start using relocation with your
different WPARs.
The relocation policies are based on three important parameters:
Period: In minutes. If you specify 20 minutes, WPAR Manager starts to relocate WPARs if
an event happens during at least 20 minutes.
CPU Threshold: If you set 80%, WPAR Manager starts to relocate WPARs if a managed
system uses more than 80% of the CPU.
Memory Threshold: If you 80%, WPAR Manager starts to relocate WPARs if a managed
system uses more than 80% of the available memory.
In this example, WPAR Manager will not relocate WPARs if all managed systems use 80% or
more of CPU and memory.
Tip: Do not specify values that are too low or WPAR Manager starts relocating WPARs too
often.
You can manage relocation policies with the command-line interface from IBM Systems
Director server, as shown in Example 8-3.
Example 8-3 Command to manage relocation policies
smcli mkwparpolicy -a -d IBM_PROD_P7 -p 30 -c 80 -m 80 -n IBM_PROD_P7_Reloc_Policy

Create policy - IBM_PROD_P7_Reloc_Policy
========================================
Enable policy - IBM_PROD_P7_Reloc_Policy
========================================
Managed system: itso-cb-sys5.itso.ral.ibm.com
smcli lswparpolicy
Name
Auto Reloc Avg Period CPU Util Mem Util Reloc Domains
----------------------------------------------------------------------------IBM_PROD_P7_Reloc_Policy Yes
30
80.0
80.0
IBM_PROD_P7
smcli rmwparpolicy -n IBM_PROD_P7_Reloc_Policy

Delete policy - IBM_PROD_P7_Reloc_Policy
========================================
Disable policy - itso-cb-sys5.itso.ral.ibm.com
==============================================
Managed system: itso-cb-sys5.itso.ral.ibm.com
412
smcli lsrelocdomain -D
===================================
Relocation domain name: IBM_PROD_P7
===================================
Description: Membership: itso-cb-sys5.itso.ral.ibm.com
Relocation policy: IBM_PROD_P7_Reloc_Policy
Do you want to do use manual relocation?

You can decide to use manual relocation. Manual relocation must be done from WPAR
Manager. It can be done from the graphical user interface (GUI) or from the command-line
interface with the smcli movewpar command. You have to decide several things before
running the manual relocation:
On which managed system do you want to relocate your WPAR?
Does this managed system meet all the requirements to allow a relocation of your WPAR?
Do you want to use static or live relocation?
Before trying a manual relocation, check the compatibility between the source system and the
target system. This can be done from the WPAR Manager graphical interface with a right-click
on the WPAR and selecting Compatibility, as shown in Figure 8-2.
Figure 8-2 Checking the compatibility between managed systems
Tip: You can also use the command-line interface by running smcli lswparcompat -n
wpar_name.
413
Consider the following compatibility checks:

Managed systems must have the same level of operating system (technical level and
service pack).
The processors class on the arrival system must be at least as high as the processor class
on the departure system.
The bos.rte, bos.wpars, and mcr.rte file sets must be strictly on the same release on
both managed systems.
The bos.rte.libc file set must be the same on both managed systems.
Allocated and exported devices must be available on the target managed system and
must not be used by another WPAR.
Ensure that versioned WPARs meet all requirements that are mentioned in the section:
Versioned WPARs and Live Application Mobility.
You can also decide to add some criteria on the WPARs to avoid issues when running
relocation. These options can be edited in the WPARs properties. From the WPAR Manager
interface, right-click the WPAR and click Edit. Go to the Advanced settings tab and select
the Compatibility tab. You can then choose one of the following options, as shown in
Figure 8-3.
Figure 8-3 List of additional options that are available for relocation compatibility checks
8.4.3 Patches and upgrades

Patches allow you to keep your environment stable and to benefit from new features for your
environment. WPAR Manager should be kept up to date every time.
Patch WPAR Manager

Upgrade WPAR Manager each time a new release is available on the IBM website. Use the
IBM Systems Director release management feature to stay up to date.
Tip: If WPAR Manager is installed on AIX, do not hesitate to upgrade the operating system.
Patch WPAR Manager agent

It is not necessary to immediately patch the WPAR Manager agent after an upgrade of WPAR
Manager, but you should nevertheless try to stay up to date.
Patch managed systems and WPARs

For AIX maintenance, such as technical level and service packs, you must upgrade the
managed systems first before any WPARs.
414
Attention: AIX upgrades cannot be managed by WPAR Manager or IBM Systems Director.
You have to run the AIX upgrade directly from the managed system or from a Network
Installation Management (NIM) server.
Shared WPARs
When the managed system has been upgraded, synchronize the WPARs. This is necessary
to allow the WPARs to use the latest release of the AIX kernel.
Attention: This does not apply to versioned WPARs. The synchronize option is not
available for application WPARs.
The next example shows the difference between a classical LPAR architecture and a WPAR
architecture when upgrading the AIX, as shown in Table 8-2.
Table 8-2 AIX upgrade comparison between LPARs and WPARs
40 LPARs
40 WPARs on one LPAR
Number of AIX upgrades
40
Number of reboots
40
Time of maintenance
40 x X minutes (upgrade AIX)

+
40 x X minutes (reboot)
1 x X minutes (upgrade AIX)

1 x X minutes (reboot)
+
40 x X minutes (WPARs sync) No
reboot needed for the sync.
Tip: The synchronization step can be done from the WPAR Manager graphical interface or
by the command line with the smcli syncwpar command. This allows you to run only one
command to synchronize all WPARs.
Attention: The synchronization between managed systems and WPARs is not supported
for versioned WPARs, application WPARs, and undeployed WPARs.
RootVG WPARs
Because RootVG WPARs have their own /usr and /opt, they have to be upgraded like the
global instance.
Tip: While upgrading AIX on the managed systems, you can decide if you want to upgrade
WPARs in the same time with the smit install_all command.
For more information about patch and file set management for WPARs, read section 10.1 in
the IBM Redbooks publication, Exploiting IBM AIX Workload Partitions, SG24-7955.
8.4.4 Backup
Using the smcli savewpar command from IBM Systems Director can help you prepare scripts
to back up all your WPARs from a single command and in a single location.
415
All backups can be stored in an NFS mount point that will be secured by backup software
after the savewpar command has been run, as shown in Example 8-4.
Example 8-4 Back up all WPARs in directory /backup (NFS share mounted on all managed systems)
smcli lswpar |grep Active |awk '{print $5}' |while read hostname ; do smcli
savewpar -n $hostname -i -M -F /nfs/backup/$hostname.bff ; done
You can also use this mount point to restore the images.
8.5 Best practices

Listed in this section are the best practices for WPAR Manager:
If you want to use versioned WPARs, you must have IBM Power7 servers and AIX 7.1
servers as managed systems.
If you want to use versioned WPARs, ensure that you meet all technical requirements
defined in this chapter and ensure that you have acquired the necessary license
programs.
Relocation is possible only from the WPAR Manager graphical interface or from the IBM
Systems Director command-line interface.
Relocation is not possible on hardware that is not from the same processor family.
Relocation is not possible between managed systems that do not have the same
operating system version.
Before using automatic relocation, define relocation domain groups and relocation policies
on IBM Systems Director server.
If you want to use NFS shared WPARs with automatic relocation, configure a separate
NFS server and configure all managed systems to access it.
If you want to use SAN WPARs with automatic relocation, configure disks on all managed
systems that are in the relocation domain group.
If you choose to do a manual relocation, do a compatibility check before the relocation.
For easy deployment, create a clone from an existing WPAR and use it to create other
WPARs.
Define a backup policy and configure a central location where the backups will be stored.
Check the WPAR logs on managed systems when you have problems with WPARs.
Read Additional documentation to have all the information and technical how-to
documentation that you need.
8.6 Additional documentation

IBM Redbooks Exploiting IBM AIX Workload Partitions, SG24-7955:
IBM PowerVM Workload Partition Manager for AIX:
r.wparmgt.helps.doc%2Fwparlpp-kickoff.html
416
WPAR AIX 6.1 Information center:

http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.wpar/wparkickoff.htm
WPAR 7.1 information center:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.wpar/wparkickoff.htm
IBM developerWorks: WPAR in AIX 6.1:
http://www.ibm.com/developerworks/aix/library/au-wpar61aix
IBM developerWorks: WPAR in AIX 7.1:
http://www.ibm.com/developerworks/aix/library/au-wparaix7
IBM developerWorks: FC Adapter-based WPAR creation with Oracle database configuration:
http://www.ibm.com/developerworks/aix/library/au-fc_adapter_wpar
IBM developerWorks: Creation and relocation of system WPARs with SAN-based data model:
http://www.ibm.com/developerworks/aix/library/au-wpar_san
Creating a versioned WPAR information center:
http://pic.dhe.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.wpar%2Fc
reconfig-create-wpar.htm
417
418
Chapter 9.
Network Control
This chapter covers the basic functionalities of Network Control, how to plan for Network
Control deployments, and describes a number of common scenarios with best practices.
9.1, Overview of Network Control on page 420

9.2, Planning for Network Control on page 422
9.3, Discovering and managing virtual networks on page 424
9.4, Discovering and managing IBM Systems Networking switches on page 426
9.5, Discovering and managing the IBM Systems Networking 5000V on page 428
419
9.1 Overview of Network Control

IBM Systems Director Network Control is an optional and chargeable plug-in for IBM Systems
Director that extends the basic capabilities available in IBM Systems Director Network
Manager. Network Control is a network management tool that can help discover, configure,
and automate network components.
Note: Network Control is always included in the Flex System Manager (FSM) appliance
that is available in IBM Flex System and IBM PureFlex configurations.
Following are the basic functionalities of Network Control:
Physical and virtual network switches discovery and monitoring: It uses Simple Network
Management Protocol (SNMP) v1, v2, or v3 to get health status from switches. Events
generated can then be used in event action plans and forwarded to your event
management system.
Protocol and VLAN configuration of physical and virtual network devices: You can create
VLANs on discovered devices and assign those VLANs to specific ports. You can also
create port groups on virtual switches.
Depending on your Ethernet switch type, you might also be able to use Network Control to
configure Converged Enhanced Ethernet (CEE) networking and Edge Virtual Bridging
(EVB).
Network topology views for physical and virtual network devices: You can view systems by
subnets and VLANs, and you can generate graphical topology views that show how
switches are inter-connected and which physical and virtual servers are connected to
them. Figure 9-1 on page 421 shows an example of a discovered network topology view
that shows the inter-switch link (ISL) between two managed switches.
420
Figure 9-1 Example of a discovered network topology view
Figure 9-2 is an example of the Systems by VLAN and Subnet view.
Figure 9-2 Systems by VLAN and Subnet view
Chapter 9. Network Control
421
In context access to remote command and in context launch of third-party tools: You can
open a command prompt to any managed network device right from the IBM Systems
Director console, or you can choose to start a third-party management tool from that same
console.
Automation of physical and virtual network configuration with network system pools: You
can create network system pools to have Network Control automatically assign VLANs to
physical switch ports and reconfigure virtual switches as virtual workloads are moved from
one host to another. This is often used with VMControl to manage PowerVM,
Kernel-based Virtual Machine (KVM), and VMware environments.
Note: For more information about how to configure network system pools, see the
information center:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.sdnm.adv.helps
.doc/fnc0_t_network_ctrl_managing_nsps_and_lnps.html
For more information about Network Control, go to the IBM Systems Director Information
Center:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.sdnm.adv.helps.doc/f
nc0_p_network_ctrl.html
To find out what is new in IBM Systems Director Network Control Version 1.4, read the
following information center article:
nc0_r_whats_new_14.html
For a comparison of basic IBM Systems Director Network Manager versus Network Control,
see the following information center page:
nc0_r_sdnm_compare_overview.html
9.2 Planning for Network Control

Planning for Network Control is a critical step in the deployment process. Network Control can
discover and manage many different types of network devices, but each has different
capabilities.
You should not assume that because you can configure VLANs on a type of switch, you will
be able to do the same for all your network devices. Management capabilities are exposed to
Network Control by using vendor plug-ins that vary greatly in what functionalities they provide.
For a table of supported capabilities per switch device type, see the following information
center page:
nc0_r_network_ctrl_device_support.html
The tables that are shown at this information center sometimes aggregate some of the
management functionalities into categories. For example, it indicates if configuration
management is supported or not on the device, but it does not provide the details of which
type of configuration is supported (protocol, VLAN, or CEE configuration).
422
For each switch device type, IBM Systems Director Network Control has one or more specific
configuration templates. It is strongly recommended that you review those templates carefully
in order to determine if the product capabilities meet your requirements.
To access configuration templates and view what options are configurable for your device
type, follow these simple steps:
1. Access the System Configuration Configuration Templatesmenu and click Create,
Figure 9-3 The configuration template
2. Select Ethernet Switch from the Template type drop-down list, and select your device
type from the Configuration to create a template drop-down list, as shown in Figure 9-4.
Figure 9-4 Creating a configuration template
423
3. Finally, navigate through the available options for this specific type of configuration
template, as shown in Figure 9-5, and ensure that it has the settings that you require.
Figure 9-5 Examining the available options in a configuration template
When you have determined that the configuration settings that you need are supported by the
available templates, perform testing on your specific device types in order to confirm that all
requirements are met.
The information center does not clearly document all the requirements for each device type,
which is why it is important to test your network devices before implementing your network
using IBM Systems Director Network Manager and Network Control. For example, you might
discover that certain protocols such as Telnet and HTTP are required for device configuration
but are prohibited by your company security policy.
9.3 Discovering and managing virtual networks

Network Control can be used to manage networking in different virtual environments, such as
PowerVM, KVM, and VMware vSphere. For more information about how to manage PowerVM
and KVM environments using VMControl, Storage Control, and Network Control, refer to
Chapter 5, VMControl on page 247.
Network Control can also discover virtual switches in VMware vSphere environments.
VMware distributed virtual switches are not supported by Network Control. The only type of
distributed virtual switch that is supported is the IBM Systems Networking 5000V.
Whereas standard network switches are discovered using their management IP address,
VMware vSphere virtual switches do not have management IP addresses and must be
discovered by running an inventory on the vCenter Server.
424
To discover standard VMware vSphere virtual switches, perform the following steps:
1. Discover the vCenter Server operating system by using System Discovery and unlock
access to the discovered managed endpoint using credentials that have both local
administrative privileges on the operating system and privileged access to the vCenter
Server application instance.
2. Perform a full inventory of the vCenter Server. This automatically discovers all associated
ESXi physical hosts that are managed by the vCenter Server as well as virtual servers
managed by those hosts.
3. Perform a full inventory of those ESXi hosts. This discovers virtual switches.
4. You can then use the Inventory View Network Topologyview to see how virtual
machines are connected to the virtual network. For example, in Figure 9-6, you can see
how the virtual machine is connected to the host via the virtual switch, and what the
network interface MAC addresses are.
Figure 9-6 Example of a virtual network topology
After you successfully discover your virtual switches, you will also be able to deploy new port
groups by editing the current configuration of the virtual switch managed endpoint. To do so,
select the vSwitch in the Resource Explorer Groups All Network Systems view, then
select Actions System Configuration Current Configuration.
You can then click Virtual Switch Module VLAN Configuration and create a new VLAN.
Alternatively, if you want to create or remove multiple port groups on multiple vSwitches, you
can use configuration templates:
1. From the lBM Systems Director console left pane, select System Configuration
Configuration Templates.
2. Click Create to create a new configuration template.
425
3. Select Virtual Switch from the Template type drop-down list and select Virtual Switch
Module VLAN Configuration from the Configuration to create a template drop-down list.
4. Enter a name for the configuration template, such as My VLAN configuration.
5. Click Create.
6. To add a port group, leave the default Create a new VLAN configuration from the Select
a task drop-down list and enter a VLAN ID. To remove a port group, select Delete an
existing VLAN configuration from the Select a task drop-down list and enter the VLAN
ID of the port group that you want to remove.
7. Add or remove as many port groups as you want and save your configuration when you
are done. You can then click Deploy and select vSwitches as targets.
Note: When you create port groups using Network Control, they are automatically
named DirectorVLANID_vSwitch name. You cannot change that default naming
convention.
In addition, Network Control does not create the port group if another port group with
the same VLAN ID already exists, even if the names are different.
Finally, when you remove port groups, Network Control selects the port group that is
based on the VLAN ID, regardless of the name that it has.
This can be useful if you have many ESXi hosts and VLANs and you are using standard
virtual switches because the vSphere client graphical user interface does not let you deploy
port groups to multiple virtual switches in a single step. If your virtual infrastructure
administrators do not know Powershell, they can use Network Control to automate that task.
9.4 Discovering and managing IBM Systems Networking

switches
IBM Systems Networking switches are best discovered using a custom discovery profile and
using at least SNMP v2. When discovering this type of switch, consider the following factors:
1. The Telnet protocol might be required for configuration of your switch, including
configuration of the initial SNMP trap server address that occurs automatically after the
switch MEP has been fully unlocked. If you get a warning after discovery that the SNMP
trap address could not be configured, rediscover the switch after you enable Telnet.
2. Ensure that the switch is in ISCLI or prompt mode. You can use the boot cli-mode iscli
or boot cli-mode prompt ISCLI commands from a Secure Shell (SSH) prompt on your
switch.
3. Ensure that the switch can resolve the fully qualified domain name of the IBM Systems
Director server using DNS. This is because IBM Systems Director uses its fully qualified
domain name (FQDN) as the SNMP trap server address. You can use the show ip dns
ISCLI command to view the current DNS configuration on your switch, and the ISCLI ip
dns primary-address <ip address> and ip dns secondary-address <ip address> to
configure a primary and a secondary DNS server for name resolution.
4. Ensure that you have correctly configured the SNMP trap source on the switch or the IBM
Systems Director server might not receive events. Use the snmp-server trap-source 128
command to configure SNMP trap events to be sent over the management interface of the
switch.
426
5. If you are not receiving events in a format that is appropriate, load all the Management
Information Base (MIB) files available from the IBM Systems Networking image update
package compressed file, which you can get from IBM FixCentral. Go to Settings
Manage MIBs and manually import all RFC MIB files included in that package in
alphabetical order before you are able to successfully import the switch main MIB file. In
addition, you might have to edit the map file, which defines severity and event text based
on the SNMP trap OID. For more information about this topic, see the following information
center topic:
ctor.automation.helps.doc%2Ffqm0_c_ea_mapping_snmp_traps_events.html
Note: At the time of writing, the G8052 and G8264 MIB files could not be compiled and
loaded successfully in IBM Systems Director 6.3.2.1. Only the EN4093 MIB file could
be tested successfully.
The G8052 and G8264 files contain a syntax error in the dhcpSnoopingBindingInfoExpiry
section. To correct that error and successfully load the MIB files in IBM Systems Director,
open the MIB files in a text editor, search for dhcpSnoopingBindingInfoExpiry, and replace
the line, SYNTAX Counter32 with SYNTAX Unsigned32. Save the file and try to load it again in
6. Perform discovery on the SNMP write community, not the SNMP read community.
7. Always completely unlock the switch. If it remains in partial access, the SNMP trap server
address will not be configured and your IBM Systems Director server will not receive
SNMP events.
Note: A simple way to test if you are correctly receiving SNMP traps from your switches
is to simply log in and out of your switch using either the web user interface (also known
as the BBI), Telnet, or SSH. Those events should generate traps of Unknown or
Information severity on your IBM Systems Director server.
When the switches have been discovered and inventoried, perform the following tasks:
1. Configure additional SNMP trap server addresses using the protocol configuration
template: Go to Resource Explorer Groups All Network Systems, select your
switch and then select Actions System Configuration Current Configuration and
finally, select the Protocol Configuration template.
2. Create VLANs and assign VLANs to switch ports using the VLAN configuration template:
Go to Resource Explorer Groups All Network Systems, select your switch and
then select Actions System Configuration Current Configuration and finally,
select the VLAN Configuration template.
3. Create and deploy CEE networking and EVB configurations: Go to System
Configuration Configuration Templates and create a new template of type, Ethernet
Switch. Then, select CEE Configuration for <your switch type> or EVB Configuration
for <your switch type>.
4. Start a remote command line on the switch: Go to Resource Explorer Groups All
Network Systems, select your switch, and then select Actions Remote Access
Remote Command Line.
5. View a network topology for your switch: Go to Resource Explorer Groups All
Network Systems, select your switch, and then select Actions Topology
Perspectives Network. Then, select either the Basic, Port-level, Subnet, or
System-level view.
427
Note: For more advanced management about capabilities of IBM Systems Networking
switches, consider using the IBM Systems Networking Switch Center product.
Switch Center replaces what was formerly known as IBM Systems Networking Element
Manager (SNEM).
For more information about the IBM System Networking Switch Center, go to the following
website:
http://www-03.ibm.com/systems/networking/software/snsc/index.html
You can also find the IBM System Networking Switch Center 7.1.1 User Guide here:
http://www-01.ibm.com/support/docview.wss?uid=isg3T7000624
9.5 Discovering and managing the IBM Systems Networking

5000V
Unlike traditional virtual switches, you must discover the IBM System Networking Distributed
Virtual Switch 5000V directly by using its management IP address and a custom discovery
profile, as documented in the information center:
qm0_t_network_ctrl_distributed_virtual_switches_discover.html
If you have not yet discovered the VMware vCenter server that is connected to the 5000V, the
operating system MEP for the vCenter Server will be automatically added to the IBM Systems
Director inventory when inventory is collected on the 5000V MEP. Unlock the vCenter Server
operating system MEP and collect inventory from it to enable all management functionalities
of the 5000V from Network Control.
Note: Enabling the Telnet protocol is not required for the 5000V.
Basic management capability is limited to receiving SNMP events, viewing network topology
views (as shown in Figure 9-7 on page 429), and accessing the remote command line on the
5000V.
428
Figure 9-7 Network topology view for the 5000V
The VLAN and EVB configuration of the 5000V by using Network Control is not supported.
In order to receive events from your 5000V, perform the following tasks:
1. Manually configure the SNMP system name on your 5000V by using the snmp-server
name command in the configuration menu.
2. Manually configure the SNMP manager target address (your IBM Systems Director server
address) by using the snmp-server target-address <a number> address <ip address
of your IBM Systems Director server> name <a name for this entry> command.
3. Manually upload the iswitch.mib file that is provided with the 5000V into your IBM
Systems Director server by going to Settings Manage MIBs.
Example 9-1 shows the list of SNMP events that are defined in the iswitch.mib MIB file.
Example 9-1 List of SNMP events that are defined in iswitch.mib
VM disconnect
VM connect
create vnic profile
delete vnic profile
add ports to vnic profile
delete ports from vnic profile
change pvid settings of vnic profile
change tagging settings of vnic profile
change tagpvid settings of vnic profile
429
change designated-uplinks settings of vnic profile

change vepa settings of vnic profile
change dps settings of vnic profile
add vlans to vnic profile
remove vlans from vnic profile
change vsi settings of vnic profile
change dot1p settings of vnic profille
add RX ACL for vnic profile
remove RX ACL from vnic profile
change RX/TX policy map settings of vnic profile
change RX/TX rate limit settings of vnic profile
Note: At the time of writing, the iswitch.mib file did not enable IBM Systems Director
version 6.3.2.1 to interpret all SNMP events from the 5000V correctly. As a result, some
events were coming in to the server with a severity of type, unknown.
This is due to missing entries in the BNTTraps.map. You can learn how to customize the
map file in the information center:
ctor.automation.helps.doc%2Ffqm0_c_ea_mapping_snmp_traps_events.html
If you want to configure 802.1Qbg (also known as EVB) and you are planning on using your
IBM Systems Director server as the VSI manager (aka the VSI database), configure the VSI
manager IP address on your 5000V manually by using the iswitch myvsidb <ip address of
your IBM Systems Director server> command.
For more information about how to use your IBM Systems Director server as a VSI manager,
read the following information center document:
nc0_r_learnmore_VSI_config.html
For more information about how to configure 802.1Qbg, see the following IBM Redbooks
publication:
http://www.redbooks.ibm.com/abstracts/sg247985.html?Open
Note: IBM Systems Director 6.3.3 with Network Control 1.4.1 also enables EVB support
for Flex Power compute nodes that are managed by an FSMl.
With IBM Systems Director 6.3.2, you can use the IBM Systems Director server as a VSI
manager to enable EVB support for KVM environments. You can then create Logical
Network Profiles (LNPs), which use the VSI manager ID, VSI type ID, and VSI type version
that is specified in your VSI database and assign those LNPs to your network system
pools.
430
9.6 Best practices

When implementing your network using IBM Systems Director Network Manager and
Network Control, keep the following best practices in mind:
Carefully plan your Network Control deployment by ensuring that your network devices
are supported and that available configuration templates include the options that you
require.
Always test Network Control discovery and management on your specific network device
type before deployment in order to ensure that device requirements can be met.
Use custom discovery profiles so that you can use non-default SNMP community names.
Fully unlock access to your network device managed endpoints, or the SNMP trap server
address will not be automatically configured and your devices will not be correctly
monitored.
Ensure that your network devices can resolve the IBM Systems Director server fully
qualified domain name.
Import MIB files for all your network devices when the default system behavior does not
meet your monitoring requirements. In addition, edit the map file to handle event text and
severity appropriately.
Always inventory your network devices after discovering them or topology views might be
inaccurate.
For configuration management, your IBM Systems Networking switches will need to be
configured in ISCLI mode.
Use configuration templates to deploy or remove multiple port groups to multiple VMware
vSphere virtual switches.
Consider using EVB in the Logical Network Profiles of your network system pools in
VMControl because this is the emerging standard for automated network configuration.
431
432
10
Chapter 10.
Service and Support Manager

This chapter provides information about the IBM Systems Director Service and Support
Manager (SSM). It describes how the Service and Support Manager must be set up and how
it handles serviceable events.
10.1, Service and Support Manager on page 434

10.2, Launch Service and Support Manager on page 437
10.3, Connectivity to IBM on page 445
10.4, Enabling systems for service and support on page 446
10.5, Serviceable event processing on page 447
10.6, Managing support files on page 448
433
10.1 Service and Support Manager

IBM Systems Director Service and Support Manager (SSM) manages serviceable problems
and reports the events to IBM. A serviceable problem is a problem to which IBM service
typically responds, such as a failure of a hardware component that is under warranty.
IBM Systems Director Service and Support Manager is documented in the information center:
http://publib.boulder.ibm.com/infocenter/director/pubs/topic/com.ibm.esa.director.
help/esa_kickoff.html
Service and Support Manager is viewed as an advanced manager within Systems Director,
although it is installed with the base Systems Director server installation. The core objective
of Service and Support Manager is to work with service information:
Supported systems monitoring

Serviceable event processing
Support file management
CLI support
Collection of performance management data to send to IBM
Service and Support Manager support different system types in the environment. See
Figure 10-1 on page 435. Following are the different system types:
In-band communication:
Windows on x86 systems
Linux on x86 system
BladeCenter servers (no JS and QS blades)
AIX and Linux on IBM Power Systems with Common Agent installed (not managed by
Integrated Virtualization Manager (IVM) or Hardware Management Console (HMC))
IBM i partition on Power Systems managed by HMC
IBM Flex System V7000 Storage Node
Out-of-band communication:
Integrated management module (IMM and IMM v2)
Remote Supervisor Adapter (RSA and RSA II) and baseboard management controller
(BMC)
434
Figure 10-1 shows systems that are supported by SSM.
Figure 10-1 Systems supported by Service and Support Manager
A complete list of systems and resources that are eligible for monitoring by Service and
Support Manager are listed in the information center:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp?topic=%2Fcom.ibm.esa.dir
ector.help%2Fesa_eligibility.html
To enable a system for the Service and Support Manager, complete the following steps:
System must be discovered and unlocked
A full inventory of the system must be collected
After finishing the inventory collection and when the Service and Support Manager is
configured, the monitoring of the systems begins automatically. You can check if a system is
eligible by right-clicking the system and selecting Service and Support Check Eligibility.
When eligible for the Service and Support Manager, it is automatically added to the Group
Service and Support Groups Monitored Systems group. Systems that are not eligible
for the Service and Support Manager can be found in the Excluded Systems group.
Systems where the IBM Systems Director has no access or the access state in unknown can
be found in the Unknown Systems group.
Chapter 10. Service and Support Manager
435
Service and Support Manager subscribes to Systems Director events and filters out
unserviceable events. When a serviceable event is received by Service and Support
Manager, it submits a service request for the applicable event to IBM. Service and Support
Manager runs data collectors on managed endpoints by using the snap command for AIX and
Linux on Power Systems. Service and Support Manager runs data collectors on managed
endpoints by using Dynamic System Analysis (DSA) for Linux and Windows on IBM x86
systems.
The following data will be collected by the different systems and tools:
System x
Dynamic Systems Analysis (DSA)
SSM uses DSA to collect data from System x endpoints. SSM remotely uploads the
DSA tool to the endpoint system. DSA creates a compressed XML report, which will be
sent back to the SSM. This file will be submitted to IBM for the serviceable problem.
DSA collects the following data:
System configuration
Installed packages
Kernel modules
Network interface and settings
Performance data and details for running processes
Hardware inventory information
IBM Lightpad status
Service processor status and configuration
Vital product data (VPD) data, firmware, and basic input/output system (BIOS)
information
ServeRAID and LSI Redundant Array of Independent Disks (RAID) configuration
Event logs from operating system, RAID controller, and service processors
sosreport
System x systems that are running RedHat Enterprise Linux with sosreport version 1.7
or newer are eligible for sosdata collection. SSM runs the /usr/sbin/sosreport
command and creates a compressed tar file. The IBM Electronic Service Agent
(ESA) transmits this file and sosreport to the SSM.
IMM service log
The IMM service log contains service information that is collected by the IMM service
processor. These files are collected from x86 ITE within a Flex Enterprise Chassis and
from System x systems that have an IMM v2 service processor.
IBM BladeCenter chassis
Service log
Collects data from the BladeCenter chassis by collection service information from the
AMM and stores this data in a support file
AIX and Linux on Power Systems
snap
SSM uses the snap command to collect system data on AIX and Linux on Power
Systems. The snap command gathers system configuration information and
compresses this information into a pax file. This file is sent to IBM support.
436
Detailed information about the snap command can be found at the following link:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.i
bm.aix.cmds/doc/aixcmds5/snap.htm
sos report
Linux on Power Systems that are running RedHat Enterprise Linux with sosreport
version 1.7 or newer are eligible for sosdata collection. SSM runs the
/usr/sbin/sosreport command and creates a compressed tar file. The ESA transmits
this file as a report file to the SSM.
IBM i partition on a Power System managed by HMC
APAR Library
Authorized program analysis report (APAR) data is saved in a unique APAR library. The
aparlib command collects partition local problem error data in the APAR library.
When automatically collected, the default options collect primary APAR save files and
manifest files from the IBM i partition. Additional collection is available by manual
collection.
IBM Flex Enterprise Chassis
SSM collects several different types of data from monitored x86 compute nodes, IBM Flex
System V7000 Storage Nodes, and from the IBM Flex Enterprise Chassis itself.
CMM service log
The CMM service log contains service information from the CMM
IMM service log
Contains information that is collected from IMM on x86 compute nodes within a Flex
Enterprise Chassis
SVC snap
Collects storage data from an eligible IBM Flex System V7000 Storage Node
10.2 Launch Service and Support Manager

To launch Service and Support Manager from the Systems Director home page, click
Plug-ins and scroll down to Service and Support Manager.
437
Before starting the Service and Support Manager the first time, it needs to be configured. To
configure the Service and Support Manager, click Getting Started with Electronic Service
Agent (see Figure 10-2).
Figure 10-2 Service and Support Manager
A wizard opens. Put in the necessary data and information and then test the connectivity.
438
This necessary data includes the contact data (see Figure 10-3). The minimum required data
is marked with an asterisk. After finishing the setup wizard, you can add additional contacts
for using IBM Systems Director Service and Support Manager.
Figure 10-3 Configure Service and Support manager: Contact data
439
On the next page, put in the location for your systems. If there are different locations, put in
data for the main location. Also, the minimum required data is marked with an asterisk (see
Figure 10-4).
Figure 10-4 Configure Service and Support manager: System location
440
On the next page, you can configure the Internet connection. To run and automatically create
hardware calls at IBM, an Internet connection is necessary. Figure 10-5 shows the two
possible methods:
Direct Internet connection
Connection over an HTTP proxy
Select the method that fits best for your environment.
Figure 10-5 Configure Service and Support Manager: Internet connection
441
On the next page, you can put in the IBM ID. Providing your IBM ID enables you to access the
service information that is transmitted to IBM. See Figure 10-6.
Figure 10-6 Configure Service and Support Manager: IBM ID
At the end, you see a summary page with all the information and data that you submitted.
Click Finish and the data is saved.
After you enter the required information, the Service and Support Manager is ready, as shown
in Figure 10-7.
Figure 10-7 Service and Support Manager: Status
442
The Service and Support Manager creates default groups within Systems Director. The
groups are under Resource Explorer Groups Service and Support Groups, as
shown in Figure 10-8. The groups are dynamic and automatically populated.
Figure 10-8 Service and Support Manager groups
When the Service and Support manager is configured, you see additional links at the bottom
of the page:
Manage settings
Manage your system contacts
Getting started with Electronic Service Agent (which reopens the configuration wizard)
When you select Manage your system contacts, a new window opens where you can see
the actual defined contacts. You can also put in new contacts and assign systems to each of
the contacts. Select which contact will be the default (this is the person that will be contacted
by IBM Service in case of an event. See Figure 10-9.
Figure 10-9 Managing your system contacts
443
When selecting Manage Settings, a window opens where you can perform the following
functions:
Set or change the IBM ID (like in the setup wizard before)
Test the connectivity (like in the setup wizard before)
Enable or disable the problem reporting and define settings for the reporting
(Figure 10-10)
Figure 10-10 Service Agent settings
Define the cache settings for the support files (default is 500 MB), the lifetime for the
support files (default is seven days), and the support file collector application settings
(Figure 10-11 on page 445).
444
Figure 10-11 Support file settings
10.3 Connectivity to IBM

For the Service and Support Manager to function, enable connectivity through your firewall to
IBM. The addresses and ports that are used are listed in Table 10-1.
Table 10-1 SSM proxy
Host name
IP address
Port
www6.software.ibm.com
207.25.253.41
443
192.109.81.20
443
download2.boulder.ibm.com
207.25.253.8
80
download3.boulder.ibm.com
207.25.253.76
80
eccgw01.boulder.ibm.com
207.25.252.197
443
eccgw02.rochester.ibm.com
129.42.160.51
443
445
Host name
IP address
Port
www-945.ibm.com
129.42.26.224
129.42.34.224
129.42.42.224
443
www.ibm.com
129.42.56.216
129.42.58.216
129.42.60.216
443 or 80
www-03.ibm.com
204.146.30.17
80
If you encounter problems, see the following information center link:

http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.tbs.helps.d
oc/fqm0_r_tbs_um_proxy_issues.html
10.4 Enabling systems for service and support

Perform the following tasks to enable a system for monitoring:
The system is discovered.
The system is unlocked.
An inventory is collected.
After the tasks are complete, check whether the ESA agent is running on your endpoints. For
guidance, see the following information center page:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.esa.director.help/es
a_problem_optimize.html
To enable reporting to IBM, follow the steps in the following information center page:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.esa.director.help/es
a_enable_disable_problem.html
To check the functionality, send a test problem by using the Send test problem link in the
Common Tasks section, as shown in Figure 10-12. This should be done only if there might be
a problem with sending events to IBM and when recommended by IBM service personal.
Also, this sends a test problem and will create a hardware call at IBM.
Figure 10-12 Electronic Service Agent Status panel
446
A reminder appears that advises you that this action sends an actual report to IBM support
(Figure 10-13).
Figure 10-13 Send test problem confirmation
After you click OK, the test problem report is submitted to IBM support. This report is visible
under the dashboard and the Problem Reporting view (Figure 10-14).
Figure 10-14 Service and Support Manager: Problem Reporting view
10.5 Serviceable event processing

Serviceable event processing is the management and transmission of serviceable events for
hardware problems to IBM.
Serviceable events are determined by IBM and cannot be altered. The analysis component of
Service and Support Manager determines whether the event warrants the creation of a
serviceable event. Serviceable events are viewable in the Service and Support Manager
plug-in, as shown in Figure 10-14.
447
If an event is serviceable and the Service and Support Manager is fully configured, the
service request is transferred automatically to IBM unless otherwise configured.
Duplicate event processing is supported. Any duplicate event that is generated within a
24-hour window does not generate a new ticket with IBM.
10.6 Managing support files

After the problem is submitted to IBM support, additional data that is associated with the
problem can be uploaded to IBM to help diagnose the problem. The data includes detailed
system information, dump files, and event logs.
Take the following steps to view the support files and then submit them to IBM:
1. Under Common Tasks in the Service and Support Manager home page (Figure 10-2 on
page 438), select Manage Support Files. The window that is shown in Figure 10-15
opens.
Figure 10-15 Manage Support Files panel
2. When you collect support files, select the monitored system where you want to collect the
support files and click Collect Support Files. Use the predefined groups that are listed in
448
3. Choose the target system as shown in Figure 10-16.
Figure 10-16 Monitored systems
449
4. As shown in Figure 10-17, click the Support Files tab to select the support files.
5. Figure 10-17 displays the types of support files to collect. Select the required option and
click Collect.
Figure 10-17 Collect Support Files panel
6. On the window that is shown in Figure 10-18, you can select the support files to send to
IBM. After submission, you can delete files manually. However, Service and Support
Manager removes support files after seven days after the successful file transmission of
data to IBM.
Figure 10-18 Snap files
10.7 Best practices

To use the Service and Support Manager, apply the following best practices:
Enable Service and Support Manager by clicking Getting Started with Electronic
Service Agent and completing the necessary information.
Test connectivity to the Internet to ensure that the Service and Support Manager can send
events to IBM.
Prepare your systems: Discover, unlock, and run inventory on your systems.
450
11
Chapter 11.
Storage Management solutions

and Storage Control
This chapter describes the storage monitoring and management capabilities that are offered
by IBM Systems Director server along with best practices.
11.1, Storage management solutions in IBM Systems Director on page 452
11.2, Base edition: IBM Systems Director Storage Manager on page 457
11.3, Advanced edition: IBM Systems Director Storage Control on page 469
451
11.1 Storage management solutions in IBM Systems Director

IBM Systems Director supports monitoring and management (includes storage volume
creation/deletion, zone creation/deletion, logical volume management) of a wide variety of
storage devices, including disks, switches, internal Redundant Array of Independent Disks
(RAID) controllers, and storage subsystems.
The IBM Systems Director portfolio offers storage monitoring and management capabilities in
two editions:
Base edition: IBM Systems Director Storage Manager, which is part of IBM Systems
Director base edition.
Advanced edition: IBM Systems Director Storage Control, which is an advanced paid
plug-in of IBM Systems Director base edition. It comes with a 90-day trial license for users
to evaluate the features.
This section explains both of the storage management editions, including introduction,
support, and configuration, along with best practice tips for the supported tasks.
11.1.1 Terms to know

Before starting to read about IBM Systems Director storage management, it is important that
you familiarize yourself with some of the storage terminologies that are used by IBM Systems
Director:
Storage volume
A storage volume is the basic unit of storage, such as allocated space on a disk, or a
single tape cartridge. Logical unit number (LUN) can be considered as a synonym to the
term, storage volume.
Storage pool
A storage pool is a collection of storage volumes. Array can be considered as a synonym
to the term, storage pool.
SMI-S provider
An SMI-S provider is a vendor-specific module that is used so that independent
management software, such as IBM Systems Director, can manage a vendor device by
using a standard interface that is based on the Common Information Model (CIM) protocol.
11.1.2 Storage device support and management

IBM Systems Director offers monitoring and management of the following storage types:
Dedicated Local Storage, which is accessed with Integrated RAID Controllers (IRC).
IBM BladeCenter integrated storage, which is accessed by using IBM BladeCenter S SAS
RAID Controller Modules.
Network storage, which is an external storage system that is accessed with storage
switches, adapters, and protocols such as Fibre Channel, serial-attached SCSI (SAS), or
Internet Small Computer System Interface (iSCSI).
452
The diagram that is shown in Figure 11-1 depicts the required and optional components that
are involved in managing the storage devices from IBM Systems Director.
Tivol i P roductiv ity

Cen ter (TPC)
TPC API
I BM Syste ms Director Base
Storage M anager
IBM S ystems Director

Storage Control
advanced pl ug-i n
En tr y l evel and mi d range

network storage
En terpri se class networ k storage
SVC
IB M DS8K series
IB M St orage DS3512 and DS3524
IB M XI V
IB M St orwize v7K and v3K serie s
EMC s torage
HDS storage
Brocade 8 GB FC switch (st and alone)
Brocade 16-GB (Chassis-mount ed)
IB M Syst em St orage DS4K series

IB M Syst em St orage N s eries: N3600 and
N3700
Brocade 2-GB or 4-GB (Chassis-mounted
or stand-alone) FC s witch
Qlogic 4-GB or 8-GB FC switch
IBM Bl adeCen ter S

in tegrated storage
IB M B ladeCenter S
IBM Systems Direct or

Management path
M anaged system s
l ocal stor age
Legacy RAID Cont roller
Basic RAID Controller
Advanced RAID Controller
Opt ional management

pat h
Figure 11-1 IBM Systems Director storage device management
As shown in Figure 11-1, there are a few storage devices that are supported for management
via IBM Systems Director Storage Manager, whereas some other storage devices require
either the IBM Systems Director Storage Control or the IBM Tivoli Storage Productivity
Center.
You can choose to use the optional management path that is shown in Figure 11-1 if your
environment already has the IBM Tivoli Storage Productivity Center installed. In this case, the
IBM Systems Director communicates with Tivoli Storage Productivity Center by using Tivoli
Storage Productivity Center application programming interfaces (APIs) to monitor and
manage the enterprise class network storage and Fibre Channel (FC) switches. IBM Systems
Director can integrate with Tivoli Storage Productivity Center basic edition 4.1 or later
releases.
Best Practice: Although integration with IBM Tivoli Productivity Center version 4.1 or later
is supported, to get the additional storage device management support, it is recommended
to upgrade IBM Tivoli Productivity Center to at least version 4.2.2 FP1+ before integrating it
with the IBM Systems Director.
How does communication with storage devices happen?

IBM Systems Director storage manager and Storage Control plug-in communicates to the
managed storage devices using the Storage Management Initiative Specification (SMI-S)
protocol.
Chapter 11. Storage Management solutions and Storage Control
453
Note: Storage Management Initiative Specification is a storage standard developed and

maintained by the Storage Networking Industry Association (SNIA). For more information,
see the following website:
http://www.snia.org/tech_activities/standards/curr_standards/smi
Following are types of SMI-S providers with which the IBM Systems Director Storage
Manager or Storage Control communicates for monitoring and managing the end-storage
devices:
External SMI-S providers, which are vendor-provided.
Native SMI-S providers, which are built into the storage subsystems.
IBM Systems Director Platform Agent: Has native interfaces to monitor and manage the
local storage on the IBM System x servers.
Which storage devices are supported?

Table 11-1 depicts the list of supported storage devices by IBM Systems Director 6.3.2 along
with the required providers and the management components.
Table 11-1 IBM Systems Director v6.3.2 storage support matrix
Hardware type
Model
SMI-S provider
component
IBM Systems Director storage

management component
required
Integrated RAID
Controller (IRC)
attached to System x
LSI IRC 1064/1064e/1068/1078
00.32.05.xx/SMI-S
1.2 IBM Systems
Director Platform
Agent 6.3.2

Manager
LSI IRC 2208

LSI IRC M5014/ M5015/M5025
LSI IRC M5110
Adaptec ServeRAID 4/5/6/7/8/9
IBM BladeCenter S
SAS RAID Controller
454
RSSM (System x)
7.89, SMI-S 1.1 IBM

Systems Director
Platform Agent
6.3.0/6.3.1
FC Switch
QLogic 4-GB
QLogic SMI-S 1.1

[embedded]
QLogic 8-GB
IBM Flex System Fabric CN4093
10-GB Converged Scalable
Switch
IBM SMI-S 1.1

[embedded]
Brocade 2-GB or 4-GB

(Chassis-mounted or
stand-alone)
Brocade 120.10.0
(SMI-S 1.2)
Brocade 8-GB (stand-alone)
Brocade SMI Agent

120.11.0
or
Brocade Network
Advisor 11.1.x (with
Integrated SMI Agent)

Control
DS3300, DS3400, DS4100,

DS4200, DS4300, DS4400,
DS4500, DS4700, DS4800,
DS5020, DS5100, and DS5300
Eagle 10.19.GG.xx,
SMI-S 1.4

Manager
DS3512, DS3524
Native

Control
Brocade 16-GB
(Chassis-mounted)
NetApp Storage
IBM Storage
DS8300, 8700, SAN Volume

Controller 4.3 and 5.1
DS8300; SAN Volume Controller
6.1, 6.2, and 6.3; IBM Storwize
V7000
DS8300; SAN Volume Controller
6.1, 6.2, and 6.3; IBM Flex
System V7000 Storage Node,
IBM Storwize V7000
Storwize V3700 and Storwize
V3500
IBM XIV 2810-A14, 2812-A14
IBM XIV Gen 3 2810-114,
2812-114
NAS storage
N-series (N3600 or N3700) - NFS

only
NetApp 3.0.2 SMI-S

1.2

Manager
EMC storage
CLARiiON AX Series, AX4

Series, CX Series, CX3 Series,
CX4 Series, Symmetrix DMX
Series, and V-Max Series3
EMC SMI-S Provider

v4.2.0/Solutions
Enabler v7.2-1108 0.0

Control
455
Hitachi Data Systems
Various models mentioned at the

following link:
http://www-304.ibm.com/suppor
t/docview.wss?rs=0&uid=swg270
19305#hds
Hitachi Device
Manager 7.0
For more information about where to install the required SMI-S providers, details about
supported firmware versions, and restrictions that apply on storage management functionality
as of IBM Systems Director Version 6.3.2, see the following site:
r.plan.helps.doc%2Ffqm0_r_hardware_compatibility_storage_devices.html
Interoperation with IBM Systems Director VMControl plug-in

IBM Systems Director VMControl is an advanced plug-in to IBM Systems Director, which is
responsible for virtualization management including virtual machine lifecycle management,
OS deployment, and server and storage pool management. For more information about
VMControl, see Chapter 5, VMControl on page 247.
IBM Systems Director VMControl communicates with IBM Storage Manager or IBM Storage
Control, depending on the storage device that is involved, for serving the operations involving
creation and assignment of storage volumes from the network storage devices to the virtual
machines. Following are the operations that need VMControl interactions with the Storage
Manager or Storage Control plug-in:
Creation and deletion of storage volumes in the network storage for virtual server
deployments
Creation and deletion of zones on the Fibre Channel switch for N-Port ID Virtualization
(NPIV)-based virtual server deployments
Best Practice: Before performing any operations that involve dealing with assignment of
new and existing volumes on the supported network storage using IBM Systems Director
VMControl, ensure that IBM Systems Director Storage Manager or Storage Control is
configured with the necessary providers (in Table 11-1 on page 454) to communicate with
the network and storage devices involved.
IBM Systems Director VMControl supports an environment with NPIV on only Power Systems
servers and only the following storage devices:
456
SAN Volume Controller

IBM Storwize V7000, Storwize V3700, and Storwize V3500
IBM Flex System V7000 Storage Node
Brocade switches:
Brocade 4-GB FC storage switches (chassis-mounted or stand-alone)
Brocade 8-GB FC storage switches (stand-alone)
Brocade 16-GB FC storage switches (chassis-mounted)
Table 11-2 shows the task that is supported by IBM Systems Director Storage Control
working with IBM Systems Director VMControl plug-in.
Table 11-2 Storage volume allocation to the virtual servers by the Storage Control plug-in
Hypervisor platform
Operation
Supported by VMControl
Express Edition
Supported by VMControl
Standard or Enterprise
Edition
PowerVM and RHEL

Kernel-based Virtual
Machine (KVM)
Server to Storage Mapping

view
Yes
Yes
Allocate new storage

volume to the host server
Yes
Yes
Allocate storage disks while

deploying virtual servers
from IBM Systems Director
server
No
Yes
Creating and working with

Server System Pools and
Storage System Pools
No
Yes
Create new virtual servers

with:
New and existing SAN
disks with NPIV
New and existing
vSCSI-based VIOS
local and SAN disks
Yes
Yes
Edit virtual server and add:

New and existing SAN
disks with NPIV
New and existing
vSCSI-based VIOS
local and SAN disks
Yes
Yes
Create new virtual servers

with new and existing SAN
disks
Yes
Yes
Edit existing virtual servers

and add new and existing
SAN disks
Yes
Yes
PowerVM
Red Hat KVM
11.2 Base edition: IBM Systems Director Storage Manager

IBM Systems Director Storage Manager is part of the base IBM Systems Director server.
There is no need for a separate installation of Storage Manager. This section describes the
basic needs and best practices to be followed when using IBM Systems Director Storage
Manager.
IBM Systems Director Storage Manager communicates to providers that are external to the
IBM Systems Director server to manage the storage devices.
457
Following are the two components to which the Systems Director Storage Manager
communicates to monitor and manage the storage devices:
IBM Systems Director Platform Agent: To manage internal storage of the managed
systems.
Note: IBM Systems Director Platform Agent is also included as part of the
IBM Systems Director Common Agent package.
The SMI-S Provider Agent, which is released by the supported storage vendors: To
monitor and manage the specific storage devices. This management software has many
different names: SMI-S CIM provider, storage proxy, storage provider, or storage agent. It
might also be referred to as the provider or agent as well. In this book, we refer to this
software as SMI-S Provider Agent.
If your environment does not have any of the enterprise storage devices that you are planning
to monitor and manage by using IBM Systems Director server, IBM Systems Director Storage
Manager, working with SMI-S providers, can serve the need of monitoring and management
of the existing storage devices.
11.2.1 Planning for storage management

To manage most storage systems with IBM Systems Director, you need to install an SMI-S
provider released by the respective storage device vendor. This is required for all storage
systems except IBM DS8000, XIV, SAN Volume Controller, and V7000 storage systems,
which can be managed directly.
If your storage system requires an SMI-S Provider Agent, print Table 11-3 and complete the
information and then use it when installing the SMI-S Provider Agent.
Table 11-3 Information to gather before installing an SMI-S Provider Agent
Information needed
Operating systems that the SMI-S CIM provider can run on,
such as AIX or Windows
Review the storage system product information to determine
this.
Server that is running the supported operating system
For example, this would be the server that has supported an
operating system for SMI-S Provider Agent installation.
Ports for the SMI-S Provider Agent to use
Determine whether the default CIM ports are in use. The default
ports are 5988 (HTTP) and 5989 (HTTPS).
If the default ports are available, use default ports

when installing the SMI-S Provider Agent.
If the default ports are not available, use non-default
ports when you install the SMI-S Provider Agent. A
common practice is to add 1000 to the port numbers.
For example, you could specify ports 6988 (HTTP)
and 6989 (HTTPS).
458
Your information
11.2.2 SMI-S provider installation and configuration

For communicating with certain storage devices, IBM Systems Director Storage Manager
needs an SMI-S provider. Table 11-1 on page 454 provides information about the storage
devices and SMI-S provider version that is needed for IBM Systems Director Storage
Manager.
Figure 11-2 shows the SMI-S Provider Agent connectivity to IBM Systems Director server.
Figure 11-2 SMI-S provider connection illustration
For detailed information about where to download and how to configure these providers for
IBM Systems Director V6.3.2, see the following site:
r.storage.helps.doc%2Ffqm0_t_sm_managing_smis_providers.html
Following are some of the main best practices to be followed when using the storage
providers in your environment:
Choose a system other than IBM Systems Director server or a systems hosting platform
agent for installation of the SMI-S provider.
Try to avoid installing more than one SMI-S provider on the same system. If there is a
need to install more than one provider on the same server, ensure that the ports on which
the provider agent CIM server listens are unique.
Uninstalling some of the SMI-S providers does not remove the CIM component. If the
system chosen for SMI-S provider installation was hosting any other SMI-S providers
previously, ensure that the CIM components are removed completely before going ahead
with a new installation of an SMI-S provider.
There is no hard limit on how many storage systems can be supported by a single provider
instance. The recommended maximum is 10 storage systems per provider.
After SMI-S provider installation, ensure that both CIM object manager (CIMOM) and
Service Location Protocol (SLP) services are active:
On AIX/Linux, run the following command to verify the status of CIM and SLP services:
ps -ef | grep cim --> look for cimserver and provider processes
ps-ef | grep slp --> look for slp related processes
On Microsoft Windows, look at Services to determine the CIM server and SLP
service status.
459
If you are reinstalling any SMI-S provider, it is recommended that you copy files that
contain the IP addresses of the systems under management and the ports that are in use
to a safe location.
11.2.3 IBM Systems Director Platform Agent installation

IBM Systems Director Storage Manager can monitor and manage the following devices by
communicating to the IBM Systems Director Platform Agent on the managed endpoint:
Integrated RAID Controller (IRC) attached to a System x system
IBM BladeCenter S SAS RAID Controller: RSSM (System x)
For more information about the IBM Systems Director v6.3.2 supported IRC cards and the
operating systems on which the platform agent installation is required, see the following
information center link:
r.plan.helps.doc%2Ffqm0_r_hardware_compatibility_storage_devices.html
Information on installing IBM Systems Director Platform Agent can be found at the following
information center link:
r.install.helps.doc%2Ffqm0_t_installing_platform_agent.html
Following are some of the best practices to be followed while installing and using IBM
Systems Director Platform Agent:
1. Ensure that the system clocks on systems that contain IBM Systems Director server and
Platform Agent remain synchronized.
2. On the system, where the agent installation is planned, run the IBM Systems Director
pre-Installation utility to ensure that your system meets all the applicable requirements. If
not, take appropriate actions to meet the requirements before proceeding with the
installation.
For instructions to run Pre-Installation Utility on Windows, see the following link:
ctor.install.helps.doc%2Ffqm0_t_running_piu_win_agents.html
For instructions to run Pre-Installation Utility on Linux, see the following link:
ctor.install.helps.doc%2Ffqm0_t_running_piu_aix_agents.html
3. If you are installing IBM Systems Director Platform Agent on a Linux system, ensure that
the Linux system has all prerequisite RPMs. See the following link to get the list of all
prerequisite RPMs:
ctor.install.helps.doc%2Ffqm0_t_preparing_to_install_core_on_xseries.html
4. After you install IBM Systems Director Platform Agent, before you discover the platform
agent in the IBM Systems Director server, run the following SLP query from the IBM
Systems Director server to ensure that the platform agent service is advertised properly
and that there is no firewall blocking between the platform agent and the IBM Systems
Director server.
460
You can run either the slptool command or slp_query tool on the IBM Systems Director
server based on the operating system where you installed the IBM Systems Director
server.
On Linux, run the following command:
/opt/ibm/icc/bin/slptool -u <ip_of_managed_resource> findsrvs
service:management-software.IBM:platform-agent
On Windows, run the following command:
slp_query --type=service:management-software.IBM:platform-agent
--address=<ip_of_managed_resource>
11.2.4 IBM Systems Director Storage Manager: Discovery

Similar to managing other type of endpoints, discover the storage devices as a first step
before monitoring and managing them through IBM Systems Director server.
We use an example of discovering an SMI-S Provider Agent for IBM DS4000 series SAN
storage in IBM Systems Director:
1. As a first step, install and configure the SMI-S Provider Agent for the storage device. Each
SAN component that is managed by Storage Manager requires an SMI-S Provider Agent
to be installed and configured. SMI-S Provider Agent can be installed on any system. For
more information about installing SMI-S Provider Agent, see SMI-S provider installation
and configuration on page 459.
2. On the IBM Systems Director server console, discover the SMI-S provider using the
following steps:
a. Log on to the IBM Systems Director server console, go to Inventory System
Discovery. Click Create new profile under Advanced Tasks, as shown in Figure 11-3.
Figure 11-3 System Discovery: Create new profile
b. On the Discovery Profile Wizard, click Next on the Welcome page.
461
c. On the Profile Properties panel, as shown in Figure 11-4, enter the profile name and
select the resource type, Operating System. Select All for the resource subtype. Click
Next.
Figure 11-4 Discovery Profile Wizard: Profile Properties page
d. On the Protocol Selection page, select Storage Management Initiative Specification

(SMI-S) Discovery from the list of protocols that are displayed, as shown in
Figure 11-5. Click Next.
Figure 11-5 Discovery Profile Wizard: Protocol Selection page
462
e. On the SMI-S Configuration page, perform the steps that are shown in Figure 11-6:
i. Choose SMI-S Direct connection discovery.
ii. Choose the hardware type depending on the type of storage device that you have.
iii. Select the type of protocol that is configured on the SMI-S Provider Agent.
iv. Enter the IP address and port details of the SMI-S Provider Agent.
v. Click Next.
Figure 11-6 Discovery Profile Wizard: SMI-S Configuration page
f. Optionally, on the Access Request page you can provide the access details of the
operating system where SMI-S Provider Agent has been installed. Click Next.
g. Optionally, on the Inventory Discovery page you can configure settings to
automatically discover (collect) inventory. Click Next.
h. On the Summary page, review the summary of your profile selections. If there are no
modifications required, click Finish to create a new profile.
3. On the System Discovery page that is shown in Figure 11-7 on page 464, perform the
following steps:
a. Under Select a discovery option:, choose Select a discovery profile to run.
b. Select newly created discovery profile.
c. Click Discover Now.
When the discovery job is completed, you are able to see the SMI-S Provider Agent
system and the managed storage devices, if you provided the access details in the
discovery profile already.
463
Figure 11-7 Discover SMI-S Provider Agent using the customized discovery profile
Note: If you have IBM Systems Director Storage Control activated in your environment,
following the steps mentioned above to discover a storage device creates a data source in
the Storage Control [e-Tivoli Storage Productivity Center basic edition] database.
11.2.5 IBM Systems Director Storage Manager: Inventory collection

The inventory collection operation should be the first step performed after discovering any
storage devices in the IBM Systems Director server.
Best Practice: Users should ensure that the inventory collection is done for each endpoint
before running any IBM Systems Director or plug-in tasks. This ensures that the IBM
Systems Director server tasks when run would be starting from a known state. In other
words, IBM Systems Director server and its plug-ins would be aware of the environment on
which they were installed and activated. The inventories on the endpoints can be done in
any order, or even at the same time.
If there are any changes or tasks, such as volume addition or deletion done on the storage
devices using native management consoles, an inventory rerun should be performed on
those devices for IBM Systems Director server to reflect the changes made.
To collect inventory on storage devices, perform the following steps:
1. On the IBM Systems Director console, go to the Resource Explorer page.
2. Click the All Storage Systems group, right-click the required storage device, and select
Inventory Collect Inventory. Run the inventory job.
464
3. When the inventory collection succeeds, you are able to see the amount of raw storage
that is available, usable capacity of the storage, and available capacity, as shown in
Figure 11-8.
Figure 11-8 Resource Explorer All Storage Systems (View Members)
4. Right-clicking the storage device and selecting Related Resources, as shown in

Figure 11-9, allows you to see related disk drives, IP interfaces, storage volumes, and
storage pools information.
Figure 11-9 Storage device Related Resources page
11.2.6 IBM Systems Director Storage Manager: Managing storage

You can perform real-time management of the storage systems that are attached to IBM
BladeCenter or System x systems.
IBM Systems Director Storage Manager supports management of these storage systems that
are attached to or integrated with IBM BladeCenter and System x systems:
Integrated RAID Controllers

ServeRAID MR Controllers
BladeCenter SAS Connectivity Modules
IBM BladeCenter S SAS RAID Controller Modules
For more information about how to configure and manage the preceding devices, see the
following link:
r.storage.helps.doc%2Ffqm0_t_sm_managing_storage_in_real_time.html
465
In this book, we use an example of discovering an IBM System x86 server that has IRC
running IBM Systems Director Platform Agent v6.3.2 IBM Systems Director:
1. Install the platform agent on the IBM System x86 that has supported IRC. Refer to IBM
Systems Director Platform Agent installation on page 460 for more information about
installation and best practices.
2. On the IBM Systems Director server web console, go to Inventory System Discovery.
3. Input the IP address and host name of the server that needs to be discovered. Select
Operating System as the resource type. Click Discover Now, as shown in Figure 11-10.
Figure 11-10 System Discovery page
4. When the discovery is complete, the operating system (OS) instance is listed under
Discovered Manageable Systems, as shown in Figure 11-11.
Figure 11-11 Discovered Manageable Systems panel
5. Request access to the discovered endpoint by right-clicking and select Security

Request Access. Provide the user name and credentials that have root privileges to
unlock the OS instance endpoint. When the request access is successful, close the
Request Access page and return to the System Discovery page.
6. If you have the management controller/service processor on the server hosting the OS
instance that was discovered, on the network reachable by IBM Systems Director server,
you see a server instance that is created. The instance is in a locked mode, as shown in
466
Figure 11-12 After getting access to the OS instance
7. Request access to the server instance by right-clicking and select Security Request
Access. Input the management controller/service processor user name and credentials to
unlock the server instance endpoint.
8. Go to Resource Explorer Groups All Systems (View Members). Right-click the
OS instance and select Inventory Collect Inventory. Run the inventory collection and
wait until the job is completed.
Note: Running inventory collection is a necessary step to get the storage management
options for the system having supported-IRC.
9. When inventory collection is complete, go to Resource Explorer Groups All
Systems (View Members). Right-click the OS instance. Select System Configuration
Storage, as shown in Figure 11-13 on page 468. This option can be used to view and
manage the storage that is associated with the managed system.
467
Figure 11-13 Storage monitor and manage option for IRC on IBM System x86 server
10.Clicking the System Configuration Storage option leads you to the Storage page
where, as shown in Figure 11-14, you can view the local storage devices and volumes that
are associated with the system and perform any necessary tasks that are associated with
storage volumes, such as creating and deleting volumes.
Figure 11-14 Monitor and Management panel for IRC-managed storage devices
Note: The Volumes and Storage Pools pages do not support all the Action menu
choices. The Volumes page only supports Create Volumes and Delete Volumes. The
Storage Pools page only supports Create Storage Pool and Delete Storage Pool. All
other Action menu choices for those pages are not supported.
468
Removing managed devices

If the storage devices are managed through an SMI-S Provider Agent, it is always
recommended to remove the SMI-S Provider Agent followed by removal of the managed
storage devices. For more information about removal of managed objects from IBM Systems
Director server, see the following link:
r.console.helps.doc%2Ffqm0_t_rn_removing_a_resource.html
11.3 Advanced edition: IBM Systems Director Storage Control

IBM Systems Director Storage Control is the advanced plug-in for IBM Systems Director
server, which provides the users with flexibility to monitor and manage the enterprise-level
storage devices from the same console that is used for server and network device monitoring.
This section outlines the tasks that are supported in IBM Systems Director Storage Control
along with best practices, tips, and troubleshooting topics.
Need for Storage Control plug-in

Below are the scenarios depending on which the requirement to buy IBM Systems Director
Storage Control plug-in can be decided:
Storage Control plug-in is required if your environment has storage devices or the Fibre
Channel (FC) switches are not supported by the base IBM Systems Director Storage
Manager and there is no Tivoli Storage Productivity Center management server in your
environment.
When you already have a Tivoli Storage Productivity Center management server in your
environment, a Storage Control plug-in is not a mandatory requirement. IBM Systems
Director can communicate with an external Tivoli Storage Productivity Center to manage
the enterprise storage devices and the supported FC switches.
As of IBM Systems Director server version 6.3.2, if your environment has Cisco MDS
9100, 9200, and 9500 family switches, it can be managed only by an external Tivoli
Storage Productivity Center server. IBM Systems Director server can communicate with
external Tivoli Storage Productivity Center to manage these switches.
When using VMControl plug-in, IBM Systems Director manages and communicates with
the virtual SCSI storage devices through the SMI-S providers, the HMC, and optionally,
IBM Tivoli Storage Productivity Center. For N-Port ID Virtualization (NPIV) storage
devices, the devices must be managed through either IBM Systems Director Storage
Control or IBM Tivoli Storage Productivity Center. You cannot manage the storage devices
by using the SMI-S provider through IBM Systems Director Storage Manager.
11.3.1 Planning for Storage Control

Listed below are the requirements for using IBM Systems Director Storage Control:
The virtual/physical server that is chosen for the installation of IBM Systems Director
server should have at least the minimum hardware configuration. See Table 11-4 on
page 470.
469
Table 11-4 Hardware requirements

Storage Control minimum hardware requirements
Processor
Installed memory
3 GHz
3 GB (Total requirement for

Systems Director, DB2, and
Storage Control)
0.8 GB RAM (Requirement
for Storage Control only)
Disk storage
5.15 GB
For AIX or Linux installations,
the 5.15 GB must be in these
directories:
/tmp - 2.15 GB
/opt - 2.6 GB
/home - 400 MB
/etc - 10 KB
The Storage Control plug-in supports most of the Red Hat Enterprise Linux, Microsoft
Windows, and AIX operating systems that Systems Director also supports, with these
exceptions: Red Hat Enterprise Linux on Power Systems, Red Hat Enterprise Linux on
System z systems, and SUSE Linux Enterprise.
IBM Systems Director 6.2.1 or higher is required in order to use Storage Control.
As a best practice, plan to use a local IBM DB2 database that is managed by Systems
Director server. If not, you must use one of these versions of IBM DB2 as the local
database application for Systems Director to use Storage Control:
IBM DB2 Enterprise Edition v. 9.7
IBM DB2 Enterprise Edition v. 9.7 with fix pack 4
For more information about the IBM Systems Director Storage Control requirements, see the
following site:
r.storagectrl.helps.doc%2Ffqm0_c_sc_planning.html
11.3.2 Installation of Storage Control

IBM Systems Director Storage Control is a separately downloadable and installable plug-in
that is available on the following platforms:
Red Hat Enterprise Linux (RHEL) running on IBM x86 servers
Microsoft Windows running on IBM x86 servers
AIX running on IBM Power Servers
Before installing Storage Control, ensure that the supported version of the managed DB2
server is running on IBM Systems Director server:
On Linux/AIX operating system:
Command to show the version, fix pack, and installation information of the managed DB2
installed:
<IBM Systems Director installation directory>/director/db2/adm/db2level
On Microsoft Windows operating system:
Command to show the version, fix pack, and installation information of the managed DB2
installed:
<IBM Systems Director installation directory>\director\db2\adm\db2level
470
If the managed DB2 version is other than the supported version mentioned in 11.3.1,
Planning for Storage Control on page 469, ensure that the supported managed DB2 version
is installed before moving ahead with IBM Systems Director Storage Control plug-in
installation. The following site provides the instruction for performing fix pack installation for
DB2 version 9.7:
http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.q
b.server.doc%2Fdoc%2Fc0025016.html
IBM Systems Director Storage Control 4.2.1.1 must be installed before you apply updates,
including Storage Control 4.2.3.1.
You can use IBM Systems Director update manager to acquire and install IBM Systems
Director Storage Control versions that are compatible with IBM Systems Director 6.3.1 and
6.3.2. Table 11-5 lists the installation log file locations for the IBM Systems Director Storage
Control plug-in.
Table 11-5 Installation log location
Operating system platform
Installation log file location
IBM AIX/RHEL
/opt/IBM/TPC/TPC.log
/var/log/SCinst.log
/opt/IBM/TPC/log/install
Microsoft Windows
C:\Program Files\IBM\TPC\TPC.log
C:\Program Files\IBM\TPC\log\install
For more information about installing Storage Control 4.2.1.1, see the following information
center link:
r.storagectrl.helps.doc%2Ffqm0_t_sc_installing_storage_control.html
After you install IBM Systems Director Storage Control, activate the plug-in by using the
following steps:
1. Run the following command to get the advanced plug-in status:
# smcli lsmgrs
Network Control : Activated
Active Energy Manager : Deactivated
VMControl : Activated
Storage Control : Deactivated
2. If you see Storage Control in the deactivated state, run the following command to activate:
#smcli activatemgrs Storage Control
3. When Storage Control is activated, run the following commands to restart IBM Systems
Director server:
On Linux/AIX operating system,
<IBM Systems Director installation location>/bin/smstop
<IBM Systems Director installation location>/bin/smstart
On Microsoft Windows operating system,
net stop dirserver
net start dirserver
When there are Storage Control software quality or feature function updates, an update is
made available.
471
Storage Control updates must be applied to an existing Storage Control installation. The
procedure for updating Storage Control depends on the version that is installed. To determine
the version of Storage Control that is installed, open the Plug-ins tab of the IBM Systems
Director Home page and scroll to the Storage Management section. The Storage Control
version is listed in the Storage Management section. For steps to update storage control, see
the following site:
r.storagectrl.helps.doc%2Ffqm0_t_sc_updating_storage_control.html
11.3.3 IBM Systems Director Storage Control lifecycle operations

There could be situations where users need to stop, start, or rediscover the Storage Control
Farm object which could be a part of troubleshooting issues as well. Listed below are a few of
those instances:
After performing an upgrade from IBM Systems Director 6.2 to Systems Director 6.3.2, the
access type for the remote service access point (RSAP) of a switch or storage device
does not have the correct value of Tivoli Storage Productivity Center.
If you changed the password that IBM Systems Director uses to access IBM DB2 and
Storage Control can no longer access IBM DB2.
If you changed the IP address of the management server and you can no longer
communicate with Storage Control.
After you switch to using the managed IBM DB2 database for IBM Systems Director.
Stop Storage Control plug-in

Stop Storage Control by running the appropriate command on the management server,
where DIRHOME is the root directory of your IBM Systems Director installation:
On Windows: From a command prompt, run the following command:

DIRHOME\StorageControl\bin\stopStorageControl.bat
On AIX or Linux: From the command line, run the following command:
DIRHOME/StorageControl/bin/stopStorageControl.sh
Start Storage Control plug-in

Start Storage Control by running the appropriate command on the management server,
where DIRHOME is the root directory of your IBM Systems Director installation:
On Windows: From a command prompt, run the following command:

DIRHOME\StorageControl\bin\startStorageControl.bat
On AIX or Linux: From the command line, run the following command:
DIRHOME/StorageControl/bin/startStorageControl.sh
Remove and rediscovering the Storage Control Farm object

Removing Storage Control Farm object is similar to removing any other resource from the
IBM Systems Director database.
For more information about removing a resource, see the following link:
r.console.helps.doc%2Ffqm0_t_rn_removing_a_resource.html
472
Follow the steps below to rediscover and request access to the Storage Control Farm.
For Windows, any of the following two methods can be used:

Create and run a discovery profile to discover and request access to the farm. When you
create the profile, be sure to specify the following settings:
Tivoli Storage Productivity Center database configuration:
IP Address: The management server address
Port: 50010
Database Name: TPCDB
Database User ID: The Windows administrator user name
Database Password: The password for the specified Windows administrator user
name
Tivoli Storage Productivity Center server configuration:
TPC User ID: The Windows administrator user name
TPC Password: The password for the specified Windows administrator user name
TPC Storage Resource Group Selection: Select ALL
Access Request: Specify the Windows administrator user name and password
From the Director Server command line, run the following command, where DIRHOME is the
path of the directory of your IBM Systems Director installation:
DIRHOME\StorageControl\bin\SCDiscoverUnlock.sh
On AIX or Linux: On the management server from a command line, run the following
command, where DIRHOME is the root directory of your IBM Systems Director installation:
DIRHOME/StorageControl/bin/SCDiscoverUnlock.sh
Note: This command discovers and automatically requests access to the Storage Control
Farm.
11.3.4 Discovering storage devices

To start managing storage devices with Storage Control, the storage device should be
discovered in the IBM Systems Director server as a first step. Below are the type of storage
devices that you can discover and manage from IBM Systems Director Control:
FC switch
IBM Systems Storage: includes DS4000/3000/5000 series
IBM DS8000 series
XIV storage systems
IBM SAN Volume Controller
IBM Flex System V7000 and Storwize V7000
Starting with IBM Systems Director Storage Control 4.2.3, use the Discover Storage task that
is present on the IBM Systems Director console. Using Discover Storage makes it easy and
straightforward to discover the data sources for your storage devices and subsystems so that
Storage Control can communicate with them. You also can automatically collect inventory on
the discovered devices.
Note: The term data source describes how the storage device is managed. Some data
sources are the location of the SMI-S provider for the device. For example, the data source
for a Brocade Fibre Channel switch is the location of the SMI-S provider for the switch.
Other data sources are the device itself. For example, for the current firmware levels of the
SAN Volume Controller and IBM Storwize V7000, the device is the data source.
473
Before starting to work with Storage Control, run the following command to ensure that the
Storage Control plug-in is activated:
# smcli lsmgrs
Network Control : Activated
Active Energy Manager : Deactivated
VMControl : Activated
Storage Control : Activated
If Storage Control is in the deactivated state, follow the steps that are listed in section 11.3.2,
Installation of Storage Control on page 470 to activate the IBM Systems Director Storage
Control.
The following sections provide demonstrations about how to discover storage devices in
IBM Systems Director Storage Control, using IBM Storwize V7000 and the Brocade 16 GB
Fibre Channel switch as examples.
Discovering an SVC storage device in IBM Systems Director

To discover an IBM Storwize V7000 SVC node, perform the following steps:
1. Ensure that you have a Secure Shell (SSH) key pair generated and associated with an
IBM Storwize V7000 user. Following are the steps to generate an SSH key pair and
associating it with a user on v7000:
a. On any host, perform the following step to set up an RSA key pair:
On an AIX or Linux host, create an RSA key pair by issuing a command on the host
that is similar to the following command. Issue the command from the $HOME/.ssh
directory:
#ssh-keygen -t rsa
This process generates two user named files. The files are named <key name> and
<key name>.pub. Where key name is the name of the private key and
keyname.pub is the name of the public key.
If you need to perform the preceding step from a server running Microsoft Windows
operating system, tools such as puttygen can be used.
b. Download the public key that is generated to the workstation from where you are
accessing Storwize V7000. Associate the public key that is generated in the previous
step with a user on the Storwize V7000 or Storwize V7000 system, using the following
steps:
i. Log in to the Storwize V7000 web console.
ii. Go to Access Users. Click New User, as shown in Figure 11-15 on page 475, to
create a new user.
474
Figure 11-15 IBM Storwize V7000 user management console
iii. Complete the information about the New User panel and upload the public key that
is generated in step (a). When done, the new user is displayed under the All Users
section, as shown in Figure 11-16.
Figure 11-16 IBM Storwize V7000 add user panel
2. Copy the generated SSH private key to IBM Systems Director server or the workstation
where you will access the IBM Systems Director web console depending on the method,
either graphical user interface (GUI) or command line, that you are using for discovery of
the storage device. Both methods are explained below.
475
Discovery using the graphical user interface

Perform the following steps to discover by using the GUI:
1. Navigate to the Home window of the IBM Systems Director server console. Click Discover
Storage under the Storage Management section, as shown in Figure 11-17.
Figure 11-17 IBM Systems Director: Discover storage
2. In the Discover Storage page, select IBM Flex System V7000 and Storwize V7000 for
the storage device type.
3. Specific settings for discovering IBM Flex System V7000 and Storwize V7000 are
displayed, as shown in Figure 11-18.
Figure 11-18 Discover Storage page
Where:
a. IP address or the host name field: Enter the IP address of IBM Storwize v7000.
b. Upload SSH private key field: Specify the location where you have the private SSH
key located on the machine from where you are accessing the IBM Systems Director
server console.
c. Key passphrase (optional) field: Enter the SSH key passphrase, if any.
d. Automatically run inventory when discovering devices field: This check box is
selected by default. It is recommended to collect inventory on the Storage Farm when
you add new storage devices.
e. Click Discover to start the discovery job.
476
4. When the discovery of the IBM Storwize V7000 is done, inventory collection starts as
shown in Figure 11-19. Click Close to continue.
Figure 11-19 Discover Storage page: Completed discovery of the storage device
5. Both discovery and inventory collection can be seen on the Active and Scheduled Jobs
list, as shown in Figure 11-20.
Figure 11-20 Active and Scheduled Jobs page
6. When both discovery and inventory jobs are completed, the discovered storage device is
displayed under the Discover Storage page, as shown in Figure 11-21.
Figure 11-21 Discovered IBM Storwize V7000
477
7. To further manage and monitor the IBM Storwize V7000, go to Resource Explorer
Groups All Storage Systems (View Members). The discovered V7000 is displayed
along with additional information, such as Raw Capacity, Usable Capacity, Available
Capacity, as shown in Figure 11-22.
Figure 11-22 Resource Explorer panel
Discovery using the command line

Perform the following steps to discover by using the command line:
1. Log in to the IBM Systems Director server command line.
2. Run the following command to discover the IBM Storwize V7000:
smcli mkdatasource -c svc -i <IP address of the v7000> -f <path to generated
private SSH Key on systems director server> -v V7000
When the v7000 discovery is done, inventory collection is done automatically on the
Storage Control Farm object.
11.3.5 Discovering Fibre Channel fabric in IBM Systems Director

Discovery of the Fibre Channel (FC) switch is supported in both GUI and command line,
similar to discovery of storage devices. Both methods are documented below.
Discovery using the GUI

To discover a Brocade FC switch, perform the following steps:
1. On a dedicated physical/virtual server, install and configure the Brocade SMI Agent or
Brocade Network Advisor (with Integrated SMI Agent) with the Brocade FC switch. For
more information about installation and configuration, see the following link:
http://www.brocade.com/services-support/drivers-downloads/smi-agent/index.page
2. Navigate to the Home page of the IBM Systems Director server console. Click Discover
Storage under the Storage Management section, as shown in Figure 11-23.
Figure 11-23 IBM Systems Director: Discover Storage page
3. In the Discover Storage page, select FC switch for the storage device type.
4. Specific settings for discovering FC switch are displayed, as shown in Figure 11-24 on
page 479.
478
Figure 11-24 Discover storage: FC switch
Where:
i. SMI-S IP address or host name field: Enter the IP address of the server on which
SMI-S Provider Agent has been installed.
ii. Port field: Leave the default value if you have not chosen a different port while
installing the SMI-S Provider Agent. If there is a different port selected, enter that
port number in this text box.
iii. Username and Password fields: Enter the user name and password of the server
on which SMI-S Provider Agent has been installed.
iv. Interoperability namespace field: Leave the default value if you have not chosen a
different name for the namespace while installing the SMI-S Provider Agent. If there
is a different name, enter that name in this text box.
v. Protocol field: Choose the protocol using which IBM Systems Director Storage
Control communicates with the SMI-S Provider Agent.
vi. Automatically run inventory when discovering devices option: This check box is
selected by default. It is recommended to collect inventory on the Storage Farm
when you add new storage devices.
Click Discover to start the discovery job.
479
vii. When the discovery of the FC switch is done, inventory collection is started. Both
the discovery and the inventory collection tasks can be seen on the Active and
Scheduled Jobs list of IBM Systems Director server.
viii.When both discovery and inventory jobs are completed, the discovered FC switches
managed by the SMI-S provider are displayed under the Discover Storage page, as
Figure 11-25 Discover Storage page: FC switches discovered
Discovery using the command line

From the IBM Systems Director command line, run the following command to discover the FC
switch:
smcli mkdatasource -c fabric -i <IP address of the SMI-S provider agent> -t
<https/http> -p <https/http port> -u <Username> -w <password> -n <name of the
interoperability namespace>
When the discovery FC switch is done, inventory collection is done automatically on the
Storage Control Farm object.
For more information about the commands used to discover other types of Storage
Control-supported storage devices, see the following link:
r.cli.helps.doc%2Ffqm0_r_cli_mkdatasource.html
11.3.6 Inventory collection on Storage Control-managed devices

Before using any tasks that are related to IBM Systems Director Storage Control or the
dependent plug-ins such as VMControl, inventory collection has to be done on the managed
storage devices.
IBM Systems Director Storage Control uses the embedded version of the IBM Tivoli Storage
Productivity Center server.
Discovering and running inventory against the Storage Farm that represents the embedded
IBM Tivoli Storage Productivity Center server causes Systems Director to fully populate all of
the devices that are being managed by the embedded IBM Tivoli Storage Productivity Center,
including Fibre Channel switches and storage subsystems.
480
Note: You can collect inventory for only one device in a Storage Farm at a time. Collecting
inventory at the same time for multiple devices that are managed by the embedded IBM
Tivoli Storage Productivity Center is not supported.
Below are a couple of the scenarios where a user needs to run inventory collection on the
storage devices:
As a first step after discovering storage devices in IBM Systems Director server.
When the configuration changes for a storage device, that is managed by IBM Systems
Director Storage Control, using external management such as the native device
management tools. For IBM Systems Director Storage Control to update its database, an
inventory collection on the specific storage device or FC switch should be done.
There is no specific sequence to be followed in an inventory collection operation for FC
switches, Storage Control Farm, and storage devices.
11.3.7 IBM Systems Director Storage Control: Allocating storage volumes

to virtual servers
When IBM Systems Director Storage Control is working in conjunction with IBM Systems
Director VMControl [express/standard/enterprise edition], you manage storage allocation and
deallocation on the Power VM/KVM virtual servers.
This book provides an example of allocating and viewing storage volume relationships of
existing PowerVM virtual servers to demonstrate the capability of IBM Systems Director
Storage Control:
1. As a best practice, ensure that you have collected inventory on the following instances, as
applicable to your configuration:
a. The IBM HMC/IVM instances
b. The IBM Power Servers instances
c. VIOS Virtual Server instances
Note: It is not necessary to collect inventory every time before doing VMControl or
Storage Control operations. See section 11.3.6, Inventory collection on Storage
Control-managed devices on page 480 for more information about when collecting
inventory is necessary.
481
2. Go to Inventory Views Virtual Servers and Hosts on the IBM Systems Director
server web console. Right-click the virtual server to which you need to allocate the storage
disk and select System Configuration Create Storage Volumes, as shown in
Figure 11-26.
Figure 11-26 Create Storage Volumes option
3. On the Create Storage Volumes wizard, click Next to get past the Welcome page.
482
4. On the Storage Pool page, you see all the storage pools to which the virtual server has
access to, as shown in Figure 11-27. Select the appropriate storage pool and click Next.
Figure 11-27 Storage pools that are accessible to the selected virtual server
Note applies only to PowerVM: In this example, we chose a virtual server that has
vFC adapters and is configured to use NPIV. When you are trying to assign storage to
existing virtual servers, the following disk types are supported to be added from the IBM
Systems Director GUI:
New/existing NPIV disks
Existing vSCSI disks
Creating a new vSCSI disk and assigning it to an existing virtual server is supported
from the command line and REST interface. Following is an example of the smcli
command that is used to allocate a new vSCSI disk to an existing PowerVM virtual
server:
# smcli lsvrtcap -c chvs -n <name of virtual server>
Note the storage pool key from the above command output
# smcli chvs -s "assigneddisks=diskname:<new disk name>;disksize:<disk size
in MB>;adddisklocation:storagepools[<Pool Key>]" -n <name of virtual server>
483
5. On the Additional Servers page, you can select any other virtual servers that you want to
have access to the storage volume being created using the current task. In this example,
we selected virtual server ip10-32-42-88, as shown in Figure 11-28. Click Next to
continue.
Figure 11-28 Additional servers that need to have access to the new storage volume
484
6. On the Settings page, enter the volume name and size details, as shown in Figure 11-29.
Figure 11-29 Volume settings
7. If you need to look at the existing storage volumes on the selected storage pool, click View
Existing Storage Volumes. Existing storage volumes are displayed as shown in
Figure 11-30. Click Close to exit.
Figure 11-30 Existing storage volumes on the storage pool selected
485
8. Clicking Next on the Settings page brings you to the Summary page, as shown in
Figure 11-31. Review the settings and click Finish.
9. Monitor the task in the Active and Scheduled Jobs list until it is complete.
10.To view the storage volume that was allocated in previous steps, go to Inventory
Views Virtual Servers and Hosts on the IBM Systems Director server web console.
Right-click the virtual server to which you just allocated the storage disk and select
Related Resources Storage Volumes.
The resulting page shows you the storage volumes that are related to the virtual server.
Both CreateVS and ip10-32-42-88, as shown in Figure 11-32 and Figure 11-33 on
page 487, are allocated with the newly created volume.
Figure 11-32 CreateVS: Virtual server: storage volume relationship
486
Figure 11-33 ip10-32-42-88: Virtual server: storage volume relationship
11.To see the Server to Storage Mapping View, go to Inventory Views Virtual
Servers and Hosts on the IBM Systems Director server web console. Right-click the
virtual server to which you allocated the storage disk and select System Configuration
Server to Storage Mapping View.
The resulting page shows you an end-to-end storage configuration, as shown in
Figure 11-34.
Figure 11-34 Server to Storage Mapping View page
11.3.8 Removing Storage Control-managed devices

When you discover the storage devices that are going to be managed by IBM Systems
Director Storage Control, two types of objects are created in the IBM Systems Director
database. One is a data source that is defined by IBM Systems Director Storage Control and
the other is a corresponding managed endpoint instance that is created by IBM Systems
Director server:
1. Running the smcli lsdatasource command retrieves all the data sources that are defined
by IBM Systems Director Storage Control. Below is an example command output that lists
all the data sources that are defined by Storage Control in the IBM Systems Director
server database:
#smcli lsdatasource
Data Source: 1
Management IP Addresses: 9.x.x.x
Category: svc
User ID:
Managed Devices OID: [0x7a6c]
Data Source: 2
Category: svc
User ID:
487
Managed Devices OID: [0xaab1]
Data Source: 3
Category: fabric
User ID: Administrator
Managed Devices OID: [0x8150, 0x7f92, 0x7fe8, 0x81a4, 0x8068, 0x80f2, 0x821e]
Port: 5989
Protocol: https
Namespace: /interop
2. Running the smcli lsmeps command retrieves all the managed endpoints that are defined
by IBM Systems Director server, which also includes the FC switches and storage devices.
Included below is an example command output that lists the extracts pointing to the
managed endpoint instances defined by IBM Systems Director server in its database for
the storage devices and FC switches. You are able to see the following instances in the
IBM Systems Director GUI interface:
smcli lsmeps
..
..
MEP: Storwize V7000-2076-VMC7000_1-IBM (resource name: 00000200A0203BD9+0)
OID: 31340
GUID: 988DB4C7FA483DB29BF84208B9D2AE3A
ResourceType StorageSubsystem
MEP: Flex V7000-4939-V7000 Storage Node-IBM (resource name: 0000000020600062+0)
OID: 43697
GUID: E617B60819D7307895789421691B499B
ResourceType StorageSubsystem
..
MEP: IBM_2498_B24 (resource name: IBM_2498_B24)
OID: 32872
GUID: A09E353C97E7392287997A1CBC5555B2
ResourceType Switch
When you need to remove the storage devices or FC switches that are managed by
IBM Systems Director Storage Control, both of following endpoint types should be removed:
Farm objects that are defined by IBM Systems Director Storage Control. See the following
link for more information about the removal of farm objects:
ctor.cli.helps.doc%2Ffqm0_r_cli_rmdatasource.html
Managed endpoint instances that are defined by IBM Systems Director server. See the
following link for more information about the removal of managed objects from IBM
Systems Director server:
ctor.console.helps.doc%2Ffqm0_t_rn_removing_a_resource.html
488
11.4 Storage management: smcli references

This section describes the smcli commands for the most commonly used storage
management scenarios:
Listing all related storage volumes for a resource
Syntax:
smcli lsstvol -n <resource name>
Example:
#smcli lsstvol -n "Storwize V7000-2076-VMC7000_1-IBM"
Where, resource selected is an IBM Storwize V7000 Storage
#smcli lsstvol -n ip10-32-42-88
Where, resource selected is an IBM PowerVM LPAR having vFC adapters
Tip: This command should be used to list related storage volumes for a server that has
Fibre Channel ports. If your server has Fibre Channel ports and has storage volume
allocated using external tools other than storage control, ensure that you have collected
inventory on the server and farm object at least once.
Creating a new storage volume in the network storage
Syntax:
smcli mkstvol -n "<virtual servers name separated by comma, if more than one>"
-P "<Host name>" -p <name of the new storage volume> -s <size> -u <unit>
Example:
smcli mkstvol -n "CreateVS, ip10-32-42-88" -P "pfm9253_pfm9254" -p
New_storage_volume -s 5.0 -u GB
Where:
New_storage_volume is the name of the new storage volume
pfm9253_pfm9254 is the name of the existing storage pool on which the storage
volume is created
CreateVS & ip10-32-42-88 are the two virtual servers that have access to the
newly created storage volume
Tip:
Before running this command, ensure that all server, switch, and storage devices are
discovered and inventory collection is done at least once.
Detach and delete storage volumes
Syntax:
smcli rmstvol -n volume_name
Example:
smcli rmstvol -n New_storage_volume
Where:
New_storage_volume is the storage volume name that will be detached from the
servers that it is currently attached and then deleted from the storage sub system.
489
Tip:
Before running this command, you can verify that all servers are using the storage
volume by using the following command:
smcli svsrelationships --src server --rel uses --tgt storagevolume
In a Power Server environment, you can find physical volume names present on the
VIOS. To find the storage volumes backing them, run the following command:
smcli svsrelationships -src physicalvolume -tgt storagevolume
For more storage management commands, see the following information center link:
r.cli.helps.doc%2Ffqm0_r_cli_storage_cmds.html
11.5 Best practices

Listed below are the best practices to be followed in using storage management features
efficiently:
If you are planning to use IBM Systems Director server for monitoring and managing the
storage devices, before starting to use Storage Manager or Storage Control, perform the
following functions:
List the storage devices that you have
Determine the following for each of these storage devices:
The type of SMI-S Provider Agents that are required.
The edition of storage management that is required.
Verify the existing firmware versions on the storage devices and ensure that they
comply with IBM Systems Director server-supported firmware versions.
Before installing IBM Systems Director Storage Control, ensure that you have a managed
DB2 version that meets storage control requirements.
For the SMI-S provider, the best practice is to consider the following factors:
Determine the servers where you can install the SMI-S Provider Agents, if required, for
monitoring and managing the storage devices.
It is required to choose a system other than IBM Systems Director server or systems
hosting Platform Agent for installation of the SMI-S provider (because of port conflicts).
Download the required SMI-S Provider Agents followed by installation and
configuration of the SMI-S Provider Agent on the predetermined servers.
Do not install more than one SMI-S provider on the same system. If there is a need to
install more than one provider on the same server, ensure that the ports on which the
provider agent CIM server listens are unique.
After SMI-S provider installation, ensure that both CIMOM and SLP services are active.
These protocols are needed for discovery and communication between IBM Systems
Director server and the SMI-S provider.
Uninstalling some of the SMI-S providers does not remove the CIM component. If the
system chosen for SMI-S provider installation was hosting any other SMI-S provider
previously, ensure that the CIM components are removed completely before going
ahead with the new installation of an SMI-S provider.
490
If you are reinstalling any SMI-S provider, it is recommended that you copy files that
contain the IP addresses of the systems under management and the ports in use to a
safe location.
It is always recommended to remove the SMI-S Provider Agent followed by removal of
the managed storage devices.
There is no hard limit on how many storage systems can be supported by a single
provider instance. The recommended maximum is 10 storage systems per provider.
If your environment already has IBM Tivoli Storage Productivity Center, ensure that it is at
version level 4.2.2 FP1+ before integrating it with IBM Systems Director.
Before performing any operations that involve dealing with the assignment of new and
existing volumes on the supported network storage using IBM Systems Director
VMControl, ensure that the IBM Systems Director Storage Manager or Storage Control
plug-in is configured with the necessary providers to communicate with the required
network and storage devices.
Ensure that the inventory collection is done for each endpoint at least once before running
any IBM Systems Director or plug-in tasks. The inventory collection on the endpoints can
be done in any order, or even at the same time.
If there are any changes in the configuration of the devices managed by IBM Systems
Director Storage Manager or Storage Control using the native management tools, an
inventory should be collected on those devices in IBM Systems Director for it to detect the
change and update the database.
While collecting inventory on the devices managed by Storage Control or IBM Tivoli
Storage Productivity Center, ensure that you collect inventory for only one device in a
Storage Farm at a time.
If the storage devices are managed through Storage Control and you want to remove this
storage device, it is recommended to remove both the farm objects as well as managed
endpoint instances defined by IBM Systems Director server representing this storage device.
491
492
12
Chapter 12.
Troubleshooting
This chapter covers troubleshooting techniques for the different components of
12.1, Troubleshooting the installation of IBM Systems Director components on page 494
12.2, Troubleshooting security-related issues on page 500
12.3, Troubleshooting VMControl on page 502
12.4, Troubleshooting AIX Profile Manager on page 509
12.5, Troubleshooting Workload Partition Manager on page 509
12.6, Troubleshooting Storage Control on page 512
493
12.1 Troubleshooting the installation of IBM Systems Director

components
This section covers the information for checking and troubleshooting the installation of
12.1.1 Pre-installation check

Since IBM Systems Director 6.3, there is a tool that is available that checks the installation
requirement for the IBM Systems Director server. The checkds program is located in the
checkds folder of the installation medium (DVD or installation package).
There are two ways to use the checkds program:
Run as a separate program before starting the installation
Integrated into the installation process
When running checkds as a separate program, the result of the check is shown as a web
page html format on Windows and Linux (with graphical interface) or as a text file on AIX and
Linux. Examples for the output can be found in the installation chapters for Windows and
Linux above.
The result files can be found in the following directories:
Windows
c:Users/%Username%/AppData/Temp/checkds/reports
Linux/AIX
/tmp/checkds/reports
12.1.2 Post Installation Validator

Post Installation Validator (PIV) is a new tool that comes with IBM Systems Director version
6.3.2. It is intended for use by service personnel, not the normal user.
PIV is located on the installation media in the PIV folder. It must be run manually after
finishing the installation of the IBM Systems Director.
The PIV analyzes the system to determine the state of the IBM Systems Director installation.
The PIV tool generates a report that contains a list of errors (if there are some) extracted from
the log files. The tool also analyzes the status of the IBM Systems Director and shows used
ports.
To start the PIV, run the following command from the command line:
494
Windows: PostInstallValidator_win.exe
Linux on x86: PostInstallValidator_xLin
Linux on Power: PostInstallValidator_pLin
Linux on z: PostInstallValidator_zLin
AIX: PostInstallValidator_AIX
Per default, a text (PostInstallationReport.txt) and HTML (PostInstallationReport.html) report

is created. Following is the default location for these reports:
Windows:
%temp%
Linux and AIX:
/tmp
There are different options that are available. With the -h option, a list of all available options
is shown (Figure 12-1).
.\PostInstallValidator_Win.exe -h
usage: PostInstallValidator_Win.exe [-h] [-o output directory]
[-c config file] [-s] [-r] [-n] [-v] [-d]
[-w] [-j]
The Post Installation Validator analyzes the local system to determine the
state of an IBM Systems Director Installation.
The syntax of this command is:
optional arguments:
-h, --help
show this help message and exit
-o output directory, --output output directory
Location of post install report
-c config file, --config config file
Location of configuration file
-s, --silent
Run this utility silently
-r, --report
Open text report upon completion (Windows only)
-n, --noninteractive Run this utility non-interactively
-v, --version
show program's version number and exit
-d, --detailed
Include detailed information in the report
-w, --wait
Wait to return until install is completed
-j, --nohtmlreport
Do not create HTML report
Options are case insensitive.
Report: PostInstallReport.txt (also PostInstallReport.html unless -j or
--nohtmlreport is used)
Default Windows Directory: %temp%
Default Linux / AIX Directory: /tmp
Press return to exit
Figure 12-1 Post Installation Validator options
Chapter 12. Troubleshooting
495
When running the PIV tool in a Windows environment, for example, you see the different
steps and the result for each one of the steps (Figure 12-2).
.\PostInstallValidator_Win.exe -d
Report being written to
c:\users\adminstrator\appdata\local\temp\PostInstallationReport.txt
Loading configuration file ./piv.ini
Check that no other Director installation is running.....................OK
Search for Director logs.................................................OK
Analyze installation type................................................OK
Search for installation path.............................................OK
Verify install directory.................................................OK
Analyze Windows Server MSI log file......................................OK
Analyze Windows Common Agent MSI log file................................OK
Analyze Windows Server log file..........................................OK
Analyze Windows TivGuid MSI log file.....................................OK
Analyze Windows Tivoli CAS Pre-Install log file..........................OK
Analyze Windows Tivoli CAS Install log file..............................OK
Analyze Windows Tivoli CAS Install Status log file.......................OK
Analyze Windows Platform Agent MSI log file............................FAIL
Check that the Agent Manager is configured...............................OK
Search for configuration logs............................................OK
Analyze InstallFeatures log..............................................OK
Analyze InstallConfigTools Log...........................................OK
Analyze InstallConfigTools Log 1.........................................OK
Check database install configuration.....................................OK
Analyze mergetools.log...................................................OK
Analyze mergetools.log.1.................................................OK
Analyze mergetools.log.2.................................................OK
Analyze usmi-cas-setup Log...............................................OK
Checking smstatus command................................................OK
Checking ports...........................................................OK
Checking active services.................................................OK
Analyze PIU results......................................................OK
Press return to exit
Figure 12-2 Run of PostInstallValidator_Win.exe
In our example, you see a failed result for the Platform Agent MSI log. Now you can check the
PostInstallationReport file to find the problem.
496
An excerpt from the report file that shows the failure can be seen in Figure 12-3.
...
***************************************************************************
Analyze Windows Tivoli CAS Install Status log file.........................
- Opening log C:\Program Files (x86)\IBM\Director\agent\runtime\agent\l
ogs\install\epInstallStatus.log
Analyze Windows Tivoli CAS Install Status log file.......................OK
***************************************************************************
***************************************************************************
Analyze Windows Platform Agent MSI log file................................
- Opening log C:\Windows\platinst_022813_084725.log
- 28.02.2013 08:48:58 MofcompExecute: Error; File 'C:\Program Files
(x86)\IBM\Director\cimom\mof\lsicontroller.mof' not found.
See line 12652 of C:\Windows\platinst_022813_084725.log
(x86)\IBM\Director\cimom\mof\lsicontrollerR.mof' not found.
(x86)\IBM\Director\cimom\mof\qlogic.mof' not found.
(x86)\IBM\Director\cimom\mof\qlogicR.mof' not found.
Analyze Windows Platform Agent MSI log file............................FAIL
***************************************************************************
***************************************************************************
Check that the Agent Manager is configured.................................
Check that the Agent Manager is configured...............................OK
***************************************************************************
...
Figure 12-3 Excerpt from the PostInstallationReport.txt file
In our example, the IBM Systems Director ran in a virtual machine (VM). Therefore, no LSI
adapter and no QLogic adapter are installed. That is why no Managed Object Format (MOF)
files for these adapters were compiled.
12.1.3 IBM Systems Director messages

When running a task or getting a message box in the IBM Systems Director console, you see
a message code in front of the message.
This code has a specific format, a unique message identifier (example: ATKSRV614E).
497
The format XXXYYY######Z is defined in the following way:
XXX identifies the component prefix that sends the message

YYY identifies the subsystem from which the message comes (this is optional)
The next 3..6 digits ###### identify the message number
Z, the last character, identifies the severity code:
E: Error message
I: Information message
W: Warning message
There is no list with all the messages for download available, but you can search for the
message in the IBM Systems Director Information Center at the following link:
http://pic.dhe.ibm.com/infocenter/director/pubs/index.jsp
Put the message in the search field on top of the left column and then the result shows with
the explanation of the message (Figure 12-4). You can also put in a part of the message key,
for example, ATK*, to get all messages that start with ATK. Then, you can go through the list
and search the message that you want to get information from.
Figure 12-4 Search for messages in IBM Systems Director Information Center
498
12.1.4 IBM Systems Director log files

IBM Systems Director creates some log files during the installation and also during the work.
These log files can help to find problems and solve them. In Table 12-1, you can see the
location of the most important log files for IBM Systems Director and agents.
Table 12-1 Location of log files by OS
Log file type
Windows
Linux
IBM Systems
Director server
installation logs
c:\Windows\
dirserverinst_time.log
dirserversetup.log
db2prereqcheck.log
prereqcheckdb2.log
installdb2.log
tivguidinst64.log
%inst_dir%\IBM\Direct
or\log\recovery.txt
c:\Windows\
agent_install.log
CasInst.log
certutil.log
diragnetinst_time.log
diragnetsetup.log
tivguidinst.log
/var/log/dirinst.log
c:Windows\platinst_ti
me.log
/var/opt/ibm/platform/l
og/install.log
Common Agent
installation logs
Platform Agent
installation logs
/opt/ibm/director/log/*
.log
/opt/ibm/director/log/r
ecovery.txt
AIX
IBM i
/var/log/director/*
/opt/ibm/director/lo
g/recovery.txt
Common Agent
uninstall logs
Platform agent
uninstall logs
c:\Windows\
platuninst.logs
sysdiremoval.log
/var/opt/ibm/platform/l
og/uninstall.log
Configuration
logs
%inst_dir%\IBM\Direct
or\log\*.log
/opt/ibm/director/log/*.l
og
/tmp/director/installA
gent.log
/tmp/director/installDi
rAgent.log
www/cas/lwi/runtime/
agent/logs/install
/tmp/director/uninstall
DirAgent.log
-
/var/log/director/*
Logcollector tool
To help collect all necessary log_files and information for a support case, a tool named
logcollector is available. The tool is located in the %install_dir%/IBM/Director/bin
directory. It is a command line tool and creates a packed report file in the following format
dirlogs-systename-date-time.zip. This report per default is located in the user home
directory from the user that runs the logcollector tool.
The logcollector tool collects information from and runs checks with the following parts:
Common Agent on the system

IBM Systems Director database
Network Control
Platform Agent information
IBM Systems Director server Core (actual status and configuration of the server)
Server JavaCoreDump
smcli collection
Storage Control collection
Local System collection (network configuration, systeminfo, firewall)
499
The size of the report file depends on the number of installed advanced managers and the
number of endpoints managed by the IBM Systems Director server.
The report file has a data structure like what is shown in Figure 12-5. There can be more
information in the report when, for example, Network Control and Storage Control are
installed on the server.
Figure 12-5 Logcollector report file: data structure
This report file is often needed by the support if there are problems with IBM Systems
Director and a defect call is opened.
In some rare cases, especially in large environments, the log collector can fail to collect all
information because of a timeout problem. The client might not see this because a report file
is created that contains all log information until the time of failure.
To avoid this problem, increase the time that the program waits for commands to complete.
Run the following command:
logcollector -t 600
Where: The value of -t 600 defines a 5-minute (set in seconds) time to wait for completion.
The default value is 120 seconds (2 minutes).
12.2 Troubleshooting security-related issues

If you are unable to log on to the Systems Director server or if the server fails to start, review
the logs to determine the error. You can increase the logging with Systems Director in two
ways:
lwilog.sh script
logging.properties file
If the server is active, use the lwilog.sh script as shown in Figure 12-6.
-bash-3.2# /opt/ibm/director/lwi/bin/lwilog.sh -addlogger -name
com.ibm.lwi.security.rolemanagers.ldap -level FINEST
ALR0299I: Logger successfully added for package com.ibm.lwi.security.rolemanagers.ldap.
SUCCESS
-bash-3.2
Figure 12-6 lwilog.sh script
500
If the server is not active, edit the logging.properties file as shown in Figure 12-7.
-bash-3.2#echo -e "#additional LDAP
logging\ncom.ibm.lwi.security.rolemanagers.ldap.level=FINEST" >>logging.properties
Figure 12-7 Increase the logging level
The following additional logging attributes are available:

For the lwilog.sh script:
com.ibm.usmi.kernel.security -level FINEST
com.ibm.usmi.console.security -level FINEST
For the logging.properties file:
com.ibm.usmi.kernel.security.level=ALL
com.ibm.usmi.console.security.level=ALL
After the logging threshold is changed by using the lwilog.sh script, refresh the logs by
using the -refresh parameter:
/opt/ibm/director/lwi/bin/lwilog.sh -refresh
If you edit the logging.properties file, restart the Systems Director server. Log files are
stored in the /opt/ibm/director/lwi/logs/error-log-0.html directory.
12.2.1 Restoring local OS authentication

To restore Systems Director to use local OS authentication, use the cfguserreg.sh script
(Figure 12-8). Before you use the script, restore the original security.properties file.
Remove the securityLDAP.properties file from the /opt/ibm/director/lwi/conf/overrides/
directory.
-bash-3.2# cfguserreg.sh -os
/opt/ibm/director/bin
Security settings have been set to use operating system registry.
Restart IBM Systems Director Server to complete configuration.
-bash-3.2#smstop;smstart;smstatus -r
active.
Starting
Active
Figure 12-8 cfguserreg.sh script
12.2.2 Additional information

For OpenLDAP support with Systems Director, see the IBM Support Portal:
http://ibm.com/support/search.wss?q1=openldap&tc=SGZ2Z3
For common troubleshooting steps with LDAP, see this site:
http://ibm.com/support/docview.wss?uid=nas7917752a664b2c71a8625768e0001ab13
501
For additional common troubleshooting steps with LDAP, see the following site:
http://ibm.com/support/docview.wss?uid=nas7cf1a05b97228ef0d86257749007b7025
12.3 Troubleshooting VMControl

This section covers troubleshooting steps for the VMControl advanced manager plug-in.
12.3.1 KVM troubleshooting

This section describes basic operations for common troubleshooting tasks with Kernel-based
Virtual Machine (KVM) on Red Hat Enterprise Linux and IBM Systems Director VMControl.
Handling request access failures with Common Agent

The management software uses an agent manager to communicate with Common Agent
after it is installed on a managed system.
The agent manager provides authentication and authorization services for installed common
agents and the management software. It also maintains a registry of configuration information
about Common Agent-managed systems.
There are several actions that you can take to investigate and resolve Request Access
failures for a system that is managed by IBM Systems Director and has Common Agent
installed:
Ensure that the system is not being managed by more than one agent manager
An IBM Systems Director-managed resource can be managed by only one agent manager
at a time. If the managed resource is an operating system and IBM Systems Director
stops managing it, its agent is not unregistered from the agent manager. To manage the
agent with IBM Systems Director unregisters the agent manually.
Query current manager
On the operating system endpoint, query the usma service detail information to determine
the current agent manager. Issue the following command that is applicable for the
managed compute node operating system. See Example 12-1.
Note: To run the following command on a system with Virtual I/O Server (VIOS), you must
first exit the restricted shell. To get out of the restricted shell, run the oem_setup_env
command before you attempt to query the usma service detail information.
AIX or Windows:
slp_query --type=* --address=<system_IP_address>
See Example 12-1 for the querying manager in Linux.
Example 12-1 Querying manager in Linux
[root@node11229 ~]# /opt/ibm/icc/bin/slptool -u 127.0.0.1 findattrs

service:management-software.IBM:usma
([email protected]@10.31.21.148),(mac-address=3440B5BE9178),(t
ivguid=CE32DB6061CD11E2BFC63440B5BE9178),(uid=31322f0d5b16c1ea),(uuid=C4E2DA1E-206
D-11E2-A23E-3440B5BE9178),(vendor=IBM),(System-Name=node11229),(timezone-offset=12
0),(version=6.3.2),(port=9510),(manager=10.31.54.199)
502
Reconnect host to manager:

On the operating system endpoint, issue the following command that is applicable for the
managed compute node operating system:
AIX or Linux
/opt/ibm/director/agent/runtime/agent/toolkit/bin/configure.sh -unmanaged
-force
Windows
<install_root>\agent\runtime\agent\toolkit\bin\configure.bat -unmanaged -force
Remove the operating system endpoint from the IBM Systems Director and rediscover the
operating system endpoint, then request access again.
Ensure that you are using the correct user ID and password
When requesting access to a secured system from the IBM Systems Director Request
Access page, you cannot enter a password longer than 45 characters. The Request
Access task has a password length limit of 45 characters.
Additional characters are ignored. You cannot gain access to a Common Agent-managed
system by using a user credential that has a password greater than 45 characters in
length. To correct this problem, shorten the password on the managed system to gain
access.
Tip: Check by manually logging in to the managed system via SSH, Telnet (tn), or
mstsc.exe to confirm that the password is correct.
Many browsers pre-fill the password field. Empty it and ensure that it is the correct
password.
Check the firewall
Request Access requires a reliable connection between the IBM Systems Director and
Common Agent. You need a connection in both directions: agent to server and server to
agent. Ensure that you can use SSH, Telnet (tn), or mstsc.exe from either direction.
Agent and server-side example checks follow (Example 12-2):
Windows agent side:
telnet ISD_IPADDR 9513
AIX or Linux agent side:
/opt/ibm/director/agent/runtime/agent/toolkit/bin/checkconn.sh -host AM_IP
-password AM_password
Example 12-2 Connection check in Linux
[root@node11229 ~]#
/opt/ibm/director/agent/runtime/agent/toolkit/bin/checkconn.sh -host
10.31.54.199 -password PASSW0RD
BTC8614I The connection to the agent manager has been established successfully.
BTC8619I The common agent would register successfully with the given password.
Windows:
<install_root>\agent\runtime\agent\toolkit\bin\checkconn.bat -host AM_IP
-password AM_password
503
Server side:
Test from IBM Systems Director server that network connectivity to CAS agent is valid:
telnet Agent_IP 9510
Check to see if the IBM Systems Director IP address has changed:
If there is an IBM Systems Director IP address change, restart the server before issuing a
Request Access. A correct server IP address is a prerequisite for Request Access.
You can run the following commands to check the IP address. See Example 12-3.
Example 12-3 Check that Systems Director is in the correct IP address
[root@node11229 ~]# wget -O AgentMgr.Info http://10.31.54.199:9513/AgentMgr/Info
--2013-04-18 22:08:17-- http://10.31.54.199:9513/AgentMgr/Info
Connecting to 10.31.54.199:9513... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: AgentMgr.Info
[ <=>
15,374
]
--.-K/s
in 0s
2013-04-18 22:08:17 (68.9 MB/s) - AgentMgr.Info
Agent Health check. See Example 12-4.

AIX or Linux:
/opt/ibm/director/lwi/runtime/agentmanager/toolkit/bin/HealthCheck.sh
-toolkitPassword AM_password
Windows:
<install_root>\lwi\runtime\agentmanager\toolkit\bin\HealthCheck.bat
-toolkitPassword AM_password
Example 12-4 Agent Health check
C:\Program Files\IBM\Director\lwi\runtime\agentmanager\toolkit\bin>HealthCheck.bat -toolkitPassword Salasana1
CTGEM2470I It is the agent manager instance ID: 7e61ca6dd647361cbcd94863afc27cd8
AGENT_CONFIG_SERVICE
CRL_REQUEST
MULTI_SCHEDULER_SYNCHRO_SERVICE
FILE_DOWNLOAD_SERVICE
UPGRADE_SERVICE
REGISTRATION_SERVICE
SERVICE_CATALOGUE_REQUEST
AGENT_MANAGER_QUERY
AGENT_QUERY
MIGRATION_SERVICE
MANAGER_CREDENTIALS_SERVICE
TRUSTSTORE_REQUEST
PATCH_SERVICE
COMMON_AGENT_QUERY
CERT_REVOCATION_SERVICE
SCHEDULER_ADMIN_SERVICE
DELETE_AGENTS_SERVICE
SCHEDULER_SYNCHRO_SERVICE
VERSION_SERVICE
DEREGISTER_SERVICE
CONFIG_UPDATE_SERVICE
CERT_RENEWAL_SERVICE
FILE_ADMIN_SERVICE
INFO_PAGE
IPADDRESS_SERVICE
JOB_MANAGER_SERVICE
CTGEM2450I The Health Check tool passed.
504
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
https://127.0.0.1:9512/AgentMgr/AgentConfiguration
http://127.0.0.1:9513/AgentMgr/CRLRequest
https://127.0.0.1:9512/AgentMgr/MultiScheduleSynchronizer
http://127.0.0.1:9513/AgentMgr/Patches
https://127.0.0.1:9512/AgentMgr/UpgradeService
https://127.0.0.1:9511/AgentMgr/Registration
http://127.0.0.1:9513/AgentMgr/ServiceCatalogueRequest
http://127.0.0.1:9513/AgentMgr/AgentManagerQuery
https://127.0.0.1:9512/AgentMgr/AgentQuery
https://127.0.0.1:9512/AgentMgr/MigrationService
https://127.0.0.1:9512/AgentMgr/AuthAdmin
http://127.0.0.1:9513/AgentMgr/TrustedCertificateQuery
https://127.0.0.1:9512/AgentMgr/PatchService
https://127.0.0.1:9512/AgentMgr/CommonAgentQuery
https://127.0.0.1:9512/AgentMgr/CertificateRevocation
https://127.0.0.1:9512/AgentMgr/ScheduleManager
https://127.0.0.1:9512/AgentMgr/DeleteAgents
https://127.0.0.1:9512/AgentMgr/ScheduleSynchronizer
http://127.0.0.1:9513/AgentMgr/Version
https://127.0.0.1:9512/AgentMgr/DeregistrationService
https://127.0.0.1:9512/AgentMgr/ConfigurationUpdate
https://127.0.0.1:9512/AgentMgr/CertificateRenewal
https://127.0.0.1:9512/AgentMgr/PatchAdmin
http://127.0.0.1:9513/AgentMgr/Info
http://127.0.0.1:9513/AgentMgr/IPAddress
https://127.0.0.1:9512/AgentMgr/JobManager
Check the Common Agent status. See Example 12-5.

Request Access requires that the Common Agent is in good status. You can run the
following queries to check agent status:
AIX or Linux
Example 12-5 Check endpoint status in host
[root@node11229 director]#
/opt/ibm/director/agent/runtime/agent/bin/endpoint.sh status
Running.
Example 12-6 shows the test connector status.
Example 12-6 Test connector
/opt/ibm/director/agent/runtime/agent/bin/agentcli.sh connector alive
BTC7101I The connector is active.
Windows:
<install_root>\agent\runtime\agent\bin\endpoint.bat status Running.
<install_root>\agent\runtime\agent\bin\agentcli.bat connector alive BTC7101I
The connector is active.
If the Common Agent status is not active, complete the following steps:
Issue the following command to check to ensure that the SLP is in an operational state.
See Example 12-7.
Example 12-7 Check that you have SLP services running
[root@node11229 director]# ps
daemon
25079
1 0 Jan30
root
25672 27826 0 23:15
root
25700
1 0 Jan30
-ef|grep
?
pts/3
?
slp
00:08:32 /opt/ibm/icc/bin/slpd
00:00:00 grep slp
00:00:04 /opt/ibm/platform/bin/tier1slp
Test from IBM Systems Director server that you can connect the Common Agent host to
port 427:
telnet AGENT_IPADDRESS 427
If you cannot reach the port, the SLP service is not working properly.
In this case, you might need to install with yum openslp package. Restart the server and
remove the Common Agent host from the Systems Director inventory and place the host
in the unmanaged state.
Common Agent running on AIX or Linux:
/opt/ibm/director/agent/runtime/agent/toolkit/bin/configure.sh -unmanaged
-force
Common Agent running on Windows:
<install_root>\agent\runtime\agent\toolkit\bin\configure.bat -unmanaged -force
After that, perform the following command on the Common Agent host.
Common Agent running on AIX or Linux:
/opt/ibm/director/agent/runtime/agent/toolkit/bin/configure.sh -amhost
agentmanager_IP_address -passwd agentregistration_password -force
505
Common Agent running on Windows:

<install_root>\agent\runtime\agent\toolkit\bin\configure.bat -amhost
active_agent_manager_IP_address -passwd active_agent_registration_password
-force
Discover the Common Agent host from the Systems Director user interface and connect it
with root credentials.
Check DNS settings:
Ensure that the DNS is set correctly on the agent system. If no DNS is configured, check
the hosts files on the agent system. The following entry is available:
- 127.0.0.1 localhost
- ::1 localhost
Note: -:1 localhost applies only if there are IPv6 addresses.
Every global IP address should be mapped to the host name of the endpoint.
12.3.2 VMware vSphere troubleshooting

This topic describes common problems when working with IBM Systems Director and
VMware environments.
Launching VMware management software

From VMControl, you can open VMware management software such as the VMware vSphere
Client or the VMware Infrastructure Client. To launch a VMware client from IBM Systems
Director VMControl, the VMware client must be installed in the default location:
C:\\Program Files (x86)\\VMware\\Infrastructure\\Virtual Infrastructure Client\\
Launcher\\VpxClient.exe
However, if you installed the VMware client in a different location, you can use a text editor to
create a properties file to override the default location. Create the file named
vmcontrolvmware.properties in the following directory on your IBM Systems Director server
system:
AIX or Linux:
install_path/ibm/director/lwi/conf/overrides/vmcontrolvmware.properties
Windows:
install_path\IBM\Director\lwi\conf\overrides\vmcontrolvmware.properties
The install_path field is the location where IBM Systems Director is installed.
You can copy the following sample and paste it into your vmcontrolvmware.properties file.
Revise it to specify where the VMware client is installed in your environment. Ensure that the
installation path is all on one line in the vmcontrolvmware.properties file that you create:
RequiredPathToClientVC4=C:\\Program Files\\VMware\\Infrastructure\\Virtual
Infrastructure Client\\Launcher\\VpxClient.exe
RequiredPathToClientVC5=C:\\Program Files\\VMware\\Infrastructure\\Virtual
Infrastructure Client\\Launcher\\VpxClient.exe
The defined variable must be formatted as a Windows path with file separators specified as \\.
506
The following variables map to versions of VMware software:

RequiredPathToClientVC4 = VMware vCenter 4
RequiredPathToClientVC5 = VMware vCenter 5
Note: After the vmcontrolvmware.properties file has been created to set the defined
VMware client installation path, every Windows system that is used to launch the VMware
client must have the VMware Infrastructure Client installed in the specified location.
After the vmcontrolvmware.properties file is created, you must collect inventory on the
VMware vCenter systems.
To launch a VMware client, complete the following instructions.
In the IBM Systems Director navigation pane, click Resource Explorer to locate the host or
virtual server from which you want to start the VMware client. Right-click the host or virtual
server, and select VMware Client. The VMware client is started in a new window.
VMware ESXi hosts not discovered in a BladeCenter chassis

This problem affects discovery of VMware ESXi version 4.0 hosts in a BladeCenter chassis:
Problem
During discovery of multiple VMware ESXi version 4.0 operating

systems, only one server-managed endpoint is associated after the
request access task completes. The problem occurs if the
BladeCenter chassis has not been discovered and request access has
not been granted before discovering the operating system with
VMware ESXi version 4.0.
Explanation
In VMware ESXi version 4.0, the same IP address is commonly

surfaced for all of the VMware ESXi hosts. IBM Systems Director
interprets the same IP address as the same hardware. This problem is
resolved in VMware ESXi version 4.1 or later versions.
Resolution
Remove the VMware ESXi host systems and the single server
managed endpoint. Discover the BladeCenter chassis and request
access to it. Rediscover the VMware ESXi operating systems and
request access. The servers are now associated properly to each
VMware ESXi operating-system managed endpoint.
12.3.3 PowerVM troubleshooting

This section covers the troubleshooting for PowerVM.
HMC discovery
Ensure that the ID that is used to request access to the HMC has hmcsuperadmin rights or
hmcoperator rights.
Check the status of the following protocols: SSH and CIM.
VMControl NIM subagent

If the VMControl subagent installation fails, check the following error logs for detailed error
messages:
AIX or Linux: director/agent/logs/*.xml
Windows: director\agent\logs\*.xml
Where: The director field is the path where IBM Systems Director is installed.
507
For more information about how to install the IBM Systems Director VMControl subagent
manually, see the following site:
oc/fsd0_vim_t_installing_agent_manual.html
For additional configurations after the installation, see the following information center link:
oc/fqm0_t_configuring_vmc.html
Check if the SLP query lists required services advertisement:
# slp_query --type=* --address=10.32.42.98
...
URL: service:wbem:http://10.32.42.98:5988
URL: service:wbem:https://10.32.42.98:5989
ATTR: (template-url-syntax=https://10.32.42.98:5989) (https://10.32.42.98:5989%29)
URL: service:management-software.IBM:platform-agent://10.32.42.98
ATTR:
(vendor=IBM),(version=6.3.3),(uid=7F836092D21E574B),(ip-address=10.32.42.98),(host
name=ip10-32-42-98.pokprv.stglabs.ibm.com)
URL: service:management-software.IBM:usma://ip10-32-42-98.pokprv.stglabs.ibm.com
ATTR:
(ip-address=10.32.42.98),(mac-address=8e.15.19.c7.f3.3),(tivguid=A0F2F5A6AC5311E2B
A4A8E1519C7F303),(uid=7f836092d21e574b),(vendor=IBM),(System-Name=ip10-32-42-98.po
kprv.stglabs.ibm.com),(timezone-offset=-240),(version=6.3.3),(port=9510),(manager=
unmanaged)
URL: service:TivoliCommonAgent://ip10-32-42-98.pokprv.stglabs.ibm.com:9510
ATTR:
(ca-uid=file:///var/opt/tivoli/ep/runtime/agent),(am-host=null),(ca-ips=10.32.42.9
8),(ca-basic-port=9510),(ca-cert-port=9510),(ca-version=1.4.2.4),(os-uid=A0F2F5A6A
C5311E2BA4A8E1519C7F303)
URL: service:service-agent://10.32.42.98
ATTR: (service-type=service:management-software.IBM:usma,service:service-agent)
Virtual server relocation validation

If you are not able to perform a relocation, check from your HMC if the logical partition (LPAR)
is valid to be relocated:
1. Go to Servers and then select the host where your LPAR is located.
2. Select the server and open the pop-up menu.
3. Select Operations Mobility Validate (Figure 12-9 on page 509).
508
Figure 12-9 HMC Partition Migration Validation page
12.4 Troubleshooting AIX Profile Manager

When having problems with AIX Profile Manager, consider the following troubleshooting tips:
When deploying a template, all logs are available in the Task Management tab. Locate the
job, open it, and go to the Logs tab. Everything is logged here.
When using IBM security AIXPert, all logs are available in the /etc/security/aixpert/log
directory.
With artex commands, you can specify a debug level to have more information when a
command is not working properly. The debug level must be specified in the
/etc/security/artex/artex.conf file.
12.5 Troubleshooting Workload Partition Manager

This section shows some examples that can help in case you have issues in your
environment with the WPAR Manager.
12.5.1 WPAR-capable system does not appear in WPAR Manager console

Check the basic requirements:
1. Does the managed system have the IBM Systems Director Common Agent installed?
509
Use the lslpp command as shown in Example 12-8 to check if IBM Systems Director
Common Agent is installed on the server.
Example 12-8 Checking if IBM Systems Director Common Agent is installed on the managed system
lslpp -l DirectorCommonAgent
Fileset
Level State
Description
DirectorCommonAgent
6.2.1.3 COMMITTED All required files of Director
Common Agent, including JRE,
LWI
Path: /etc/objrepos
DirectorCommonAgent
6.2.1.3
COMMITTED
All required files of Director

Common Agent, including JRE,
LWI
2. Is the managed system discovered and fully inventoried in IBM Systems Director?
3. Is the WPAR Manager Agent installed on the managed systems?
Use the lslpp command as shown in Example 12-9 to check if WPAR Manager Agent is
installed on the server.
Example 12-9 Check if WPAR Manager Agent is installed on the managed system
lslpp -l wparmgt.agent.rte
Fileset
Level State
Description
wparmgt.agent.rte
2.3.1.1 COMMITTED Workload Partitions Manager
Agent
Path: /etc/objrepos
wparmgt.agent.rte
2.3.1.1
COMMITTED
Workload Partitions Manager

Agent
4. Have you run an inventory with the Extended WPAR Inventory profile enabled on the
managed system, as shown in Figure 12-10.
Figure 12-10 Run the inventory with Extended WPAR Inventory profile
12.5.2 Remove WPAR from Director

In some cases, you might still see a WPAR on a managed system in IBM Systems Director
after it has been removed by using the smcli rmwpar command. To definitely remove the
WPAR from IBM Systems Director server, go to the IBM Systems Director console in WPAR
Manager Plug-ins and then click View workload partitions, as shown in Figure 12-11 on
page 511.
510
Figure 12-11 Remove WPAR from IBM Systems Director
Select the WPAR. Then, click Actions Remove and click OK.
Go back to the command line and run the smcli lswpar command. It should produce the
following result, as shown in Example 12-10.
Example 12-10 List WPAR with CLI
smcli lswpar
DNZWML806E No valid WPAR target(s) found.
12.5.3 Creating WPARs

Creating a WPAR by using an IP that is already used on another WPAR in the same managed
system is not possible. The creation task will fail. If the creation is done on another managed
system, the task will be successful but you end up with two WPARs sharing the same IP.
12.5.4 WPAR logs

All WPAR operation logs can be found on managed systems in the
/var/adm/wpars/event.log file, as shown in Example 12-11.
Example 12-11 Event.log
cat /var/adm/wpars/event.log
V 2013-04-26 09:38:52 7667912
V 2013-04-26 09:38:53 9961476
I 2013-04-26 09:38:53 7667912
I 2013-04-26 09:38:53 7667912
'wpar3test1'.
I 2013-04-26 09:38:53 7667912
file systems.
I 2013-04-26 09:38:54 7667912
I 2013-04-26 09:38:54 7667912
devices.
I 2013-04-26 09:38:55 7667912
I 2013-04-26 09:38:55 7667912
I 2013-04-26 09:38:55 7667912
1
I 2013-04-26 09:38:55 7667912
I 2013-04-26 09:38:55 7667912
I 2013-04-26 09:38:55 7667912
I 2013-04-26 09:38:55 7667912
3
I 2013-04-26 09:38:55 7667912
3
startwpar - COMMAND START, ARGS: wpar3test1

ckwpar wpar3test1 ckwpar: Passed.
startwpar wpar3test1 Lock acquired.
startwpar wpar3test1 Starting workload partition
startwpar wpar3test1 Mounting all workload partition
startwpar wpar3test1 Loading workload partition.
startwpar wpar3test1 Exporting workload partition
startwpar wpar3test1 Exporting device /dev/null, 1
startwpar wpar3test1 Exporting device /dev/tty, 1
startwpar wpar3test1 Exporting device /dev/console,
startwpar
startwpar
startwpar
startwpar
wpar3test1
wpar3test1
wpar3test1
wpar3test1
Exporting
Exporting
Exporting
Exporting
device
device
device
device
/dev/zero, 1
/dev/clone, 1
/dev/sad, 3
/dev/xti/tcp,
startwpar wpar3test1 Exporting device /dev/xti/tcp6,
511
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/xti/udp,

3
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/xti/udp6,
3
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device
/dev/xti/unixdg, 3
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device
/dev/xti/unixst, 3
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/error, 1
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/errorctl,
1
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/audit, 1
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/nvram, 1
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting device /dev/kmem, 1
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Exporting workload partition
kernel extensions.
W 2013-04-26 09:38:55 9765080 lswpar - lswpar: 0960-679 wpar3test1 has no kernel
extension configuration.
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Starting workload partition
subsystem 'cor_wpar3test1'.
I 2013-04-26 09:38:55 7667912 startwpar wpar3test1 Verifying workload partition
startup.
V 2013-04-26 09:38:56 12124344 runwpar - COMMAND START, ARGS: wpar3test1
E 2013-04-26 09:38:56 12124344 runwpar wpar3test1 runwpar: 0960-246 Workload
partition 'wpar3test1' is currently locked by startwpar (PID = 7667912).
I 2013-04-26 09:38:56 12124344 runwpar wpar3test1 Starting workload partition
init.
I 2013-04-26 09:38:56 12124344 runwpar wpar3test1 Removing work directory
/tmp/.workdir.9764952.12124344_1
I 2013-04-26 09:38:56 7667912 startwpar wpar3test1 Lock released.
I 2013-04-26 09:38:56 7667912 startwpar wpar3test1 Removing work directory
/tmp/.workdir.9961680.7667912_1
V 2013-04-26 09:38:56 7667912 startwpar wpar3test1 Return Status = SUCCESS.
12.6 Troubleshooting Storage Control

This section includes the basic troubleshooting steps that should be followed for IBM Systems
Director Storage Management.
12.6.1 Runtime log locations

The IBM Systems Director runtime storage management logs can be found in the following
specified locations:
On Microsoft Windows:
<IBM Systems Director installation location>\director\lwi\logs\
C:\Program Files\IBM\TPC\device\log\
On Linux/AIX:
/opt/ibm/director/lwi/logs/
/opt/IBM/TPC/device/log/
512
IBM Systems Director Storage Control logs are also included as part of log collection when a
user runs the following command:
On Microsoft Windows:
<IBM Systems Director installation location>\Director\bin\logcollector.bat
On Linux/AIX:
<IBM Systems Director installation location>/director/bin/logcollector.sh
12.6.2 Troubleshooting
Troubleshooting steps for various storage management-related issues are documented in the
following IBM Systems Director information center link:
r.tbs.helps.doc%2Ffqm0_r_tbs_sm_storage_troubleshooting.html
Troubleshooting the basic tasks speeds up the configuration time that is taken. Following are
some of the storage management issues related to discovery and inventory tasks:
Unable to remove storage device by using the rmdatasource command
Description:
There is a rare case where a user might try to remove a data source from their Storage
Control server using the rmdatasource command or the remove data source function in the
GUI, but the data source will not be removed. The commands return with a success
message even though the data source is still there if the client lists them using the smcli
lsdatasource command.
Resolution:
The reason this is happening is due to a timeout issue in the TPC database when it is
attempting to remove the device from the database. The TPC server has a default timeout
value but it might not be sufficient in some cases. There is not a fix. The default timeout
value is a permanent restriction.
Unable to discover Storage Management Initiative Specification (SMI-S) Provider Agent
that is installed on a system with multiple IP addresses
Description:
There might be an issue in discovering the SMI-S Provider Agent system with dual IPs
configured.
Resolution:
If the network of the system is configured with dual IPs and the SMI-S provider is
installed on the dual IP systems, the provider will be listening to both of the dual IPs.
Under this situation, running the discovery profile to discover the SMI-S protocol for
one of the IPs will not discover the DSxxxx storages.
A user must run the Discovery profile for both of the dual IPs so that SMI-S protocol will
be discovered for both the IPs to discover the DSxxxx storages in IBM Systems
Director.
Inventory on a V7000/SAN Volume Controller (SVC) might fail after performing a Tier 3 or
4 recovery procedure on the storage
Description:
After the V7000/SVC gets managed in IBM Systems Director, the inventory on
V7000/SVC fails after a Tier 3 or 4 recovery procedure is performed on the storage.
513
Resolution:
i. Run the following command to remove the storage from the IBM Systems Director
server command line:
smcli rmdatasource -c svc -i <storageIP>
ii. Run the following command to add the storage back into IBM Systems Director
server:
smcli mkdatasource -c svc -i <storageIP> -f <sshKeyPath> -r
<keyPassphrase>
Cannot rediscover a Storage Farm object after the farm was removed manually
Description:
If the Storage Control Farm object is not removed completely or if the process of removing
it is interrupted, the farm resource still exists in the IBM Systems Director internal
database and the rediscovery task cannot create a new Storage Control Farm object.
Resolution:
The resolution is to remove the Farm resource instance and then rediscover the Farm
MEP.
On the IBM Systems Director server command line, run the following commands:
i. Locate the Globally Unique Identifier (GUID) value from the output of the following
command:
smcli lsresource farm
ii. Run the following command to remove the Storage Control Farm object:
smcli rmresource (GUID of the farm obtained from Step 3 above)
iii. Change directory to: <IBM Systems Director installation path>/StorageControl/bin
and run the following command, which discovers the Storage Control Farm object:
SCDiscoverUnlock.sh
Inventory collection on Storage Control Farm object fails
Description:
When a user performs an inventory collection on the Storage Control Farm object, it might
complete with errors.
Resolution:
The inventory collection issue can be due to one of the following reasons:
Caused by the wrong data stored in DB2 by Storage Control.
Caused due to the wrong credentials. This can result in the inappropriate access
state occurring to the Storage Control Farm object.
To fix this problem, complete the following steps:

i. From the IBM Systems Director command line, change the directory to:
<IBM Systems Director installation path>/StorageControl/bin and run the
following command:
SCDiscoverUnlock.sh
ii. Collect the inventory on the associated Storage Control Farm object from the
IBM Systems Director web console or by running the following command:
smcli collectinv -n <name of the farm object> -p All Inventory
514
Inventory collection on Storage Control Farm object fails

Description:
If the Storage Control Farm object is managing an IBM Storwise V7000 and some of the
disk drives in V7000 show as offline and have enclosure IDs and slot IDs missing,
inventory on the Storage Control Farm object fails.
Resolution:
To resolve the inventory failed issue, perform the following steps:
i. Recover from the offline physical disk from V7000 (follow the fix procedure on
V7000 to fix the disk offline error).
ii. Remove the v7000 storage MEP from the IBM Systems Director server. See
Removing Storage Control-managed devices on page 487 to get more information
about how to remove storage devices.
iii. Add the v7000 storage by using the following command:
smcli mkdatasource -c svc -i <IP address of the v7000> -f <path to
generated private SSH Key on systems director server> -v V7000
iv. Collect the inventory on the associated Storage Control Farm object from the
IBM Systems Director web console or by running the following command:
smcli collectinv -n <name of the farm object> -p All Inventory
515
516
Appendix A.
Technical articles
This appendix provides information about sources of information for the IBM Systems
Director. This includes the IBM Systems Director Information Center, social media references
such as YouTube, and information about the IBM Systems Director forum and wiki.
There are also links provided for downloading IBM Systems Director components and other
additional, useful links.
517
A.1 Information center

One of the first sources to go to for information is the IBM Systems Director Information
Center. The Systems Director Information Center is an online and regularly updated version
of the Systems Director product publications. For the latest version of Systems Director, see
the following website:
If you use older versions of Systems Director, see the URLs listed in Table A-1.
Table A-1 Information center links
IBM Systems
Director version
Information center
6.2.x
Systems Director version 6.2.x Information Center:

http://publib.boulder.ibm.com/infocenter/director/v6r2x/index.jsp
6.1.x
Systems Director version 6.1.x Information Center:

http://publib.boulder.ibm.com/infocenter/director/v6r1x/index.jsp
5.2.x
IBM Director version 5.20.x Information Center:

http://publib.boulder.ibm.com/infocenter/eserver/v1r2/topic/diricinfo
_5.20/fqm0_main.html
In the information centers, you can search for information about the installation, configuration,
management, and problem determination. You can also download the PDF versions of the
Installation Guide, Planning Guide, Troubleshooting Guide, and Systems Management Guide.
A.2 Social media and support

Other users can be a great source of help with IBM Systems Director. You can connect to
them over the IBM forum, the wiki, or see information and comments on YouTube and
Facebook. There are also information messages available through the My Notification
function.
A.3 Forum
The IBM Systems Director Forum is available at the following link:
http://www.ibm.com/developerworks/forums/forum.jspa?forumID=759
This forum provides a place for all IBM Systems Director topics. You can post your questions
and comments and share your thoughts, ideas, and solutions with other users.
518
The forum also offers an RSS feed. Click the orange RSS icon to access the RSS
subscription page. You can then select the method to use to subscribe to the feed and click
Subscribe Now (Figure A-1).
Figure A-1 Systems Director Forum RSS feeds
A.4 Wiki
There are two wikis for IBM Systems Director. Both wikis are focused on IBM Systems
Director running on a Power Systems platform. However, some of the information applies to
all platforms:
IBM Systems Director Wiki:
https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en#/wiki/Po
wer%20Systems/page/IBM%20Systems%20Director
IBM Systems Director Best Practices Wiki:
56c32_416f_a604_4633cd375569/page/Best%20Practices
Appendix A. Technical articles
519
A.5 YouTube channel

To subscribe to this channel, go to http://www.youtube.com/user/IBMSystemsDirector/feed
(Figure A-2) and click Subscribe.
Figure A-2 Systems Director at YouTube
A.6 My Notifications email announcements

With My Notifications, you can subscribe to support updates for any IBM product.
Tip: The My Notifications tool replaces My Support, a similar tool.
520
With My Notifications, you can specify that you want to receive daily or weekly email
announcements. You can specify the type of information that you want to receive:
Publications
Hints and tips
Product flashes (also known as alerts)
Downloads
Drivers
With My Notifications, you can customize and categorize the products about which you want
to be informed and the delivery methods that best suit your needs.
Complete the following steps to subscribe to My Notifications:
1. Go to http://www.ibm.com/support/mynotifications.
2. Enter your IBM ID and password and click Submit.
3. Identify the updates that you want to receive and the method through which you want to
receive them:
a. Click the Subscribe tab.
b. Select IBM Systems Director.
c. Specify or select your notifications and other preferences.
d. Click Submit.
A.7 Education and training

IBM offers various educational offerings, including instructor-led online (ILO) courses,
classroom courses, virtual learning courses, private/on-site training, and web-based learning
videos. Links are available in the IBM Systems Director console for online training.
521
A.8 Integrated education modules in IBM Systems Director

The Systems Director console provides links for online training. The links are on the Systems
Director Home page under the Learn tab, as shown in Figure A-3.
Figure A-3 IBM Systems Director console Home page
522
On the Learn page, you can see the available learning modules for Systems Director
(Figure A-4).
Figure A-4 Learn tab
523
When you click one of the topics, you link to the Systems Director Information Center website.
Videos for the selected topic are displayed. In our example, we select the Managing system
access and security topic (Figure A-5).
Figure A-5 Managing system access and security module
You can also access the training modules at the Systems Director Information Center through
the following link:
r.main.helps.doc%2Ffqm0_c_elearning.html
524
A.9 Education courses

The following classroom (XTR) courses and ILO (XTV) courses for IBM Systems Director 6.3
are available in the US at the time of writing:
XTR/XTV 42: IBM Systems Director 6.3 Hands-on Workshop
XTR/XTV 46: IBM Systems Director 6.3 - Introduction
XTR/XTV 47: IBM Systems Director 6.3 for IBM System x and BladeCenter Servers Base
XTR/XTV 48: IBM Systems Director 6.3 for IBM System x and BladeCenter Servers Advanced
XTRD1+2/XTVD1+2: IBM Systems Director 6.3 for IBM System x and BladeCenter
Servers
AN940/AX940: IBM Systems Director 6.3 for Power Systems I: Installation and
Management
A self-paced virtual class (SPVC) is available:
AN0D0/XTRD0: IBM Systems Director 6.3 - Power and System x - Planning and
Installation
The availability of onsite or classroom training depends on your country. For detailed
information about the offerings in your country, see the following link:
http://www-304.ibm.com/jct03001c/services/learning/ites.wss/zz/en?pageType=page&c=
a0011023
Complete the following steps to check the availability of learning courses in your country:
1. Go to the following link:
http://www-304.ibm.com/jct03001c/services/learning/ites.wss/zz/en?pageType=page
&c=a0011023
2. Select your country and click the arrow.
3. Scroll to the bottom of the page and click Search for training courses.
4. Type IBM Systems Director 6.3 in the search field and click Search.
5. The available courses are displayed.
6. Select your course.
A.10 Downloads
All downloads for Systems Director, including server, agents, and plug-ins or advanced
managers, are at the following link:
http://ibm.com/systems/software/director/downloads
On the Downloads overview page, you can view information about the recent product updates
that you can download (Figure A-6 on page 526). By selecting the tabs for Management
servers, Agents, Plug-ins, and Partner integration, you can access the pages for download.
You need an IBM ID to download the codes. If you do not have an IBM ID, you can request
one on the website where the ID is required. The IBM ID is available at no charge.
525
Figure A-6 Downloads for Systems Director
A.11 Other useful links

The following references are useful:
IBM websites about System x, BladeCenter, and Flex Systems:
xREF: IBM x86 Server Reference:
http://www.redbooks.ibm.com/xref
IBM Configuration and Options Guide (COG):
http://ibm.com/support/entry/portal/docdisplay?lndocid=SCOD-3ZVQ5W
BladeCenter Interoperability Guide (BIG):
http://ibm.com/support/entry/portal/docdisplay?lndocid=MIGR-5073016
IBM Flex System Interoperability Guide:
http://www.redbooks.ibm.com/fsig
IBM ToolsCenter (ServerGuide, Bootable Media Creator, Advanced Settings Utility):
http://ibm.com/support/entry/portal/docdisplay?lndocid=TOOL-CENTER
IBM Information Center:
IBM Systems Director Information Center:
526
IBM BladeCenter Information Center:

http://publib.boulder.ibm.com/infocenter/bladectr/documentation/index.jsp
IBM PureFlex System Information Center:
http://publib.boulder.ibm.com/infocenter/flexsys/information/index.jsp
IBM Power Systems Hardware Information Center (including IBM System p,
IBM System i, and Hardware Management Console information):
http://pic.dhe.ibm.com/infocenter/powersys/v3r1m5/index.jsp?topic=/ipha8/hwicwe
lcome.htm
External website:
IBM Quicklinks (link collection for IBM products):
http://www.ibmquicklinks.com
527
528
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.
IBM Redbooks
The following IBM Redbooks publications provide additional information about the topic in this
document. Note that some publications referenced in this list might be available in softcopy
only.
IBM Systems Director 6.3 Best Practices: Installation and Configuration, REDP-4932-00
IBM Systems Director Management Console: Introduction and Overview, SG24-7860-00
IBM CSM to IBM Systems Director Transformation Guide, SG24-8002-00
You can search for, view, download or order these documents and other Redbooks,
Redpapers, Web Docs, drafts, and additional materials, at the following website:
ibm.com/redbooks
Online resources
These websites are also relevant as further information sources:
IBM Systems Workload Estimator for Systems Director 6.3:
Hardware requirements for IBM Systems Director:
ps.doc/fqm0_r_hardware_requirements.html
Supported operating systems:
ctor.plan.helps.doc%2Ffqm0_r_supported_operating_systems.html
Security features and considerations are documented in the information center at:
ctor.security.helps.doc%2Ffqm0_c_security.html
File system requirements that are needed for the installation are documented at this site:
ctor.plan.helps.doc%2Ffqm0_r_hardware_requirements_servers_running_aix.html
A list of all TCP/IP ports that are used by IBM Systems Director is provided at this site:
You can download lsof as part of the AIX Expansion Pack from this link:
http://www-03.ibm.com/systems/power/software/aix/expansionpack/index.html
529
Information about ports used by the server, managed systems, and important port
considerations:
IBM Tivoli Provisioning Manager for OS Deployment and IBM Tivoli Provisioning Manager
for Images, Version 7.1.1 information:
http://pic.dhe.ibm.com/infocenter/tivihelp/v3r1/index.jsp?topic=/com.ibm.tivoli
.tpm.osd.doc/welcome/osdhome.html
Preparing agentless managed systems:
ctor.install.helps.doc%2Ffqm0_t_preparing_agentless_managed_systems.html
Configuring access to agentless managed systems:
helps.doc/fqm0_t_setting_up_access_to_agentless_systems.html
Platform Agent systems:
ctor.main.helps.doc%2Ffqm0_c_platform_agent.html
Common Agent systems:
ctor.main.helps.doc%2Ffqm0_c_common_agent.html
Coexistence of Director V6 CAS Agent with other Tivoli CAS Agents:
56c32_416f_a604_4633cd375569/page/Coexistence+of+Director+V6+CAS+Agent+with+oth
er+Tivoli+CAS+Agents
Obtaining licenses for Common Agent:
helps.doc/fqm0_t_obtaining_licenses.html
Choosing the level of agent capabilities to deploy on managed systems:
ctor.plan.helps.doc%2Ffqm0_t_agent_tiers.html
Discovering systems that use a mirrored image:
ctor.discovery.helps.doc%2Ffqm0_t_discovering_systems_mirrored_image.html
Choosing the IBM Systems Director database application:
ps.doc/fqm0_t_selecting_the_ibm_director_database_application.html
Binding Platform Agent to specific IP addresses:
http://pic.dhe.ibm.com/infocenter/director/pubs/topic/com.ibm.director.agent.he
lps.doc/fqm0_t_binding_pa_specific_ip_addresses.html
530
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
Related publications
531
532
IBM Systems Director 6.3 Best

Practices
(1.0 spine)
0.875<->1.498
460 <-> 788 pages

Practices

Practices
Back cover
IBM Systems Director 6.3

Best Practices
Provides additional
guidance beyond
standard instructions
Covers basic and
advanced features
Learn from the
experts in the field
This IBM Redbooks publication describes the positioning of the IBM Systems Director in the
complete management range. It also compares the IBM Systems Director with the IBM
Flex Systems Manager (FSM) and describes the environments for which each tool is best
suited.
This publication helps you plan, install, tailor, and configure the IBM Systems Director on
different platforms. It contains information about required system resources and which network
ports are used. It shows how to use the Workload Estimator to select the appropriate hardware
for IBM Systems Director server and provides information about the IBM Systems Director
Editions.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
Best practices are covered for the basic management tasks that are available in IBM Systems
Director, including how to perform discovery; how to collect inventory on discovered resources;
how to deploy agent, driver, and firmware updates; how to manage hardware events; and other
miscellaneous tasks.
An overview of best practices is provided for using IBM Systems Director VMControl. Systems
Director VMControl is a cross-platform product that assists you in rapidly deploying virtual
appliances to create virtual servers that are configured with the operating system and software
applications that you want. It also enables you to group resources into system pools, which
enable you to centrally manage and control the different workloads in your environment.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
The following plug-in offerings are described:
Energy monitoring and management features offered by IBM Systems Director Active
Energy Manager along with the best practice, which needs to be followed in using the IBM
Systems Director Active Energy Manager.
The IBM AIX Profile Manager is a tool that can help implement and monitor the security of
all AIX servers in a production environment but also implement and monitor the system
compliance of those AIX servers.
Best practices and the most important questions to ask before creating Workload Partition
Manager (WPAR) and WPAR Manager infrastructure. In addition, how you can manage and
relocate WPARs using WPAR Manager graphical interface and the command-line interface.
Network Control basic functionalities and how to plan for Network Control deployments and
also a number of common scenarios with best practices.
The IBM Systems Director Service and Support Manager describes how to set up and how
to handle serviceable events.
Best practices for the Storage Monitoring and Management capabilities offered by IBM
This publication is for IBM IT specialists and IT architects, IBM Business Partners, and clients,
who are utilizing or considering implementing the IBM Systems Director.
IBM Redbooks are developed

by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:

ibm.com/redbooks
SG24-8141-00
ISBN 0738438650

System Director Sg248141

Uploaded by

Copyright:

Available Formats

System Director Sg248141

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Director Sg248141

Uploaded by

Copyright:

Available Formats

Front cover

IBM Systems Director 6.3

International Technical Support Organization

First Edition (November 2013)

Copyright International Business Machines Corporation 2013. All rights reserved.

Copyright IBM Corp. 2013. All rights reserved.

Chapter 4. Basic management tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

IBM Systems Director 6.3 Best Practices

Chapter 6. Active Energy Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.5.1 Working with power cap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 7. AIX Profile Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 8. Workload Partition Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 9. Network Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 10. Service and Support Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 11. Storage Management solutions and Storage Control. . . . . . . . . . . . . . .

IBM Systems Director 6.3 Best Practices

11.2.2 SMI-S provider installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 12. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix A. Technical articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IBM Systems Director 6.3 Best Practices

Copyright IBM Corp. 2013. All rights reserved.

The following terms are trademarks of other companies:

IBM Systems Director 6.3 Best Practices

Copyright IBM Corp. 2013. All rights reserved.

Rufus Credle is a Certified Consulting IT Specialist at the

IBM Systems Director 6.3 Best Practices

Nicolas Bour is a UNIX Systems Administrator in Switzerland.

Olaf Menke is a Consultant and Subject Matter Expert for

Now you can become a published author, too!

IBM Systems Director 6.3 Best Practices

Stay connected to IBM Redbooks

IBM Systems Director 6.3 Best Practices

Positioning IBM Systems

1.1, Description of IBM Systems Director on page 2

Copyright IBM Corp. 2013. All rights reserved.

1.1 Description of IBM Systems Director

1.2 Functionality of IBM Systems Director

IBM Systems Director 6.3 Best Practices

1.3 Positioning of IBM Systems Director

Figure 1-1 Positioning IBM Systems Director

Chapter 1. Positioning IBM Systems Director

IBM BladeCenter chassis management

1.4 IBM Systems Director and IBM Flex Systems Manager

IBM Systems Director 6.3 Best Practices

Figure 1-2 IBM Systems Director versus Flex Systems Manager

1.5 Best practices

Chapter 1. Positioning IBM Systems Director

IBM Systems Director 6.3 Best Practices

2.1, System resources on page 8

Copyright IBM Corp. 2013. All rights reserved.

2.1 System resources

Four processors, POWER5, IBM

Four processor cores (two

30 GB plus space for

Four processor cores (two

30 GB plus space for

30 GB plus space for

Recommendations are based on 64-bit Java virtual machine (JVM).

< 500 managed systems

500 > managed systems < 1000