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.