HP-UX Virtual Partitions Administrator’s Guide HP Part Number: T1335-90083 Published: December 2007 Edition: 14.
© Copyright 2007 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.......................................................................................................17 Publication History...............................................................................................................................17 1 Introduction...................................................................................................................19 What Is vPars?.........................................................................
Number of Virtual Partitions...........................................................................................................54 Virtual Partition Names...................................................................................................................54 Minimal Hardware Configuration..................................................................................................54 CPUs..................................................................................................
Overview of the Mixed HP-UX 11i v1/v2 vPars Environment Update Process.............................81 Update-UX Primer...........................................................................................................................84 OE Bundle Names for Update-UX.............................................................................................84 vPars Bundle Names for Update-UX.........................................................................................
Monitor: Using the Monitor Commands from ISL or EFI..................................................................130 Commands: vPars Manpages..............................................................................................................131 Commands: vPars Commands Logging.............................................................................................131 Log File Location and Log Format............................................................................................
Example.........................................................................................................................................167 Managing Resources With Only One Virtual Partition......................................................................169 6 CPU, Memory, and I/O Resources (A.05.xx)........................................................171 I/O: Topics..............................................................................................................................
Using both the Hardware Path Specification and CLP specification............................................198 CPU: Notes on vPars Syntax, Rules, and Output...............................................................................198 CPU: CLI Rules for Dynamic Migration of Memory and CPU.....................................................198 CPU: Deleting CPUs Summary.....................................................................................................199 CPU: vparstatus...............
CPU.....................................................................................................................................................226 CPU: Boot Processor and Dynamic CPU Definitions ........................................................................227 CPU: Specifying Min and Max Limits................................................................................................228 CPU: Adding and Deleting by Total.................................................................
Choosing the Hardware Path of a Bound CPU.............................................................................251 CPU: Removing a Bound CPU............................................................................................................251 CPU: Removing a CPU with a Specified Hardware Path.............................................................252 CPU: Adding, Removing, and Migrating Unbound CPUs................................................................
Recovering the Virtual Partition...............................................................................................281 Using make_tape_recovery within a vPars-environment on PA-RISC Servers (vPars A.03.03, A.04.03, A.05.01)............................................................................................................................283 Requirements and the BOOT Attribute.....................................................................................283 Archiving................
Create A Fourth Virtual Partition.............................................................................................304 Remove a Virtual Partition.......................................................................................................304 Problem is Encountered...........................................................................................................304 The Workaround: Reboot the Target 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...........................................................................................................19 Superdome Cabinet.......................................................................................................................20 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 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 PA-RISC and Integrity Differences................................................................................................41 Differences Among vPars Versions...............................................................................................42 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/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 159).
vPars commands; for HP-UX 11i v3 (11.31), ioscan’s default output will continue to show the legacy format. vPars does not affect the use of the agile view with non-vPars commands. Wherever the new formats are supported by other HP-UX commands and tools, you can use these new formats within the virtual partitions running HP-UX 11i v3 (11.31). vPars does not support disabling legacy 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.
You can create, modify, and view the database contents using vPars commands at the Unix shell level. See “Monitor and Shell Commands” (page 117). Because the format of the database is proprietary, you must use only vPars commands to create, modify, and view the database. Whenever you execute a vPars command from the Unix shell of a partition, the change is made first to the Monitor’s master copy. Then, the operating system from which you executed the command updates its local copy from the master copy.
Boot Sequence: The Details With or without vPars, the firmware loads and launches ISL or EFI. PA-RISC Integrity ISL> Shell> fs0: fs0:\> \efi\hpux\hpux.efi In a server without vPars, from ISL or EFI, the loader hpux or hpux.efi loads the kernel /stand/vmunix: PA-RISC Integrity ISL> hpux /stand/vmunix HPUX> boot vmunix However, in a server with vPars, from the loader (hpux or hpux.
When the partition that owns the hardware console port is not running, the vPars Monitor takes over the management of the I/O to the hardware console port, so you will still have access to the virtual console displays. You can access the console port as you would on any non-vPars server, for example, through a dumb terminal or lan console. Then, to cycle between the virtual console displays of the various partitions, press Ctrl-A.
Each virtual partition has an 8K circular buffer for console output. If not already displayed, the 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 57).
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 131).
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 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 32).
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 (A.05.xx and HP-UX 11i v3 firmware only) Console Port Assigned to First Partition yes (A.03.
Table 2-2 Differences Among vPars Versions (continued) vPars Version A.03.xx A.04.xx A.05.
Table 2-3 To Migrate the Resource, the Target Virtual Partition State must be... Version CPUs A.03.xx bound: unbound: Memory down up or down I/O down A.04.xx A.05.xx boot processor: all others: down float: up or down base: down up or down add: up or down delete: down The table below shows the same information, but from the perspective of dynamic migration (in other words, online migration): Table 2-4 Dynamic Migration Version A.03.xx A.04.xx A.05.
Table 2-5 CPU Syntax from A.03.xx to A.04.xx/A.05.xx (continued) vPars A.03.xx Syntax vPars A.04.xx/A.05.xx Syntax cpu::total • total = bound + unbound CPUs cpu::total • total = (number of CPUs assigned by hw_path) + (number of CPUs assigned by cell) + (number of CPUs assigned by vPars Monitor) NOTE: when the virtual partition is booted, one of the CPUs from the operand list above becomes the boot processor. NOTE: from a user’s point of view, the same CPU could be considered under more than one category.
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 60) • “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.
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/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 and cellular 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 Processor winona# i
Memory For detailed information on memory allocation, read “Memory: Allocation Notes” (page 226). If you are planning an A.05 system, you should also see “Memory: Topics” (page 177). 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.
Feature Summary The following table highlights the rules for having a mixed HP-UX 11i v1/v2 vPars environment. 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 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 v2/v3 vPars Environments in vPars A.05.
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.
• • • • “Managing: Creating a Virtual Partition” (page 147). “Monitor: Booting the vPars Monitor” (page 126). “Booting a Virtual Partition” (page 150) “Shutting Down or Rebooting the nPartition (OR Rebooting the vPars Monitor)” (page 152). Server Chipset Upgrade The process documented in many of the updates assumes you are not performing a hardware upgrade that causes a change in hardware paths (for example, upgrading from the sx1000 chipset to the sx2000 chipset).
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. After the firmware installation has completed, you can boot the Monitor and virtual partitions as you normally would.
5. 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 24). 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: 1.
If you wish to upgrade to a mixed HP-UX 11i v2/v3 vPars environment (vPars A.04.xx/11.23 & vPars A.05.xx/11.31 in the same nPartition), see “Updating from vPars A.04.xx to Mixed HP-UX 11i v2/v3 vPars (A.04.xx and A.05.xx) Environment” (page 93). This process works only using Update-UX and a corresponding Ignite-UX depot; it does not work by directly using the OE and vPars media.
Because both the OE and vPars bundle are the parameters for update-ux, both the OE (including the OS version) and the vPars version are updated in this single step. NOTE: When using the 11.31 binaries for update-ux, there is now a -p (preview) option similar to the swinstall preview option. If you are unfamiliar with the Update-UX product or would like information on using or debugging Update-UX, read the HP-UX 11.31 or 11.23 Installation and Update Guide.
Virtual Partition Name ============================== keira1 keira2 keira3 3. State ===== Up Up Up Attributes ============ Dyn,Auto,Nsr Dyn,Manl,Nsr Dyn,Auto,Nsr Boot Kernel Path Opts ======================= ===== /stand/vmunix /stand/vmunix /stand/vmunix Install the latest Update-UX bundle onto each virtual partition (use Ctrl-A to switch between consoles). Note that this does not update the operating system, only the Update-UX bundle.
NOTE: At this point, you need to reboot the nPartition from the MON> prompt, not just the virtual partition. By rebooting the nPartition, you can load the new vPars Monitor in the next step. 7. If needed (depending upon how your nPartition’s autoboot configuration is set up), interrupt the nPartition boot process and load the vPars Monitor. Example for PA-RISC: BCH> bo pri interact with IPL: y ISL> hpux /stand/vpmon Example for Integrity: Shell> fs0: fs0:\> hpux HPUX> boot vpmon 8.
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.
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 86).
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 86). 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 60).
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 installing iCAP on an HP-UX 11i v1 vPars system, and wish to update to vPars A.03.05, or configure 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.
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.
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 62).
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.
keira1# parstatus -w The local partition number is 0. 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.
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.
• • e. on Integrity: keira# vparenv -m vPars on PA, 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. Example for PA-RISC: BCH> bo pri interact with IPL: y ISL> hpux /stand/vpmon Example for Integrity: Shell> fs0: fs0:\> hpux HPUX> boot vpmon 10. Boot the virtual partitions.
There is no method to convert the memory to float during the update process. For information base and float memory, see “Definitions for Dynamically Migrating ILM or CLM Memory ” (page 178). To convert the base memory to float memory, see “Memory: Converting Base Memory to Float Memory” (page 186). Updating from vPars A.03.xx to A.05.xx At the time of this publication, updating directly from vPars A.03.xx to A.05.
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 # vparmodify -p keira2 keira1 # vparmodify -p keira3 keira1 # vparmodify -p keira3 -B nosearch -B manual -B 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 that this does not update the operating system, only the Update-UX bundle.
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 installing iCAP on an HP-UX 11i v1 vPars system, and wish to update to vPars A.03.05, or configure a mixed 11i v1/v2 vPars environment, you must install iCAP version 8.03 (B.11.11.08.03.
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 57). 3.
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. As a result of this process, the virtual partition will automatically reboot.
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.
keira2 loaded b. press Ctrl-A until you see the console of the target partition. c. Select a MAC address from the list to perform a LAN boot. [keira2] 01 Acpi(000222F0,0)/Pci(1|0)/Mac(00306E0E5268) Select Desired LAN: 1 Selected Acpi(000222F0,0)/Pci(1|0)/Mac(00306E0E5268) Running LoadFile() CLIENT MAC ADDR: 00 30 6e 0e 52 68 DHCP… d. Using the Ignite-UX server, install the necessary bundles.
6. Reboot the system. # /etc/shutdown -r 7. Boot the system to ISL or EFI shell and boot the Monitor and all the virtual partitions: • PA-RISC BCH> bo pri interact with IPL: y ISL> hpux /stand/vpmon vparload -all • Integrity Shell> fs0: fs0:\> hpux HPUX> boot /stand/vpmon vparload -all Your system should now be booted with all virtual partitions up. Removing the vPars Product From a Single Virtual Partition To remove the vPars product, execute the swremove command from the target virtual partition.
5 Monitor and Shell Commands This chapter covers: • Using Integrity systems — Setting Modes — EFI to Hardware Path Mappings • Using the vPars Monitor — Booting the Monitor — Accessing the Monitor Prompt — Using Monitor Commands • Using the vPars Commands — vPars Manpages — vPars Commands Logging — Obtaining Monitor and Hardware Resource Information • Managing the Virtual Partitions — Creating a Virtual Partition — Booting a Virtual Partition — Shutting Down or Rebooting a Virtual Partition — Shutting D
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.
Then execute the vparconfig command. 2 • To set the mode to nPars and then immediately reboot the nPartition into nPars mode Shell> fs0: 1 fs0:\> vparconfig reboot nPars First access the disk. Then execute the vparconfig command. 1 2 • 2 EFI: parconfig [mode[-n]] where mode has the value of only nPars.
• 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 Monitor command vparload, see the 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 Monitor command scan. • A.04.xx and A.05.xx: When any CPU is available, you will see the MON> prompt.
the ln -s command also should be executed to create the soft link. Otherwise, it will not be possible to boot from the backup database file. • vparload-all vparload-autovparload-ppartition_name[-bkernelpath][-oboot_options][-Bhardware_path] [-D disk_index] [-E disk_index] boots the virtual partition partition_name; this command is similar to the vPars Unix shell command vparboot. -all Boots all virtual partitions, regardless of the autoboot or autosearch attributes.
nPartition have been shut down and the vPars Monitor rebooted. For more information see “Shutting Down or Rebooting the nPartition (OR Rebooting the vPars Monitor)” (page 152). • displays the device from which the vPars Monitor (/stand/vpmon) was booted bootpath Example: MON>bootpath disk(0.0.2.0.6.0) • reboot [mode] reboots the entire hard partition. Other hard partitions are not affected. mode sets the mode for the next reboot and has the value of either nPars or vPars.
The ls command-line options are the same as the Unix shell lsoptions. For detailed explanations, see the ls(1M) manpage. In brief: -a all entries -l long listing -n numerical UIDs and GIDs -i inode -F appends a character after the entry, depending on the file type, such as a / (slash) for a directory For example, to view the listing of files in winona2’s /stand directory: MON> ls /stand lost+found system.d kernrel vmunix.backup vpdb.backup ioconfig vmunix rootconf system.
Commands: vPars Manpages The purpose of this document is to describe vPars concepts and how to perform common vPars tasks. For detailed information on the vPars commands, including description, syntax, all the command line options, and the required state of a virtual partition for each command, see the vPars manpages. NOTE: The vparresources(5) manpage contains critical information about the vPars commands, including option precedence and the required state of a virtual partition prior to command execution.
Oct 29 19:47:47 winona2 vparmodify[2962]: exit status 1 Cases Where No Logging Occurs Below are the cases where logging does not occur: • a non-root user attempting a vPars command • syntax, usage, or vPars commands version errors • vPars commands which do not change the vPars database and/or do not affect the state of other virtual partitions. These commands include vparstatus, vparextract, vecheck, vpardump, and vparreloc. Additionally, for only vPars A.03.03 and earlier and A.04.
NOTE: nPartition Logs (see also “nPartition Logs” (page 37)) On an nPartition server running vPars, all virtual partitions within an nPartition share the same console device: the nPartition’s console. Thus, an nPartition’s console log contains console I/O for multiple virtual partitions. Further, since the vPars Monitor interface is displayed and accessed through the nPartition’s console, vPars Monitor output is also recorded in the nPartition’s console log. There is only one Monitor per nPartition.
• • • • • • “vparstatus: pending migrating CPUs operations” (page 143) “vparstatus: dual-core CPUs” (page 142) “vparstatus: CPU information on vPars A.04/A.05” (page 140) “vparstatus: pending migrating memory operations” (page 144) “vparstatus: pending nPartition Reboot for Reconfiguration” (page 146) “vparstatus: Monitor and database information” (page 147) NOTE: • Actual vparstatus output differs from version to version of vPars. Depending on your version and system, the output shown below may differ.
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 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: Monitor and database information Beginning with vPars A.03.02, the -m option displays the console path, the hardware path from which the Monitor was booted, the fleshiest path of the Monitor, and the vPars database file that is being used by the Monitor. Beginning with vPars A.04.01, memory ranges used by the 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 Monitor command vparload or the shell command vparboot. (To shutdown a booted virtual partition, see “Shutting Down or Rebooting a Virtual Partition” (page 150)).
After winona1 is shutdown, the virtual partition is in the down state. For more information, see “Virtual Partition States” (page 133). • 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 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 Monitor boots the virtual partitions.
Autobooting the vPars Monitor and Virtual Partitions You can setup the 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 172) “I/O: Adding or Deleting LBAs” (page 174) “I/O: Allocation Notes” (page 176) 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.
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 17
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 184). 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.01, 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 198) Additional CPU Topics — “CPU: Dual-Core Processors” (page 200) — “CPU: Hyperthreading ON/OFF (HT ON/OFF)” (page 202) — “CPUs: Managing I/O Interrupts” (page 203) — “CPU: CPU Monitor (formerly known as LPMC Monitor)” (page 204) 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 va
Example • To create the virtual partition keira2 with 3 CPUs, set num to 3: keira1# vparcreate -p keira2 -a cpu::3 ... vparmodify With the vparmodify command, you can use the following: • -a option to add num CPUs to the virtual partition. • -d option to delete num CPUs from the virtual partition. • -m option to modify (set) to num the number of CPUs assigned to the partition. The vPars Monitor automatically will add or delete CPUs to or from the virtual partition to reach num CPUs.
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.
NOTE: 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). If the virtual partition is down, total is not changed and becomes a high boundary.
• — 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. • • HT ON is not supported in a mixed HP-UX 11i v2/v3 vPars environment.
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 Monitor will not allow the partition to boot until the deconfigured or deactivated CPU can be taken out of use.
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.
NOTE: • For a given virtual partition, the vPars memory and CPU online modification requests (vparmodify) are processed serially; in other words, a subsequent operation on the same virtual partition cannot begin until the current modification has been successfully completed or canceled. When using the -C sequenceID operation, you can cancel only the current (pending) operation.
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 213). 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 i
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: 212 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 Monitor when the virtual partition boots. The 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 217). 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 219) 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:yspecification: 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 set
Example • To create the virtual partition keira2 with 3 CPUs, set num to 3: keira1# vparcreate -p keira2 -a cpu::3 ... vparmodify With the vparmodify command, you can use the: • -a option to add num CPUs to the virtual partition, • -d option to delete num CPUs from the virtual partition, • -m option to modify (set) to num the number of CPUs assigned to the partition. The vPars Monitor automatically will add or delete CPUs to or from the virtual partition to reach num CPUs.
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.
NOTE: 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). If the virtual partition is down, total is not changed and becomes a high boundary.
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 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 233)). When you are in the vPars environment or vPars mode, you can activate a CPU using icod_modify -a.
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: • • • • 236 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 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 243). 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 i
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: 242 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 246). 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 set
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 -ppartition_name [-acpu::total] [-a cpu:::[min][:[max]]]] [[-acpu: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: 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. One bound CPU will be removed from the partition, but one unbound CPU will be added to the partition in order to maintain the total of two CPUs. NOTE: Because one of the value requirements for CPUs is min <= total and because command line options are processed left to right, when setting both min and total to one, you need to set min to one before setting total to one.
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 26). For more information, see “Shutting Down or Rebooting the nPartition (OR Rebooting the vPars Monitor)” (page 152) and the vPars Monitor command “reboot [mode]” (page 129). 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 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.
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 : 270 nPartition Operations 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 Monitor. When the Monitor crashes, a 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 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, see “Using make_tape_recovery within a vPars-environment on PA-RISC Servers (vPars A.03.03, A.04.03, A.05.
Using make_net_recoverywithin 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 275).
Using make_tape_recovery Outside of a vPars Environment The creation of make_tape_recovery tapes is supported on vPars-enabled servers. However with vPars A.04.01, A.03.01, and A.03.02, 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 281). • 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 three 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. 282 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 on PA-RISC Servers (vPars A.03.03, A.04.03, A.05.01) For PA-RISC servers, beginning with vPars A.03.03 for HP-UX 11i v1 and A.04.03 for HP-UX 11iv2, vPars supports tape drives. This includes recovery of a virtual partition within a vPars environment and without using an Ignite-UX server as a boot helper.
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: • • • • • 284 You can no longer read from or write to system-wide stable storage using setboot. See “Setboot and System-wide Stable Storage ” (page 153). mkboot modifies the LIF area, but vPars does not use the LIF area to boot a virtual partition.
11 vPars Flexible Administrative Capability (vPars A.03.03, A.03.04, vPars A.04.02, A.04.03, A.05.01) 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.
local partition This is the virtual partition from which a vPars command is executed. For example, in the command: winona1# vparmodify -p winona2 -a cpu::1 assuming the HP-UX shell prompt contains the hostname, the vparmodify command is executed from winona1, so winona1 is the local virtual partition. winona2 is the target partition. designated-admin virtual partition This is a virtual partition that is allowed to perform vPars commands that affect other virtual partitions.
partition. How to add or delete virtual partitions from this list is discussed in a later section. Whenever the flexible administrative capability mode is set to ON, the designated-admin virtual partition list will be empty. flexible administrative capability mode When this mode is set to ON, only designated-admin virtual partitions are allowed to successfully execute vPars commands that affect other partitions.
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
virtual partitions. Once you set the mode to OFF, the designated-admin virtual partition list is deleted as well as the flexible administrative capability password. -a|-d partition_name • Adds or deletes a virtual partition to or from the designated-admin virtual partition list. No flexible administrative capability password is required here; passwords are required only at the HP-UX shell prompt. -l • Lists all the virtual partitions that are currently in the designated-admin virtual partition list.
-C • Changes the flexible administrative capability password. It will ask you for the existing password before allowing you to change it. -a|-d partition_name • Adds or deletes a virtual partition to or from the designated-admin virtual partition list. You will need to provide the flexible administrative capability password. -l • Lists all the virtual partitions that are currently in the designated-admin virtual partition list. Use vparadmin -a to add virtual partitions to the list.
Table 11-1 Flexible Administrative Capability Impact on vPars Commands vPars command Executed from a ...
Also, this allows you to have at least one virtual partition to be a designated-admin virtual partition, which allows you to vparcreate, vparboot, vparreset, and vparmodify other partitions if needed. Assuming we have already installed the vPars product, created virtual partitions, and have booted the Monitor, we can set the flexible administrative capability feature to ON.
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. This can be done from any virtual partition, but you will need to know the flexible administrative capability password. winona2# vparadmin -a winona2 password: Virtual partition winona2 is added to the Designated-Admin virtual partitions 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. NOTE: Discontinuance of the Virtual Partition Manager for vPars A.04.
After vPars is installed and running, you must boot at least one virtual partition to a HP-UX kernel. You can then start the virtual partition manager in that virtual partition by executing the command vparmgr /opt/vparmgr/bin/vparmgr [-h] /opt/vparmgr/bin/vparmgr -tcreate /opt/vparmgr/bin/vparmgr -tmodify|par_details -pvp_name With no arguments, the vparmgr graphical user interface is launched.
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. Each vparmgr screen works in a similar fashion. Select the object, then click a button to act on the object. Some buttons do not require a selected object. For example, the refresh button will refresh the display, using the latest data available from the vPars Monitor.
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.
float memory This is memory that can be either added to or deleted from a virtual partition while the virtual partition is up. ILM (Interleaved Memory) The nPartition’s system default is to have all memory configured as ILM. mixed environment A mixed HP-UX 11i v2/v3 vPars environment allows you to have a vPars A.05.xx monitor and database that simultaneously supports virtual partitions running vPars A.05.xx on HP-UX 11i v3 (11.31) and virtual partitions running vPars A.04.
Index Symbols /stand filesystem, 70 A adding cpu to a partition, 194, 226, 247 adding i/o to a partition, 174, 176, 211, 213, 241, 243 adding memory resources to a partition, 178, 214, 244 alternate partition database files, 167 application fault isolation, 21 attributes, 149 AUTO file, 159 Autoboot, 59, 161 B BCH.
expert recovery, 24, 284 L getauto, 129 glance, 25 golden image, 273 granularity, 187, 218 GSP. See Guardian Service Processor, 69 Guardian Service Processor terminal type, 69 lan cards, 74, 113 lan path, 59 LBA concepts, 172, 209, 239 LBA.
N NO_HW (ioscan output), 26, 36 nPartition, 20, 259 Adding a cell, 262 Reboot for Reconfiguration, 146, 263, 264 O ODE, 23 OLAR.
virtual consoles, 33 GSPdiag1 device file, 36 output delay, 36 terminal emulation, 36 virtual partitions, 20, 30 adding a cell, 262 adding cpu resources, 194, 226, 247 adding i/o resources, 174, 176, 211, 213, 241, 243 adding memory resources, 178, 214, 244 compared to hard partitions, 20 creating, 147 defined, 19 monitor, 31 naming, 54 rebooting, 150 removing, 148 removing cpu resources, 194, 226, 247 removing i/o resources, 174, 176, 211, 213, 241, 243 removing memory resources, 178, 214, 244 shutdown, 15
