Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Steps to Create Virtual Partitions
In this section we'll cover the steps to create Virtual Partitions. These are steps I performed while working with vPars with some of the very first installations. This list should serve as a framework for working with vPars. You may chose not to perform some of the steps and to add others. It is only a framework for getting vPars working on your system.
In our upcoming examples to create our Virtual Partitions, we'll execute the steps shown in Figure 1-4.
){kind=link}
Figure 1-4 Steps to Create Virtual Partitions
1) Load HP-UX 11i
HP-UX 11i must be loaded on the volumes that will be used to host all vPars. The method you use to install 11i, whether media, Ignite-UX, or some other technique, are all acceptable provided that HP-UX 11i is present on all of the disks. HP-UX 11i must be present on the first disk before you begin the vPar creation. You can create vPars on other disks before HP-UX 11i is loaded on them and then use vparboot -p vp_name -I ignite_kernel to boot and load HP-UX 11i on the other disks. In this article I first load HP-UX 11i on all disks before creating vPars. In our upcoming example the first Virtual Partition will be created on the internal disk on an rp 5400 (formerly know as L-Class) system. The second Virtual Partition will be created on an external disk. After loading HP-UX 11i on one of the root volumes, I issued uname, which resulted in the following output:
# uname -a HP-UX cvhdcon3 B.11.11 U 9000/800 136414696 unlimited-user license #
The hostname of cvhdcon3 and HP-UX revision 11.11, which is the latest HP-UX 11i available at the time of this writing, are shown.
An interesting nuance to working with vPars is the naming of hosts and vPars. In a nutshell, you supply hostnames when installing 11i and Virtual Partition names when creating vPars. It reduces confusion if both the hostname and vPar name are the same for an instance of HP-UX 11i. In some cases, however, organizations require hostnames to conform to conventions that result in names that are difficult to remember. In this case some system administrators pick easy-to-remember vPar names. In the upcoming example we used different names for the vPars and hostnames.
Our upcoming examples have hostnames of cvhdcon3 and cvhdcon4. The respective vPar names used are cable1 and cable2.
2) Load the Virtual Partitions Application Software
The Virtual Partitions software must also be loaded on the volumes that will be used to host all vPars. At the time of this writing there are base and full versions of the software. The restrictions of the base software are a maximum of two vPars and a maximum of one CPU in one of the vPars. After loading the vPars software on one of the root volumes I ran swlist which resulted in the following output:
# swlist # Initializing... # Contacting target "cvhdcon3"... # # Target: cvhdcon3:/ # # # Bundle(s): # BUNDLE11i B.11.11.0102.2 Required Patch Bundle for HP-UX 11i, Febr uary 2001 CDE-English B.11.11 English CDE Environment FDDI-00 B.11.11.01 PCI FDDI;Supptd HW=A3739A/A3739B;SW=J3626 AA FibrChanl-00 B.11.11.06 PCI/HSC FibreChannel;Supptd HW=A6684A,A66 85A,A5158A GigEther-00 B.11.11.14 PCI/HSC GigEther;Supptd HW=A4926A/A4929A/ A4924A/A4925A;SW=J1642AA HPUX11i-OE-MC B.11.11.0106 HP-UX Mission Critical Operating Environm ent Component HPUXBase64 B.11.11 HP-UX 64-bit Base OS HPUXBaseAux B.11.11.0106 HP-UX Base OS Auxiliary HWEnable11i B.11.11.0106.8 Hardware Enablement Patches for HP-UX 11i , June 2001 OnlineDiag B.11.11.03.08 HPUX 11.11 Support Tools Bundle, Jun 2001 RAID-00 B.11.11.01 PCI RAID; Supptd HW=A5856A VPARSBASE A.01.00.03 HP-UX Virtual Partitions #
The HP-UX Virtual Partitions software is the last entry shown in this listing.
3) Gather the System Component and Hardware Paths
You get to know your hardware at an intimate level when working with vPars. You not only need to know the components of which your system is comprised, you also need to know the paths of much of the hardware. Some system components, such as System Bus Adapters and the memory controller, are shared among vPars, so you don't specify those components as part of individual Virtual Partitions. Most other components in your system, such as processors, I/O cards, disks, and others, are fixed to specific vPars.
In order to see the components of which our example system is comprised, we'll run ioscan -f and dmesg in the following listing:
# ioscan -f
Class I H/W Path Driver S/W State H/W Type Description
=============================================================================
root 0 root CLAIMED BUS_NEXUS
ioa 0 0 sba CLAIMED BUS_NEXUS System Bus
Adapter (803)
ba 0 0/0 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
lan 0 0/0/0/0 btlan CLAIMED INTERFACE HP PCI 10/100
Base-TX Core
ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C896
Ultra Wide Single-Ended
target 0 0/0/1/0.1 tgt CLAIMED DEVICE
disk 0 0/0/1/0.1.0 sdisk CLAIMED DEVICE HP DVD-ROM 304
target 1 0/0/1/0.3 tgt CLAIMED DEVICE
tape 0 0/0/1/0.3.0 stape CLAIMED DEVICE HP C1537A
target 2 0/0/1/0.7 tgt CLAIMED DEVICE
ctl 0 0/0/1/0.7.0 sctl CLAIMED DEVICE Initiator
ext_bus 1 0/0/1/1 c720 CLAIMED INTERFACE SCSI C896
Ultra Wide Single-Ended
target 3 0/0/1/1.0 tgt CLAIMED DEVICE
disk 1 0/0/1/1.0.0 sdisk CLAIMED DEVICE SEAGATE ST17340 4LC
target 4 0/0/1/1.2 tgt CLAIMED DEVICE
disk 2 0/0/1/1.2.0 sdisk CLAIMED DEVICE SEAGATE ST17340 4LC
target 5 0/0/1/1.7 tgt CLAIMED DEVICE
ctl 1 0/0/1/1.7.0 sctl CLAIMED DEVICE Initiator
ext_bus 2 0/0/2/0 c720 CLAIMED INTERFACE SCSI C87x
Ultra Wide Single-Ended
target 6 0/0/2/0.0 tgt CLAIMED DEVICE
disk 3 0/0/2/0.0.0 sdisk CLAIMED DEVICE SEAGATE ST17340 4LC
target 7 0/0/2/0.2 tgt CLAIMED DEVICE
disk 4 0/0/2/0.2.0 sdisk CLAIMED DEVICE SEAGATE ST17340 4lc
target 8 0/0/2/0.7 tgt CLAIMED DEVICE
ctl 2 0/0/2/0.7.0 sctl CLAIMED DEVICE Initiator
ext_bus 3 0/0/2/1 c720 CLAIMED INTERFACE SCSI C87x
Ultra Wide Single-Ended
target 9 0/0/2/1.7 tgt CLAIMED DEVICE
ctl 3 0/0/2/1.7.0 sctl CLAIMED DEVICE Initiator
tty 0 0/0/4/0 asio0 CLAIMED INTERFACE PCI Serial
tty 1 0/0/5/0 asio0 CLAIMED INTERFACE PCI Serial
ba 1 0/1 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
ba 2 0/2 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
ba 3 0/3 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
ba 4 0/4 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
ba 5 0/5 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
ba 6 0/8 lba CLAIMED BUS_NEXUS Local PCI Bus
Adapter (782)
fc 0 0/8/0/0 td CLAIMED INTERFACE HP Tachyon TL/TS
Fibre Channel Mass Storage Adapter
fcp 0 0/8/0/0.8 fcp CLAIMED INTERFACE FCP Protocol
Adapter
ext_bus 4 0/8/0/0.8.0.5.0 fcparray CLAIMED INTERFACE FCP
Array Interface
target 10 0/8/0/0.8.0.5.0.0 tgt CLAIMED DEVICE
disk 5 0/8/0/0.8.0.5.0.0.0 sdisk CLAIMED DEVICE HP A5277A
disk 6 0/8/0/0.8.0.5.0.0.1 sdisk CLAIMED DEVICE HP A5277A
disk 7 0/8/0/0.8.0.5.0.0.2 sdisk CLAIMED DEVICE HP A5277A
disk 8 0/8/0/0.8.0.5.0.0.3 sdisk CLAIMED DEVICE HP A5277A
target 11 0/8/0/0.8.0.5.0.1 tgt CLAIMED DEVICE
disk 9 0/8/0/0.8.0.5.0.1.0 sdisk CLAIMED DEVICE HP A5277A
target 12 0/8/0/0.8.0.5.0.2 tgt CLAIMED DEVICE
disk 10 0/8/0/0.8.0.5.0.2.0 sdisk CLAIMED DEVICE HP A5277A
target 13 0/8/0/0.8.0.5.0.3 tgt CLAIMED DEVICE
disk 11 0/8/0/0.8.0.5.0.3.0 sdisk CLAIMED DEVICE HP A5277A
ext_bus 5 0/8/0/0.8.0.255.0 fcpdev CLAIMED INTERFACE FCP
Device Interface
target 14 0/8/0/0.8.0.255.0.5 tgt CLAIMED DEVICE
ctl 4 0/8/0/0.8.0.255.0.5.0 sctl CLAIMED DEVICE HP A5277A
ba 7 0/9 lba CLAIMED BUS_NEXUS Local PCI
Bus Adapter (782)
fc 1 0/9/0/0 td CLAIMED INTERFACE HP Tachyon
TL/TS Fibre Channel Mass Storage Adapter
fcp 1 0/9/0/0.8 fcp CLAIMED INTERFACE FCP Protocol
Adapter
ext_bus 6 0/9/0/0.8.0.4.0 fcparray CLAIMED INTERFACE FCP Array
Interface
target 15 0/9/0/0.8.0.4.0.0 tgt CLAIMED DEVICE
disk 12 0/9/0/0.8.0.4.0.0.0 sdisk CLAIMED DEVICE HP A5277A
disk 13 0/9/0/0.8.0.4.0.0.1 sdisk CLAIMED DEVICE HP A5277A
disk 14 0/9/0/0.8.0.4.0.0.2 sdisk CLAIMED DEVICE HP A5277A
disk 15 0/9/0/0.8.0.4.0.0.3 sdisk CLAIMED DEVICE HP A5277A
target 16 0/9/0/0.8.0.4.0.1 tgt CLAIMED DEVICE
disk 16 0/9/0/0.8.0.4.0.1.0 sdisk CLAIMED DEVICE HP A5277A
target 17 0/9/0/0.8.0.4.0.2 tgt CLAIMED DEVICE
disk 17 0/9/0/0.8.0.4.0.2.0 sdisk CLAIMED DEVICE HP A5277A
target 18 0/9/0/0.8.0.4.0.3 tgt CLAIMED DEVICE
disk 18 0/9/0/0.8.0.4.0.3.0 sdisk CLAIMED DEVICE HP A5277A
ext_bus 7 0/9/0/0.8.0.255.0 fcpdev CLAIMED INTERFACE FCP
Device Interface
target 19 0/9/0/0.8.0.255.0.4 tgt CLAIMED DEVICE
ctl 5 0/9/0/0.8.0.255.0.4.0 sctl CLAIMED DEVICE HP A5277A
ba 8 0/10 lba CLAIMED BUS_NEXUS Local PCI
Bus Adapter (782)
lan 1 0/10/0/0 btlan CLAIMED INTERFACE HP A5230A/
B5509BA PCI 10/100Base-TX Addon
ba 9 0/12 lba CLAIMED BUS_NEXUS Local PCI
Bus Adapter (782)
lan 2 0/12/0/0 btlan CLAIMED INTERFACE HP A5230A/
B5509BA PCI 10/100Base-TX Addon
pbc 0 32 pbc CLAIMED BUS_NEXUS Bus Converter
processor 0 33 processor CLAIMED PROCESSOR Processor
pbc 1 36 pbc CLAIMED BUS_NEXUS Bus Converter
processor 1 37 processor CLAIMED PROCESSOR Processor
pbc 2 96 pbc CLAIMED BUS_NEXUS Bus Converter
processor 2 97 processor CLAIMED PROCESSOR Processor
pbc 3 100 pbc CLAIMED BUS_NEXUS Bus Converter
processor 3 101 processor CLAIMED PROCESSOR Processor
memory 0 192 memory CLAIMED MEMORY Memory
#
# dmesg
Jul 31 20:03
gate64: sysvec_vaddr = 0xc0002000 for 2 pages
NOTICE: nfs3_link(): File system was registered at index 3.
NOTICE: autofs_link(): File system was registered at index 6.
NOTICE: cachefs_link(): File system was registered at index 7.
0 sba
0/0 lba
0/0/0/0 btlan
0/0/1/0 c720
0/0/1/0.1 tgt
0/0/1/0.1.0 sdisk
0/0/1/0.3 tgt
0/0/1/0.3.0 stape
0/0/1/0.7 tgt
0/0/1/0.7.0 sctl
0/0/1/1 c720
0/0/1/1.0 tgt
0/0/1/1.0.0 sdisk
0/0/1/1.2 tgt
0/0/1/1.2.0 sdisk
0/0/1/1.7 tgt
0/0/1/1.7.0 sctl
0/0/2/0 c720
0/0/2/0.0 tgt
0/0/2/0.0.0 sdisk
0/0/2/0.2 tgt
0/0/2/0.2.0 sdisk
0/0/2/0.7 tgt
0/0/2/0.7.0 sctl
0/0/2/1 c720
0/0/2/1.7 tgt
0/0/2/1.7.0 sctl
0/0/4/0 asio0
0/0/5/0 asio0
0/1 lba
0/2 lba
0/3 lba
0/4 lba
0/5 lba
0/8 lba
0/8/0/0 td
td: claimed Tachyon TL/TS Fibre Channel Mass Storage card at 0/8/0/0
0/8/0/0.8 fcp
0/8/0/0.8.0.5.0 fcparray
0/8/0/0.8.0.5.0.0 tgt
0/8/0/0.8.0.5.0.0.0 sdisk
0/8/0/0.8.0.5.0.0.1 sdisk
0/8/0/0.8.0.5.0.0.2 sdisk
0/8/0/0.8.0.5.0.0.3 sdisk
0/8/0/0.8.0.5.0.1 tgt
0/8/0/0.8.0.5.0.1.0 sdisk
0/8/0/0.8.0.5.0.2 tgt
0/8/0/0.8.0.5.0.2.0 sdisk
0/8/0/0.8.0.5.0.3 tgt
0/8/0/0.8.0.5.0.3.0 sdisk
0/8/0/0.8.0.255.0 fcpdev
0/8/0/0.8.0.255.0.5 tgt
0/8/0/0.8.0.255.0.5.0 sctl
0/9 lba
0/9/0/0 td
td: claimed Tachyon TL/TS Fibre Channel Mass Storage card at 0/9/0/0
0/9/0/0.8 fcp
0/9/0/0.8.0.4.0 fcparray
0/9/0/0.8.0.4.0.0 tgt
0/9/0/0.8.0.4.0.0.0 sdisk
0/9/0/0.8.0.4.0.0.1 sdisk
0/9/0/0.8.0.4.0.0.2 sdisk
0/9/0/0.8.0.4.0.0.3 sdisk
0/9/0/0.8.0.4.0.1 tgt
0/9/0/0.8.0.4.0.1.0 sdisk
0/9/0/0.8.0.4.0.2 tgt
0/9/0/0.8.0.4.0.2.0 sdisk
0/9/0/0.8.0.4.0.3 tgt
0/9/0/0.8.0.4.0.3.0 sdisk
0/9/0/0.8.0.255.0 fcpdev
0/9/0/0.8.0.255.0.4 tgt
0/9/0/0.8.0.255.0.4.0 sctl
0/10 lba
0/10/0/0 btlan
0/12 lba
0/12/0/0 btlan
32 pbc
33 processor
36 pbc
37 processor
96 pbc
97 processor
100 pbc
101 processor
192 memory
btlan: Initializing 10/100BASE-TX card at 0/0/0/0....
System Console is on the Built-In Serial Interface
btlan: Initializing 10/100BASE-TX card at 0/10/0/0....
btlan: Initializing 10/100BASE-TX card at 0/12/0/0....
Entering cifs_init...
Initialization finished successfully... slot is 9
Logical volume 64, 0x3 configured as ROOT
Logical volume 64, 0x2 configured as SWAP
Logical volume 64, 0x2 configured as DUMP
Swap device table: (start & size given in 512-byte blocks)
entry 0 - major is 64, minor is 0x2; start = 0, size = 8388608
Dump device table: (start & size given in 1-Kbyte blocks)
entry 0000000000000000 - major is 31, minor is 0x12000; start = 117600,
size = 4194304
Starting the STREAMS daemons-phase 1
Create STCP device files
Starting the STREAMS daemons-phase 2
$Revision: vmunix: vw: -proj selectors: CUPI80_BL2000_1108 -c 'Vw
for CUPI80_BL2000_1108 build' -- cupi80_bl2000_1108 'CUPI80_BL2000_1108' Wed
Nov 8 19:24:56 PST 2000 $
Memory Information:
physical page size = 4096 bytes, logical page size = 4096 bytes
Physical: 4194304 Kbytes, lockable: 3231756 Kbytes, available: 3711728 Kbytes
#
The output of ioscan -f and dmesg provide a lot of useful information about our system. We'll use the components and paths in ioscan output and the memory information in dmesg to create a list of components for the respective vPars in the upcoming step. We now know, for instance, that the paths of two of the LAN cards are at 0/0/0/0 and 0/10/0/0. We know the paths of all four processors of 33, 37, 97, and 101. The console is located at 0/0/4/0. From the dmesg output we know that we have a total of four GBytes of RAM that can be spread among the vPars.
From these two outputs we have the information we need to create the Virtual Partitions in the next step.
4) List the Components of the Virtual Partitions
From the ioscan and dmesg messages we can select the components of our first Virtual Partition. The following is a list of components we'll include in this partition:
First vPar cable1
name cable1 processors min of one (bound) max of three (two unbound) with num (bound + unbound) equal to one memory 1024 MB LBA Core I/O 0/0 (all components on 0/0 are implied) LAN 0/0/0/0 (not specified explicitly, on 0/0) boot disk 0/0/1/1.2.0 kernel /stand/vmunix (this is default) autoboot off (manual) console 0/0/4/0 (not specified explicitly, on 0/0)
You may want to set autoboot to auto during installation and set to manual after installation. This makes booting easier during installation.
Some of the components require some explanation concerning the way in which they are implemented with vPars. The following is a more detailed discussion of some of these components, including CPU, memory, and LAN, bootdisk, setboot, kernel, and console.
CPU
The CPUs used in both this partition (cable1) and the one we will define shortly (cable2) are specified with min, max, and num. We will have min bound CPUs that have I/O interrupts assigned to them and are therefore ideal for I/O-intensive applications. The additional CPUs assigned to the vPars are unbound, which do not process I/O interrupts. Therefore, unbound CPUs are ideal for processor-intensive applications as opposed to I/O-intensive applications. unbound CPUs can be freely moved from one vPar to another while vPars are running, so having min bound CPUs gives us the freedom to move around the unbound CPUs. Bound CPUs can also be added to and deleted from Virtual Partitions only when the partition is down.
On machines that employ Non-Uniform Memory Access (NUMA) you would use hardware paths (path) to specify CPUs. This is to ensure that you minimize the distance between CPUs and memory. On systems such as the rp 7400 (formerly know as N-Class) and rp 5400 (formerly know as L-Class) that do not employ NUMA, min is recommended to define bound CPUs.
For our work on cable1 and cable2 and for my work with vPars in general, the most common desire is to have a min number of bound CPUs in all vPars and then move around unbound CPUs as the applications in vPars need them. For instance, when vparcreate is run we would specify the following:
vparcreate -p cable1 -a cpu:::1:3 -a cpu::1
At the time of creation cable1 will have one bound CPU only because we specified a min of one and a num of one. num is the total bound + unbound CPUs, and since we specified one for num, we'll get one bound CPU (I have seen some vPars material use num and some use total so num and total are interchangeable in this book.) Since max is three we have left the door open to add as many as two additional unbound CPUs. If we have two unbound CPUs on our system, we can move them among the vPars as required with vparmodify. To remove the two unbound CPUs from cable2 and add them to cable1, we would issue the two following vparmodify commands:
vparmodify -p cable2 -m cpu::1 <-- reduces cable2 from 3 to 1
vparmodify -p cable1 -m cpu::3 <-- increases cable1 from 1 to 3
We first removed the two unbound CPUs from cable2 and then added them to cable1. If the two unbound CPUs were not assigned to a vPar, we would not have to remove them from cable2 prior to adding them to cable1.
There are many ways to work with CPUs, so by characterizing your applications and understanding the options for using bound and unbound CPUs, you can use the processor mix that best meets your needs.
Memory
We have identified one GByte of memory for cable1. Memory can be specified by range or size.
To add one GByte of memory to cable1 using size we would use the following vparcreate command:
vparcreate -p cable1 -a mem::1024
This vparcreate command specifies only the memory for use in cable1. The full vparcreate command for creating cable1 will be shown in an upcoming section.
The memory is specified in MBytes (1024 MBytes = 1 GByte) in multiples of 64 MBytes. At the time of this writing, the Virtual Partition Monitor consumes roughly 128 MBytes of RAM, so this will not be available to allocate to a Virtual Partition. Modifying memory allocation requires that the Virtual Partition be down, at the time of this writing.
On machines that employ Non-Uniform Memory Access (NUMA) you would use the range. Range is a subset of size. On systems such as the rp 7400 (formerly know as N-Class) and rp 5400 (formerly know as L-Class) that do not employ NUMA, the size is recommended to define memory. The syntax for specifying memory by range is as follows:
mem:::base:range
None of the examples in this book were prepared using NUMA systems so you won't see any examples using the range syntax; all examples use the size syntax.
LAN
The LAN interface used for this first Virtual Partition is on Local Bus Adapter (LBA) zero. This means that any other components on LBA zero would have to be in this Virtual Partition as well. At the time of this writing, components on an LBA can't be shared between vPars.
Note that we have decided not to use the hostname as our Virtual Partition name. As mentioned earlier, it is desirable to use the same name for the hostname and vPar. Because our hostnames are a little hard to remember the system administrator decided to use simple vPar names. When we loaded HP-UX 11i on the system we selected the hostnames (you can also run set_parms after loading 11i to set the system name and other parameters) of cvhdcon3 and cvhdcon4. We then chose the simple vPar names of cable1 and cable2, respectively.
Boot Disk
The ioscan issued earlier in this article showed many disk devices. The boot device for our first Virtual Partition is the internal disk with the hardware path 0/0/1/1.2.0.
At the time of this writing, components that are at or below the Local Bus Adapter (LBA) level are devoted to a single Virtual Partition. This means that although the output of our earlier ioscan command shows four internal disks, all four of these disks must be in the same Virtual Partition because they are on the same LBA.
Kernel
We'll use the default HP-UX kernel of /stand/vmunix for the kernel in this Virtual Partition. Since we're using the default kernel, we don't have to specify this as part of the vparcreate command; however, we'll include it in the vparcreate command for completeness purposes.
setboot Command
In our example we have autoboot set to off for our Virtual Partition. The setboot command on a non-vPars system reads from and writes to stable storage. On a vPars system the setboot command interacts with the Virtual Partition database. In our upcoming example we'll set the autoboot to off when we create cable1 with vparcreate. Running setboot on a vPars system has the effects shown in Table 1-2:
Table 1-2 setboot and Virtual Partitions
|
vPars setboot Option |
Description |
|
-a |
Changes the alternate boot path of the Virtual Partition. To set the alternate boot path: # setboot -a 0/8/0/0.8.0.5.0.0.0 |
|
-b |
Sets the autoboot attribute of the Virtual Partition. To set Autoboot on: # setboot -b on |
|
-p |
Changes the primary boot path of the Virtual Partition. To set the primary boot path: # setboot -p 0/0/1/1.2.0 |
|
-s |
Has no effect. |
|
no options |
Displays information about boot attributes. |
The setboot command is one of the aspects of working with vPars that is different from a non-vPars system.
Console
Chapter 5 of the vPars book contains detailed information on the way in which the console operates in a vPars environment. In our first partition we have specified LBA 0/0 as a component of vPar cable1. Since the physical console at 0/0/4/0 is on the Core I/O card at 0/0, it is an implied component of cable1 and we do not have to specify the physical console in this partition. The other Virtual Partitions on this system will use the virtual console functionality of vPars whereby issuing Ctrl-A cycles between virtual console displays.
Database
The Virtual Partition database that contains all vPar-related information is /stand/vpdb. This is managed, and synchronized for you, so you don't need to pay too much attention to it if you don't want to. You can, however; create an alternate database if you wish. You may want to do this in order to create a completely different Virtual Partition configuration for your system without affecting your currently running database.
When creating Virtual Partitions with vparcreate you can use the -D option and specify an alternate database name that is a file in the /stand directory, such as /stand/vpdb.app2. When you boot vPars from this database (with ISL> hpux /stand/vpmon -D db_file) it is the default, so all modifications made to vPars defined in this database are made to it rather than the default.
Second vPar cable2
We'll list the same categories of components for cable2 as we did for cable1 in the following list:
name cable2 processors min of one (bound) max of three (two unbound) with num (bound + unbound) equal to one memory 1024 MB LAN 0/10/0/0 boot disk 0/8/0/0.8.0.5.0.0.0 kernel /stand/vmunix (this is the default) autoboot off (manual) console virtual console to be created
We now have a list of components for two vPars. The result is that our rp 5400 (formerly know as L-Class) system has been divided into two vPars that look like Figure 1-5:
){kind=link}
Figure 1-5 rp 5400 (formerly know as L-Class) with Two vPars (unused components not shown)
Figure 1-5 reflects what our system will look like when we perform the upcoming steps to create our two vPars. Note that two unbound processors, shown as 2,3 in Figure 1-5, can be assigned to cable1 and cable2 as required.
5) Virtual Partition Kernel-Related Work
Each Virtual Partition has its own instance of HP-UX 11i, which has its own HP-UX kernel. It is likely that you'll customize these kernels in a variety of ways to suit the applications you have running in the respective vPars. When you install the vPars software, it automatically reconfigures the kernel to include the vPar drivers and make the kernel relocatable. You do not have to perform the kernel-related steps in this section because they are performed for you when vPars software is loaded. It is still informative; however, to see the steps that were manually performed in this section to get better insight concerning the way vPars operate. In this step we'll investigate the files that have been updated by the vPars application and build the new kernel. Keep in mind that the new kernel needs to be built on every volume that has HP-UX 11i on it and will run a vPar.
Because memory is shared among multiple vPars, the kernel must be relocatable in memory. At the time of this writing, there are patches that allow the kernel to be built as a relocatable kernel. We won't perform any checks related to patches.
The file /sbin/vecheck is a vPar file that is required on the system. The following listing is a portion of /usr/conf/gen/config.sys that checks to see if /sbin/vecheck has been loaded on the system:
# Determine whether the linker supports kernel relocation. If it does,
# link the kernel using the relocation options.
LOADOPTS_ADDL=´ \
if [ -f /sbin/vecheck ]; then \
${WHAT} ${LD} | \
${AWK} '$$0 ~ /92453-07 linker/ { \
split($$7, vers, "."); \
if ( vers[1] == "B" && \
( vers[2] == 11 && vers[3] >= 25 ) || vers[2] > 11 ) \
print "${LOADOPTS_RELOC}"; \
else print "${LOADOPTS_STATIC}"; }'; \
else \
echo "${LOADOPTS_STATIC}"; \
fi; \
The following is a long listing of /sbin/vecheck which was loaded with the vPar software:
# ll /sbin/vecheck -r-xr-xr-x 1 bin bin 20533 Mar 5 19:01 /sbin/vecheck #
Next let's take a look at /stand/system to see the vpar driver that has been added to the file:
# cat /stand/system
***************************************
* Source: /ux/core/kern/filesets.info/CORE-KRN/generic
* @(#)B.11.11_LR
*
***************************************
* Additional drivers required in every
* machine-type to create a complete
* system file during cold install.
* This list is every driver that the
* master.d/ files do not force on the system
* or is not identifiable by ioscan.
* Other CPU-type specific files can exist
* for their special cases.
* see create_sysfile (1m).
***************************************
*
* Drivers/Subsystems
sba
lba
c720
sctl
sdisk
asio0
cdfs
cxperf
olar_psm
olar_psm_if
dev_olar
diag0
diag1
diag2
dmem
dev_config
iomem
nfs_core
nfs_client
nfs_server
btlan
maclan
dlpi
token_arp
inet
uipc
tun
telm
tels
netdiag1
nms
hpstreams
clone
strlog
sad
echo
sc
timod
tirdwr
pipedev
pipemod
ffs
ldterm
ptem
pts
ptm
pckt
td
fddi4
gelan
GSCtoPCI
iop_drv
bs_osm
vxfs
vxportal
lvm
lv
nfsm
rpcmod
autofsc
cachefsc
cifs
prm
vpar <--- vpar driver added here
STRMSGSZ 65535
nstrpty 60
dump lvol
maxswapchunks 2048
#
The vpar driver is a master driver described in /usr/conf/master.d as shown below:
# pwd /usr/conf/master.d # cat vpar $CDIO vpar 0 $$$ $DRIVER_INSTALL vcn -1 209 vcs -1 -1 vpar_driver -1 -1 $$$ $DRIVER_DEPENDENCY vcn vpar vcs vpar vpar vcs vcn vpar_driver vpar_driver vpar $$$ $DRIVER_LIBRARY * * The driver/library table. This table defines which libraries a given * driver depends on. If the driver is included in the dfile, then the * libraries that driver depends on will be included on the ld(1) command * line. Only optional libraries *need* to be specified in this table, * (but required ones can be included, as well). * * Driver handle <libraries> * * subsystems first vcn libvpar-pdk.a vcs libvpar-pdk.a vpar libvpar-pdk.a vpar_driver libvpar-pdk.a $$$ $LIBRARY * * The library table. Each element in the library table describes * one unique library. The flag member is a boolean value, it is * initialized to 1 if the library should *always* be included on * the ld(1) command line, or 0 if the library is optional (i.e. it * is only included when one or more drivers require it). The order * of the library table determines the order of the libraries on the * ld(1) command line, (i.e. defines an implicit load order). New * libraries must be added to this table. * Note: libhp-ux.a must be the last entry, do not place * anything after it. * * Library <required> * libvpar-pdk.a 0 $$$ #
You can see in this file there are multiple drivers present. The vcn and vcs drivers are used to support the console in a vPars environment. Since you'll probably only have one physical console for multiple partitions, you need a way to share the physical device. The use of these drivers is described in Chapter 4 in the vPars book in which kernel configuration is covered. For now it is sufficient to know that these drivers exist as part of the vPars installation and must be built into the kernel.
Now that the kernel has what it needs to be built relocatable and the drivers are present for vPars, we can run mk_kernel to build the new kernel and kmupdate to move the new kernel-related files into place. This is done automatically for you, but the following commands show how you would perform this process:
# mk_kernel Generating module: krm... Compiling /stand/build/conf.c... Loading the kernel... Generating kernel symbol table... # kmupdate Kernel update request is scheduled. Default kernel /stand/vmunix will be updated by newly built kernel /stand/build/vmunix_test at next system shutdown or startup time. #
Keep in mind that this procedure needs to be performed for all HP-UX 11i operating systems that will run a Virtual Partition.
6) Create the First Virtual Partition
The vparcreate command is used to create a vPar. The summary of this command is shown in Table 1-1 and its man page appears in Appendix A. The general form of the command is as follows:
vparcreate -p vp_name [-B boot_attr] [-D db_file] [-S static_attr] [-b kernel_path] [-o boot_opts] [-a rsrc] [-a...]
When creating this vPar, I placed the vparcreate command in a file so that I could modify it for the second vPar and execute it. The vparcreate command is shown below:
# cat /tmp/cable1 vparcreate -p cable1 -B manual -b /stand/vmunix -a cpu::1 -a cpu:::1:3 -a mem::1024 -a io:0/0 -a io:0/0/1/1.2.0:boot #
After changing the permissions on this file and running it, the vPar cable1 was successfully created. Next we'll boot the vPar we just created.
7) Boot the First Virtual Partition
Now that the first vPar has been created and the kernel automatically rebuilt to support vPars, we can boot the first vPar which we named cable1.
We'll both boot off the first vPar and check its status. We need to load the Virtual Partition Monitor (vpmon) at the ISL> prompt. vpmon is a ramdisk kernel, similar to vmunix, that needs to be loaded at the time of boot. From the ISL> prompt we are going to run vpmon to get the MON> prompt. From the MON> prompt we boot our Virtual Partition with vparload, as shown in the following example:
ISL> hpux /stand/vpmon Boot : disk(0/0/1/1.2.0.0.0.0.0;0)/stand/vpmon 421888 + 142056 + 4247112 start 0x23000 cable1: WARNING: No boot device specified Welcome to VPMON (type '?' for a list of commands) MON> vparload -p cable1 [MON] Console client set to cable1 [MON] cable1 loaded . . .
You may see messages different from those shown in the example after the vparload command was issued. In any event, the system progressed through the remainder of the boot process and booted the one Virtual Partition cable1 that we created. We now have a subset of the system components dedicated to this Virtual Partition.
The vparload command has the following three forms:
form1: vparload -all form2: vparload -auto form3: vparload -p vp_name [-b kernelpath] [-o boot_options] [-B hardware_path]
We issued the third form shown above.
Now that the partition has booted, let's first obtain the status of the one Virtual Partition we created, called cable1, that we have running:
# vparstatus -p cable1 -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33
Unbound [Path]:
[IO Details]
0.0
0.0.1.1.2.0 BOOT
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
The output of vparstatus shows that cable1 is up. The -v option is used to obtain a verbose output. You can see from this listing that the bound CPU at hardware path 33 (the bound CPU we specified with the min) is part of the partition, that there is one GByte of memory in the partition, and that the I/O components we specified are in the partition. Had there been other partitions configured, we would have seen their output as well.
Note that the console at 0/0/4/0 is an implied component of this vPar. So too is the LAN interface at 0/0/0/0. Both of these components are part of the Core I/O card that we specified as part of cable1 with the -a io:0/0 argument to the vparcreate command.
We can now run vparstatus -A to view the available components of our system. Since we created a first partition with only one CPU, we should see three CPUs and many other system components available, as shown in the following listing:
# vparstatus -A
[Unbound CPUs (path)]: 37
97
101
[Available CPUs]: 3
[Available I/O devices (path)]: 0.1
0.2
0.3
0.4
0.5
0.8
0.9
0.10
0.12
32
36
96
100
[Unbound memory (Base /Range)]: 0x0/128
(bytes) (MB) 0xc000000/1856
0x180000000/1088
[Available memory (MB)]: 3072
#
This output shows many components available for our second partition. Based on our earlier planning exercise, we know the components that we wish to include in the second vPar, and this vparstatus -A command confirms that they are indeed available.
For cable2 we want one CPU initially, and there are three available. We want the I/O cards for boot and LAN at 0/8 and 0/10 respectively We want one GByte of memory and there are now roughly three GBytes available. We have all of the components we need to proceed to our next step of creating cable2.
8) Create the Second Virtual Partition
We earlier listed all of the components of which our second partition is to be comprised and confirmed that these components are still available with the vparstatus -A command. HP-UX 11i has already been loaded on a second disk on the same system used to create our first Virtual Partition cable1. We can create our second Virtual Partition, which we'll call cable2. We'll create the second while the first is running and boot the second vPar from the first.
Here are the components we earlier listed for our second vPar:
name cable2 processors min of one (bound) max of three (two unbound) with num (bound + unbound) equal to one memory 1024 MB LAN 0/10 LBA 0/8 boot disk 0/8/0/0.8.0.5.0.0.0 kernel /stand/vmunix (this is the default) autoboot off (manual) console virtual console to be created
There are several differences between the list of components for the two vPars. We have devoted a different LAN card and boot disk. We have specified the CPUs in the same manner in both vPars with min (this will be bound) of one and max of three, num of one, and let the vPars software identify the one bound processor. These two Virtual Partitions will use different I/O paths for their devices. Let's now run the vparcreate command to create cable2:
We can now proceed to create the second partition with the command shown in the following file:
# cat /tmp/cable2 vparcreate -p cable2 -B manual -b /stand/vmunix -a cpu::1 -a cpu:::1:3 -a mem::1024 -a io:0/8 -a io:0/8/0/0.8.0.5.0.0.0:boot -a io:0/10 #
After executing this file we can determine if the second vPar has been created and the components of which it is comprised by running vparstatus:
# vparstatus -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33
Unbound [Path]:
[IO Details]
0.0
0.0.1.1.2.0 BOOT
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
[Virtual Partition Details]
Name: cable2
State: Down
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 37
Unbound [Path]:
[IO Details]
0.8
0.8.0.0.8.0.5.0.0.0, BOOT
0.10
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
This output shows that the first vPar is intact and that the second has been successfully created with the name, kernel file, CPU, I/O, and memory components we specified. Note that each vPar has one bound CPU assigned to it. The LAN card assigned to cable2 appears in the output because we specified LBA 0/10 as one of the components of cable2. The console at 0/0/4/0 and the LAN interface at 0/0/0/0 are implied components of cable1 and do not appear in the vparstatus -v output.
With the second vPar created, we can proceed to the next step and boot it.
9) Boot the Second Virtual Partition
Since we already have the first vPar running, called cable1, and the second vPar created, called cable2, we can boot the second vPar from the first. There are many options to boot vPars. Since we already have the first vPar running, we'll simply boot the second from the first with vparboot and then run vparstatus -v as shown in the following example. If we type subsequent vparstatus commands we can see the status of vPar cable2 progress from Load, to Boot in the next output, and finally Up when the vPar is running, as shown in the following listing:
# vparboot -p cable2
vparboot: Booting cable2. Please wait...
# vparstatus
[Virtual Partition]
Boot
Virtual Partition Name State Attributes Kernel Path Opts
============================== ===== ========== ========================= =====
cable1 Up Dyn,Manl /stand/vmunix
cable2 Load Dyn,Manl /stand/vmunix
[Virtual Partition Resource Summary]
CPU Num Memory (MB)
CPU Bound/ IO # Ranges/
Virtual Partition Name Min/Max Unbound devs Total MB Total MB
============================== ================ ==== ====================
cable1 1/ 3 1 0 4 0/ 0 1024
cable2 1/ 3 1 0 4 0/ 0 1024
# vparstatus
[Virtual Partition]
Boot
Virtual Partition Name State Attributes Kernel Path Opts
============================== ===== ========== ========================= =====
cable1 Up Dyn,Manl /stand/vmunix
cable2 Boot Dyn,Manl /stand/vmunix
[Virtual Partition Resource Summary]
CPU Num Memory (MB)
CPU Bound/ IO # Ranges/
Virtual Partition Name Min/Max Unbound devs Total MB Total MB
============================== ================ ==== ====================
cable1 1/ 3 1 0 4 0/ 0 1024
cable2 1/ 3 1 0 4 0/ 0 1024
# vparstatus
[Virtual Partition]
Boot
Virtual Partition Name State Attributes Kernel Path Opts
============================== ===== ========== ========================= =====
cable1 Up Dyn,Manl /stand/vmunix
cable2 Up Dyn,Manl /stand/vmunix
[Virtual Partition Resource Summary]
CPU Num Memory (MB)
CPU Bound/ IO # Ranges/
Virtual Partition Name Min/Max Unbound devs Total MB Total MB
============================== ================ ==== ====================
cable1 1/ 3 1 0 4 0/ 0 1024
cable2 1/ 3 1 0 4 0/ 0 1024
#
This progression of states of cable2 reflects the time it takes to boot the operating system from the second volume on which this vPar is run.
In addition to load, boot, and up, there are other states in which you may find a Virtual Partition as well. Table 1-3 summarizes the states of Virtual Partitions at the time of this writing:
Table 1-3 Virtual Partitions States
|
vPars State |
Description |
|
load |
The kernel image of a Virtual Partition is being loaded into memory. This is done by the Virtual Partition monitor. |
|
boot |
The Virtual Partition is in the process of booting. The kernel image has been successfully loaded by the Virtual Partition monitor. |
|
up |
The Virtual Partition has been successfully booted and is running. |
|
shut |
The Virtual Partition is in the process of shutting down. |
|
down |
The Virtual Partition is not running and is down. |
|
crash |
The Virtual Partition has experienced a panic and is crashing. |
|
hung |
The Virtual Partition is not responding and is hung. |
With more than one vPar running, you would use the built-in vPars drivers to toggle the console between any number of Virtual Partitions using Ctrl-A. Figure 1-6 shows using the console to view cable1 with a hostname of cvhdcon3. Issuing Ctrl-A connects to vPar cable2 with a hostname of cvhdcon4. When you issue Ctrl-A to switch to the next vPar in the console you are supplied with the name of the vPar to which you have connected in brackets, such as [cable1].
){kind=link}
Figure 1-6 Console Shown Using Ctrl-A to Toggle Between vPars
In addition to using the console to switch between vPars, you can also use the LAN cards configured into the respective vPars to open a TELNET or other type of session to the vPars. This is the same technique you would use to connect to any system over the network and is one of the primary reasons you always want to have a LAN card configured as part of every vPar.
We did not cover the configuration of the two LAN cards, one in each vPar, in this article. The LAN configuration would have to be completed for both vPars in order to use the networking cards for such operations as a TELNET session. Chapter 13 of the vPars book covers many networking topics, including the /etc/hosts file; /etc/rc.config.d/netconf file, which must be configured on each vPar; and many others.
10) Modify the Virtual Partition
It is likely that you'll want to modify your Virtual Partitions in a variety of ways. You may want to add or remove a CPU, for instance. Let's take a look at an example of adding a CPU to a Virtual Partition.
In the upcoming example there is a four-processor system on which there are the two Virtual Partitions we just created: cable1 and cable2. Each vPar has one bound CPU that was assigned by min when the vPars were created. Let's run vparstatus to see the components of which these two Virtual Partitions are comprised and confirm that each has one bound CPU:
# vparstatus -p cable1 -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33 <-- one bound CPU @ 33
Unbound [Path]:
[IO Details]
0.0
0.0.1.1.2.0 BOOT
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
# vparstatus -p cable2 -v
[Virtual Partition Details]
Name: cable2
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 37 <-- one CPU in use at 37
Unbound [Path]:
[IO Details]
0.8.0.0.8.0.5.0.0.0 BOOT
0.10.0.0
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
The output of these two vparstatus commands shows that cable1 has one bound CPU and cable2 has one bound CPU. On the rp 5400 (formerly know as L-Class) system on which these vPars were created there are a total of four CPUs. This means that two CPUs should be available. Let's run vparstatus -A to view the available components on a system:
# vparstatus -A
[Unbound CPUs (path)]: 97
101
[Available CPUs]: 2
[Available I/O devices (path)]: 0.1
0.2
0.3
0.4
0.5
0.9
0.12
32
36
96
100
[Unbound memory (Base /Range)]: 0x0/64
(bytes) (MB) 0xc000000/1856
0x180000000/128
[Available memory (MB)]: 2048
#
This output confirms that there are two CPUs available at hardware paths 97 and 101. We can add these CPUs in a variety of ways. Let's use the vparmodify command to change the num of CPUs in cable1 to two CPUs. We do this by adding one to the current number of CPUs with -a. This is a relative operation in that one CPU will be added to the current number of CPUs. You can use vparmodify -m if you want to specify the absolute number of CPUs for the vPar rather than the relative number. The following shows this vparmodify command:
# vparmodify -p cable1 -a cpu::1 #
We can now run vparstatus -p cable1 -v to confirm that the CPU has been added, shown in the following listing:
# vparstatus -p cable1 -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33 <-- original CPU @ 33
Unbound [Path]: 97 <-- unbound CPU @ 97
[IO Details]
0.0
0.0.1.1.2.0 BOOT
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
The vparstatus output shows that the CPU at hardware path 97 has indeed been added to cable1 with the vparmodify command as unbound.
In addition, we can run GlancePlus or top to confirm that there are two CPUs in use on cable2. The following is a top output run on cable2:
# top System: cvhdcon3 Thu Oct 4 15:30:42 2001 Load averages: 0.19, 0.51, 0.62 124 processes: 110 sleeping, 14 running Cpu states: CPU LOAD USER NICE SYS IDLE BLOCK SWAIT INTR SSYS 0 0.37 0.0% 0.2% 0.0% 99.8% 0.0% 0.0% 0.0% 0.0% 1 0.02 0.0% 0.0% 0.8% 99.2% 0.0% 0.0% 0.0% 0.0% --- ---- ----- ----- ----- ----- ----- ----- ----- ----- avg 0.19 0.0% 0.2% 0.4% 99.4% 0.0% 0.0% 0.0% 0.0% Memory: 93636K (57816K) real, 322124K (239536K) virtual, 746284K free Page# 1/4 CPU TTY PID USERNAME PRI NI SIZE RES STATE TIME %WCPU %CPU COMMAND 0 ? 36 root 152 20 0K 832K run 0:00 0.33 0.33 vxfsd 1 ? 1342 root 158 10 80K 212K sleep 0:10 0.28 0.28 cclogd 0 ? 1149 root 152 20 4644K 7260K run 0:06 0.21 0.21 prm3d 1 ? 922 root 154 24 540K 808K sleep 0:00 0.15 0.15 hpterm 0 pty/ttyp1 3114 root 186 24 596K 528K run 0:00 0.17 0.15 top 1 ? 1146 root -16 20 7788K 7240K run 0:03 0.14 0.13 midaemon 1 ? 3 root 128 20 0K 32K sleep 0:04 0.11 0.11 statdaemon 0 ? 2018 root 154 20 3908K 1908K sleep 0:00 0.05 0.04 alarmgen 1 ? 1272 root 152 20 856K 960K run 0:00 0.04 0.04 opcmona 1 ? 1372 root 152 20 1076K 2356K run 0:00 0.04 0.04 samd 0 ? 0 root 128 20 0K 0K sleep 0:11 0.02 0.02 swapper 1 ? 1 root 168 20 448K 204K sleep 0:00 0.02 0.02 init 0 ? 2 root 128 20 0K 32K sleep 0:00 0.02 0.02 vhand 0 ? 4 root 128 20 0K 32K sleep 0:00 0.02 0.02 unhashdaemo 1 ? 20 root 147 20 0K 32K sleep 0:00 0.02 0.02 lvmkd 0 ? 22 root 147 20 0K 32K sleep 0:00 0.02 0.02 lvmkd 1 ? 24 root 147 20 0K 32K sleep 0:00 0.02 0.02 lvmkd 0 ? 339 root 154 20 152K 204K sleep 0:00 0.02 0.02 syncer 0 ? 342 root 168 20 76K 192K sleep 0:00 0.02 0.02 vphbd 0 ? 345 root 168 20 156K 216K sleep 0:00 0.02 0.02 vpard 0 ? 410 root 154 20 80K 224K sleep 0:00 0.02 0.02 syslogd 0 ? 446 root 127 20 156K 424K sleep 0:00 0.02 0.02 netfmt 0 ? 552 root 154 20 740K 816K sleep 0:00 0.02 0.02 rpc.statd 0 ? 558 root 154 20 1004K 1032K sleep 0:00 0.02 0.02 rpc.lockd 0 ? 586 root 154 20 180K 316K sleep 0:00 0.02 0.02 inetd 0 ? 855 root 154 20 1064K 472K sleep 0:00 0.02 0.02 sendmail: 0 ? 863 root 154 20 772K 712K sleep 0:00 0.02 0.02 snmpdm 0 ? 896 root 154 20 620K 552K sleep 0:00 0.02 0.02 mib2agt 0 ? 914 root 154 20 1332K 444K sleep 0:00 0.02 0.02 cmsnmpd 1 ? 951 root 154 20 4044K 1840K sleep 0:00 0.02 0.02 rpcd 1 pty/ttyp1 952 root 158 24 512K 180K sleep 0:00 0.02 0.02 sh 0 ? 974 root 168 20 152K 304K sleep 0:04 0.02 0.02 scrdaemon 0 ? 996 root 154 20 200K 336K sleep 0:00 0.02 0.02 pwgrd 0 ? 1039 root 154 10 308K 428K sleep 0:00 0.02 0.02 diagmond 0 ? 1093 root 154 20 1224K 816K sleep 0:00 0.02 0.02 ttd 1 ? 1135 root 154 20 2588K 1624K sleep 0:00 0.02 0.02 perflbd 0 ? 1156 root 154 20 2952K 1572K sleep 0:00 0.02 0.02 swagentd 0 ? 1167 root 154 20 224K 252K sleep 0:00 0.02 0.02 emsagent 0 ? 1168 root 127 20 2380K 2204K sleep 0:00 0.02 0.02 scopeux
This output shows two CPUs, labeled 0 and 1, in cable1. The System name of cvhdcon3 is shown at the output because the hostname for cable1 is cvhdcon3.
Although this is a simple example showing how a Virtual Partition can be modified, it also demonstrates the power of vPars. While both vPars on the system are running, a processor can be added to one or both without interruption of the programs running in the vPars.
Note that the -a option to vparmodify changed the number of CPUs relative to the current number. In our case the current number of CPUs was one and using -a cpu::1 added one CPU to the current number of one resulting in two CPUs. This is true also when we use the -d option to vparmodify to remove processors. The following example shows running vparstatus to see the two CPUs, using vparmodify to change the number of CPUs back to one (this is also relative to the current number of CPUs, which is two,) and a vparstatus to confirm that this change has taken place:
# vparstatus -p cable1 -v
# vparstatus -p cable1 -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33 <-- bound CPU @ 33
Unbound [Path]: 97 <-- unbound CPU @ 97
[IO Details]
0.0
0.0.0.0
0.0.1.1.2.0 BOOT
0.0.4.0 CONSOLE
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
# vparmodify -p cable1 -d cpu::1
# vparstatus -p cable1 -v
[Virtual Partition Details]
Name: cable1
State: Up
Attributes: Dynamic,Manual
Kernel Path: /stand/vmunix
Boot Opts:
[CPU Details]
Min/Max: 1/3
Bound by User [Path]:
Bound by Monitor [Path]: 33 <-- original CPU @ 33
Unbound [Path]: <-- no unbound CPUs
[IO Details]
0.0
0.0.0.0
0.0.1.1.2.0 BOOT
0.0.4.0 CONSOLE
[Memory Details]
Specified [Base /Range]:
(bytes) (MB)
Total Memory (MB): 1024
#
We could perform many other modifications to the vPars with the two unbound CPUs that are available, such as adding two CPUs to one of the vPars or one CPU to each vPar.
Please keep in mind the relative nature of components when using vparmodify and that some changes, such as modifying memory or adding I/O components, require the vPar to be down at the time of this writing.
Virtual Partition Dump Files
When a Virtual Partition crashes, a dump file is created in /stand/vmpon.dmp. When the Virtual Partition boots, files are created in /var/adm/crash/vpar. The files have an extension with a number indicating the number of the dump that occurred. For instance, vpmon.1, vpmon.dmp.1, and summary.1 indicate the first set of files that are saved in /var/adm/crash/vpar.
An example of what you might see in /stand and /var/adm/crash/vpar related to dumps are shown in the following listing:
VPARNAME = extraq1 # ll /stand total 100400 -rw-r--r-- 1 root sys 19 Jul 13 15:04 bootconf drwxr-xr-x 4 root sys 2048 Oct 18 11:43 build drwxrwxrwx 5 root sys 1024 Oct 18 13:06 dlkm drwxrwxrwx 5 root root 1024 Oct 18 11:21 dlkm.vmunix.prev -rw-r--r-- 1 root sys 3388 Oct 18 13:16 ioconfig -r--r--r-- 1 root sys 82 Jul 13 15:34 kernrel drwxr-xr-x 2 root sys 1024 Oct 18 13:18 krs drwxr-xr-x 2 root root 1024 Oct 18 13:16 krs_lkg drwxr-xr-x 2 root root 1024 Oct 18 13:18 krs_tmp drwxr-xr-x 2 root root 8192 Jul 13 15:04 lost+found -rw------- 1 root root 12 Oct 18 13:16 rootconf -r--r--r-- 1 root sys 2035 Oct 18 11:42 system -r--r--r-- 1 root sys 994 Jul 13 15:28 system.01 -r--r--r-- 1 root sys 999 Jul 13 15:56 system.02 -r--r--r-- 1 root sys 994 Jul 13 15:28 system.base drwxr-xr-x 2 root sys 1024 Jul 13 15:37 system.d -r--r--r-- 1 root sys 2035 Oct 18 10:55 system.prev -rwxr-xr-x 1 root root 22682568 Oct 18 13:16 vmunix -rwxr-xr-x 1 root root 22682568 Oct 18 11:04 vmunix.prev -rw------- 1 root sys 8232 Oct 18 13:36 vpdb -rw------- 1 root root 8232 Jul 17 14:11 vpdb.OLD -r-xr-xr-x 1 bin bin 837616 Aug 31 18:59 vpmon -rw------- 1 root root 5078504 Oct 10 10:43 vpmon.dmp <-- vPar dump # ll /var/adm/crash/vpar <-- vPar dump directory total 46464 -rw-r--r-- 1 root root 2 Oct 10 10:43 count -rw-r--r-- 1 root root 16794 Jul 17 13:26 summary.0 -rw-r--r-- 1 root root 17953 Jul 18 10:35 summary.1 -rw-r--r-- 1 root root 19538 Jul 18 11:36 summary.2 -rw-r--r-- 1 root root 10012 Oct 10 10:43 summary.3 -r-xr-xr-x 1 root root 855928 Jul 17 13:26 vpmon.0 -r-xr-xr-x 1 root root 855928 Jul 18 10:35 vpmon.1 -r-xr-xr-x 1 root root 855928 Jul 18 11:36 vpmon.2 -r-xr-xr-x 1 root root 837616 Oct 10 10:43 vpmon.3 -rw------- 1 root root 5078504 Jul 17 13:26 vpmon.dmp.0 -rw------- 1 root root 5078504 Jul 18 10:35 vpmon.dmp.1 -rw------- 1 root root 5078504 Jul 18 11:36 vpmon.dmp.2 -rw------- 1 root root 5078504 Oct 10 10:43 vpmon.dmp.3
The /var/adm/crash/vpar directory has in it the vPar dump-related files for four (0-3) crashes.
The dump file created in /stand is saved in /var/adm/crash/vpar and extended with the crash number. The dump file in /stand is overwritten with each crash, but you have a history with all of the dump files and related information in /var/adm/crash/vpar. Please leave in place the /stand/vpmon.dmp file.
Summary
There were some vPars-related commands in this article that were not used. The vparreset and vparremove commands summarized in Table 1-1 were not issued at all for instance. The vparremove command can be run on any vPar provided that it is in the down state. The general steps to get vPars up and running and to perform some modification were covered to give you a simple framework from which to work. There are some other commands that were not covered, for which there are manual pages in Appendix A as well.
More detail in specific areas appears in other chapters of the vPars book and I encourage you to review the online man pages for all of the vPars in Appendix A.
There are also some considerations related to server technology that we did not cover. If you have Instant Capacity on Demand (iCOD) employed on your server, all CPUs must be activated in order for vPars to work. When employing Processor Sets (psets) in a vPar, use only bound CP