HP-UX Virtual Partitions Administrator Guide March 2011 HP Part Number: 5900-1312 Published: March 2011 Edition: 20
© Copyright 2011 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.
Contents About This Document...................................................................................14 Publication History..................................................................................................................14 1 Introduction.............................................................................................16 What Is vPars?.......................................................................................................................
Virtual Partition Names.......................................................................................................51 Minimal Hardware Configuration.........................................................................................51 CPUs................................................................................................................................51 vPars A.04.xx and later.................................................................................................
Ignite-UX, the LAN, the LAN card, and vparboot -I......................................................................76 PA-RISC............................................................................................................................76 Integrity............................................................................................................................77 Updating from vPars A.04.xx to A.05.xx..................................................................................
5 vPars Monitor and Shell Commands..........................................................123 Notes on Examples in this Chapter.........................................................................................123 Syntax of Example Commands..........................................................................................123 Example Server...............................................................................................................
Booting Using the Primary or Alternate Boot Paths................................................................160 Autoboot.............................................................................................................................160 The AUTO File on a Virtual Partition...................................................................................160 Autobooting the vPars Monitor and Virtual Partitions.............................................................161 Single-User Mode..
vparstatus: Base and Float Memory Amounts.......................................................................184 Memory: Converting Base Memory to Float Memory.................................................................184 Memory: Granularity Concepts .............................................................................................185 Granularity Value Locations...............................................................................................
System, Cells, SBA, LBA, Devices and Relationships..............................................................204 I/O: Adding or Deleting LBAspartitionsadding i/o resourcespartitionsremoving i/o resourcesadding i/o to a partitionremoving i/o from a partitionvirtual partitionsadding i/o resourcesvirtual partitionsremoving i/o resourcesvparmodifyi/o resources...........................................................206 I/O Syntax in Brief.....................................................................
Managing I/O Interrupts.......................................................................................................225 intctl Command...............................................................................................................225 Notes.............................................................................................................................225 CPU: Using iCAP (Instant Capacity on Demand) with vPars (vPars A.04.xx and iCAP B.07)............
CPU: Managing I/O Interrupts...............................................................................................242 intctl Command...............................................................................................................242 Notes.............................................................................................................................243 CPU: Dual-Core Processors.................................................................................................
Recovering.................................................................................................................266 Expert Recovery...................................................................................................................266 11 vPars Flexible Administrative Capability....................................................267 Synopsis..............................................................................................................................
C Calculating the Size of Kernels in Memory (PA-RISC only)............................286 Calculating the Size of a Kernel..............................................................................................286 Examples of Using the Calculations.........................................................................................286 Changing Dynamic Tunables.............................................................................................
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 For the most current information, visit the HP-UX Virtual Partitions page on the Business Support Center (BSC) website at http://www.hp.com/go/hpux-vpars-docs. Publication History The manual publication date and part number indicate its current edition.
• Edition 2: June 2002, T1335-90012. Includes vPars version A.02.01 on HP-UX 11i v1. • Edition 1: November 2001, T1335-90001. Includes vPars version A.01.01 on HP-UX 11i v1.
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.
hardware component that plugs into a processor socket. 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.
• ◦ PCI Error Recovery Product Note ◦ PCI Error Recovery Support Matrix Support Tools For information on the required version of the Support Tools package that can run on your vPars server, see the section on Online Diagnostics in the HP-UX Virtual Partitions Ordering and Configuration Guide. Prior to STM version A.43.
adding up the numbers results in a total of nine CPUs for the server when there are actually only five physical CPUs. • (PA-RISC only) The WINSTALL Boot Kernel Paths with Different Versions of Ignite-UX and the vparboot -I command The examples in this document use the Ignite-UX bootable kernel WINSTALL path as: ◦ /opt/ignite/boot/WINSTALL This is the correct path for Ignite-UX versions B.05.xx and earlier. However, if you are using Ignite-UX version C.06.
• Ignite-UX and other Curses Applications On the virtual console, when using applications that use curses, such as the terminal versions of Ignite-UX and SAM, do not press Ctrl-A to toggle to the console display window of another virtual partition while you are still within the curses application. This is especially applicable when you are using vparboot -Iand the Ignite-UX application to install vPars. For more information on curses, see the curses_intro(3X) manpage.
also set these values on a vPars server from the HP-UX shell of a virtual partition using the vPars command vparutil. For more information, see the vparutil(1M) manpage. For vPars A.04.xx and later: use the mptconfig command to view or set the SCSI parameters for Ultra320 host bus adapters (HBAs). For information on the mptconfig command, see the HP A7173A PCI-X Dual Channel Ultra320 SCSI Host Bus Adapter Support Guide.
advanced administrators for performance tuning. If you are managing interrupts on vPars systems, see the section “Managing I/O Interrupts” (page 225). • kernel crash dump analyzer You cannot use a kernel crash dump analyzer on vPars Monitor dumps because vPars Monitor dumps are structured differently than kernel dumps. For more information on vPars Monitor dumps, see “vPars Monitor Dump Analysis Tool” (page 258).
• vMedia Support vPars A.05.03 and HP-UX support read-only use of optical media via an iLO 2 MP on HP Integrity servers based on the sx2000 chipset, including rx7640, rx8640, and HP Integrity Superdome servers. ◦ vPars A.05.03 supports all the standard iLO 2 MP features that are supported by HP-UX, including the Lights Out Advanced features of vMedia. However, vPars does not support virtual keyboard, video, and mouse features.
rules, tuning recommendations, HP-UX 11i v3 enhancements, and tools to support them. For more information on LORA, see “Planning Your Virtual Partitions for LORA Support” (page 64). Ordering vPars For the latest information on ordering vPars, see the HP-UX Virtual Partitions Release Notes and the HP-UX Virtual Partitions Ordering and Configuration Guide. NOTE: 26 Introduction The free product known as VPARSBASE is obsolete and is no longer available or supported.
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 4 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 6 Software Stack for Server with Two Virtual Partitions Application 1 Application 2 HP-UX 11i Patch Level B HP-UX 11i Virtual Partition Monitor Hardware / Firmware vPars Monitor and Database vPars Monitor For each hard partition, the vPars Monitor manages the assignment of hardware resources to virtual partitions, boots virtual partitions and their kernels, and emulates certain firmware calls.
As a preventive action, you can back up the vPars partition database to avoid accidental loss of configuration changes. For more details, see “Network and Tape Recovery” (page 259) and “Using an Alternate Partition Database File ” (page 167). You can create, modify, and view the database contents using vPars commands at the Unix shell level. See “vPars Monitor and Shell Commands” (page 123).
Adding vPars adds the vPars Monitor layer, so now hpux(for Integrity, hpux.efi) loads the vPars Monitor. Then the vPars Monitor boots the kernels of the virtual partitions. The boot sequence becomes the following. 1. ISL or EFI (firmware) 2. hpux or hpux.efi 3. /stand/vpmon (vPars Monitor and partition database) 4. /stand/vmunix (kernels of the virtual partitions) Boot Sequence: The Details With or without vPars, the firmware loads and launches ISL or EFI.
Virtual Consoles HP-UX servers have a special terminal or window called a console that allows special control and displays system error messages. With vPars, each virtual partition has its own virtual console. On Integrity, the console is virtualized by firmware (and therefore, there is no vcs driver). On PA-RISC, for each partition, its console I/O is sent to its vcn (Virtual CoNsole) driver. From the vcn driver, the console I/O is sent to the vPars Monitor.
Each virtual partition has an 8K circular buffer for console output. If not already displayed, the vPars Monitor copies this 8K buffer to the console when you press Ctrl-A. CAUTION: (A.03.xx only) The first virtual partition that you create must own the LBA (local bus adapter) that contains the physical hardware console port. For an example, see “Assigning the Hardware Console LBA” (page 54).
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.
To avoid display problems, be sure that the terminal setting of the GSP on the vPars server matches the terminal or terminal emulator that you are using to access it. For details on how to do this, see “Setting the GSP Terminal Type” (page 71). • Ignored Keyboard Input (A.03.xx only) There is one known case where the virtual console will ignore keyboard input (data sent to the console continues to be displayed; only keyboard input is ignored).
Location of Log Files On an nPartition not running vPars, the MCA logs are gathered from the firmware during OS reboot and saved in the /var/tombstones directory. Typically, multiple files are created of the form mca*. When running vPars, logs from a local MCA are saved in the virtual partition that experienced the MCA. Similar to the non-vPars configuration, these files are in the /var/tombstones directory of the virtual partition.
vparenv HP-UX shell command that allows you to set the mode (vPars or nPars) for the next reboot of the nPartition or to set the memory granularity unit size in firmware. vparconfig EFI command that allows you to set the mode (vPars or nPars) and forces a reboot of the nPartition. Note that vparconfig is not a built-in EFI command; you will need to go to the fsN:\> disk prompt to execute this command. vparconfig is installed in the EFI partition of the root disk when vPars is installed.
3. 4. 5. 6. 7. 8. Select Boot Option Maintenance Menu. Select Delete Boot Option(s). Select HP-UX Primary Boot and then exit. Select Exit to return to the EFI Boot Manager. Select EFI Shell [Built-in]. Launch HP-UX from the EFI shell prompt: Shell> fsN: fsN:\> efi\hpux\hpux boot vmunix 9. Use the setboot command to set up the primary boot path with the desired boot device. This also sets the HP-UX Primary Boot boot option with the latest EFI device path. 10.
On PA-RISC, the lan card of the source partition is used. • Boot String On Integrity platforms, the boot string used at the hpux.efi prompt (hpux>) is “boot vpmon”. See “Boot Sequence” (page 30). See “vPars Monitor: Booting the vPars Monitor” (page 132). See “Autoboot” (page 160). On PA-RISC, the boot string at the hpux prompt (HPUX>) is “hpux /stand/vpmon”.
Table 1 PA-RISC and Integrity Differences (continued) vPars Functionality PA-RISC Integrity Server Mode Specification Methods N/A • Shell> fsN: fsN:\> vparconfig reboot mode • MON> reboot mode • HP-UX# vparenv -m mode where mode is vPars or nPars Boot vPars Monitor Steps ISL> hpux /stand/vpmon Shell> fs0:\> vPars ...
Table 2 Differences Among vPars Versions vPars Version A.03.xx A.04.xx A.05.xx Architectures Supported PA-RISC PA-RISC, Integrity PA-RISC, Integrity Product Number T1335AC T1335BC T1335CC (Up to vPars A.05.05) or T1335DC (vPars A.05.05 and later) Media Format CD DVD DVD OS HP-UX 11i v1 (B.11.11) HP-UX 11i v2 (B.11.23) HP-UX 11i v3 (B.11.31) vPars Monitor Supports mixed HP-UX 11i no v1/v2 vPars yes (vPars A.04.
Table 2 Differences Among vPars Versions (continued) vPars Version A.03.xx A.04.xx A.05.xx Tape Boot Support yes (vPars A.03.03 and later) yes yes (PA-RISC: vPars A.04.03 and later) (PA-RISC: vPars A.05.xx) no (Integrity: A.05.02 and (Integrity: A.04.
NOTE: In a mixed HP-UX 11i v2/v3 vPars environment or a mixed HP-UX 11i v1/v2/v3 vPars environment, dynamic memory migration is only supported on the vPars versions that support dynamic memory migration. In other words, memory migration operations can be initiated only from virtual partitions running vPars A.05.xx, and the virtual partition target for the memory migration must be running vPars A.05.xx as well. Transitioning from vPars A.03.xx to vPars A.04.xx/A.05.
Table 6 CPU Rules from A.03.xx to A.04.xx/A.05.xx vPars A.03.xx Rules vPars A.04.xx/A.05.
Table 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) deleting by hw_path (-d cpu:hw_path) • can only delete CPU added by 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 56) • “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.xx” (page 58) • “Mixed HP-UX 11i v1/v2/v3 vPars Environments in vPars A.05.
1/0 1/2 1/2/0/0 1/2/0/0.0 1/2/0/0.0.0 1/2/0/0.7 1/2/0/0.7.0 1/2/0/1 1/2/0/1.7 1/2/0/1.7.0 1/4 1/4/0/0 1/4/0/0.5 1/4/0/0.5.0 1/4/0/0.7 1/4/0/0.7.0 1/4/0/1 1/4/0/1.7 1/4/0/1.7.
0/0/1/1/0 ba 0/0/1/1/0/4/0 lan 0/0/1/1/0/5/0 lan 0/0/1/1/0/6/0 lan 0/0/1/1/0/7/0 lan 0/0/2 ba 0/0/2/1/0 lan 0/0/4 ba 0/0/6 ba 0/0/6/1/0 fc 0/0/8 ba 0/0/8/1/0 ba 0/0/8/1/0/1/0 ext_bus 0/0/8/1/0/1/0.7 0/0/8/1/0/1/0.7.0 0/0/8/1/0/1/1 ext_bus 0/0/8/1/0/1/1.7 0/0/8/1/0/1/1.7.0 0/0/8/1/0/4/0 lan 0/0/10 ba 0/0/12 ba 0/0/14 ba 0/5 memory 0/10 processor 0/11 processor 0/12 processor 0/13 processor 0/14 processor 0/15 processor 1 cell 1/0 ioa 1/0/0 ba 1/0/0/0/0 tty 1/0/0/0/1 tty 1/0/0/3/0 ext_bus 1/0/0/3/0.
Planning, Installing, and Using vPars with an nPartitionable Server When using vPars, the major difference between non-nPartitionable and nPartitionable systems is the hardware path.
# vparcreate -p winona2 -a cpu::2 -a cpu:::2 -a cpu:41 -a cpu:45 ... But for an nPartitionable system, if the ioscan output shows 0/12 processor Processor 0/13 processor Processor 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 ...
NOTE: When you create a partition, the vPars Monitor assumes you will boot and use the partition. Therefore, even if a partition is down, the resources assigned to the partition cannot be used by any other partition. The next few sections will describe how we arrived at each portion of the partition plan.
The ioscan output for the example non-cellular (winona) and cellular (keira) systems show the following CPUs: keira# ioscan -kC processor H/W Path Class Description ====================================================== 0/10 processor Processor 0/11 processor Processor 0/12 processor Processor 0/13 processor Processor 0/14 processor Processor 0/15 processor Processor 1/10 processor Processor 1/11 processor Processor 1/12 processor Processor 1/13 processor Processor 1/14 processor Processor 1/15 processor Pr
Memory For detailed information on memory allocation, read “Memory: Allocation Notes” (page 219). If you are planning an A.05 system, you should also see “Memory: Topics” (page 176). 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/12 1/0 1/2 1/4 1/8 1/10 1/12 ba ba ba ba ba ba ba Local Local Local Local Local Local Local PCI PCI PCI PCI PCI PCI PCI Bus Bus Bus Bus Bus Bus Bus Adapter Adapter Adapter Adapter Adapter Adapter Adapter (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.5 lan 1.
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.
For more information, see the vparmodify(1M) manpage. NOTE: When using vparboot -I to install vPars, you need to leave the autoboot attribute set to AUTO during the installation due to the reboots that occur during the installation. After installation is complete, you can set the autoboot attribute to MANUAL using the vparmodify command.
A.04.05 Monitor and database that 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). An example mixed HP-UX 11i v1/v2 vPars environment looks like the following: Table 7 Mixed HP-UX 11i v1/v2 vPars Environment HP-UX 11i v2 (11.23) running vPars A.04.05 HP-UX 11i v1 (11.11) running vPars A.03.05 HP-UX 11i v1 (11.11) running vPars A.03.05 HP-UX 11i v2 (11.23) running vPars A.04.05 HP-UX 11i v1 (11.
• When the vPars Flexible Administrative Capability feature is enabled, a vPars A.04.05 virtual partition should be the designated-admin virtual partition. Because of HP-UX 11i v1 virtual partition command restrictions in mixed HP-UX 11i v1/v2 vPars environments, if only vPars A.03.05 virtual partitions are configured to be designated-admin, then no virtual partitions will be able to perform vparmodify, vparremove, or vparcreate operations on other virtual partitions.
NOTE: Read the following rules and the table below when running a mixed HP-UX 11i v2/v3 vPars environment. Many of the features of vPars are version-specific. To switch to an environment of only virtual partitions running vPars A.04.xx on HP-UX 11i v2, shut down the A.05.01 vPars Monitor and boot up the A.04.xx vPars Monitor. Features The following features work from all virtual partitions: • legacy vPars functions This includes dynamic CPU migration, except where noted below.
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 10 Mixed HP-UX 11i v2/v3 vPars Environment Feature Summary Feature vPars A.05.xx instances vPars A.04.xx instances vPars A.03.xx instances Minimum vPars Version A.05.01 A.04.
keira1 keira2 • B.11.31 B.11.23 Up Up vparstatus output from a virtual partition running vPars A.04.03 in a mixed HP-UX 11i v2/v3 vPars environment: keira2# vparstatus -P Commands product information: A.04.03 Monitor product information: A.05.01 Mixed HP-UX 11i v1/v2/v3 vPars Environments in vPars A.05.03 Beginning with vPars A.05.03, you can have a mixed HP-UX 11i v1/v2/v3 vPars environment on PA-RISC systems only. A mixed HP-UX 11i v1/v2/v3 vPars environment allows you to have a vPars A.05.
• When the vPars Flexible Administrative Capability feature is enabled, a vPars A.05.03 virtual partition should be the designated-admin virtual partition. Because of HP-UX 11i v1 and 11i v2 virtual partition command restrictions in mixed HP-UX 11i v1/v2/v3 vPars environments, if only HP-UX 11i v1 or HP-UX 11i v2 virtual partitions are configured to be designated-admin, then no virtual partitions will be able to perform vparmodify, vparremove, or vparcreate operations on other virtual partitions.
• HP-UX 11i v1 virtual partitions (vPars A.03.05) does not support CLM or CLP resources. It is possible—but not supported—to add CLM or CLP resources to an HP-UX 11i v1 virtual partition when it is in a “down” state. However, booting an HP-UX 11i v1 virtual partition will be halted if it has CLM or CLP resources assigned to it. • The system firmware must match the vPars A.05.03 firmware requirements.
access memory. Therefore, enhancing the performance significantly for vPars on multi-cell Integrity systems. With LORA enabled, an administrator or a user can configure vPars using the vparcreate command along with CPU by count, and Cell Local Memory (CLM). Also, specifying the I/O card from the same cell as that of memory further enhances the system performance. For more information on LORA, see http://h20000.www2.hp.com/bc/docs/support/SupportManual/c02070810/ c02070810.pdf.
Figure 7 nPars with Resources Aligned as per LORA Guidelines Virtual Partitions Layout Plan Implementation with LORA Guidelines The following table shows a virtual partitions layout plan to implement LORA guidelines. Table 15 Virtual Partitions Layout Plan for Implementing LORA Guidelines Partition Name keira1 keira2 keira3 Assigned CPUs (A.05.xx) num = 10 num = 8 num = 6 Unassigned CPUs (A.05.
Figure 8 vPars with Resources Aligned as per LORA Guidelines When a vparmodify command is issued targeting any other vPar or self, addition or deletion of CPU by count is based on LORA guidelines.
Therefore, you can notice that the CPUs are aligned near the memory when you modify the vPar by specifying CPU by count. Implementing LORA Guidelines in Mixed HP-UX 11i v2/v3 vPars Environments To implement LORA guidelines in Mixed HP-UX 11i v2/v3 vPars environments, ensure that you create or modify the target or self virtual partition using vPars A.05.05 in order to implement LORA guidelines on all the partitions. NOTE: In mixed mode, LORA is not supported on HP-UX 11i v1 operating system.
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 73) • Ignite-UX.
For more information on booting and boot devices on PA-RISC systems, see also the paper titled Booting, Installing, Recovery, and Sharing in a vPars Environment from DVD / CDROM / TAPE / Network available on the BSC website at: www.hp.com/go/hpux-vpars-docs For information on using the vPars commands, see the following sections in the chapter vPars Monitor and Shell Commands: • “Managing: Creating a Virtual Partition” (page 150). • “vPars Monitor: Booting the vPars Monitor” (page 132).
Installing Server Firmware on non-nPartitionable Servers Installing Firmware for the systems running vPars must be done in a standalone (PA-RISC) or nPars (Integrity) mode. Once in standalone or nPars mode, the procedure for installing firmware on a system with vPars installed is the same as a system without vPars installed. Additional information is shown below. For information on specific firmware versions for your servers, see the HP-UX Virtual Partitions Ordering and Configuration Guide.
• If you are using a hardwired HP terminal or a LAN-based terminal emulator of type “hpterm”, set the GSP terminal-type setting to hpterm. • If you are using a LAN-based terminal emulator of type “dtterm” or “xterm”, set the GSP terminal-type setting to vt100. How to Set the GSP Terminal Type 1. 2. 3. 4. Access the GSP through the lan console, the remote-modem port, or a physically connected terminal.
NOTE: The SecurePath product is not supported on HP-UX 11i v3 (11.31). Use the native multipathing available with the HP-UX 11i v3 mass storage stack, as described in the white paper The Next Generation Mass Storage Stack. To locate this paper go to the BSC website at www.hp.com/go/hpux-core-docs, and click HP-UX 11i v3. Bundle Names You can install vPars on an existing HP-UX installation directly from a depot, DVD, or by using an Ignite-UX server.
CAUTION: Mixing vPars versions within the same nPartition Mixing different vPars versions within the same nPartition is only supported when using the following vPars releases: • vPars A.05.01 or later with vPars A.04.02 or later. See “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.xx” (page 58). • vPars A.04.05 or later with vPars A.03.05 or later. See “Mixed HP-UX 11i v1/v2 vPars Environments in vPars A.04.05” (page 56). • vPars A.05.03 or later with vPars A.04.02 or later and vPars A.03.
VPARMGR is available on the vPars CD and from the HP Software Depot website: http:// www.hp.com/go/softwaredepot To install the VPARMGR bundle using the vPars CD: # swinstall -s /cdrom VPARMGR To remove the VPARMGR product: # /usr/sbin/swremove vParManager NOTE: The product VPARMGR is optional.
Ignite-UX, the LAN, the LAN card, and vparboot -I NOTE: Using vparboot -p target_partition -I On both PA-RISC and Integrity, before booting a virtual partition for installation (in other words, using vparboot -p target_partition -I...), be sure that you have specified a boot disk using the BOOT attribute (io:boot_device:BOOT)for the virtual partition. This is performed during either the initial vparcreate or subsequent vparmodify commands when configuring the target virtual partition.
Note that only the vPars shell command vparboot can be used to boot a subsequent virtual partition for installation (or recovery); the vPars Monitor command vparload cannot do this. Thus, you need at least one virtual partition successfully booted to use the vparboot command. Integrity The following is the sequence of events when a vparboot -I is issued from an existing virtual partition to boot a target virtual partition for an Integrity System: NOTE: vPars A.05.
Updating from vPars A.04.xx to A.05.xx This section describes how to update an existing A.04.xx vPars on 11iv2 (11.23) environment to a vPars A.05.xx vPars environment on 11iv3 (11.31). For information on vPars and OS versions, see the HP-UX Virtual Partitions Ordering and Configuration Guide. For information on the typical time needed to update the OS version, see the HP-UX 11i v3 Installation and Update Guide. The process is similar to updating from A.03.xx to A.04.xx.
For example, the command line used in this section is: • # update-ux -s depot1:/release/1131/HPUX11i-OE-Ent.DVD HPUX11i-OE-Ent T1335DC where ◦ depot1:/release/1131/HPUX11i-OE-Ent.DVD is the source depot ◦ HPUX11i-OE-Ent is the Enterprise OE bundle. The OE bundle name will differ when using a different HP-UX operating environment, as shown in “OE Bundle Names for Update-UX” (page 79). ◦ T1335DC is the vPars A.05.xx bundle.
The Update Process To update vPars from A.04.xx to A.05.xx, follow the process below. The following steps should be done from the console: 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.
Although you can do all the updates in parallel, you need to make sure that all of the other virtual partition updates have successfully performed the updating to the point of halting. 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.
keira1 # vparmodify -p keira3 keira1 # vparmodify -p keira3 -B auto -B nosearch 10. The virtual partitions should now be running the latest vPars version. To verify this, you can login to each virtual partition and use the vparstatus command with the -P option: Example: keira1# vparstatus -P Current Virtual Partition Version: A.05.01 Monitor Version: A.05.01 [Virtual Partition OS Version] Virtual Partition Name OS Version ============================ ========== keira1 B.11.31 keira2 B.11.
• “Installing vPars with Ignite-UX on PA-RISC” (page 116) • “Installing vPars with Ignite-UX on Integrity” (page 118) • “Installing vPars with Software Distributor ” (page 120) 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.
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 10. 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 88). 1. Make sure that all the virtual partitions are up. 2.
• If updating all virtual partitions in parallel, then perform the following steps. On all remaining virtual partitions: ◦ – If the OE must also be updated, use Update-UX to install the latest OE and the vPars A.03.05 bundle to the virtual partition. – If only the vPars bundle needs to be updated, use swinstall to install vPars A.03.05. Wait for the vPars A.03.05 updates to complete. ◦ Monitor the installation logs (such as the /var/adm/sw/swagent.log file or swinstall.
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.
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).
This step must be performed to avoid automatically rebooting into the wrong vPars Monitor. 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 57).
TIP: The parmodify command requires major path components to be separated with a slash (/). For example, 0.0.6.0.0.5.0 would be specified as 0/0/6/0/0.5.0 when using parmodify. 7. Install the latest and OS-applicable Update-UX bundle onto each virtual partition that will be updating the HP-UX Operating Environment—including all virtual partitions updating to HP-UX 11i v2 and vPars A.04.05. This does not update the operating system, only the Update-UX bundle. Use Ctrl-A to switch between consoles.
NOTE: If you are updating to vPars A.03.05, or configuring a mixed 11i v1/v2 vPars environment, you must install iCAP version 8.03 (B.11.11.08.03.00) on each HP-UX 11i v1 virtual partition. This will also install the required versions of WBEM and NParProvider and necessary patches. Installing iCAP 8.03 onto an HP-UX 11i v1 system running versions of vPars prior to A.03.05 will exhibit an error message which can be ignored, and you can proceed with updating the vPars software.
11. Update the remaining virtual partitions to vPars A.03.05. How you perform the remaining updates will depend on whether you are doing parallel or staggered updates. a. If updating all virtual partitions in parallel then perform the following steps. i. On all remaining virtual partitions: • If the HP-UX Operating Environment must also be updated, use Update-UX to install the latest OE and the vPars A.03.05 bundle to the virtual partition. In the following example the target OS will be HP-UX 11.
• On the last virtual partition, wait for the vPars A.03.05 update to complete. 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.
============================ ========== ===== 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.
◦ First updating to a mixed HP-UX 11i v1/v2 vPars environment (including vPars A.03.05 and vPars A.04.05). This process is documented in “Updating from vPars A.03.xx to Mixed HP-UX 11i v1/v2 vPars (A.03.05 and A.04.05) Environment” (page 82). ◦ Then updating the virtual partitions going to HP-UX 11i v3 from vPars A.04.05 to vPars A.05.03. See the Migrating from HP-UX 11i v1 Virtual Partitions to a Mixed HP-UX Version Environment white paper on the BSC website at http://www.hp.
NOTE: In a mixed HP-UX 11i v1/v2/v3 vPars environment, all HP-UX 11i v1 vPars must be updated to vPars A.03.05. However, before vPars A.03.05 is installed, you must install iCAP version 8.03 on each HP-UX 11i v1 virtual partition. This will also install the required versions of WBEM and NParProvider and necessary patches. Installing iCAP 8.03 onto an HP-UX 11i v1 system running versions of vPars prior to A.03.
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.
This shows that you are running an Enterprise OE. vPars Bundle Names for Update-UX For vPars, the possible vPars bundles are: T1335DC vPars A.05.xx bundle T1335CC vPars A.05.xx bundle T1335BC vPars A.04.xx bundle 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.
The first virtual partition is defined as the virtual partition that owns the boot disk from which the vPars Monitor was booted; you can use the vparstatus -m and vparstatus -v commands to determine which virtual partition this is. We wish to update to the following: • keira1 running A.05.01 (on 11.31) • keira2 running A.04.02 (on 11.23) • keira3 running A.05.01 (on 11.31) The Update Process: Step by Step The following steps should be done from the console: 1.
In our example, the first virtual partition keira1 is being updated to vPars A.05.01, so we would not need to change the nPartition PRI boot path and can proceed to the next step. However, if keira1 is being updated to only A.04.02, then we would need to change the nPartition’s PRI boot path to the boot disk of a virtual partition that is being updated to A.05.01. To do this, perform the following: a. Find the nPartition partition number for the current nPartition.
Be sure that both the OE and vPars bundles are specified on the update-ux command line. 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.
BCH> bo pri interact with IPL: y ISL> hpux /stand/vmunix Example for Integrity: Shell> fs0: fs0:\> hpux HPUX> boot vmunix b. Change the nPartition’s PRI path to the boot path of the future A.05.01 partition recorded earlier. Example: keira# parmodify -p0 -b 0.0.6.0.0.5.0 where the syntax of parmodify is c. • -p nPartition_number • -b primary_boot_path Verify the new PRI path using parstatus. If you are using the 11.31 vPars, that is, A.05.
11. Turn autoboot and autosearch settings back to their original settings that you recorded earlier above. Example: keira1 keira1 keira1 keira1 keira1 keira1 # # # # # # vparmodify vparmodify vparmodify vparmodify vparmodify vparmodify -p -p -p -p -p -p keira1 keira1 keira2 keira2 keira3 keira3 -B -B -B -B -B -B auto nosearch manual nosearch auto nosearch 12. Verify the Virtual Partitions. The virtual partitions should now be running the latest vPars version.
IMPORTANT: The mixed minor versions vPars feature is available only on HP-UX 11i v3 vPar software version 05.05.xx and later. On HP-UX 11i v2 this feature is available only for vPars version 04.07. Any other vPars version on an HP-UX 11i v2 Operating Environment is not supported. Supported vPar Configuration and OE Environments The following vPars versions are supported in various mixed HP-UX combinations in vPars environment: • HP-UX 11i v2: A.04.07 • HP-UX 11i v3: A.05.05, A.05.06, A.05.07, A.05.
• In HP-UX 11iv2 environment, except for vPars A.04.07 no other vPar versions support the mixed minor version feature. • In a mixed minor environment running HP-UX 11iv2 with vPar A.04.07, the booted monitor must always be a 11i v3 vPar monitor. This is because a 11i v2 vPar monitor is not enabled to provide all the functionality required by a HP-UX 11iv3 vPar environment. 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 keira1 keira1 keira1 keira1 keira1 # # # # # # vparmodify vparmodify vparmodify vparmodify vparmodify vparmodify -p -p -p -p -p -p keira1 keira1 keira2 keira2 keira3 keira3 -B -B -B -B -B -B manual nosearch manual nosearch manual nosearch Note that the -B nosearch option is valid for only vPars A.03.02 and later. If you are using an earlier version of vPars, you can skip thevparmodify ... -B nosearch command. 4.
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 11i v1 December 2006 or later release. This is only applicable for PA-RISC servers based on the HP sx2000 chipset (rp7440, rp8440, HP 9000 Superdome). The vPars A.03.05 vPars Monitor (vpmon) requires that all vPars be running vPars A.03.05. Earlier vPars releases are not supported by the vPars A.03.05 vpmon. NOTE: If you are updating to vPars A.03.05, or configuring a mixed 11i v1/v2 vPars environment, you must install iCAP version 8.
BCH> bo pri interact with IPL: y ISL> hpux /stand/vpmon 10. Boot all virtual partitions. 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.
If you have configured your AUTO file in the LIF area to boot the vPars Monitor and virtual partitions automatically, then this step will be performed automatically. For more information, see “Autoboot” (page 160). 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).
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 19 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.2 Bottom slimline DVD, if present 1/0/1/1/0/4/0 1/0/1/1/0/6/0 1/0/1/1/0/6/1 0/0/8/1/0/4/0 0/0/1/1/0/6/0 0/0/1/1/0/6/1 1/0/1/1/0/1/0.
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 22 rp7420 to rp7440 Hardware Path Changes (continued) rp7420 Path rp7440 Path Description 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.2 Bottom slimline DVD, if present 1/0/1/1/0/4/0 1/0/1/1/0/6/0 1/0/1/1/0/6/1 0/0/8/1/0/4/0 0/0/1/1/0/6/0 0/0/1/1/0/6/1 1/0/1/1/0/1/0.x 1/0/1/1/0/4/0.x 1/0/1/1/0/4/1.x 0/0/8/1/0/1/0.x 0/0/1/1/0/4/0.x 0/0/1/1/0/4/1.
• 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.0 the new hardware path is • 1/0/8/1/0.6.0 Not all I/O hardware paths change after the PCI to PCI-X backplane upgrade.
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 54). 3. Use ioscan to verify the hardware addresses in your virtual partition plan. # ioscan 4. Create the virtual partitions using the information you prepared in the virtual partition plan. For example, the non-nPartitionable system running A.03.
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.
# vparboot -p -I [ [-d dbprofile_name]| [-s ignite_ux_server_ip [-c client_ip -g gateway_ip -m subnet_mask] -b boot_file [-o optional_data]]] For our example, if the target partition is keira2, execute the following command from keira1: # vparboot -p keira2 -I or vparboot -p keira2 -I -s 17.2.165.152 -c 17.2.163.92 -g 17.2.165.240 -m 255.255.248.0 -b /opt/ignite/boot/nbp.efi -o IINSTALL The syntax for vPars A.05.
NOTE: So that the TERM variable will always be set correctly, you should ensure that the first virtual partition owns the hardware console port. For more information, see “Assigning the Hardware Console LBA” (page 54). • Integrity Shell> fs0: fs0:\> hpux HPUX> boot vmunix 3. Use ioscan to verify the hardware addresses in your virtual partition plan: # ioscan 4. Create the virtual partitions using the information you prepared in the virtual partition plan.
If you are at the console of winona3, use Ctrl-A to toggle to another virtual partition. CAUTION: Remove the vPars product only at the product level (VirtualPartition). Do NOT remove the vPars product at the bundle level (T1335AC or VPARSBASE). Recommended kernel patches are included in the vPars bundle; if the bundle is removed, these kernel patches will also be removed. For more information on bundles and patches, go to the BSC website at http://www.hp.
5 vPars Monitor and Shell Commands This chapter covers: • • • • • Using Integrity systems ◦ Setting Modes ◦ EFI to Hardware Path Mappings Using the vPars Monitor ◦ Booting the vPars Monitor ◦ Accessing the vPars Monitor Prompt ◦ Using vPars Monitor Commands Using the vPars Commands ◦ vPars Manpages ◦ vPars Commands Logging ◦ Obtaining vPars Monitor and Hardware Resource Information Managing the Virtual Partitions ◦ Creating a Virtual Partition ◦ Booting a Virtual Partition ◦ Shutti
Example Server Some examples in this section use the same non-cellular rp7400/N4000 configuration as in the installation chapter. See “Full ioscan Output of Non-Cellular System Named winona” (page 46). Note: unlike the rp7400/N4000, on a Superdome and other nPartition servers, the first element of the hardware path of the ioscan output is the cell number.
mode has the value of either vPars or nPars Sets the mode for the next nPartition reboot. Note that this may sometimes take a few minutes to process. CAUTION: After using vparenv to change the boot mode from vPars mode to nPars mode, further booting and loading of virtual partitions will fail although the vPars Monitor has not been rebooted. To boot or load virtual partitions, use vparenv to change the boot mode back to vPars mode.
mode has the value of only nPars. parconfig does not allow you to set the mode to vPars -n means no interactive prompts NOTE: HP recommends using vparconfig instead of parconfig whenever possible; information on parconfig is provided here as additional information or when vparconfig is not present on the disk. vparconfig is installed only on the boot disks of the virtual partitions when vPars is installed. If the boot disks are removed or you switch boot disks, you may need to use parconfig.
2 Set the mode and reboot the system. NOTE: vparconfig is an EFI utility which gets installed in the EFI partition during the installation of the vPars product. • If you are at EFI shell prompt in vPars mode and you do not have vPars installed on any of your disks, you can use the built-in EFI command parconfig to switch to nPars mode: Shell> parconfig nPars Shell> parconfig reset Note: Remember to issue a parconfig reset after setting the mode. parconfig nPars only sets the mode to nPars.
CAUTION: • When you set the mode to vPars for the first time on a system, you must use vparenv. When a vPars database does not exist on a system, first boot into nPars (standalone) mode, create the vPars database, and then use vparenv -m vPars to switch the mode to vPars. If vparconfig reboot vPars is used and vparenv -m vPars has not previously been executed on the system, it may not be possible to boot vPars.
To update the EFI path of a boot disk in the vPars database (for example, after creating a boot disk mirror), execute vparefiutil -u (-u for update) on each virtual partition. Other examples of when you should use vparefiutil include: • For a specific HP-UX hardware path, if there is no EFI path mapping, the vparboot and vparload commands will fail with the following error message: Primary boot path not found. Internal error in setting up vPars variables. "vpar" load failed.
For more information on vparefiutil and all the possible options, see the manpage vparefiutil(1M). CAUTION: It is recommended to use the documented procedure of using vparboot -I to create the virtual partitions so that users do not have to use vparload -E. For information on the vPars Monitor command vparload, see the vPars Monitor manpage vpmon(5). vparload -E works in a trial and error fashion, meaning you may have to serially attempt different disk indices.
Following are some scenarios where you may need to perform additional actions if the EFI path to hardware path mappings are not up to date in the vPars database:: • Creating an alternate vPars database while in vPars mode.
Solutions: • After creating the mirror disk, set the mirror disk as alternate path using setboot. # 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.
• A.03.xx and earlier: When the system monarch CPU is not owned by any virtual partition, you will also see the vPars Monitor prompt MON> while toggling among the virtual consoles. A monarch CPU exists in both non-vPars and vPars servers. After a server is powered-on, the monarch CPU determines what other CPUs are configured in the server and then launches the other CPUs to create a multi-CPU server.
Example: ◦ If you have a backup copy of the partition database in the file /stand/vpdb.backup, you can read the database configuration information using: MON> readdb /stand/vpdb.backup Notes: ◦ This command can only be used when the vPars Monitor /stand/vpmon is booted and the default partition database (/stand/vpdb) does not exist, the alternate partition database as specified in the -D option of /stand/vpmon does not exist, or the database file read is corrupt.
MON> vparload -p winona2 -b /stand/vmunix.prev ◦ To boot the partition winona2 using the disk device at 0/8/0/0.2.0: MON> vparload -p winona2 -B 0.8.0.0.2.0 Note: ◦ -b kernelpath allows you to change the target kernel for only the next boot of partition_name. If you wish to make a permanent change to the partition database, use the vparmodify command. For example, to change the partition database information so that winona2 always boots using /stand/vmunix.
NOTE: You should shut down each virtual partition (using the Unix shutdown command) prior to executing the vPars Monitor reboot command. A confirmation prompt is provided, but if you accept confirmation of the reboot while any virtual partitions are running, the reboot brings the running partitions down ungracefully. For more information, see “Shutting Down or Rebooting the nPartition (Or Rebooting the vPars Monitor)” (page 154).
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.
To run the same command from ISL or EFI, use ISL> hpux /stand/vpmon vparload -p winona1 Shell> fs0:efi\hpux\hpux boot vpmon vparload -p winona1 where the command (vparload -p winona) is the argument for the vPars Monitor (/stand/vpmon). Commands: vPars Manpages The purpose of this document is to describe vPars concepts and how to perform common vPars tasks.
Below are examples of vPars syslog entries. Oct 29 19:44:30 winona2 vparutil[2947]: user root: vparutil -s 1/0/0/3/1.7.
NOTE: nPartition Logs (see also “nPartition Logs” (page 35)) 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 vPars Monitor per nPartition.
• “vparstatus: Pending Migrating CPUs Operations” (page 147) • “vparstatus: Dual-Core CPUs” (page 147) • “vparstatus: CPU Information on vPars A.04/A.05” (page 145) • “vparstatus: Pending Migrating Memory Operations” (page 148) • “vparstatus: Pending nPartition Reboot for Reconfiguration” (page 149) • “vparstatus: vPars Monitor and Database Information” (page 150) NOTE: • Actual vparstatus output differs from version to version of vPars.
Virtual Partition Name ============================== thurman24 thurman25 thurman26 thurman27 Ranges/MB Total MB ====================== 0/ 0 1024 1/1024 1024 0/ 0 1024 1/ 512 1024 vparstatus: Verbose Information Use vparstatuswith verbose (-v) option. Examples • vPars A.03.
[IO Details] 1.0.12 1.0.12.1.0.4.0.8.0.255.0.2.0 BOOT [Memory Details] ILM, user-assigned [Base /Range]: 0x100000000/1024 (bytes) (MB) 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.
Example Table 27 possible commands to arrive at vparstatus output vparstatus output (final) set of possible commands in sequence to create vparstatus output keira1 # vparstatus -p keira1 [Virtual Partition Details] Name: keira1 State: Up Attributes: Dynamic,Autoboot,Autosearch Kernel Path: /stand/vmunix Boot Opts: -v # vparmodify -p keira1 -a cpu:1/10 -a cpu:1/12 (since the vpar is down, total is not modified. therefore, 2 of the 4 CPUs assigned by the Monitor become user-assigned by hardware_path (1.
Table 28 possible commands to arrive at vparstatus output vparstatus output (final) another set of possible commands in sequence to create vparstatus output 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.
Example winona1# vparstatus . . . [Virtual Partition Resource Summary] CPU Num CPU Bound/ IO Virtual Partition Name Min/Max Unbound devs ============================== ================ ==== winona1 2/ 8 2 0 2 winona2 2/ 8 2 1p 2 winona3 1/ 8 1 0 2 winona1# vparstatus -p winona2 -v ... [CPU Details] Min/Max: 1/8 Bound by User [Path]: 41 45 Bound by Monitor [Path]: Unbound [Path]: 97 (migration pending) [IO Details] 0.8.0.0.5.0 0.8 1.
ILM Total (MB): 4352 (Floating ILM Granularity (MB): 256) 0x688000000/256 (Migration pending) 128 CLM, user-assigned [CellID Base /Range]: 0 0x704c0000000/128 (bytes) (MB) CLM, monitor-assigned [CellID Base /Range]:0 0x703c0000000/384 (bytes) (MB) 0 0x70500000000/128 CLM (CellID MB): 0 640 (Floating 128) (Migration pending) CLM Granularity (MB): 128 [OL* Details] Sequence ID: 1234 Operation: Memory Addition Status: PENDING For more information on canceling pending memory or CPU operations, see “Memor
============================== keira1 keira2 Note: ================ 2/ 8 2 0 2/ 12 2 2 A profile change is pending. ==== 7 3 ==================== 0/ 0 2048 0/ 0 2048 The hard partition must be rebooted to complete it. vparstatus: vPars Monitor and Database Information Beginning with vPars A.03.
• all hardware where the LBA is at 0/8 or 1/10 • a boot disk at 0/8/0/0.5.0 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.
You need to shutdown the virtual partition before attempting removal. If the target virtual partition is running, vparremove will fail. 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.
(vPars A.04.01) For 11i v2 (11.23) systems, alternate kernels are in the directory /stand/ alternate_config/. Booting a Virtual Partition To boot a single virtual partition, use either the vPars Monitor command vparload or the shell command vparboot. (To shutdown a booted virtual partition, see “Shutting Down or Rebooting a Virtual Partition” (page 153)).
Examples • To shutdown the virtual partition winona1: winona1# vparstatus winona1# shutdown -h After winona1 is shutdown, the virtual partition is in the down state. For more information, see “Virtual Partition States” (page 140). • 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.
winona1# vparstatus winona1# shutdown -h winona2# vparstatus winona2# shutdown -h winona3# vparstatus winona3# shutdown -h 2. After the last virtual partition is shut down, you will be at the vPars Monitor prompt (MON>) on the console. a. To reboot the hard partition, use the vPars Monitor command reboot: MON> reboot b. To shut down the rp5470/L3000 or rp7400/N4000 servers, access the GSP usingCtrl-B. You can then use the GSP command PC to power off the server.
WARNING! Before modifying power settings, and for detailed warnings and information on power for nPartitionable servers, read the section “Powering Cells and IO Chassis On and Off” in the manual nPartition Administrator’s Guide available on the BSC website at www.hp.com/go/hpux-npars-docs. Setboot and System-wide Stable Storage On a vPars system, the setboot command does not read from or write to system-wide stable storage.
NOTE: • Like many other HP-UX applications, MirrorDisk/UX software is supported. However, vPars does not have a knowledge of the mirror configuration. If your boot disk is mirrored, you may want to explicitly configure the mirror disk as the alternate boot path. Also, on Integrity systems, after creating a mirrored boot disk, you will have to do either a setboot -[p|a|t] or vparefiutil -u to be able to boot from the mirror later.
• 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.0 Using vparcreate Within the vparcreate command, you can specify the primary or alternate boot paths with the BOOT and ALTBOOT attributes: • To set the primary boot path: winona1# vparcreate -p winona2 -a io:0.8.0.0.5.0:BOOT • To set the alternate boot path: winona1# vparcreate -p winona2 -a io:0.8.0.0.2.
. [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.5.0 0.0.6.0.0.6.0 BOOT ALTBOOT and its nPartition showed the nPartition’s alternate path to be 2/0/14/0/0.6.0: keira2# 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.
keira2# parmodify -p0 -t 0/0/6/0/0.4.0 Command succeeded. The nPartition’s alternate path has now changed: keira2# 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 0/0/6/0/0.4.0 0/0/6/0/0.5.
Examples • On a non-vPars server, to change the AUTO file to use the boot options -lq, the command is: ◦ PA-RISC: # mkboot -a "hpux -lq"raw_device_file ◦ Integrity: # mkboot -a "boot vmunix -lq" raw_device_file On a vPars server, to get the same effect when the partition winona2 is booted, modify the partition database using -o (boot options): # vparmodify -p winona2 -o "-lq" • On a non-vPars server, to change the AUTO file to use a different kernel, the command is: ◦ PA-RISC: # mkboot -a "hpux /stan
and after logging into winona2 which owns the alternate boot disk at 0/8/0/0.5.0, execute: 4. — PA-RISC: winona1# mkboot -a "hpux /stand/vpmon -a" /dev/rdsk/c1t5d0 — Integrity: winona1# mkboot -a "boot vpmon -a" /dev/rdsk/c1t5d0 The autoboot flag of all the virtual partitions is set to AUTO. If applicable and desired, set the autosearch flag of all the virtual partitions to SEARCH. AUTO is the default.
From HP-UX shell prompt From the HP-UX shell prompt of another virtual partition, specify the -o option with the vparboot command: winona1# vparboot -p winona2 -o "-is" Example: A Hung Partition If you wish to boot a virtual partition using vparboot into single-user mode, it must be in the down state. If you find a virtual partition is instead in the hung state, perform the following before executing the vparboot: 1. Turn off autoboot for the target partition: winona1# vparmodify -p winona2 -B manual 2.
ISL> hpux -lm On a vPars server, you specify the same -lm option but as an argument to either the vPars Monitor vparload command or as a -o option to the shell vparboot command.
1. Run lvlnboot. lvlnboot -v /dev/vg00 2. Examine the output to identify the “Boot” and “Swap” logical volumes. For example: Boot: lvol1 on: /dev/dsk/c1t6d0 Swap: lvol2 on: /dev/dsk/c1t6d0 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.
3. Remove the old information about root volume group. vgexport /dev/vg00 You may have to remove/etc/lvmtab. 4. Prepare to import the root volume group (vg00). mkdir /dev/vg00 mknod /dev/vg00/group c 64 0x000000 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.
Soft Reset On a hard partition not running vPars, a soft reset (TOC) allows HP-UX to attempt to capture a state and potentially create a crash dump and then the hard partition reboots. To issue a soft reset, the administrator types a Ctrl-B at the console to connect to a service processor and then types the command TC (transfer of control). On a hard partition running vPars, a soft reset will take dumps of all the virtual partitions2 as well as the vPars Monitor image, and then the hard partition reboots.
You could create an alternate partition database where the configuration is: Partition Name winsim1 winsim2 Bound CPUs total = 4 min = 4 total = 4 min = 4 Unbound CPUs no CPUs are available 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.
Because the local copy is now /stand/vpdb.sim, you do not need to specify the -D /stand/vpdb.sim option when performing vPars Monitor commands. For example, to set the static attribute for the partition winsim2, the command is: winsim2# vparmodify -p winsim2 -S static 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.
6 CPU, Memory, and I/O Resources (A.05.
NOTE: Some examples in this chapter may use a non-nPartitionable system where there is no cell in the hardware path. If using an nPartitionable system you must include the cell in the hardware path; read “Planning, Installing, and Using vPars with an nPartitionable Server” (page 49).
Figure 14 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 16 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 add -d delete
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.
NOTE: When assigning I/O, if you specify a path below the LBA level (for example, cell/ sba/lba/.../device, vPars automatically assigns the LBA to the virtual partition. For example, if you specify -a io:0/0/0/2/0.6.0 where 0/0/0 is the cell/sba/lba, the lba of 0/0/0 is assigned to the virtual partition. Further, this LBA assignment implies that all devices using 0/0/0 are assigned to the virtual partition. The assignment rules of LBAs remain applicable: the LBA can only be owned by one virtual partition.
Memory: Topics The memory topics in this section are: • “Memory: Concepts and Functionality” (page 176) • Assigning (Adding) Or Deleting Memory • • ◦ “Memory: Assigning (Adding) or Deleting by Size (ILM)” (page 180) ◦ “Memory: Assigning (Adding) Or Deleting by Size (CLM)” (page 181) ◦ “Memory: Assigning (Adding) Or Deleting by Address Range” (page 182) ◦ “Memory, CPU: Canceling Pending Operations” (page 201) ◦ “Memory: Converting Base Memory to Float Memory” (page 184) ◦ “Memory: Available
◦ This uses the specified cell’s CLM. The basic syntax for this is: -a|d cell:cell_ID:mem::size ◦ • For more information, see “Memory: Assigning (Adding) Or Deleting by Size (CLM)” (page 181). By address range. ◦ This uses an address range within the available nPartition’s ILM or cell’s CLM. The basic syntax for this is: -a|d mem:::base:range For more information, see “Memory: Assigning (Adding) Or Deleting by Address Range” (page 182).
There are no minimum requirements of vPars for float memory assigned to a virtual partition. NOTE: Memory is bound to a virtual partition when the virtual partition is booted, when memory is added online, and when assigned using an explicit user-specified range. Memory acquires the base or float attribute only when it is bound to a virtual partition. The available memory ranges within the vPars Monitor that are not bound to any virtual partition do not have any base or float attribute.
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.
Syntax The basic syntax for adding or deleting ILM resources assigned to a virtual partition is: -a|d mem::size[:base|float] where: -a add -d delete size the quantity of ILM in MBs base add/delete as base memory (this is the default when neither base nor float is specified) float add/delete as float memory Examples • To create the virtual partition winona2 with 1024 MB of ILM: winona1# vparcreate -p winona2 -a mem::1024 • To add 1024 MB of ILM as float memory to an existing partition winona2: w
where: -a add -d delete -m modify cell_ID the cell number size the quantity of memory in MBs base add/delete as base memory float 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.
NOTE: • Specifying an address range to a virtual partition that is down does not increase the amount of memory assigned to the virtual partition. The address range is a specific subset of the existing ILM or CLM amount assigned to the virtual partition. Therefore, the total amount of memory specified by ILM or CLM addresses cannot exceed the amount of ILM and CLM assigned to the virtual partition.
# vparstatus -A [Available ILM (Base /Range)]: (bytes) (MB) [Available ILM (MB)]: 0x3000000/80 0x10000000/512 0x50000000/768 0xb8000000/1024 0x100000000/1920 0x178000000/96 [Available CLM (CellID Base /Range)]: (bytes) (MB) [Available CLM (CellID MB)]: NOTE: 0 0x70080000000/256 0 0x700b0000000/1152 0 0x700f8000000/120 0 504 1 0 To see how memory is used by vPars in nPartitions, see Appendix D (page 288). vparstatus: Base and Float Memory Amounts With vPars A.05.
3. Remove the amount of :base memory from the target partition that you wish to convert to :float memory. keira1# vparmodify -p keira3 -d mem::512 4. Add that amount of memory as :float to the target partition. keira1# vparmodify -p keira3 -a mem::512:float 5. Boot up the target partition.
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.
where: -g is granularity ILM|CLM specifies whether the unit size is applied to ILM or CLM unit 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. y|n [vparcreate only; Integrity only] The default memory granularity for CLM and ILM is based on the total memory in the nPartition. The minimum default value is 128 MB.
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.
# vparenv -g ILM:512 -g CLM:256 1 MON> reboot 2 ... HPUX> boot vpmon -D /stand/vpdb.alt 1 2 3 3 Set granularity value in firmware. Reboot the nPartition. Load the alternate vPars database.
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: Notes on vPars Syntax, Rules, and Output Memory: CLI Rules for Dynamic Migration of Memory Note the following CLI (Command Line Interface) rules for online migration of memory and CPUs while the target partitions are up.
• Memory is allocated in multiples of granule size. • On cellular systems that have System Firmware (SFW) version 6.xx or later installed, a non-optimal memory configuration may result in CLM memory in the vPars available memory, even though CLM is not configured. This is new behavior, and must not be considered an error. This behavior occurs because the firmware returns a portion of the memory reserved for the firmware back to the operating system as CLM.
processor. Note that the specific CPU chosen as the boot processor may differ across virtual partition reboots. Dynamic CPUs These are all the other CPUs, because all CPUs, except the boot processor of each virtual partition, can be dynamically migrated. You can find which CPU is the boot processor by using the vparstatus command; see “Commands: Displaying vPars Monitor and Resource Information (vparstatus)” (page 140).
NOTE: CPU deletion fails when deletion by total and by CLP are given in the same vparmodify command. In this situation, the CPU deletion by total fails with the error message “vPar does not own enough Monitor-assigned CPUs to satisfy the request” although there are enough monitor-assigned CPUs. Instead, issue separate vparmodify commands to delete by total and delete by CLP.
keira1# vparmodify -p keira2 -m cpu::2 • If you would like to add 1 CPU to an existing partition, regardless of its current CPU count, you can add 1 CPU by using the -a option and setting num to 1: keira1# vparmodify -p keira2 -a cpu::1 To remove the added CPU from the partition, use the -d option and set num to 1: keira1# vparmodify -p keira2 -d cpu::1 CPU: Adding or Deleting by CLP (Cell Local Processor) Similar to CLM (cell local memory), CLP (cell local processor) refers to CPUs on a specific cell.
To decrease the number of CPUs by 2 using the CPUs of cell 6: keira1# vparmodify -p keira2 -d cell:6:cpu::2 CPU: Adding or Deleting by Hardware Path The syntax for specifying by hardware path is: -[a|d] cpu:hw_path where: -a add -d delete hw_path the hw_path (you can find the hardware path using ioscan or vparstatus -v) NOTE: The target virtual partition can be up or down when specifying by hardware path.
• ◦ 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.
Determining If the System Has Dual-Core Processors 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: # 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.
The hardware paths for the sibling pairs are 0/10 0/12 0/14 0/16 and and and and 0/11 0/13 0/15 0/17 After vPars is installed, you can also use the vPars Monitor’s scan command to show hardware paths.
Hyperthreading is supported within vPars A.05.xx environments. However, note the following details. • HT ON/OFF can be set using any of the following commands. ◦ The vPar Monitor’s threads command.
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 v2 and later, the software for intctl is part of the Core OS. For more information, see the Interrupt Migration Product Note available on the BSC website at http://www.hp.com/go/bizsupport or see the intctl(1M) manpage. Notes • At boot time of a virtual partition, interrupts are processed by all the CPUs in the virtual partition.
NOTE: On a vPars system, when a virtual partition goes down and contains a deconfigured or deactivated CPU, the vPars Monitor will try to decommission the CPU from use and replace it with another good CPU if possible. If this is not possible, the vPars Monitor will not allow the partition to boot until the deconfigured or deactivated CPU can be taken out of use.
Table 31 Values for the Status field State Definition Pending The requested operation is pending. When this is the Status value, you can cancel the operation. Pass The requested operation has completed successfully. Fail The requested operation has encountered an early failure before it started on the target operating system. It will not have a valid SequenceID.
The vparstatus output shows that a pending online addition of memory has been assigned the sequenceID of 1234. 2. To cancel this pending operation, use the -C sequenceID option of the vparmodify command.
7 CPU, Memory, and I/O Resources (A.04.xx) Managing Hardware Resources • I/O Allocation (Adding or Deleting I/O Resources) • Memory Allocation (Firmware Configuration and Adding or Deleting Memory Resources) • CPU Allocation (Adding or Deleting CPU Resources) • Using iCAP (formerly known as iCOD) with vPars • CPU Monitor (deallocation and deconfiguration) NOTE: Some examples in this chapter may use a non-nPartitionable system where there is no cell in the hardware path.
NOTE: Regarding syntax and how vPars commands interpret what is specified on the command line, see “I/O: Allocation Notes” (page 207). 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 23 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 is adding -d is
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: • An LBA can be assigned to at most one virtual partition at any given time.
# 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.) and the boot disk is specified using the full hardware path (-a io:0.0.0.2.0.6.0). For information on using the LBA level on nPartitionable systems, also see “Planning, Installing, and Using vPars with an nPartitionable Server” (page 49). • SBA/LBA versus cell/SBA/LBA When viewing hardware paths, note the following: 1.
• by size this uses the nPartition’s ILM. • by cell and a corresponding size this uses the specified cell’s CLM. Within the available nPartition’s ILM or cell’s CLM, you can also: • specify an address range to use This does not increase the amount of memory assigned to the virtual partition. The address range is a specific subset of the existing ILM or CLM amount assigned to the virtual partition.
The syntax to assign an amount of CLM is: -a|d cell:cell_ID:mem::size where: -a is adding -d is deleting cell_ID is the cell number size is the quantity of memory in MBs Example • To add 1024 MB of memory from cell 6 (at least 1024 MB must already be configured as CLM) to the existing partition keira2: keira1# vparmodify -p keira2 -a cell:6:mem::1024 • You can set both ILM and CLM memory on the same partition.
CAUTION: Normally, ranges are granule-aligned (in other words, the starting address and the ending address of the range is a multiple of a granule). However, due to memory fragmentation, some of the ranges may not be granule-aligned. It is not recommended to assign such nongranulealigned ranges as user-specified ranges (mem:::base:range).
Granularity Value Locations Integrity Systems. There are two areas where granularity values are set: 1. The nPartition firmware, specifically the EFI variables in NVRAM (non-volatile RAM). 2. The vPars database. In order for the virtual partitions in the vPars database to be able to boot, the granularity values in the vPars database must match the granularity values in the firmware.
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 213) 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.
vparenv # vparenv -g ILM|CLM:unit writes the unit granularity value to firmware. This takes effect for the nPartition on the next nPartition boot. For example, to set the granularity unit size in firmware for ILM to 512 MB and for CLM to 256 MB: # vparenv -g ILM:512 -g CLM:256 Note that this does not set the granularity value in the vPars database. Only vparcreate sets the granularity value in the vPars database.
1. 2. You are in a vPars environment, running the default vPars database of /stand/vpdb that uses the 128 MB granularity values for ILM and CLM. Because the virtual partitions have been booted successfully, this means that the current firmware 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.
incorrectly using the initial vparcreate command, you cannot adjust it later. You must re-create the vPars database. Usage Scenario In standalone mode, you create your first virtual partition with a 256 MB granularity value for both ILM and CLM. The command is: # vparcreate -g ILM:256 -g CLM:256 -p keira1 ... This writes the granularity values to the vPars database.
For additional information on using iCAP (formerly known as iCOD), including temporary-iCAP CPUs with vPars, see “CPU: Using iCAP (Instant Capacity on Demand) with vPars (vPars A.04.xx and iCAP B.07)” (page 225). NOTE: Using vPars A.03.xx and Earlier Syntax on a vPars A.04.xx System Although not recommended under most circumstances, you can still use the vPars A.03.xx CPU syntax on vPars A.04.xx systems. However, the concepts and rules of boot processors and dynamic CPUs in A.04.
Examples • To set the minimum number of CPUs to 2: keira1# vparmodify -p keira2 -m cpu:::2 • To set the minimum number of CPUs to 2 and the maximum to 4: keira1# vparmodify -p keira2 -m cpu:::2:4 CPU: Adding and Deleting by Total The basic syntax for adding and deleting CPUs is: -a|d|m cpu::num where: -a|d|m specifies adding, deleting, or modifying the total count of CPUs num specifies the number of CPUs NOTE: CPU deletion fails when deletion by total and by CLP are given in the same vparmodify comm
• -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.
NOTE: CPU deletion fails when deletion by total and by CLP are given in the same vparmodify command. In this situation, the CPU deletion by total fails with the error message “vPar does not own enough Monitor-assigned CPUs to satisfy the request” although there are enough monitor-assigned CPUs. Instead, issue separate vparmodify commands to delete by total and delete by CLP.
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 vPars Monitor), use the same method—by CLP, by hardware path, or by count—on your deletion command line that you used on your addition command line. • The current boot processor can not be deleted from a virtual partition. (Use vparstatus -v to determine the current boot processor.
Activating and Deactivating CPUs When you are in standalone (PA-RISC) or nPars (Integrity) mode, you can activate CPUs using the icod_modify -a command. Then, while you are in the vPars environment or vPars mode, you can use vparmodify -a as long as you do not go above the number of Intended Active CPUs (see “Intended Active Boundary” (page 226)). 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.
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.
• CPU 0/14 (owned by vpar4) and CPU 0/15 (unassigned) • CPU 1/14 (unassigned) and CPU 1/15 (unassigned) 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.
NOTE: On a vPars system, when a virtual partition goes down and contains a deconfigured or deactivated CPU, the Monitor will try to decommission the CPU from use and replace it with another good CPU if possible. If this is not possible, the vPars Monitor will not allow the partition to boot until the deconfigured or deactivated CPU can be taken out of use.
8 CPU, Memory, and I/O Resources (A.03.xx) NOTE: The A.03.xx release of vPars, and therefore this chapter, applies only to PA-RISC systems. Managing Hardware Resources • I/O Allocation (Adding or Deleting I/O Resources) • Memory Allocation (Adding or Deleting Memory Resources) • CPU Allocation (Adding or Deleting CPU Resources) • CPU Monitor (deallocation and deconfiguration) NOTE: Some examples in this chapter may use a non-nPartitionable system where there is no cell in the hardware path.
NOTE: Regarding syntax and how vPars commands interpret what is specified on the command line, see “I/O: Allocation Notes” (page 234). 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 30 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 is adding -d is
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: • An LBA can be assigned to at most one virtual partition at any given time.
#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.
Assignments You assign memory to a virtual partition: • by size This uses the nPartition’s ILM. Within the available nPartition’s ILM, you can also: • specify an address range to use This does not increase the amount of memory assigned to the virtual partition. The address range is a specific subset of the existing ILM amount assigned to the virtual partition. Therefore, the total amount of memory specified by ILM addresses cannot exceed the amount of ILM assigned to the virtual partition.
NOTE: Specifying an address range does not increase the amount of memory assigned to the partition. Rather, it only specifies addresses to use for the already allocated memory sizes. Therefore, all specified ranges cannot exceed the total allocated memory for the virtual partition. In other words, the sum of the ILM-specified ranges cannot exceed the total amount of ILM memory reserved for the virtual partition.
CPU NOTE: Processor Terminology Processing resources under vPars, both as input arguments and command outputs, are described as “CPUs.” For multi-core processors such as the PA-8800, the term “CPU” is synonymous with “core.” The term “processor” refers to the hardware component that plugs into a processor socket. 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.
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.
• 1 <= min <= total <= max • hw_path is the hardware path of a bound CPU. If not specified, the vPars Monitor chooses the hardware path. Note on vparmodify Syntax The vparmodify command follows a similar syntax, except that vparmodify allows the -m (modify) option as well as the -a (add) or -d (delete) option. With the -m option, the number used with the -m is an absolute number.
CPU: Removing a Bound CPU To remove a bound CPU from a virtual partition, use the vparmodify command to modify the total and min parameters for the virtual partition. NOTE: When executing any operations relating to bound CPUs (adding, modifying, or deleting), the target virtual partition must be down.
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.xx and earlier): # vparcreate -p winona2 -a cpu::3 -a cpu:::2 • To add an unbound CPU to an existing partition, use the vparmodify command to either modify the total number of CPUs (-m cpu::total) or add to the total number of CPUs (-a cpu::total).
For more information, see the Interrupt Migration Product Note available on the BSC website at http://www.hp.com/go/bizsupport or see the intctl(1M) manpage. Notes • Interrupts are processed only by bound CPUs. • Therefore, when managing I/O interrupts with intctl, you can manage the I/O interrupts only among the bound CPUs. • Further, disabling interrupts on a bound CPU does not convert the bound CPU into an unbound CPU.
Figure 31 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
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 on the BSC website at www.hp.com/go/hpux-npars-docs. 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 23). • For more information, see “Shutting Down or Rebooting the nPartition (Or Rebooting the vPars Monitor)” (page 154) and the vPars Monitor command “reboot [mode]” (page 135).
1 0/1/0 2 1.4 GHz 6 MB None 20/00 C0 Active CPU threads are turned off. • to show only the state of the threads: Shell> cpuconfig threads cpuconfig: Threads are turned off. • to turn HT ON: Shell> cpuconfig threads on cpuconfig: Threads will be on after a reset. Shell> cpuconfig PROCESSOR MODULE INFORMATION Cell ---1 Cab/ Cell Slot/ CPU Module -----0/1/0 # of Logical CPUs ------2 Speed -------1.4 GHz L3 Cache Size -----6 MB L4 Cache Size -----None Family/ Model (hex.
Cell ---1 Cab/ Cell Slot/ CPU Module -----0/1/0 # of Logical CPUs ------4 Speed -------1.4 GHz L3 Cache Size -----6 MB L4 Cache Size -----None Family/ Model (hex.) ------20/00 Processor Rev State --- ------------C0 Active CPU threads are turned off.
Reconfiguring an nPartition (Integrity) NOTE: On an Integrity server, the OS kernel in nPars mode needs to write the new CPU mapping data to certain EFI variables; in order for this to occur properly, a complete reboot in nPars mode is required after the parmodify operation has taken affect. From nPars mode: 1. Perform the changes as you would in a non-vPars environment.
Shell> fsN: fsN:\> efi\hpux\hpux /stand/vmunix 5. Once the system boots into nPars mode, the OS kernel automatically will write the correct CPU mapping data to EFI. Now you can reboot the nPartition back into vPars mode and reboot the vPars Monitor. keira# vparenv -m vPars keira# shutdown -r ... fs0:\EFI\HPUX> boot vpmon ... Reconfiguring an nPartition (PA-RISC) For the following example, the virtual partitions keira1 and keira2 exist within the nPartition 0. Only relevant output is shown. 1.
Cell ---0 Cab/ Slot ---0/0 Cell State -----------Idle 1 0/1 Active ------- Processor -------# Speed State --- -------- ----------0A 1000 MHz Idle 0B 1000 MHz Idle 1A 1000 MHz Idle 1B 1000 MHz Idle 2A 1000 MHz Idle 2B 1000 MHz Idle 0A 1000 MHz Active 0B 1000 MHz Idle 1A 1000 MHz Idle 1B 1000 MHz Idle 2A 1000 MHz Idle 2B 1000 MHz Idle Primary Boot Path: Boot Actions: 1/0/0/3/0.6 Go to BCH. HA Alternate Boot Path: Boot Actions: 1/0/0/3/0.6 Go to BCH.
. . Configuring CLM for an nPartition ILM memory can be re-configured to be CLM using the parmodify command. Then, you can assign existing available CLM to a virtual partition. For complete information on CLM and configuring cells and nPartitions, see the nPartition’s Guide. parmodify syntax The syntax for the parmodify command is parmodify -pnPar_num -mcell:[type]:[use]:[fail][:clm] where nPar_num is the nPartition number cell is the cell to be modified.
• nPartition configuration rules limit the minimum amount of configured CLM memory for a cell. If you have any CLM on a cell, it must be at least 512 MB. • When performing parmodify commands within a vPars environment, you will see only the cells that are within the nPartition running vPars. If you wish to add cells from outside the nPartition, you will need to be in standalone (PA-RISC) or nPars (Integrity) mode to see the other cells.
CAUTION: • • If you reduce the ILM amount below that configured for all the virtual partitions in your vPars database, one or more of the virtual partitions may not boot. Be sure that there is enough CLM and ILM configured in the nPartition so that the sum of ILM and CLM memory of all your virtual partitions does not exceed the ILM and CLM in the nPartition. New servers should be set with 100% ILM and 0% CLM. However, a firmware update or even another systems administrator can change these values.
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 : 256 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 vPars Monitor. When the vPars Monitor crashes, a vPars Monitor dump is created. By default, kernel dumps are not saved.
Enter Address: quit 2. 3. 4. 5. 6. 7. continues with the default crash handling (PA-RISC only) allows you to chose an alternate device to which the vPars Monitor dump is written. The alternate device must contain the pre-allocated file /stand/vpmon.dmp. The file vpmon.dmp is automatically created in/standof a partition’s boot disk by the vPars startup script. soft resets the current hard partition4. hard resets the current hard partition.
1. (11i v2 and above) Beginning with HP-UX 11i v2 and therefore vPars A.04, the savecrash processing has changed. Instead of copying the kernel file that was in use during the crash, the directory /stand/crashconfig is copied. Therefore, prior to executing the crashconf and savecrash steps below, create the /stand/crashconfigdirectory using # kconfig -s crashconfig Or if the kernel configuration used in the last boot is different from the current kernel configuration, use the -c option.
• make_tape_recovery within a vPars-environment in conjunction with a disk-based Ignite-UX boot helper, see “Using make_tape_recovery and Dual-media Boot” (page 264) • make_tape_recovery within a vPars-environment, see “Using make_tape_recovery within a vPars Environment” (page 265) • golden images for recovery, see the white paper Using Golden Images with Virtual Partitions • peripheral boot devices, see the white paper Booting, Installing, Recovery, and Sharing in a vPars Environment from DVD/CDROM
4. 5. Run the Ignite-UX recovery as you would on a hard partition not running vPars, entering the data (boot disk and LAN) of the target partition. After the target partition has been recovered: a. if the autoboot attribute has been changed, set it back to what was recorded in the first step. For example, to set the autoboot attribute back to manual: winona1# vparmodify -p winona2 -B manual b.
• Boot the vPars Monitor from an alternate boot disk with the current vPars database. When the recovered virtual partition is booted, the database will be synchronized with the current configuration. • Recover an up-to-date database file from a backup before booting the vPars Monitor. • Boot the vPars Monitor and the recovered partition, and then update the configuration with vparmodify, vparcreate, and vparremove.
a. b. 6. 7. Correct the primary and alternate boot paths if necessary by using setboot. This works at this step because vPars is not active. Correct the autoboot setting if necessary (mkboot -a “string” /dev/rdsk/:AUTO where /dev/rdsk/ is the boot device for the system and “string” is the contents of the AUTO file from step 2b above. The device file name may be different from that found in step (2)(a). Reboot the nPartition.
8. Use vparboot -I to recover the other virtual partitions using the make_net_recovery files created in step (2). 9. There may be normal filesystem recoveries that need to be done to fully recover the virtual partitions after they are booted in step (8). 10. Modify the autoboot string (using mkboot -a ...) so that the virtual partitions will autoboot at the next system boot. 11. Reboot the nPartition to test if all the virtual partitions come up as expected.
Recovering the Virtual Partition NOTE: 1. The target virtual partition (the partition that is being recovered) must own a tape device. Make sure the target virtual partition is in the down state. For example, if it is up, shutdown the virtual partition: winona2# shutdown -hy 0 2. Boot the virtual partition. The exact vparboot command line depends on how you set up the install kernels. For example, if you used bootsys, use this command: winona1# vparboot -p winona2 -B hardware_path -b /stand/WINSTALL 3.
[IO Details] 1.0.14 1.0.12 1.0.14.0.0.4.0.10.0.0.0.0.0 BOOT 1.0.14.0.0.4.0.5.0.0.0.0.0 TAPE . . . Archiving The process of creating an archive is the same as for non-vPars OS instances: # make_tape_recovery -A -a /dev/rmt/1mn Recovering To begin recovery, specify the -B TAPE option to boot the target virtual partition using a tape drive: winona1# vparboot -p winona2 -B TAPE On HP Integrity systems, all tape devices assigned to the virtual partition are listed. Select the one from which to boot.
11 vPars Flexible Administrative Capability This chapter discusses the concepts and tasks on using the vPars Flexible Administrative Capability feature (formerly called Primary-Admin vPars Security). With this feature, you can specify vPars administration capabilities for zero, one, or more designated virtual partitions.
Terms and Definitions target partition This is the virtual partition that is affected when a vPars command is executed. For example, in the command: # vparmodify -p winona2 -a cpu::1 ... an attempt is made to add a CPU to winona2, so winona2 is the target virtual partition. The argument of the -p option is the target partition. local partition This is the virtual partition from which a vPars command is executed.
designated-admin virtual partition, the command will not be successful. designated-admin virtual partition list This is the list of virtual partitions that are currently set as designated-admin virtual partitions. If a virtual partition is in this list or added to this list, it is a designated-admin virtual partition. If a virtual partition is not in this list or is deleted from this list, it is a non-designated-admin virtual partition.
• 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 virtual partition list • list which virtual partitions are currently in the designated-admin virtual partition list (in other words, are set as designated-admin virtual partitions) Basic Syntax and Usage monadmin [-S on|off] | [-a|-d partition_name] | [-l
-S on|off • Sets the flexible administrative capability mode either ON (enabled) or OFF (disabled). ◦ ON and OFF are not case-sensitive. ◦ The flexible administrative capability mode can be set only at the vPars Monitor prompt (MON>). ◦ By default, the mode is OFF. When the mode is set to ON, the list of designated-admin virtual partitions is empty, regardless of any previous settings.
• display whether the vPars flexible administrative capability feature is ON (enabled) or OFF (disabled) • change the flexible administrative capability password • specify a virtual partition to be added or deleted to or from the designated-admin virtual partition list • list which virtual partitions are currently in the designated-admin virtual partition list (in other words, are set as designated-admin virtual partitions) Basic Syntax and Usage vparadmin [-C] | [-a|-d partition_name] | [-l] -C •
vPars Commands When the flexible administrative capability mode is ON, the vPars flexible administrative capability feature restricts the vPars commands such that you can alter another virtual partition only if you execute the command from a partition that is in the designated-admin virtual partition list. When you execute the command from a non-designated-admin virtual partition, if the command alters another virtual partition, it will not be allowed. (A.03.
NOTE: When the Target Partition is the Local Partition If you use a command that alters a virtual partition but you execute it from the partition itself (in other words, the target partition equals the local virtual partition), this is allowed. For example, winona2# vparmodify -p winona2 -a cpu::1 Because you are not modifying another virtual partition, this will be allowed even if winona2 is not a designated-admin virtual partition.
Example HP-UX Shell Scenario (vparadmin) Below describes examples that include (from the HP-UX shell): • a command successfully executed • a command not executed due to the flexible administrative capability feature • adding a virtual partition to the designated-admin virtual partition list • deleting a virtual partition from the designated-admin virtual partition list • listing the virtual partitions in the designated-admin virtual partition list • changing the flexible administrative capability
winona1# vparadmin -l ---------- Designated-Admin virtual partitions ---------winona1 Only winona1 is displayed as a designated-admin virtual partition. Since winona2 (and winona3) are not in the list, they are not designated-admin virtual partitions. Changing the Flexible Administrative Capability Password We can change the flexible administrative capability password with the vparadmin -C command.
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.
The virtual partition manager has special features to save you time and effort: • with a command-line parameter, you can start vparmgr directly in the task that you want to perform • after using the graphical interface to select the task and options that you want to perform, vparmgr can show you the command line that would perform the operation directly. Starting the Virtual Partition Manager Before you can start the virtual partition manager, vPars must be installed and running.
Figure 32 vPars GUI Status Screen This displays the status of all of the virtual partitions and available resources on the system. To perform an action on an object (a virtual partition or a set of available resources), click on the object in the list and then click the button corresponding to the action that you want to perform on that object.
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 34 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 Ba
rp8400 PCI I/O Block Diagram Figure 36 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 37 Superdome (SD16000, SD32000, SD64000) I/O Hardw
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.
Unbound CPU Kernel Entries x06 x06 x06 x07 x07 x07 x08 x08 x08 Paths of Unbound CPUs x06, x07, x08 Looking at vpar3, because kernel entries for CPUs at x06, x07, and x08 exist, any of the unbound CPUs (x06, x07, or x08) can be added to vpar3. They could also be added to vpar1 or vpar2.
The Workaround: Reboot the Target Virtual Partition Because unbound CPU kernel entries are created when the target partition is booted, you can reboot the target partition so that kernel entries created correctly reflect the available unbound CPUs. In our example, if we want to add an unbound CPU to vpar3, we can reboot vpar3: vpar3# vparstatus vpar3# shutdown -r When vpar3 boots again, its kernel will create the correct entries for the unbound CPUs, which are now at x03 and x04.
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
E Moving from a Standalone to vPars A standalone system running a single instance of HP-UX can be further divided into multiple virtual partitions. This section provides a brief overview of the process for moving from a standalone system environment to a virtual partitions environment. Converting a standalone system to a virtual partitions environment divides system resources among the virtual partitions and enables the system to run multiple instances of HP-UX.
F Supported Configurations for Memory Migration HP-UX 11i v3 (11.31) supports dynamic memory migration in conjunction with vPars. To optimize runtime performance as well as memory migration performance, system administrators configure the amount of memory that is available for critical system needs and the amount of memory that may be deleted without a reboot.
Glossary All vPars Versions core The actual data-processing engine within a processor. A single processor might have multiple cores. Sometimes referred to as a “processing core”. See also processor. dynamic CPU migration The vPars ability to add or remove CPUs (cores) while a virtual partition is running. hard partition Any isolated hardware environment, such as a rp7400 server or an nPartition within a Superdome complex.
CLP (Cell Local Processor) A CPU (core) on a specific cell in an nPartition. Using CLP notation to add or delete CPUs from a virtual partition specifies the cell where the CPU resides. ILM (Interleaved Memory) The nPartition’s system default is to have all memory configured as ILM. vPars A.05.xx-specific Terms base memory This is memory that can be only added to virtual partitions while the virtual partition is up. This memory cannot be deleted from a virtual partition while it is up.
Index Symbols /stand filesystem, 72 A adding cpu to a partition, 191, 219, 238 adding i/o to a partition, 173, 174, 206, 207, 233, 234 adding memory resources to a partition, 176, 208, 235 alternate partition database files, 167 application fault isolation, 18 attributes, 152 AUTO file, 160 Autoboot, 55, 161 B BCH.
E K EFI, 36, 128, 137 EFI paths, 128 expert recovery, 21, 266 kernel size, 51 vmunix file, 31 F L flexibility independent operating system instances, 18 floater CPUs. See unbound CPUs, 239 lan cards, 76, 118 lan path, 55 LBA concepts, 171, 204, 231 LBA.
vparinfo, 137 vparload, 134, 162, 163 vparreset, 163 crash dump files, 258 prompt, 132 vpmon file, 29, 31, 154, 258 monitor prompt toggling past, 35 N NO_HW (ioscan output), 23, 34 nPartition, 17, 246 Adding a cell, 249 Reboot for Reconfiguration, 149, 250, 251 O ODE, 20 OLAR.
toddriftreset, 22, 137 U unbound CPUs, 239 Uninterruptible Power Supply, 22 Update-UX, 78, 82, 85, 96, 97, 105 Updating, 78, 83, 96, 106 UPS.
