HP-UX Virtual Partitions Administrator Guide March 2012 HP Part Number: 5900-2188 Published: March 2012 Edition: 21
© Copyright 2011, 2012 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...................................................................................13 Publication History..................................................................................................................13 1 Introduction.............................................................................................15 What Is vPars?.......................................................................................................................
vPars A.03.xx and earlier...............................................................................................50 Memory...........................................................................................................................50 I/O..................................................................................................................................51 Assigning I/O at the LBA Level........................................................................................
OE Bundle Names for Update-UX...................................................................................76 The Update Process: Goal...................................................................................................76 The Update Process............................................................................................................76 Updating from vPars A.03.xx to Mixed HP-UX 11i v1/v2 vPars (A.03.05 and A.04.05) Environment..................................................
Commands to Set the Mode..............................................................................................120 Differences Between vparconfig and parconfig................................................................122 Usage Scenarios..............................................................................................................122 EFI Boot Disk Paths, including Disk Mirrors, and vparefiutil (Integrity Only)...................................
Verification.................................................................................................................159 Preparation................................................................................................................160 Change the boot device hardware path.........................................................................160 Boot into LVM maintenance mode.................................................................................160 LVM maintenance mode steps..
CPU: Concepts and Functionality............................................................................................186 CPUs: Definitions for CPUs................................................................................................186 CPU: Specifying Min and Max Limits......................................................................................187 CPU: Adding and Deleting by Total........................................................................................
Usage Scenarios..............................................................................................................212 Memory: Setting the Granularity Values (PA-RISC).....................................................................213 Syntax............................................................................................................................213 Commands.....................................................................................................................
CPU: Determining When to Specify a Hardware Path for a Bound CPU.......................................233 CPU: Adding and Removing Bound CPUs ...............................................................................233 CPU Allocation Syntax In Brief...........................................................................................233 Syntax for vparcreate...................................................................................................233 Note on vparmodify Syntax............
Recovering the Virtual Partitions Using one of the Virtual Partitions as the Ignite-UX Server...................................................................................................................256 Using make_tape_recovery and Dual-media Boot.................................................................257 Setting Up a Disk for Dual-Media Recovery....................................................................257 Recovering the Virtual Partition..........................................
C Calculating the Size of Kernels in Memory (PA-RISC only)............................279 Calculating the Size of a Kernel..............................................................................................279 Examples of Using the Calculations.........................................................................................279 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.
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.
• 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.
• (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.xx or later, the WINSTALL path has changed to: ◦ /opt/ignite/boot/Rel_B.11.NN/?INSTALL ◦ – ◦ For example, if vPars is using HP-UX 11i v2 (11.
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. As with most curses applications, if you get a garbled display, you can press Ctrl-L to refresh the display. • ServiceGuard ServiceGuard is supported with vPars.
Ultra2/Ultra160 SCSI HBAs, the SCSI parameters can only be set from the BCH prompt (on PA-RISC) or from the EFI Shell prompt using EFI applications (on Integrity). For information on setting and confirming SCSI parameters for Ultra2/Ultra160 HBAs, see the HP A6828A PCI Ultra160 SCSI Host Bus Adapter: Service and User Guide.
• top and other applications that show CPU ID The CPU ID displayed by the top command and other applications may not be indicative of the actual CPU index in standalone or nPars mode, nor of the actual hardware path. Within a virtual partition, top sees only the CPUs assigned to it. Possible top output is shown below; the CPU index is the left-most column. CPU 0 1 2 4 7 8 --avg • LOAD 0.01 0.00 0.01 0.01 0.01 0.06 ---0.02 USER 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% ----0.0% NICE 0.0% 0.0% 0.0% 0.0% 0.0% 0.
• 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 61). 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: 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 252) and “Using an Alternate Partition Database File ” (page 162). You can create, modify, and view the database contents using vPars commands at the Unix shell level. See “vPars Monitor and Shell Commands” (page 119).
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.
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 68). • 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.
4. 5. 6. 7. 8. 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. Use the vparenv command to switch to vPars mode. 11. Reboot the nPartition.
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 29). See “vPars Monitor: Booting the vPars Monitor” (page 127). See “Autoboot” (page 155). 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 (continued) vPars Version A.03.xx A.04.xx A.05.xx 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.05 and no later) vPars Monitor Supports mixed HP-UX 11i no v2/v3 vPars no yes vPars Monitor Supports mixed HP-UX 11i no v1/v2/v3 vPars no yes (vPars A.05.
Table 2 Differences Among vPars Versions (continued) vPars Version A.03.xx A.04.xx PPU Supported Products Percent Utilization Both Percent Utilization Both Percent Utilization and Active CPU and Active CPU Setting SCSI Parameters vparutil mptconfig 1 2 A.05.xx mptconfig Dynamic memory migration requires the firmware revisions indicated in the HP-UX Virtual Partitions Ordering and Configuration Guide.
This table summarizes the A.04.xx and A.05.xx CPU syntax and rules Table 5 CPU Syntax from A.03.xx to A.04.xx/A.05.xx vPars A.03.xx Syntax vPars A.04.xx/A.05.
Table 6 CPU Rules from A.03.xx to A.04.xx/A.05.xx (continued) vPars A.03.xx Rules vPars A.04.xx/A.05.
Table 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 54) • “Mixed HP-UX 11i v2/v3 vPars Environments in vPars A.05.xx” (page 56) • “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/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.6 target 1/0/0/3/0.6.
I/O Hardware Paths For non-nPartitionable systems, the beginning portions of the I/O hardware paths are in the format: • sba/lba But for nPartitionable systems, the beginning portions of the I/O hardware paths include the cell and are in the format: • cell/sba/lba Impact on vPars Commands: Specifying I/O On a non-nPartitionable system, a vparcreate command might look like: # vparcreate -p winona1 -a cpu::2 -a cpu:::2 -a mem::1024 -a io:0.0 -a io:0.4 -a io:0.0.2.0.6.0:BOOT • where -a io:0.
where 0/12 and 0/13 are the cell/CPU hardware paths, then the vparcreate command would look like: # vparcreate -p vpar2 -a cpu::2 -a cpu:::2 -a cpu:0/12 -a cpu:0/13 ... Planning Your Virtual Partitions Virtual Partitions Layout Plan Before you install vPars, you should have a plan of how you want to configure the virtual partitions within your server. Example of a virtual partition plan for vPars A.04.xx based on the example cellular server: Partition Name keira1 keira2 keira3 Assigned CPUs (A.04.
The next few sections will describe how we arrived at each portion of the partition plan. Number of Virtual Partitions For the latest information on the recommended and maximum number of virtual partitions per system or nPartition, see the document HP-UX Virtual Partitions Ordering and Configuration Guide available on the BSC website at: www.hp.com/go/hpux-vpars-docs Virtual Partition Names All virtual partitions must be given text names that are used by the vPars commands.
====================================================== 0/10 processor Processor 0/11 processor Processor 0/12 processor Processor 0/13 processor Processor 0/14 processor Processor 0/15 processor Processor 1/10 processor Processor 1/11 processor Processor 1/12 processor Processor 1/13 processor Processor 1/14 processor Processor 1/15 processor Processor winona# ioscan -kC processor H/W Path Class Description ====================================================== 33 processor Processor 37 processor Processor
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. For this reason, we currently recommend that 1 GB of base memory is assigned per vpar. The more base memory a virtual partition has, the better the performance will be.
1/8 1/10 1/12 ba ba ba Local PCI Bus Adapter (782) Local PCI Bus Adapter (782) Local PCI Bus Adapter (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.4 boot Assigning the Hardware Console LBA One of the virtual partitions must own the LBA that contains the physical hardware console port.
Choosing the Boot and Lan Paths Using the full ioscan output, we chose the following boot disk path and note the LAN card path: Partition Name keira1 keira2 keira3 Boot Path 1/0/0/3/0.6.0.0.6.0 1/0/4/1/0/4/0.1.0.0.0.0.1 0/0/0/3/0.6.0 LAN 0/0/1/1/0/4/0 1/0/1/1/0/4/0 0/0/2/1/0 Partition Name winona1 winona2 winona3 Boot Path 0.0.2.0.6.0 0.8.0.0.5.0 1.4.0.0.5.0 LAN 0.0.0.0 1.10.0.0.4.0 0.5.0.0.4.
console port (PA-RISC Only) owned by keira1 Autoboot AUTO MANUAL AUTO Partition Name winona1 winona2 winona3 Bound CPUs (A.03.xx) total = 2 min = 2 total = 2 min = 2 paths = 41,45 total = 1 min = 1 Unbound CPUs (A.03.xx) three CPUs are available Memory 1024 MB 1280 MB 1280 MB I/O LBAs 0.0 0.4 0.8 1.10 0.5 1.4 Boot Path 0.0.2.0.6.0 0.8.0.0.5.0 1.4.0.0.5.0 LAN 0.0.0.0 1.10.0.0.4.0 0.5.0.0.4.
• HP-UX 11i v1 virtual partitions (running vPars A.03.05) can use vparmodify on itself only, and cannot use the vparcreate and vparremove commands. Thus, in a mixed HP-UX 11i v1/v2 vPars environment, an HP-UX 11i v1 virtual partition cannot remove virtual partitions, cannot create new virtual partitions, and can modify only itself. • HP-UX 11i v2 virtual partitions (running vPars A.04.05) have no vPars command restrictions as compared with a pure HP-UX 11i v2 vPars environment.
Table 8 Mixed HP-UX 11i v1/v2 vPars Feature Summary Feature vPars A.03.xx Instances vPars A.04.xx Instances vPars A.05.xx Instances Minimum vPars Version A.03.05 A.04.
The following features can be executed only from the vPars-A.05.01/11.31-OS virtual partitions: • creation, removal, and modification of a target virtual partition. The vparcreate and vparremove operations can only be performed from the vPars A.05.01/11.31-OS virtual partitions; vparmodify operations affecting other virtual partitions can only be performed from the vPars A.05.01/11.31-OS virtual partitions. Note that this only applies to performing these operations on other virtual partitions.
Table 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.
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. • The status details reported by the vparstatus command are determined by the target virtual partition version and the vPars software version of the virtual partition issuing the command.
• 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.
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. The following sections discuss how LORA guidelines are implemented on vPars.
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 70) • 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 144). • “vPars Monitor: Booting the vPars Monitor” (page 127).
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.
display type as set in the GSP to the display type of the terminal or terminal emulator that you are using. For example: • 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.
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.
vPars-related Bundles (A.03.xx and earlier) Products related to this release of vPars are: Bundle Name Description B6826AA Partition Manager for nPartitions (parmgr) (Required for vPars A.03.xx and earlier) VPARMGR vPars GUI (vparmgr) for vPars A.03.xx and earlier (Optional) Installing and Removing vPars-related Bundles B6826AA (parmgr) The Partition Manager (parmgr) is required for installation of the vPars A.03.xx and earlier.
Ignite-UX Versions vPars A.03.xx and A.04.xx have different version requirements. This version information has been moved to the HP-UX Virtual Partitions Ordering and Configuration Guide. NOTE: PA-RISC only: When using Ignite-UX version C.06.xx or later, the bootable kernel path has changed from /opt/ignite/boot/WINSTALL in Ignite-UX B.05.xx and earlier to/opt/ ignite/boot/Rel_B.11.NN/WINSTALL in Ignite-UX C.06.xx and later. Thus, when using Ignite-UX C.06.
Ignite-UX, the LAN, the LAN card, and vparboot -I NOTE: Using vparboot -p target_partition -I On both PA-RISC and Integrity, before booting a virtual partition for installation (in other words, using vparboot -p target_partition -I...), be sure that you have specified a boot disk using the BOOT attribute (io:boot_device:BOOT)for the virtual partition. This is performed during either the initial vparcreate or subsequent vparmodify commands when configuring the target virtual partition.
Note that only the vPars shell command vparboot can be used to boot a subsequent virtual partition for installation (or recovery); the vPars Monitor command vparload cannot do this. Thus, you need at least one virtual partition successfully booted to use the vparboot command. Integrity The following is the sequence of events when a vparboot -I is issued from an existing virtual partition to boot a target virtual partition for an Integrity System: NOTE: vPars A.05.
Updating from vPars A.04.xx to A.05.xx This section describes how to update an existing A.04.xx vPars on 11iv2 (11.23) environment to a vPars A.05.xx vPars environment on 11iv3 (11.31). For information on vPars and OS versions, see the HP-UX Virtual Partitions Ordering and Configuration Guide. For information on the typical time needed to update the OS version, see the HP-UX 11i v3 Installation and Update Guide. The process is similar to updating from A.03.xx to A.04.xx.
For example, the command line used in this section is: • # update-ux -s depot1:/release/1131/HPUX11i-OE-Ent.DVD HPUX11i-OE-Ent 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 76). ◦ T1335DC is the vPars A.05.xx bundle.
1. Make sure that all the virtual partitions are up. You can check this with vparstatus. Example: keira1# vparstatus [Virtual Partition] Virtual Partition Name ============================== keira1 keira2 keira3 2. State ===== Up Up Up Attributes ============ Dyn,Auto,Nsr Dyn,Manl,Nsr Dyn,Auto,Nsr Boot Kernel Path Opts ======================= ===== /stand/vmunix /stand/vmunix /stand/vmunix Record the current autoboot and autosearch settings of all the virtual partitions.
NOTE: If the BOOT and ALTBOOT disks are a mirrored pair, updating is not required on the ALTBOOT disk. Otherwise, if you wish to have the alternate boot disk up dated, after updating the OS on the primary boot path disk, boot the virtual partitions from the alternate path boot disk and repeat the update-ux procedure.
keira1 # vparmodify -p keira3 keira1 # vparmodify -p keira3 -B auto -B nosearch 10. The virtual partitions should now be running the latest vPars version. To verify this, you can login to each virtual partition and use the vparstatus command with the -P option: Example: keira1# vparstatus -P Current Virtual Partition Version: A.05.01 Monitor Version: A.05.01 [Virtual Partition OS Version] Virtual Partition Name OS Version ============================ ========== keira1 B.11.31 keira2 B.11.
Note that this process works only using Update-UX and a corresponding Ignite-UX depot; it does not work by directly using the OE and vPars media.
Figure 10 Overview of Update Process for 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.
6. If it is necessary to change the PRI boot path for the nPartition, do so now using the parmodify command from HP-UX running on any of the virtual partitions. Because the vPars Monitor is loaded from the first virtual partition (whose disk is specified by the PRI path), the PRI disk must be installed with vPars A.04.05. 7. 8.
17. Verify the correct vPars Monitor has been booted. 18. Restart gWLM if needed. Following the mixed HP-UX 11i v1/v2 vPars update, perform any application updates as needed. 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.
NOTE: Before performing the update, you should verify that all of the target virtual partitions meet the HP-UX 11.23 requirements as documented in the HP-UX 11.23 Read Before Installing or Updating document. One example of a possible issue is file system size.
NOTE: To change the nPartition’s PRI boot path, you cannot use setboot from within a virtual partition; using setboot within a virtual partition changes only the virtual partition’s primary path entry in the vPars database. You can use parmodify to change the nPartition boot path, or you can make the change at the Boot Console Handler (BCH) PA-RISC firmware interface. Using parmodify to change the nPartition PRI boot path to point to a vPars A.04.
1. Make sure that all the virtual partitions are up. You can check this with the vparstatus command. azure1# vparstatus [Virtual Partition] Virtual Partition Name ============================== azure1 azure2 azure3 2. State ===== Up Up Up Attributes ============ Dyn,Auto,Nsr Dyn,Manl,Nsr Dyn,Auto,Nsr Boot Kernel Path Opts ======================= ===== /stand/vmunix /stand/vmunix /stand/vmunix Record the current autoboot and autosearch settings of all the virtual partitions.
5. Determine if you need to change the PRI boot path and record the necessary boot path details. If the current nPartition’s PRI boot path currently points to a virtual partition that will be updated to only A.03.05 and not A.04.05, you will need to change the nPartition’s PRI boot path such that it points to the boot disk of a virtual partition that will be updated to A.04.05. For more information, see “Changing nPartition Boot Paths To Boot the vPars A.04.xx Monitor” (page 84).
To list the current Update-UX bundle, use the swlist command. For example: azure2 # swlist -l product | grep Update If necessary to update the Update-UX bundle, use the swinstall command. Example where target OS will be HP-UX 11.23 azure1 # swinstall -s depot1:/release/1123/HPUX11i-OE-Ent.DVD Update-UX Ctrl-A azure3 # swinstall -s depot1:/release/1123/HPUX11i-OE-Ent.DVD Update-UX Example where target OS will be HP-UX 11.11 azure2 # swinstall -s depot1:/release/1111/HPUX11i-OE-Ent.DVD Update-UX 8.
11. Update the remaining virtual partitions to vPars A.03.05. How you perform the remaining updates will depend on whether you are doing parallel or staggered updates. a. If updating all virtual partitions in parallel then perform the following steps. i. On all remaining virtual partitions: • If the HP-UX Operating Environment must also be updated, use Update-UX to install the latest OE and the vPars A.03.05 bundle to the virtual partition. In the following example the target OS will be HP-UX 11.
Monitor the installation progress until the virtual partitions halt. To monitor the log files, first login to the virtual partition being updated (for example, use telnet) and then use the tail -f command to view the current installation status being written to the /var/adm/sw/swagent.log file or swinstall.log file. 12. Make sure that all virtual partition updates have successfully completed to the point of halting, then reboot the nPartition.
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.
Two approaches are available for migrating to a mixed HP-UX 11i v1/v2/v3 vPars environment: • A “cold migration” update process. The cold migration process involves updates of vPars A.03.xx to vPars A.03.05, the installation of a new HP-UX 11i v3 boot disk (with vPars A.05.03), and subsequent virtual partition updates to vPars A.04.05 and/or A.05.03 as needed. • A two-phased update, involving: ◦ First updating to a mixed HP-UX 11i v1/v2 vPars environment (including vPars A.03.05 and vPars A.04.05).
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.
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. # swlist -d @ depot1:/release/1123/HPUX11i-OE-Ent.
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. 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.
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. keira1# parstatus -w The local partition number is 0. The nPartition number is 0. Record this information. b. Find the boot path of the boot disk of a future vPars A.05.01 virtual partition.
6. After the all updates for the above virtual partitions have completed, use Update-UX to install the latest OE and vPars bundle to the first virtual partition. Example: keira1 # update-ux -s depot1:/release/1131/HPUX11i-OE-Ent.DVD HPUX11i-OE-Ent T1335CC 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.
c. Verify the new PRI path using parstatus. If you are using the 11.31 vPars, that is, A.05.08, instead of using the parmodify or the parstatus command, use the vPars monitor command mon_bootpath to change and verify the nPartition's boot path. keira# parstatus -p0 -V [Partition] Partition Number : 0 Partition Name : npar0 Status : active IP address : 0.0.0.0 PrimaryBoot Path : 0/0/6/0/0.5.0 ... d. Once the PRI path has been successfully changed, set the mode to back to vPars.
Virtual Partition Name OS Version ============================ ========== keira1 B.11.31 keira2 B.11.23 keira2# vparstatus -P Commands product information: A.04.03 Monitor product information: A.05.01 State ===== Up Up 13. Verification the vPars Monitor. If you changed the nPartition’s PRI boot path, you can also verify that the vPars Monitor has been booted from the correct boot disk: keira3# vparstatus -m Console path: No path as console is virtual Monitor boot disk path: 0.0.6.0.0.5.
Table 17 HP-UX OE versions required for the different supported vPar versions. vPars Release Version HP-UX OE Version A.04.07 HP-UX 11i v2 (11.23) June 2008 Update or later A.05.05 HP-UX 11i v3 (11.31) March 2009 Update or later A.05.06 HP-UX 11i v3 (11.31) March 2010 Update or later A.05.07 HP-UX 11i v3 (11.31) September 2010 Update or later A.05.08 HP-UX 11i v3 (11.
General Process for A.03.xx to A.05.xx Workaround (PA only) The general process for updating from A.03.xx to A.05.xx is to perform the update in two steps: 1. Update your virtual partitions from A.03.xx to A.04.02 or later. “Updating from vPars A.03.xx to A.04.xx” (page 102) 2. Update your virtual partitions from A.04.02 or later to A.05.01 “Updating from vPars A.04.xx to A.05.xx” (page 75) “Updating from vPars A.04.xx to Mixed HP-UX 11i v2/v3 vPars (A.04.xx and A.05.
The Steps 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.
HPUX11i-OE-Ent Enterprise OE HPUX11i-OE-MC Mission Critical OE You should chose the same OE that your current virtual partition is running. Use the swlist command to check which OE you are currently running: # swlist -l bundle | grep -i OE HPUX11i-OE-Ent B.11.23.0505 HP-UX Enterprise Operating Environment • T1335BC is the vPars A.04.xx bundle. NOTE: line. 6.
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 The virtual partitions should now be running the latest OE and vPars version. Updating vPars A.03.xx to vPars A.03.05 This section describes the process for updating a vPars environment from earlier vPars A.03.xx releases to vPars A.03.05.
6. For each virtual partition—except the first virtual partition—use Update-UX to install the latest OE and vPars bundle, or use swinstall if only updating the vPars bundle. 7. After the previous updates complete, use Update-UX to install the latest OE and vPars bundle to the first virtual partition, or use swinstall if only updating the vPars bundle. 8. Reboot the nPartition after making sure that all virtual partition updates have successfully completed to the point of halting. MON> reboot 9.
5. Reboot the system: # shutdown -r 6. Boot the vPars Monitor and the virtual partitions from the disk where you installed the vPars bundle. For example, if we had installed the bundle to the disk at the primary path: BCH> bo pri interact with IPL? y . . . ISL> hpux /stand/vpmon -a 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 155). 7.
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 155). 6. On each virtual partition, repeat Step 3 to install the vPars sub-system patch on each boot disk of each virtual partition. No reboot of the virtual partition is required.
vPars Database Changes As part of the upgrade process, HP qualified service personnel will need to make updates to each virtual partition’s vPars database (vpdb) in nPars mode following the server hardware changes. These and other necessary steps are described in the HP I/O Hardware Upgrade Scripts Guide for HP Integrity Superdome/sx2000 Servers and HP-UX Impacts on the Upgrade Process for the rx8620 to rx8640 Hardware Upgrade service documents.
Table 21 Integrity Superdome Hardware Path Changes (x=cell) (continued) Slot sx1000 Path sx2000 Path 6 x/0/14/1 x/0/14/1 7 x/0/12/1 x/0/13/1 8 x/0/11/1 x/0/12/1 9 x/0/10/1 x/0/10/1 10 x/0/9/1 x/0/9/1 11 x/0/8/1 x/0/8/1 Upgrading HP 9000 Servers from the sx1000 to sx2000 Chipset You can upgrade the following HP 9000 servers from the sx1000 to sx2000 chipsets: • rp7420 to rp7440 • rp8420 to rp8440 • HP 9000 Superdome To perform the hardware upgrade, follow the process documented in th
HP 9000/sx2000 Superdome Servers and HP-UX Impacts on the Upgrade Process for the rp8420 to rp8440 Hardware Upgrade service documents. Hardware Path Tables The following tables show the new hardware paths. For details on the new hardware paths and other hardware information, see the applicable hardware upgrade manuals for your server. Table 22 rp7420 to rp7440 Hardware Path Changes rp7420 Path rp7440 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.
Table 24 HP 9000 Superdome Hardware Path Changes (x=cell) (continued) Slot sx1000 Path sx2000 Path 9 x/0/10/1 x/0/10/1 10 x/0/9/1 x/0/9/1 11 x/0/8/1 x/0/8/1 Upgrading Backplanes from PCI to PCI-X If you upgrade from the PCI to PCI-X backplane with the following server upgrades: • rp7410 to rp7420 • the rp8400 to rp8420 • Superdome the hardware paths of the I/O devices will change. The I/O device paths are in the format • cell/sba/lba/device/function.target.
BCH> bo lan.ww.xx.yy.zz install Interact with IPL: n 2. Using the Ignite-UX server, install HP-UX, desired patches, the Quality Pack bundle, the vPars bundle, and the desired vPars-related bundles onto the disk that will be the boot disk of the first virtual partition. NOTE: So that the TERM variable will always be set correctly, you should ensure that the first virtual partition owns the hardware console port. For more information, see “Assigning the Hardware Console LBA” (page 52). 3.
You will see a message similar to the following: winona2 loaded b. c. Press Ctrl-A until you see the console of the target partition. The console will display the Ignite-UX installation interface. Enter the boot disk path, lan info, hostname, and IP of the target partition into the Ignite-UX interface and install HP-UX, desired patches, the Quality Pack bundle, the vPars bundle, and the desired vPars-related bundles. 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.
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.
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: # vparcreate -p keira1 -a cpu::2 -a mem::1024 -a io:0.0.1 -a io:1.0.0 -a io:1/0/0/3/0.6.0:BOOT # vparcreate -p keira2 -a cpu::1 -a cell:1:cpu::1 -a mem::1024 -a io:1.0.1 -a io:1.0.4 -a io:1/0/4/1/0/4/0.1.0.0.0.0.1:BOOT # vparcreate -p keira3 -a cpu::1 -a mem::1024 -a io:0.0.2 -a io:0.0.0 -a io:0/0/0/3/0.6.
From the Entire System 1. 2. Remove the vPars product from each virtual partition one by one. After you have removed vPars from the last virtual partition, you will be at the vPars Monitor prompt. At this point, you can type REBOOT to reboot the system. MON> reboot NOTE: On Integrity systems, you will also need to change the mode from vPars to nPars in order to be able to boot in nPars (standalone) mode.
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 44). 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.
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.
NOTE: • When the system is at the EFI shell prompt in vPars mode, you can use either one of the following commands to reset the nPartition: ◦ EFI_Shell> parconfig reset ◦ EFI_Shell> fsx: fsx:\> vparconfig reboot vPars The standard EFI Shell command reset should not be used to reset the system or nPartition when it is in vPars mode. • If the desired mode is not set, you will not be able to boot into that mode.
Start of HP-UX HA Alternate Boot: 1/0/0/2/0.6.0 failed: Not Found vparefiutil without any options can be used to display the current hardware to EFI path mappings. 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.
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.
• 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 149).
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.
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. For detailed information on the vPars commands, including description, syntax, all the command line options, and the required state of a virtual partition for each command, see the vPars manpages.
Oct 29 19:44:30 winona2 vparutil[2947]: exit status 4 Oct 29 19:47:47 winona2 vparmodify[2962]: user root: /sbin/vparmodify -p winona3 -a cpu::1 Oct 29 19:47:47 winona2 vparmodify[2962]: exit status 1 Cases Where No Logging Occurs Below are the cases where logging does not occur: • a non-root user attempting a vPars command • syntax, usage, or vPars commands version errors • vPars commands which do not change the vPars database and/or do not affect the state of other virtual partitions.
NOTE: nPartition Logs (see also “nPartition Logs” (page 33)) 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 142) • “vparstatus: Dual-Core CPUs” (page 141) • “vparstatus: CPU Information on vPars A.04/A.05” (page 140) • “vparstatus: Pending Migrating Memory Operations” (page 142) • “vparstatus: Pending nPartition Reboot for Reconfiguration” (page 144) • “vparstatus: vPars Monitor and Database Information” (page 144) NOTE: • Actual vparstatus output differs from version to version of vPars.
============================== thurman24 thurman25 thurman26 thurman27 ====================== 0/ 0 1024 1/1024 1024 0/ 0 1024 1/ 512 1024 ====================== 0/ 0 0 0/ 0 0 1/ 256 256 1/ 768 1024 vparstatus: Verbose Information Use vparstatuswith verbose (-v) option. Examples • vPars A.03.
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.
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.13 1.11 1.13 1.14 [CLP (CellID Count)]: [Available CPUs]: 0 3 1 3 5 [Available I/O devices (path)]: 0.0.0 0.0.1 0.0.4 0.0.6 0.0.10 0.0.12 0.0.14 1.
[Available CPUs]: 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.14 [Available ILM (Base /Range)]: (bytes) (MB) 0x3000000/80 0x10000000/512 0x50000000/768 0xb8000000/1024 0x100000000/1920 0x178000000/96 [Available ILM (MB)]: [Available CLM (CellID Base /Range)]: (bytes) (MB) [Available CLM (CellID MB)]: 0 0x70080000000/256 0 0x700b0000000/1152 0 0x700f8000000/120 0 504 1 0 # vparstatus: CPU Information on vPars A.04/A.
Table 27 possible commands to arrive at vparstatus output (continued) 1 totat==5 (2 assigned by hardware path and 2 assigned by Monitor and 1 assigned by CLP)) 1 ... # vparboot -p keira1 assume I/O and memory have been assigned so that keira1 can boot. at boot time: min==1, max==12 user-assigned CPU is 1.10 boot processor is chosen by Monitor to be the other user-assigned CPU at 1.12 2 CPUs assigned by Monitor are 0.10 and 0.11 1 CPU assigned by the Monitor by CLP is 1.
===== 0.10 0.11 0.12 0.13 0.14 0.15 ... ================== ==== ====== 0xfffffffffc070000 0 E 0xfffffffffc071000 0 E 0xfffffffffc074000 0 E 0xfffffffffc075000 0 E 0xfffffffffc078000 0 E 0xfffffffffc079000 0 E ================== vpkeira1 vpkeira3 vpkeira4 - ======================= 0.11 vpkeira3 0.10 vpkeira1 0.13 vpkeira4 0.12 0.15 0.14 - vparstatus: Pending Migrating CPUs Operations Migrating CPUs may not occur instantaneously.
Virtual Partition Name ============================== winona1 winona2 winona3 • ILM # User Ranges/MB Total MB ====================== 1/ 128 4352p 0/ 0 2560 0/ 0 1224 CLM # User Ranges/MB Total MB ====================== 1/ 128 640p 0/ 0 0 0/ 0 0 winona1# vparstatus -p winona1 -v ...
vparstatus: Pending nPartition Reboot for Reconfiguration On an nPartitionable system, if the nPartition has a pending Reboot for Reconfiguration, the vparstatus output will show the following message: Note: A profile change is pending. The hard partition must be rebooted to complete it.
NOTE: When you create a virtual partition, the vPars Monitor assumes you will boot and use the partition. Therefore, when a virtual partition is created, even if it is down and not being used, the resources assigned to it cannot be used by any other partition. Also, when using vPars, the physical hardware console port must be owned by a partition. To avoid terminal type mismatches, this should be the first virtual partition created. For an example, see “Assigning the Hardware Console LBA” (page 52).
TIP: For the vparcreate options, you can create a text file that includes all the options and then cat the text file within the vparcreate command line. This avoids having to remember all the options when you are typing the vparcreate command line. For example, for the vPars A.03.xx vparcreate command of winona2, you can create a text file called /stand/winona2.opts: winona1# vi /stand/winona2.
TIP: When a virtual partition is removed, data residing on the disk(s) of the target partition is not removed. If you have removed a partition by accident, you may be able to recover the partition by immediately re-creating the same virtual partition with the same assigned resources. Managing: Modifying Attributes of a Virtual Partition You can change a virtual partition’s name and its resource attributes via the vparmodify command.
NOTE: — If the vparboot fails but vparstatus shows the target virtual partition as down, try the vparboot again after waiting a few seconds. There is a small window of time after a virtual partition is downed by the shutdown or vparreset command before you can perform the vparboot command successfully. — (PA-RISC only) On nPartitionable servers, memory assigned to a virtual partition is scrubbed as part of the boot process.
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. For more information on the virtual partition attributes, see the vparmodify(1M) manpage and “Managing: Modifying Attributes of a Virtual Partition” (page 147).
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. For example: MON> ^B GSP> PC Alternatively, you can power off the rp5470/L3000 or rp7400/N4000 servers via the physical power switch.
The actions of setboot on a virtual partition are: setboot option vPars effect -p changes the primary boot path of the virtual partition -a changes the alternate boot path of the virtual partition -s sets the autosearch attribute of the virtual partition (pre-A.03.
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.
Using setboot Because setboot affects only the virtual partition from which you execute the command, execute these commands from winona2. • To set the primary boot path: winona2# setboot -p 0/8/0/0.5.0 • To set the alternate boot path: winona2# setboot -a 0/8/0/0.2.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.
State: Down Attributes: Dynamic,Autoboot . . . [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 BOOT 0.0.6.0.0.6.0 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.
Changing the nPartition’s Path (Complex Profile Data) To change the nPartition’s alternate path to 0/0/6/0/0.4.0, run the command: 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.
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 46).
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 171) • Assigning (Adding) Or Deleting Memory • • ◦ “Memory: Assigning (Adding) or Deleting by Size (ILM)” (page 175) ◦ “Memory: Assigning (Adding) Or Deleting by Size (CLM)” (page 176) ◦ “Memory: Assigning (Adding) Or Deleting by Address Range” (page 177) ◦ “Memory, CPU: Canceling Pending Operations” (page 196) ◦ “Memory: Converting Base Memory to Float Memory” (page 179) ◦ “Memory: Available
You can assign memory to a virtual partition by any of the following methods: • By size. ◦ This uses the nPartition’s ILM. The basic syntax for this is: -a|d mem::size ◦ • For more information, see “Memory: Assigning (Adding) or Deleting by Size (ILM)” (page 175). By cell and a corresponding size. ◦ 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 176).
is also true when you assign memory during the creation of a virtual partition. If you do not specify :float during the creation of the virtual partition, all memory assigned to the virtual partition will be considered as base. When you wish to delete float memory online, you must also specify :float or :f on the command line; otherwise, because :base is the default, you will be attempting to delete base memory, which is not allowed.
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
-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 281). 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.
vparcreate # vparcreate -p vpar1_name [-g ILM:unit[:y]][-g CLM:unit[:y]] If you specify the above command without the :y, vparcreate only writes the unit granularity value to the vPars database; it does not write the value to firmware. If you specify the above command with the :y, vparcreate writes the unit granularity value to both the vPars database and to firmware.
3 Load the alternate vPars database. Memory: Setting the Granularity Values (PA-RISC) Syntax The syntax for setting granularity unit size is -g ILM|CLM:unit[:y|n] 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. y|n specifies whether granularity unit size should be written to firmware. The default is n.
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. Note that because the following applies only to online migration (in other words, where the target partition is up), it does not apply to the vparcreate command, where the target virtual partition should never be up during the vparcreate invocation.
error. This behavior occurs because the firmware returns a portion of the memory reserved for the firmware back to the operating system as CLM.
“Commands: Displaying vPars Monitor and Resource Information (vparstatus)” (page 135).
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.
You must specify each change on a separate command line. For example, the following are allowed: • ◦ 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.
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.
In the example below, each LBA (shown in brackets) can be assigned to a different virtual partition. Figure 21 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 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.
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 46). • SBA/LBA versus cell/SBA/LBA When viewing hardware paths, note the following: 1. The explicit specification of an LBA on a non-nPartitionable system consists of two fields: sba/lba 2.
Assignments You assign memory to a virtual partition: • 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.
Memory: Assigning by Size (CLM) Before assigning CLM, see the section on configuring CLM: “Configuring CLM for an nPartition” (page 246).
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- or CLM-specified ranges cannot exceed the total amount of ILM or CLM memory reserved for the virtual partition. • (vPars A.04.
On Integrity systems, memory is divided into the granules by the firmware; therefore, it is required that you set and match the corresponding EFI variables. PA-RISC systems. There is only one area where granularity values are set: the vPars database. For PA-RISC, there are no granularity values in the PA-RISC firmware. The memory is divided into the granules by the vPars Monitor itself. Note that this means the update firmware option ([:y]) of vparcreate is ignored on PA-RISC.
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.
100 GB / 2 GB => 50 granules Note that as seen in “Granularity Issues (Integrity and PA-RISC)” (page 208) 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. Further, this means that any memory assigned between the multiples will be rounded up to the next multiple.
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 220). 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
Example • To create the virtual partition keira2 with 3 CPUs, set num to 3: keira1# vparcreate -p keira2 -a cpu::3 ... vparmodify With the vparmodify command, you can use the: • -a option to add num CPUs to the virtual partition, • -d option to delete num CPUs from the virtual partition, • -m option to modify (set) to num the number of CPUs assigned to the partition. The vPars Monitor automatically will add or delete CPUs to or from the virtual partition to reach num CPUs.
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.
Example • To add the CPUs at 0/10 and 0/11 to keira2: keira1# vparmodify -p keira2 -a cpu:0/10 -a cpu:0/11 Using both the Hardware Path Specification and CLP specification Although you can add and delete CPUs by hardware path, to avoid confusion it is recommended that you specify by cell rather than by hardware path. The exception is for dual-CPU sockets.
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 the intctl(1M) manpage. Notes • At boot time of a virtual partition, interrupts are processed by all the CPUs in the virtual partition.
At this point, the 3 CPUs have already been added; you do not need to run vparmodify -a cpu::3. If you do run vparmodify -a cpu::3, this will add 3 more CPUs to the virtual partition (in addition to the 3 CPUs that were added with the icod_modify command). Note that if you deactivate CPUs while in the vPars environment or in vPars mode using icod_modify -d, this will un-assign those CPUS from the local virtual partition.
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.
Deconfiguration of a socket means that the EMS issues a firmware call, marking the socket for deconfiguration on the next system boot. On the next system boot, none of the cores in the target socket are visible to either the OS in standalone mode or the OS instances of the virtual partitions. The deconfiguration is persistent across system boots. Note the following two items: • A deactivation of a CPU does not mean a deconfiguration of its socket.
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 228). 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.
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.) and the boot disk is specified using the full hardware path (-a io:0.0.0.2.0.6.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 22). • For more information, see “Shutting Down or Rebooting the nPartition (Or Rebooting the vPars Monitor)” (page 149) and the vPars Monitor command “reboot [mode]” (page 130).
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.
keira# parmodify -p0 -a 6:base:y:ri In order to activate any cell that has been newly added,reboot the partition with the -R option. Command succeeded. 2. Perform a Reboot for Reconfiguration from a virtual partition. For example, keira# shutdown -R Do not put the nPartition into vPars mode; you will need to perform an additional reboot into nPars mode. 3. Allow the system to reboot into nPars mode. Once this is successful, the OS kernel automatically will write the correct CPU mapping data to EFI.
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. Perform the changes as you would in a non-vPars environment. For example, if we want to add cell 6 to partition 0: keira1# parmodify -p0 -a 6:base:y:ri In order to activate any cell that has been newly added,reboot the partition with the -R option. Command succeeded. 2. Perform a Reboot for Reconfiguration from a virtual partition.
2B 1000 MHz 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. Alternate Boot Path: Boot Actions: Console Path: Idle 32 MB 32 MB 1/0/12/1/0.8 Go to BCH. 1/0/0/0/1.0 Putting an nPartition into an Inactive State and Other GSP Operations 1. If possible, gracefully shutdown all the virtual partitions within the target nPartition. For example: keira1# vparstatus keira1# shutdown -h keira2# vparstatus keira2# shutdown -h 2.
where nPar_num is the nPartition number cell is the cell to be modified. this can be either the global format (cell_number) or hardware format (cabinet/slot) type is the cell type. base is the only valid value and is the default. use is the use-on-next-boot value. this is either a y or n. The default is y. Use y if the cell is to be an active member of the nPartition or n if the cell is to be an inactive member fail is the cell failure usage.
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 : 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 257) • make_tape_recovery within a vPars-environment, see “Using make_tape_recovery within a vPars Environment” (page 258) • 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.
be out of date.If the recovered configuration is out of date, the recovery will require one of the following additional steps: • 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.
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.
1. 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. 4. 5. 6. When the main Ignite-UX menu is displayed, select Install HP-UX.
. . . 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. On PA-RISC systems, the tape device specified with the TAPE attribute is booted.
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.
monadmin monadmin is a vPars Monitor command that allows you to • display whether the vPars flexible administrative capability feature is ON (enabled) or OFF (disabled) • set or reset the flexible administrative capability mode • specify a virtual partition to be added or deleted to or from the designated-admin 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 Synt
-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.
vparadmin vparadmin is a vPars command that allows you to • 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 U
Therefore, persistence across vPars Monitor reboots will not be maintained under any of the following conditions: • The vPars Monitor boot disk is not owned by any of the virtual partitions or no virtual partitions are rebooted from the same disk. In this case, the vPars database of the vPars Monitor’s boot disk will not be updated. • All virtual partitions are down such that any flexible administrative capability changes cannot be written to the vPars database.
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
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. Note that there is no -C option in the monadmin command, although you will be asked for a new password when you set the mode from OFF to ON.
12 Virtual Partition Manager (A.03.xx) This chapter provides an overview of the Virtual Partition Manager (vparmgr), which provides a GUI to the vPars commands. This chapter includes: • About the Virtual Partition Manager • Starting the Virtual Partition Manager • Using the vPars Graphical User Interface (GUI) • Stopping the Virtual Partition Manager For more detailed information, see the Virtual Partition Manager online help.
Starting the Virtual Partition Manager Before you can start the virtual partition manager, vPars must be installed and running. For information on installing vPars, see “Installing, Updating, or Removing vPars and Upgrading Servers with vPars” (page 66). For information on installing the virtual partition manager, see “Installing and Removing vPars-related Bundles ” (page 71). After vPars is installed and running, you must boot at least one virtual partition to a HP-UX kernel.
This displays the status of all of the virtual partitions and available resources on the system. To perform an action on an object (a virtual partition or a set of available resources), click on the object in the list and then click the button corresponding to the action that you want to perform on that object. For more information about this screen, select the virtual partition status page from the navigation links on the left side of the Virtual Partition Manager online help.
A LBA Hardware Path to Physical I/O Slot Correspondence (PA-RISC only) This section contains a simplified PCI I/O block diagrams for the rp5470/L3000, rp7400/N4000, rp7405/rp7410, rp8400, and HP 9000 Superdome (SD16000, SD32000, SD64000) servers. These diagrams can be used to help determine which LBAs correspond to which physical I/O slots. The diagrams presented here were created due to incorrect or inaccessible PA-RISC documentation. For other supported servers, see your server manual.
rp7400/N4000 I/O Block Diagram Figure 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).
Example System Assume our example system is: • an Integrity server • running vPars A.05.
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.
G vPars Support on HP Superdome 2 (SD2) Integrity Servers vPars A.05.07 includes changes to enable vPars support on HP Superdome 2 (SD2) Integrity servers. In SD2, the implementation of Virtual Partitions has changed. For more information, see the HP Superdome 2 Partitioning Release Notes and HP Superdome 2 Administrator Guide on the BSC website at http://www.hp.com/go/hpux-vpars-docs.
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, 69 A adding cpu to a partition, 186, 214, 232 adding i/o to a partition, 168, 169, 201, 202, 227, 228 adding memory resources to a partition, 171, 203, 229 alternate partition database files, 162 application fault isolation, 17 attributes, 147 AUTO file, 155 Autoboot, 53, 156 B BCH.
E K EFI, 34, 124, 132 EFI paths, 124 expert recovery, 20, 259 kernel size, 49 vmunix file, 30 F L flexibility independent operating system instances, 17 floater CPUs. See unbound CPUs, 233 lan cards, 73, 114 lan path, 53 LBA concepts, 166, 199, 225 LBA.
vparinfo, 132 vparload, 129, 157, 158 vparreset, 158 crash dump files, 251 prompt, 127 vpmon file, 28, 30, 149, 251 monitor prompt toggling past, 33 N NO_HW (ioscan output), 22, 32 nPartition, 16, 240 Adding a cell, 243 Reboot for Reconfiguration, 144, 243, 244, 245 O ODE, 19 OLAR.
toddriftreset, 21, 132 U unbound CPUs, 233 Uninterruptible Power Supply, 21 Update-UX, 75, 79, 83, 93, 94, 102 Updating, 75, 80, 93, 102 UPS.
