OpenVMS Alpha Galaxy Guide
←Previous Next→ Contents Tables Close Download Help
  9.4  Using the GCU Charts

  The Galaxy Configuration File contains a considerable
  amount of configuration data and can grow quite large
  for complex Galaxy configurations.  If the GCU displayed all
  the information it has about the system, the display would
  become unreasonably complex.  To avoid this problem, the
  GCU provides Galaxy charts.  Charts are simply a set of
  masks that control the visibility of the various components,
  devices, and interconnections.  The entire component hier-
  archy is present, but only the components specified by the
  selected chart are visible.  Selecting a different chart alters
  the visibility of component subsets.

  By default, the GCU provides five preconfigured charts.  Each
  is designed to show a specific component relationship.  Some
  GCU command operations can be performed only within
  specific charts.  For example, you cannot reassign CPUs
  from within the Physical Structure chart.  The Physical
  Structure chart does not show the Galaxy instance compo-
  nents, thus you would have no target to drag and drop a CPU
  on.  Because you can modify the charts the GCU does not re-
  strict its menus and command operations to specific chart
  selections.  In some cases, the GCU displays an informational
  message to help you select an appropriate chart.

  For more information about modifying charts, see ?????.

  9.4.1  Component Identification and Display Properties
  Each component has a unique identifier.  This identifier be a
  simple sequential number, such as with CPU IDs, a physi-
  cal backplane slot number, as with I/O adapters, or a physical
  address, as with memory devices.  Each component type is
  also assigned a shape and color by the GCU. Where possi-
  ble, the GCU further distinguishes each component using
  supplementary information it gathers from the running
  system.

  The display properties of each component are assigned within
  the Galaxy Configuration Ruleset (SYS$MANAGER:GALAXY.GCR).
  You should not edit this file, except to customize certain
  display properties, such as window color or display text style.

  The text that gets displayed about each component is also
  customizable.  Each component type has a set of statements in
  the ruleset that determine its appearance, data content, and
  interaction.

  One useful feature is the ability to select which text is dis-
  played in each component type on the screen.  The device
  declaration in the ruleset allow you to specify the text and
  parameters, which make up the display text statement.  A
  subset of this display text is displayed whenever the zoom
  scale factor does not allow the full text to be displayed.  This
  subset is known as the mnemonic.  The mnemonic can be
  altered to include any text and parameters.

  9.4.2  Physical Structure Chart

  The Physical Structure chart describes the physical hardware
  in the system.  The large rectangular component at the top,
  or root, of the chart represents the physical system cabinet
  itself.  Typically, below the root, you will find physical compo-
  nents such as modules, slots, arrays, adapters, and so on.  The
  type of components presented and the depth of the compo-
  nent hierarchy is directly dependent on the level of support
  provided by the console firmware for each hardware plat-
  form.  If you are viewing a single-instance Galaxy on any

  Alpha system, then only a small subset of components may be
  displayed.  As a general rule, the console firmware presents
  components only down to the level of configurable devices,
  typically to the first-level I/O adapter or slightly beyond.  It
  is not a goal of the GCU or of the Galaxy console firmware
  to map every device, but rather those that are of interest to
  Galaxy configuration management.

  The Physical Structure chart is useful for viewing the entire
  collection of components in the system.  However, it does not
  display any logical partitioning of the components.

  In the Physical Structure chart you can:

  *   Examine the parameters of any system component.

  *   Perform a hot-swap inquiry to determine how to isolate a
      component for repairs.

  *   Apply an Optimization Overlay to determine whether the
      hardware platform has specific optimizations that will
      ensure the best performance.  For example, multiple-
      CPU modules may run best if all CPUs residing on
      a common module are assigned to the same Galaxy
      instance.

  *   Shut down or reboot the Galaxy or specific Galaxy in-
      stances.

  9.4.2.1  Hardware Root

  The topmost component in the Physical Structure chart is
  known as the hardware root (HW_Root).  Every Galaxy sys-
  tem has a single hardware root.  It is useful to think of this
  as the physical floorplan of the machine.  If a physical device
  has no specific lower place in the component hierarchy, it will
  appear as a child of the hardware root.  A component that is a
  child can be assigned to other devices in the hierarchy when
  the machine is partitioned or logically defined.

                                 Tip

      Clicking the root node of any chart will perform an
      auto-layout operation if the Auto Layout mode is set.

  9.4.2.2  Ownership Overlay

  Choose Ownership Overlay from the Windows menu to
  display the initial owner relationships for the various com-
  ponents.  These relationships indicate the instance that will
  own the component after a power cycle.  Once a system has
  been booted, migratable components may change owners dy-
  namically.  In order to alter the initial ownership, the console
  environment variables must be changed.

  The ownership overlay has no effect on the Physical
  Structure chart or the Failover Target chart.

  9.4.3  Logical Structure Chart
  The Logical Structure chart displays Galaxy communities
  and instances and is the best illustration of the relationships
  which form the Galaxy.  Below these components are the
  various devices they currently own.  Ownership is an im-
  portant distinction between the Logical Structure chart and

  Physical Structure chart.  In a Galaxy, resources that can
  be partitioned or dynamically reconfigured have two distinct
  ``owners''.

  The owner describes where the device will turn up after a
  system cold boot.  This value is determined by the console
  firmware during bus-probing procedures and through inter-
  pretation of the Galaxy environment variables.  The owner
  values are stored in console nonvolatile memory so that they
  can be restored after a power cycle.

  The current_owner describes the owner of a device at a
  particular moment in time.  For example, a CPU is free to
  reassign among instances.  As it does, its current_owner value
  is modified, but its owner value remains whatever it was set
  to by the lp_cpu_mask# environment variables.

  The Logical Structure chart illustrates the current_owner
  relationships.  To view the nonvolatile owner relationships,
  select Ownership Overlay from the Window menu.

  9.4.3.1  Software Root
  The topmost component in the Logical Structure chart is
  known as the software root (SW_Root).  Every Galaxy system
  has a single software root.  If a physical device has no specific
  owner, it will appear as a child of the software root.  A com-
  ponent that has a child can be assigned to other devices in the
  hierarchy when the machine is logically defined.

                                 Tip
      Clicking the root node of any chart will perform an
      auto layout operation if the Auto Layout mode is set.

  9.4.3.2  Unassigned Resources

  You can configure Galaxy partitions without assigning all de-
  vices to a partition, or you can define but not initialize one
  or more partitions.  In either case, some hardware may be
  unassigned when the system boots.

  The console firmware handles unassigned resources in the
  following manner:

  *   Unassigned CPUs will be assigned to partition 0.

  *   Unassigned memory will be ignored.

  Devices that remain unassigned after the system boots will
  appear assigned to the software root component and may not
  be accessible.

  9.4.3.3  Community Resources
  Resources such as shared memory can be accessed by all in-
  stances within a sharing community.  Therefore, for shared
  memory, the community itself is considered the owner.

  9.4.3.4  Instance Resources
  Resources that are currently or permanently owned by a
  specific instance are displayed as children of the instance
  component.

  9.4.4  Memory Assignment Chart

  The Memory Assignment chart illustrates the partitioning
  and assignment of memory fragments among the Galaxy
  instances.  This chart displays both hardware components
  (arrays, controllers, and so on) and software components
  (memory fragments).

  Current Galaxy firmware and operating system software
  does not yet support dynamic reconfiguration of memory.
  Thus, the Memory Assignment chart reflects the way the
  memory address space has been partitioned by the console
  among the Galaxy instances.  This information can be use-
  ful for debugging system applications or for studying possible
  configuration changes.

  9.4.4.1  Console Fragments
  The console requires one or more small fragments of mem-
  ory.  Typically, a console allocates approximately 2 MB
  of memory in the low address range of each partition.
  This varies by hardware platform and firmware revision.
  Additionally, some consoles allocate a small fragment in high
  address space for each partition to store memory bitmaps.
  The console firmware may need to create additional frag-
  ments to enforce proper memory alignment.

  9.4.4.2  Private Fragments

  Each Galaxy instance is required to have at least 64 MB
  of private memory (includes the console fragments) to boot
  OpenVMS. This memory may consist of a single fragment, or
  the console firmware may need to create additional private
  fragments to enforce proper memory alignment.

  9.4.4.3  Shared Memory Fragments

  To create a true Galaxy, a minimum of 8 MB of shared
  memory must be allocated.  This means the minimum mem-
  ory requirement for an OpenVMS Galaxy is actually 72 MB
  (64 MB for a single instance, and 8 MB for shared memory).

  9.4.5  CPU Assignment Chart

  The CPU Assignment chart displays the minimal number
  of components required to reassign CPUs among the Galaxy
  instances.  This chart can be useful for working with very
  large Galaxy configurations.

  9.4.5.1  Primary CPU
  Each primary CPU is displayed as an oval rather than a
  hexagon.  This is a reminder that primary CPUs cannot be
  reassigned or stopped.  If you attempt to drag and drop a pri-
  mary CPU, the GCU displays an error message in its status
  bar and does not allow the operation to occur.

  9.4.5.2  Secondary CPUs
  Secondary CPUs are displayed as hexagons.  Secondary CPUs
  can be reassigned among instances in either the Logical

  Structure chart or the CPU Assignment chart.  Simply drag
  and drop the CPU on the desired instance.  If you drop a
  CPU on the same instance that currently owns it, the CPU
  will be stopped and restarted.

  9.4.5.3  Fast Path and Affinitized CPUs
  If you migrate a CPU that has a Fast Path device currently
  affinitized to the CPU, the device will move to another CPU.
  If a CPU has current process affinity assignment, the CPU
  cannot be reassigned.

  For more information about using OpenVMS Fast Path
  features, see theOpenVMS I/O User's Reference Manual        .

  9.4.5.4  Lost CPUs

  You can reassign secondary CPUs to instances that are not
  yet booted (partitions).

  Similarly, You can reassign a CPU to a node that is not con-
  figured as a member of the Galaxy sharing community.
  In this case, you can push the CPU away from its current
  owner instance, but you cannot get it back unless you log in
  to the independent node (a separate security domain) and
  reassign the CPU back to the current owner.  The GCU
  communicates only with the Galaxy members.

  Regardless of whether an instance is part of the Galaxy
  sharing community or is an independent node, it will still be
  present in the Galaxy configuration file; therefore, thus the
  GCU will still be able to display it.

  9.4.6  IOP Assignment Chart
  The IOP Assignment chart displays the current relationship
  between I/O processors and the Galaxy instances.  Note that,
  depending on what type of hardware platform is being used,
  a single-instance Galaxy on any Alpha system may not show
  any IOPs in this display.

  The Ownership Overlay can be shown in this chart to see the
  nonvolatile owner (which instance the device will be assigned
  to after a power cycle), but until IOP reconfiguration is sup-
  ported by the OpenVMS Galaxy implementation, the owner
  will always be the same as the default display illustrates.

  9.4.7  Failover Target Chart

  The Failover Target chart shows how each processor will
  automatically failover to other instances in the event of a
  shutdown or failure.  Additionally, this chart illustrates the
  state of each CPUs autostart flag.

  For each instance, a set of failover objects are shown, repre-
  senting the full set of potential CPUs.  By default, no failover
  relationships are established and all autostart flags are set.

  To establish automatic failover of specific CPUs, drag and
  drop the desired failover object to the instance you want the
  associated CPU to target.  To set failover relationships for
  all CPUs owned by an instance, drag and drop the instance
  object on top of the instance you want the CPUs to target.

  To clear individual failover targets, drag and drop a failover
  object back to its owner instance.  To clear all failover re-
  lationships, right-click on the instance object to display the
  Parameters & Commands dialog box, click on the Commands
  button, click the ``Clear ALL failover targets?'', button and
  then click OK.

  By default, whenever a failover operation occurs, the CPUs
  will automatically start once they arrive in the target in-
  stance.  You can control this autostart function using the
  autostart commands found in the Parameters & Commands
  dialog box for each failover object, or each instance object.

  The Failover Target chart displays the state of the autostart
  flag by displaying the Failover objects in green if autostart is
  set, and red if autostart is clear.

  Please note the following restrictions in the current imple-
  mentation of failover and autostart management.

  *   The failover and autostart settings are not preserved
      across system boots.  Thus, you will need to reestablish the
      model whenever the system reboots.  To do this, invoke a
      previously saved configuration model, either by manu-
      ally restoring the desired model or by using a command
      procedure during system startup.

  *   The GCU currently is not capable of determining the au-
      tostart and failover relationships of instances other than
      the one the GCU is running on, unless the instances are
      clustered.

  *   The GCU currently does not respond to changes in
      failover or autostart state that are made from another
      executing copy of the GCU or from DCL commands.  If
      this state is altered, the GCU refreshes its display only if
      the active model is closed and then reopened.
←Previous Next→ Contents Tables Close Download Help