HP OpenVMS Alpha Partitioning and Galaxy Guide |
OpenVMS Galaxy Configuration Utility |
|
|
| |
By default, the GCU provides five preconfigured charts:
Each chart 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 components; you would have no target to drag and drop a CPU on. Similarly, you cannot perform a hot-swap inquiry operation if you are displaying the Logical Structure chart. Device hot-swapping is a physical task that cannot be represented in the logical chart. Because you can modify the charts, the GCU does not restrict 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.
Component Identification and Display Properties ![]()
Each component has a unique identifier. This identifier can
be a simple sequential number, such as with CPU IDs, a physical
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 possible, 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). Do not edit this file, except to customize certain display properties, such as window color or display text style.
You can also customize the text that gets displayed about each component. 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 displayed in each component type on the screen. The device declaration in the ruleset allows 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.
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
find physical components such as modules, slots, arrays, adapters,
and so on. The type of components presented and the depth of the
component hierarchy is directly dependent on the level of support provided
by the console firmware for each hardware platform. If you are viewing
a single-instance Galaxy on any Alpha system, then only a small
subset of components can 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:
Hardware Root ![]()
The topmost component in the Physical Structure chart is known
as the hardware root (HW_Root). Every Galaxy system 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 appears 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.
| Clicking the root instance of any chart performs an auto-layout operation if the Auto Layout mode is set. |
Ownership Overlay ![]()
Choose Ownership Overlay from the Windows menu to display
the initial owner relationships for the various components. These
relationships indicate the instance that owns the component after
a power cycle. Once a system has been booted, migratable components
may change owners dynamically. 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.
Logical Structure Chart ![]()
The Logical
Structure chart displays Galaxy communities and instances and is
the best illustration of the relationships that form the Galaxy.
Below these components are the various devices they currently own. Ownership
is an important 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 turns up after a system power-up. This value is determined by the console firmware during bus-probing procedures and through interpretation 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.
The following sections describe the components of the Logical Structure chart.
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 appears
as a child of the software root. A component that has a child can
be assigned to other devices in the hierarchy when the machine is
logically defined.
| Clicking the root instance of any chart performs an auto-layout operation if the Auto Layout mode is set. |
Unassigned Resources ![]()
You can configure Galaxy partitions without assigning all
devices 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:
Devices that remain unassigned after the system boots appear to be assigned to the software root component and may not be accessible.
Community Resources ![]()
Resources such as shared memory can be accessed by all instances
within a sharing community. Therefore, for shared memory, the community
itself is considered the owner.
Instance Resources ![]()
Resources that are currently or permanently owned by a specific
instance are displayed as children of the instance component.
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 support dynamic reconfiguration of memory. Therefore, 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 useful for debugging system applications or for studying possible configuration changes.
The following sections discuss memory fragments.
Console Fragments ![]()
The console requires one or more small fragments of memory.
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 fragments
to enforce proper memory alignment.
Private Fragments ![]()
Each Galaxy instance is required to have at least 64 MB of
private memory (including the console fragments) to boot OpenVMS.
This memory can consist of a single fragment, or the console firmware
may need to create additional private fragments to enforce proper
memory alignment.
Shared Memory Fragments ![]()
To create an OpenVMS Galaxy, a minimum of 8 MB of shared memory
must be allocated. This means the minimum memory requirement for
an OpenVMS Galaxy is actually 72 MB (64 MB for a single instance
and 8 MB for shared memory).
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.
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 primary CPU, the GCU displays
an error message in its status bar and does not allow the operation
to occur.
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. Drag and drop the CPU on the desired
instance. If you drop a CPU on the same instance that currently
owns it, the CPU stops and restarts.
Fast Path and Affinitized CPUs ![]()
If you reassign a CPU that has a Fast Path device currently
affinitized to the CPU, the affinity device moves to another CPU
and the CPU reassignment succeeds. If a CPU has a current process
affinity assignment, the CPU cannot be reassigned.
For more information about using OpenVMS Fast Path features, see the HP OpenVMS I/O User's Reference Manual.
Lost CPUs ![]()
You can reassign secondary CPUs to instances that are not
yet booted (partitions).
Similarly, you can reassign a CPU to an instance that is not configured 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 instance (a separate security domain) and reassign the CPU back to the current owner.
Regardless of whether an instance is part of the Galaxy sharing community or is an independent instance, it is still present in the Galaxy configuration file; therefore, the GCU is still able to display it.
IOP Assignment Chart ![]()
The IOP Assignment chart displays the current relationship
between I/O modules 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 I/O modules in this
display.
Failover Target Chart ![]()
The
Failover Target chart shows how each processor automatically fails
over to other instances in the event of a shutdown or failure. Additionally,
this chart illustrates the state of each CPU's autostart flag.
For each instance, a set of failover objects are shown, representing 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 relationships,
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
automatically start once they arrive in the target instance. 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 implementation of failover and autostart management:
|
|