Hp Instant Capacity Icap Users Manual User's Guide For Version 10.x

2015-01-05

: Hp Hp-Instant-Capacity-Icap-Users-Manual-156089 hp-instant-capacity-icap-users-manual-156089 hp pdf

Open the PDF directly: View PDF PDF.
Page Count: 232 [warning: Documents this large are best viewed by clicking the View PDF Link!]

HP Instant Capacity user's guide for Version
10.x
HP-UX 11i v3, HP-UX 11i v2, and HP-UX 11i v1
HP Part Number: T1428-90074
Published: September 2010
Edition: 3
©Copyright 2000-2010 Hewlett-Packard Development Company, L.P
Legal Notices
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express
warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP
shall not be liable for technical or editorial errors or omissions contained herein.
UNIX is a registered trademark of The Open Group.
Table of Contents
About This Guide.............................................................................................................11
Intended Audience................................................................................................................................11
New and Changed Information in This Edition...................................................................................11
Publishing History................................................................................................................................12
Document Organization.......................................................................................................................13
Typographic Conventions.....................................................................................................................14
Location of Instant Capacity Information.............................................................................................15
Instant Capacity users guide for Version 10.x................................................................................15
Locating the Instant Capacity release notes for Version 10.x..........................................................15
Manpages.........................................................................................................................................16
HP Encourages Your Comments..........................................................................................................16
1 Introduction to Instant Capacity..................................................................................17
Instant Capacity Summary...................................................................................................................18
Terminology.....................................................................................................................................19
Overview...............................................................................................................................................20
Software Product Overview............................................................................................................20
System Overview.............................................................................................................................20
Instant Capacity System Hardware...........................................................................................21
Instant Capacity Software..........................................................................................................21
Utility Pricing Solutions Portal..................................................................................................22
Instant Capacity Administration System...................................................................................22
Instant Capacity Database..........................................................................................................22
Other System Management Commands....................................................................................22
Most Recent Instant Capacity Product Versions and Supported Platforms...................................23
Past Versions and Supported Operating Systems...........................................................................25
2 Getting Started.............................................................................................................27
Instant Capacity Requirements.............................................................................................................28
Program Requirements....................................................................................................................28
Software Requirements....................................................................................................................28
HP-UX 11i v1 Requirements and Dependent Products.............................................................28
Required Patches for HP-UX 11i v1...........................................................................................29
HP-UX 11i v2 Requirements and Dependent Products.............................................................29
Required Patches for HP-UX 11i v2...........................................................................................29
HP-UX 11i v3 Requirements and Dependent Products.............................................................30
OpenVMS Version 8.4 Requirements.........................................................................................30
Network Requirements...................................................................................................................30
Email Requirements........................................................................................................................30
System Contact Requirement..........................................................................................................31
Usage Rights Requirement..............................................................................................................31
Instant Capacity Integration with Virtual Partitions (HP-UX)........................................................31
Instant Capacity Components..............................................................................................................33
Overview.........................................................................................................................................33
Processors and Cores.......................................................................................................................33
Cell Boards and Memory.................................................................................................................33
Global Instant Capacity........................................................................................................................35
Instant Capacity Codewords................................................................................................................36
Temporary Instant Capacity.................................................................................................................37
Table of Contents 3
Instant Capacity Compliance and Enforcement...................................................................................38
Configuration Change Notification......................................................................................................39
Core Activation.....................................................................................................................................40
Increasing Processing Capacity by Purchasing RTUs.....................................................................40
Instant Capacity Cell Board..................................................................................................................41
Instant Capacity Software Validation...................................................................................................42
On HP-UX Systems..........................................................................................................................42
On OpenVMS Systems....................................................................................................................42
Status Reporting on Instant Capacity Systems.....................................................................................43
Time Zone Considerations....................................................................................................................44
3 Installing and Removing Instant Capacity Software.................................................45
Installing Instant Capacity Software.....................................................................................................46
Installing from the HP-UX Media (HP-UX 11i v1, 11i v2, and 11i v3):...........................................46
Installing from the HP Software Depot (For HP-UX 11i v1, 11i v2, and 11i v3):............................47
For All HP-UX Installations.............................................................................................................47
Installing Instant Capacity on OpenVMS Systems.........................................................................47
Reinstalling Instant Capacity Software.................................................................................................48
Preserving current Instant Capacity information...........................................................................48
Removing Instant Capacity Software...................................................................................................49
4 Using Instant Capacity to Manage Processing Capacity........................................51
Checking the Status of your Instant Capacity System..........................................................................52
Setting System Contact Information.....................................................................................................54
Applying a Right To Use (RTU) Codeword..........................................................................................55
Activating Cores...................................................................................................................................57
Example Core Activation Session....................................................................................................58
Deactivating Cores................................................................................................................................59
Example Deactivation Session for Hardware-Partitionable Systems..............................................59
Overriding Deferred Activation and Deactivation...............................................................................61
Load-Balancing Active Cores................................................................................................................62
Understanding and Managing Intended Active Values.......................................................................63
Activations and Deactivations in a Virtual Partition Environment......................................................64
When to Use the vparmodify or icapmodify Commands...............................................................64
What is Unused Capacity................................................................................................................64
Static Virtual Partitions....................................................................................................................64
Activating Cores in a Virtual Partition Environment......................................................................65
Deactivating Cores in a Virtual Partition Environment..................................................................65
Boot Time Compliance....................................................................................................................66
Assigning a Cell to a Partition..............................................................................................................67
Unassigning a Cell from a Partition......................................................................................................69
Software Application Considerations...................................................................................................71
Test Activation of Cores Using Temporary Capacity...........................................................................72
Replacement of Failed Cores................................................................................................................73
HP-UX LPMC and HPMC...............................................................................................................73
LPMC Deactivations in Virtual Partitions.......................................................................................73
Failed Monarch Processors (HP-UX)...............................................................................................73
Replacement of Failed Cores on OpenVMS....................................................................................73
Failed OpenVMS Primary Processors.............................................................................................73
5 Temporary Instant Capacity........................................................................................75
Temporary Instant Capacity Overview................................................................................................76
Ordering Temporary Instant Capacity.................................................................................................78
4 Table of Contents
HP-UX Licensing and Support with Temporary Instant Capacity.................................................78
OpenVMS Licensing and Support with Temporary Instant Capacity............................................78
Using Temporary Instant Capacity.......................................................................................................79
Acquiring and Configuring Temporary Instant Capacity...............................................................79
Using Temporary Instant Capacity.................................................................................................79
Temporary Capacity and Virtual Partitions..........................................................................................81
Tracking Usage of Temporary Instant Capacity...................................................................................83
Temporary Instant Capacity Warning Period.......................................................................................85
Temporary Instant Capacity Expiration and Compliance Enforcement..............................................86
Temporary Instant Capacity Exceptions...............................................................................................87
Error for Activation with Insufficient Temporary Capacity............................................................87
Temporary Capacity Balance Needing Action................................................................................87
Temporary Capacity Negative Balance...........................................................................................87
Temporary Capacity Enforcement..................................................................................................87
6 Instant Capacity Cell Board........................................................................................91
Instant Capacity Cell Board..................................................................................................................92
Overview.........................................................................................................................................92
Ordering Instant Capacity Cell Board..................................................................................................93
HP-UX and OpenVMS License and Support........................................................................................94
Acquiring Usage Rights for Instant Capacity Cell Board.....................................................................95
Instant Capacity Cell Board and Considerations of Core Usage Rights..............................................96
Activation of an Instant Capacity Cell Board.......................................................................................97
Accidental Activation of an Instant Capacity Cell Board.....................................................................98
Instant Capacity Cell Board Activation Exception Error......................................................................99
Instant Capacity Cell Board and Temporary Instant Capacity...........................................................100
7 Global Instant Capacity............................................................................................101
Global Instant Capacity Overview......................................................................................................102
Global Instant Capacity Requirements...............................................................................................104
Global Instant Capacity Group Managers..........................................................................................105
Standby Group Managers..............................................................................................................105
Global Instant Capacity Grouping Rules............................................................................................107
Global Instant Capacity Sharing Rights..............................................................................................108
Creating Global Instant Capacity Groups...........................................................................................109
Global Instant Capacity Resource Sharing.........................................................................................112
Effect of Temporary Capacity........................................................................................................112
Status Reporting............................................................................................................................113
Global Instant Capacity and Temporary Capacity.............................................................................115
Temporary Capacity and Freed Usage Rights...............................................................................115
Temporary Capacity and Status Reporting...................................................................................115
Temporary Capacity Prefetch........................................................................................................116
Removing a Global Instant Capacity Group Member........................................................................117
Reinstalling a Group Member.............................................................................................................118
Group Manager Availability (No Standby Manager).........................................................................119
Group Manager Failover Considerations...........................................................................................120
Upgrades and Global Instant Capacity...............................................................................................121
Adding New Partitions..................................................................................................................121
Rights Seizure......................................................................................................................................122
When to Migrate Usage Rights and When to Seize Usage Rights................................................122
Effects of Rights Seizure................................................................................................................122
Down Partitions with Powered-On Cells......................................................................................123
Temporary Capacity and Rights Seizure.......................................................................................123
Table of Contents 5
Other Considerations.....................................................................................................................124
Additional HA Solutions...............................................................................................................124
Summary of Rights Seizure...........................................................................................................124
Considerations for Multiple Groups...................................................................................................127
Additional Considerations..................................................................................................................128
8 Using Instant Capacity on HP Integrity Superdome 2...........................................129
Overview.............................................................................................................................................129
iCAP: From compliance check paradigm to self enforcement......................................................129
Important Considerations...................................................................................................................130
Sizing Partitions.............................................................................................................................130
Resizing Partitions.........................................................................................................................130
Memory iCAP................................................................................................................................130
Installing iCAP on HP Integrity Superdome 2...................................................................................130
iCAP commands.................................................................................................................................131
Viewing number of active cores....................................................................................................131
Generating snapshot......................................................................................................................131
Setting usage rights for a partition................................................................................................132
Deactivating Cores.........................................................................................................................132
Activating Cores............................................................................................................................132
Using iCAP Memory.....................................................................................................................132
iCAP Use Cases...................................................................................................................................133
Core migration between partitions in a complex..........................................................................133
Core migration across complexes (GiCAP)...................................................................................134
9 Troubleshooting..........................................................................................................137
Handling Compliance Exceptions......................................................................................................137
Troubleshooting the Instant Capacity Software..................................................................................140
Diagnosing Email Configuration........................................................................................................142
10 Frequently Asked Questions...................................................................................143
Instant Capacity Software...................................................................................................................144
Instant Capacity Hardware.................................................................................................................147
Global Instant Capacity.......................................................................................................................148
1 Instant Capacity HP-UX Manpages.........................................................................149
iCAP(5)................................................................................................................................................150
icapmanage(1M)..................................................................................................................................159
icapmodify(1M)...................................................................................................................................174
icapnotify(1M).....................................................................................................................................180
icapstatus(1M).....................................................................................................................................182
icapd(1M)............................................................................................................................................189
A Special Considerations.............................................................................................191
Assumed Values in icapstatus Command..........................................................................................192
Assumed Processor Values............................................................................................................192
Assumed Memory Values..............................................................................................................192
Upgrading to Instant Capacity version B.06.x or later (HP-UX)........................................................193
Dual-Core Support in Instant Capacity Systems................................................................................195
New Partition Creation and Instant Capacity.....................................................................................196
Implications of Removing a Cell from an Instant Capacity System ..................................................197
6 Table of Contents
Shutting Down a Partition with Instant Capacity Cores....................................................................198
Instant Capacity and Reinitializing the nPartition (Genesis Partitions).............................................199
par Commands from PC System Management Station......................................................................200
Instant Capacity Compatibility with Processor Sets (HP-UX)...........................................................201
Overview........................................................................................................................................201
Scope of the Instant Capacity Software Interacting with psets.....................................................201
psets on nPars................................................................................................................................201
psets on vPars................................................................................................................................201
Configuring Email on Instant Capacity Systems................................................................................202
Email Requirements.......................................................................................................................202
Email Configuration.................................................................................................................202
Steps to Confirm or Diagnose Email Configuration................................................................204
Configuring Instant Capacity’s From Email Address..............................................................204
Configuring Your Server to Send but Not Receive Email........................................................205
Testing Email Transmission of the Asset Report......................................................................205
Measurement Software and Instant Capacity Systems.......................................................................206
HP OpenView Measurement Products.........................................................................................206
Other Measurement Software........................................................................................................206
Dynamic Processor Resilience (HP-UX).............................................................................................207
Security Issues.....................................................................................................................................208
Customer protections which iCAP assumes to be in place...........................................................208
Disabling the iCAP daemon (HP-UX)...........................................................................................208
Customer Security Requirements..................................................................................................208
Security Tuning Options................................................................................................................208
B Considerations for OpenVMS Systems....................................................................209
CLI Support on OpenVMS..................................................................................................................210
HP-UX Style Commands...............................................................................................................210
OpenVMS Command Mapping.....................................................................................................210
OpenVMS iCAP Files.....................................................................................................................211
DCL ICAP Command....................................................................................................................212
DCL Commands..................................................................................................................................212
ICAP ACTIVATE...........................................................................................................................212
ICAP APPLY..................................................................................................................................213
ICAP DEACTIVATE......................................................................................................................214
ICAP RECONCILE........................................................................................................................215
ICAP SET.......................................................................................................................................216
ICAP SHOW..................................................................................................................................218
ICAP_SERVER...............................................................................................................................219
Special OpenVMS-Specific Features and Considerations..................................................................220
Core Activation and Deactivation.................................................................................................220
Email Considerations.....................................................................................................................220
Restrictions..........................................................................................................................................221
Glossary.........................................................................................................................223
Index...............................................................................................................................229
Table of Contents 7
List of Figures
1-1 Instant Capacity System Elements................................................................................................21
4-1 Permanent Activation of Instant Capacity Components..............................................................56
4-2 Partition premodification state: One cell assigned with 3 active and 1 inactive cores, and usage
rights for 2 additional cores...........................................................................................................67
4-3 Premodification state: Unassigned cell with 4 inactive cores and no usage rights......................67
4-4 Partition postmodification state: Cell 2 assigned to partition.......................................................67
4-5 Partition premodification state: Three cells with 2 active and 2 inactive cores in each, and 6
expected inactive cores..................................................................................................................69
4-6 Partition postmodification state: Cell 3 is unassigned (total of 6 active cores remaining)...........69
4-7 Partition postmodification state: Unassigned Cell 3 with 4 inactive cores...................................69
4-8 Partition premodification state: Three cells with 3 active and 1 inactive cores in each, and 3
expected inactive cores..................................................................................................................69
4-9 Partition postmodification state: Unassigned Cell 3 (total of 8 active cores are set)....................70
4-10 Postmodification state: Unassigned Cell 3 with 4 inactive cores, with usage rights available for
1 additional core............................................................................................................................70
5-1 Using Temporary Instant Capacity: Temporary Activation of Cores Without Usage Rights.......77
6-1 nPartition premodification state: One cell assigned with 1 active core and 3 inactive cores; the
complex has no additional core usage rights................................................................................99
6-2 nPartition premodification state: Instant Capacity cell (Cell 2) with 4 inactive cores..................99
6-3 nPartition requested state: Instant Capacity Cell (Cell 2) cannot be activated in nPartition........99
7-1 Using Global Instant Capacity.....................................................................................................103
8-1 iCAP Memory configuration option...........................................................................................133
8 List of Figures
List of Tables
1-1 Most Recent Instant Capacity Versions and Supported Platforms...............................................23
6-1 Cell Board Activation Not Requiring Additional Core Usage Rights..........................................96
6-2 Cell Board Activation Requiring Additional Core Usage Rights.................................................96
8-1 Use Case 1 — Initial Configuration.............................................................................................133
8-2 Use Case 1 — Configuration of Complex After Core Migration................................................134
8-3 Use Case 2 — Initial Configuration.............................................................................................134
8-4 Use Case 2 — Initial Configuration.............................................................................................134
8-5 Configuration of Complex1 post core migration........................................................................134
8-6 Configuration of Complex2 post core migration........................................................................135
10-1 Email sent by the Instant Capacity software...............................................................................145
10-2 Asset reporting email sent by the Instant Capacity software......................................................146
A-1 Removing a Cell and Decreasing Inactive Cores........................................................................197
B-1 HP-UX and OpenVMS Command Equivalents..........................................................................210
B-2 OpenVMS iCAP Files..................................................................................................................211
9
List of Examples
2-1 Configuration Change Notification email for Instant Capacity System (not vPar)......................39
4-1 Sample Session of icapstatus (on HP-UX).....................................................................................53
4-2 Applying an RTU Codeword (HP-UX).........................................................................................55
4-3 Activating an Additional Core (HP-UX).......................................................................................58
4-4 Deactivating an Active Core (HP-UX)...........................................................................................60
4-5 Correcting an Incorrect Number of Deferred Active Cores (HP-UX)...........................................61
4-6 Undoing an Accidental Deferred Activation (HP-UX).................................................................61
4-7 vPar Boot–Time Compliance Message..........................................................................................66
5-1 Applying a Temporary Capacity Codeword (HP-UX).................................................................79
5-2 Activating an Instant Capacity Core with Temporary Capacity (HP-UX)...................................80
5-3 Temporary Capacity Information from icapstatus Command (HP-UX)......................................83
5-4 Temporary Capacity Expiration Reminder...................................................................................84
5-5 Error Message for Activation with Insufficient Temporary Capacity (HP-UX)...........................87
5-6 Error Message for Temporary Capacity Partial Enforcement.......................................................88
5-7 Error Message for Temporary Capacity Complete Enforcement..................................................89
7-1 Applying a Sharing Rights Codeword........................................................................................108
7-2 Creating a Group.........................................................................................................................109
7-3 Adding a Member to a Group.....................................................................................................110
7-4 Example Output of icapstatus for a Group Member System......................................................111
9-1 Exception Report for More Cores Active than Expected............................................................138
A-1 Example Edit to Sendmail Configuration (/etc/mail/sendmail.cf)..............................................203
10 List of Examples
About This Guide
The HP Instant Capacity user’s guide for Version 10.x provides you with the most recent information
for using the Instant Capacity Version 10 software. This document describes Instant Capacity
Version B.11.31.10.00.00 on HP-UX 11i v3 systems, B.11.23.10.00.00 on HP-UX 11i v2 systems,
B.11.11.09.02.00 on HP-UX 11i v1 systems, and Instant Capacity Version 9.x on OpenVMS 8.4
Integrity servers.
The latest version of this document can be found online at: www.hp.com/go/hp-icap-docs.
This chapter covers the following topics:
“Intended Audience” (page 11)
“New and Changed Information in This Edition” (page 11)
“Publishing History” (page 12)
“Document Organization” (page 13)
“Typographic Conventions” (page 14)
“Location of Instant Capacity Information” (page 15)
“HP Encourages Your Comments” (page 16)
Intended Audience
All personnel with system administrator access (that is, with root login privileges on HP-UX
systems, or Administrators on OpenVMS systems) to an Instant Capacity system should read
and understand the contents of this document and the implications of managing an Instant
Capacity system.
Administrators are expected to have knowledge of HP-UX, or OpenVMS Integrity operating
system concepts, commands, and configuration.
This document is not a tutorial.
New and Changed Information in This Edition
This edition of HP Instant Capacity user’s guide for Version 10.x. includes a new chapter that provides
information about iCAP support on HP Integrity Superdome 2. For detailed information about
iCAP support on HP Integrity Superdome 2, see Chapter 8 (page 129)
Intended Audience 11
Publishing History
The document printing date and part number indicate the document’s current edition. The
printing date will change when a new edition is printed. Minor changes may be made at reprint
without changing the printing date. The document part number will change when extensive
changes are made. Document updates may be issued between editions to correct errors or
document product changes. To ensure that you receive the updated or new editions, you should
subscribe to the appropriate product support service. See your HP sales representative for details.
You can find the latest version of this document on line at:
www.hp.com/go/hp-icap-docs.
Publication DateEdition NumberSupported VersionsSupported Operating
Systems
Manufacturing Part
Number
September 20103B.11.23.10.00.00HP-UX 11i v2T1428-90074
B.11.31.10.00.00HP-UX 11i v3
November 20092B.11.11.09.00.00HP-UX 11i v1B9073-90201
B.11.23.09.00.00HP-UX 11i v2
B.11.31.09.00.00HP-UX 11i v3
9.xHP OpenVMS
Version 8.4
12
Document Organization
This users guide is not designed to be read from front to back in its entirety. To get an
understanding of Instant Capacity version 9.x, you should read this chapter, Chapter 1 - Instant
Capacity Overview, and Chapter 2 - Getting Started. After reading these chapters, you can utilize
the table of contents and index (in back) for specific topics of interest.
About This Guide provides an introduction to this guide and locating Instant Capacity
information.
Chapter 1, Introduction to Instant Capacity provides an overview of the Instant Capacity system.
Chapter 2, Getting Started describes Instant Capacity requirements, concepts and methods,
and related software topics.
Chapter 3, Installing and Removing Instant Capacity Software contains procedures on how to
install and reinstall Instant Capacity software.
Chapter 4, Using Instant Capacity to Manage Processing Capacity explains how to view system
status, apply codewords, activate and deactivate cores, assign and unassign cells, and HP’s
test activation policy for Instant Capacity.
Chapter 5, Temporary Instant Capacity gives you details on what temporary capacity is, and
how to order and use it.
Chapter 6, Instant Capacity Cell Board provides details on what Instant Capacity Cell Board
is, and how to order and use it.
Chapter 7, Global Instant Capacity gives you details on Global Instant Capacity, describes the
concept of groups and shared resources, and how to order and use it.
Chapter 8, Using Instant Capacity on HP Integrity Superdome 2 provides information about
iCAP support on HP Integrity Superdome 2.
Chapter 9, Troubleshooting gives you step by step procedures to resolve problems with the
Instant Capacity software and other related configurations.
Chapter 10, Frequently Asked Questions contains questions and answers to common Instant
Capacity software topics.
Instant Capacity HP-UX Manpages contains the actual HP-UX manpages for icap,
icapmanage,icapmodify,icapnotify,icapstatus, and icapd.
Appendix A, Special Considerations describes assumed values in icapstatus output,
upgrading to Instant Capacity B.06.x or later software, dual core support, creating and
shutting down partitions, implications of removing a cell board from an Instant Capacity
system, par commands with PC SMS, integration with Psets, configuring email, testing
email transmission of an asset report, measurement software, dynamic processor resilience,
and security related issues.
Appendix B, Considerations for OpenVMS Systems contains information for running Instant
Capacity on OpenVMS systems.
Glossary explains Instant Capacity systems and software terms.
Document Organization 13
Typographic Conventions
This document uses the following conventions:
%,$, or #A percent sign represents the C shell system prompt. A dollar
sign represents the system prompt for the Bourne, Korn, and
POSIX shells. A number sign represents the superuser prompt.
audit(5) A manpage. The manpage name is audit, and it is located in
Section 5.
Command A command name or qualified command phrase.
Computer output Text displayed by the computer.
Ctrl+x A key sequence. A sequence such as Ctrl+x indicates that you
must hold down the key labeled Ctrl while you press another
key or mouse button.
ENVIRONMENT VARIABLE The name of an environment variable, for example, PATH.
[ERROR NAME] The name of an error, usually returned in the errno variable.
Key The name of a keyboard key. Return and Enter both refer to the
same key.
Glossary term The defined use of an important word or phrase.
User input Commands and other text that you type.
Variable The name of a placeholder in a command, function, or other
syntax display that you replace with an actual value.
[] The contents are optional in syntax. If the contents are a list
separated by |, you must choose one of the items.
{} The contents are required in syntax. If the contents are a list
separated by |, you must choose one of the items.
... The preceding element can be repeated an arbitrary number of
times.
Indicates the continuation of a code example.
| Separates items in a list of choices.
WARNING A warning calls attention to important information that if not
understood or followed will result in personal injury or
nonrecoverable system problems.
CAUTION A caution calls attention to important information that if not
understood or followed will result in data loss, data corruption,
or damage to hardware or software.
IMPORTANT This alert provides essential information to explain a concept or
to complete a task
NOTE A note contains additional information to emphasize or
supplement important points of the main text.
14
Location of Instant Capacity Information
Instant Capacity user’s guide for Version 10.x
You can find the HP Instant Capacity user’s guide for Version 10.x in the following locations:
On the HP Documentation website:
www.hp.com/go/hp-icap-docs
These are the most current and the most current localized versions of the user guide.
September 2010 HP-UX 11i v1 Instant Information media (English and Japanese only)
September 2010 HP-UX 11i v2 Instant Information media (English and Japanese only)
September 2010 HP-UX 11i v3 Instant Information media (English and Japanese only)
In the Instant Capacity 10.x HP-UX software product:
/usr/share/doc/icapRelNotes.pdf
On the OpenVMS Version 8.4 Documentation CD (English only)
Locating the Instant Capacity release notes for Version 10.x
You can find the Instant Capacity release notes for Version 10.x in the following locations:
On the HP Documentation website:
www.hp.com/go/hp-icap-docs
These are the most current release notes and the most current localized versions.
September 2010 HP-UX 11i v1 Instant Information media (English and Japanese only)
September 2010 HP-UX 11i v2 Instant Information media (English and Japanese only)
September 2010 HP-UX 11i v3 Instant Information media (English and Japanese only)
In the Instant Capacity 10.x HP-UX software product:
/usr/share/doc/icapRelNotes.pdf
This document is not localized and is available in English only.
On the OpenVMS Version 8.4 Documentation CD (English only)
Location of Instant Capacity Information 15
Manpages
NOTE: The information contained in this section applies only to HP-UX systems. It does not
apply to Integrity servers running OpenVMS.
See “Instant Capacity HP-UX Manpages” (page 149) for more information about the following
manpages:
icap(5): overview of the Instant Capacity commands and their usage
icapmanage(1M): how to manage Global Instant Capacity (GiCAP) groups
icapmodify(1M): how to manage processing capacity in your Instant Capacity system, change
system contact information, and apply codewords
icapnotify(1M): how to manage asset reporting and configuration notification
icapstatus(1M): how to display processing capacity status, usage information, and system
information
icapd(1M): overview of the Instant Capacity daemon, which provides the software a
complexwide view of processing capacity
HP Encourages Your Comments
HP encourages your comments concerning this document. We are committed to providing
documentation that meets your needs. Send any errors found, suggestions for improvement, or
compliments to:
docsfeedback@hp.com
Include the document title, manufacturing part number, and any comment, error found, or
suggestion for improvement you have concerning this document.
16
1 Introduction to Instant Capacity
This chapter covers the following topics:
“Instant Capacity Summary” (page 18)
“Overview” (page 20)
For more in-depth information, see icap(5).
17
Instant Capacity Summary
HP Instant Capacity software provides the ability to instantly increase or decrease computing
capacity on specified HP enterprise servers.
NOTE: HP Instant Capacity for HP 9000 and HP Integrity Servers, also known as Instant
Capacity or iCAP, was known in earlier versions as Instant Capacity on Demand, or iCOD.
Although the commands, warning messages and error messages refer to the software as iCAP,
some internal files might still refer to iCOD.
NOTE: For simplicity and commonality, this book uses the HP-UX commands in all examples.
For information about OpenVMS command equivalents, see Appendix B (page 209).
With Instant Capacity, you initially purchase an HP enterprise server with a specified amount
of active processing capacity, and a specified amount of inactive processing capacity. This amount
can vary based on your sales contract with HP.
Processing capacity consists of the system components:
Processors containing cores
Cell boards
• Memory
For each type of component, the number of components that can be active is equal to the number
of usage rights applied to the complex for that type of component. Components that are purchased
with a part number identifying them as “Instant Capacity” and without the label “Right to Use”
come without usage rights. Components that are not labeled “Instant Capacity” implicitly include
usage rights that can be applied to any component of that type that is installed on the complex.
Prior to activation of an inactive component, you must obtain additional usage rights. The
fundamental method is to purchase usage rights by purchasing the appropriate Instant Capacity
products that include the label “Right to Use (RTU)”. HP then supplies an RTU codeword. When
the codeword is applied to the HP enterprise server, the inactive component can be activated.
Additional methods for activating components for which usage rights have not been purchased
include:
If an HP-UX server is a member of a Global Instant Capacity (GiCAP) group, and if extra
capacity is available from other members of the group, capacity can be “borrowed” from
another member of the group. For information about GiCAP, see Chapter 7.
You can purchase additional temporary capacity and apply the Temporary Instant Capacity
(TiCAP) codeword in order to activate one or more cores temporarily. For more information
on TiCAP, see Chapter 5. If a server is a member of a GiCAP group, temporary capacity can
be shared among members of the group.
You can temporarily activate one or more inactive cores using the Instant Access Capacity
(IAC) provided with the initial purchase of the Instant Capacity component. Instant Access
Capacity is the same as TiCAP except it is automatically provided with an Instant Capacity
component and cannot be purchased separately. It provides an immediate buffer of temporary
capacity in case extra capacity is needed before there is time to purchase an RTU or a TiCAP
codeword, or to set up a GiCAP group on an HP-UX system.
IMPORTANT: It is always a good idea to keep some quantity of temporary capacity in reserve.
Purchase of codewords may take one or more days, so having a buffer of temporary capacity
allows you to avoid delays in activation of additional cores. Instant Access Capacity provides
this buffer initially, but as that capacity is depleted, ongoing purchases of additional temporary
capacity are recommended to replenish it.
The Instant Capacity software product is a part of the HP Utility Pricing Solutions (formerly On
Demand Solutions) program.
18 Introduction to Instant Capacity
This document provides you with the most recent information about using the Instant Capacity
version 9.x software to manage processing capacity in your HP enterprise server.
NOTE: All personnel with system administrator access (that is, root login privileges) to an
Instant Capacity system should read and understand the contents of this document and the
implications of increasing or decreasing processing capacity.
Terminology
For commonly used terms associated with the HP Utility Pricing Solutions program, see the
Glossary.
Instant Capacity Summary 19
Overview
Software Product Overview
The following Instant Capacity software products are associated with HP’s Utility Pricing
Solutions program:
iCOD: HP product number B9073BA (HP-UX)
iCAP: HP OpenVMS product number BA484AA
This user's guide contains information for Instant Capacity version 10.x on HP-UX systems and
version 9.x on OpenVMS systems.
Instant Capacity must be run on a partitionable system. In an Integrity Virtual Machines (VM)
environment, Instant Capacity software provides meaningful functionality only on the VM Host
system; it does not run on a virtual machine (also known as a “guest”).
The Instant Capacity product has been available on HP-UX since March 2000 (version B.01.00).
The HP-UX version 9.x software can be obtained from the following HP Software Depot website
(search for “Instant Capacity”):
http://www.hp.com/go/softwaredepot
System Overview
Instant Capacity version 9.x consists of the following elements:
Instant Capacity system hardware (including cells, cores, and memory)
Instant Capacity software
Utility Pricing Solutions Portal
Instant Capacity Administration System
Instant Capacity database
Other system management commands
For more information about Instant Capacity concepts and methods, see Chapter 2: “Getting
Started” (page 27).
Figure 1-1 (page 21) shows how the Instant Capacity system elements and processes are linked.
20 Introduction to Instant Capacity
Figure 1-1 Instant Capacity System Elements
Other
System Management
Commands
iCAP DB
System
Compliance
Codeword
Generation
Asset
Report
Record Purchase
Status and
Control
Status and
Control
Status and
Control
Authorization
Purchase
Codeword Request
Notification
Cores, Cells
and Memory
HP Sales
Rep.
iCAP Admin
System
iCAP
Software
iCAP Web
Portal
Customer
Instant Capacity System Hardware
The Instant Capacity system hardware is made up of the following components:
Cell boards
Processors, which contain cores
• Memory
Every Instant Capacity system contains a combination of these components that are purchased
either with usage rights (and available for activation) or without usage rights (must be inactive).
Note that although you purchase processors, the Instant Capacity software monitors and manages
cores.
Instant Capacity Software
The Instant Capacity software provides the means to:
Increase or decrease (load balance) system processing capacity (icapmodify command).
View status and configuration of the system components (icapstatus command).
Administer system identification and notification information (icapmodify command).
If configured, send system asset reports through encrypted email to HP (icapd daemon on
HP-UX, ICAP_SERVER process on OpenVMS).
Send configuration change notification, through encrypted email, to the specified system
contact.
Overview 21
Monitor and report system compliance (icapd daemon on HP-UX, ICAP_SERVER process
on OpenVMS).
Manage Global Instant Capacity groups (icapmanage command).
For details about these commands on HP-UX, see “Instant Capacity HP-UX Manpages” (page 149).
For the OpenVMS equivalents of these commands, see “DCL Commands” (page 212).
Utility Pricing Solutions Portal
The Utility Pricing Solutions (or Instant Capacity) portal is located at the HP web site:
http://www.hp.com/go/icap/portal
After you purchase a component without usage rights, HP sends you a letter containing
instructions on how to obtain an RTU codeword from the Utility Pricing Solutions portal.
Instant Capacity Administration System
If asset reporting is configured, the icapd daemon sends asset reports, in the form of encrypted
email messages, to the Instant Capacity Administration System, which saves information in the
Instant Capacity database.
Instant Capacity Database
The Instant Capacity database is a repository on an HP (internal) corporate server that tracks
system resources and provides the information for codeword generation. Note that this database
should not be confused with a Global Instant Capacity database, which is created on a customer
Group Manager system. See Chapter 7 (page 101) for details about Global Instant Capacity.
Other System Management Commands
Other system management commands (such as vparmodify,parCLI and parMgr on HP-UX)
provide an interface to modify system configuration that affects Instant Capacity contractual
compliance.
22 Introduction to Instant Capacity
Most Recent Instant Capacity Product Versions and Supported Platforms
Table 1-1 lists the current versions of Instant Capacity and the platforms supported for each
version.
Table 1-1 Most Recent Instant Capacity Versions and Supported Platforms
NotesSupported Hardware
Platforms
Operating System
Version
Software and Version
Available on:
http://www.hp.com/go/softwaredepot
September 2009 HP-UX 11i v3 Operating
Environment media
HP Integrity servers:
HP Integrity
Superdome 2
• Superdome
• rx8640
• rx8620
• rx7640
• rx7620
HP 9000 servers:
• Superdome
• rp8440
• rp8420
• rp8400
• rp7440
• rp7420
• rp7410
HP-UX 11i v3iCAP
B.11.31.10.00.00
(B9073BA)
Available on:
http://www.hp.com/go/softwaredepot
September 2009 HP-UX 11i v2 Applications
Software media
HP Integrity servers:
• Superdome
• rx8640
• rx8620
• rx7640
• rx7620
HP 9000 servers:
• Superdome
• rp8420
• rp8400
• rp7420
• rp7410
HP-UX 11i v2iCAP
B.11.23.10.00.00
(B9073BA)
Available on:
http://www.hp.com/go/softwaredepot
September 2009 HP-UX 11i v1 Applications
Software media
HP 9000 servers:
• Superdome
• rp8440
• rp8420
• rp8400
• rp7440
• rp7420
• rp7410
HP-UX 11i v1iCAP
B.11.11.09.00.00
(B9073BA)
Available on:
OpenVMS Version 8.4 Operating System
media
HP Integrity servers:
• Superdome
• rx8640
• rx8620
• rx7640
• rx7620
HP OpenVMS
Version 8.4
iCAP 9.x
(BA484AA)
For commonality across all platforms supported by Instant Capacity, generic references to version
numbers are in the form “9.x” in this document. Because the operating system version is also
Overview 23
incorporated in the depot version number on newer releases of HP-UX, specific references to
version numbers may be more precise; for example, B.11.23.09.00.00 for the HP-UX 11i v2 depot.
24 Introduction to Instant Capacity
Past Versions and Supported Operating Systems
Previous versions of the Instant Capacity software are as follows:
B.01.00 (on HP-UX 11.00)
B.02.x (on HP-UX 11.00 and 11i v1)
B.03.x (on HP-UX 11i v1)
B.04.x (on HP-UX 11.00 and 11i v1)
B.05.00 (on HP-UX 11.00 and 11i v1)
B.06.x (on HP-UX 11i v1 and 11i v2)
B.07.x (on HP-UX 11i v1 and 11i v2)
B.08.00 (on HP-UX 11i v1 and 11i v2)
B.08.00.01 (on HP-UX 11i v1 and 11i v2)
B.08.01.01 (on HP-UX 11i v1, 11i v2 and 11i v3)
B.08.02 (on HP-UX 11i v1, 11i v2 and 11i v3)
B.08.02.01 (on HP-UX 11i v1, 11i v2 and 11i v3)
B.08.03.00 (on HP-UX 11i v1, 11i v2, and 11i v3)
B.08.03.01 (on HP-UX 11i v1, 11i v2, and 11i v3)
8.0 (on OpenVMS Version 8.3)
8.1 (on OpenVMS Version 8.3-1H1)
Overview 25
26
2 Getting Started
This chapter covers the following topics:
“Instant Capacity Requirements” (page 28)
“Instant Capacity Components” (page 33)
“Global Instant Capacity” (page 35)
“Instant Capacity Codewords” (page 36)
“Temporary Instant Capacity” (page 37)
“Instant Capacity Compliance and Enforcement” (page 38)
“Configuration Change Notification” (page 39)
“Core Activation” (page 40)
“Instant Capacity Cell Board” (page 41)
“Instant Capacity Software Validation” (page 42)
“Status Reporting on Instant Capacity Systems” (page 43)
“Time Zone Considerations” (page 44)
For more in-depth information, see icap(5).
27
Instant Capacity Requirements
Program Requirements
To participate in the Instant Capacity version 9.x program, you must comply with the following
conditions of the HP Utility Pricing Solutions program:
Maintain the HP Instant Capacity software on each HP-UX or OpenVMS partition in the
system. The Instant Capacity software is a nonintrusive, low-overhead software module
that resides on the partition.
Migrate to later Instant Capacity software versions as they become available.
For specifics about your individual program requirements, see the Utility Pricing Solutions
contract from HP or your authorized channel partner.
IMPORTANT: Participants in the Utility Pricing Solutions program who do not meet these
requirements may be in breach of contract. This can result in unnecessary expense for both the
program participant and HP.
Software Requirements
Every HP-UX and OpenVMS partition in an Instant Capacity system is required to have the
Instant Capacity software installed and the icapd daemon running (on HP-UX systems), or the
ICAP_SERVER process running (on OpenVMS systems). You must maintain the Instant Capacity
software until all program requirements are fulfilled and until the system is no longer considered
an Instant Capacity system. If you are using GiCAP, all systems must be running Instant Capacity
version 9.x.
NOTE: For necessary HP-UX updates, install the latest Operating Environments Update Release
(OEUR) or Application Release (AR) update, if possible. This ensures that you install all required
products and versions. Instant Capacity does not work correctly with HP-UX releases prior to
December 2004.
Your Instant Capacity system is ordered and shipped with all of the following required software
and dependent products, with the exception of the vPars software. If your system’s operating
system is reinstalled or installed with Ignite-UX, ensure that the following software requirements
are satisfied.
HP-UX 11i v1 Requirements and Dependent Products
The following software is required for Instant Capacity version 9.x on HP-UX 11i v1:
HP-UX 11i v1
iCOD software bundle B9073BA (version 9.x) — On the 11i v1 Applications Software media,
or download the most recent version from the HP Software Depot at http://www.hp.com/
go/softwaredepot.
The kernel configuration must include the diag2 module.
WBEM B8465BA bundle (version A.02.05 or higher)
nParProvider bundle (version B.12.01.06.02 or higher, available from the OE media)
If you have a virtual partitioned environment, the Virtual Partitions (vPars) software (bundle
T1335AC) must be version A.03.05 or higher. vPars is available separately and is not included
with the OE.
(GiCAP only) The CIM Server configuration property sslClientVerificationMode
must be set to a value of “optional” on all GiCAP Group Managers and on all OS instances
of all member systems. (The CIM Server may need to be restarted if the property was not
previously set to this value.) For details, see cimconfig(1M). Note that communication between
28 Getting Started
the managers and members of groups is established using SSL certificates that are supplied
by the GiCAP software.
Required Patches for HP-UX 11i v1
The following patches are required for Instant Capacity version 9.x on HP-UX 11i v1:
PHKL_22987: S700_800 11.11 pstat() patch (Use only if your system runs
MeasureWare software)
PHKL_23154: S700_800 11.11 dflush() patch
PHKL_25218: S700_800 11.11 PDC Call retry, PDC_SCSI_PARMS, iCOD hang
fix
PHKL_26232: S700_800 11.11 Psets Enablement patch,FSS iCOD patch
PHKL_30197: S700_800 11.11 Psets & vPar, Reboot hangs, serial number
PHCO_24396: S700_800 11.11 /etc/default/tz patch
PHCO_24477: S700_800 11.11 sar (1M) patch
PHCO_29832: S700_800 11.11 reboot(1M) patch
PHCO_29833: S700_800 11.11 killall(1M) patch
IMPORTANT: For the most recent required patches, see the Instant Capacity Installation page
on the HP Software Depot (search for “B9073BA”):
http://www.hp.com/go/softwaredepot
HP-UX 11i v2 Requirements and Dependent Products
The following software is required for Instant Capacity version 9.x on HP-UX 11i v2:
HP-UX 11i v2
iCOD software bundle B9073BA (version 9.x) — On the 11i v2 Applications Software media,
or download the most recent version from the HP Software Depot at http://www.hp.com/
go/softwaredepot.
The kernel configuration must include the diag2 module.
WBEM B8465BA bundle (version A.02.05 or higher)
nParProvider bundle (version B.23.01.06.02 or higher, available from the OE media)
If you have a virtual partitioned environment, the Virtual Partitions (vPars) software (bundle
T1335BC) must be version A.04.01 or higher. vPars is available separately and is not included
with the OE.
(GiCAP only) The CIM Server configuration property sslClientVerificationMode
must be set to a value of “optional” on all GiCAP Group Managers and on all OS instances
of all member systems. (The CIM Server may need to be restarted if the property was not
previously set to this value.) For details, see cimconfig(1M). Note that communication between
the managers and members of groups is established using SSL certificates that are supplied
by the GiCAP software.
NOTE: On HP-UX 11i v2 systems, updated firmware might be required by the nPar or Virtual
Partition software, as documented for these products.
Required Patches for HP-UX 11i v2
The following patches are required for Instant Capacity version 9.x on HP-UX 11i v2:
PHKL_33752: S700_800 11.23 Itanium 2 Processor speed reporting patch
required only for IA systems
PHCO_34721: killall(1M) patch
PHKL_35174: _CS_PARTITION_IDENT patch required for GiCAP on rx8640 and rx7640
systems
Instant Capacity Requirements 29
IMPORTANT: For the most recent required patches, see the Instant Capacity Installation page
on the HP Software Depot (search for “B9073BA”):
http://www.hp.com/go/softwaredepot
HP-UX 11i v3 Requirements and Dependent Products
The following software is required for Instant Capacity version 9.x on HP-UX 11i v3:
HP-UX 11i v3
iCOD software bundle B9073BA (version 9.x) — Installed automatically when the HP-UX
11i v3 Operating Environment (OE) is installed, or download the most recent version from
the HP Software Depot at http://www.hp.com/go/softwaredepot.
The kernel configuration must include the diag2 module.
WBEMSvcs bundle (version A.02.05 or higher)
nParProvider bundle (version B.31.01.07.01 or higher, available from the OE media)
If you have a virtual partitioned environment, the Virtual Partitions (vPars) software (bundle
T1335BC) must be version A.05.01 or higher. vPars is available separately and is not included
with the OE.
(GiCAP only) The CIM Server configuration property sslClientVerificationMode
must be set to a value of “optional” on all GiCAP Group Managers and on all OS instances
of all member systems. (The CIM Server may need to be restarted if the property was not
previously set to this value.) For details, see cimconfig(1M). Note that communication between
the managers and members of groups is established using SSL certificates that are supplied
by the GiCAP software.
OpenVMS Version 8.4 Requirements
The following software is required for Instant Capacity version 9.x on OpenVMS Version 8.4:
HP OpenVMS Version 8.4 for Integrity Servers or later
iCAP software bundle BA484AA (version 9.x) — Included with OpenVMS Version 8.4 and
automatically installed on relevant systems when Version 8.4 is initially installed
WBEMCIM bundle ( version X2.92 or higher) — Optionally installed with OpenVMS Version
8.4
nParProvider bundle — Installed with OpenVMS Version 8.4
SSL bundle (version SSL 1.4 or higher) — Optionally installed with OpenVMS Version 8.4
Network Requirements
GiCAP and iCAP do not use any network ports directly. However, version 9.0 GiCAP uses
WBEM/SSL for the communication protocol, requiring use of the CIM HTTPS port 5989. GiCAP
also uses ping (which uses port 7 for the echo protocol) and host lookup services (getaddrinfo
and getnameinfo) which may use the Domain Name System (DNS), Network Information
Service (NIS), or a local host file to provide the lookup function.
Email Requirements
For some configurations, previous versions of the Instant Capacity software (prior to B.07.x)
required email connectivity to HP in order to send asset reports as encrypted email messages.
Instant Capacity version B.07.x and later no longer require email connectivity or asset reporting,
however, you can choose to configure it because it can be useful for viewing complexwide asset
information at the Utility Pricing Solutions portal (http://www.hp.com/go/icap/portal).
30 Getting Started
NOTE: Starting with iCAP version 8.02, asset reporting is turned off by default for new
installations. However, for reinstallation and upgrades the asset reporting remains at its previous
setting; if your system was manufactured prior to iCAP version 8.02, asset reporting might still
be turned on. Unless you turn off asset reporting or configure the email connectivity, error
messages are logged when the software attempts to send asset reports. The icapstatus
command displays the current configuration for asset reporting. You turn asset reporting on or
off with the icapnotify -a command. For details about how to configure email connectivity,
see “Configuring Email on Instant Capacity Systems” (page 202).
System Contact Requirement
Your organization can ensure the successful management of Instant Capacity systems by
designating a system contact. The system contact receives the following types of email notifications
from the Instant Capacity software:
Core activation or deactivation
Compliance exception
Temporary capacity expiration
Instant Capacity enforcement
Virtual partition boot time compliance
Hardware incompatibility in a GiCAP group (see “Upgrades and Global Instant Capacity”
(page 121))
If a system contact is not specified, notification of core changes are not sent from the Instant
Capacity partition. However, the root account on HP-UX and the SYSTEM account on OpenVMS
continue to receive other notification messages.
Usage Rights Requirement
A system managed under the Instant Capacity program can include one or more components
(core, cell, or memory) that are without usage rights. Before you can use these components, you
must obtain additional usage rights. Usage rights can either be purchased from HP, or, if the
system is a member of a GiCAP group, borrowed temporarily from another member of the group,
as described in the section “Global Instant Capacity Sharing Rights” (page 108).
Purchase of usage rights from HP is managed through the use of RTU codewords. Contact your
HP sales representative in order to purchase component-specific usage rights. After such a
purchase, HP sends you a letter informing you how to retrieve the RTU codeword from the HP
Utility Pricing Solutions website:
http://www.hp.com/go/icap/portal
After the RTU codeword is retrieved from the Utility Pricing Solutions portal, the RTU codeword
is applied to your server by the use of the icapmodify -C command. When the codeword is
applied, component-specific usage rights on the system are increased, allowing you to activate
one or more additional components.
Instant Capacity Integration with Virtual Partitions (HP-UX)
The minimum required versions of vPars software for HP-UX systems are as follows:
HP-UX 11i v1: vPars version A.03.05
HP-UX 11i v2: vPars version A.04.01
HP-UX 11i v3: vPars version A.05.01
Each of these versions provides a virtual partition environment which is tightly integrated with
Instant Capacity, making it less likely for a complex to be misconfigured or to violate contractual
compliance.
Instant Capacity Requirements 31
The Instant Capacity software must be installed on all virtual partitions in an Instant Capacity
system.
For details about virtual partitions, see the Installing and Managing HP-UX Virtual Partitions
manual on the HP Documentation website:
http://docs.hp.com
32 Getting Started
Instant Capacity Components
Overview
The Instant Capacity software monitors and enforces compliance with contractual agreements.
It authorizes or denies activation of system components (cores, cells, memory) based on a
complexwide database of usage rights. For details about acquiring additional usage rights, see
“Usage Rights Requirement” (page 31).
Activation of components is restricted according to complexwide compliance for each component
type. A complex is in a compliant state when the number of active components of a given type
does not exceed the number of that component’s available usage rights on the complex.
Processors and Cores
Although you purchase Instant Capacity processors for your system, the Instant Capacity software
monitors and manages the total number of cores. For example, if you have a dual-core Instant
Capacity processor, two cores must remain inactive on the complex.
The Instant Capacity software enforces compliance for cores by comparing the actual number
of inactive cores with the expected number of inactive cores (the number of cores without usage
rights) for the entire complex, according to the contract with HP. Available core usage rights can
be used to activate any core in an active cell board. Note also that temporary capacity can be
used to activate cores beyond the number of available core usage rights for the complex, but
only for a limited period of time.
NOTE: Unless a system participates in a GiCAP group (see Chapter 7), usage rights are
complexwide (single node for OpenVMS) only. If components are moved from one complex to
another, the counts of allowable active and inactive components do not change for either complex.
In particular, the number of “expected inactive” components of each type does not change if
components are removed. This means that the removal of inactive components from a complex
can cause that complex to be out of compliance with the Instant Capacity contract because there
are fewer visible inactive components than the complex-wide count of components without
usage rights. The complex might even become unusable if, for example, enough other cores must
be made inactive to meet compliance resulting in insufficient active cores to have at least one
active core per configured cell.
Cell Boards and Memory
Instant Capacity offers you a way to have additional (inactive) cell-board capacity in your system
for growing business needs. When the need arises, these cell boards, which contain memory and
cores, are available for instant activation and use after reboot or cell online activation when
additional cell-board usage rights are purchased from HP and an RTU codeword is applied. As
with cores, the Instant Capacity software enforces compliance by comparing the number of actual
inactive cells with the expected number of inactive cells (the number of cells without usage rights
for the entire complex).
The cell-board, memory, and core usage rights are tracked separately. To activate an Instant
Capacity cell, you must acquire sufficient cell usage rights, as well as sufficient memory usage
rights to enable all the memory attached to the cell. You cannot activate a cell board without
activating all attached memory, so when you purchase an RTU for a cell you need to purchase
an RTU for the cell’s memory. These are normally bundled together in a single purchase.
Depending on the need, you might want to activate one or more cores at the same time the cell
and memory are activated, so you might also need to acquire additional core usage rights. After
a cell board is activated, all of the cores on the cell board are available for activation if the complex
has enough available core usage rights or temporary capacity. Since usage rights for all types of
Instant Capacity Components 33
components can be conveyed with a single RTU codeword, it is particularly useful to anticipate
the core and memory needs when purchasing cell-board usage rights.
As with other components, the Instant Capacity software enforces compliance for memory by
comparing the actual amount of inactive memory with the expected inactive memory.
IMPORTANT: You must have one active core for each active cell board.
34 Getting Started
Global Instant Capacity
Global Instant Capacity, or GiCAP, provides HP customers with the flexibility to move usage
rights for Instant Capacity components within a group of servers. It also provides “pooled”
temporary capacity across the group. This provides more cost-effective high availability, including
disaster recovery capabilities, more adaptable load balancing, and more efficient and easier use
of temporary capacity.
Global Instant Capacity is built on the concept of a server group, or GiCAP group. A GiCAP
group is a list of servers that are allowed to share Instant Capacity usage rights. In addition, at
least one HP-UX system running Instant Capacity must be designated as the GiCAP Group
Manager. The Group Manager hosts the GiCAP software that maintains a database of information
about the group and about group resources (usage rights and temporary capacity). A GiCAP
group is managed using the command icapmanage on the Group Manager system.
While GiCAP is part of Instant Capacity and is installed at the same time as Instant Capacity, it
is not enabled during installation. To create groups and share resources across groups, you must
purchase GiCAP sharing rights, acquire the GiCAP codeword from the HP Utility Pricing
Solutions portal (http://www.hp.com/go/icap/portal), and apply the associated codeword to the
Group Manager system. Application of the sharing rights codeword to the Group Manager
system enables the addition of members with Instant Capacity components to groups. In addition,
you must acquire grouping rules from the portal and apply those rules to the Group Manager
system. GiCAP sharing rights and grouping rules are described in Chapter 7 (page 101). All
GiCAP Group Manager systems and group members must run Instant Capacity version 9.0 or
later.
Instant Capacity allows deactivation of cores on non-Instant Capacity systems (those without
any Instant Capacity components), allowing such systems to participate in a GiCAP group and
loan usage rights to Instant Capacity systems. A GiCAP group consists of servers that are allowed
to be grouped together according to a set of grouping rules defined by HP. These grouping rules
must be acquired from the Utility Pricing Solutions portal and applied to the Group Manager
system before groups can be created. For more information, see “Global Instant Capacity Grouping
Rules” (page 107).
Global Instant Capacity 35
Instant Capacity Codewords
Instant Capacity uses codewords for several purposes: to adjust available usage rights for system
components (RTU codewords), to apply temporary capacity to the system, and to apply sharing
rights to a GiCAP Group Manager system to enable the creation of one or more groups.
All types of codewords must be purchased as specific product numbers from HP. After purchase,
the actual codeword (an encrypted string) can be retrieved from the Utility Pricing Solutions
web portal. When you retrieve codewords from the portal, you must provide the sales order
number for the codeword purchase and the serial number of the system. For more information
about purchasing codewords, see the Utility Pricing Solutions web portal information in “System
Overview” (page 20).
Once obtained from the portal, the rules and uses of GiCAP codewords are very different from
other types of Instant Capacity codewords. The GiCAP codewords are described in “Global
Instant Capacity Sharing Rights” (page 108) and are referred to as “GiCAP codewords”. Other
types of codewords are referred to as “Instant Capacity codewords”.
The following Instant Capacity codewords are applied to a server using the icapmodify -C
command:
Core RTU
Cell board RTU
Memory RTU
Temporary capacity
For details about using temporary capacity codewords, see Acquiring and Configuring
Temporary Instant Capacity” (page 79).
Application of an RTU codeword adjusts the number of component-specific usage rights on the
system. As a result, more components can be active simultaneously.
IMPORTANT: Instant Capacity codewords are based on both the serial number of a system and
a unique sequencing value for that server. These codewords must be applied in the sequence in
which they are obtained for a particular server. They can be applied to any partition on the server.
36 Getting Started
Temporary Instant Capacity
You can purchase an amount of temporary processing capacity for your Instant Capacity system.
Temporary Instant Capacity, or TiCAP, is purchased in units of processing days. TiCAP allows
one or more cores beyond the count allowed by the available usage rights to be activated for up
to the specified period of prepaid minutes without requiring the purchase of additional usage
rights.
You can activate and deactivate cores according to your needs until the activation time equals
your prepaid temporary capacity duration. For example, with a prepaid duration of 30 days of
temporary capacity, you can activate one core for 30 days, or four cores for one hour a day for
180 days (or any combination that totals 43,200 minutes).
NOTE: Temporary Instant Capacity cannot be used to activate inactive Instant Capacity cell
boards or memory. To activate cores on an inactive cell board, you must first activate the cell
board and its memory either by using newly purchased cell and memory usage rights or by
deactivating a cell board and memory elsewhere in the server.
Your temporary capacity balance is decreased only when you are using more cores than normally
allowed by your available core usage rights. The charge against temporary capacity is not
associated with specific cores or partitions. That is, if you use temporary capacity to activate one
core in partition A, and then you deactivate any core in partition B, the complex stops using
temporary capacity.
The Instant Capacity software uses the debiting of temporary capacity to track the noncompliance
of a system, as described in “Instant Capacity Compliance and Enforcement” (page 38).
TiCAP can be added to an Instant Capacity system by purchasing and applying a temporary
capacity codeword (available from the Utility Pricing Solutions portal) using the icapmodify -C
command.
The icapstatus command provides information about the amount of temporary capacity time
remaining on the complex.
For more information about temporary capacity, see Chapter 5: “Temporary Instant Capacity”
(page 75). For a discussion of temporary capacity in a GiCAP group, see Chapter 7.
Temporary Instant Capacity 37
Instant Capacity Compliance and Enforcement
The Instant Capacity software primarily maintains complexwide information about the usage
rights and activation of system components. The software monitors the number of usage rights
for the entire complex for each type of component. (If you are using Global Instant Capacity, the
software also maintains groupwide information about usage rights. For more information about
GiCAP, see Chapter 7.)
The Instant Capacity software uses the debiting of temporary capacity as a compliance
enforcement mechanism on the following systems:
A system where TiCAP has been applied (the TiCAP balance is nonzero)
A GiCAP group member system (or a system which had previously been a GiCAP group
member and has a nonzero TiCAP balance)
A system which has had a TiCAP debit within the past 24 hours
If temporary capacity is negative, it means the system has gone out of compliance. Also, if the
temporary capacity balance is negative and the number of active cores exceeds the number of
core usage rights for the complex, automatic deactivation of cores might occur at boot time.
The Instant Capacity software authorizes activation of cores, cells, and memory if allowed by
the system usage rights. You cannot activate additional components if that action takes the system
out of compliance.
For example, if your Instant Capacity contract specifies that your server must contain 12 cores
with usage rights and 4 cores without usage rights, you can have up to 12 cores activated at any
one time, and 4 cores must be inactive at all times.
The Instant Capacity software can determine the following compliance aspects:
Whether a system is in compliance or out of compliance with the Instant Capacity contract
The number of additional cores that can be activated
The number of additional cells and the quantity of memory that can be activated
The enforcement methods used by the software include:
Not allowing activations that cause the system to be out of compliance
Deactivating cores at boot time:
Automatically deactivate cores at boot time if temporary capacity is exceeded and the
number of active cores continues to exceed the number of core usage rights for the
complex (see “Temporary Instant Capacity Expiration and Compliance Enforcement”
(page 86)).
Prevents a virtual partition from booting if the number of assigned cores is greater than
the number of intended active cores for the nPartition (see “Boot Time Compliance”
(page 66)).
For GiCAP members in a running (booted) virtual partition environment, if the number of
assigned cores is greater than the number of intended active cores, the icapmodify
command may be disallowed. In this case, to bring the vPar database into compliance,
deactivate cores using the vparmodify command.
On OpenVMS systems, the ICAP_SERVER process dynamically deactivates active cores that
exceed the number of core usage rights for the complex.
38 Getting Started
Configuration Change Notification
Specifying an increase or decrease in the number of active cores (using the icapmodify
command) causes a core configuration change. An email notification is sent to the system contact
when a change occurs that affects the configuration of cores.
If you do not want an email notification to be sent when configuration changes are made, disable
this feature by using the following command on HP-UX systems:
/usr/sbin/icapnotify -n off
Example 2-1 shows a configuration change email notification the Instant Capacity software sends
to the system contact. Note that if the operation is a deferred configuration change, “previous”
and “current” show equal values; only the value for “Number of cores to be active after reboot”
reflects the requested change.
Example 2-1 Configuration Change Notification email for Instant Capacity System (not vPar)
Subject: Instant Capacity Configuration Change Notification
A configuration change has been made to the following system:
super.corp.com
One or more cores were activated.
Details of the change include:
Time of change: 09/08/08 11:00:00
Deferred change: No
Previous number of active cores: 3
Current number of active cores: 4
Number of cores to be active after reboot: 4
Description of change: New fiscal year increase
Person making change: Mary Jones
System contact email: mjones@corp.com
If you are the system contact and do not want to receive this
type of notification in the future, it can be disabled by
executing the following command on the system in question:
/usr/sbin/icapnotify -n off
To turn notification on, execute:
/usr/sbin/icapnotify -n on
Configuration Change Notification 39
Core Activation
As previously described, an Instant Capacity system contains a specified quantity of activated
processing capacity (cells, cores, and memory) and a specified amount of deactivated processing
capacity. Systems can have fewer active components than they have rights to activate. Such
systems can instantly activate additional components without the need to purchase an RTU, up
to the number of component usage rights on the system.
Increasing Processing Capacity by Purchasing RTUs
When processing demands change significantly, you can enable use of additional system
components using the following procedure:
1. Purchase additional usage rights for a component type, by sending a purchase order to HP
for an Instant Capacity RTU product. Soon after HP receives your purchase order, you
receive a letter from HP that contains information about retrieving the RTU codeword from
the Utility Pricing Solutions web portal.
2. Acquire the RTU codeword from the Utility Pricing Solutions web portal:
http://www.hp.com/go/icap/portal
3. Apply the RTU codeword by entering the icapmodify -C command (note the -C option
is uppercase) on any partition in the complex.
4. Activate a component. Depending on the type of component, do one of the following:
Activate a core in a hard partition (nPartition) by entering the icapmodify -a
command. Note: For details about activating a core in a virtual partition, see “Instant
Capacity Integration with Virtual Partitions (HP-UX)” (page 31).
Activate a cell board by using the parmodify or parmgr command. For details about
activation of cell boards (and memory), see Activation of an Instant Capacity Cell
Board” (page 97).
IMPORTANT: To avoid a delay in activation of additional cores, purchase and keep in reserve
some quantity of temporary capacity for the system. Temporary capacity can be used to instantly
and temporarily activate cores while waiting for an RTU codeword. For details about temporary
capacity, see Chapter 5. You can also temporarily activate one or more cores using the Instant
Access Capacity (IAC) provided with the purchase of Instant Capacity processors.
40 Getting Started
Instant Capacity Cell Board
Instant Capacity Cell Board allows you to have additional (inactive) cell-board capacity in your
system for growing business needs. When the need arises, you can purchase additional cell and
memory usage rights; then the inactive cell boards, which contain memory and cores, are available
for instant activation and use.
The Instant Capacity software monitors and enforces the count of inactive cell boards (those
without usage rights) throughout the complex. Inactive cell boards assigned to a partition have
the use-on-next-boot flag set to n(no).
After applying a cell board and memory codeword to convey additional usage rights, you may
activate any cell board with memory not exceeding the amount allowed by the available memory
usage rights, and configure the cell into an nPartition. This is controlled by setting the
use-on-next-boot flag to y(yes) with the parmodify command after the cell is configured
and assigned to the partition, and then rebooting the nPartition.
IMPORTANT: An active cell board must have a minimum of one active core; therefore, you
must also have sufficient core usage rights on the complex to activate at least the one core per
cell board. The Instant Capacity software redistributes active cores across all cell boards of the
partition. Temporary Instant Capacity can be used to activate this core but the system needs to
have at least one core usage right for each active cell. Also, if you are creating a new partition
for the new cell board, additional constraints apply and you might need to acquire additional
core usage rights. For more information see “New Partition Creation and Instant Capacity”
(page 196).
For more information about Instant Capacity Cell Board, see Chapter 6: “Instant Capacity Cell
Board” (page 91).
Instant Capacity Cell Board 41
Instant Capacity Software Validation
On HP-UX Systems
The Instant Capacity software (HP-UX product B9073BA) is installed by HP manufacturing on
instantly ignited HP-UX systems. The Instant Capacity software can also be installed by an HP
service representative on existing (supported) HP-UX enterprise servers as an add-on.
NOTE: The Instant Capacity software is automatically installed when the HP-UX 11i v3, 11i
v2, or 11i v1 Operating Environment (OE) is installed.
To verify the Instant Capacity software is installed on your system, execute the following HP-UX
command:
/usr/sbin/swlist -l product iCOD
Output similar to the following is displayed:
iCOD B.11.23.09.00 HP-UX iCOD Instant Capacity
To verify that the Instant Capacity software installation has not been corrupted, execute the
following HP-UX command:
/usr/sbin/swverify iCOD
The command will display the message Verification succeeded.
On OpenVMS Systems
On OpenVMS systems, the Instant Capacity software is automatically installed on partitionable
systems when the OpenVMS Version 8.3 or later operating system is installed. You should not
need to install the Instant Capacity software separately on OpenVMS systems. Onsite Instant
Capacity installation by an HP service representative after the initial installation of OpenVMS
Version 8.3 is not an option for OpenVMS systems.
To verify that the Instant Capacity software is installed and configured, run the following
commands:
$ @sys$manager:ICAP$CLI_UTILS.COM CONFIG_CHECK
$ show log ICAP$CONFIGURED
"ICAP$CONFIGURED" = "TRUE" (LNM$JOB_nnnnnnnn)
42 Getting Started
Status Reporting on Instant Capacity Systems
You can use the icapstatus command to view the status of your Instant Capacity system. With
no options, the icapstatus command provides the following information:
Version number of the Instant Capacity software
System identification information (system ID, serial number, current product number, unique
ID)
Email addresses for both the system contact (mail to the local system) and a “From” address
(mail from the local system)
Asset reporting status (on or off)
Temporary capacity warning period (in days)
Exception status (indicates whether complex is in an exception state)
If part of a GiCAP group, group membership information, including borrow/loan status
Local partition information
Instant Capacity resource information for the entire complex
Allocation of Instant Capacity resources among the hard partitions
For information about what is reported by the icapstatus command, see “Checking the Status
of your Instant Capacity System” (page 52). For details about the icapstatus command, see
icapstatus(1M).
Status Reporting on Instant Capacity Systems 43
Time Zone Considerations
On HP-UX systems, the icapd daemon performs routine Instant Capacity software tasks on a
daily basis. A partition’s local time zone setting affects what time zone the icapd daemon uses
for the timing of these tasks Be sure that the time zone is set properly to ensure synchronization
among the partitions.
Because the HP-UX icapd daemon is started by init, the /etc/default/tz file must contain
the desired time zone specification. By default, the time zone is set to EST5EDT. You can specify
the time zone the icapd daemon uses to interpret noon and midnight by modifying the entry
in the /etc/default/tz file.
On OpenVMS systems, the ICAP_SERVER uses the time zone settings defined by the
SYS$STARTUP:TDF$UTC_STARTUP.COM file. To view the time zone settings, enter the command
@sys$manager:utc$time_setup show. Enter the command
@sys$manager:utc$time_setup and follow the menu instructions to modify the time zone
setting for the iCAP partition.
44 Getting Started
3 Installing and Removing Instant Capacity Software
This chapter covers the following topics:
“Installing Instant Capacity Software” (page 46)
“Reinstalling Instant Capacity Software” (page 48)
“Removing Instant Capacity Software” (page 49)
45
Installing Instant Capacity Software
Factory Integrated Systems
The Instant Capacity software is installed by HP on all HP enterprise servers, even those without
Instant Capacity components. To verify that the software is installed and configured, use the
following HP-UX command :
/usr/sbin/swverify iCOD
The command output displays the message Verification succeeded .
IMPORTANT: The Instant Capacity software is automatically installed when the HP-UX 11i v1,
11i v2, or 11i v3 Operating Environment (OE) is installed. If any partition in the system has
version B.06.x or later installed, then all partitions in the system with Instant Capacity software
must be running version B.06.x or later. For details about upgrading the software from a version
previous to B.06.x, see “Upgrading to Instant Capacity version B.06.x or later (HP-UX)” (page 193).
For HP-UX you generally do not need to install the Instant Capacity software. However, if you
do, it is available from the following media/location:
HP software depot at http://www.hp.com/go/softwaredepot
September 2008 HP-UX 11i v3 Operating Environments (OE) media
September 2008 HP-UX 11i v2 Applications Software media
September 2008 HP-UX 11i v1 Applications Software media
If the system is a Group Manager or a member of a GiCAP group, prior to installing the iCAP
version 9.0 software, ensure that WBEM version A.02.05 or later is installed, set the CIM Server
configuration property sslClientVerificationMode to “optional”, and restart the
cimserver on the Group Manager, the standby Group Manager (if any), and on all HP-UX OS
instances of all member systems. Because this configuration attribute is not dynamic, you must
specify the -p option, and you must restart the cimserver to set the value. For details, see
cimconfig(1M).
Use the following commands to set sslClientVerificationMode to “optional”and restart
the cimserver:
# cimconfig -s sslClientVerificationMode=optional -p
# cimserver -s; cimserver
Use the following command to verify the value of sslClientVerificationMode after a
restart:
# cimconfig -g sslClientVerificationMode -c -p
Current value: optional
Planned value: optional
Installing from the HP-UX Media (HP-UX 11i v1, 11i v2, and 11i v3):
Follow this procedure to install the Instant Capacity software on your HP-UX system from either
the appropriate HP-UX Applications Software or OE media:
1. Log in as root.
2. Determine the DVD drive device file by entering the following command:
ioscan -fnC disk
3. Insert the appropriate HP-UX Applications Software or OE DVD into the DVD drive.
4. Mount the DVD drive to the desired directory. The following example uses the /dev/dsk/
c1t2d0 device file (from step 2) and the /dvd directory. To mount the DVD drive, enter a
similar command as:
mount -r /dev/dsk/c1t2d0 /dvd
5. Install the B.09.x bundle B9073BA from the DVD:
46 Installing and Removing Instant Capacity Software
swinstall -s /dvd B9073BA
6. Continue with “For All HP-UX Installations” (page 47).
Installing from the HP Software Depot (For HP-UX 11i v1, 11i v2, and 11i v3):
1. Search for B9073BA on the HP Software Depot website: http://www.hp.com/go/
softwaredepot
2. Select the link that appeared as a result of your search, and follow the instructions on the
Installation page.
3. Continue with “For All HP-UX Installations” (page 47).
For All HP-UX Installations
After you have successfully installed the Instant Capacity software using the swinstall
command, perform the following procedure to validate your installation:
1. Execute the /usr/sbin/icapstatus command.
2. Verify that the icapstatus command output indicates the correct number of components
without usage rights for cells, cores, and memory.
If any number is incorrect, contact your local HP Response Center and request iCAP
assistance.
3. Log in as root
4. Set the system contact information by entering the following command:
/usr/sbin/icapmodify -c <contact_email_address>
5. If you want to configure asset reporting, then ensure that outgoing mail can be sent to HP
mail servers from your system, even if the system is behind a firewall. See “Diagnosing
Email Configuration” (page 142).
Test the transmission of your asset report, via email to HP, by entering the following
command:
/usr/sbin/icapnotify <reply_address>
The icapnotify command sends an asset report to HP, root, and the supplied reply
address.
HP responds with an email to the reply address after the asset report is received.
Use an email client to verify the return email from HP to the reply email address.
Installing Instant Capacity on OpenVMS Systems
On OpenVMS systems, the Instant Capacity software is automatically installed on partitionable
systems when the OpenVMS Version 8.3 or later operating system in installed. You should not
need to install the Instant Capacity software separately on OpenVMS systems. Instant Capacity
hardware components have already been configured at the factory before delivery. The Instant
Capacity software is included on the OpenVMS Version 8.3 Operating Systems media.
To verify that the Instant Capacity software is installed and configured, run the following
OpenVMS commands:
$ @sys$manager:ICAP$CLI_UTILS.COM CONFIG_CHECK
$ show log ICAP$CONFIGURED
"ICAP$CONFIGURED" = "TRUE" (LNM$JOB_nnnnnnnn)
Installing Instant Capacity Software 47
Reinstalling Instant Capacity Software
Preserving current Instant Capacity information
If you reinstall HP-UX on a partition with Instant Capacity (for example, installing HP-UX by
either cold-installing or installing from a golden image), you must perform the following steps.
Otherwise, all information in the Instant Capacity configuration file (change history, system
contact information) is lost.
IMPORTANT: If the system is a member of a GiCAP group, it should be removed from the
group before reinstalling HP-UX, and added back into the group after the reinstallation.
“Reinstalling a Group Member” (page 118) describes a workaround if HP-UX is reinstalled while
a system is a member of a GiCAP group. If the system is a GiCAP Group Manager, additional
steps described in Chapter 7 are necessary to configure the Group Manager after a reinstallation
of HP-UX.
1. Before the reinstall action , manually save your Instant Capacity data and processor allocation
history by backing up the following files:
a. HP-UX: /etc/.iCOD_data
OpenVMS: SYS$SYSTEM:SYS$ICAP.DAT
b. HP-UX: /var/adm/icap.log
OpenVMS: SYS$MANAGER:ICAP.LOG
c. HP-UX: /var/adm/icap.log.old
d. OpenVMS: SYS$MANAGER:ICAP$CORES.DAT
These files are restored in step 3.
2. Install the appropriate HP-UX or OpenVMS OE from its media onto the partition. The Instant
Capacity software bundle B9073BA is installed automatically when the HP-UX OE is installed,
and the Instant Capacity software bundle BA484AA is installed automatically on OpenVMS
systems.
3. Restore your Instant Capacity data and processor allocation history files:
a. HP-UX: /etc/.iCOD_data
OpenVMS: SYS$SYSTEM:SYS$ICAP.DAT
b. HP-UX: /var/adm/icap.log
OpenVMS: SYS$MANAGER:ICAP.LOG
c. HP-UX: /var/adm/icap.log.old
d. OpenVMS: SYS$MANAGER:ICAP$CORES.DAT
48 Installing and Removing Instant Capacity Software
Removing Instant Capacity Software
IMPORTANT: Do not attempt to remove the Instant Capacity software.
Removing Instant Capacity Software 49
50
4 Using Instant Capacity to Manage Processing Capacity
This chapter covers the following topics:
“Checking the Status of your Instant Capacity System” (page 52)
“Setting System Contact Information” (page 54)
Applying a Right To Use (RTU) Codeword” (page 55)
Activating Cores” (page 57)
“Deactivating Cores” (page 59)
“Overriding Deferred Activation and Deactivation” (page 61)
“Load-Balancing Active Cores” (page 62)
“Understanding and Managing Intended Active Values” (page 63)
Activations and Deactivations in a Virtual Partition Environment” (page 64)
Assigning a Cell to a Partition” (page 67)
“Unassigning a Cell from a Partition” (page 69)
“Software Application Considerations” (page 71)
“Test Activation of Cores Using Temporary Capacity” (page 72)
“Replacement of Failed Cores” (page 73)
51
Checking the Status of your Instant Capacity System
You can use the icapstatus command to view the status of your Instant Capacity system. The
icapstatus command, issued without options, provides the following information:
Version number of the Instant Capacity software
System identification information (system ID, serial number, product number, unique ID)
System contact email address
Instant Capacity From: email address
Asset reporting status (on or off)
Temporary capacity warning period (in days)
Exception status (indicates if complex is in an exception state)
If a member of a GiCAP group, membership information and borrow/loan status of usage
rights
Local virtual partition status (if applicable):
Total number of assigned cores
Number of active assigned cores
Number of inactive assigned cores
Additional cores that can be assigned with current usage rights
Number of cores that could be assigned with additional usage rights
Number of cores that can be assigned with temporary capacity
Number of cores currently unavailable for assignment
Local nPartition status (if not a virtual partition):
Date and time the command was issued
Total number of configured cores
Number of intended active cores
Number of active cores
Number of inactive cores
Additional cores that can be activated with current usage rights
Number of cores that could be activated with additional usage rights
Number of cores that can be activated with temporary capacity
Number of cores that are deconfigured or attached to inactive cells
Instant Capacity resource summary:
Number of cells without usage rights
Number of inactive cells
Amount of memory without usage rights
Amount of inactive memory
Number of cores without usage rights
Number of inactive cores
Number of cores using temporary capacity
Number of cores that must be deactivated (insufficient usage rights)
Temporary capacity available
Projected temporary capacity expiration
Allocation of Instant Capacity resources among hard partitions:
nPar ID
Total cores
Intended active cores
Actual active cores
Inactive cores
52 Using Instant Capacity to Manage Processing Capacity
Inactive memory
Inactive cells
Runs iCAP (indicates whether the hard partition contains compatible Instant Capacity
software)
nPar name
For details about the icapstatus command and its output, see icapstatus(1M).
Example 4-1 Sample Session of icapstatus (on HP-UX)
> /usr/sbin/icapstatus
Software version: B.11.31.09.00.00.71
System ID: supericod
Serial number: 1234567890
Product number: A6912A
Unique ID: fffff-fff-ffffff-ffff
System contact e-mail: mjones@corp.com
From e-mail: Set to the default ('adm')
Asset reporting: on
Temporary capacity warning period: 15 days
Exception status: No exception
Local nPartition Status (09/17/08 12:34:56)
-------------------------------------------
Total number of configured cores: 8
Number of Intended Active cores: 7
Number of active cores: 6
Number of inactive cores: 2
Additional cores that can be activated with current usage rights: 1
Number of cores that could be activated with additional usage rights: 1
Number of cores that can be activated with temporary capacity: 0
Number of cores that are deconfigured or attached to inactive cells: 0
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 0
Number of inactive cells: 0
Amount of memory without usage rights: 0.0 GB
Amount of inactive memory: 0.0 GB
Number of cores without usage rights: 4
Number of inactive cores: 6
Number of cores that must be deactivated (insufficient usage rights): 0
Temporary capacity available: 0 days, 0 hours, 0 minutes
Allocation of Instant Capacity Resources among the nPartitions
--------------------------------------------------------------
Intended Actual
nPar Total Active Active =======Inactive======= Runs
ID Cores Cores Cores Cores Memory Cells iCAP nPar Name
==== ===== ======== ====== ====================== ==== ====================
0 8 5 4 4 0.0 GB 0 Yes Partition 0
1 8 7 6 2 0.0 GB 0 Yes Partition 1 (local)
N/A 0 N/A N/A N/A 0.0 GB 0 N/A Unassigned Cells
Checking the Status of your Instant Capacity System 53
Setting System Contact Information
HP recommends that you specify a system contact’s email address on each partition in your
system. On OpenVMS systems, the email address may be a logical pointing to a distribution list.
If specified, the system contact receives the following types of Instant Capacity email:
Configuration change notification when cores are activated or deactivated
Compliance exception notification
Temporary capacity expiration notification
Instant Capacity enforcement notification
Virtual partition boot time compliance notification
If participating in a GiCAP group and a hardware incompatibility is detected (see “Upgrades
and Global Instant Capacity” (page 121))
NOTE: Instant Capacity email messages are sent to the system contact email address, if specified,
and the root account on the partition. Most notifications are also written to the system log.
To specify the Instant Capacity system contact’s email address, use the icapmodify -c
command. Note that you must specify a valid Internet email address. For example:
> /usr/sbin/icapmodify -c mjones@corp.com
The contact email address has been set to mjones@corp.com.
NOTE: The email address specified for the system contact can be an email alias if you want
multiple recipients to receive Instant Capacity email messages.
54 Using Instant Capacity to Manage Processing Capacity
Applying a Right To Use (RTU) Codeword
Unless you have a balance of Instant Access Capacity (IAC) or temporary capacity (or usage
rights available from a GiCAP group), you must purchase additional usage rights before activation
of an inactive core. To purchase additional usage rights:
1. Contact your HP sales representative to purchase the appropriate Instant Capacity RTU
products.
2. Acquire an RTU codeword from the Utility Pricing Solutions web portal at http://
www.hp.com/go/icap/portal.
3. Apply the RTU codeword using the icapmodify -C command. Note that the -C option
is in uppercase.
Example Example 4-2 shows how to apply a core RTU codeword using the icapmodify -C
command.
Example 4-2 Applying an RTU Codeword (HP-UX)
> /usr/sbin/icapmodify -C mDwvj0M.fbHhKC9.byrgc8k.Pc7PjMt-1cp63H9.29xrDLU.g2CJhQM.RzuYyd6
The following valid codeword has been applied to the complex:
Right to Use Codeword
1 Core(s)
Use icapstatus(1M) to see the results of the application of this codeword.
NOTE: Application of Right to Use codewords does not result in the
activation of components. Use icapstatus(1M) to see the results
of the application of this codeword.
For cores: Use icapmodify(1M) to activate the cores.
For cell boards and memory: Use parmodify(1M) to activate cells
by setting the use_on_next_boot flag to y or use parmgr(1M).
Application of the codeword increments the count of Additional cores that can be
activated with current usage rights (limited by the Number of inactive cores)
in the output of the icapstatus command.
IMPORTANT: RTU codewords are based on both the serial number of a system and a unique
sequencing value for that server. These codewords must be applied in the sequence in which
they are obtained for a particular server. They can be applied to any partition on the server.
Figure 4-1 (page 56) illustrates the process of ordering Instant Capacity components and ordering
and applying usage rights.
Applying a Right To Use (RTU) Codeword 55
Figure 4-1 Permanent Activation of Instant Capacity Components
Order iCAP
System/
Components
Apply IAC
Codeword to
System
Acquire IAC
Codeword
from Portal
Acquire RTU
Codeword
from Portal
Activate
Component(s)
Using IAC
Consumption
of IAC Halted
Apply RTU
Codeword to
System
Order
iCAP
RTU(s)
HP (or rep)
Installs iCAP
System/
Components
Customer
Additional Core
Capacity Needed
Post IAC in
iCAP DB
Post RTU Order
in iCAP DB
Send
Ack
Letter
HP
Process
Order for
RTU(s)
Ship iCAP
System/
Components
56 Using Instant Capacity to Manage Processing Capacity
Activating Cores
The icapmodify command provides the ability to increase processing capacity instantly by
activating cores with available usage rights in Instant Capacity systems. At any time, any number
of inactive cores with usage rights can be activated, as long as sufficient usage rights are available.
Whether you are activating or deactivating cores, the icapmodify command adjusts only the
number of dynamic cores, and it does not explicitly identify specific cores.
Activating Cores in nPartitions
The Instant Capacity software provides two types of activation:
Instant (icapmodify command’s default behavior) — activation occurs immediately.
Deferred (icapmodify -D) — activation occurs after the next reboot of the partition.
Instant activation of cores occurs when the icapmodify command is used with either the -a
or -s option, and the -D option is not specified. If the -s option is used, the number of cores
specified must be greater than the number of currently active cores.
Deferred activation of cores occurs when the icapmodify command is used with both the -D
option and either the -a or -s option. With the deferred option (-D), core activation occurs after
a reboot of the partition. The reboot (and the core activation) can take place at a planned time.
For example, if you activate cores in deferred activation mode and schedule a partition reboot
to occur on the first day of the next month, the cores are activated at that time.
IMPORTANT: If you shut down a partition for 12 hours or more, it should be powered off or
deactivated to avoid additional charges. To power off the partition, execute the PE command
from the system MP.
On HP-UX systems, always use the shutdown -R -H command when shutting down or
rebooting an Instant Capacity partition. If the partition is already shut down, use the rr command
from the system MP to reset cells for reconfiguring. For information about the shutdown
command, see shutdown(1M).
On OpenVMS systems, always use the sys$system:shutdown.com command procedure
when shutting down or rebooting an Instant Capacity partition.
Although a deferred activation does not immediately change the number of active cores, the
intended active value is changed. This change does affect compliance checking, even before the
partition reboot occurs. In particular, compliance checking is calculated as if the activation had
not been deferred.
IMPORTANT: On OpenVMS Instant Capacity systems, HP strongly recommends that you
activate cores using the icapmodify or the ICAP SET command. The use of the START CPU
command on an Instant Capacity system can result in unintended consequences, such as a
reduction of available temporary capacity. Another unintended side effect might be the adjustment
in core usage across the complex, depending on the intended core settings on the partition where
the START CPU command was issued.
To activate one or more inactive cores, use the icapmodify command as root. For more
information about this command, see icapmodify((1M)).
Constraints
The Instant Capacity software does not activate cores that are marked for deconfiguration. Also,
you cannot use Instant Capacity to activate more cores than are configured in the current
nPartition. If you want more cores, you must modify the nPartition with the parmodify
command. You can use Instant Capacity to activate more cores than are configured into the
current virtual partition, but only if the associated nPartition contains enough unassigned cores
Activating Cores 57
and the virtual partition allows enough additional cores to fulfill the request . Otherwise, use
the parmodify command to reconfigure the nPartitions, or use the vparmodify command to
remove cores from other virtual partitions within the same nPartition (essentially adding to the
unassigned pool).
Example Core Activation Session
Example 4-3 shows how to activate an additional core in an nPartition environment. At the
beginning of this activation session, there are a total of 4 cores in the partition; 2 cores are activated
and 2 are inactive, but usage rights have been acquired to activate at least one inactive core. In
this example, 1 additional core is activated, leaving the partition with 3 active cores and 1 inactive
core.
Example 4-3 Activating an Additional Core (HP-UX)
> /usr/sbin/icapmodify -a 1 "Add CPU for new FY: Bill P."
3 cores are intended to be active and are currently active.
In this example, note the following:
The core activation is instant (that is, a reboot is not required).
The double-quoted text serves as an audit trail of why the activation was done and who
performed it. This information is optional and is written to the Instant Capacity log file
(var/adm/icap.log) if provided.
NOTE: To defer the activation until the next reboot, add the -D option to the command. For
more information, see icapmodify(1M).
The icapmodify command allows you to activate additional cores with the -a option, or set
the total number of active cores with the -s option. For example, the icapmodify -a 2
command activates two additional cores in a partition. The icapmodify -s 2 command sets
the total number of active cores in a partition to 2.
For details about software application implications when activating additional cores, see “Software
Application Considerations” (page 71).
58 Using Instant Capacity to Manage Processing Capacity
Deactivating Cores
You can decrease processing capacity instantly on HP enterprise servers with the Instant Capacity
software (even on servers with sufficient usage rights for all cores to be active simultaneously).
Any number of active cores can be deactivated at any time, within the following partition
constraints. Core deactivation can be useful for load balancing cores in nPartitions (hard partitions)
of Instant Capacity systems.
Deactivating Cores in nPartitions
The software provides two types of core deactivation:
Instant (icapmodify command’s default behavior) — deactivation occurs immediately.
Deferred (icapmodify -D) — deactivation occurs after the next reboot of the partition.
Instant deactivation of cores occurs when the icapmodify command is used with the -d option
but without the -D option.
IMPORTANT: On OpenVMS Instant Capacity systems, HP strongly recommends that you
deactivate cores using the icapmodify or the ICAP SET command. The use of the STOP CPU
command on an Instant Capacity system can result in unintended consequences, such as a
reactivation of the core when an Instant Capacity reconciliation transaction is requested.
Deferred deactivation of cores occurs when the icapmodify command is used with both the
-D and -d options. With the deferred option (-D), core deactivation occurs after a reboot of the
partition. The scheduled timing of the reboot (and the core deactivation) can take place at a
planned time. For example, if you deactivate cores in deferred activation mode and schedule a
partition reboot to occur on the first day of the next month, the cores are deactivated at that time.
Since deferred deactivation does not immediately decrease the number of active cores, compliance
checking is not affected by deferred deactivation.
To deactivate one or more active cores, use theicapmodify command as root. For details, see
icapmodify(1M).
Partition Constraints
An nPartition must have a minimum of one active core for each active cell. Deactivation of cores
is limited by this rule. If the deactivation applies to a virtual partition, additional constraints
might apply, such as the minimum number of cores specified for the virtual partition.
Example Deactivation Session for Hardware-Partitionable Systems
Example 4-4 (page 60) shows how to deactivate an active core. At the beginning of this
deactivation session, there are a total of 4 cores in the partition; 3 cores are active and 1 is inactive.
In this example, 1 active core is deactivated, leaving the partition with 2 active cores and 2 inactive
cores. As with activation, you do not specify a particular core to be deactivated. You specify only
the number of cores to be deactivated.
Deactivating Cores 59
Example 4-4 Deactivating an Active Core (HP-UX)
> /usr/sbin/icapmodify -d 1
2 cores are intended to be active and are currently active.
NOTE: In Example 4-4, the core deactivation is instant (that is, does not require a reboot). To
defer deactivation until the next reboot, use the -D option with the command. For details, see
icapmodify(1M).
The icapmodify command allows you to either deactivate cores with the -d option or to set
the total number of active cores with the -s option. For example, the icapmodify -d 1
command deactivates 1 additional core in a partition. The icapmodify -s 2 command sets
the total number of active cores in a partition to 2.
60 Using Instant Capacity to Manage Processing Capacity
Overriding Deferred Activation and Deactivation
NOTE: Although this section discusses only activation of cores, the discussion applies also to
deactivation of cores.
If you have performed a deferred core activation (using the icapmodify -D command), and
the intended number of active cores specified is no longer desirable, you can override the
(pending) deferred activation by performing another deferred or instant icapmodify operation.
This second operation overrides the first activation.
You might experience one of the following scenarios with deferred activation:
The deferred number of active cores was incorrect and you want it to be correct when the
system reboots.
The entire deferred operation was accidental and you want to undo it.
Example 4-5 and Example 4-6 describe how to override these situations.
Example 4-5 Correcting an Incorrect Number of Deferred Active Cores (HP-UX)
1. On your system or partition you currently have 2 active cores and 2 inactive cores. You need
4 active cores, so you perform a deferred activation for 2 additional active cores by entering
the following command:
/usr/sbin/icapmodify -D -a 2
2. Later, and prior to a system reboot, you realize that you need only 3 active cores (not 4).
You can override the action in step 1 by entering the following command:
/usr/sbin/icapmodify -D -s 3
The -s option in step 2 sets the number of active cores. The activation takes place after the next
system reboot due to the -D option. You could also perform step 2 without the -D option so that
the icapmodify operation is instant.
Example 4-6 Undoing an Accidental Deferred Activation (HP-UX)
1. On your system or partition, you currently have 2 active cores and 2 inactive cores. You
accidentally perform a deferred activation for 1 additional active core by entering the
following command:
/usr/sbin/icapmodify -D -a 1
2. Later, and prior to a system reboot, you realize that you didn’t want to activate the additional
core (which would give you 3 active cores) and you want the number of active cores to be
2. You can override the action in step 1 by entering the following command:
/usr/sbin/icapmodify -a 0
The -a 0 option in step 2 overrides the previous (deferred) icapmodify command, which was
executed in step 1. The -a option is relative to the number of active cores, not to the intended
number of active cores.
You could accomplish the same result as step 2 with the following command:
/usr/sbin/icapmodify -s 2
Overriding Deferred Activation and Deactivation 61
Load-Balancing Active Cores
Active cores can be redistributed across any or all partitions of a hardware-partitionable system
if those partitions contain inactive cores.
For example, consider a system with two partitions:
Partition 1 has 5 active cores and 3 inactive cores.
Partition 2 has 8 active cores and 0 inactive cores.
You need to add processing power to Partition 1 because of application demand and you notice
that the active cores in Partition 2 are underutilized.
Deactivating an active core in Partition 2 decreases the number of active cores in that partition,
and activating one of the cores in Partition 1 increases the number of active cores in that partition.
The total number of active cores in the complex is the same at the end of this operation.
IMPORTANT: To remain in compliance, you must perform the deactivation operation first.
The two partitions are left with the following:
Partition 1 now has 6 active cores and 2 inactive cores.
Partition 2 now has 7 active cores and 1 inactive core.
Redistribution of active cores does not affect compliance. This is because you do not change the
overall number of active cores in the complex. If the complex was in compliance prior to the
redistribution, it remains in compliance. Make sure that you have proper licensing for all
proprietary and nonproprietary software when performing load balancing.
62 Using Instant Capacity to Manage Processing Capacity
Understanding and Managing Intended Active Values
The Instant Capacity software maintains a value for each nPartition of a complex called intended
active. Fundamentally, the intended active value is the number of cores intended to be active
after a reboot of the nPartition.
The concept and proper manipulation of intended active is critical because:
It determines the number of cores which will be active upon the boot of an nPartition.
The value is used to establish the allocation of core usage rights for an nPartition within the
total number of core usage rights purchased for the complex. That is, it represents the
intended distribution of core resources for each nPartition.
When the intended active value changes, the distribution of usage rights across the hard partitions
is changed, and the core resources originally intended for one nPartition might be diverted to
another nPartition. In fact, this is the mechanism that allows for load balancing of resources to
occur. Within a GiCAP group, changes to the intended active value allow resources to be load
balanced across the entire group. Naturally, it is important to be sure that this is an intentional
redistribution of resources.
Note that even inactive nPartitions have an intended active value that represents a “reservation”
of usage rights for that partition. This is necessary to ensure every configured nPartition has core
resources in order to boot.
IMPORTANT: An nPartition that was created but never booted to HP-UX will implicitly reserve
usage rights for all configured cores, regardless of any intended active value set for the nPartition.
Within a virtual partition environment, the intended active value is especially critical because a
value that does not conform to the virtual partition assignments can result in a virtual partition
environment that cannot be booted. For more information see “Boot Time Compliance” (page 66).
In a virtual partition environment, the behavior of the icapmodify -a,-d and -s options is
different when there is unused capacity represented by an intended active value that exceeds
the sum of the cores assigned to the virtual partitions in an nPartition, as described in Activations
and Deactivations in a Virtual Partition Environment” (page 64).
Understanding and Managing Intended Active Values 63
Activations and Deactivations in a Virtual Partition Environment
Instant Capacity can be present on HP-UX systems or partitions where virtual partition technology
is employed. In a virtual partition environment, cores that are not assigned to any virtual partition
are considered inactive (in addition to other classes of inactive cores). Unassigned cores can be
assigned (activated) or deassigned (deactivated) using either the icapmodify command or the
vparmodify command, depending on the type of adjustment needed and the level of logging
or reporting desired.
One important consideration is that vparmodify can be used to activate or deactivate cores in
other virtual partitions within the nPartition; icapmodify only activates or deactivates cores
within the current virtual partition (the partition where the command is invoked). The
vparmodify command does not change the value for the number of intended active cores for
the nPartition.
Another consideration is that core assignment via the vparmodify command does not result
in Instant Capacity logging of the activation, email configuration change notification, or
transmission of an asset report to HP.
NOTE: Deferred activations and deactivations are not supported in any virtual partition
environment.
Instant Capacity always consumes unused capacity before it consumes additional usage rights
when activating cores. Instant Capacity always releases usage rights from unused capacity before
it releases usage rights by deactivating cores.
When to Use the vparmodify or icapmodify Commands
When usage rights freed by deactivating cores are to be used in a different nPartition, use the
icapmodify command. When usage rights freed by deactivating cores are to be used by another
virtual partition within the same nPartition, use the vparmodify command. The following
sections provide details on activating and deactivating cores within nPartition and virtual partition
environments.
What is Unused Capacity
In a virtual partition environment, the Instant Capacity software may allocate or deallocate cores
from what is called “unused capacity”. Unused capacity is the difference between actual active
and intended active cores, and it is a side effect of using vparmodify to deactivate cores while
not immediately activating the cores in another virtual partition within the same nPartition. This
is usually a transient state, since a user typically migrates cores from one virtual partition to
another with a deactivate command followed by an activate command. However, unused capacity
can persist if, for example, a utility such as gWLM ignores an error status from an activation and
leaves the previously deactivated cores in an unassigned state. The Instant Capacity software
always takes unused capacity into account when a request is made to activate or deactivate cores
such that it attempts to eliminate the discrepancy between intended active and actual active.
Static Virtual Partitions
If a virtual partition is static (that is, if its resources cannot be migrated, added, deleted, or
modified) and you attempt to activate or deactivate cores, the Instant Capacity software displays
a message indicating that the configuration cannot be modified.
64 Using Instant Capacity to Manage Processing Capacity
NOTE: The icapstatus command output indicates that the number of cores that can be
assigned (to the local virtual partition) is zero if the static resource attribute for the local virtual
partition is set.
Activating Cores in a Virtual Partition Environment
In a virtual partition environment, the icapmodify command must be used to modify processing
capacity when you are making any adjustment to an nPartition or to multiple nPartitions. When
you execute the icapmodify command to activate a core, the Instant Capacity software verifies
that the request can be satisfied. If so, the local nPartitions intended active number is increased,
and the appropriate number of cores are added to the local virtual partition.
When cores in a virtual partition are activated using the icapmodify command, if unused
capacity is available, the cores are activated from the unused capacity balance before increasing
the active cores. If enough cores are available to meet the request, the proper number of cores
are added to the local virtual partition. If there is any unused capacity available prior to the
activation, the result is that the actual active count changes by more than the intended active
count, and the intended active count may not change at all. However, the discrepancy between
intended active and actual active is reduced. If there is no unused capacity available, the desired
number of cores will be activated in the virtual partition.
If you are adjusting core assignments across virtual partitions in a single nPartition, use the
vparmodify command for the best coordination between the Instant Capacity software and the
vPars software, and for optimized performance. The vparmodify command is the fastest and
most efficient way to adjust capacity within virtual partitions of a single nPartition, but it does
not affect the intended active count for the nPartition. Therefore, it cannot be used to migrate
unused capacity either to or from other nPartitions. When you execute the vparmodify command
to activate a core, the command verifies with the Instant Capacity software how many cores are
available for activation. This number is calculated as the difference between the local nPartition’s
intended active number and the total number of cores assigned to the vPars database.
Deactivating Cores in a Virtual Partition Environment
In a virtual partition environment, the icapmodify command must be used to modify processing
capacity when you are making any adjustment to an nPartition or to multiple nPartitions. When
you execute the icapmodify command to deactivate a core, the Instant Capacity software
verifies that the request can be satisfied. If so, the local nPartition’s intended active number is
decreased, and the appropriate number of cores are removed from the local virtual partition.
When the icapmodify command is used in a virtual partition, it checks with the Instant Capacity
software to determine how many cores are available for deactivation. This number is calculated
as the difference between the local nPartition’s intended active number and the total number of
cores assigned to the vPars database. If there is any unused capacity available prior to the
deactivation, the result is that the actual active count changes by more than the intended active
count, and the intended active count may not change at all. However, the discrepancy between
intended active and actual active is reduced.
If you are adjusting core assignments across virtual partitions in a single nPartition, use the
vparmodify command for the best coordination between the Instant Capacity software and the
vPars software, and for optimized performance. The vparmodify command is the fastest and
most efficient way to adjust capacity within virtual partitions of a single nPartition, but it does
not affect the intended active count for the nPartition and it therefore cannot be used to migrate
unused capacity either to or from other nPartitions. When you execute the vparmodify command
to deactivate a core, authorization is not required from the Instant Capacity software.
Whether you are activating or deactivating cores, the icapmodify command adjusts only the
number of dynamic cores, and it does not explicitly identify specific cores.
Activations and Deactivations in a Virtual Partition Environment 65
Boot Time Compliance
A compliance check is performed whenever a virtual partition is booted. If the total number of
cores assigned to all virtual partitions in the current vPar database exceeds the nPartition’s
intended active core count, the Instant Capacity software notifies the vPar monitor. The monitor
prevents any virtual partition from booting until the user first performs a hard partition boot
and then modifies either the vPar configuration or the Instant Capacity intended active count
for the nPartition. Example 4-7 shows a sample boot-time compliance message sent when a
virtual partition is prevented from booting.
Example 4-7 vPar Boot–Time Compliance Message
To: root@par1.yourorg.com
Subject: vPar Boot Time Compliance
This message is being sent to inform you that a vpar is not
being allowed to boot because doing so would take this complex
out of compliance from an Instant Capacity perspective. The
number of cores assigned to this vPar database (/stand/vpdb)
exceeds the number of intended active cores by 1. To correct
this problem, boot this partition back into an nPartition and
modify the vPars assigned to this database or modify the number
of intended active cores for this nPartition.
66 Using Instant Capacity to Manage Processing Capacity
Assigning a Cell to a Partition
A cell can be assigned to a partition only if sufficient cell usage rights are available across the
complex, as well as sufficient memory usage rights to enable activation of all the memory on the
cell, and sufficient usage rights for at least one core of the cell to be active.
In an Instant Capacity system, when a cell is assigned to a partition, depending on the number
of core usage rights available in the system when the cell is assigned, the number of intended
active cores for the partition automatically changes. Figure 4-2,Figure 4-3, and Figure 4-4 illustrate
a single partition with one assigned and one unassigned cell.
Figure 4-2 Partition premodification state: One cell assigned with 3 active and 1 inactive cores,
and usage rights for 2 additional cores
AActive Core
Inactive (iCAP) Core
Cell 1
AAA
Available Core
Usage Rights
UR UR
I
I
Figure 4-3 Premodification state: Unassigned cell with 4 inactive cores and no usage rights
Cell 2
II I I
Figure 4-4 Partition postmodification state: Cell 2 assigned to partition
Cell 1
AAA I
Cell 2
AA II
When Cell 2 is assigned to the partition, the number of intended active cores for the partition is
automatically changed to 5. When the partition is rebooted, 5 cores in the partition are activated.
When an unassigned cell is assigned to a partition via the parmodify command, the Instant
Capacity software determines the number of available core usage rights in the complex, and uses
this number to activate as many cores as possible in the new cell. (This number typically
corresponds to the icapstatus value for Additional cores that can be activated
with current usage rights or the actual number of cores, whichever is smaller. In order
to assign an inactive cell to a partition, this value must be nonzero.)
However, when a new partition is created via the parcreate command, core usage rights must
be available for all cores configured on the new partition's cells, and core usage rights are
automatically assigned to these new cells. For more information see “New Partition Creation
and Instant Capacity” (page 196).
Note that when determining available usage rights, the Instant Capacity software calculates the
usage rights consumed by each partition to be the greater of either the actual active or
intended active cores for the partition.
Assigning a Cell to a Partition 67
NOTE: Cell boards are assigned to specific partitions and cannot be shared between partitions.
All cores on a cell board are accessible by only the partition to which the cell board is assigned.
Cores on one cell board cannot be shared across multiple partitions.
68 Using Instant Capacity to Manage Processing Capacity
Unassigning a Cell from a Partition
When a cell is unassigned from a partition in an Instant Capacity system, the number of intended
active cores in the partition decreases only if the number of cores being removed with the cell is
greater than the number of expected inactive cores in the partition. In Figure 4-5,Figure 4-6, and
Figure 4-7 showing a single partition system with 3 cells, the number of intended active cores
remains the same because the number of cores with the removed cell (4) does not exceed the
total number of expected inactive cores in the partition (6).
Figure 4-5 Partition premodification state: Three cells with 2 active and 2 inactive cores in each,
and 6 expected inactive cores
Cell 1
AA II
Cell 2
AA II
Cell 3
AA II
Figure 4-6 Partition postmodification state: Cell 3 is unassigned (total of 6 active cores remaining)
Cell 1
A AA I
Cell 2
A AA I
Figure 4-7 Partition postmodification state: Unassigned Cell 3 with 4 inactive cores
Cell 3
IIII
When Cell 3 is unassigned from the partition, the number of intended active cores for the partition
remains at 6. When the partition is rebooted, a total of 6 cores are activated. Cell 3 becomes an
unassigned cell with 4 inactive cores, essentially freeing up usage rights that are distributed
among the remaining cells.
In Figure 4-8,Figure 4-9, and Figure 4-10, the number of cores removed (4) is greater than the
number of expected inactive cores in the partition (3). When this happens, the number of intended
active cores is automatically set to the total number of remaining cores in the partition (8).
Figure 4-8 Partition premodification state: Three cells with 3 active and 1 inactive cores in each,
and 3 expected inactive cores
Cell 1
A AA I
Cell 2
A AA I
Cell 3
A AA I
Unassigning a Cell from a Partition 69
Figure 4-9 Partition postmodification state: Unassigned Cell 3 (total of 8 active cores are set)
Cell 1
A A AA
Cell 2
A A AA
Figure 4-10 Postmodification state: Unassigned Cell 3 with 4 inactive cores, with usage rights
available for 1 additional core
Cell 3 Available
Usage Rights
UR
IIII
When Cell 3 is unassigned from the partition, the number of intended active cores changes from
9 to 8 (because 8 is the total number of cores remaining in the partition). When the partition is
rebooted, a total of 8 cores are activated. Cell 3 becomes an unassigned cell with 4 inactive cores,
and (unused) usage rights are available for 1 additional core for the complex.
NOTE: If you intend to migrate a cell from one partition to another, you can control the number
of core usage rights available to the cell (in the new partition) by deactivating cores in the partition
you removed the cell from. By deactivating cores, you make core usage rights available to the
entire complex.
70 Using Instant Capacity to Manage Processing Capacity
Software Application Considerations
Some software applications size themselves based on the number of available cores when the
application is started. If an application is running when an additional core is activated, the
application might not recognize the newly activated core as available for processing. Therefore,
you might need to do one of the following for optimal performance with this type of application:
Restart the application in order for it to recognize the presence of newly activated cores.
Reconfigure the application prior to restarting it, for maximum performance benefits of the
newly activated core.
Use the deferred activation option when activating cores so that processors are activated
only in conjunction with system reboots. For details, see icapmodify(1M) for details
IMPORTANT: When you activate a core, the number of active cores in the system increases.
Consequently, a license upgrade might be required for some of the software from HP or other
vendors on your system.
Software Application Considerations 71
Test Activation of Cores Using Temporary Capacity
You might want to test your software application for proper operation and improved performance
by activating an additional core. The use of temporary capacity or Instant Access Capacity (IAC)
is required for activation of a core without usage rights for testing purposes. For details, see
Chapter 5: “Temporary Instant Capacity” (page 75).
The following testing guidelines are meant to be an aid to your test plan. You might need to get
consulting help to develop a more detailed plan.
1. Test your applications for proper functionality and performance first by testing with the
number of inactive cores equal to the number of cores without usage rights. (The system
should already be configured this way.) Be sure to check measurement tools that monitor
core usage.
2. Acquire temporary capacity for the necessary amount of core test activation.
3. Use temporary capacity to activate one or more inactive cores to be used while your
applications are running.
4. Confirm that measurement tools, which monitor processing usage, account for the newly
activated cores.
5. Verify that applications are benefiting from the performance of the extra cores (as per your
expectations for your applications). Some applications might need to be restarted or
reconfigured to take advantage of the newly activated cores.
6. When you are finished with your testing, deactivate cores until the number of inactive cores
again matches the number of cores without usage rights, thereby stopping the usage of
temporary capacity.
7. Use icapstatus to verify that no cores are consuming temporary capacity.
72 Using Instant Capacity to Manage Processing Capacity
Replacement of Failed Cores
HP-UX LPMC and HPMC
If an active core fails with a Low Priority Machine Check (LPMC) in a partition with Instant
Capacity, its processing capacity is replaced instantly by an inactive core, if any are available in
the partition. The failed core is marked for deconfiguration during the next system reboot.
For additional considerations in a virtual partition environment, see “LPMC Deactivations in
Virtual Partitions” (page 73).
If an active core fails with a High Priority Machine Check (HPMC), then upon reboot the failed
core is deconfigured and its processing capacity is instantly replaced by an inactive core, if any
are available in the partition.
NOTE: In both of the preceding scenarios, replace the failed core in a timely manner using your
normal hardware support process.
LPMC Deactivations in Virtual Partitions
In a vPar environment, if the LPMC monitor deactivates a core, it automatically replaces the
failing core with an Instant Capacity core from the free pool, if such a core is available. The failing
core remains in the virtual partition until either the virtual partition or the virtual partition
monitor is rebooted.
For more information about LPMC in vPars, see the various white papers at the HP Documentation
web site (search for “LPMC”):
http://docs.hp.com
Failed Monarch Processors (HP-UX)
Monarch processors that are failing with an LPMC are not instantly replaced. When a monarch
processor experiences an LPMC, the LPMC monitor marks the processor for deconfiguration;
however, the LPMC monitor cannot deactivate the processor until the system is rebooted.
Deactivation of a monarch processor is not possible because it is the controlling processor of the
operating system (CPU 0). Therefore, the system cannot replace a (failing) monarch processor.
If your system has only one active processor, that processor is considered a monarch processor
and it cannot be replaced on line. A reboot of the system is required to replace the failing monarch
processor.
If there are multiple active processors in your system, one of them is designated as the monarch
processor, and the other (nonmonarch) processors can be replaced on line. If the monarch
processor fails, it cannot be replaced without a reboot.
Replacement of Failed Cores on OpenVMS
If a core is experiencing correctable errors, shut it down and start up another Instant Capacity
core, thereby keeping the active-core count constant.
If a core experiences a fatal problem leading to a system crash, upon reboot you can start another
Instant Capacity core, thereby replacing the failed core and keeping the active-core count constant.
Failed OpenVMS Primary Processors
An OpenVMS primary processor that is failing cannot be instantly replaced.
If your system has only one active processor, it is considered a primary processor and it cannot
be replaced on line. A reboot of the system is required to replace the failing primary processor.
Replacement of Failed Cores 73
If there are multiple active processors in your system, one of them is designated as the primary
processor and the other (nonprimary) processors can be replaced on line. If the primary processor
fails, it cannot be replaced without a reboot.
74 Using Instant Capacity to Manage Processing Capacity
5 Temporary Instant Capacity
This chapter covers the following topics:
“Temporary Instant Capacity Overview” (page 76)
“Ordering Temporary Instant Capacity” (page 78)
“Using Temporary Instant Capacity” (page 79)
“Temporary Capacity and Virtual Partitions” (page 81)
“Tracking Usage of Temporary Instant Capacity” (page 83)
“Temporary Instant Capacity Warning Period” (page 85)
“Temporary Instant Capacity Expiration and Compliance Enforcement” (page 86)
“Temporary Instant Capacity Exceptions” (page 87)
75
Temporary Instant Capacity Overview
You can purchase an amount of temporary capacity (TiCAP) time for inactive cores without
usage rights in your Instant Capacity system. Temporary capacity can be purchased in units of
processing days. Temporary capacity allows one or more inactive cores to be activated for up to
the specified period of prepaid processing time, without requiring permanent usage rights for
the cores.
You can activate and deactivate inactive cores as necessary until the elapsed activation time
equals the duration of your prepaid temporary capacity. For example, with a prepaid duration
of 30 days of temporary capacity, you can activate one core for 30 days or four cores for 1 hour
a day for 180 days (or any combination that totals 43,200 minutes).
Temporary capacity activations are persistent. This means that activations using temporary
capacity survive in a partition that is rebooted. You must deactivate cores to stop consumption
of temporary capacity. The cores you deactivate need not be on the same partition as those you
activated to start consuming temporary capacity.
NOTE: Temporary capacity credits can be used on any partition in the complex for which they
were purchased. Temporary capacity credits are not transferable from one system to another
unless the systems are in the same Global Instant Capacity group. For details of temporary
capacity in a GiCAP group, see Chapter 7.
If temporary capacity is depleted and you continue to have more active cores than core usage
rights across the complex, on the next reboot of any partition in the complex the software
automatically deactivates one or more cores in order to bring the system into a state closer to
compliance. The Instant Capacity software deactivates as many cores as necessary to either stop
consumption of temporary capacity or to bring the partition to the minimum number of required
active cores (one per active cell board).
IMPORTANT: Temporary capacity can be used to activate Instant Capacity cores on a temporary
basis only. It cannot be used to activate Instant Capacity cell boards or Instant Capacity memory.
Figure 5-1 illustrates the process of purchasing and applying temporary capacity.
76 Temporary Instant Capacity
Figure 5-1 Using Temporary Instant Capacity: Temporary Activation of Cores Without Usage Rights
Order iCAP
System/
Components
Acquire TiCAP
Codeword
from Portal
Apply TiCAP
Codeword to
System
Order
TiCAP
HP (or rep)
Installs iCAP
System/
Components
Customer
Prior to Needing
Additional Core
Capacity
Activate
Core(s), with
-t option
Deactivate
Core(s)
Additional Core
Capacity Needed
Post TiCAP
Order in
iCAP DB
Send
Ack
Letter
HP
Ship iCAP
System/
Components Process
Order for
TiCAP
Temporary Instant Capacity Overview 77
Ordering Temporary Instant Capacity
To add temporary capacity credits to a system, order the desired quantity of the Temporary
Instant Capacity product for your type of server. The system serial number is required for orders
of Temporary Instant Capacity.
Instant Capacity cores that are added to an existing system can include some additional temporary
capacity called Instant Access Capacity (IAC). Over time, the IAC can be consumed and you
might want to also order additional temporary capacity in order to continue activating cores on
a temporary basis. Temporary capacity is purchased in units of processing days, each of which
can be used to activate a single core for 24 hours (either continuously or spread over several
days), or multiple cores for portions that add up to a single day. Then you must follow the
configuration procedures for each partition (see Acquiring and Configuring Temporary Instant
Capacity” (page 79)).
HP-UX Licensing and Support with Temporary Instant Capacity
When you purchase temporary capacity, the temporary HP-UX license-to-use is included when
Instant Capacity cores are activated using temporary capacity. You might also need software
licenses for nonproprietary software. Check with your application software vendor for licensing
requirements. Since licensing requirements can change without notice, check your contract to
understand the details of software licensing with temporary capacity.
OpenVMS Licensing and Support with Temporary Instant Capacity
When you purchase temporary capacity, the temporary OpenVMS license-to-use is included
when Instant Capacity cores are activated using temporary capacity. The OpenVMS License
Management Facility recognizes when Temporary Instant Capacity cores are activated, and they
treat the usage as compliant. For nonproprietary software that uses per-core licensing, check
with the vendor for licensing requirements.
78 Temporary Instant Capacity
Using Temporary Instant Capacity
Acquiring and Configuring Temporary Instant Capacity
To add temporary capacity to a system that contains Instant Capacity cores (cores without usage
rights), follow this procedure:
1. Order the desired amount of Temporary Instant Capacity for your type of server by
submitting a purchase order to HP. Be sure to specify the system serial number.
After you purchase an amount of temporary capacity, HP sends you a letter that tells you
how to acquire a temporary capacity codeword and apply it to the system.
2. Acquire the temporary capacity codeword from the Utility Pricing Solutions portal (http://
www.hp.com/go/icap/portal)
3. Apply the temporary capacity codeword using the icapmodify -C command, on any
partition of the server, as shown in Example 5-1.
Example 5-1 Applying a Temporary Capacity Codeword (HP-UX)
> /usr/sbin/icapmodify -C vnyqD.qjieC7e.LaLdQGH.4aCNYBp-BQk3w9n.jfDhpvz.LiEB58C.7Q3dca2
The following valid codeword has been applied to the complex:
Temporary Capacity Codeword
30 days 0 hours 0 minutes
Use icapstatus(1M) to see the results of the application of this codeword.
NOTE: Instant Capacity codewords are based on both the serial number of a system and
a unique sequencing value for that server. These codewords must be applied in the sequence
in which they are obtained for a particular server. They can be applied to any partition on
the server.
4. Optional: To view temporary capacity balances on the portal, configure your partition for
email connectivity to HP. For details, see “Configuring Email on Instant Capacity Systems”
(page 202).
Using Temporary Instant Capacity
Auditing of temporary capacity is done at the complex level on Instant Capacity systems that
support partitioning and that are not part of a GiCAP group. For information about GiCAP, see
“Global Instant Capacity and Temporary Capacity” (page 115).
In a system that contains Instant Capacity cores with the temporary capacity RTU codeword
applied, you can activate one or more cores in an nPartition and allow them to use temporary
capacity by entering the icapmodify -t -a<number_of_cores> command.
In Example 5-2, two cores are currently active in the partition. You want to activate a third core,
but there are no available usage rights for activation. Because temporary capacity is available on
the system, you can activate a third core with it.
Using Temporary Instant Capacity 79
Example 5-2 Activating an Instant Capacity Core with Temporary Capacity (HP-UX)
> /usr/sbin/icapmodify -t -a 1
3 cores are intended to be active and are currently active.
Number of cores using temporary capacity: 1
Projected temporary capacity exporation: 12/22/08 08:00:00
NOTE: Temporary capacity cannot be used to activate Instant Capacity cores in inactive Instant
Capacity cell boards. You must purchase additional usage rights for the cell board and perhaps
also for the memory of the cell board.
To decrease the use of temporary capacity or to stop using it entirely, deactivate the appropriate
number of cores. (Do not use the icapmodify -t command when deactivating cores.) Temporary
capacity is no longer used when the number of active cores is equal to or less than the number
of cores with usage rights, across the complex.
To deactivate one or more cores in an nPartition, use the icapmodify -d <number> command.
80 Temporary Instant Capacity
Temporary Capacity and Virtual Partitions
If temporary capacity is being consumed in any virtual partition environment (previously
authorized with icapmodify -a n -t), deactivating a core with the vparmodify -d
command temporarily reduces the consumption of temporary capacity, although there may be
a delay of up to 30 minutes for the consumption of temporary capacity to cease. A subsequent
core activation using the vparmodify -a command increases consumption of temporary
capacity, if the activation results in more active cores than available core usage rights.
Use the icapmodify -d command to immediately decrease or cease the use of temporary
capacity. It is not necessary to use the -t option with the -d option. Use the icapmodify -a -t
command to resume temporary capacity consumption.
The following is an example of the output from an icapstatus command on a partitionable
system containing vPars.
> /usr/sbin/icapstatus
Software version: B.11.31.09.00.00.71
System ID: zoo6
Serial number: USR4020003
Product number: A6093A
Unique ID: Z3e0ec8e078cd3c7b
System contact e-mail: mjones@corp.com
From e-mail: Set to the default ('adm')
Asset reporting: on
Temporary capacity warning period: 15 days
Exception status: No exception
Local Virtual Partition Status
------------------------------
Total number of assigned cores: 4
Number of active assigned cores: 4
Number of inactive assigned cores: 0
Additional cores that can be assigned with current usage rights: 2
Number of cores that could be assigned with additional usage rights: 1
Number of cores that can be assigned with temporary capacity: 0
Number of cores currently unavailable for assignment: 0
Local nPartition Status (09/17/08 12:34:56)
-------------------------------------------
Total number of configured cores: 8
Number of Intended Active cores: 3
Number of active cores: 5
Number of inactive cores: 3
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 0
Number of inactive cells: 0
Amount of memory without usage rights: 0.0 GB
Amount of inactive memory: 0.0 GB
Number of cores without usage rights: 4
Number of inactive cores: 6
Number of cores that must be deactivated (insufficient usage rights): 0
Temporary capacity available: 0 days, 0 hours, 0 minutes
Allocation of Instant Capacity Resources among the nPartitions
--------------------------------------------------------------
Intended Actual
nPar Total Active Active =======Inactive======= Runs
ID Cores Cores Cores Cores Memory Cells iCAP nPar Name
==== ===== ======== ====== ====================== ==== =====================
0 4 4 4 0 0.0 GB 0 Yes zoo0
1 4 4 4 0 0.0 GB 0 Yes zoo1
2 8 4 4 4 8.0 GB 1 Yes zoo2
3 4 0 4 0 0.0 GB 0 Yes zoo3a
4 0 4 4 0 0.0 GB 0 Yes zoo5
5 2 2 4 2 0.0 GB 0 Yes zoo7
6 3 3 4 1 0.0 GB 0 Yes zoo6 (local)
Temporary Capacity and Virtual Partitions 81
8 0 1 4 3 0.0 GB 0 Yes zoo8
9 0 4 4 0 0.0 GB 0 Yes zoo9
10 0 4 4 0 0.0 GB 0 Yes zoo10
11 0 4 4 0 0.0 GB 0 Yes zoo11
12 0 4 4 0 0.0 GB 0 Yes zoo12
13 0 4 4 0 0.0 GB 0 Yes zoo13
N/A 8 N/A N/A 8 4.0 GB 2 N/A Unassigned Cells
82 Temporary Instant Capacity
Tracking Usage of Temporary Instant Capacity
The icapstatus command provides the following information about the use of temporary
capacity on the system:
Amount of temporary capacity remaining (in days, hours, and minutes)
Number of cores using temporary capacity (number of active cores without usage rights)
Projected temporary capacity expiration date and time (based on the current temporary
capacity consumption rate)
You can find this information in the Instant Capacity Resource Summary section of the
icapstatus command output.
Example 5-3 shows the display of temporary capacity information from the Instant Capacity
Resource Summary section of the icapstatus command output:
Example 5-3 Temporary Capacity Information from icapstatus Command (HP-UX)
> /usr/sbin/icapstatus
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 0
Number of inactive cells: 0
Amount of memory without usage rights: 0.0 GB
Amount of inactive memory: 0.0 GB
Number of cores without usage rights: 4
Number of inactive cores: 3
Number of cores using temporary capacity: 1
Temporary capacity available: 10 days, 1 hours, 40 minutes
Projected temporary capacity expiration: 12/31/08 16:00:00
If the system is part of a GiCAP group, additional group temporary capacity might also be
available, and is visible only via the icapmanage command on the Group Manager system.
Temporary Capacity Expiration Reminder
The Instant Capacity software calculates when the temporary capacity balance will expire, based
on the current consumption rate. After the temporary capacity balance reaches a certain residual
number of days (see “Temporary Instant Capacity Warning Period” (page 85)), a reminder email
message is automatically sent to the system contact, if one is specified, and root. These messages
are sent on a daily basis until temporary capacity expires. Example 5-4 shows a temporary
capacity expiration reminder email message. Note that the output from icapstatus during
the warning period includes a warning about the expiration of temporary capacity.
Tracking Usage of Temporary Instant Capacity 83
Example 5-4 Temporary Capacity Expiration Reminder
To: root@par1.yourorg.com
Subject: Temporary Capacity Expiration Reminder
***************************************************************************
**** Failure to perform the following steps will result in the complex ****
**** attempting to deactivate cores on any booting partitions until ****
**** the complex is in compliance with the Instant Capacity contract. ****
***************************************************************************
This message is being sent to remind you that your Instant Capacity complex
(containing the partition krmt10b) has 3 cores currently consuming temporary
capacity (TiCAP) and that the temporary capacity balance at the current
consumption rate is projected to expire on or around:
12/31/08 16:00:00
You can view the current temporary capacity balance and consumption rate,
by using the icapstatus command.
To adjust the number of calendar days to receive the temporary capacity
warning before temporary capacity actually expires use: icapmodify -w
Before the temporary capacity balance runs out, you must perform one of the
following steps:
1. Purchase additional temporary capacity and apply the temporary
capacity codeword to the complex.
2. Deactivate cores until the number of inactive cores on
the complex matches the number of cores without usage rights,
reported by icapstatus.
3. Purchase additional core usage rights to match the number of cores
currently consuming temporary, and apply the Right to Use
codewords to the complex so that they can be permanently activated.
See the Instant Capacity user's guide at /usr/share/doc/icapUserGuide.pdf
for more information.
84 Temporary Instant Capacity
Temporary Instant Capacity Warning Period
By default, the Instant Capacity software sends the expiration reminder when the temporary
capacity balance is projected to expire within 15 days. You can adjust that warning period by
specifying a different value with the icapmodify command, using the -w option. For example,
the following command specifies a longer warning period, for more advance notice:
> icapmodify -w 20
The Temporary Capacity Warning Period has been successfully set to 20 days.
Temporary Instant Capacity Warning Period 85
Temporary Instant Capacity Expiration and Compliance Enforcement
IMPORTANT: If you leave cores without usage rights activated beyond the purchased temporary
capacity duration, the software automatically deactivates one or more cores on the next reboot
of any partition in the complex.
After the temporary capacity is depleted and you continue to have more active cores than usage
rights across the complex, a notice similar to the following appears at the bottom of the
icapstatus output:
WARNING: Temporary capacity has expired and this complex is out
of compliance with the Instant Capacity contract because there
are 2 more active cores than there are core usage rights.
Deactivation of cores may occur during partition reboot to
bring the complex into compliance. In order to avoid the
deactivation of cores upon reboot, you need to take corrective
action immediately. Either deactivate 2 core(s), apply
additional temporary capacity codewords, or purchase and apply
Right to Use codewords for 2 core(s).
As stated in the warning, if cores without usage rights continue to be used, then on the next
reboot of any partition in the complex, the software automatically deactivates one or more cores
in order to bring the system into a closer state of compliance. The Instant Capacity software
deactivates as many cores as is necessary to either stop consumption of temporary capacity or
to bring the partition to the minimum number of required active cores. You must purchase either
additional temporary capacity or the appropriate number of usage rights (RTU codewords) to
be in full compliance.
For examples of the error messages that are sent as a result of compliance enforcement, see
“Temporary Instant Capacity Exceptions” (page 87).
Auditing of temporary capacity is done at the complex (OpenVMS node) level on Instant Capacity
systems that support partitioning (and are not part of a GiCAP group). Although temporary
capacity might have been purchased for use by a specific partition, it is available to all partitions
in the complex or OpenVMS node (or to the entire GiCAP group, if applicable).
86 Temporary Instant Capacity
Temporary Instant Capacity Exceptions
Error for Activation with Insufficient Temporary Capacity
You cannot activate an Instant Capacity core with temporary capacity unless there is a sufficient
balance of temporary capacity available. For details on how to increase the temporary capacity
balance, see Acquiring and Configuring Temporary Instant Capacity” (page 79).
Example 5-5 shows an error message for attempting to activate an inactive core without usage
rights and without a sufficient balance of temporary capacity:
Example 5-5 Error Message for Activation with Insufficient Temporary Capacity (HP-UX)
> /usr/sbin/icapmodify -t -a 1
ERROR: Operation not approved because there is not enough temporary capacity
to satisfy the request. Activations require at least 30 minutes
worth of temporary capacity per core consuming temporary capacity.
Temporary Capacity Balance Needing Action
If the temporary capacity balance reaches 30 minutes or less, the icapstatus command output
displays “less than 30 minutes” in the Exception status field (at the beginning of the
icapstatus output). When this state occurs, you need to take corrective action immediately
by doing one of the following:
Deactivate Instant Capacity cores that are using temporary capacity.
Apply additional temporary capacity codewords.
Acquire additional core usage rights and apply the RTU codeword.
Temporary Capacity Negative Balance
A complex is out of compliance with the Instant Capacity contract if a negative balance of
temporary capacity occurs.
The Instant Capacity software sends an exception report (via email) if there is a negative balance
of temporary capacity. Exception information is also written to the syslog file. For details of
the exception report for a negative temporary capacity balance, see “Handling Compliance
Exceptions” (page 137).
If you continue to have more active cores than core usage rights across the complex, a negative
capacity balance results in a compliance enforcement action, as described in “Temporary Instant
Capacity Expiration and Compliance Enforcement” (page 86). If there is a negative temporary
capacity balance but the number of cores with usage rights is greater than or equal to the number
of active cores, then the complex remains in an exception state, but without (additional)
enforcement action.
Temporary Capacity Enforcement
When the temporary capacity balance is depleted and you continue to have more active cores
than core usage rights across the complex, an enforcement action occurs at partition reboot to
bring the system into a state closer to compliance (by deactivating one or more cores). Example 5-6
shows the message that is sent when enforcement results in a partially compliant state but
temporary capacity continues to be depleted. Example 5-7 shows the message that is sent when
the enforcement is able to deactivate enough cores so that temporary capacity is no longer used.
Temporary Instant Capacity Exceptions 87
Example 5-6 Error Message for Temporary Capacity Partial Enforcement
To: root@par1.yourorg.com
Subject: Instant Capacity enforcement notice
This message is being sent to inform you that, due to expiration of
temporary capacity, 1 additional core(s) were deactivated on your Instant
Capacity system (containing the partition par1) to bring the complex
into compliance.
Prior to deactivation, the number of active cores exceeded the number of
available core usage rights by 3. 3 core(s) without usage rights were found to
be active in the complex. This state was likely the result of having activated
Instant Capacity core(s) using temporary capacity (TiCAP), and then allowing
the TiCAP balance to expire prior to deactivation of the core(s).
As a result, the intended active value was reduced by 1 and 1 core(s)
were deactivated.
There are currently 3 active core(s) and 1 core usage rights. This complex
is not in compliance with the Instant Capacity contract. Other partitions
may also experience core deactivation upon reboot until compliance is restored.
To bring the system back into compliance now, perform one or more of the
following steps:
1. Purchase additional temporary capacity and apply the temporary
capacity codeword(s) to the complex.
2. Deactivate cores until no cores are consuming temporary
capacity.
3. Purchase additional usage rights to match the number of cores consuming
temporary capacity and apply the Right to Use codewords to the complex
so that they can be permanently activated.
To activate these 1 core(s) again, you can perform one of the
following actions:
1. Purchase additional temporary capacity and apply the TiCAP
codeword(s) to the complex, and use temporary capacity to
activate the core(s).
2. Deactivate cores in other partitions after the complex is in
compliance. This frees up core usage rights which can be used
to activate cores on this partition.
You can view the current temporary capacity compliance of your system by using
the icapstatus command.
See the Instant Capacity user's guide at /usr/share/doc/icapUserGuide.pdf
for more information.
88 Temporary Instant Capacity
Example 5-7 Error Message for Temporary Capacity Complete Enforcement
To: root@par1.yourorg.com
Subject: Instant Capacity enforcement notice
This message is being sent to inform you that, due to expiration of
temporary capacity, 1 core(s) were deactivated on your Instant Capacity
complex (containing the partition par1) to bring the complex into compliance
with the Instant Capacity contract.
Prior to deactivation, the number of active cores exceeded the number
of available usage rights by 1. 1 core(s) without usage rights were
found to be active in the complex. This state was likely the result of
having activated Instant Capacity core(s) using temporary capacity (TiCAP)
and then allowing the temporary capacity balance to expire prior to
deactivation of the core(s).
As a result, the intended active value was reduced by 1 and 1 core(s)
were deactivated. To activate these 1 core(s) again, you can perform
one of the following actions:
1. Purchase additional temporary capacity, apply the TiCAP codeword(s)
to the complex, and use temporary capacity to activate the core(s).
2. Deactivate cores in other partitions. This frees up core usage
rights which can be used to activate cores on this partition.
There are currently 3 active core(s) and 3 core usage rights. This complex
is now compliant with the Instant Capacity contract.
You can view the current temporary capacity compliance of your system by
using the icapstatus command.
See the Instant Capacity user's guide at /usr/share/doc/icapUserGuide.pdf
for more information.
Temporary Instant Capacity Exceptions 89
90
6 Instant Capacity Cell Board
This chapter covers the following topics:
“Instant Capacity Cell Board” (page 92)
“Ordering Instant Capacity Cell Board” (page 93)
“HP-UX and OpenVMS License and Support” (page 94)
Acquiring Usage Rights for Instant Capacity Cell Board” (page 95)
“Instant Capacity Cell Board and Considerations of Core Usage Rights” (page 96)
Activation of an Instant Capacity Cell Board” (page 97)
Accidental Activation of an Instant Capacity Cell Board” (page 98)
“Instant Capacity Cell Board Activation Exception Error” (page 99)
“Instant Capacity Cell Board and Temporary Instant Capacity” (page 100)
91
Instant Capacity Cell Board
Overview
Instant Capacity Cell Board offers a way to have additional (inactive) cell board capacity in your
system for growing business needs. When the need arises, you acquire the necessary usage rights
in order to activate and use the cell boards, which contain memory and processors or cores.
An Instant Capacity cell board is configured at HP manufacturing already assigned to an nPartition
(hard partition) with its use-on-next-boot flag set to n(no), so it does not participate in the
boot of the nPartition.
When you are ready to activate a cell board, you can increase the cell usage rights by either
purchasing the appropriate Right to Use (RTU) products, or by borrowing usage rights if you
are using Global Instant Capacity to share usage rights within a group of servers. To purchase
usage rights, submit a purchase order to HP for the appropriate RTU products to increase the
cell usage rights available on the complex, as well as sufficient usage rights for all of the memory
on the cell board and, depending on the available usage rights and existing complex configuration,
usage rights for one or more additional cores. Then, the cell board is available for activation and
participation in the boot of the nPartition. This is controlled by setting the use-on-next-boot
flag to y(yes) with the parmodify command and rebooting the nPartition.
NOTE: If usage rights for the cell board, its memory, and at least one core are insufficient, the
Instant Capacity software prevents the cell board from being configured to participate (become
active) in the boot of an nPartition.
Any cell board, whether or not usage rights are available for activation, can be assigned to an
nPartition with the use-on-next-boot flag set to n(no).
Because an active cell board must have a minimum of 1 active core, prior to activation of a cell
board one of the following must be true:
Usage rights for at least one additional core must be available in the complex. There must
be at least one active core per cell board. The Instant Capacity software redistributes active
cores across all cell boards in the partition.
Usage rights for at least one additional core must be purchased and the RTU codeword must
be applied to the complex.
If the complex is a member of a Global Instant Capacity (GiCAP) group, usage rights for at
least one additional core must be available from the group.
After a cell board is activated, all of the cores on the cell board can be activated, depending on
the availability of core usage rights. You might need to acquire additional core usage rights in
order to activate additional cores from the newly activated cell board.
For information about assigning and unassigning a cell board to an nPartition, see Assigning
a Cell to a Partition” (page 67) and “Unassigning a Cell from a Partition” (page 69).
Ask your HP sales representative about availability of the Instant Capacity Cell Board product.
92 Instant Capacity Cell Board
Ordering Instant Capacity Cell Board
To order the Instant Capacity Cell Board product, do the following:
Order the appropriate HP product number for the cell board for your specific class of HP
server.
Order the appropriate HP product number for the entire amount of Instant Capacity memory
on the cell board.
Order the appropriate HP product numbers and quantities of Instant Capacity processors
for the number of additional cores to activate on the cell board (for details about core usage
rightssee “Instant Capacity Cell Board and Considerations of Core Usage Rights” (page 96)).
NOTE: It is highly recommended that you have the same number of processors or cores and
amount of memory on all cell boards in a given hard partition (nPartition). For optimal
performance, each nPartition should have cell boards with identical numbers of processors or
cores and amounts of memory (otherwise, system performance can be unpredictable).
Rules for ordering memory help ensure that the Instant Capacity cell board matches the amount
of memory in the other cell boards in a given nPartition.
Ordering Instant Capacity Cell Board 93
HP-UX and OpenVMS License and Support
You do not initially pay for HP-UX and OpenVMS license and support fees on an Instant Capacity
cell board.
When you acquire the usage rights for a cell board by purchasing the cell board RTU product,
there is an additional cost for the incremental HP-UX or OpenVMS license and support for each
core that is activated. That is, the HP-UX or OpenVMS license and support costs are based on a
“per active core” basis and are not included as part of the cell board RTU.
If activation of an Instant Capacity cell board does not increase the number of active cores, then
you do not have to pay incremental HP-UX or OpenVMS license and support fees.
Your system must be properly licensed for the HP-UX or OpenVMS Operating Environment
(OE) when activating the Instant Capacity cell board. You might also need software licenses for
nonproprietary software. Consult your application software vendor about licensing requirements.
94 Instant Capacity Cell Board
Acquiring Usage Rights for Instant Capacity Cell Board
Before activation of an (inactive) Instant Capacity cell board, you must acquire (purchase, or
borrow from a GiCAP group) additional usage rights from HP. To purchase additional usage
rights:
Order the appropriate HP RTU product for the cell board for your specific class of HP server.
Order the appropriate HP RTU product for the entire amount of Instant Capacity memory
on the cell board.
Order the appropriate HP RTU products for the number of additional cores you want to
activate on the cell board. This number depends on several factors (and in some cases might
not be required); examine this need before ordering any cell board usage rights. For more
details about how to determine this number, see “Instant Capacity Cell Board and
Considerations of Core Usage Rights” (page 96).
HP sends you a letter that tells you on how to acquire RTU codewords for the purchased
components. The letter also describes how to apply the codewords to the system to increase the
usage rights on the complex. The steps are as follows:
1. Acquire the appropriate RTU codeword (cell board, memory, core) from the Utility Pricing
Solutions portal (http://www.hp.com/go/icap/portal).
2. Apply the appropriate RTU codeword (cell board, memory, core) using the icapmodify -C
command.
NOTE: If multiple RTU products are purchased at one time, a single codeword can be generated
that incorporates multiple usage rights for the different components.
IMPORTANT: RTU codewords are based on both the serial number of a system and a unique
sequencing value for that server. These codewords must be applied in the sequence in which
they are obtained for a particular server. They can be applied to any partition on the server.
For an alternative to purchasing usage rights, see Chapter 7 for a discussion of GiCAP and how
you can borrow usage rights from other members of a GiCAP group.
Acquiring Usage Rights for Instant Capacity Cell Board 95
Instant Capacity Cell Board and Considerations of Core Usage Rights
At least one core usage right must be available for an Instant Capacity cell board you want to
activate. Each active cell board must have at least 1 active core. However, you do not necessarily
need to acquire additional core usage rights. No additional core usage rights are required unless
the requirement for a minimum of 1 core per active cell board cannot otherwise be met. If the
number of active cores in an nPartition equals (or exceeds) the number of cell usage rights, then
you do not need to purchase additional core usage rights.
NOTE: The following examples assume that the number of intended active cores for the
nPartition remains constant before and after cell board activation.
For example, consider an nPartition with 1 active cell board with all 4 cores active, and 1 inactive
cell board with 4 inactive cores. The number of intended active cores for the nPartition is 4. No
additional core usage rights are available. Activation of the inactive cell board on the complex
results in 2 active cores per cell board after reboot. That is, the Instant Capacity software distributes
the available core usage rights across the 2 active cell boards in the partition. The requirement
that at least 1 core is active on each cell board is satisfied, so purchase of additional core usage
rights is not necessary. You can choose to activate additional cores in the partition. If you do so,
you should purchase core usage rights at the same time as the cell usage rights. In this instance,
it is not required.
Table 6-1 Cell Board Activation Not Requiring Additional Core Usage Rights
NotesInactive Cell Board
Cores
Active Cell Board
Cores
State
No additional core usage rights are available on
the complex.
4 inactive4 activeBefore Cell Board
Activation
No additional core usage rights are required
because the number of core usage rights is greater
than the number of active cell boards.
2 active, 2 inactive2 active, 2 inactiveAfter Cell Board
Activation
In a different scenario, activation of an additional cell usage right can cause the number of core
usage rights to be below the minimum (1 active core per active cell board) and necessitate the
acquisition of additional core usage rights. For example, consider an nPartition with 1 active cell
board containing 1 active core and 3 inactive cores, and 1 inactive cell board with 4 inactive cores.
The number of intended active cores is 1 and there are no available core usage rights on the
complex. In this case, purchase of an additional cell usage right for the inactive cell board requires
purchase of an additional core usage right in order to meet the minimum requirement of 1 core
per active cell board.
Table 6-2 Cell Board Activation Requiring Additional Core Usage Rights
NotesInactive Cell Board
Cores
Active Cell Board
Cores
State
No core usage rights are available on the complex.4 inactive1 active, 3 inactiveBefore Cell Board
Activation
One additional core usage right is acquired
because the number of core usage rights is less
than the number of active cell boards.
1 active, 3 inactive1 active, 3 inactiveAfter Cell Board
Activation
96 Instant Capacity Cell Board
Activation of an Instant Capacity Cell Board
An Instant Capacity cell board is usually assigned to an nPartition; however, the cell board does
not participate in the boot of the nPartition. Activating an Instant Capacity cell board is a two-step
process:
1. Set the cell board’s use-on-next-boot flag to y(yes) using the parmodify command.
2. Reboot the nPartition (using the shutdown -r command on HP-UX), or (on HP-UX 11.31
OEUR 0709 or later) a Cell Online Activation.
For example, to change the use-on-next-boot flag to yon the Instant Capacity cell board in
cabinet 0, slot 5, in nPartition 3, execute the following command:
/usr/sbin/parmodify -p 3 -m 0/5::y:
If core usage rights are available in the complex, the number of intended active cores is increased
to as high a number as possible, limited by the number of cores in the newly activated cell board.
The available core usage rights are automatically used in the cell activation. If there are no
available core usage rights, the number of active cores remains the same.
After you have set the cell board’s use-on-next-boot flag to y, and have rebooted the
nPartition, you can use the icapmodify command to activate cores that are listed as Additional
cores that can be assigned with current usage rights (as reported by the
icapstatus command).
Activating an Instant Capacity cell board causes at least one core to become active on that cell
board after reboot.
For details about adding and configuring cells in nPartitions, see the nPartition Administrator's
Guide.
Activation of an Instant Capacity Cell Board 97
Accidental Activation of an Instant Capacity Cell Board
If you accidentally activate an Instant Capacity cell board, you can deactivate it by following this
two-step procedure:
1. Set the cell board’s use-on-next-boot flag to n(no) by using the parmodify command.
2. Reboot the nPartition, or (on HP-UX 11.31 OEUR 0709 or later) a Cell Online Deactivation.
This step is not necessary if there was no reboot after the activation.
For example, to change the use-on-next-boot flag to non the Instant Capacity cell board in
cabinet 0, slot 5, in nPartition 3, execute the following command:
/usr/sbin/parmodify -p 3 -m 0/5::n:
In this command, the nflag sets the cell board’s use-on-next-boot flag to “no” and causes
the cell board to not participate in the nPartition when it is booted.
For details about adding and configuring cells in nPartitions, see the nPartition Administrator's
Guide.
98 Instant Capacity Cell Board
Instant Capacity Cell Board Activation Exception Error
When you attempt to activate an Instant Capacity cell board in an nPartition, depending on the
number of core usage rights that are currently available in the complex, there is a chance the
number of intended active cores for the nPartition is out of compliance and the activation fails.
Figure 6-1,Figure 6-2, and Figure 6-3 illustrate this.
Figure 6-1 nPartition premodification state: One cell assigned with 1 active core and 3 inactive
cores; the complex has no additional core usage rights
AActive Core
Inactive (iCAP) Core
Cell 1
A
Available Core
Usage Rights
None
III
I
Figure 6-2 nPartition premodification state: Instant Capacity cell (Cell 2) with 4 inactive cores
Cell 2
IIII
Figure 6-3 nPartition requested state: Instant Capacity Cell (Cell 2) cannot be activated in nPartition
Cell 1
AI
Cell 2
IIII II
In this case, the parmodify command fails. This is because the nPartition would have 2 active
cell boards, and therefore must have at least 2 active cores. With only one core usage right, the
nPartition is out of compliance.
To activate the Instant Capacity cell board and be in compliance, you must first purchase an RTU
for an additional core usage right, or deactivate a core in another partition, if possible.
Instant Capacity Cell Board Activation Exception Error 99
Instant Capacity Cell Board and Temporary Instant Capacity
You can activate cores only on activated cell boards for which cell board usage rights have been
acquired. This is true for both permanent activation of a core and temporary activation of a core
using temporary capacity.
To acquire usage rights for an Instant Capacity cell board, you must acquire usage rights for the
cell board and the entire amount of memory it contains. For details, see Acquiring Usage Rights
for Instant Capacity Cell Board” (page 95).
100 Instant Capacity Cell Board
7 Global Instant Capacity
This chapter covers the following topics:
“Global Instant Capacity Overview” (page 102)
“Global Instant Capacity Requirements” (page 104)
“Global Instant Capacity Group Managers” (page 105)
“Global Instant Capacity Grouping Rules” (page 107)
“Global Instant Capacity Sharing Rights” (page 108)
“Creating Global Instant Capacity Groups” (page 109)
“Global Instant Capacity Resource Sharing” (page 112)
“Global Instant Capacity and Temporary Capacity” (page 115)
“Removing a Global Instant Capacity Group Member” (page 117)
“Reinstalling a Group Member” (page 118)
“Group Manager Availability (No Standby Manager)” (page 119)
“Group Manager Failover Considerations” (page 120)
“Upgrades and Global Instant Capacity” (page 121)
“Rights Seizure” (page 122)
“Considerations for Multiple Groups” (page 127)
Additional Considerations” (page 128)
101
Global Instant Capacity Overview
Global Instant Capacity, or GiCAP, provides you with the flexibility to move usage rights for
Instant Capacity components within a group of servers. It also provides “pooled” temporary
capacity across the group. This has several potential benefits: cost-effective high availability,
more adaptable load balancing, and more efficient and easier use of temporary capacity. A GiCAP
Group is managed using the icapmanage command.
Global Instant Capacity provides several benefits:
Cost-effective high availability. In case of planned or unplanned down time, you can
transfer usage rights from a failed partition or a failed member complex to one or more other
servers in the group that are providing backup availability. Without GiCAP, the only way
to provide this failover scenario is to provision each server with an adequate amount of
temporary capacity.
Load balancing. To provide adaptability and to accommodate changing demands, usage
rights can be transferred between servers in a group. For example, a server with extra,
unused capacity can release usage rights to activate additional components on an overloaded
server that needs extra capacity.
Pooled temporary capacity. Temporary capacity usage rights can be shared across servers
for better efficiency and ease of use. By pooling temporary capacity, there is less need to
provision temporary capacity for each server.
Global Instant Capacity is part of Instant Capacity version 8.x and later on HP-UX systems, and
is enabled by purchasing a special GiCAP sharing rights codeword. After purchase, the codeword
can be retrieved from the HP Utility Pricing Solutions web portal:
http://www.hp.com/go/icap/portal
When you retrieve the codeword, you must provide the sales order number for the codeword
purchase, the serial number of the Group Manager system, and partition information for the
Group Manager. Applying this codeword on a system running Instant Capacity enables the
creation of a GiCAP group with members.
Figure 7-1illustrates the process of configuring and using Global Instant Capacity.
102 Global Instant Capacity
Figure 7-1 Using Global Instant Capacity
Create
GiCAP Group
Add Member
Systems to
Group
Apply
Codeword
on Group
Manager
Apply
Grouping Rules
on Group
Manager
Select
Group Manager
System
Acquire
Grouping Rules
from Portal
Deactivate
Components
on System B
Activate
Components
on System A
Customer
Additional Capacity
Needed on System A
Excess Capacity
on System B
Purchase
GiCAP
Sharing Rights
Codeword
Post GiCAP
Order in
iCAP Database
Send
Acknowledgement
Letter
HP
Process
Order for
Codeword
Global Instant Capacity Overview 103
Global Instant Capacity Requirements
To use Global Instant Capacity, the Group Manager and all partitions on all servers in the group
must be running Instant Capacity version 9.0 or later. Every GiCAP group member must be
hardware-compatible with other GiCAP group members as determined by the GiCAP grouping
rules.
WBEM version A.02.05 or higher must be installed on the Group Manager and on all member
systems in order to use GiCAP. The CIM Server configuration property
sslClientVerificationMode must be set to a value of “optional” on all GiCAP Group
Managers and on all OS instances of all member systems. (The CIM Server may need to be
restarted if the property was not previously set to this value.) For details, see cimconfig(1M). Note
that communication between the managers and members of groups is established using SSL
certificates that are supplied by the GiCAP software.
To create a GiCAP group with members, you must purchase GiCAP sharing rights, acquire the
GiCAP codeword from the HP Utility Pricing Solutions portal, and apply the associated codeword
to the Group Manager system. GiCAP sharing rights are described in “Global Instant Capacity
Sharing Rights” (page 108).
For a complete list of all software requirements, see “Instant Capacity Requirements” (page 28).
104 Global Instant Capacity
Global Instant Capacity Group Managers
For each group, an HP-UX system must be designated as an active GiCAP Group Manager. This
system maintains information about the group, group resources, and grouping rules. Use the
icapmanage commands on a Group Manager system only.
The active Group Manager must be an HP-UX system running Instant Capacity software version
9.0 or later. The system running the Group Manager does not require any Instant Capacity
components, and it does not need to be a partitionable system. A Group Manager cannot be run
on a virtual machine (also known as a guest). The system must have a machine-readable serial
number, as displayed by the shell command getconf CS_MACHINE_SERIAL.
The Group Manager can be run on either a partitionable or a nonpartitionable system. If run on
a partitionable system, changing the configuration of the partitions can result in the Group
Manager becoming inoperative. For optimal availability, run the Group Manager on a server or
partition that is not a member of any GiCAP group, although it does not need to be dedicated
to only the Group Manager software. A Group Manager can manage multiple groups, but it is
recommended that it manages a single group for recoverability and ease of use.
Standby Group Managers
The active GiCAP Group Manager can designate a standby Group Manager to be available for
use as an active Group Manager if the current Group Manager is unavailable. The requirements
and recommendations defined for the Group Manager also apply to the standby Group Manager;
it is a Group Manager with “standby” status. This standby Group Manager is set up using the
icapmanage -a -S command on the active Group Manager system.
When the icapmanage -a -S command is issued, it sets up a cron job on the active Group
Manager that periodically transfers a copy of the GiCAP database to the standby Group Manager.
Prior to activating the standby Group Manager as the active Group Manager, the GiCAP database
on the standby Group Manager should match the database on the active Group Manager.
Although this is done automatically on a periodic basis, under some circumstances (such as
intermittent problems with network communication between the active Group Manager and the
standby Group Manger) the database on the standby Group Manager may be out of date. In this
case, you might need to manually transfer a copy of the database from the active Group Manager
to the standby Group Manager. This is done using the icapmanage -t command on the active
Group Manager.
The standby Group Manager can take control of GiCAP group management from the active
Group Manager using the command icapmanage -Q on the standby Group Manager. This
allows GiCAP group operations to continue if the GiCAP Group Manager is unable to function.
The new active Group Manager attempts to contact all group members, informing them that this
system is the active Group Manager. It also attempts to contact the previous Group Manager to
make it the standby Group Manager. The current system becomes the active Group Manager
regardless of whether or not these attempted contacts succeed or fail.
When the standby Group Manager becomes the active Group Manager, the cron job set up an
the former active (and now standby) Group Manager is removed, and a new cron job is set up
on the currently active Group Manager to continue the periodic transfer of a copy of the GiCAP
database to the standby Group Manager.
The standby Group Manager is removed using the icapmanage -r -S command on the active
Group Manager system. The active Group Manager updates all member hosts about the removal,
discontinues all GiCAP database transfer operations, and directs the standby Group Manager
to remove its copy of the GiCAP database.
The use of the icapmanage command is limited on a standby Group Manager. Only the -Q and
-s options are allowed, all other options are restricted to use only on the active Group Manager.
Global Instant Capacity Group Managers 105
In some circumstances, the cron job set up by the icapmanage -a -S command may stop
running, perhaps due to another operation on the Group Manager system. The cron entry can
be restored by any of the following methods:
Manually edit the crontab file and re-enter the icapmanage -t instruction. This is the
preferred method.
Remove and re-add the standby Group Manager.
Run icapmanage -Q
on the active Group Manager. This is not recommended because it might have some
unexpected side effects.
106 Global Instant Capacity
Global Instant Capacity Grouping Rules
A GiCAP group consists of a list of server complexes that are allowed to share Instant Capacity
usage rights (for cores, cell boards, and memory) and temporary capacity. Other than performance
considerations, there are no particular constraints on the number of servers allowed in a group,
but there are grouping rules defined by HP to specify the types of servers allowed to group
together.
NOTE: The Instant Capacity installation does not include a default grouping rules file. Grouping
rules must be downloaded from the HP Utility Pricing Solutions portal:
http://www.hp.com/go/icap/portal
Grouping rules are defined according to server class. The price structure of usage rights is also
based on server class. Since GiCAP pools usage rights, these usage rights can be used on any
type of server, regardless of the server class for which they were originally purchased. Therefore,
grouping rules were created to define the classes of servers allowed to share usage rights.
Use the icapmanage -R command to view the hardware grouping information. When used in
combination with a list of host names, this command reports all hardware types with which the
hosts might be grouped. If the hosts are not compatible with each other, no hardware is reported.
Without a list of host names, this command reports all supported hardware and grouping rules.
Under some circumstances you might need to acquire newer grouping rules from the portal (for
example, when adding new hardware not previously covered by the grouping rules currently
in use). Install the encrypted rules file on the Group Manager system using the icapmanage -i
command. The icapmanage -R command shows the version number of the grouping rules
installed, and when you download a new grouping rules file use icapmanage -R -U to compare
the version and supported systems before deciding to install the new grouping rules.
The following command installs a grouping rules file, retrieved from the portal, on the Group
Manager system:
> icapmanage -i -U FSTL012234_gicap.encrypt
Global Instant Capacity Grouping Rules 107
Global Instant Capacity Sharing Rights
Although GiCAP is part of Instant Capacity and is installed at the same time as Instant Capacity,
it is not enabled during installation. To share resources across groups, you must purchase GiCAP
sharing rights, acquire the GiCAP codeword from the HP Utility Pricing Solutions portal (http://
www.hp.com/go/icap/portal), and apply the associated codeword to the Group Manager system.
Application of the sharing rights codeword to the Group Manager system enables the addition
of members with Instant Capacity components to groups.
You purchase at least as many GiCAP sharing rights as the total number of cores without usage
rights across all the potential group members. Members can be added to a GiCAP group as long
as there are sufficient sharing rights available, and as long as the grouping rules indicate hardware
compatibility.
Unlike other Instant Capacity codewords, GiCAP codewords must be generated for and applied
to a specific partition if the Group Manager is on a partitionable system. This means that to
retrieve the codeword, you must specify the purchase order number, the system serial number
and partition information, if any. Use the icapmanage -s command on the Group Manager
system to retrieve the serial number and nPar ID, or vPar code that is applicable.
GiCAP codewords have a sequence value and must be applied in the order in which they were
generated for the Group Manager system. However, GiCAP codewords are sequenced
independently from any other types of Instant Capacity codewords that might be generated for
the same system, and can therefore be applied independently from Instant Capacity codewords.
Example 7-1 shows how to apply a sharing rights codeword.
Example 7-1 Applying a Sharing Rights Codeword
> icapmanage -C R8J2DBW.5UTxyWQ.2MekJ43.G5cdTVP.1-m9kvweQ.AYqEXym.wj3dyLj.Fbtg7s1
The following valid codeword has been applied to the complex:
Global Instant Capacity Sharing Rights Codeword
32 Sharing Rights
Use icapmanage(1M) to see the results of the application of this codeword.
108 Global Instant Capacity
Creating Global Instant Capacity Groups
After the sharing rights codeword and the grouping rules have been applied to the Group
Manager, a GiCAP group can be created by issuing the icapmanage command using the -a,
-g, and -m options. Use the -a option to add members, the -g option to select the group name,
and the -m option to specify a name for the new member along with a list of hosts running on
the system. The list of hosts must include at least one host per nPartition or virtual partition on
the system.
Note that a single partition of a complex cannot join a GiCAP group; rather you must specify all
partitions of a complex when adding a group member. All partitions on a group member must
be running HP-UX. An Instant Capacity server can join a group if the Group Manager has at
least as many GiCAP sharing rights as the total number of cores without usage rights on that
server. Members can be added to a GiCAP group as long as there are sufficient GiCAP sharing
rights available and it is permitted by the grouping rules. Each member that joins the group
decreases the available GiCAP sharing rights by the number of cores without usage rights
contributed by that member complex.
Although the size of GiCAP groups is not specifically restricted, performance of group-related
functions is affected by the number of group members and the number of partitions for each
member server, as well as by the types of hardware involved. A larger number of group members
can cause an increase in startup time for the Group Manager and can also affect the performance
of icapmodify commands when a transfer of usage rights occurs. If temporary capacity is being
used, then the size of the group may also increase the amount of communication time needed
for tracking of temporary capacity.
When adding groups to a Group Manager system, you can use the icapmanage -T command
to test hardware compatibility for one or more host systems in order to determine which groups
the systems can join. When used in combination with the -g option to specify a group name,
this command tests whether the specified host systems have hardware that is compatible with
the group. Without the -g option, this command reports which groups of all the groups managed
by this Group Manager have hardware which is compatible with the host systems. The host
names do not have to be from the same complex, but in order to best predict the possibility of
being able to join a group, the list of hosts should include all the nPartitions for a particular
complex. If the hosts are not compatible with each other, no groups are reported as having
compatible hardware.
You can create multiple GiCAP groups that can be managed by the same Group Manager or by
different Group Manager systems. Systems with no any Instant Capacity components can be
part of a GiCAP group. Deactivating resources on these systems allows them to loan usage rights
to other members in the group.
Example 7-2 shows how to create a group and show group status.
Example 7-2 Creating a Group
> icapmanage -a -g one
Group one added.
> icapmanage -s
Software version: B.09.00
32 GiCAP Sharing Rights: 0 in use, 32 available
Group ID: one
Group Members:
No members found
Example 7-3 updates the grouping rules for all groups managed by the Group Manager, tests
whether a server complex has hardware compatible with group “one”, and adds a member called
Creating Global Instant Capacity Groups 109
“IT” to that group. When you first add new members to a group, you are prompted for the root
password for each specified host. The password is used only to establish secure communication
and is not saved or stored.
Example 7-3 Adding a Member to a Group
> icapmanage -i -U /tmp/GiCAP.rules
> icapmanage -T node.corp.com -g one
root@mypar.node.corp.coms password:
The server(s) are compatible with GiCAP group one
> icapmanage -a -m IT:node.corp.com -g one
Member IT added to group one.
Example 7-4 shows the output of the icapstatus command for a group member system.
110 Global Instant Capacity
Example 7-4 Example Output of icapstatus for a Group Member System
> /usr/sbin/icapstatus
Software version: B.11.31.09.00.00.71
System ID: node
Serial number: USR4020003
Product number: A6093A
Unique ID: Z3e0ec8e078cd3c7b
System contact e-mail: mjones@corp.com
From e-mail: Set to the default ('adm')
Asset reporting: on
Temporary capacity warning period: 15 days
Exception status: No exception
Member zoo6 in GiCAP group MyGroup
----------------------------------
Active Group Manager: node1.corp.com
Standby Group Manager: node2.corp.com
Borrowed core usage rights: 0
Borrowed cell usage rights: 0
Borrowed memory usage rights: 0.0 GB
Local nPartition Status (09/17/08 12:34:56)
-------------------------------------------
Total number of configured cores: 8
Number of Intended Active cores: 2
Number of active cores: 2
Number of inactive cores: 6
Additional cores that can be activated with current usage rights: 0
Number of cores that could be activated with additional usage rights: 6
Number of cores that can be activated with temporary capacity: 6
Number of cores currently unavailable for assignment: 0
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 0
Number of inactive cells: 0
Amount of memory without usage rights: 0.0 GB
Amount of inactive memory: 0.0 GB
Number of cores without usage rights: 6
Number of inactive cores: 6
Number of cores using temporary capacity: 0
Temporary capacity available: 60 days, 0 hours, 0 minutes
Projected temporary capacity expiration: N/A
Allocation of Instant Capacity Resources among the nPartitions
--------------------------------------------------------------
Intended Actual
nPar Total Active Active =======Inactive======= Runs
ID Cores Cores Cores Cores Memory Cells iCAP nPar Name
==== ===== ======== ====== ====================== ==== ==================
0 8 # 2 2 6 0.0 GB 0 Yes zoo0 (local)
1 8 8 8 0 0.0 GB 0 Yes zoo1
N/A 0 N/A N/A N/A 0.0 GB 0 N/A Unassigned Cells
# Value for Intended Active not specifically set and defaults to the
number of configured cores in active cells.
Creating Global Instant Capacity Groups 111
Global Instant Capacity Resource Sharing
Once a group is established, Instant Capacity resources (core, cell board, memory usage rights,
and temporary capacity) can be shared among all the members of the group. Resource sharing
can occur in several ways:
During creation of the group, some members might have unused usage rights, so that by
simply joining the group, additional usage rights are available for use by any member of
the group.
Even if there are no unused usage rights across the group, a member of the group can
deactivate resources (cores, cells, or memory) to make additional usage rights available for
activation by any other member in the group.
Temporary capacity from all members of the group is available for use by any member of
the group.
Rights seizure allows the sharing of usage rights from failed partitions or failed servers.
Usage rights are shared by deactivating resources on one group member and then activating the
resources on another member of the group. The system on which the resources are deactivated
is lending usage rights to the activating (or borrowing) system. Activations and deactivations
are performed on the individual member systems using the usual icapmodify commands (for
cores) or parmodify commands (for cells) to effect this “loan” operation (also sometimes referred
to as a transfer of usage rights).
Any temporary capacity available to individual members of the group is combined into a larger
pool of temporary capacity that is available for consumption by any and all members of the
group, as needed. Initiating usage of shared temporary capacity is the same as with individually
purchased TiCAP: group members use the icapmodify -a -t command to activate shared
temporary capacity. This differs from the sharing of usage rights in that temporary capacity is
never a “loan” to be returned; it is always depleted through usage over time.
Example: Core Rights Sharing
In this scenario, core usage rights are not immediately available to any member of the group
mygroup. Group member member1 has an immediate need for more processing power. However,
group member member2 can loan a core usage right by deactivating one core.
First, member2, currently with 8 active cores, deactivates one core:
member2> icapmodify -d 1
7 cores are intended to be active and are currently active.
The core usage right from member2 is now available to any member of the group and can be
used to activate an additional core on member1:
member1> icapmodify -a 1
8 cores are intended to be active and are currently active.
The output of the icapstatus command on loaning system member2 shows that the Number
of Intended Active Cores and Number of active cores have decreased by 1, and
the Number of inactive cores and Number of cores without usage rights have
increased by 1. On borrowing system member1, the Number of Intended Active Cores
and Number of active cores have increased by 1, and the Number of inactive cores
and Number of cores without usage rights have decreased by 1.
The output of icapmanage -s on the Group Manager system shows that the total number of
cores without usage rights for the group has not changed.
Effect of Temporary Capacity
On systems where usage rights and temporary capacity are available, Instant Capacity uses usage
rights before it uses temporary capacity. If temporary capacity is being used on at least one
member system, a component on another member is deactivated, and a component on a third
112 Global Instant Capacity
member system needs to be activated, the usage rights made available by the deactivated
component can be taken by the system using temporary capacity. In this case you might need
to use the -t option to the icapmodify command to activate the component on the third member
system by using temporary capacity.
Whenever you have more active cores than the number of core usage rights, the temporary
capacity balance is depleted as a mechanism for tracking noncompliance of the group, even if
TiCAP has not been purchased for or applied to any member of the group. This differs from the
behavior of TiCAP on a complex which is not a member of a group, where TiCAP is decremented
only if TiCAP had been specifically purchased for the complex. Within a GiCAP group, temporary
capacity is used as an additional compliance mechanism to support the high availability features
of a group.
Because group members are automatically considered to be users of temporary capacity, to avoid
unexpected TiCAP depletion in a group, it is important to avoid the situations that cause the
Instant Capacity software to make assumptions that all cores might be active on a remote
nPartition.
If a member is removed from the group, the TiCAP balance on that complex will continue to be
used as a compliance mechanism (decremented whenever the number of active cores exceeds
the number of core usage rights), unless the TiCAP balance on the system is exactly 0.
Status Reporting
Usage rights and temporary capacity can sometimes be temporarily assigned to the Group
Manager, which can result in difficulty interpreting some of the data from the icapstatus
command. The total temporary capacity reported for the group by icapmanage -s might not
equal the sum of temporary capacity reported by each member system. This is because the Group
Manager prefetches an amount of temporary capacity in anticipation of needing it for a future
operation, so the temporary capacity might not be immediately assigned to a member system.
Also, individual counts of cores, cells, and memory without usage rights for each member of the
group might not add up to the total counts of cores, cells, and memory without usage rights for
the group. In all cases, totals reported (by icapmanage -s) for group temporary capacity and
usage rights are the important values that represent available resources for the group. Use the
verbose (-v) option to the icapmanage -s command to see resources held by the Group
Manager.
The icapstatus command reports usage rights borrowed or loaned by the system from or to
other members of the group. Borrowed rights are those that are currently resident on the member
and that originated elsewhere. Loaned rights originate on the system but are currently resident
somewhere else in the group. They might be either in use or unassigned on another group
member, or they might be unassigned on the Group Manager itself. The icapmanage -s
command displays the status of the entire group, while the icapstatus command displays an
isolated view of a single member.
Unassigned usage rights are free to be moved to other member systems, even if a particular
activation request fails. For example, consider a group where there are no free usage rights. If
member m1 releases 2 core usage rights by deactivating 2 cores, and member m2 tries to activate
3 cores, the activation request fails (not enough usage rights), after the Group Manager has
already migrated 2 core usage rights from m1 to m2. The borrow and loan values for m1 and m2
show that the loan has occurred, even though the activation on m2 failed to activate any cores.
A subsequent activation of 2 cores on m2 will be successful and will occur more quickly because
the 2 core usage rights are already assigned to m2, or because the rights are moved elsewhere in
the group if requested.
Global Instant Capacity Resource Sharing 113
Example: Cell/Memory Sharing
In this scenario, member1 of the group mygroup has an inactive cell it wants to activate, but no
usage rights are available on the system. However, member2 of the group has available usage
rights.
First, the output from the icapstatus command on member1 shows that no cell or memory
usage rights are available:
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 1
Number of inactive cells: 1
Amount of memory without usage rights: 16.0 GB
Amount of inactive memory: 16.0 GB
Number of cores without usage rights: 8
Number of inactive cores: 8
The output of the icapstatus command on member2 shows that memory and cell usage rights
are available, along with 1 core usage right:
Instant Capacity Resource Summary
---------------------------------
Number of cells without usage rights: 1
Number of inactive cells: 2
Amount of memory without usage rights: 16.0 GB
Amount of inactive memory: 32.0 GB
Number of cores without usage rights: 7
Number of inactive cores: 8
In this situation, it is not necessary to deactivate components on member2 because the system
is underutilized and usage rights are available. The usage rights from member2 are available to
member1, and the cell can be activated:
member1> parmodify -p 0 -m 2::y:
After a reboot or (on HP-UX 11.31 OEUR 0709 or later) a Cell Online Activation, all of the cell
and memory components on member1 are active.
114 Global Instant Capacity
Global Instant Capacity and Temporary Capacity
Temporary capacity can be shared across servers for better efficiency and ease of use. Temporary
capacity within a GiCAP group is always available to all members of a group without the need
to purchase temporary capacity for each server. You can exercise some control over how “willing”
each GiCAP member system is to share temporary capacity by setting its “temporary capacity
warning period”. No member's temporary capacity balance is decreased below the member's
warning period until all members of the group are within their warning period.
Example: Activation Using Pooled Temporary Capacity
In this scenario, member1 of mygroup has 2 active cores and needs to activate 6 more cores, but
only 5 usage rights are available in the group. There is no temporary capacity available on
member1. Other members of mygroup have a sufficient amount of temporary capacity, so you
can activate the cores using temporary capacity:
member1> icapmodify -a 6 -t
8 cores are intended to be active and are currently active.
Number of cores using temporary capacity: 1
Projected temporary capacity expiration: Less than 30 minutes
Notice that 5 additional cores are permanently activated with the available usage rights, and
only the last core is activated with TiCAP. Initially, only 30 minutes of temporary capacity are
transferred to member1, since 30 minutes of temporary capacity are transferred per core activated
with temporary capacity. Every 30 minutes the daemon determines whether temporary capacity
is depleted and acquires more from the group as needed.
Temporary Capacity and Freed Usage Rights
When a complex consumes temporary capacity, the Instant Capacity daemon periodically
decrements a complex’s temporary capacity balance. Before doing so it contacts the Group
Manager to determine whether there are core usage rights available on other group members.
If not, temporary capacity continues to be consumed. If usage rights are available anywhere in
the group, they are transferred to the complex using temporary capacity in order to stop temporary
capacity consumption on that complex.
Between the time the core usage rights are made available and the Instant Capacity daemon
monitors temporary capacity consumption, the icapstatus command reports that temporary
capacity is being consumed when it is not. When the transfer of usage rights is completed, the
icapstatus output is updated on both systems to reflect the transfer. Because of the delay, the
changes might appear to be unrelated to a user-initiated operation, but they are due to the
previously initiated deactivation that freed up core usage rights.
Temporary Capacity and Status Reporting
The temporary capacity balance reported by icapstatus on a group member reflects only the
temporary capacity that has been applied or transferred to that system via the Group Manager.
You might still receive temporary capacity expiration warning messages even though more
temporary capacity is available in the group.
Temporary capacity is transferred to group members in 30-minute blocks. When a block of
temporary capacity has been consumed, the Group Manager continues to transfer group temporary
capacity to the system every 30 minutes as long as it is available. However, the icapstatus
command on the local system might report temporary capacity as expired even though it is still
being used to activate cores, as shown in the icapstatus listing of “Number of cores using
temporary capacity”.
Global Instant Capacity and Temporary Capacity 115
Temporary Capacity Prefetch
Because temporary capacity is pooled for the group, adjustments to the temporary capacity
balance can be made even when it is not being consumed. For performance reasons, the Group
Manager anticipates potential future use of temporary capacity and might prefetch an amount
of temporary capacity from one or more member systems. Although temporary capacity will
not be used on a member system unless the -t option was specified with the icapmodify
command, an icapmodify command without the -t option might still result in an adjustment
of the temporary capacity balance for members of the group. When this happens, the overall
temporary capacity balance for the group does not change, but there might be differences in the
allocation to individual member systems.
116 Global Instant Capacity
Removing a Global Instant Capacity Group Member
Before removing a member from a GiCAP group, all the borrowed usage rights must be returned
and all outstanding loans reclaimed. Do this by deactivating resources on the member about to
be removed. Loaned usage rights are reclaimed by deactivating enough resources elsewhere in
the group to cover the loan. The reclamation of loaned usage rights on the member about to be
removed does not require the activation of resources on that member. As long as the usage rights
are not in use elsewhere in the group, removing the member results in the member reclaiming
its loans.
There is no constraint on temporary capacity because a removed member will take with it
whatever temporary capacity is assigned to it.
When a member is removed from a group, some number of sharing rights are released and made
available for future use. The number freed is equal to the number of cores without usage rights
on the removed member.
The following commands remove member IT from its group, and then remove group one:
> icapmanage -r -m IT
Member IT removed.
> icapmanage -r -g one
Group one removed.
A group cannot be removed until all members in that group have been removed.
Removing a Global Instant Capacity Group Member 117
Reinstalling a Group Member
If a group member is reignited, use the icapmanage command as follows to reestablish
communication between the newly ignited group member and the Group Manager:
icapmanage -a -m <member>:<host> -g <group_name>
See the HP Instant Capacity Release Notes for more details about reestablishing SSL certificates.
118 Global Instant Capacity
Group Manager Availability (No Standby Manager)
If the active Group Manager becomes unavailable and a standby Group Manager is not defined
or not used, management of the GiCAP group is unavailable until the Group Manager is restored
or replaced. The GiCAP group members continue to operate as isolated Instant Capacity systems,
using whatever usage rights and temporary capacity they had available when the Group Manager
became unavailable. A GiCAP group member using borrowed usage rights can continue using
those usage rights. A GiCAP group member that has loaned usage rights to other members in
the GiCAP group cannot recover those usage rights until the Group Manager is restored.
If a standby Group Manager is not used, loaned and borrowed usage rights remain in place in
GiCAP group members when the active Group Manager is unavailable. All usage rights held
by the Group Manager itself are left unavailable until the Group Manager is restored.
Normally, usage rights are not held by the Group Manager, but this can occur after a member
is removed from a GiCAP group, or if the Group Manager becomes unavailable during the
transfer of usage rights from one GiCAP group member to another.
Group Manager Availability (No Standby Manager) 119
Group Manager Failover Considerations
If the active Group Manager system becomes unavailable and a standby Group Manager has
previously been defined, the standby Group Manager can be used to take over GiCAP group
operations from the Group Manager. If both the active Group Manager and the standby Group
Manager are unavailable, or if the active Group Manager fails and the administrator chooses not
to have the standby Group Manager take over group operations, then the usage rights and
temporary capacity remain as per allocated to each group member, as described in the previous
section “Group Manager Availability (No Standby Manager)” (page 119).
However, if a standby Group Manager has been defined, an administrator can have a standby
Group Manager take control at any time using the icapmanage -Q command. While this can
be done routinely, for example to allow shutting down a functioning active Group Manager for
maintenance, normally this command is issued either when the active Group Manager has failed,
or when a network outage has made it unable to communicate with critical group members.
When a standby manager is told to take control, it attempts to update all members and the current
active Group Manager so that group operations can proceed smoothly.
However, in the case of a failure, it is possible that the icapmanage -Q command is unable to
contact the active Group Manager and some members of the groups that it now manages. When
this happens, the previously active Group Manager remains active, unaware of the change of
control. This is referred to as a “bifurcated” (or “split”) GiCAP group. Members that were
reachable by the standby Group Manager when it took control cannot accept commands from
the old active Group Manager; but unreachable members continue to consider it active. Control
operations can be carried out on both active Group Managers, each communicating with the
members that it (and only it) can reach. Groups and members can be added or removed on both
(subject to the set of members each can command), and sharing rights can be added on both. In
some cases this can be valuable; for example, when two data centers each remain functional but
some intervening network link has been broken. Each isolated set of systems can proceed with
independent disaster recovery operations within their group subset.
At some point, communication is restored and the split groups must be rejoined. This is
accomplished through issuing new icapmanage -Q command. It can be executed on either
active Group Manager to confirm that Group Manager as the active Group Manager and demote
the other to standby status. Be aware that doing this loses all database changes made on the
demoted Group Manager during the time that the group was split. There is no method to merge
the two databases, and in particular any new sharing rights applied to the Group Manager
designated now as standby are lost.
120 Global Instant Capacity
Upgrades and Global Instant Capacity
Be careful before upgrading or changing hardware or operating systems for any member of a
GiCAP group. If a member of a GiCAP group changes hardware in such a way that the hardware
is no longer compatible with the group, then the group is considered to be out of compliance
and group functions are restricted.
Also, the number of available sharing rights is adjusted whenever an Instant Capacity codeword
is applied to a GiCAP member system that modifies the number of cores without usage rights
on that member. (RTU and AddOn codewords for cores cause such adjustments.)
If more sharing rights are in use than were purchased for the Group Manager, all groups managed
by that Group Manager are out of compliance and all group functions are restricted until the
problem is resolved. The problem can be resolved by purchasing and applying additional sharing
rights to the Group Manager, purchasing and applying core usage rights to one or more group
members, or removing one or more group members from their group.
When such an incompatibility is detected, the GiCAP Group Manager sends email to the local
root account and to the registered contact email address for each member of the group.
Adding New Partitions
When reconfiguring a member system by adding or deleting an nPartition, use the icapmanage
-u command to add or remove host names to or from the member. For example, enter this
command to add a new nPartition with hostname hostC to member memberA:
icapmanage -u -m memberA -h hostC
To remove a host name, prefix the host name with “!”, as in !hostC. You can also add or remove
a list of hosts; separate the additions from the removals with a “!”, as in
hostA,hostB!hostC,hostD to add hostA and hostB while removing hostC and hostD.
If the Group Manager runs on a partitionable system, changing the configuration of the partitions
may render the Group Manager inoperative. This is because the Group Manager database is tied
to the serial number of the complex, the nPartition ID number, and a virtual partition ID number.
Although adding or modifying partitions does not change these IDs, they are changed if a partition
is deleted and then re-created on the Group Manager.
Upgrades and Global Instant Capacity 121
Rights Seizure
GiCAP disaster recovery was introduced in Instant Capacity version 8.02.01 and provides the
ability to “seize” core usage rights from a GiCAP member that is off line because of some disaster,
and transfer them to the Group Manager. Then, using normal activation commands, these usage
rights can be used to activate additional processor cores on other group members to increase
capacity. Rights seizure can be used to provide disaster recovery when all partitions of a GiCAP
member fail. It also enables the restoration of usage rights to the member once contact has been
restored.
When a failure occurs on a partition in an active group member, use the icapmanage -x
command to acquire core usage rights from the specified host to make them available to other
group members. This is known as rights seizure. The specified host must be known to the GiCAP
Group Manager (it appears in the output of the icapmanage -s command) and not currently
running. That and any other (vPar) hosts associated with the same hard partition are verified to
be unreachable by the GiCAP Group Manager. The icapmanage -x command verifies with
each known host on the hard partition. The hard partition containing the specified host is left
with one core usage right per active cell. Any core usage rights in excess of this are made available
for use elsewhere in the GiCAP group.
The seizure of core usage rights from a fully unavailable member is temporary. After 10 days,
the usage rights are automatically restored to the member from which they were seized. Seizure
of core usage rights from a member with at least one accessible partition (at the time of rights
seizure) do not expire. The icapmanage -z command allows you to restore previously seized
core usage rights to a specified host.
The following command seizes core usage rights from a partition that is unavailable, so that the
rights are available for other group member activations:
icapmanage -x mypar1.node.corp.com
When to Migrate Usage Rights and When to Seize Usage Rights
Here are some basic guidelines for determining when to seize usage rights or when to simply
migrate those rights:
Planned downtime and load balancing
Whenever possible, migrate usage rights by deactivating cores in one partition and then
activating cores in another partition. The involved partitions do not need to be part of the
same member server. For example, if maintenance is planned such that a partition is
unavailable for a period of time, deactivate cores in that partition before it becomes
unavailable. The usage rights from this partition are available to the entire GiCAP group
during this maintenance period.
Unplanned downtime
When an nPartition or server goes down unexpectedly, seize the usage rights from that
nPartition to make them available to the remaining GiCAP group members.
Effects of Rights Seizure
Rights seizure takes almost all the available usage rights from the hard partition containing the
specified host, leaving only enough usage rights to be able to boot (one core usage right for each
cell configured for use-on-next-boot (UONB)). The partition has the value intended active
set to the required minimum (one core per configured cell) and the value actual active set
to zero. The number of core usage rights seized is equal to the difference between the new value
for intended active and the greater of the old values for intended active and actual
active. These seized core usage rights are available for use elsewhere in the GiCAP group.
Although rights can be seized from any hard partition that is unavailable, the Instant Capacity
software makes some additional restrictions when all partitions of a complex are unavailable.
122 Global Instant Capacity
As a result, there are different behaviors and constraints depending on whether any partitions
can be contacted on the specified member complex.
If, at the time of rights seizure, at least one member partition can be contacted, then the software
is able to make an immediate adjustment to the available core usage rights, just as if a normal
migration operation using icapmodify -d had been performed before the specified hard
partition stopped running. This makes core usage rights available for potential loans to other
member systems. In this situation, the seized core usage rights do not have an expiration date.
However, because other member partitions are running Instant Capacity software, you can
assume that the unreachable partition is using all cores on cells configured for that partition.
Unless an explicit restore operation is performed, when the failed partition is rebooted it will
have only the minimum number of core usage rights left after the rights seizure. Because of this,
cells in partitions from which usage rights have been acquired should be rebooted or made
inactive within 12 hours. If this is not done, the partition may begin to consume temporary
capacity. If temporary capacity is not available, the complex may no longer be in compliance
with the Instant Capacity contract. Cells may be made inactive by removing them from the
partition, shutting down the partition from within the OS by using shutdown -R -H, or with
the MP RR command.
If, at the time of rights seizure, all member partitions are unreachable, the rights seizure is deferred
and must be viewed as a limited and immediate loan of usage rights from the specified partition
to the group. This loan of seized usage rights expires in 10 days. Upon expiration, usage rights
are automatically restored to the member partitions from which they were seized. The expiration
date for a rights seizure operation effectively terminates the period during which the core usage
rights are available to other group members for purposes of disaster recovery. If none of the
member partitions are reachable by the expiration date for a particular member, the usage rights
are automatically restored (reassigned) to the member partition (or complex, in the case of
unassigned seized rights) from which they were seized. However, note that if the seized usage
rights have been redeployed to other members and are not released at the expiration time, the
group may go out of compliance or temporary capacity may be used to maintain compliance.
If any partition of the inaccessible member from which rights seizures were deferred reconnects
to the group before the expiration date, the seized core usage rights (for all partitions) are finalized
as a loan from the member to the group, the expiration date is no longer relevant, and the usage
rights can thereafter be manipulated with normal icapmodify operations.
The icapmanage -x operation can be performed once for each hard partition on the member.
Down Partitions with Powered-On Cells
Partitions that are not running an Instant Capacity daemon are assumed to be running another
OS and using all cores on cells configured in the partition. The Instant Capacity software can
avoid this assumption when all cells configured in the partition are powered down. Unless an
explicit restore operation is performed, when the failed partition is rebooted it will have only
the minimum number of core usage rights left after the rights seizure. Because of this, cells in
partitions from which usage rights have been seized should be rebooted or made inactive within
12 hours. If this is not done, the partition may begin to consume temporary capacity. If temporary
capacity is not available, the complex may no longer be in compliance with the Instant Capacity
contract. Cells can be made inactive by removing them from the partition, shutting down the
partition from within the OS by using shutdown -R -H, or with the MP RR command.
Temporary Capacity and Rights Seizure
Instant Capacity is designed to stop using temporary capacity and instead take advantage of
usage rights if any become available. If temporary capacity is in use during a failover sequence,
the activation on the failover node might need to specify the use of temporary capacity. After
the rights have been seized and before the activation on the failover node, there is a window of
time when the iCAP daemons (on other partitions in the group) can wake up and start using the
Rights Seizure 123
seized usage rights in order to stop using temporary capacity. If this happens, the seized usage
rights are no longer available for the failover activation.
By specifying the use of temporary capacity on failover activation, you guarantee that the core
activations needed for failover will occur. The total temporary capacity consumption across the
group remains the same, even though the temporary capacity might be consumed on the failover
server instead of on the original server.
If, for some reason, it is important to keep the temporary capacity usage to a particular server,
you can manually deactivate the temporary capacity-consuming cores before doing the failover
activations, and then reactivate the temporary capacity usage after the failover activations. For
similar reasons, it might also be important to make sure other activations are not occurring
simultaneously during a failover sequence.
Other Considerations
Rights seizure can be used as part of an automatic failover system, but be sure that resources are
seized appropriately and in a manner that does not cause problems when the problem is corrected.
The Instant Capacity software determines that the partition is down based on whether the ping
command is unsuccessful for the partition. In some circumstances, ping might be unsuccessful
but the system remains functional (for example, if a network connection is interrupted). In this
case, rights seizure may be inappropriate and leave workloads without the necessary resources.
There are no restrictions regarding the type of environment from which rights were seized. Rights
that are seized from either an nPartition environment or a virtual partition environment can be
deployed on any member of the GiCAP group, regardless of the target environment type.
Additional HA Solutions
Although rights seizure is the main method used in a GiCAP high availability (HA) scenario,
there are additional methods and configurations allowing GiCAP to provide you with HA
solutions:
You can use GiCAP to move capacity from one or more nonproduction servers, such as test
servers, during a failover situation. You have a set of standby servers that are part of a group
and can pool their resources to provide failover capability.
You can combine GiCAP with temporary capacity. If you have a set of nonproduction servers,
and some of those servers contain temporary capacity, temporary capacity from the entire
group is made available during a failover situation. Temporary capacity is not seizable, so
any HA solution involving temporary capacity must ensure that it is available on the standby
server.
Systems with full usage rights can also be a part of a GiCAP group and can be used as donor
systems, contributing usage rights to the group and allowing additional activations on
member systems with Instant Capacity components.
Summary of Rights Seizure
The following summarizes usage rights seizure on GiCAP systems:
iCAP can seize usage rights from an unavailable server.
Usage rights can be seized from a group member even if the entire server is unavailable. In
this case, usage rights expire after 10 days and revert to the original partition.
Only core usage rights can be seized.
While GiCAP allows migration of all types usage rights between member servers (cores,
cells, and memory), seizure from a failed partition is only for core usage rights. If cell or
memory usage rights are needed, partitioning tools such as the parmodify command can
be used either remotely or on an accessible partition to remove one or more cells from the
unavailable partition, making usage rights available. Changing the use-on-next-boot (UONB)
124 Global Instant Capacity
flag to false for an inactive cell also releases the cell usage right and associated memory
usage rights.
Maximum core usage rights are seized.
There is no way to specify the number of core usage rights that are seized. Instant Capacity
seizes the maximum number possible, while ensuring that the nPartition can still be booted.
This seizure results in a partition with one core usage right for each active cell upon reboot
of the server.
Expiration of seized usage rights (complete server failure)
If at the time of an attempted rights seizure all member partitions are unreachable, the right
seizure is instead treated as a loan of usage rights from the specified member to the group.
The loan expires 10 days from the first use of the icapmanage -x command. If none of the
member partitions are reachable by the expiration date for a particular member, the usage
rights are automatically restored (or reassigned) to the member from which they were seized.
If, however, one of those member partitions reconnects to the group before the expiration,
the loan can be committed, with the usage rights actually transferred from the member.
If a system cannot reconnect to the Group Manager within the 10-day period, you can extend
the expiration of the seized usage rights. This extension is applied to the Group Manager
through the use of a codeword obtained from HP support.
Core usage rights are always seized from the nPartition, even when the specified host is a
virtual partition.
Usage rights can be seized from an nPartition only when:
The nPartition is down.
Assuming the nPartition is hosting virtual partitions, all the virtual partitions are down.
In either of these cases, rights seizure is the only technique available for migrating core usage
rights from the nPartition.
Because rights are seized at the nPartition level, when an entire server is unavailable, to
seize all rights from the server, the icapmanage -x command must be run on each
nPartition in the server.
An nPartition must be unavailable for usage rights to be seized.
Usage rights can be seized only if the partition is unavailable as determined by the ping
command.
Partial server failure
If, at the time of rights seizure at least one nPartition of the server is still running, Instant
Capacity can make an immediate adjustment to the available core usage rights, and the
seized core usage rights do not have an expiration date. However, because there are other
nPartitions running Instant Capacity software, the unreachable partition might be assumed
to be using all cores on cells configured for that partition, resulting in possible noncompliance
or temporary capacity usage. To avoid this, cells in partitions from which usage rights have
been seized should be made inactive within 12 hours.
When seizing usage rights from an nPartition that contains virtual partitions:
All the virtual partitions must be down before rights seizure is allowed.
Usage rights cannot restored to the virtual partitions before they boot. Otherwise, you
may not be able to reboot certain virtual partitions, depending on the vPars database
definition and the allocation of usage rights among the virtual partitions. Run the
restoration command icapmanage -z specifying any virtual partition of the nPartition
from which rights were seized. Failure to restore usage rights to the virtual partition
before connecting to the Group Manager can leave the virtual partition in a nonbootable
state, requiring additional steps to fix the vPars database before the virtual partitions
can be booted.
Rights Seizure 125
If there are multiple VM guests for the hard partition, they will be affected by the reduction
of usage rights. In an HP Integrity VM environment, specify rights seizure only for the VM
host, not the guests.
The Group Manager must have network connectivity.
If the Group Manager is also unavailable, and a standby Group Manager is not defined, it
is not possible to transfer usage rights to a standby server.
For additional information about rights seizure, see the Cost-effective high-availability solutions
with HP Instant Capacity on HP-UX white paper on the HP Documentation website:
http://docs.hp.com
126 Global Instant Capacity
Considerations for Multiple Groups
You can create multiple GiCAP groups, and they can be managed by the same Group Manager
or by different Group Manager systems. Note that if a Group Manager has an associated standby
Group Manager, the standby Group Manager functions as a standby for all the groups managed
by that Group Manager.
A server complex can be a member of only one GiCAP group at a time. To participate in a different
group, it must be removed from one group before being added to the other group.
Sharing rights can never be transferred between two active Group Manager systems. As you
create new groups or add new members to existing groups, you might need to purchase and
apply additional sharing rights to the relevant active Group Manager systems. This is necessary
even if the member has been moved from another Group Manager that now has excess sharing
rights.
Sharing rights can never be applied to a Group Manager with standby status. If a standby Group
Manager is requested to take control, the sharing rights of the former active Group Manager
move to it. If additional sharing rights need to be applied before failing back to the original Group
Manager, they must be purchased specifically for the new active Group Manager system (formerly
the standby Group Manager) and acquired from the portal. Once applied, the new total of sharing
rights moves to the originally active Group Manager if it is requested to retake control, although
only if the new active Group Manager is able to propagate its GiCAP database to the originally
active Group Manager.
Considerations for Multiple Groups 127
Additional Considerations
Systems that do not have any Instant Capacity components can be part of a GiCAP group.
Deactivating resources on these systems allows them to loan usage rights to other members in
the group.
Members of a GiCAP group do not have to be located near each other. IP connectivity between
the members, the Group Manager, and the standby Group Manager (if any), sufficient GiCAP
sharing rights, and adherence to the GiCAP grouping rules are the only constraints.
For systems with multiple network cards, you can specify the additional network paths as
additional hosts when defining member systems in a group, for enhanced connectivity. However,
there might be a significant performance penalty because the Instant Capacity software
occasionally must access all the multiple hosts in that case. You cannot specify the Group Manager
and the standby Group Manager such that they are different network paths to the same system.
An OS instance can host one and only one GiCAP database, regardless of the number of hostnames
by which that OS instance might be reachable.
WBEM version A.02.05 or higher must be installed on the Group Manager and on all member
systems in order to use Global Instant Capacity. The CIM Server configuration property
sslClientVerificationMode must be set to a value of “optional” on all GiCAP Group
Managers and on all OS instances of all member systems. (The CIM Server may need to be
restarted if the property was not previously set to this value.) For details, see cimconfig(1M). Note
that communication between the managers and members of groups is established using SSL
certificates that are supplied by the GiCAP software.
If the GiCAP Group Manager system becomes unavailable, the standby GiCAP Group Manager
can take over GiCAP group operations from the Group Manager. If both the Group Manager
and the standby Group Manager are unavailable, usage rights and temporary capacity remain
as allocated to each group member. Within a server complex, the usage rights can be deployed
to other partitions, but movement of usage rights between complexes cannot occur.
On a system with full usage rights, the icapd daemon does not constantly verify the system
configuration. It can take up to 12 hours for each partition of a system converted from non-iCAP
to iCAP to discover that it is now an iCAP system. During this time, icapmanage -s shows
asterisks for the new member, and the icapstatus command issued on that system shows
“Runs iCAP” as “N”. To force a faster conversion, kill the icapd daemon and wait for it to
restart.
128 Global Instant Capacity
8 Using Instant Capacity on HP Integrity Superdome 2
This chapter covers the following topics:
“Overview” (page 129)