icod man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

iCAP(5)								       iCAP(5)

       iCAP - Instant Capacity software for HP-UX

       The  HP	Instant	 Capacity  program  provides  services	for  instantly
       increasing or decreasing processing capacity on supported HP servers to
       meet  varying system demands.  An Instant Capacity server is an HP cel‐
       lular (partitionable) server that is governed by	 an  Instant  Capacity
       contract constraining the number of cores, cell boards, and memory that
       must remain inactive at all times.  The total number of	each  type  of
       component  that	can be active at any time is referred to as the number
       of usage rights for that component type.	 The Instant Capacity software
       provides	 the ability to dynamically assign usage rights where they are
       needed among the various partitions of a complex	 through  the  use  of
       commands	 like  icapmodify(1M)and  parmodify(1M),  and  it provides the
       means to load balance system processing capacity through these  manage‐
       ment  commands.	 When the processing demand significantly changes, you
       can purchase additional component usage rights to increase the  overall
       number of components that can be activated at any time.

       Instant	Capacity  is  a part of the HP Utility Pricing Solutions (UPS)
       program, and was formerly known	as  iCOD.   For	 detailed  information
       about  Instant  Capacity,  see  the located at /usr/share/doc/icapUser‐

   Initializing an Instant Capacity Server
       Instant Capacity software is installed by HP manufacturing on instantly
       ignited systems, and is a required component of all HP-UX systems.  You
       can   upgrade   to   later   versions   by    downloading    it	  from
       http://www.hp.com/go/softwaredepot  (search for product ID B9073BA), or
       by installing it from an OE or AE update.

       An Instant Capacity server needs no additional initialization, but some
       of the following configuration steps might be useful:

	      1.	Execute	 the  command to configure contact information
			(email address) for configuration change  notification
			and exception reports.

	      2.	If  using  temporary  capacity, execute the command to
			configure the temporary capacity warning period.

	      3.	If the server is a GiCAP Group Manager or a member  of
			a  GiCAP group, use the command (see cimconfig(1M)) to
			set   the   CIM	   Server    configuration    property
			sslClientVerificationMode  to  "optional" .  You might
			need to restart the CIM Server (see cimserver(1M))  if
			the property was not previously set to this value.

       Instant	Capacity uses codewords for several purposes: to adjust avail‐
       able usage rights for system components, to apply an amount of  "tempo‐
       rary capacity" to the system, and to apply "sharing rights" to a Global
       Instant Capacity (GiCAP) Group Manager to enable	 creation  of  one  or
       more groups of member servers that can share usage rights.

       All  types  of  codewords must be purchased as specific product numbers
       from HP.	 After purchase, the codeword (an encrypted  string)  must  be
       retrieved  from the Utility Pricing Solutions web portal and applied to
       the appropriate system.	Codewords are generated specifically  for  the
       system for which they were purchased.  You must always specify at least
       the system serial number and the purchase  order	 number	 in  order  to
       retrieve	 a  codeword  from  the	 portal.  Application and use of GiCAP
       codewords are different from other iCAP codewords and are described  in
       the section "GiCAP Sharing Rights" .

       Prior to activating an Instant Capacity component, a Right to Use (RTU)
       codeword must be applied to the complex to increase the	component-spe‐
       cific usage rights on the complex.  After a fee has been paid to HP for
       the type and number of components that are to be activated,  RTU	 code‐
       words  are made available through the HP Utility Pricing Solutions por‐
       tal (http://www.hp.com/go/icap/portal).

       Instant Capacity codewords (such as RTU codewords)  are	applied	 to  a
       complex	using the command on any partition of the complex.  iCAP code‐
       words are generated with a sequence number, and all iCAP codewords  for
       a  particular  complex  must be applied in the order in which they were

       After the appropriate codewords have been applied to a  complex,	 addi‐
       tional  components in the complex may be activated, up to the number of
       component usage rights granted by the applied codewords.	 Depending  on
       their  type,  components are activated using the command (if activating
       cores), or other commands including (see parmodify(1M)) and  (see  par‐

       In  addition  to	 RTU  codewords, cores can be activated with temporary
       capacity.  Temporary capacity codewords allow the  activation  of  more
       cores  than  allowed by the usage rights on the complex, but only for a
       limited time.

   Software Removal
       Instant Capacity software cannot be removed.  Other  software  products
       depend on it to approve configuration changes to the system.

   Status of Instant Capacity Components
       Information  about the Instant Capacity components on a complex and the
       available usage rights for each type of component can  be  obtained  by
       invoking the command.  This command also provides information about the
       amount of temporary capacity presently in use, the projected expiration
       of  the	temporary  capacity,  and counts of active and inactive compo‐

       One status field that is important to understand is the intended active
       (IA)  value  for	 each  nPartition.  Fundamentally, the intended active
       value is the number of cores intended to be active after a reboot.   As
       processing  needs change, the IA value is modified by commands like , ,
       and to represent the new distribution of active cores across the	 nPar‐
       titions	and thus, the new numbers to activate on reboot of the nParti‐

       Note that the status field intended active can differ from  the	status
       field actual active (AA) in some cases, including the following:

	      ·	 In   an  nPartition,  activations  or	deactivations  can  be
		 deferred, meaning that the change is pending until  the  next

	      ·	 If  there are deconfigured (failed) cores, it may be impossi‐
		 ble for the nPartition to reach the configured IA value.  The
		 IA  value  is	not affected by deconfigured cores, but the AA
		 value may be lower in this case.

	      ·	 In a virtual partition, core assignments can be increased  or
		 decreased  with  either  the command or the command, but only
		 changes the intended active for the  nPartition.   activation
		 commands  are	constrained  by the intended active value, but
		 deactivation commands are allowed to deactivate below IA,  so
		 that the number of cores actually assigned to all the virtual
		 partititons of the nPartition (represented by the  AA	status
		 field)	 may  be  less	than  the IA value for the nPartition.
		 This results in something called "unused capacity" ; but typ‐
		 ically	 happens only during the window of time that resources
		 are being shifted across the virtual partitions of an nParti‐
		 tion.	Overall, this mechanism allows for quicker shifting of
		 resources within virtual partitions.

       If the complex is a member of  a	 GiCAP	group,	the  command  provides
       information about group membership, including any borrow or loan status
       of usage rights.	  Detailed  information	 about	GiCAP  groups  can  be
       obtained by invoking the command on a Group Manager system.

   Virtual Partitions
       Instant	Capacity  has  a  minimum version dependency on vPars A.03.05.
       For versions of vPars before A.03.05, the  command  for	activating  or
       deactivating  cores  in a virtual partition fails with an error message
       indicating the vPars version dependency.

       Instant Capacity can be present on 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 command or the command, depending on the type of adjustment
       needed, the version of vPars being used, and the level  of  logging  or
       reporting desired.

       One  important consideration is that can be used to activate or deacti‐
       vate cores in other virtual  partitions	within	the  nPartition;  only
       activates  or  deactivates  cores  within the current virtual partition
       (the partition where the command is invoked).  Another consideration is
       that  core assignment via the command does not result in logging of the
       activation, email configuration change notification, or transmission of
       an asset report to HP.

       However,	 the  most important consideration is that the command must be
       used in a virtual partition environment when you are making any adjust‐
       ment  to	 an  nPartition.  If you are adjusting core assignments across
       virtual partitions in a single nPartition, use the command for the best
       coordination  between the Instant Capacity software and the vPars soft‐
       ware, and for optimized performance.  The command is  the  fastest  and
       most  efficient	way  to adjust capacity within virtual partitions of a
       single hard partition, 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.

       Note that with vPars A.03.05 or greater, a  compliance  check  is  per‐
       formed  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 Capac‐
       ity software notifies the vPar monitor, and the	monitor	 prevents  any
       virtual partition from booting until the user performs a hard partition
       boot and modifies either the vPar configuration or the Instant Capacity
       intended activecount for the nPartition.

       For more information about virtual partitions, see vparmodify(1M).

   HP Integrity Virtual Machines (Integrity VM)
       In  an  Integrity  VM  environment,  Instant Capacity software provides
       meaningful functionality only on the VM Host; it does not run on a vir‐
       tual  machine (also known as a "guest").	 In particular, Instant Capac‐
       ity commands will report an error if attempted from a guest.   A	 GiCAP
       Group Manager cannot be run on a guest, nor can a guest be specified in
       the host list for a GiCAP group member.

   Processor Sets
       In an environment where processor sets  are  being  used,  the  command
       activates  Instant  Capacity  cores  into the default processor set and
       deactivates cores from only the default processor set.	Activation  or
       deactivation of cores in nondefault processor sets is a two-step opera‐
       tion.  The first step involves the user migrating the cores into or out
       of  the	default	 processor  set;  the second step is the activation or
       deactivation of those cores using the command.

       For more information about processor sets, see psrset(1M).

   Temporary Capacity (TiCAP) Program
       Customers can purchase an amount of temporary capacity time.  This tem‐
       porary  capacity	 can  be used to activate one or more cores beyond the
       number for which usage rights have been purchased.  These  extra	 cores
       can  remain  active until they consume the available temporary capacity
       time.  This allows temporary activation of cores without requiring  the
       purchase and activation of an RTU codeword for permanent activation.

       Whenever	 an  Instant  Capacity	component without usage rights is pur‐
       chased, an amount of  Instant  Access  Capacity	(IAC)  might  also  be
       included.   Instant  Access  Capacity  is exactly the same as temporary
       capacity, except it is automatically provided with an Instant  Capacity
       component  and  is  not separately purchased.  It provides an immediate
       buffer of temporary capacity in case extra capacity  is	needed	before
       there  is time to purchase either an RTU codeword, a temporary capacity
       codeword, or to setup a Global Instant Capacity (GiCAP) group.

       Temporary capacity can be added to the complex by applying a  temporary
       capacity codeword (available from the HP Utility Pricing Solutions por‐
       tal) using the command.	Information  about  the	 amount	 of  temporary
       capacity	 time  remaining on a complex can be obtained by executing the
       command.	 A warning is also sent via email when the temporary  capacity
       balance is expected to be depleted within a certain period of time.

       The  command  allows activating a core using temporary capacity only if
       at least 30 minutes of temporary capacity is available  for  each  core
       being activated.

       Whenever	 temporary  capacity  has  been applied to a system (or if the
       complex is part of a GiCAP group), extra care must be  taken  to	 avoid
       situations  that	 cause the Instant Capacity software on one nPartition
       of a group member to make assumptions that all cores might be active on
       another	nPartition  of the member, for example, when the nPartition is
       making boot-related configuration changes (at EFI or BCH).  If left  in
       this state for more than 12 hours, unexpected temporary capacity may be
       consumed on the complex.

       Instant Capacity Cell Board offers a way to have additional  (inactive)
       cell  board  capacity  for  your	 system.   These Instant Capacity cell
       boards, which contain memory and cores, can be activated after  a  cell
       RTU  codeword  is obtained from the HP Utility Pricing Solutions portal
       and is applied to the complex using the command.	 To activate  a	 cell,
       you  must  have usage rights for all memory attached to the cell and at
       least one core.

       Global Instant Capacity (GiCAP) provides HP customers with  the	flexi‐
       bility  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.

       For  example, in case of planned or unplanned down time, a customer can
       transfer usage rights from a failed partition on one server to  one  or
       more other servers in the group that are providing backup availability,
       thus allowing additional activations of iCAP components on  the	backup
       servers.	 Without GiCAP, the only way to provide this failover scenario
       is to provision each server with an adequate amount of temporary capac‐

       A similar scenario exists for load balancing.  Rather than using tempo‐
       rary capacity whenever a server is overloaded (peak  profiles  for  all
       workloads  on  a	 server),  usage  rights can be transferred from other
       servers in the GiCAP group that have extra  capacity.   These  borrowed
       usage rights enable new component activations on the overloaded system.

       Pooled  temporary  capacity  for	 a  group of servers is more efficient
       because all temporary capacity is available to all servers in the GiCAP
       group.	It  is also easier to manage if temporary capacity needs to be
       applied to only one member of the group and monitored across the	 group
       instead of monitoring TiCAP for each member complex.

       Global  Instant	Capacity is built on the concept of a server group, or
       GiCAP group.  The 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.  There are no  constraints  on  the
       number  of servers allowed in a group, but grouping rules defined by HP
       specify the types of servers allowed to group together.

       For each group, an HP-UX system must be designated as an active	Global
       Instant	Capacity  Group	 Manager.   It	is  this system that maintains
       information about the group, group resources, and grouping rules.   The
       commands are intended to be used only on a Group Manager system to man‐
       age one or more GiCAP groups.

       The active Group Manager must be an HP-UX system	 running  the  Instant
       Capacity	 software  version 9.0 or later.  The system running the Group
       Manager does not need to have any Instant Capacity components, nor does
       it  need to be a partitionable system.  The system must have a machine-
       readable serial number, as displayed by the shell command .  It is rec‐
       ommended	 that the Group Manager not be on a partition that is a member
       of any GiCAP group, and that it manages a single group.	If  run	 on  a
       partitionable  system, changing the configuration of the partitions may
       result in the GiCAP Manager becoming inoperative.

       The active GiCAP Group Manager can designate a standby  Group  Manager.
       This  standby  Group Manager can take control of GiCAP group management
       from the active Group Manager using the command .   This	 allows	 GiCAP
       group  operations  to  continue if the GiCAP Group Manager is unable to

       Note that the requirements and recommendations defined  for  the	 Group
       Manager	also apply to the standby Group Manager; it is a Group Manager
       with "standby" status.  The Group Manager in charge of  the  group  has
       "active"	 status.   If  the  standby  Group  Manager takes control, the
       intention is that its status becomes "active" and the former Group Man‐
       ager's status becomes "standby".	 For more details, see the "Group Man‐
       ager Failover Considerations" section.

       Every operating system on a GiCAP group member must be running  Instant
       Capacity	 version 9.0 or later.	Every GiCAP group member must be hard‐
       ware-compatible with other GiCAP group members  as  determined  by  the
       GiCAP grouping rules.

       Once  you  have determined which system will host the active Group Man‐
       ager, you must acquire grouping rules from the portal and  install  the
       encrypted  file	on  the active Group Manager system using the command.
       Under some circumstances (for example, when  adding  new	 hardware  not
       covered	by  the	 grouping  rules  currently in use), you might need to
       acquire newer grouping rules from the portal.

       To create a GiCAP group with members, you must purchase	GiCAP  sharing
       rights,	acquire	 the  GiCAP codeword from the HP Utility Pricing Solu‐
       tions portal (http://www.hp.com/go/icap/portal), and apply the  associ‐
       ated  codeword  to  the	active	Group Manager system.  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 sufficient sharing rights are	avail‐
       able,  and  as long as the grouping rules indicate hardware compatibil‐

       Unlike other iCAP codewords, GiCAP codewords must be generated for, and
       applied	to,  a	specific partition if the active Group Manager is on a
       partitionable system.  This means that in order to retrieve  the	 code‐
       word,  you  must	 specify  the purchase order number, the system serial
       number and partition information, if  any.   Use	 the  command  on  the
       active  Group  Manager  system  to get the applicable serial number and
       nPar ID, or vPar code.

       GiCAP codewords also have a sequence value and must be applied  in  the
       order  in which they were generated for the Group Manager system.  How‐
       ever, GiCAP codewords are sequenced independently from any other	 types
       of  iCAP codewords that might be generated for the same system, and can
       therefore be applied independently from iCAP codewords.

       After the sharing rights codeword and  the  grouping  rules  have  been
       applied	to  the	 active Group Manager, a GiCAP group can be created by
       issuing the command using the , and  options.   Members	are  added  by
       issuing	the  command  using the option, the option to select the group
       name, and the 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;
       all  partitions	of  a  complex must be specified when creating a group
       member.	All partitions on a group member  must	be  running  HP-UX  or
       OpenVMS.	  Each	member	that  joins  the group decreases the available
       GiCAP sharing rights by the number of cores without usage  rights  con‐
       tributed by that member complex.

       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.

       Usage  rights are shared by deactivating resources on one group member,
       and then activating resources on	 another  member  of  the  group.   In
       effect,	the  system on which the resources were deactivated is loaning
       usage rights to the activating (or borrowing) system.   The  activation
       and  deactivation commands are done using the usual and commands on the
       individual member systems to effect this "loan" operation  (also	 some‐
       times 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.  Usage of
       shared temporary capacity is the same as	 with  individually  purchased
       TiCAP:  group  members  use  the	 command  to activate shared temporary
       capacity.  This differs from the sharing of usage rights in that tempo‐
       rary  capacity  is  never  a loan to be returned; it is always depleted
       through its usage over time.

       Before removing a member from a GiCAP group,  all  the  borrowed	 usage
       rights  must  be returned, and all outstanding loans must be reclaimed.
       Borrowed usage rights are returned by  deactivating  resources  on  the
       member about to be removed.  Loaned usage rights are reclaimed by deac‐
       tivating 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 such constraint with	 respect  to  temporary	 capacity.   A
       removed	member	will  take with it whatever temporary capacity is cur‐
       rently assigned to it.

       When a member is removed from a group, some number  of  sharing	rights
       are  released and become available for future use.  The number freed is
       equal to the number of cores without usage rights on the	 removed  mem‐

       Care must be exercised before upgrading or changing hardware or operat‐
       ing 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 as described in the sec‐
       tion "Group Compliance".

       Also, note that the number of  available	 sharing  rights  is  adjusted
       whenever	 an  iCAP  codeword  is applied to a GiCAP member system which
       modifies the number of cores without usage rights on that member.  (RTU
       and AddOn codewords for cores cause such adjustments.)

       If  available  sharing  rights  go negative (more in use than were pur‐
       chased for the Group Manager), then 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 purchas‐
       ing  and	 applying  additional  sharing rights to the Group Manager, by
       purchasing and applying core usage rights to one or more group members,
       or by removing one or more group members from their group.

       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 pur‐
       chased 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  pur‐
       chased  for  the	 complex.  Within a GiCAP group, temporary capacity is
       used as an additional compliance mechanism to support the  high	avail‐
       ability features of a group.

       Because	group members are automatically considered to be users of tem‐
       porary capacity, to avoid unexpected TiCAP depletion in a group, it  is
       important to avoid the situations that cause the Instant Capacity soft‐
       ware to make assumptions that all cores might be	 active	 on  a	remote
       nPartition, as described previously in the Temporary Capacity section.

       If  a  member is removed from the group, the TiCAP balance on that com‐
       plex 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.

       When a group is out of compliance, the group is said  to	 be  "locked".
       Sharing	of  usage rights and temporary capacity between members of the
       group is not allowed, although members can return borrowed usage rights
       or  reclaim  loaned  rights.  Members cannot be added to the group, but
       members can be removed from the group as long as the members deactivate
       any  cores  using borrowed usage rights and as long as GiCAP is able to
       reclaim any loaned usage rights.

       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.

       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 only be a member of a  single  GiCAP  group	 at  a
       time.  In order to participate in a different group, it must be removed
       from its group before being added to the other group.

       Sharing rights can never be transferred between two active  Group  Man‐
       ager  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 addi‐
       tional 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.	  For more details, see the "Group Manager Failover Considera‐
       tions" section.

       If the active Group Manager system  becomes  unavailable,  the  standby
       Group  Manager can take over GiCAP group operations from the Group Man‐
       ager.  If both the active Group Manager and the standby	Group  Manager
       are  unavailable,  or if the active Group Manager fails and the command
       was not issued to make the standby Group Manager the active Group  Man‐
       ager,  usage  rights  and temporary capacity remain as per allocated to
       each group member.  Within a server complex, the usage  rights  can  be
       deployed	 to  other partitions, but movement of usage rights and tempo‐
       rary capacity between complexes cannot occur.

       An administrator can have a standby Group Manager take control  at  any
       time  using the command.	 While this can be done routinely, for example
       to allow shutting down a functioning active Group Manager  for  mainte‐
       nance,  normally	 this  command	is issued either when the active Group
       Manager has failed, or when a network outage has made it unable to com‐
       municate	 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 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 unreach‐
       able 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 com‐
       mand), 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 a new command.	It can
       be executed on either active Group Manager to confirm that  Group  Man‐
       ager  as	 the active Group Manager and demote the other to standby sta‐
       tus.  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.

       Note that in the more straightforward  case  where  the	Group  Manager
       fails  over  to	the  standby Group Manager, but the standby is able to
       contact all the members of the group, then on reboot of the  originally
       active  Group Manager, the group is "split" only in the sense that both
       Group Managers believe they are the active Group Manager.  All  members
       are  being  managed  by	the  newly  active Group Manager (formerly the
       standby), and all group database changes	 have  been  captured  in  the
       database managed by the newly active Group Manager.  In this case, what
       is needed is to update the GiCAP database of  the  failed  GiCAP	 Group
       Manager,	 and  optionally  to  fail back to the original Group Manager.
       Updating the GiCAP database of the failed Group Manager involves	 issu‐
       ing  another  command  on  the newly active Group Manager (formerly the
       standby) once the failed Group Manager is rebooted and is  network-con‐
       tactable by the newly active Gorup Manager.  Then, you may wish to fail
       back to the originally active Group Manager by issuing another  command
       on that Group Manager.

       Systems that have no 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.
       The only constraints are IP connectivity between the members, the Group
       Manager, and the standby Group Manager (if any), sufficient GiCAP shar‐
       ing rights, and adherence to the GiCAP grouping rules.

       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  signifi‐
       cant  performance  penalty  because the Instant Capacity software occa‐
       sionally 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 host‐
       names 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  man‐
       agers  and members of groups is established using SSL certificates that
       are supplied by the GiCAP software.

       In general, a complex is in a compliant state when the number of active
       components  of  a given type does not exceed the number of usage rights
       associated with the type of component.  The one exception is  that  the
       number  of  active  cores is allowed to exceed the number of core usage
       rights as long as there is a sufficient positive balance	 of  temporary
       capacity.  A negative balance always indicates a system which is out of

       A GiCAP group is in a compliant state as long as all the members are in
       a  compliant  state, all the members of the group continue to have com‐
       patible hardware as determined by the hardware grouping rules, and  the
       number  of  sharing  rights  installed on the GiCAP manager is equal or
       greater than the total number of cores without  usage  rights  on  com‐
       plexes managed by the Group Manager.

       icapmodify(1M),	  icapnotify(1M),    icapstatus(1M),   icapmanage(1M),
       icapd(1M), parmgr(1M), parmodify(1M), parolrad(1M), vparmodify(1M).


List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net