AlphaServer GS140 Getting Started with Logical Partitions Order Number: EK–TUNLP–SF This document describes the hardware configuration rules and the console firmware commands and environment variable settings needed to run multiple instances of an operating system on Compaq AlphaServer GS140 systems.
First Printing, May 1999 The information in this publication is subject to change without notice. COMPAQ COMPUTER CORPORATION SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL.
Contents Preface Chapter 1 1.1 1.2 1.3 4.1 4.2 4.
.4 Step 3: Set and Initialize Environment Variables, Boot/Install from Secondary Consoles Chapter 5 5.1 5.2 5.2 5.3 5.
3-1 3-2 3-3 3-4 3-5 5-1 5-2 Environment Variables and lpinit Command Construction of Three-Partition CPU Bit Mask Construction of Two-Partition CPU Bit Masks Construction of Three-Partition I/O Bit Masks Construction of Two-Partition I/O Bit Masks Setting auto_action to Halt in Each Partition Debugging One Partition 3-2 3-4 3-6 3-8 3-9 5-2 5-10 Tables 1 2-1 2-2 3-1 Related AlphaServer GS140 Documentation Requirements for a Three-Partition System Requirements for a Two-Partition System Environment Variab
Preface Intended Audience This manual is written for anyone wishing to understand the concepts and requirements of logical partitions for a Compaq AlphaServer GS140 system, as well as how to use the console firmware to define them. Document Structure This manual uses a structured documentation design. Topics are organized into small sections for efficient online and printed reference. Each topic begins with an abstract. You can quickly gain a comprehensive overview by reading only the abstracts.
Documentation Titles Table 1 lists the books in the AlphaServer GS140 documentation set and operating system documentation that you may find useful.
Chapter 1 Introduction Partitioning is defined as the capability to run multiple copies, or instances, of an operating system on one hardware system. Each instance is maintained at a separate console monitor, as shown for two partitions in Figure 1–1. The AlphaServer GS140 system supports up to three partitions.
1.1 Reasons for Partitioning Partitioning can be used for various reasons, including the consolidation of computing resources into one system or increasing the efficiency of an existing system.
With logical partitioning, you can divide computing resources into as many as three distinct partitions. Partitioning can be used for a variety of reasons, including: • Consolidation of several different computing requirements into one hardware system, thereby reducing floor space requirements, power consumption, and air conditioning costs.
1.2 Important Considerations for Partitioned Systems Here are some important considerations for partitioned AlphaServer GS140 systems. Figure 1–3 Reset: Use Caution with Partitioned Systems Reset Don't forget to shut down the Operating System in all partitions! Primary Console Secondary Con sole s (powerup display) . ..
There are some important things to be aware of when running multiple instances of operating systems on separate partitions on AlphaServer GS140 systems: • Reset Keyswitch Position. Once partitions are up and running separate instances of the operating system, turning the control panel keyswitch to the Reset position causes the system to initialize, stopping whatever is going on in all partitions.
1.3 Overview of the Partitioning Process To define logical partitions, you need to check the hardware configuration, assign modules to partitions as desired, initialize the partitions, and install the operating system.
There are hardware, firmware, and software requirements and restrictions to meet before you can run logical partitions. Chapter 2 describes the major hardware configuration rules as of this printing. However, you should check the Systems and Options Catalog for the most up-to-date information on the hardware, firmware, and software required. The Systems and Options Catalog also lists hardware that is not supported for partitioned systems and must be removed from your system before partitions will run.
Chapter 2 Configuration Rules To define logical partitions for AlphaServer GS140 systems, you must have certain hardware. Other hardware normally supported on AlphaServer GS140 systems are not supported with logical partitions. Check the Systems and Options Catalog for up-to-date information. This chapter describes the hardware requirements at the time this manual was printed.
2.1 Overview of Configuration Requirements Here are the minimum and maximum configurations for partitioned systems.
Table 2–1 lists the minimum requirements and maximum restrictions for three logical partitions; Table 2–2, for two partitions.
2.2 Example of a Partitioned System These illustrations give an overview of some of the interplay between the number of hardware modules, DWLPB adapters, KFE70/KFE72 adapters, and disks that you will need to consider in configuring your AlphaServer GS140 system to run logical partitions.
Figures 2–1 and 2–2 show an example of an AlphaServer GS140 system with three CPUs, three memories, and three I/O modules. This assortment of TLSB modules would allow either 3 or 2 logical partitions, each running an instance of the operating system. The KFE72-DAs needed to support logical partitions are present. Two CD-ROM drives are shown. Note that these CD-ROM drives protrude from the front of the shelf, and can only be installed in the rightmost shelf position in the front of either cabinet.
2.3 Module Configuration Partitions are constructed of a number of CPUs, memory, and I/O modules. Each partition must have at least one of each type.
Logical partitions are divided on hardware module boundaries. For example, each CPU module contains 2 CPUs, but you cannot have one CPU in one partition, and the other CPU in another. Both CPUs on a module must be in the same partition. Each partition must have at least one CPU module, one memory module, and one KFTIA or KFTHA I/O module. The combined partitions may include up to nine modules (the limit of the TLSB card cage).
2.4 Memory Allocation 2.4.1 Two Partitions The console firmware assigns memory to partitions such that an asnear-to-equal-as-possible amount of memory is given to each partition. Figure 2–4 Memory Allocation with Two Partitions A. Two (or four) memories of the same size: 1 (or 2) memories to each partition. B. Three or five memories of same size: largest amount of memory to partition 0, next-largest to partition 1.
When you are defining two partitions, you may have from two to five memory modules, depending on the number of CPU and I/O modules in the system. Memory is always allocated on module boundaries. Set the interleave environment variable to none, as noted in Chapter 4. The console firmware allocates the largest sized module to partition 0, and the smallest module to partition 1. It then attempts to distribute the remaining modules such that as equal an amount is given to both partitions as is possible.
2.4.2 Three Partitions Three-partition systems require at least three memory modules. Each partition is allocated one module. Memory modules are allocated in decreasing size order. Figure 2–5 Memory Assignment with Three Partitions Three partitions, three memories: A. Memories all the same size: 1 memory to each partition. B. Memories of different size: largest memory to partition 0, next-largest to partition 1, smallest to partition 2.
When you are defining three partitions, three memory modules are always needed. They may or may not be of the same size. Figure 2–5 shows some examples of how memory is divided in this case. When all three memories are of the same size, one is allocated to each partition. When the memories are of different size, the largest memory is assigned to partition 0; the next largest (or equal), to partition 1, and the next largest (or equal), to partition 2.
2.5 DWLPB PCI Card Cages and Hose Connections One DWLPB PCI card cage is required for each secondary partition.
Each AlphaServer GS140 system may have a DWLPB PCI card cage with either a KFE70 adapter (standard I/O) or a KFE72-EA adapter (for graphics support) installed. This is only necessary if you wish to have the floppy drive installed near the front panel switches in the main cabinet. The I/O hose for this PCI must be connected to the I/O module in TLSB slot 8. An additional DWLPB PCI card cage must be installed in the system for each secondary partition.
2.6 KFE72-DA Adapters and Attached Console Terminals One KFE72-DA adapter is required for each logical partition beyond partition 0. The KFE72-DA provides the port to connect an additional serial console terminal.
The connection for the primary console terminal is on the control panel on the front of the machine. This connection is shown for the leftmost terminal in Figure 1–1 on page 1-1 of this manual. You may also have a KFE70 or KFE72EA adapter connected to the TLSB I/O module in slot 8 to provide floppy support on the front of the cabinet (see Figure 2–9). This is optional, however.
2.7 CD-ROM Drives for Secondary Partitions The CD-ROM drive for partition 0 is located near the control panel on the front of an AlphaServer GS140. You may install RRD43/44/45/46/47VA CD-ROM drives for each secondary partition in the rightmost shelf at the front of either the main cabinet or the expander cabinet.
You can install one RRD46/47-VA CD-ROM drive for each secondary partition in your system, if, for example, you have no network adapter or installation server available and want to boot from a CD-ROM in each partition. If you put these disks in the main or expander cabinets, they must occupy the rightmost shelf at the front of the cabinet. They protrude from the shelf, and the front door will not close if they are in other shelves.
2.8 Attaching Floppy Drives for Secondary Partitions (Optional) You may wish to install floppy drives on your KFE72-DA adapters.
You may install a floppy drive off of the floppy drive port on the connector module of the KFE72-DA (in front panel slot 2 of the PCI card cage), as shown in Figure 2–10. If you only have one floppy drive, and wish to move it between partitions, see Section 2.9.
2.9 Moving One Floppy Drive Between Partitions (Optional) Your configuration may include only one floppy drive, and you may want to run configuration utilities (for example, the Raid Configuration Utility) on each partition. This section tells how to move a single floppy from one partition to another.
If you need to run configuration utilities from various partitions, and have only one floppy drive, you can attach it to separate partitions as follows: 1. Shut down the operating system instances in each partition. 2. Disable partitions and reinitialize the system to a nonpartitioned state, as described in Section 5.3. You may wish to record the environment variable information and use it when you re-enable partitions. 3. Power the system down. 4.
Chapter 3 Environment Variables that Create Logical Partitions You define what resources are allocated to each partition by creating or setting environment variables. Before showing the sequence of these commands (see Chapter 4), you should understand in detail the significance of these environment variables and their settings, as described in this chapter.
3.1 Environment Variables Used Four environment variables and the lpinit command define partitions. Figure 3–1 Environment Variables and lpinit Command P0 Environment Variables define: P1 1. Number of partitions: lp_count (0, 2, or 3) 2. CPU modules in each partition: lp_cpu_mask* (bit mask) P1 P0 3. I/O modules in each partition: lp_io_mask* (bit mask) P0 P1 4.
You define values for one environment variable to define the number of logical partitions on your system, one to set the memory mode, and two for each partition that define the CPU and I/O modules in each partition. The lpinit command (described in context in Chapter 4) initializes the logical partitions defined. Figure 3–1 and Table 3–1 give an overview of the environment variables and what they do.
3.2 Detailed Directions for lp_cpu_mask The lp_cpu_mask environment variable is set to a value that creates a binary mask in which a bit set to 1 indicates that an individual CPU belongs to a partition. Recall that there are two CPUs per module, and that partitions must contain whole modules. Figure 3–2 Construction of Three-Partition CPU Bit Mask Partition 0 6 Slot No. CPU No. 5 3 2 1 0 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Bits set ... 0 0 0 0 1 1 6 Slot No. CPU No.
Note that you must assign CPUs to a partition on module boundaries. CPU modules can be assigned to partitions in any order. Three-Partition System For a three-partition system, three CPU modules is the maximum allowed (since there must also be three memories and three I/O modules, and the total number of slots is 9.) In this case, assigning CPUs to partitions is fairly straightforward. Again, the CPUs in slot 0 must be assigned to partition 0. The CPUs in slots 1 and 2 can be assigned as desired.
Figure 3–3 Construction of Two-Partition CPU Bit Masks Partition 0: CPU Module in Slot 0 6 Slot No. Bit No. Bits set 5 4 3 2 1 0 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ... 0 0 0 0 0 0 1 1 = hex value 3 Partition 1: CPU Modules in Slots 1, 2, and 3 6 Slot No. Bit No. Bits set 5 4 3 2 1 0 13 12 11 10 9 8 7 6 5 4 3 2 1 0 ... 1 1 1 1 1 1 0 0 = hex value FC Partition 0: CPU Modules in Slots 0, 1, and 3 6 Slot No. 5 Bit No. Bits set 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 ...
Two-Partition System A two-partition system has more possibilities for CPU allocation. From two to five slots may be occupied by CPU modules in TLSB slots 0 – 4. Again, the CPUs in slot 0 must be assigned to partition 0. Other than that, there are no restrictions. The top portion of Figure 3–3 shows 4 CPU modules in slots 0, 1, 2 , and 3, with the CPUs in slot 0 included in partition 0, and the CPUs in slots 1, 2 and 3 included in partition 1.
3.3 Detailed Instructions for lp_io_mask The lp_io_mask environment variable is set to a hexadecimal mask in which the bit position of a 1 indicates the slot in which the I/O module resides. Figure 3–4 Construction of Three-Partition I/O Bit Masks Partition 0 Slot No. Bits set 876543210 ... 1 0 0 0 0 0 0 0 0 = hex value 100 Partition 1 Slot No. 876543210 ... 0 1 0 0 0 0 0 0 0 = hex value 80 Bits set Partition 2 Slot No. 876543210 Bits set ...
Two-partition-systems may have two or three I/O modules. Figure 3–5 gives two examples of three-I/O-module, two-partition systems. The first shows partition 0 with one I/O module in slot 8, and partition 1 with two modules in slots 6 and 7. The console commands are: create –nv lp_io_mask0 100 create –nv lp_io_mask1 c0 The bottom of Figure 3–5 shows a two-partition system with the I/O modules in slots 8 and 6 assigned to partition 0, and the I/O module in slot 7 assigned to partition 1.
Chapter 4 Setting Up, Initializing, and Booting Logical Partitions The sequence of console commands used to define and initialize partitions is described in this chapter.
4.1 Primary Console: Check Configuration Before you define any partitions, check to make sure you have all you need to support partitions as you wish to configure them. Example 4–1 Check Configuration from Primary Console ff.fe.fd.fc.fb.fa.f9.f8.f7.f6.f5.f3.f2.f1.f0. ➊ ef.ee.ed.f4. 20.21.22.23.24.25.26.27.a2.a4.a5.a7.a8.a9.ec.eb.ea.e9.e8.e7.e6.e5.e3. F E D C B A 9 8 A o . o . + . 6 A o . o . + . + . . + . . . . 5 M + . + . + . + . . + . . . . 4 M + . + . + . + . . . . . . . 3 M + . + . + . . .
From the primary console terminal, check the configuration. You can do this either from the power-up display (Example 4–1) or by using a show config command. ➊ The AlphaServer GS140 power-up display includes (as long as a CPU module is in slot 0) test numbers as testing proceeds, so that if the system fails, the user or field service engineer can determine the point during testing that the system failed.
Example 4–1 Check Configuration from Primary Console (Continued) P00>>> sho config TLSB 0++ 1++ 2++ 3+ 4+ 5+ 6+ 7+ 8+ ➊ Name Type Rev KN7CG-AB KN7CG-AB KN7CG-AB MS7CC MS7CC MS7CC KFTHA KFTHA KFTIA 8025 8025 8025 5000 5000 5000 2000 2000 2020 0000 0000 0000 0B04 0000 0000 0D03 00D3 0000 Mnemonic kn7cg-ab0 kn7cg-ab1 kn7cg-ab2 ms7cc0 ms7cc1 ms7cc2 kftha1 kftha0 kftia0 C0 Internal PCI connected to kftia0 0+ QLogic ISP1020 10201077 0001 1+ QLogic ISP1020 10201077 0001 2+ DECchip 21040-AA 21011 0024 4+ Q
Example 4–1 Check Configuration from Primary Console (Continued) C8 PCI connected to kftha1 0+ SIO 4828086 3+ VGA D1011 6+ QLogic ISP1040B 10201077 7+ QLogic ISP1040B 10201077 8+ DECchip 21041-AA 141011 9+ DECchip 21140-AA 91011 A+ KZPSA 81011 B+ Mylex DAC960 11069 0+ 1+ 2+ 3+ 6+ Controllers on SIO DECchip 21040-AA FLOPPY KBD MOUSE TOY 21011 2 3 4 7 0015 0022 0005 0005 0021 0022 0000 0002 pci3 sio2 vga1 isp6 isp7 tulip6 tulip7 kzpsa1 dac3 0024 0000 0000 0000 0000 sio2 tulip5 floppy2 kbd2 mouse2 toy2
4.2 Step 1: Create and Initialize Environment Variables from the Primary Console Create (or set) a series of environment variables from the primary console terminal. Example 4–2 Initial Commands from the Primary Console P00>>> show version version V5.
Begin to define logical partitions by issuing commands from the primary console terminal. Example 4–2 shows a possible sequence. The steps are described below. ➊ Logical partitions require console firmware support. (See the Systems and Options Catalog for the version necessary.) If you have not already done so, verify that your system’s console revision number is the minimum or greater by issuing the show version command. If the version is not at the desired level, you need to update the console firmware.
4.3 Step 2: Initialize Partitions from the Primary Console; Boot/Install OS in Partition 0 Initialize partition 0 and then initialize the secondary partition(s). Boot and install the operating system in partition 0.
Following the system reset, you are still issuing commands at the primary console. Perform the following actions: ➊ Issue the lpinit command to start the secondary partitions. The primary console displays information on the partitions defined. The CPUs assigned to each partition are listed, the memory ranges assigned are listed, a check is made for interleaving, and the results displayed. Then the firmware starts the CPUs in each partition, and displays that information as the partitions “come alive”.
4.4 Step 3: Set and Initialize Environment Variables, Boot from Secondary Consoles From each secondary console, set desired environment variables, initialize and boot the operating system. Example 4–4 Using the Secondary Consoles [initialization display] . .
Once lpinit is executed from the primary console, initialization displays appear at the secondary consoles. ➊ Note that the console prompt displays the processor number of the boot processor for the secondary partition. Example 4–4 shows the user issuing a show config command. ➋ Note that the show config displays the entire TLSB configuration, but only the I/O configuration for this particular partition. In the example, a PCI card cage is attached to hose C4 on the KFTHA in slot 7.
Chapter 5 Tips and Troubleshooting This chapter describes some things you may want to do after you have defined and initialized logical partitions on your system.
5.1 Setting auto_action Within Partitions Here are some tips on setting the auto_action environment variable for partitions. Figure 5–1 Setting auto_action to Halt in Each Partition Reset Don't forget to shut down the Operating System in all partitions! Primary Console Secondary Con sole s (powerup display) . .. P00>>>lpinit (powerup display) . .. P02>>> (powerup display) . ..
In general, it is reasonable practice to set auto_action to halt in each partition when you are first starting up logical partitions. Once you are sure that the partitions have been defined as you wish, you can install and boot the operating system in each partition. Once you have partitions running smoothly, you can make changes to auto_action as desired.
5.2 How to Stop a Hung Partition You can halt a hung operating system instance in partition 0 by typing Ctrl/P at the primary console. You can halt a hung operating system instance in a secondary partition by issuing a stop n command from another partition. Example 5–1 Halting a Hung OS Instance in Partition 0 . . . [operating system in partition 0 hung] . . . P00>>> Example 5–2 Halting a Hung OS Instance in Secondary Partitions . . . [shut down operating system in partition 0] . . .
CAUTION: It is always recommended practice to shut down the operating system before attempting to halt a partition. This may not always be feasible, for instance, when an operating system instance is hung. The procedures described here refer to that situation. When an operating system instance hangs in partition 0, you can return to the console prompt by typing Ctrl/P at the primary console terminal, as shown in Example 5–1. The secondary partitions continue running.
5.3 Halting All Partitions to Reconfigure You may wish to change the allocations set with the lp_* environment variables, in effect reconfiguring your partitions. Shut down the operating system in each partition, reset the system, change the settings as desired, reset the system, and issue an lpinit command.
➊ Shut down the operating system, using a command such as this one, at each of the primary and secondary console terminals. ➋ Set the lp_count environment variable to 0 and issue an init to disable partitioning on the system. ➌ You must use an init to reset the system so that all CPUs again run in partition 0. This will cause the environment variable changes made to be copied later to the CPUs in the secondary partitions when they are later initialized.
5.4 Correcting Errors in Environment Variables It is easy enough to make a mistake in setting bit masks for the lp_* environment variables. When you initialize partitioning, any unallocated modules or doubly allocated modules will be noted at the primary console. Example 5–5 Correcting a Bad Bit Mask P00>>> init ➊ Are you sure you want to reset ALL partitions? (Y/) Y . . .
Continuing from the previous section, where the console firmware revealed that CPUs 2 and 3 were not assigned to any partition, do an init to reset all partitions (➊). At ➋, correct the bit mask for partition 0 to include CPUs 2 and 3, and issue an lpinit to initialize the partitions.
5.5 Using Tools to Debug a Partition You can analyze crash dumps and run DECevent from a partition while other partitions are operating normally.
A partition can crash, while other partitions remain up and running. You can use the same tools to debug the problem partition as you would for a nonpartitioned system. You must first ensure that the tool has been installed on each partition. For information on how to install DECevent, see the DECevent Installation Guide.
Index A bootdef_dev, 4-11 correcting errors in, 5-8 defining logical partitions, 3-2 interleave, 2-9, 2-11, 4-3, 4-7 lp_count, 3-4 lp_cpu_mask, 3-4 lp_cpu_mask (detail), 3-5 lp_io_mask, 3-4 lp_io_mask (detail), 3-9 lp_mem_mode, 3-4 os_type, 4-7, 4-11 Auto_action environment variable, 4-7, 4-11, 5-2 B Boot_osflags environment variable, 4-11 Boot_reset environment variable, 4-7 Bootdef_dev environment variable, 4-11 C Configuration checking, 4-3 Configuration rules, 2-1–2-21 console devices, 2-15 DWLPB PC
L lp_count, 3-4 lp_cpu_mask, 3-4, 3-5, 3-6 lp_io_mask, 3-4, 3-9, 3-10 lp_mem_mode, 3-4 Lpinit command, 3-2, 4-9 M Memory allocation two partitions, 2-8 three partitions, 2-10 O Os_type environment variable, 4-7, 4-11 P Primary console create and intialize environment variables, 4-6 Index-2 example commands, 4-3, 4-7 initialize partitions, 4-9 show config, 4-5 Process overview, 1-7 R Reconfiguring partitions, 5-6 Reset keyswitch cautions, 1-5 S Secondary console boot, 4-10 connecting to system, 2-14 e
