HP-UX Virtual Partitions Administrator’s Guide HP Part Number: T1335-90098 Published: September 2008 Edition: 16
© Copyright 2008 Hewlett-Packard Development Company L.P. All rights reserved Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
Table of Contents About This Document.......................................................................................................15 Publication History...............................................................................................................................15 1 Introduction...................................................................................................................17 What Is vPars?.........................................................................
Number of Virtual Partitions...........................................................................................................52 Virtual Partition Names...................................................................................................................52 Minimal Hardware Configuration..................................................................................................52 CPUs..................................................................................................
The Update Process.........................................................................................................................77 Updating from vPars A.03.xx to Mixed HP-UX 11i v1/v2 vPars (A.03.05 and A.04.05) Environment.........................................................................................................................................81 Overview of the Mixed HP-UX 11i v1/v2 vPars Environment Update Process.............................82 Update-UX Primer....................
vPars Monitor: Booting the vPars Monitor.........................................................................................130 vPars Monitor: Accessing the vPars Monitor Prompt........................................................................130 vPars Monitor: Using vPars Monitor Commands..............................................................................131 Booting..........................................................................................................................
LVM maintenance mode steps.................................................................................................169 Resetting a Virtual Partition................................................................................................................170 Hard Reset.....................................................................................................................................170 Soft Reset...................................................................................
CPU: Adding and Deleting by Total...................................................................................................199 vparcreate......................................................................................................................................200 vparmodify....................................................................................................................................200 CPU: Adding or Deleting by CLP (Cell Local Processor).............................
Syntax.............................................................................................................................................229 Commands.....................................................................................................................................229 vparcreate......................................................................................................................................229 Usage Scenario......................................................
CPU: Adding and Removing Bound CPUs .......................................................................................256 CPU Allocation Syntax In Brief.....................................................................................................256 Syntax for vparcreate...........................................................................................................256 Note on vparmodify Syntax.............................................................................................
Archiving the Virtual Partitions Using a Virtual Partition as the Ignite-UX Server...........286 Recovering the Virtual Partitions Using one of the Virtual Partitions as the Ignite-UX Server...................................................................................................................................286 Using make_tape_recovery and Dual-media Boot..................................................................287 Setting Up a Disk for Dual-Media Recovery................................
Create the Virtual Partitions.....................................................................................................309 Boot the Virtual Partitions........................................................................................................309 Create A Fourth Virtual Partition.............................................................................................310 Remove a Virtual Partition.......................................................................................
List of Figures 1-1 1-2 2-1 2-2 2-3 2-4 4-1 6-1 6-2 6-3 6-4 6-5 6-6 6-7 7-1 7-2 7-3 7-4 7-5 7-6 7-7 8-1 8-2 8-3 8-4 8-5 8-6 8-7 12-1 A-1 A-2 A-3 A-4 A-5 vPars Conceptual Diagram...........................................................................................................17 Superdome Cabinet.......................................................................................................................18 Server without vPars.................................................................
List of Tables 2-1 2-2 2-3 2-4 2-5 2-6 3-1 3-2 3-3 3-4 3-5 3-6 3-7 4-1 4-2 4-3 4-4 4-5 4-6 5-1 5-2 5-3 5-4 5-5 6-1 6-2 10-1 11-1 F-1 14 PA-RISC and Integrity Differences................................................................................................39 Differences Among vPars Versions...............................................................................................40 To Migrate the Resource, the Target Virtual Partition State must be............................................
About This Document Intended Audience This document is written for system administrators to help them learn and manage the product HP-UX Virtual Partitions (vPars) on HP-UX 11i v1, 11i v2, and 11i v3. Where to Get the Latest Version of This Document New information may have been developed after the time of this publication. For the most current information, see the vPars areas of the HP Technical Documentation website: vPars A.03.xx and earlier on HP-UX http://docs.hp.com/hpux/11i/ 11i v1 index.
1 Introduction This chapter covers: • What Is vPars? • Why Use vPars? • Supported Environments • Product Interaction • Ordering vPars What Is vPars? vPars is a Virtual Partitions product that enables you to run multiple instances of HP-UX simultaneously on one hard partition by dividing that hard partition further into virtual partitions. Each virtual partition is assigned its own subset of hardware, runs a separate instance of HP-UX, and hosts its own set of applications.
NOTE: Definitions This document uses the following definitions when discussing virtual partitions, nPartitions, and hard partitions: A complex is the entire partitionable server, including both cabinets, all cells, I/O chassis, cables, and power and utility components. A cabinet is the Superdome hardware “box”, which contains the cells, Guardian Service Processor (GSP), internal I/O chassis, I/O fans, cabinet fans, and power supplies. A complex has up to two cabinets.
• • Software-related kernel panics 1, resource exhaustion failures, and reboots in one virtual partition do not affect any other virtual partition. Processing resources and memory available at boot time can be added to or removed from a virtual partition without rebooting. Why Use vPars? The following are some of the advantages of using vPars. Note that some of these features, such as dynamic memory migration, are only available in more recent releases.
Therefore a single processor can have more than one core, and vPars commands will refer to the separate cores as distinct “CPUs,” each with its own hardware path. Two vPars terms pre-date multi-core processors, so they are exceptions to this terminology: — “boot processor”, which refers to the CPU (that is, core) on which the OS kernel of the virtual partition was booted, and — “cell local processor (CLP),” which refers to a CPU on a specified cell.
deactivates a processor, it does not automatically replace the failing processor with an iCAP (formerly known as iCOD) processor. The processor replacement must be performed manually using theicod_modify command. For more information, see the Instant Capacity User’s Guide. Beginning with STM version A.43.00, in a vPars environment, the LPMC monitor automatically replaces a failing processor with an iCAP processor if an iCAP processor is available. CAUTION: CPU Expert Tool is supported on vPars servers.
— — /opt/ignite/boot/Rel_B.11.NN/?INSTALL ◦ where NN completes the HP-UX version and where ? is W for PA-RISC systems — For example, if vPars is using HP-UX 11i v2 (11.23) instances on a PA-RISC server with Ignite-UX version C.06.xx, the path is: ◦ /opt/ignite/boot/Rel_B.11.23/WINSTALL Thus, if you are using HP-UX 11i v2 (11.23) on a PA-RISC server and — Ignite-UX version B.05.
• UPS (uninterruptible power supply) software UPS hardware communicates with UPS software via the serial port. By default, a hard partition has only one serial port. For a hard partition that runs vPars, the serial port can be owned by at most one virtual partition. Therefore, on the hard partition, the UPS can communicate with only the virtual partition that owns the serial port.
vPars partition database is read. (Note that the files in the LIF area are still read when the system or nPartition boots). To simulate the effect of an AUTO file for a virtual partition, use the vPars commands so that the information is saved in the vPars partition database. For more information, see “The AUTO File on a Virtual Partition” (page 163).
storage subsystem, support has been extended to include vPars configurations and operations starting with vPars A.05.03. Agile addressing support is only provided for lunpath hardware paths, not for LUN hardware paths. Use of LUN hardware paths will result in an error. Agile addressing is supported only for HP-UX 11iv3 (11.31) releases of vPars, starting with vPars A.05.03. It is not supported by vPars A.05.02 or earlier, vPars A.04.xx on HP-UX 11i v2 (11.23), or vPars A.03.xx on HP-UX 11i v1 (11.11).
NOTE: In certain situations when using vPars with SAS disks on HP Integrity platforms, the vparstatus -v and setboot commands may show different boot disk paths in vPars mode. This is normal, and is due to the disks being scanned in a different sequence at boot time. You may see different boot disk paths for SAS disks reported by the vparstatus -v and setboot commands in vPars mode after booting into nPars mode and then booting back into vPars mode.
2 How vPars and Its Components Work This chapter covers: • Partitioning Using vPars • vPars Monitor and vPars Partition Database • vPars Boot Sequence • EFI and Integrity Notes • Virtual Consoles and Logs • Security Partitioning Using vPars To understand how vPars works, compare it to a server not using vPars. Figure 2-1 shows a 4-way HP-UX server. Without vPars, all hardware resources are dedicated to one instance of HP-UX and the applications that are running on this one instance.
Figure 2-2 Software Stack of Server without vPars Application 2 Application 1 HP-UX 11i Hardware / Firmware Using vPars, you can allocate a server’s resources into two or more virtual partitions, each with a subset of the hardware. In Figure 2-3, two virtual partitions are shown, each with its own boot disk, its own processor resources, its own LAN connection, and a sufficient subset of memory to run HP-UX and the applications intended to be hosted on that virtual partition.
Figure 2-4 Software Stack for Server with Two Virtual Partitions Application 1 Application 2 HP-UX 11i Patch Level B HP-UX 11i Virtual Partition Monitor Hardware / Firmware vPars Monitor and Database vPars Monitor For each hard partition, the vPars Monitor manages the assignment of hardware resources to virtual partitions, boots virtual partitions and their kernels, and emulates certain firmware calls.
As a preventive action, you can back up the vPars partition database to avoid accidental loss of configuration changes. For more details, see “Network and Tape Recovery” (page 279) and “Using an Alternate Partition Database File ” (page 171). You can create, modify, and view the database contents using vPars commands at the Unix shell level. See “vPars Monitor and Shell Commands” (page 121).
Adding vPars adds the vPars Monitor layer, so now hpux(for Integrity, hpux.efi) loads the vPars Monitor. Then the vPars Monitor boots the kernels of the virtual partitions. The boot sequence becomes the following. 1. ISL or EFI (firmware) 2. hpux or hpux.efi 3. /stand/vpmon (vPars Monitor and partition database) 4. /stand/vmunix (kernels of the virtual partitions) Boot Sequence: The Details With or without vPars, the firmware loads and launches ISL or EFI.
Virtual Consoles HP-UX servers have a special terminal or window called a console that allows special control and displays system error messages. With vPars, each virtual partition has its own virtual console. On Integrity, the console is virtualized by firmware (and therefore, there is no vcs driver). On PA-RISC, for each partition, its console I/O is sent to its vcn (Virtual CoNsole) driver. From the vcn driver, the console I/O is sent to the vPars Monitor.
Each virtual partition has an 8K circular buffer for console output. If not already displayed, the vPars Monitor copies this 8K buffer to the console when you press Ctrl-A. CAUTION: (A.03.xx only) The first virtual partition that you create must own the LBA (local bus adapter) that contains the physical hardware console port. For an example, see “Assigning the Hardware Console LBA” (page 55).
NOTE: Note the following when using virtual consoles: • ioscan output On a PA-RISC system, the ioscan output for vcn and vcs drivers show a value of NO_HW in the S/W State column. This is normal. On an Integrity system, the vPars virtual console is truly virtual and will not show up in an ioscan. You can see this with the vparstatus -m command: # vparstatus -m Console path: No path as console is virtual Monitor boot disk path: 13.0.11.1.0.8.
partition. When this CPU is migrated to a running virtual partition, the console will not accept any keyboard input. You can do either of the following to resolve the problem: — — From a running partition, reset the partition that owns the hardware console port by executing vparreset -p target_partition -h, where target_partition is the partition that owns the hardware console port.
only one particular virtual partition. The virtual partition that is used is the virtual partition that was booted from the same disk that was used to boot the vPars Monitor; this disk must be the primary boot disk specified in the EFI Boot Manager after the system reboots in vPars mode following an MCA. NOTE: For information on logging of the command execution of vpar* commands, see “Commands: vPars Commands Logging” (page 135).
EFI and Integrity Notes • EFI Shell Accessibility After the vPars Monitor (/stand/vpmon) is booted, the EFI shell will not be accessible. This includes using hpux.efi and other EFI commands. If you need to perform any EFI functions, you will need to shut down all the virtual partitions and reboot the nPartition to access the EFI shell. • New vPars Commands The vPars commands introduced in vPars A.04.
new EFI device path. However, firmware-saved EFI boot path options are not updated. If the nPartition or vPars Monitor is rebooted, the new EFI boot path options are discarded and replaced with the previously saved EFI boot path options, which contain now stale EFI device paths. The EFI boot options can be updated manually by performing the following: 1. Switch to nPars mode via the vparenv or vparconfig command. 2. Reboot the nPartition to the EFI Boot Manager. 3. Select Boot Option Maintenance Menu. 4.
On PA-RISC, you do not need to set modes. • vparboot -I and the LAN Card On Integrity platforms, performing a vparboot -I uses the LAN card of the target partition to obtain the bootable kernel. See “Ignite-UX, the LAN, the LAN card, and vparboot -I” (page 74). On PA-RISC, the lan card of the source partition is used. • Boot String On Integrity platforms, the boot string used at the hpux.efi prompt (hpux>) is “boot vpmon”. See “Boot Sequence” (page 30).
Table 2-1 PA-RISC and Integrity Differences (continued) vPars Functionality PA-RISC Integrity Boot vPars Monitor Steps ISL> hpux /stand/vpmon Shell> fs0:\> vPars ... Shell> fs0:\> fs0: vparconfig reboot fs0: hpux vpmon Booting to standalone mode special steps none set to nPars mode before booting nPartition PRI and ALT saved across nPars-mode/standalone and vPars-mode/vPars changes yes yes (vPars A.05.
Table 2-2 Differences Among vPars Versions (continued) vPars Version A.03.xx A.04.xx A.05.
Resource Migration and Required States The table below shows whether a resource is dynamically migratable; in other words, for each given resource type and vPars version, the intersecting box shows whether the target virtual partition must be up or down to migrate the resource. Table 2-3 To Migrate the Resource, the Target Virtual Partition State must be... Version CPUs vPars A.03.xx bound: unbound: Memory down up or down I/O down vPars A.04.xx vPars A.05.
Table 2-5 CPU Syntax from A.03.xx to A.04.xx/A.05.xx vPars A.03.xx Syntax vPars A.04.xx/A.05.
Table 2-6 CPU Rules from A.03.xx to A.04.xx/A.05.xx (continued) vPars A.03.xx Rules vPars A.04.xx/A.05.
Table 2-6 CPU Rules from A.03.xx to A.04.xx/A.05.xx (continued) vPars A.03.xx Rules vPars A.04.xx/A.05.xx Rules deleting by hw_path (-d cpu:hw_path) • can only delete CPU added by hw_path deleting by hw_path (-d cpu:hw_path) • can delete any CPU (except the boot processor) adding by cell adding by cell (-a cell:cell_ID:cpu::num) • not available in A.03.
3 Planning Your System for Virtual Partitions This chapter addresses the following topics: • Example System • Planning Your Virtual Partitions • “Mixed HP-UX 11i v1/v2 vPars Environments in vPars A.04.05” (page 58) • “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.xx” (page 60) • “Mixed HP-UX 11i v1/v2/v3 vPars Environments in vPars A.05.
1/2/0/0.0 1/2/0/0.0.0 1/2/0/0.7 1/2/0/0.7.0 1/2/0/1 1/2/0/1.7 1/2/0/1.7.0 1/4 1/4/0/0 1/4/0/0.5 1/4/0/0.5.0 1/4/0/0.7 1/4/0/0.7.0 1/4/0/1 1/4/0/1.7 1/4/0/1.7.
0/0/2 ba 0/0/2/1/0 lan 0/0/4 ba 0/0/6 ba 0/0/6/1/0 fc 0/0/8 ba 0/0/8/1/0 ba 0/0/8/1/0/1/0 ext_bus 0/0/8/1/0/1/0.7 0/0/8/1/0/1/0.7.0 0/0/8/1/0/1/1 ext_bus 0/0/8/1/0/1/1.7 0/0/8/1/0/1/1.7.0 0/0/8/1/0/4/0 lan 0/0/10 ba 0/0/12 ba 0/0/14 ba 0/5 memory 0/10 processor 0/11 processor 0/12 processor 0/13 processor 0/14 processor 0/15 processor 1 cell 1/0 ioa 1/0/0 ba 1/0/0/0/0 tty 1/0/0/0/1 tty 1/0/0/3/0 ext_bus 1/0/0/3/0.6 target 1/0/0/3/0.6.0 disk 1/0/0/3/0.7 target 1/0/0/3/0.7.0 ctl 1/0/0/3/1 ext_bus 1/0/0/3/1.
I/O Hardware Paths For non-nPartitionable systems, the beginning portions of the I/O hardware paths are in the format: • sba/lba But for nPartitionable systems, the beginning portions of the I/O hardware paths include the cell and are in the format: • cell/sba/lba Impact on vPars Commands: Specifying I/O On a non-nPartitionable system, a vparcreate command might look like: # vparcreate -p winona1 -a cpu::2 -a cpu:::2 -a mem::1024 -a io:0.0 -a io:0.4 -a io:0.0.2.0.6.0:BOOT • where -a io:0.
where 0/12 and 0/13 are the cell/CPU hardware paths, then the vparcreate command would look like: # vparcreate -p vpar2 -a cpu::2 -a cpu:::2 -a cpu:0/12 -a cpu:0/13 ... Planning Your Virtual Partitions Virtual Partitions Layout Plan Before you install vPars, you should have a plan of how you want to configure the virtual partitions within your server. Example of a virtual partition plan for vPars A.04.xx based on the example cellular server: Partition Name keira1 keira2 keira3 Assigned CPUs (A.04.
NOTE: When you create a partition, the vPars Monitor assumes you will boot and use the partition. Therefore, even if a partition is down, the resources assigned to the partition cannot be used by any other partition. The next few sections will describe how we arrived at each portion of the partition plan.
The ioscan output for the example non-cellular (winona) and cellular (keira) systems show the following CPUs: keira# ioscan -kC processor H/W Path Class Description ====================================================== 0/10 processor Processor 0/11 processor Processor 0/12 processor Processor 0/13 processor Processor 0/14 processor Processor 0/15 processor Processor 1/10 processor Processor 1/11 processor Processor 1/12 processor Processor 1/13 processor Processor 1/14 processor Processor 1/15 processor Pr
Memory For detailed information on memory allocation, read “Memory: Allocation Notes” (page 230). If you are planning an A.05 system, you should also see “Memory: Topics” (page 181). NOTE: The default memory assigned to a virtual partition is 0 MB, so you need to specify enough memory for your applications and the operating system. While there is no specific minimum base memory requirement per vPar, the HPUX kernel does require a certain amount of base memory to boot successfully.
0/10 0/12 1/0 1/2 1/4 1/8 1/10 1/12 ba ba ba ba ba ba ba ba Local Local Local Local Local Local Local Local PCI PCI PCI PCI PCI PCI PCI PCI Bus Bus Bus Bus Bus Bus Bus Bus Adapter Adapter Adapter Adapter Adapter Adapter Adapter Adapter (782) (782) (782) (782) (782) (782) (782) (782) Partition Name keira1 keira2 keira3 I/O LBAs 1.0.0 (boot) 0.0.1 (lan) 1.0.4 (boot) 1.0.1 (lan) 0.0.0 (boot) 0.0.2 (lan) Partition Name winona1 winona2 winona3 I/O LBAs 0.0 boot/lan 0.4 0.8 boot 1.10 lan 0.
CAUTION: The A.03.xx releases of vPars require the first virtual partition to own the LBA for the physical hardware console port. For the example above, when we create the virtual partitions, we would create winona1 and keira1 first. CAUTION: vPars Console Assignment on sx2000-based Servers The console UART for sx2000-based servers is no longer on a PCI card, and the system console is memory mapped and moved to PDH. Hence, there is no LBA component for the console to be assigned to a virtual partition.
Choosing the Boot and Lan Paths Using the full ioscan output, we chose the following boot disk path and note the LAN card path: Partition Name keira1 keira2 keira3 Boot Path 1/0/0/3/0.6.0.0.6.0 1/0/4/1/0/4/0.1.0.0.0.0.1 0/0/0/3/0.6.0 LAN 0/0/1/1/0/4/0 1/0/1/1/0/4/0 0/0/2/1/0 Partition Name winona1 winona2 winona3 Boot Path 0.0.2.0.6.0 0.8.0.0.5.0 1.4.0.0.5.0 LAN 0.0.0.0 1.10.0.0.4.0 0.5.0.0.4.
LAN 0/0/1/1/0/4/0 console port (PA-RISC Only) owned by keira1 Autoboot 1/0/1/1/0/4/0 0/0/2/1/0 AUTO MANUAL AUTO Partition Name winona1 winona2 winona3 Bound CPUs (A.03.xx) total = 2 min = 2 total = 2 min = 2 paths = 41,45 total = 1 min = 1 Unbound CPUs (A.03.xx) three CPUs are available Memory 1024 MB 1280 MB 1280 MB I/O LBAs 0.0 0.4 0.8 1.10 0.5 1.4 Boot Path 0.0.2.0.6.0 0.8.0.0.5.0 1.4.0.0.5.0 LAN 0.0.0.0 1.10.0.0.4.0 0.5.0.0.4.
• The vPars A.04.05 Monitor or later is required for a mixed HP-UX 11i v1/v2 vPars environment. The vPars A.04.05 Monitor supports both virtual partitions running vPars A.04.05 on HP-UX 11i v2 (11.23) and virtual partitions running vPars A.03.05 on HP-UX 11i v1 (11.11). • The vPars A.03.05 Monitor supports booting only the HP-UX 11i v1 vPars A.03.05 environment. The vPars A.03.
Table 3-2 Mixed HP-UX 11i v1/v2 vPars Feature Summary Feature vPars A.03.xx Instances vPars A.04.xx Instances vPars A.05.xx Instances Minimum vPars Version A.03.05 A.04.
The following features can be executed only from the vPars-A.05.01/11.31-OS virtual partitions: • creation, removal, and modification of a target virtual partition. The vparcreate and vparremove operations can only be performed from the vPars A.05.01/11.31-OS virtual partitions; vparmodify operations affecting other virtual partitions can only be performed from the vPars A.05.01/11.31-OS virtual partitions. Note that this only applies to performing these operations on other virtual partitions.
Table 3-4 Mixed HP-UX 11i v2/v3 vPars Environment Feature Summary Feature vPars A.05.xx instances vPars A.04.xx instances vPars A.03.xx instances Minimum vPars Version A.05.01 A.04.
keira1 keira2 • B.11.31 B.11.23 Up Up vparstatus output from a virtual partition running vPars A.04.03 in a mixed HP-UX 11i v2/v3 vPars environment: keira2# vparstatus -P Commands product information: A.04.03 Monitor product information: A.05.01 Mixed HP-UX 11i v1/v2/v3 vPars Environments in vPars A.05.03 Beginning with vPars A.05.03, you can have a mixed HP-UX 11i v1/v2/v3 vPars environment on PA-RISC systems only. A mixed HP-UX 11i v1/v2/v3 vPars environment allows you to have a vPars A.05.
• designated-admin, then no virtual partitions will be able to perform vparmodify, vparremove, or vparcreate operations on other virtual partitions. The status details reported by the vparstatus command are determined by the target virtual partition version and the vPars software version of the virtual partition issuing the command. — Cell Local Memory (CLM) and Cell Local Processor (CLP) details are displayed only when listing details from an HP-UX 11i v2 or 11i v3 virtual partition.
Features Summary The following table highlights the rules for having a mixed HP-UX 11i v1/v2/v3 vPars environment. Table 3-7 Mixed HP-UX 11i v1/v2/v3 vPars Environment Feature Summary Feature vPars A.05.xx instances vPars A.04.xx instances vPars A.03.05 instances Minimum vPars Version A.05.03 A.04.02 or later A.03.
4 Installing, Updating, or Removing vPars and Upgrading Servers with vPars This chapter addresses the following topics: • Notes, Cautions, and Other Considerations Before You Update or Install vPars • “Bundle Names” (page 70) • Ignite-UX.
For information on using the vPars commands, see the following sections in the chapter vPars Monitor and Shell Commands: • “Managing: Creating a Virtual Partition” (page 151). • “vPars Monitor: Booting the vPars Monitor” (page 130).
a. b. At the MON> prompt, type reboot If needed, interrupt the boot sequence at the BCH>, and using the primary path, boot/stand/vmunix instead of/stand/vpmon. For example: BCH> bo pri interact with IPL? y . . . ISL> hpux /stand/vmunix NOTE: The server must be in standalone mode for the patches to take effect, so do not skip this step. 3. 4. Install the firmware patch as you would in a non-vPars environment. The firmware patch will reboot your server.
Current Flow Control: Software Do you want to modify it? (Y/[N]) 5. n Indicate which terminal type you want to use, then answer “y” (yes) to confirm your change: Enter Terminal Type ([Vt100] / Hpterm): New Terminal Type: hpterm Confirm? (Y/[N]): y -> Terminal Type will be updated. 6.
Feature11i (HP-UX 11i v2 only) Required vPars enablement patches for vPars A.04.xx. This bundle can be obtained from the HP-UX Update OE DVD. When the Feature11i and vPars product bundles are in the same depot, this bundle should be automatically selected when the vPars bundle is selected. For a complete list of required patches, see the HP-UX Virtual Partitions Release Notes. T1335AC vPars A.03.
vPars-related Bundles (A.03.xx and earlier) Products related to this release of vPars are: Bundle Name Description B6826AA Partition Manager for nPartitions (parmgr) (Required for vPars A.03.xx and earlier) VPARMGR vPars GUI (vparmgr) for vPars A.03.xx and earlier (Optional) Installing and Removing vPars-related Bundles B6826AA (parmgr) The Partition Manager (parmgr) is required for installation of the vPars A.03.xx and earlier.
Setting Up the Ignite-UX Server If you are having problems with terminal emulation, see also “Ignite-UX and other Curses Applications” (page 22). For complete information on Ignite-UX, see the document Ignite-UX Administration Guide. Ignite-UX Versions vPars A.03.xx and A.04.xx have different version requirements. This version information has been moved to the HP-UX Virtual Partitions Ordering and Configuration Guide. NOTE: PA-RISC only: When using Ignite-UX version C.06.
Ignite-UX, the LAN, the LAN card, and vparboot -I NOTE: Using vparboot -p target_partition -I On both PA-RISC and Integrity, before booting a virtual partition for installation (in other words, using vparboot -p target_partition -I...), be sure that you have specified a boot disk using the BOOT attribute (io:boot_device:BOOT)for the virtual partition. This is performed during either the initial vparcreate or subsequent vparmodify commands when configuring the target virtual partition.
Note that only the vPars shell command vparboot can be used to boot a subsequent virtual partition for installation (or recovery); the vPars Monitor command vparload cannot do this. Thus, you need at least one virtual partition successfully booted to use the vparboot command. Integrity The following is the sequence of events when a vparboot -I is issued from an existing virtual partition to boot a target virtual partition for an Integrity System: NOTE: vPars A.05.
Updating from vPars A.04.xx to A.05.xx This section describes how to update an existing A.04.xx vPars on 11iv2 (11.23) environment to a vPars A.05.xx vPars environment on 11iv3 (11.31). For information on vPars and OS versions, see the HP-UX Virtual Partitions Ordering and Configuration Guide. For information on the typical time needed to update the OS version, see the HP-UX 11i v3 Installation and Update Guide. The process is similar to updating from A.03.xx to A.04.xx.
For example, the command line used in this section is: • # update-ux -s depot1:/release/1131/HPUX11i-OE-Ent.DVD HPUX11i-OE-Ent T1335CC where — depot1:/release/1131/HPUX11i-OE-Ent.DVD is the source depot — HPUX11i-OE-Ent is the Enterprise OE bundle. The OE bundle name will differ when using a different HP-UX operating environment, as shown in “OE Bundle Names for Update-UX” (page 77). — T1335CC is the vPars A.05.xx bundle.
keira1# vparstatus [Virtual Partition] Virtual Partition Name ============================== keira1 keira2 keira3 2. State ===== Up Up Up Attributes ============ Dyn,Auto,Nsr Dyn,Manl,Nsr Dyn,Auto,Nsr Boot Kernel Path Opts ======================= ===== /stand/vmunix /stand/vmunix /stand/vmunix Record the current autoboot and autosearch settings of all the virtual partitions. The update process sets autoboot to manual, so you will need to restore these settings later.
NOTE: If the BOOT and ALTBOOT disks are a mirrored pair, updating is not required on the ALTBOOT disk. Otherwise, if you wish to have the alternate boot disk up dated, after updating the OS on the primary boot path disk, boot the virtual partitions from the alternate path boot disk and repeat the update-ux procedure.
keira1 # vparmodify -p keira3 keira1 # vparmodify -p keira3 -B auto -B nosearch 10. The virtual partitions should now be running the latest vPars version. To verify this, you can login to each virtual partition and use the vparstatus command with the -P option: Example: keira1# vparstatus -P Current Virtual Partition Version: A.05.01 Monitor Version: A.05.01 [Virtual Partition OS Version] Virtual Partition Name OS Version ============================ ========== keira1 B.11.31 keira2 B.11.
Updating from vPars A.03.xx to Mixed HP-UX 11i v1/v2 vPars (A.03.05 and A.04.05) Environment This section describes how to update an existing vPars A.03.xx environment to a mixed HP-UX 11i v1/v2 vPars environment. A mixed HP-UX 11i v1/v2 vPars environment contains both vPars A.03.05/11.11 and A.04.05/11.23 virtual partitions in the same nPartition. If you wish to upgrade to a mixed HP-UX 11i v1/v2/v3 vPars environment (vPars A.03.xx, vPars A.04.xx, and vPars A.05.
Overview of the Mixed HP-UX 11i v1/v2 vPars Environment Update Process This section provides a high-level overview of the process for updating from a vPars A.03.xx environment to a mixed HP-UX 11i v1/v2 vPars environment. For details and examples of the update process see “The Update Process for Mixed HP-UX 11i v1/v2 vPars Environments: Step by Step Details” (page 87).
High-Level Description of the Mixed HP-UX 11i v1/v2 vPars Environment Update Process The following list gives a high-level description of the process shown in Figure 4-1. After backing up all virtual partitions and establishing a depot with the required HP-UX OE and vPars versions, the steps are as follows. For details and examples see “The Update Process for Mixed HP-UX 11i v1/v2 vPars Environments: Step by Step Details” (page 87). 1. Make sure that all the virtual partitions are up. 2.
— Wait for the vPars A.03.05 update to complete on all but the last virtual partition. Monitor the installation logs (such as the /var/adm/sw/swagent.log file or swinstall.log file) until the virtual partitions halt. — On the last virtual partition, update the HP-UX Operating Environment, if needed, and update the vPars bundle. 12. Make sure that all virtual partition updates have successfully completed to the point of halting, then reboot the nPartition (reboot from the vPars Monitor). 13.
Update-UX Primer The advantages of using Update-UX are 1) you can update both OE and vPars versions simultaneously, so there are fewer reboots, and 2) although you must still reboot the nPartition, you can perform these steps within a vPars environment; you do not need to boot the system into standalone mode. CAUTION: Using Update-UX Update-UX allows for both the OE and vPars bundles to be updated in the same session.
HPUX11i-OE-MC Mission Critical OE When choosing the OE, you should select the same OE that your virtual partition is running. Use the swlist command to check which OE the virtual partition is running is currently running: # swlist -l bundle | grep -i OE HPUX11i-OE-MC B.11.11.0612 HP-UX Mission Critical Operating Environment Component This shows the virtual partition is running a Mission Critical OE. vPars Bundle Names for Update-UX For vPars, the possible vPars bundles are: T1335AC vPars A.03.
The Update Process for Mixed HP-UX 11i v1/v2 vPars Environments: Step by Step Details This section describes how to update a vPars A.03.xx environment to a mixed HP-UX 11i v1/v2 vPars environment running vPars A.03.05 and A.04.05. The Update Process: Goal In the examples used in this section, we begin with three virtual partitions, all running vPars A.03.02: • The first partition, azure1, is running vPars A.03.02 (on 11.11). • The second partition, azure2, is running vPars A.03.02 (on 11.11).
4. If gWLM is in use, disable (undeploy) gWLM’s management of resources in all virtual partitions. gWLM is supported with restrictions in mixed HP-UX 11i v1/v2 vPars environments, as of the first release of vPars A.03.05 and vPars A.04.05. For details on gWLM restrictions, see “Features of Mixed HP-UX 11i v1/v2 vPars Environments” (page 58).
TIP: The parmodify command requires major path components to be separated with a slash (/). For example, 0.0.6.0.0.5.0 would be specified as 0/0/6/0/0.5.0 when using parmodify. 7. Install the latest and OS-applicable Update-UX bundle onto each virtual partition that will be updating the HP-UX Operating Environment—including all virtual partitions updating to HP-UX 11i v2 and vPars A.04.05. This does not update the operating system, only the Update-UX bundle. Use Ctrl-A to switch between consoles.
NOTE: If you are updating to vPars A.03.05, or configuring a mixed 11i v1/v2 vPars environment, you must install iCAP version 8.03 (B.11.11.08.03.00) on each HP-UX 11i v1 virtual partition. This will also install the required versions of WBEM and NParProvider and necessary patches. Installing iCAP 8.03 onto an HP-UX 11i v1 system running versions of vPars prior to A.03.05 will exhibit an error message which can be ignored, and you can proceed with updating the vPars software.
11. Update the remaining virtual partitions to vPars A.03.05. How you perform the remaining updates will depend on whether you are doing parallel or staggered updates. a. If updating all virtual partitions in parallel then perform the following steps. i. On all remaining virtual partitions: • If the HP-UX Operating Environment must also be updated, use Update-UX to install the latest OE and the vPars A.03.05 bundle to the virtual partition. In the following example the target OS will be HP-UX 11.
Monitor the installation progress until the virtual partitions halt. To monitor the log files, first login to the virtual partition being updated (for example, use telnet) and then use the tail -f command to view the current installation status being written to the /var/adm/sw/swagent.log file or swinstall.log file. 12. Make sure that all virtual partition updates have successfully completed to the point of halting, then reboot the nPartition.
azure1 B.11.23 Up azure2 B.11.11 Up azure3 B.11.23 Up azure3# vparstatus -P Current Virtual Partition Version: A.04.05 Monitor Version: A.04.05 [Virtual Partition OS Version] Virtual Partition Name OS Version State ============================ ========== ===== azure1 B.11.23 Up azure2 B.11.11 Up azure3 B.11.23 Up 17. Verify the correct vPars Monitor has been booted.
Migrating from vPars A.03.xx to Mixed HP-UX 11i v1/v2/v3 vPars (A.03.05, A.04.02 or later, A.05.03) This section provides an overview of the process for migrating from an existing vPars A.03.xx environment to a mixed HP-UX 11i v1/v2/v3 vPars environment. A mixed HP-UX 11i v1/v2/v3 vPars environment supports virtual partitions running vPars A.05.03 on HP-UX 11i v3 (11.31), virtual partitions running vPars A.04.02 or later on HP-UX 11i v2 (11.23), and virtual partitions running vPars A.03.
NOTE: In a mixed HP-UX 11i v1/v2/v3 vPars environment, all HP-UX 11i v1 vPars must be updated to vPars A.03.05. However, before vPars A.03.05 is installed, you must install iCAP version 8.03 on each HP-UX 11i v1 virtual partition. This will also install the required versions of WBEM and NParProvider and necessary patches. Installing iCAP 8.03 onto an HP-UX 11i v1 system running versions of vPars prior to A.03.
Updating from vPars A.04.xx to Mixed HP-UX 11i v2/v3 vPars (A.04.xx and A.05.xx) Environment This section describes how to update an existing A.04.xx vPars environment to a mixed HP-UX 11i v2/v3 vPars environment; a mixed HP-UX 11i v2/v3 vPars environment contains both vPars A.04.xx/11.23 and A.05.xx/11.31 virtual partitions in the same nPartition. For information on using a mixed HP-UX 11i v2/v3 vPars environment, see “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.xx” (page 60).
you can perform these steps within a vPars environment; you do not need to boot the system into standalone mode. CAUTION: Using Update-UX Update-UX allows for both the OE and vPars bundles to be updated in the same session. To simultaneously update both the OE and vPars bundles in the same session, they both must be in the same source depot. If you update from a depot which does not contain the vPars bundle, your disk will no longer boot in vPars mode.
Note that in a mixed HP-UX 11i v2/v3 vPars environment, the vPars running A.04.xx must be running version A.04.02 or later. Therefore, the “Revision” field in the depot should be A.04.02 or greater. Using swlist, we can find the revision number for the vPars A.04.xx bundle on the depot. # swlist -d @ depot1:/release/1123/HPUX11i-OE-Ent.DVD | grep T1335BC T1335BC A.04.02.03 HP-UX Virtual Partitions for 11.23 Changing nPartition Boot Paths To Boot the vPars A.05.
1. Make sure that all the virtual partitions are up. You can check this with vparstatus. Example: keira1# vparstatus [Virtual Partition] Virtual Partition Name ============================== keira1 keira2 keira3 2. State ===== Up Up Up Attributes ============ Dyn,Auto,Nsr Dyn,Manl,Nsr Dyn,Auto,Nsr Boot Kernel Path Opts ======================= ===== /stand/vmunix /stand/vmunix /stand/vmunix Record the current autoboot and autosearch settings of all the virtual partitions.
The nPartition number is 0. Record this information. b. Find the boot path of the boot disk of a future vPars A.05.01 virtual partition. This boot path will become the nPartition’s new PRI boot path. Since keira3 is being updated to A.05.01, let’s chose to change the nPartition’s PRI path to the boot disk of keira3. Since we have chosen keira3 as the future A.05.01 virtual partition, we need to find the boot path of keira3: keira1# vparstatus -v -p keira3 ... [IO Details] 0.0.6 0.0.6.0.0.5.
In the next step, the entire nPartition will be rebooted; if the other virtual partitions are still in progress of updating, the OS instances may be in an unknown state. NOTE: If the BOOT and ALTBOOT disks are a mirrored pair, updating is not required on the ALTBOOT disk. Otherwise, if you wish to have the alternate boot disk updated, after updating the OS on the primary boot path disk, boot the virtual partitions from the alternate path boot disk and repeat the update-ux procedure.
d. Once the PRI path has been successfully changed, set the mode to back to vPars. • On Integrity: keira# vparenv -m vPars • e. On PA-RISC, no mode setting is required. Reboot the nPartition. keira# shutdown -ry 0 9. If needed (depending upon how your nPartition’s autoboot configuration is set up), interrupt the nPartition boot process and load the vPars Monitor.
keira3# vparstatus -m Console path: No path as console is virtual Monitor boot disk path: 0.0.6.0.0.5.0 Monitor boot filename: /stand/vpmon Database filename: /stand/vpdb ... The boot disk path shown is from a vPars A.05.01 virtual partition. 14. Convert base memory to float memory. vPars A.04.xx uses only base memory; therefore, when updating to vPars A.05.xx from A.04.xx, all memory will be converted as base memory. There is no method to convert the memory to float during the update process.
For information on the typical time needed to update the OS version, see the HP-UX 11i v2 Installation and Update Guide. CAUTION: Using Update-UX Update-UX allows for both the OE and vPars bundles to be updated in the same session. To simultaneously update both the OE and vPars bundles in the same session, they both must be in the same source depot. If you update from a depot which does not contain the vPars bundle, your disk will no longer boot in vPars mode.
keira1 keira1 keira1 keira1 # # # # vparmodify vparmodify vparmodify vparmodify -p -p -p -p keira2 keira2 keira3 keira3 -B -B -B -B manual nosearch manual nosearch Note that the -B nosearch option is valid for only vPars A.03.02 and later. If you are using an earlier version of vPars, you can skip thevparmodify ... -B nosearch command. 4. Install the latest Update-UX bundle onto each virtual partition (use Ctrl-A to switch between consoles).
NOTE: If the BOOT and ALTBOOT disks are a mirrored pair, updating is not required on the ALTBOOT disk. Otherwise, after updating the OS on the primary boot path disk, boot the virtual partitions from the alternate path boot disk and repeat the update-ux procedure.
NOTE: To update to vPars A.03.05, you must update HP-UX to the HP-UX 11.11 December 2006 release. The vPars A.03.05 vPars Monitor (vpmon) requires that all vPars be running vPars A.03.05. Earlier vPars releases are not supported by the vPars A.03.05 vpmon. NOTE: If you are updating to vPars A.03.05, or configuring a mixed 11i v1/v2 vPars environment, you must install iCAP version 8.03 (B.11.11.08.03.00) on each HP-UX 11i v1 virtual partition before updating to vPars A.03.05.
MON> vparload -all When the virtual partitions are booted, they will continue and complete their update processes. After this is completed, you can access the login prompt for each virtual partition. Login as root and continue to the next step. 11. Restore the virtual partition autoboot and autosearch settings to the original settings that you previously recorded. Use the vparmodify -p vpname -B setting command, where vpname is the virtual partition name and setting is the autoboot or autosearch setting.
7. On each virtual partition, repeat Step 4 to install the new vPars bundle on each boot disk of each virtual partition (you do not need to reboot the hard partition). Because the boot disk used to boot in standalone mode in Step 3 already has the new vPars bundle (this was installed during Step 4), you can exclude this step for the boot disk at the primary path. You must install the new vPars bundle on each virtual partition before putting the virtual partitions back into production.
NOTE: If you have previously applied any patches specific to vPars, you will need to re-apply those patches to the vPars product. Upgrading Integrity Servers from the sx1000 to sx2000 Chipset You can upgrade the following Integrity servers from the sx1000 to sx2000 chipsets: • rx7620 to rx7640 • rx8620 to rx8640 • Integrity Superdome To perform the hardware upgrade, follow the process documented in the hardware upgrade manual for your server. CAUTION: Upgrade Notes • vPars A.04.
Table 4-1 rx7620 to rx7640 Hardware Path Changes rx7620 Path rx7640 Path Description 1/0/1/1/0/1/1.6 1/0/1/1/0/4/1.6 Top right HDD using A6794A or AB290A 0/0/0/3/0.6 0/0/0/3/0.6 Bottom left HDD using MP/SCSI 0/0/0/3/0.5 0/0/1/1/0/4/1.5 Bottom right HDD using MP/SCSI or AB290A 1/0/0/3/1.x 1/0/0/3/1.x Internal DVD/tape (x=2 for DVD, x=3 for DAT) 0/0/0/3/1.
Upgrading HP 9000 Servers from the sx1000 to sx2000 Chipset You can upgrade the following HP 9000 servers from the sx1000 to sx2000 chipsets: • rp7420 to rp7440 • rp8420 to rp8440 • HP 9000 Superdome To perform the hardware upgrade, follow the process documented in the hardware upgrade manual for your server. CAUTION: Upgrade Notes • vPars A.03.04 is required for vPars running on HP 9000 servers with the sx2000 chipset.
Table 4-4 rp7420 to rp7440 Hardware Path Changes (continued) rp7420 Path rp7440 Path Description 1/0/0/3/1.x 1/0/0/3/1.x Internal DVD/tape (x=2 for DVD, x=3 for DAT) 0/0/0/3/1.2 Bottom slimline DVD, if present 1/0/1/1/0/6/0 Primary LAN 1/0/1/1/0/6/1 Secondary LAN 0/0/1/1/0/6/0 Primary LAN 0/0/1/1/0/6/1 Secondary LAN 1/0/1/1/0/4/0.x external SCSI (A6794A/AB290A) 1/0/1/1/0/4/1.x external SCSI (AB290A), shared with internal HDD 0/0/1/1/0/4/0.x external SCSI (A6794A/AB290A) 0/0/1/1/0/4/1.
Upgrading Backplanes from PCI to PCI-X If you upgrade from the PCI to PCI-X backplane with the following server upgrades: • rp7410 to rp7420 • the rp8400 to rp8420 • Superdome the hardware paths of the I/O devices will change. The I/O device paths are in the format • cell/sba/lba/device/function.target.lun When changing from the PCI to PCI-X backplane, the device in the hardware paths will change from 0 to 1. So, if a hardware path before the upgrade was • 1/0/8/0/0.6.
BCH> bo lan.ww.xx.yy.zz install Interact with IPL: n 2. Using the Ignite-UX server, install HP-UX, desired patches, the Quality Pack bundle, the vPars bundle, and the desired vPars-related bundles onto the disk that will be the boot disk of the first virtual partition. NOTE: So that the TERM variable will always be set correctly, you should ensure that the first virtual partition owns the hardware console port. For more information, see “Assigning the Hardware Console LBA” (page 55). 3.
# vparboot -p winona2 -I ww.xx.yy.zz,/opt/ignite/boot/Rel_B.11.11/WINSTALL You will see a message similar to the following: winona2 loaded b. c. Press Ctrl-A until you see the console of the target partition. The console will display the Ignite-UX installation interface. Enter the boot disk path, lan info, hostname, and IP of the target partition into the Ignite-UX interface and install HP-UX, desired patches, the Quality Pack bundle, the vPars bundle, and the desired vPars-related bundles.
NOTE: lanboot information Note that lanboot will show only the LAN cards that are supported for boot with your existing configuration. If the card(s) you expect to see are not displayed, it may be necessary to issue a reconnect -r at the EFI prompt. Then try lanboot select again. Example: Shell> reconnect -r Shell> map -r 3. Using the Ignite-UX server, install the necessary bundles.
# vparboot -p -I [ [-d dbprofile_name]| [-s ignite_ux_server_ip [-c client_ip -g gateway_ip -m subnet_mask] -b boot_file [-o optional_data]]] For our example, if the target partition is keira2, execute the following command from keira1: # vparboot -p keira2 -I or vparboot -p keira2 -I -s 17.2.165.152 -c 17.2.163.92 -g 17.2.165.240 -m 255.255.248.0 -b /opt/ignite/boot/nbp.efi -o IINSTALL The syntax for vPars A.05.
NOTE: So that the TERM variable will always be set correctly, you should ensure that the first virtual partition owns the hardware console port. For more information, see “Assigning the Hardware Console LBA” (page 55). • Integrity Shell> fs0: fs0:\> hpux HPUX> boot vmunix 3. Use ioscan to verify the hardware addresses in your virtual partition plan: # ioscan 4. Create the virtual partitions using the information you prepared in the virtual partition plan.
If you are at the console of winona3, use Ctrl-A to toggle to another virtual partition. CAUTION: Remove the vPars product only at the product level (VirtualPartition). Do NOT remove the vPars product at the bundle level (T1335AC or VPARSBASE). Recommended kernel patches are included in the vPars bundle; if the bundle is removed, these kernel patches will also be removed. For more information on bundles and patches, see the Patch Management Guide for HP-UX 11.x at http://docs.hp.com.
5 vPars Monitor and Shell Commands This chapter covers: • Using Integrity systems — Setting Modes — EFI to Hardware Path Mappings • Using the vPars Monitor — Booting the vPars Monitor — Accessing the vPars Monitor Prompt — Using vPars Monitor Commands • Using the vPars Commands — vPars Manpages — vPars Commands Logging — Obtaining vPars Monitor and Hardware Resource Information • Managing the Virtual Partitions — Creating a Virtual Partition — Booting a Virtual Partition — Shutting Down or Rebooting a
Notes on Examples in this Chapter Syntax of Example Commands The example commands at the Unix shell level in the following section use the following syntax: where the shell prompt consists of the hostname of the current virtual partition and the hash sign (#).
NOTE: If any of the following conditions occur, the OS must be booted in nPars mode: — An nPartition is reconfigured, by adding, deleting, or moving CPUs or cells, — The nPartition’s NVRAM is cleared, or — Hyperthreading is turned on for the first time. Once booted to an HP-UX shell, use the vparenv command, described below, to change the mode to vPars.
• To set the mode to vPars and then immediately reboot the nPartition into vPars mode: Shell> fs0: 1 fs0:\> vparconfig reboot vPars 1 2 • First access the disk. Then execute the vparconfig command. To set the mode to nPars and then immediately reboot the nPartition into nPars mode Shell> fs0: 1 fs0:\> vparconfig reboot nPars 1 2 • 2 2 First access the disk. Then execute the vparconfig command. EFI: parconfig [mode[-n]] where mode has the value of only nPars.
MON> reboot nPars The reboot nPars command sets the mode and reboots the system. • If you are at EFI shell prompt, use the following EFI utility to switch to either nPars or vPars mode: Shell> fsN: fsN:\> vparconfig reboot mode Since vparconfig is not a built-in EFI shell command, you must go to the disk to execute vparconfig. For example, to switch to vPars mode: Shell> fs0: 1 fs0:\> vparconfig reboot vPars 1 2 2 Access the EFI partition of the disk. Set the mode and reboot the system.
CAUTION: • When you set the mode to vPars for the first time on a system, you must use vparenv. When a vPars database does not exist on a system, first boot into nPars (standalone) mode, create the vPars database, and then use vparenv -m vPars to switch the mode to vPars. If vparconfig reboot vPars is used and vparenv -m vPars has not previously been executed on the system, it may not be possible to boot vPars.
To update the EFI path of a boot disk in the vPars database (for example, after creating a boot disk mirror), execute vparefiutil -u (-u for update) on each virtual partition. Other examples of when you should use vparefiutil include: • For a specific HP-UX hardware path, if there is no EFI path mapping, the vparboot and vparload commands will fail with the following error message: Primary boot path not found. Internal error in setting up vPars variables. "vpar" load failed.
For more information on vparefiutil and all the possible options, see the manpage vparefiutil(1M). CAUTION: It is recommended to use the documented procedure of using vparboot -I to create the virtual partitions so that users do not have to use vparload -E. For information on the vPars Monitor command vparload, see the vPars Monitor manpage vpmon(5). vparload -E works in a trial and error fashion, meaning you may have to serially attempt different disk indices.
Following are some scenarios where you may need to perform additional actions if the EFI path to hardware path mappings are not up to date in the vPars database:: • Creating an alternate vPars database while in vPars mode.
# setboot -a mirror_disk_hw_path • Execute the vparefiutil command on the new disk. # vparefiutil -u [-H mirror_disk_hw_path] • Booting from a recently added boot disk. Problem: If you add a boot disk at a known hardware path, it may not be possible to immediately boot from this new disk. Solution: • If the EFI signature of the disk is known, the vparload -E command can be used to boot from the disk.
the other CPUs to create a multi-CPU server. Typically, the CPU with the lowest numbered hardware path address (belonging to the core cell for nPartitionable systems) is the monarch CPU. To see the lowest numbered hardware path, on a non-vPars server use ioscan, or on a vPars server use the vPars Monitor command scan. • A.04.xx and A.05.xx: When any CPU is available, you will see the MON> prompt.
Example: — If you have a backup copy of the partition database in the file /stand/vpdb.backup, you can read the database configuration information using: MON> readdb /stand/vpdb.backup Notes: — This command can only be used when the vPars Monitor /stand/vpmon is booted and the default partition database (/stand/vpdb) does not exist, the alternate partition database as specified in the -D option of /stand/vpmon does not exist, or the database file read is corrupt.
MON> vparload -p winona2 -B 0.8.0.0.2.0 Note: — -b kernelpath allows you to change the target kernel for only the next boot of partition_name. If you wish to make a permanent change to the partition database, use the vparmodify command. For example, to change the partition database information so that winona2 always boots using /stand/vmunix.other: # vparmodify -p winona2 -b /stand/vmunix.other See the vparmodify(1M) manpage for more information on modifying the partition database. (vPars A.04.
is rebooted. If Reboot for Reconfiguration has been set in error, the clear_pending command clears it, enabling virtual partition boots. • help help or ? lists all vPars Monitor commands • lifls • getauto lists the files in the LIF area displays the contents of the AUTO file in the LIF area Example: — MON> getauto hpux /stand/vpmon • log displays the contents, including warning and error messages, of the vPars Monitor log.
• toddriftreset resets the drifts of the real-time clock. Use this command if you reset the real-time clock of the hard partition at the BCH prompt. For brief information, see “Real-time clock (RTC)” (page 23). • vparinfo[partition_name] This command is for HP internal use only. vPars Monitor: Using the vPars Monitor Commands from ISL or EFI You can specify any of the vPars Monitor commands either at the vPars Monitor prompt (MON>) or at the ISL prompt (ISL>).
date hostname vPars_command_name[pid]: user username: vPars_command_line_text date hostname vPars_command_name[pid]: exit status exit_status where • vPars_command_name is the name of the vPars command which is sending messages to syslog. • username is the name returned by getlogin(). If no username is given by getlogin(), the effective username or id will be used. • vPars_command_line_text is the vPars command line text as typed by the user. • pid is the pid (Process ID) of the command invocation.
• • Commands will be logged whether executed on the vPars database in memory, an alternate database, or in standalone mode. The command line text will be logged on only the partition from which the command was executed. The logging of the command will not be duplicated to the target syslog file (the syslog file of the target virtual partition. For example, if the vparmodify command is executed from winona1 with the target partition being winona2 (winona1# vparmodify -p winona2 ...
Table 5-2 Virtual Partition States (continued) State Description shut The virtual partition is shutting down gracefully. Once the partition is shutdown, the state moves to down. down The virtual partition is down. crash The virtual partition is crashing because of a panic (HPMC, TOC, etc.). Once the partition has completed crashing, the state moves to down. hung The virtual partition is not responding. N/A The virtual partition is in a database file that is not active, so it has no state.
vparstatus: Summary Information Use vparstatus with no options. Examples • vPars A.03.
vparstatus: Verbose Information Use vparstatuswith verbose (-v) option. Examples • vPars A.03.xx on a rp7400: winona1# vparstatus -p winona2 -v [Virtual Partition Details] Name: winona2 State: Up Attributes: Dynamic,Autoboot Kernel Path: /stand/vmunix Boot Opts: [CPU Details] Min/Max: 1/8 Bound by User [Path]: 41 45 Bound by Monitor [Path]: Unbound [Path]: 97 [IO Details] 0.8.0.0.5.0 0.8 1.10 BOOT [Memory Details] Specified [Base /Range]: (bytes) (MB) Total Memory (MB): 1280 • vPars A.04.
ILM, Monitor-assigned [Base /Range]: (bytes) (MB) ILM Total (MB): 1024 ILM Granularity (MB): 128 CLM, user-assigned [CellID Base /Range]: (bytes) (MB) CLM, Monitor-assigned [CellID Base /Range]: (bytes) (MB) CLM (CellID MB): CLM Granularity (MB): • 128 vPars A.05.
vparstatus: Available Resources Use vparstatuswith available resources (-A) option. This shows the resources not assigned to any virtual partitions. Examples • A.03.xx on a rp7400 (non-nPartitionable server) winona1# vparstatus -A [Unbound CPUs (path)]: [Available CPUs]: 101 109 2 [Available IO devices (path)]: [Unbound memory (Base /Range)]: (bytes) (MB) [Available memory (MB)]: 256 1.2 • 0x40000000/256 A.04.xx on a rp7420 (nPartitionable server) keira1# vparstatus -A [CPUs (path)]: 0.11 0.12 0.
1.13 1.14 1.15 [CLP (CellID Count)]: [Available CPUs]: 0 2 1 5 3 [Available I/O devices (path)]: 0.0.4 0.0.6 0.0.10 0.0.12 0.0.14 1.0.1 1.0.2 1.0.6 1.0.8 1.0.10 1.0.
vparstatus: CPU Information on vPars A.04/A.05 While a virtual partition is in the down state, no specific CPU is assigned to the virtual partition as the boot processor but one is allocated by the vPars Monitor if needed (there are no CPUs assigned to the virtual partition). The boot processor is determined when the virtual partition is booted. Note that the output does not determine which commands were issued; different commands can be used to arrive at the same vparstatus output.
Table 5-4 possible commands to arrive at vparstatus output another set of possible commands in sequence to create vparstatus output vparstatus output (final) keira1 # vparstatus -p keira1 [Virtual Partition Details] Name: keira1 State: Up Attributes: Dynamic,Autoboot,Autosearch Kernel Path: /stand/vmunix Boot Opts: -v # vparboot -p keira1 (assume I/O and memory have been assigned so that keira1 can boot. at this point the cpu assigned by hw_path (1.12) is the only CPU, so it becomes the boot processor.
vparstatus: Dual-Core CPUs You can see the sibling and virtual partition assignment using vparstatus-d. If you do not have a dual-core system, the output will show dashes (-) for the sibling and assignment information. Example # vparstatus -d CPU Cell Config Sibling Information path CPU HPA ID Status Assigned to Path /vPar name ===== ================== ==== ====== ================== ======================= 0.10 0xfffffffffc078000 0 E vpuma02 0.11 0xfffffffffc07a000 0 E vpuma01 0.
vparstatus: Pending Migrating CPUs Operations Migrating CPUs may not occur instantaneously. If a virtual partition has a pending (in other words, still in progress) addition or deletion of one or more CPUs, the letter p will be displayed next to the number of CPUs in the summary output and the words (migration pending) will be displayed in the detailed output: Example winona1# vparstatus . . .
vparstatus: Pending Migrating Memory Operations Migrating memory may not occur instantaneously. If a virtual partition has a pending (in other words, still in progress) addition or deletion of memory, the letter p will be displayed next to the total ILM in the summary output and the words (Migration pending) will be displayed in the detailed output: Example • winona1# vparstatus ... [Virtual Partition Resource Summary] ...
vparstatus: Base and Float Memory Amounts With vPars A.05.xx, you can assign ILM and/or CLM memory as either base or float. The verbose (-v) output of vparstatus shows how much is float relative to the total ILM and CLM memory that is assigned. # vparstatus -p keira4 -v ...
vparstatus: Pending nPartition Reboot for Reconfiguration On an nPartitionable system, if the nPartition has a pending Reboot for Reconfiguration, the vparstatus output will show the following message: Note: A profile change is pending. The hard partition must be rebooted to complete it.
vparstatus: vPars Monitor and Database Information Beginning with vPars A.03.02, the -m option displays the console path, the hardware path from which the vPars Monitor was booted, the fleshiest path of the vPars Monitor, and the vPars database file that is being used by the vPars Monitor. Beginning with vPars A.04.01, memory ranges used by the vPars Monitor and firmware are also displayed. Examples • vPars A.03.02: # vparstatus -m Console path: 0.0.2.0 Monitor Boot disk path: 0.0.1.
use the corresponding vparcreate command line options: Resource or Attribute vparcreate Option virtual partition name is winona2 -p winona2 three total CPUs -a cpu::3 of which two are bound CPUs and a maximum of four CPUs -a cpu:::2:4 at hardware paths 41 and 45 -a cpu:41 -a cpu:45 1280 MB of memory -a mem::1280 all hardware where the LBA is at 0/8 -a io:0.8 all hardware where the LBA is at 1/10 -a io:1.10 hardware at 0/8/0/0.5.0 as the boot disk -a io:0.8.0.0.5.
Example To remove a virtual partition named winona2: 1. If the virtual partition is running, shutdown the virtual partition: winona2# vparstatus winona2# shutdown -h 2.
Booting a Virtual Partition To boot a single virtual partition, use either the vPars Monitor command vparload or the shell command vparboot. (To shutdown a booted virtual partition, see “Shutting Down or Rebooting a Virtual Partition” (page 154)).
After winona1 is shutdown, the virtual partition is in the down state. For more information, see “Virtual Partition States” (page 137). • To reboot the virtual partition winona1: winona1# vparstatus winona1# shutdown -r NOTE: — If a virtual partition has its autoboot attribute set to MANUAL, the virtual partition will only halt and will not reboot when the command shutdown -r (or reboot -r) is given.
When to Shutdown All Virtual Partitions The only times you need to shutdown all the virtual partitions within a hard partition are when: • • • a hardware problem or nPartition modification requires the nPartition to be down. Note that PCI OL* is supported on vPars A.03.xx and A.04. the entire hard partition hangs. This might be a problem with the vPars Monitor.
This command controls power enable to a hardware device. B - Cabinet C - Cell I - IO Chassis Select Device: c Enter cabinet number: 0 Enter slot number: 6 The power state is ON for the Cell in Cabinet 0, Slot 6.
NOTE: • To modify stable storage, you must either: — go into standalone/nPars mode and use setboot or parmodify — within the vPars environment on PA-RISC nPartitionable servers, use parmodify (parmodify is not supported from within the vPars environment on Integrity servers — go to the BCH for PA-RISC or EFI Shell for Integrity systems For more information on using the above firmware or HP-UX commands, see the document nPartition Administrator’s Guide, Managing Systems and Workgroups (11.11, 11.
Table 5-5 Boot Attempt Results of the autoboot and autosearch Values autoboot value autosearch value resulting boot attempt manual nosearch no booting of the target virtual partition is attempted. auto nosearch only the primary path is attempted auto search attempt to boot the primary path; if boot fails, attempt to boot the alternate path.
Setting the Primary or Alternate Boot Paths In the examples below, suppose you want the virtual partition winona2 to have its primary boot disk at 0/8/0/0.5.0 and its alternate boot path at 0/8/0/0.2.0. Using setboot Because setboot affects only the virtual partition from which you execute the command, execute these commands from winona2. • To set the primary boot path: winona2# setboot -p 0/8/0/0.5.0 • To set the alternate boot path: winona2# setboot -a 0/8/0/0.2.
Using Primary and Alternate Paths with nPartitions The vPars database and the nPartition complex profile are entirely separate. Therefore, a change in the vPars database does not change any complex profile data. A change in the primary or alternate paths in the vPars database does not change the primary or alternate paths in the complex profile. To change the primary or alternate paths for both a virtual partition and its nPartition, you must change the paths for each separately.
. . . [IO Details] 0.0.6 0.0.6.0.0.5 0.0.0 0.0.4 0.0.2 0.0.6.0.0.4.0 0.0.6.0.0.5.0 0.0.6.0.0.6.0 ALTBOOT BOOT but note that the nPartition’s alternate path has not changed: # parstatus -p0 -V [Partition] Partition Number Partition Name Status IP address PrimaryBoot Path Alternate Boot Path HA Alternate Boot Path : : : : : : : 0 npar0 active 0.0.0.0 0/0/6/0/0.5.0 2/0/14/0/0.6.0 0/0/6/0/0.5.0 Changing the nPartition’s Path (Complex Profile Data) To change the nPartition’s alternate path to 0/0/6/0/0.4.
Booting Using the Primary or Alternate Boot Paths To boot winona2 using the primary path: winona1# vparboot -p winona2 -B pri However, because the primary boot path is the default, you can omit the -B portion: winona1# vparboot -p winona2 To boot winona2 using the alternate path: winona2# vparboot -p winona2 -B alt NOTE: • Setting a path using vparmodify requires the target virtual partition to be down; setboot does not.
On a vPars server, to get the same effect when the partition winona2 is booted, modify the partition database using -b (boot path): # vparmodify -p winona2 -b "/stand/vmunix.other" NOTE: For HP-UX 11i v2 (11.23) systems, alternate kernels are in /stand/ alternate_config/ On a vPars server, the HP-UX command mkboot does modify the LIF’s AUTO file. However, on a vPars server, what is booted initially is the vPars Monitor; then the vPars Monitor boots the virtual partitions.
Autobooting the vPars Monitor and Virtual Partitions You can setup the vPars Monitor and all virtual partitions to boot automatically at power up. To do this, make sure the following four conditions are met: 1. The hard partition’s primary and alternate boot paths point to the boot disks of different virtual partitions. For example, to set the primary and alternate boot paths at BCH or EFI: pa pri 0/0/2/0.6.0 pa alt 0/8/0/0.5.0 2. The autoboot flag in stable storage is set to ON.
NOTE: For Superdome and other nPartitionable servers, you must use the boot device path "path flags" to set automatic booting past the BCH for an nPartition. See the manual HP System Partitions Guide for more information, including the proper configuration of paths for an nPartition. When booting multiple virtual partitions automatically, the sequence for booting is not deterministic, and booting a sequence of virtual partitions automatically is not supported.
1. Turn off autoboot for the target partition: winona1# vparmodify -p winona2 -B manual 2. Attempt to reset the target partition with the -t option (soft reset): winona1# vparreset -p winona2 -t 3. If it still appears to be hung, reset it with the -h option (hard reset): winona1# vparreset -p winona2 -h 4. Continue verifying the state until vparstatus shows that winona2 is in the down state: winona1# vparstatus -p winona2 -v | grep -E "Name|State" Name: winona2 State: down 5.
From HP-UX shell prompt From the running partition winona1: winona1# vparboot -p winona2 -o "-lm" Overriding Quorum In LVM, when the root disk is mirrored, the server can only activate the root volume group, which contains the OS instance, when the majority of the physical volumes in a root volume group are present at boot time. This is called establishing a quorum. Sometimes, you may want to boot an OS instance regardless of whether a quorum is established.
3. Make sure that the boot and swap logical volumes are on the same device. CAUTION: If the boot and swap logical volumes are not on the same device, do not proceed with these instructions. You will need to contact HP for assistance. Preparation Before changing the hardware path of the boot device: 1. Create a mapfile for the root volume group. Keep the mapfile in the root (/) directory, so that it is accessible during single user mode boot. vgexport -p -m /mapfile.vg00 /dev/vg00 2.
5. Import the root volume group (vg00). For example: vgimport -m /mapfile.vg00 /dev/vg00 /dev/dsk/c1t1d0 /dev/dsk/c1t1d1 where the device filenames are obtained from the ioscan and vgscan above 6. Activate the root volume group (vg00): vgchange -a y /dev/vg00 You may also have to cleanup and prepare LVM logical volume to be root, boot, primary swap, or dump volume as follows: lvrmboot lvlnboot lvlnboot lvlnboot lvlnboot mount 7.
To simulate a soft reset on only one virtual partition, from a running partition, use vparreset with the -t (for TOC) option. For example, if winona2 is hung, we can execute vparreset from the running partition winona1: winona1# vparreset -p winona2 -t The target virtual partition either shuts down or reboots according to the setting of the autoboot attribute of that virtual partition. Other virtual partitions are unaffected when one virtual partition is reset.
Memory 1600 MB 1600 MB I/O Paths (LBAs) 0.0 0.4 0.8 1.10 1.2 Boot Path 0.0.2.0.6.0 0.8.0.0.5.0 LAN 0.0.0.0 1.10.0.0.4.0 Autoboot AUTO AUTO To create and boot using an alternate partition database, perform the following: 1. Create the partition configuration and alternate partition database file. winona1# vparcreate -p winsim1 -D /stand/vpdb.sim -a cpu::4 -a cpu:::4 -a mem::1600 -a io:0.0 -a io:0.4 -a io:0.0.2.0.6.0:BOOT winona2# vparcreate -p winsim2 -D /stand/vpdb.
This change will be synchronized to the local copies of /stand/vpdb.sim. (If /stand/vpdb.sim does not exist, as in this case on winsim2, the file will be automatically created during synchronization). 4. To return to using /stand/vpdb, do the same steps as above, except on the ISL command line in Step 3 is: ISL> hpux /stand/vpmon -a By default, the file /stand/vpdb is read as the partition database file.
6 CPU, Memory, and I/O Resources (A.05.
• • • “I/O: Concepts and Functionality” (page 176) “I/O: Adding or Deleting LBAs” (page 178) “I/O: Allocation Notes” (page 180) I/O: Concepts and Functionality With vPars, you allocate I/O resources at the LBA level. LBA Local Bus Adapter SBA System Bus Adapter System, Cells, SBA, LBA, Devices and Relationships On a server, an I/O device communicates to the system through the LBA and SBA. The path looks like Figure 6-1.
Figure 6-4 vPars Allocates at LBA Level not SBA Level Syste m SBA 0 LBA 0 IO Device s a LBA assignabl e to a vpa r 0/0 LBA 1 IO Device s a LBA assignabl e to a vpa r 0/1 LBA 2 IO Device s a LBA assignabl e to a vpa r 0/2 A system has multiple SBAs, but assignments remain at the LBA levels.
Figure 6-6 vPars Allocates at LBA Level not Cell Level SBA 0 LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s Cel l 0 SBA 1 Syste m SBA 0 Cel l 1 SBA 1 I/O: Adding or Deleting LBAs I/O Syntax in Brief The basic core syntax for adding or deleting I/O resources is: -a|d io:hardware_path where: -a -d hardware_path
Examples • To add all hardware using the SBA/LBA hardware path of 1/2 to an existing partition winona2: winona1# vparmodify -p winona2 -a io:1.2 • To remove all hardware with SBA/LBA 1/2 from partition winona2: winona1# vparmodify -p winona2 -d io:1.2 NOTE: The virtual partition must be in the down state to add or delete I/O resources.
I/O: Allocation Notes When planning or performing I/O allocation, note the following: • Mass Storage Stack Formats The agile view of mass storage introduced in HP-UX 11i v3 (11.31) is supported with vPars. However, the lunpath hardware path format and lun hardware path format are not supported for use on the vPars command line, and are not printed by any vPars commands.
#vparcreate -p vpar1 -a cpu::1 -a cpu:::1 -a mem::1024 -a io:0.0 -a io:0.0.2.0.6.0:BOOT where the I/O assignment is specified using the LBA level (-a io:0.0) and the boot disk is specified using the full hardware path (-a io:0.0.2.0.6.0). For an nPartitionable system, the vparcreate command would look like: # vparcreate -p vpar1 -a cpu::1 -a cpu:::1 -a mem::1024 -a io:0.0.0 \ -a io:0.0.0.2.0.6.0:BOOT where the I/O assignment is specified using the LBA level (-a io:0.0.0.
Memory: Concepts and Functionality Definitions for Assigning (Adding) Or Deleting ILM or CLM Memory Physical memory can be divided into two categories: ILM and CLM. ILM Interleaved Memory, where memory consists of blocks of memory from one or more cells of the nPartition. CLM Cell Local Memory, where memory consists of blocks of memory from only a specific cell of the nPartition. You can assign memory to a virtual partition by any of the following methods: • By size. — This uses the nPartition’s ILM.
Float Float memory can be added to as well as deleted from a virtual partition while the virtual partition is up or down. To specify float memory, you must append :float or :f to the memory assignment specification (see below). The only exception is if you are deleting a user-specified range of memory added as float, as memory ranges are unique.
NOTE: The Default is :base. When neither :base or :float is specified, the default is :base. When you add memory as :float, you must specify :float on the command line. Further, when you wish to delete float memory, you must also specify :float on the command line, for example: # vparmodify -p keira3 -d mem::256:float If you do not specify :float when adding or deleting memory, regardless of the state of the partition, the default of :base is attempted.
NOTE: WLM and Dynamically Migrating Memory in vPars If WLM is managing the target virtual partition, the WLM daemons wlmpard and wlmd should be stopped prior to execution of the vparmodify command to migrate the memory. For more information, see the WLM A.03.02 Release Notes at http://www.hp.com/go/wlm. NOTE: Granules and Memory Migration When memory is deleted from an UP virtual partition, the actual amount deleted may not be what is specified on the command line.
Memory: Assigning (Adding) or Deleting by Size (ILM) Assigning (adding) or deleting memory by specifying only size uses ILM memory.
The syntax to assign, delete, or modify an amount of CLM is: -a|d|m cell:cell_ID:mem::size[:base|float] where: -a -d -m cell_ID size base float add delete modify the cell number the quantity of memory in MBs add/delete as base memory add/delete as float memory Example • To add 1024 MB of memory as float from cell 6 to the existing partition keira2: keira1# vparmodify -p keira2 -a cell:6:mem::1024:float • You can set both ILM and CLM memory on the same partition.
Memory: Assigning (Adding) Or Deleting by Address Range Within the already allocated memory sizes, you can specify the memory address ranges using the mem:::base:range[:base|float]syntax. However, this is not recommended unless you are familiar with using memory addresses. For PA-RISC systems, you should also be familiar with the requirement that all HP-UX kernels fit within 2 GB of memory, as described in “2 GB Restriction (PA-RISC only)” (page 188). For usage information, see the vparmodify(1M) manpage.
CAUTION: Not allowing enough memory for the other partitions will cause the other partitions to not boot. You can boot the partition by freeing up enough memory for the partition to boot, such as by shutting down an active partition. If there are no memory ranges available to the partition below 2 GB, the partition will not boot. If you use the defaults of the dynamic tunables, you will not run into the 2 GB limit.
Memory: Converting Base Memory to Float Memory In vPars A.04.xx and A.03.xx, all memory is base memory, meaning this memory cannot be removed from a virtual partition while the virtual partition is up. In vPars A.05.xx, if you wish to remove memory from a virtual partition while the virtual partition is up, you will need to have that amount of memory added to the virtual partition as float.
Memory: Granularity Concepts Granularity refers to the unit size by which memory assigned to all virtual partitions in a vPars database (vpdb) can be increased or decreased. Granularity reflects only the unit size of memory and not the amount of memory that is assigned. This section briefly covers configuring memory granularity. The default granularity is 128 MB for ILM and 128 MB for CLM. However, you can specify your own granularity for CLM and/or ILM.
Memory: Granularity Issues (Integrity and PA-RISC) CAUTION: (vparcreate only) When you specify the granularity value for only one type of memory (ILM or CLM), the granularity value for the other type of memory is set using the default granularity value. For example, if you specify only -g ILM:256, the -g CLM:128 is implied where 128 is the vPars default granularity value.
Memory: Setting the Granularity Values (Integrity) Syntax The syntax for setting granularity unit size is: -g ILM|CLM:unit[:y|n] where: -g ILM|CLM unit is granularity specifies whether the unit size is applied to ILM or CLM is the granularity unit size in MBs This value must be an integral power of 2 (in other words, 2^X) and be greater than or equal to 64. specifies whether granularity unit size should be written to firmware. The default is n.
vparenv rather than vparcreate if you have more than one database with differing granularities, and wish to switch to a database with different granularity during the next vPar Monitor boot. CAUTION: The granularity values in firmware must match those in the vPars database used during the next boot of the vPars Monitor. If the granularity values in firmware do not match those in the vPars database, the virtual partitions of that database will not boot.
2. been booted successfully, this means the current firmware also has granularity values of 128 MB. You create an alternate database /stand/vpdb.alt with a granularity value of 512 MB for ILM and 256 MB for CLM. # vparcreate -D /stand/vpdb.alt -g ILM:512 -g CLM:256 -p keira1 ... 3. This writes the granularity value to the vPars database but not to firmware, which allows you to continue using the active vPars database /stand/vpdb with its 128 MB granularity value. When you wish to load /stand/vpdb.
Memory: Setting the Granularity Values (PA-RISC) Syntax The syntax for setting granularity unit size is -g ILM|CLM:unit[:y|n] where -g ILM|CLM unit is granularity specifies whether the unit size is applied to ILM or CLM is the granularity unit size in MBs This value must be an integral power of 2 (in other words, 2^X) and be greater than or equal to 64. y|n specifies whether granularity unit size should be written to firmware. The default is n. Ignored on PA-RISC.
migration (in other words, where the target partition is up), it does not apply to the vparcreate command, where the target virtual partition should never be up during the vparcreate invocation. • In the same command, you cannot have an online addition and online deletion. For example, the following are illegal: — — keira1# vparmodify -p keira2 -a cpu::2 -d cpu::1 keira1# vparmodify -p keira2 -a mem::1024 -d mem::512 You must specify each change on a separate command line.
• • “CPU: Notes on vPars Syntax, Rules, and Output” (page 203) Additional CPU Topics — “CPU: Dual-Core Processors” (page 205) — “CPU: Hyperthreading ON/OFF (HT ON/OFF)” (page 207) — “CPUs: Managing I/O Interrupts” (page 208) — “CPU: CPU Monitor (Formerly Known As LPMC Monitor)” (page 209) CPU: Concepts and Functionality NOTE: Processor Terminology Processing resources under vPars, both as input arguments and command outputs, are described as “CPUs.
CPU: Specifying Min and Max Limits The syntax to specify min and max CPUs assigned to a virtual partition is: -[a|m] cpu:::[min][:max] where: -a add (used with vparcreate or vparmodify) -m modify (used with vparmodify) min the minimum number of CPUs for the virtual partition to boot and the minimum number of CPUs that must remain assigned to the partition max the maximum number of CPUs that can be assigned to the virtual partition NOTE: The virtual partition must be in the down state to set the min or max
NOTE: CPU deletion fails when deletion by total and by CLP are given in the same vparmodify command. In this situation, the CPU deletion by total fails with the error message “vPar does not own enough Monitor-assigned CPUs to satisfy the request” although there are enough monitor-assigned CPUs. Instead, issue separate vparmodify commands to delete by total and delete by CLP.
keira1# vparmodify -p keira2 -m cpu::2 • If you would like to add 1 CPU to an existing partition, regardless of its current CPU count, you can add 1 CPU by using the -a option and setting num to 1: keira1# vparmodify -p keira2 -a cpu::1 To remove the added CPU from the partition, use the -d option and set num to 1: keira1# vparmodify -p keira2 -d cpu::1 CPU: Adding and Deleting by Total 201
CPU: Adding or Deleting by CLP (Cell Local Processor) Similar to CLM (cell local memory), CLP (cell local processor) refers to CPUs on a specific cell. The syntax to specify CLP is: -[a|d|m] cell:cell_ID:cpu::num where: -a -d -m cell_ID num add delete modify the cell ID the number of CPUs from the cell to be added to or deleted from the virtual partition. Note that the num CPUs need to be available on the cell as well as the system before they can be added.
where: -a -d hw_path NOTE: add delete the hw_path (you can find the hardware path using ioscan or vparstatus -v) The target virtual partition can be up or down when specifying by hardware path. CPUs that are added using the hardware path syntax can be deleted only by using the hardware path syntax. Adding or deleting CPUs by hardware path changes total only when the virtual partition is up (unless the operation is an addition and the specified CPU is already assigned to the partition).
• — keira1# vparmodify -p keira2 -a cpu::2 keira1# vparmodify -p keira2 -d cpu::1 — keira1# vparmodify -p keira2 -a mem::1024 keira1# vparmodify -p keira2 -d mem::512 In the same command, you cannot make changes to both memory and CPU. For example, the following are illegal: — keira1# vparmodify -p keira2 -a cpu::2 -a mem::1024 CPU: Deleting CPUs Summary • The current boot processor can not be deleted from a virtual partition. (Use vparstatus -v to determine the current boot processor.
CPU: Dual-Core Processors With the PA-8800s and other dual-core processors, there are two CPUs per socket. (On a cell board with four sockets, this allows 8 CPUs per cell board.) The CPUs that share the socket are called sibling CPUs. Splitting sibling CPUs across virtual partitions refers to assigning one sibling CPU to one partition and assigning the other sibling CPU to a different virtual partition. No noticeable performance degradation has been seen when splitting sibling CPUs.
Figure 6-7 Using Partition Manager to Determine Dual-Core Processors Determining Sibling CPUs Once you have determined that you have a dual-core system, the siblings have adjacent hardware paths. The first core’s path ends in an even number, and its sibling’s path ends in the following (odd) number.
1/0/12 1/0/14 1/5 1/6 1/10 1/11 1/14 1/15 BUS_BRIDGE BUS_BRIDGE MEMORY IPMI NPROC NPROC NPROC NPROC sv_model= 10 sv_model= 10 sv_model= 9 sv_model=192 sv_model= 4 sv_model= 4 sv_model= 4 sv_model= 4 HPA=0xffffff8110018000 HPA=0xffffff811001c000 HPA=0xfffffffffc096000 HPA=0xfffffffc300c0000 HPA=0xfffffffffc0f0000 HPA=0xfffffffffc0f1000 HPA=0xfffffffffc0f8000 HPA=0xfffffffffc0f9000 VPAR=vpar1 VPAR=NONE VPAR=ALL VPAR=ALL VPAR=vpar1 VPAR=SHARED VPAR=SHARED VPAR=SHARED where the following CPU pairs are sibl
setboot -m on|off For more information on using or setting HT ON/OFF, see the nPartition Administrator's Guide. • Although hyperthreading is supported within vPars, CPU assignments to virtual partitions remain on a per-core basis and not on a logical CPU (LCPU) basis. This means that all the vPars commands for CPUs work the same as they did in vPars A.04.xx, including using the same legacy hardware path format.
CPU: CPU Monitor (Formerly Known As LPMC Monitor) The CPU Monitor (a part of the diagnostic tool Event Monitor Services (EMS) and not a part of the vPars Monitor) is designed to monitor cache parity errors within the CPUs on the system. With its Dynamic Processor Resilience (DPR), if the CPU Monitor detects a pre-determined number of errors, the CPU Monitor will deactivate a CPU for the current boot session.
NOTE: On a vPars system, when a virtual partition goes down and contains a deconfigured or deactivated CPU, the vPars Monitor will try to decommission the CPU from use and replace it with another good CPU if possible. If this is not possible, the vPars Monitor will not allow the partition to boot until the deconfigured or deactivated CPU can be taken out of use.
Operation: Memory Addition Status: PENDING The following are the valid values for the Status: field of the vparstatus output: Table 6-2 Values for the Status field State Definition Pending The requested operation is pending. When this is the Status value, you can cancel the operation. Pass The requested operation has completed successfully. Fail The requested operation has encountered an early failure before it started on the target operating system. It will not have a valid SequenceID.
The vparstatus output shows that a pending online addition of memory has been assigned the sequenceID of 1234. 2. To cancel this pending operation, use the -C sequenceID option of the vparmodify command.
7 CPU, Memory, and I/O Resources (A.04.xx) Managing Hardware Resources • I/O Allocation (Adding or Deleting I/O Resources) • Memory Allocation (Firmware Configuration and Adding or Deleting Memory Resources) • CPU Allocation (Adding or Deleting CPU Resources) • Using iCAP (formerly known as iCOD) with vPars • CPU Monitor (deallocation and deconfiguration) NOTE: Some examples in this chapter may use a non-nPartitionable system where there is no cell in the hardware path.
NOTE: Regarding syntax and how vPars commands interpret what is specified on the command line, see “I/O: Allocation Notes” (page 217). Even if there are shortcuts in assigning LBAs, vPars assigns per LBA. In the example below, each LBA (shown in brackets) can be assigned to a different virtual partition.
Figure 7-6 vPars Allocates at LBA Level not Cell Level SBA 0 LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s Cel l 0 SBA 1 Syste m SBA 0 Cel l 1 SBA 1 I/O: Adding or Deleting LBAs I/O Syntax in Brief The basic core syntax for adding or deleting I/O resources is: -a|d io:hardware_path where: -a -d hardware_path
Examples • To add all hardware using the SBA/LBA hardware path of 1/2 to an existing partition winona2: winona1# vparmodify -p winona2 -a io:1.2 • To remove all hardware with SBA/LBA 1/2 from partition winona2: winona1# vparmodify -p winona2 -d io:1.2 NOTE: 216 The virtual partition must be in the down state to add or delete I/O resources. CPU, Memory, and I/O Resources (A.04.
I/O: Allocation Notes When planning or performing I/O allocation, note the following: • An LBA can be assigned to at most one virtual partition at any given time. When you are planning your I/O to virtual partition assignments, note that only one virtual partition may own any hardware at or below the LBA (Local Bus Adapter) level. In other words, hardware at or below the LBA level must be in the same virtual partition.
different meanings depending upon the vPars version, the type of server, and the user intent. For example, the path of x/y can mean any of the following: — sba=x, lba=y on a non-nPartitionable server running vPars A.03.01 or earlier — sba=x, lba=y on a non-nPartitionable server running vPars A.03.02 or later or A.04.xx — cell=x, sba=y on an nPartitionable server running vPars A.03.02 or later or A.04.
Memory: Assigning by Size (ILM) Assigning memory by specifying only size uses ILM memory. ILM memory is the only type of memory used in vPars A.03.xx and earlier. vPars A.04.xx and later can use either ILM or CLM memory.
NOTE: Assigning ILM or CLM memory by size only reserves the amount of physical memory the virtual partition gets. The exact physical ranges of memory the virtual partition gets is decided by the vPars Monitor when the virtual partition boots. The vPars Monitor will attempt to pick the memory ranges such that the sum of the ranges add up to the amount of ILM and CLM reserved for the partition.
Memory: Specifying Address Range Within the already allocated memory sizes, you can specify the memory address ranges using the mem:::base:range syntax. However, this is not recommended unless you are familiar with using memory addresses. For PA-RISC systems, you should also be familiar with the requirement that all HP-UX kernels fit within 2 GB of memory, as described in “2 GB Restriction (PA-RISC only)” (page 221). For usage information, see the vparmodify(1M) manpage.
Memory: Granularity Concepts Granularity refers to the unit size in which memory is assigned to all virtual partitions in a given vPars database (vpdb). Granularity reflects only the unit size of memory and not the amount of memory that is assigned. This section briefly covers configuring memory granularity. The default granularity is 128 MB for ILM and 128 MB for CLM. However, you can specify your own granularity for CLM and/or ILM.
Granularity Issues (Integrity and PA-RISC) CAUTION: (vparcreate only) When you specify the granularity value for only one type of memory (ILM or CLM), the granularity value for the other type of memory is set using the default granularity value. For example, if you specify only -g ILM:256, the -g CLM:128 is implied where 128 is the vPars default granularity value.
Granularity Memory is normally assigned to vPars in units called granules. Exceptions are described below. The granule values for CLM and ILM can be different. However, both are subject to the following rules: + MOST IMPORTANT, READ CAREFULLY. Granularity, the value of a granule specification, is not a resource. Resource assignments can be modified, even if some resource modifications require that a vPar be Down. Granularity can only be specified when creating a new database.
to load and launch the maximum supported 8 vPars. If ILM granularity is 256 MB, there are only 8 granules in the first 2 GB. The Monitor uses portions of the first one. So it will only be possible to load and launch 7 or fewer vPars. On ab Integrity server, there is no similar constraint on the maximum ILM granularity. For CLM on PA-RISC platforms, and for both ILM and CLM on Integrity systems, Hewlett-Packard recommends choosing the largest possible granularity for performance reasons.
Example 2 If the total physical memory is 100 GB, then the granularity value should be 2 GB: 100 GB / 2 GB => 50 granules Note that as seen in “Granularity Issues (Integrity and PA-RISC)” (page 223) and in the vparresources(5) manpage, memory is allocated to a virtual partition as a multiple of the granularity value. In this example, given a granularity value of 2 GB, this means that every virtual partition will have at least 2 GB (1 multiple) allocated to it.
Memory: Setting the Granularity Values (Integrity) Syntax The syntax for setting granularity unit size is: -g ILM|CLM:unit[:y|n] where: -g ILM|CLM unit is granularity specifies whether the unit size is applied to ILM or CLM is the granularity unit size in MBs This value must be an integral power of 2 (in other words, 2^X) and be greater than or equal to 64. specifies whether the granularity unit size should be written to firmware. The default is n.
When using this method, note that the -g option must be performed when creating the vPars database (in other words, when performing the initial vparcreate command). If you choose not to set a value, or if you set the value incorrectly using the initial vparcreate command, you cannot adjust it later. You must re-create the vPars database. Usage Scenarios vparcreate with the :y option The following scenario is where you would want to use vparcreate with the -g option and the:y specification: 1.
Memory: Setting the Granularity Values (PA-RISC) Syntax The syntax for setting granularity unit size is: -g ILM|CLM:unit[:y|n] where: -g ILM|CLM unit is granularity specifies whether the unit size is applied to ILM or CLM is the granularity unit size in MBs This value must be an integral power of 2 (in other words, 2^X) and be greater than or equal to 64. y|n specifies whether the granularity unit size should be written to firmware. The default is n. Ignored on PA-RISC.
Memory: Allocation Notes • • • The default memory assigned to a virtual partition is 0 MB, so you need to specify enough memory for your applications and the operating system. While there is no specific minimum base memory requirement per vpar, the HPUX kernel does require a certain amount of base memory to boot successfully. For this reason, we currently recommend that 1 GB of base memory is assigned per vpar. The more base memory a virtual partition has, the better the performance will be.
CPU: Boot Processor and Dynamic CPU Definitions Beginning with vPars A.04.01, the restrictions of bound CPUs have been removed as well as the terms bound and unbound. Now, there are two types of CPUs: boot processors and dynamic CPUs. The Boot Processor is the CPU on which the OS kernel of the virtual partition was booted. There is one boot processor per virtual partition. On booting of a virtual partition, the vPars Monitor determines which CPU becomes the boot processor.
CPU: Specifying Min and Max Limits The syntax to specify min and max CPUs assigned to a virtual partition is: -[a|m] cpu:::[min][:max] where: -a is adding (used with vparcreate or vparmodify) -m is modifying (used with vparmodify) min is the minimum number of CPUs for the virtual partition to boot and the minimum number of CPUs that must remain assigned to the partition max is the maximum number of CPUs that can be assigned to the virtual partition NOTE: The virtual partition must be in the down state to s
NOTE: CPU deletion fails when deletion by total and by CLP are given in the same vparmodify command. In this situation, the CPU deletion by total fails with the error message “vPar does not own enough Monitor-assigned CPUs to satisfy the request” although there are enough monitor-assigned CPUs. Instead, issue separate vparmodify commands to delete by total and delete by CLP.
keira1# vparmodify -p keira2 -m cpu::2 • If you would like to add 1 CPU to an existing partition, regardless of its current CPU count, you can add 1 CPU by using the -a option and setting num to 1: keira1# vparmodify -p keira2 -a cpu::1 To remove the added CPU from the partition, use the -d option and set num to 1: keira1# vparmodify -p keira2 -d cpu::1 234 CPU, Memory, and I/O Resources (A.04.
CPU: Adding or Deleting by CLP (Cell Local Processor) Similar to CLM (cell local memory), CLP (cell local processor) refers to CPUs on a specific cell. The syntax to specify CLP is: -[a|d] cell:cell_ID:cpu::num where: -a -d cell_ID num is adding is deleting is the cell ID is the number of CPUs from the cell to be added to or deleted from the virtual partition. Note that the num CPUs need to be available on the cell as well as the system before they can be added.
-a -d hw_path NOTE: is adding is deleting is the hw_path (you can find the hardware path using ioscan or vparstatus -v) The target virtual partition can be up or down when specifying by hardware path. CPUs that are added using the hardware path syntax can be deleted only by using the hardware path syntax. Adding or deleting CPUs by hardware path changes total only when the virtual partition is up (unless the operation is an addition and the specified CPU is already assigned to the partition).
Deleting CPUs Summary • • • You can delete any CPU, except the current boot processor, by specifying its hardware path. If you want to control which CPU is deleted (rather than leaving it up to the vPars Monitor), use the same method—by CLP, by hardware path, or by count—on your deletion command line that you used on your addition command line. The current boot processor can not be deleted from a virtual partition. (Use vparstatus -v to determine the current boot processor.
Activating and Deactivating CPUs When you are in standalone (PA-RISC) or nPars (Integrity) mode, you can activate CPUs using the icod_modify -a command. Then, while you are in the vPars environment or vPars mode, you can use vparmodify -a as long as you do not go above the number of Intended Active CPUs (see “Intended Active Boundary” (page 238)). When you are in the vPars environment or vPars mode, you can activate a CPU using icod_modify -a.
assigned CPUs is less than or equal to the Intended Active number, and then reboot the vPars Monitor. CPU: Using iCAP (Instant Capacity on Demand) with vPars (vPars A.04.xx and iCAP B.
CPU: Dual-Core Processors With the PA-8800s and other dual-core processors, there are two CPUs per socket. (On a cell board with four sockets, this allows 8 CPUs per cell board.) The CPUs that share the socket are called sibling CPUs. Splitting sibling CPUs across virtual partitions refers to assigning one sibling CPU to one partition and assigning the other sibling CPU to a different virtual partition. No noticeable performance degradation has been seen when splitting sibling CPUs.
Figure 7-7 Using Partition Manager to Determine Dual-Core Processors Determining Sibling CPUs Once you have determined that you have a dual-core system, the siblings have adjacent hardware paths. The first core’s path ends in an even number, and its sibling’s path ends in the following (odd) number.
1/0/12 1/0/14 1/5 1/6 1/10 1/11 1/14 1/15 BUS_BRIDGE BUS_BRIDGE MEMORY IPMI NPROC NPROC NPROC NPROC sv_model= 10 sv_model= 10 sv_model= 9 sv_model=192 sv_model= 4 sv_model= 4 sv_model= 4 sv_model= 4 HPA=0xffffff8110018000 HPA=0xffffff811001c000 HPA=0xfffffffffc096000 HPA=0xfffffffc300c0000 HPA=0xfffffffffc0f0000 HPA=0xfffffffffc0f1000 HPA=0xfffffffffc0f8000 HPA=0xfffffffffc0f9000 where the following CPU pairs are siblings: • • • • 242 CPU CPU CPU CPU 1/10 (owned by vpar1) and CPU 1/11 (unassigned) 0/
CPU: CPU Monitor (Formerly Known As LPMC Monitor) The CPU Monitor (a part of the diagnostic tool Event Monitor Services (EMS) and not a part of the vPars Monitor) is designed to monitor cache parity errors within the CPUs on the system. With its Dynamic Processor Resilience (DPR), if the CPU Monitor detects a pre-determined number of errors, the CPU Monitor will deactivate a CPU for the current boot session.
NOTE: On a vPars system, when a virtual partition goes down and contains a deconfigured or deactivated CPU, the Monitor will try to decommission the CPU from use and replace it with another good CPU if possible. If this is not possible, the vPars Monitor will not allow the partition to boot until the deconfigured or deactivated CPU can be taken out of use.
8 CPU, Memory, and I/O Resources (A.03.xx) NOTE: The A.03.xx release of vPars, and therefore this chapter, applies only to PA-RISC systems. Managing Hardware Resources • I/O Allocation (Adding or Deleting I/O Resources) • Memory Allocation (Adding or Deleting Memory Resources) • CPU Allocation (Adding or Deleting CPU Resources) • CPU Monitor (deallocation and deconfiguration) NOTE: Some examples in this chapter may use a non-nPartitionable system where there is no cell in the hardware path.
NOTE: Regarding syntax and how vPars commands interpret what is specified on the command line, see “I/O: Allocation Notes” (page 249). Even if there are shortcuts in assigning LBAs, vPars assigns per LBA. In the example below, each LBA (shown in brackets) can be assigned to a different virtual partition.
Figure 8-6 vPars Allocates at LBA Level not Cell Level SBA 0 LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s LBA 0 IO Device s LBA 1 IO Device s LBA 2 IO Device s Cel l 0 SBA 1 Syste m SBA 0 Cel l 1 SBA 1 I/O: Adding or Deleting LBAs I/O Syntax in Brief The basic core syntax for adding or deleting I/O resources is: -a|d io:hardware_path where: -a -d hardware_path
Examples • To add all hardware using the SBA/LBA hardware path of 1/2 to an existing partition winona2: winona1# vparmodify -p winona2 -a io:1.2 • To remove all hardware with SBA/LBA 1/2 from partition winona2: winona1# vparmodify -p winona2 -d io:1.2 NOTE: 248 The virtual partition must be in the down state to add or delete I/O resources. CPU, Memory, and I/O Resources (A.03.
I/O: Allocation Notes When planning or performing I/O allocation, note the following: • An LBA can be assigned to at most one virtual partition at any given time. When you are planning your I/O to virtual partition assignments, note that only one virtual partition may own any hardware at or below the LBA (Local Bus Adapter) level. In other words, hardware at or below the LBA level must be in the same virtual partition.
1. 2. 3. • The explicit specification of an LBA on a non-nPartitionable system consists of two fields: sba/lba The explicit specification of an LBA on an nPartitionable system consists of three fields: cell/sba/lba With A.03.02 and later and A.04.xx, all LBAs under a SBA are implied when explicitly specifying a SBA without specifying any LBA. Therefore, the path specified on a command line can have different meanings depending upon the vPars version, the type of server, and the user intent.
Memory: Assigning by Size (ILM) Assigning memory by specifying only size uses ILM memory. ILM memory is the only type of memory used in vPars A.03.xx and earlier. vPars A.04.xx and later can use either ILM or CLM memory.
Memory: Specifying Address Range Within the already allocated memory sizes, you can specify the memory address ranges using the mem:::base:range syntax. However, this is not recommended unless you are familiar with using memory addresses. You should also be familiar with the requirement that all HP-UX kernels fit within 2 GB of memory, as described in “2 GB Restriction” (page 252). For usage information, see the vparmodify(1M) manpage.
Memory: Allocation Concepts and Notes • • • The unit for the specified size of memory for the vPars commands is megabytes; parmodify uses gigabytes. The default memory assigned to a virtual partition is 0 MB, so you need to specify enough memory for your applications and the operating system. While there is no specific minimum base memory requirement per vpar, the HPUX kernel does require a certain amount of base memory to boot successfully.
CPU: Specifying Min and Max Limits The syntax to specify min and max CPUs assigned to a virtual partition is: -[a|m] cpu:::[min][:max] where: -a is adding (used with vparcreate or vparmodify) -m is modifying (used with vparmodify) min is the minimum number of CPUs for the virtual partition to boot and the minimum number of CPUs that must remain assigned to the partition max is the maximum number of CPUs that can be assigned to the virtual partition NOTE: The virtual partition must be in the down state to s
CPU: Bound and Unbound Definitions With vPars, there are two types of CPUs: bound and unbound. A bound CPU is a CPU that is assigned to and handles I/O interrupts for a virtual partition. Every virtual partition must have at least one bound CPU to handle its I/O interrupts. CPUs that are not assigned to any virtual partition or that are assigned to a virtual partition but do not handle its I/O interrupts are unbound CPUs. Unbound CPUs are sometimes called floater CPUs.
CPU: Adding and Removing Bound CPUs CPU Allocation Syntax In Brief To understand how to assign CPUs, you need to understand the command syntax. Below is a brief explanation of the CPU allocation syntax for the vparcreate command. For complete information, see the vparcreate(1M), vparmodify(1M), and vparresources(5) manpages. Syntax for vparcreate The core vparcreate syntax for CPU allocation includes: vparcreate -p partition_name [-a cpu::total] [-a [[-a cpu:hw_path]...
CPU: Adding a CPU as a Bound CPU All CPUs begin as not being assigned to any virtual partition, so all CPUs begin as unbound CPUs. However, you can assign CPUs as bound CPUs to the partition by specifying the min number in the -a cpu:::min command line option. Examples • To create a virtual partition winona2 with two bound CPUs: winona1# vparcreate -p winona2 -a cpu::2 -a cpu:::2 In this example, the total number of CPUs assigned to the partition is two (-a cpu::2).
NOTE: When executing any operations relating to bound CPUs (adding, modifying, or deleting), the target virtual partition must be down. Example • If the partition winona2 has two bound CPUs and you want only one bound CPU (and you do not want to add any unbound CPUs), set the total and min numbers to one: winona1# vparmodify -p winona2 -m cpu:::1 -m cpu::1 NOTE: If you set only the min number to one and leave the total number set at two, you will still have two CPUs assigned to winona2.
CPU: Adding, Removing, and Migrating Unbound CPUs For vPars A.03.xx and earlier, after min bound CPUs are assigned to a virtual partition, the quantity (total - min) CPUs are assigned to the partition as unbound CPUs. Therefore, to migrate unbound CPUs, specify total such that (total-min) is the number of unbound CPUs assigned to the target partition. Examples • To create the partition winona2 with two bound CPUs and one unbound CPU, set total to three and min to two (vPars A.03.
intctl Command The intctl command is a HP-UX tool that allows you to manage I/O interrupts among active CPUs. For HP-UX 11i v1, intctl is not installed by default with HP-UX, but you can obtain the software for intctl from the HP-UX Software Pack for 11i v1. Software Pack is available from the Software Pack DVD included with the HP-UX 11i OE DVDs or from the Software Depot website at: http://www.hp.com/go/softwaredepot For more information, see the Interrupt Migration Product Note available at http://docs.
CPU: Dual-Core Processors With the PA-8800s and other dual-core processors, there are two CPUs per socket. (On a cell board with four sockets, this allows 8 CPUs per cell board.) The CPUs that share the socket are called sibling CPUs. Splitting sibling CPUs across virtual partitions refers to assigning one sibling CPU to one partition and assigning the other sibling CPU to a different virtual partition. No noticeable performance degradation has been seen when splitting sibling CPUs.
Figure 8-7 Using Partition Manager to Determine Dual-Core Processors Determining Sibling CPUs Once you have determined that you have a dual-core system, the siblings have adjacent hardware paths. The first core’s path ends in an even number, and its sibling’s path ends in the following (odd) number.
1/0/12 1/0/14 1/5 1/6 1/10 1/11 1/14 1/15 BUS_BRIDGE BUS_BRIDGE MEMORY IPMI NPROC NPROC NPROC NPROC sv_model= 10 sv_model= 10 sv_model= 9 sv_model=192 sv_model= 4 sv_model= 4 sv_model= 4 sv_model= 4 HPA=0xffffff8110018000 HPA=0xffffff811001c000 HPA=0xfffffffffc096000 HPA=0xfffffffc300c0000 HPA=0xfffffffffc0f0000 HPA=0xfffffffffc0f1000 HPA=0xfffffffffc0f8000 HPA=0xfffffffffc0f9000 VPAR=vpar1 VPAR=NONE VPAR=ALL VPAR=ALL VPAR=vpar1 VPAR=SHARED VPAR=SHARED VPAR=SHARED where the following CPU pairs are sibl
CPU: CPU Monitor (Formerly Known As LPMC Monitor) The CPU Monitor (a part of the diagnostic tool Event Monitor Services (EMS) and not a part of the vPars Monitor) is designed to monitor cache parity errors within the CPUs on the system. With its Dynamic Processor Resilience (DPR), if the CPU Monitor detects a pre-determined number of errors, the CPU Monitor will deactivate a CPU for the current boot session.
9 nPartition Operations This section briefly covers nPartition operations when vPars are in an nPartition. For complete information on nPartitions, see the nPartition document nPartition Administrator's Guide available at http://docs.hp.com. Basic Conceptual Points on using vPars within nPartitions • • • • • Only one vPars Monitor is booted per nPartition. Virtual partitions exist within an nPartition, but they cannot span across nPartitions.
• • For more information on using the -R and -r options of the shutdown and reboot commands used in a Reboot for Reconfiguration, see “shutdown and reboot commands” (page 24). For more information, see “Shutting Down or Rebooting the nPartition (Or Rebooting the vPars Monitor)” (page 156) and the vPars Monitor command “reboot [mode]” (page 133). Setting Hyperthreading (HT ON/OFF) and cpuconfig Primer This section describes how to set HT ON/OFF for the latest dual-core processors which offer this feature.
CPU threads are turned off. • to show only the state of the threads: Shell> cpuconfig threads cpuconfig: Threads are turned off. • to turn HT ON: Shell> cpuconfig threads on cpuconfig: Threads will be on after a reset. Shell> cpuconfig PROCESSOR MODULE INFORMATION Cell ---1 Cab/ Cell Slot/ CPU Module -----0/1/0 # of Logical CPUs ------2 Speed -------1.4 GHz L3 Cache Size -----6 MB L4 Cache Size -----None Family/ Model (hex.
Cell ---1 Cab/ Cell Slot/ CPU Module -----0/1/0 # of Logical CPUs ------4 Speed -------1.4 GHz L3 Cache Size -----6 MB L4 Cache Size -----None Family/ Model (hex.) ------20/00 Processor Rev State --- ------------C0 Active CPU threads are turned off.
Reconfiguring an nPartition (Integrity) NOTE: On an Integrity server, the OS kernel in nPars mode needs to write the new CPU mapping data to certain EFI variables; in order for this to occur properly, a complete reboot in nPars mode is required after the parmodify operation has taken affect. From nPars mode: 1. Perform the changes as you would in a non-vPars environment.
Shell> fsN: fsN:\> efi\hpux\hpux /stand/vmunix 5. Once the system boots into nPars mode, the OS kernel automatically will write the correct CPU mapping data to EFI. Now you can reboot the nPartition back into vPars mode and reboot the vPars Monitor. keira# vparenv -m vPars keira# shutdown -r ... fs0:\EFI\HPUX> boot vpmon ... Reconfiguring an nPartition (PA-RISC) For the following example, the virtual partitions keira1 and keira2 exist within the nPartition 0. Only relevant output is shown. 1.
Cell ---0 Cab/ Slot ---0/0 Cell State -----------Idle 1 0/1 Active ------- Processor -------# Speed State --- -------- ----------0A 1000 MHz Idle 0B 1000 MHz Idle 1A 1000 MHz Idle 1B 1000 MHz Idle 2A 1000 MHz Idle 2B 1000 MHz Idle 0A 1000 MHz Active 0B 1000 MHz Idle 1A 1000 MHz Idle 1B 1000 MHz Idle 2A 1000 MHz Idle 2B 1000 MHz Idle Primary Boot Path: Boot Actions: 1/0/0/3/0.6 Go to BCH. HA Alternate Boot Path: Boot Actions: 1/0/0/3/0.6 Go to BCH.
. . Configuring CLM for an nPartition ILM memory can be re-configured to be CLM using the parmodify command. Then, you can assign existing available CLM to a virtual partition. For complete information on CLM and configuring cells and nPartitions, see the nPartition’s Guide. parmodify syntax The syntax for the parmodify command is parmodify -pnPar_num -mcell:[type]:[use]:[fail][:clm] where nPar_num cell type use fail clm is the nPartition number is the cell to be modified.
• • nPartition configuration rules limit the minimum amount of configured CLM memory for a cell. If you have any CLM on a cell, it must be at least 512 MB. When performing parmodify commands within a vPars environment, you will see only the cells that are within the nPartition running vPars. If you wish to add cells from outside the nPartition, you will need to be in standalone (PA-RISC) or nPars (Integrity) mode to see the other cells.
CAUTION: • If you reduce the ILM amount below that configured for all the virtual partitions in your vPars database, one or more of the virtual partitions may not boot. Be sure that there is enough CLM and ILM configured in the nPartition so that the sum of ILM and CLM memory of all your virtual partitions does not exceed the ILM and CLM in the nPartition. • New servers should be set with 100% ILM and 0% CLM. However, a firmware update or even another systems administrator can change these values.
HA Alternate Boot Path : PDC Revision : IODCH Version : Cell Architecture : CPU Compatibility : CPU Speed : 1600 MHz Core Cell : cab1,cell4 Core Cell Choice [0] : Total Good Memory Size : Total Interleave Memory: Total Requested CLM : Total Allocated CLM : 3.66 ffff Itanium(R)-based BCF-640 cab1,cell4 40.0 GB 40.0 GB 0.0 GB 0.
10 Crash Processing and Recovery Crashing and Recovery Processes • Crash Processing • Network and Tape Recovery • Expert Recovery Crash Processing Crash processing for a virtual partition is similar to the crash processing of a non-vPars OS: the OS is quiesced, portions of memory are written to disk, and in the case of vPars, resources are released to the vPars Monitor. When the vPars Monitor crashes, a vPars Monitor dump is created. By default, kernel dumps are not saved.
3. 4. 5. 6. 7. (PA-RISC only) allows you to chose an alternate device to which the vPars Monitor dump is written. The alternate device must contain the pre-allocated file /stand/vpmon.dmp. The file vpmon.dmp is automatically created in/standof a partition’s boot disk by the vPars startup script. soft resets the current hard partition4. hard resets the current hard partition.
1. (11i v2 and above) Beginning with HP-UX 11i v2 and therefore vPars A.04, the savecrash processing has changed. Instead of copying the kernel file that was in use during the crash, the directory /stand/crashconfig is copied. Therefore, prior to executing the crashconf and savecrash steps below, create the /stand/crashconfigdirectory using # kconfig -s crashconfig Or if the kernel configuration used in the last boot is different from the current kernel configuration, use the -c option.
• • • • • make_tape_recovery within a vPars-environment in conjunction with a disk-based Ignite-UX boot helper, see “Using make_tape_recovery and Dual-media Boot” (page 287) make_tape_recovery within a vPars-environment, see “Using make_tape_recovery within a vPars Environment” (page 289) golden images for recovery, see the white paper Using Golden Images with Virtual Partitions peripheral boot devices, see the white paper Booting, Installing, Recovery, and Sharing in a vPars Environment from DVD/CDROM/TAP
Using make_net_recovery within a vPars Environment Archiving Virtual Partition make_net_recovery works the same for making archives of both non-vPars and vPars systems. Recovering a Virtual Partition from a Running Virtual Partition To recover a virtual partition, perform the following from a running virtual partition. (In these examples, the partition winona1 is running and the target partition winona2 is the partition being recovered.) 1. Record the following: a.
After this virtual partition is recovered, recover the remaining partitions using the instructions in “Recovering a Virtual Partition from a Running Virtual Partition ” (page 281).
Using make_tape_recovery Outside of a vPars Environment The creation of make_tape_recovery tapes is supported on vPars-enabled servers. However, for the vPars releases that do not support tape boot, recoveries using these tapes must be done outside of the vPars environment; they cannot be used to recover a system from within a virtual partition. For example, the tape cannot be used with the vparboot -I command on PA-RISC servers. NOTE: The exception to this is using a dual-media boot.
Archiving and Recovering a Virtual Partition Archiving the Virtual Partition(s) This section describes how to create the recovery tape. NOTE: • To recover a single virtual partition from a tape, all active virtual partitions must be shutdown. The exception to this is using a dual-media boot. For information on using a dual-media boot, see “Using make_tape_recovery and Dual-media Boot” (page 287). • The make_tape_recovery command is not a backup utility. The virtual partition should be backed up separately.
7. only start automatically if the AUTO file was originally configured to do so. If not, you will boot up in standalone mode. Once the virtual partition has started you can complete any other recovery of application data, or other virtual partitions.
Archiving and Recovering a Virtual Partition Using Another Virtual Partition as the Ignite-UX Server Archiving the Virtual Partitions Using a Virtual Partition as the Ignite-UX Server The following steps describe how one or more virtual partitions can be archived using make_tape_recovery. These first steps describe how to create a disaster recovery tape. 1. 2. 3. One of the virtual partitions is an Ignite server. Its root disk is the one that is booted first, when the vPars Monitor is booted.
Using make_tape_recovery and Dual-media Boot A dual-media boot allows you to boot the target partition using another disk and then recover using the tape device. Currently with Ignite-UX, you cannot boot over the network and then recover from tape; you must boot from a disk device. Setting Up a Disk for Dual-Media Recovery IMPORTANT: Dual-media recovery is only supported if you boot the install kernel from the same version of Ignite-UX that was used to create the recovery tape.
4. 5. 6. 288 When the User Interface and Media Options screen is displayed, select Media only installation from the Source Location Options, and Advanced Installation from User Interface Options, then select OK. From the Media Installation Selection, select Boot from CD/DVD, Recover from Tape. Note that there does not need to be a CD or DVD in the server. Select OK. From the Tape Drive Selection menu, select the appropriate tape drive, and press the Enter.
Using make_tape_recovery within a vPars Environment For PA-RISC servers, vPars supports tape drives beginning with vPars A.03.03 for HP-UX 11i v1, vPars A.04.03 for HP-UX 11i v2, and vPars A.05.01 for HP-UX 11i v3. This includes recovery of a virtual partition within a vPars environment and without using an Ignite-UX server as a boot helper. For HP Integrity servers, vPars supports tape drives beginning with vPars A.04.04 for HP-UX 11i v2, and vPars A.05.
Then proceed with the recovery as normal. NOTE: The system may appear but is actually not hung when booting from tape due to the increased time it takes to load a kernel from tape instead of from disk. Expert Recovery When you are performing Expert Recovery, you need to remember the following: • • • • • 290 You can no longer read from or write to system-wide stable storage using setboot. See “Setboot and System-wide Stable Storage ” (page 157).
11 vPars Flexible Administrative Capability This chapter discusses the concepts and tasks on using the vPars Flexible Administrative Capability feature (formerly called Primary-Admin vPars Security). With this feature, you can specify vPars administration capabilities for zero, one, or more designated virtual partitions.
Terms and Definitions target partition This is the virtual partition that is affected when a vPars command is executed. For example, in the command: # vparmodify -p winona2 -a cpu::1 ... an attempt is made to add a CPU to winona2, so winona2 is the target virtual partition. The argument of the -p option is the target partition. local partition This is the virtual partition from which a vPars command is executed.
designated-admin virtual partition, the command will not be successful. designated-admin virtual partition list This is the list of virtual partitions that are currently set as designated-admin virtual partitions. If a virtual partition is in this list or added to this list, it is a designated-admin virtual partition. If a virtual partition is not in this list or is deleted from this list, it is a non-designated-admin virtual partition.
Flexible Administrative Capability Commands The flexible administrative capability commands are: • monadmin • vparadmin executed from the vPars Monitor (MON>) executed from the HP-UX shell monadmin monadmin is a vPars Monitor command that allows you to • • • • display whether the vPars flexible administrative capability feature is ON (enabled) or OFF (disabled) set or reset the flexible administrative capability mode specify a virtual partition to be added or deleted to or from the designated-admin vi
-S on|off • Sets the flexible administrative capability mode either ON (enabled) or OFF (disabled). — — — ON and OFF are not case-sensitive. The flexible administrative capability mode can be set only at the vPars Monitor prompt (MON>). By default, the mode is OFF. When the mode is set to ON, the list of designated-admin virtual partitions is empty, regardless of any previous settings.
• • • • display whether the vPars flexible administrative capability feature is ON (enabled) or OFF (disabled) change the flexible administrative capability password specify a virtual partition to be added or deleted to or from the designated-admin virtual partition list list which virtual partitions are currently in the designated-admin virtual partition list (in other words, are set as designated-admin virtual partitions) Basic Syntax and Usage vparadmin [-C] | [-a|-d partition_name] | [-l] -C • Changes
vPars Commands When the flexible administrative capability mode is ON, the vPars flexible administrative capability feature restricts the vPars commands such that you can alter another virtual partition only if you execute the command from a partition that is in the designated-admin virtual partition list. When you execute the command from a non-designated-admin virtual partition, if the command alters another virtual partition, it will not be allowed. (A.03.
For this section, let’s assume we have the virtual partitions winona1, winona2, and winona3.
Note that if the target partition is the local virtual partition, then the partition is only altering itself and not altering another partition, so this will be allowed. winona2# vparmodify -p winona2 -a cpu::1 Adding a Virtual Partition to the Designated-admin Virtual Partition List If we want the non-designated-admin virtual partition winona2 to be able to alter other virtual partitions, we need to add it to the designated-admin virtual partition list.
12 Virtual Partition Manager (A.03.xx) This chapter provides an overview of the Virtual Partition Manager (vparmgr), which provides a GUI to the vPars commands. This chapter includes: • About the Virtual Partition Manager • Starting the Virtual Partition Manager • Using the vPars Graphical User Interface (GUI) • Stopping the Virtual Partition Manager For more detailed information, see the Virtual Partition Manager online help.
Starting the Virtual Partition Manager Before you can start the virtual partition manager, vPars must be installed and running. For information on installing vPars, see “Installing, Updating, or Removing vPars and Upgrading Servers with vPars” (page 67). For information on installing the virtual partition manager, see “Installing and Removing vPars-related Bundles ” (page 72). After vPars is installed and running, you must boot at least one virtual partition to a HP-UX kernel.
This displays the status of all of the virtual partitions and available resources on the system. To perform an action on an object (a virtual partition or a set of available resources), click on the object in the list and then click the button corresponding to the action that you want to perform on that object. For more information about this screen, select the virtual partition status page from the navigation links on the left side of the Virtual Partition Manager online help.
A LBA Hardware Path to Physical I/O Slot Correspondence (PA-RISC only) This section contains a simplified PCI I/O block diagrams for the rp5470/L3000, rp7400/N4000, rp7405/rp7410, rp8400, and HP 9000 Superdome (SD16000, SD32000, SD64000) servers. These diagrams can be used to help determine which LBAs correspond to which physical I/O slots. The diagrams presented here were created due to incorrect or inaccessible PA-RISC documentation. For other supported servers, see your server manual.
rp7400/N4000 I/O Block Diagram Figure A-2 rp7400/N4000 I/O Hardware Paths rp7400 / N4000 I/O Block Diagram System Board Cabinet 00 - Cardcage 00 LBA 2 LBA 0 Slot 12 4 x PCI 1/0 0/10 Slot 5 4 x PCI LBA 10 LBA 8 Slot 11 4 x PCI 1/8 0/8 Slot 4 4 x PCI LBA 8 LBA 2 Slot 10 4 x PCI 1/2 0/12 Slot 3 4 x PCI LBA 12 LBA 4 Slot 9 4 x PCI 1/4 0/4 Slot 2 2 x PCI LBA 4 LBA 10 Slot 8 4 x PCI 1/10 0/5 Slot 1 2 x PCI LBA 5 LBA 12 Slot 7 4 x PCI 1/12 SBA 1 Slot 6 4 x PCI SBA 0 0/2 I/O B
rp8400 PCI I/O Block Diagram Figure A-4 rp8400 I/O Hardware Paths Slot_0_8 LBA 001 Rope 001 Ropes 002, 003 Slot_0_7 LBA 002 Ropes 004, 005 Slot_0_6 LBA 004 Slot_0_5 PCI Backplane Ropes 006, 007 Link to Cell LBA 006 Ropes 014, 015 LBA 014 Slot_0_4 LBA 012 Slot_0_3 Ropes 010, 011 Slot_0_2 SBA 0 Ropes 012, 013 LBA 010 Ropes 008, 009 LBA 008 Slot_0_1 Rope 000 to Core I/O 0 Superdome (SD16000, SD32000, SD64000) PCI I/O Block Diagram Figure A-5 Superdome (SD16000, SD32000, SD64000) I/O Har
B Problem with Adding Unbound CPUs to a Virtual Partition (A.03.xx) Unbound CPUs allow you to easily adjust processing power between virtual partitions. But a corner case can occur where you will not be able to add specific unbound CPU(s) without rebooting the target partition. This appendix discusses when this situation can occur and how to work around it.
Note that the entries for the unbound CPUs are only entries for unbound CPUs that can potentially be added to the partition.
vparmodify Error: “-a cpu::1”: One or more unbound CPUs were not available when virtual partition vpar3 was booted. You must shutdown the partition to add them. Although two unbound CPUs are available, their hardware paths are x03 and x04. But the kernel entries for vpar3 are x06, x07, and x08. Therefore, the command will fail.
C Calculating the Size of Kernels in Memory (PA-RISC only) One requirement of vPars is the sum of sizes of the kernels running in memory within a hard partition must be less than 2 GB. This only limits the maximum number of virtual partitions that can be created. If you use the defaults of the dynamic tunables, you will not run into this 2 GB limit. However, if you have adjusted the dynamic tunables, you can perform the calculations described in this appendix to ensure you meet this criteria.
For example, if we calculated the size of the kernel of the first OS to be 64 MB and the second OS to be 128 MB, the sum is 192 MB. 192 MB is below the 2 GB limit, so we have met the criteria and can migrate the OSs from the multiple non-vPars servers to the single vPars server. NOTE: For vPars A.04 and later, you will need to accommodate for your granularity setting by rounding memory usage to the granularity boundary.
D Memory Usage with vPars in nPartitions This section discusses various usages of memory for vPars within nPartitions. Within a vPars environment, memory is used not only by the HP-UX OS and applications, but can also be used by the following: • nPartition Firmware • Firmware Partitions (fPars) on Integrity servers • vPars Monitor nPartition Firmware When the nPartition boots, the firmware requires between 8 to 64 MB of each cell (therefore, using CLM).
• • containing 8 GB of total memory consisting of: — 4 GB of ILM — 4 GB of CLM (2 GB from each cell) with 2 virtual partitions booted with each virtual partition assigned: — 2 GB of ILM — 2 GB of CLM Then, the memory not available to the virtual partitions’ OS and applications would consist of the following: 128 MB nPartition firmware (64 MB from each cell x 2 cells) 384 MB fpar0 128 MB fpardump 32 MB fpar1 for virtual partition 1 32 MB fpar2 for virtual partition 2 From a vPars perspective, this means t
E Moving from a Standalone to vPars A standalone system running a single instance of HP-UX can be further divided into multiple virtual partitions. This section provides a brief overview of the process for moving from a standalone system environment to a virtual partitions environment. Converting a standalone system to a virtual partitions environment divides system resources among the virtual partitions and enables the system to run multiple instances of HP-UX.
F Supported Configurations for Memory Migration HP-UX 11i v3 (11.31) supports dynamic memory migration in conjunction with vPars. To optimize runtime performance as well as memory migration performance, system administrators configure the amount of memory that is available for critical system needs and the amount of memory that may be deleted without a reboot.
Glossary All vPars Versions core The actual data-processing engine within a processor. A single processor might have multiple cores. Sometimes referred to as a “processing core”. See also processor. dynamic CPU migration The vPars ability to add or remove CPUs (cores) while a virtual partition is running. hard partition Any isolated hardware environment, such as a rp7400 server or an nPartition within a Superdome complex.
CLP (Cell Local Processor) A CPU (core) on a specific cell in an nPartition. Using CLP notation to add or delete CPUs from a virtual partition specifies the cell where the CPU resides. ILM (Interleaved Memory) The nPartition’s system default is to have all memory configured as ILM. vPars A.05.xx-specific Terms base memory This is memory that can be only added to virtual partitions while the virtual partition is up. This memory cannot be deleted from a virtual partition while it is up.
Index Symbols /stand filesystem, 70 A adding cpu to a partition, 198, 230, 253 adding i/o to a partition, 178, 180, 215, 217, 247, 249 adding memory resources to a partition, 182, 218, 250 alternate partition database files, 171 application fault isolation, 19 attributes, 153 AUTO file, 163 Autoboot, 57, 165 B BCH.
expert recovery, 22, 290 L getauto, 134 glance, 23 golden image, 279 granularity, 191, 222 GSP. See Guardian Service Processor, 69 Guardian Service Processor terminal type, 69 lan cards, 74, 116 lan path, 57 LBA concepts, 176, 213, 245 LBA.
N NO_HW (ioscan output), 24, 34 nPartition, 18, 265 Adding a cell, 268 Reboot for Reconfiguration, 150, 269, 270 O ODE, 21 OLAR.
virtual consoles, 32 GSPdiag1 device file, 34 output delay, 34 terminal emulation, 34 virtual partitions, 18, 28 adding a cell, 268 adding cpu resources, 198, 230, 253 adding i/o resources, 178, 180, 215, 217, 247, 249 adding memory resources, 182, 218, 250 compared to hard partitions, 18 creating, 151 defined, 17 monitor, 29 naming, 52 rebooting, 154 removing, 152 removing cpu resources, 198, 230, 253 removing i/o resources, 178, 180, 215, 217, 247, 249 removing memory resources, 182, 218, 250 shutdown, 15
