HP-UX Virtual Partitions

By Marty Poniatowski

System Configuration Repository, which I'll call SCR in this section, gathers a lot of system information that can be used for viewing and can be compared to previously gathered data to produce a list of differences. SCR will view each Virtual Partition as a separate system and should be run separately in each Virtual Partition. SCR is easy to use, so the best way to learn about it is to run some SCR commands. It is particularly important in an environment with Virtual Partitions to use SCR. The more instances of HP-UX you have, the more important it is to maintain information about your system. You can only keep so much information about your vPars in your system log book and SCR may help you maintain more useful information about your vPars and systems.

You can obtain documents related to SCR from www.docs.hp.com. When writing this chapter I obtained two documents that were helpful for installing and using SCR. The first is Troubleshooting Guide for SCR+DMI and the second is System Configuration Repository User's Reference.

Using SCR

SCR is easy to use. The first command to issue is scrconfig with the option -n to register nodes to be managed by SCR. Since you can have a central system act as the SCR server on which information for all managed nodes will be kept, you can issue the scrconfig command on the central system for all systems to be managed. We'll issue it only for the first Virtual Partition used for our earlier vPar example called actappd1 (vPar 1):

root@actappd1[/] > scrconfig -n +actappd1 "actappd1" is registered as a managed node. Default parameters are applied: Schedule time: Off Interval: 1 week Expiration period: 3 months Collection timeout: 15 minutes

To register additional nodes, you would list the node names preceded by the plus sign on the same line in the format:

# scrconfig -n +node1 +node2 +node3 ...

Since the L-Class system in our earlier example had two vPars running on it, we'll register the second vPar called ecvpard2 (vPar 2) as well:

root@actappd1[/] > scrconfig -n +ecvpard2 "ecvpard2" is registered as a managed node. Default parameters are applied Schedule time: Off Interval: 1 week Expiration period: 3 months Collection timeout: 15 minutes

We now have both vPars registered with SCR and we can collect on one or both.

You can schedule data collection for a node to take place at any time. The scrconfig command is also used to schedule data collection. We'll specify the node name with the -n option and use -s to specify the date and time at which we want collection to take place. The following example collects data on 09/06/2001 at 13:05 on vPar 1:

root@actappd1[/] > date Thu Sep 6 12:59:03 EDT 2001 root@actappd1[/] > scrconfig -n actappd1 -s 200109061305 Parameter for "actappd1" is set to: Schedule time: 09/06/2001 13:05 EDT

This command has scheduled collection on vPar 1 on the specified date and time. Note that the time is in 24-hour format. We could initiate data collection on-demand on node l1 by omitting the -s option and date and time with scrconfig -n actappd1. Each time data is collected from a node, it is callled a snapshot. A snapshot will not be saved if there are no changes since the last snapshot that was obtained from the system. If you try to obtain snapshots in very close succession with one another, the second snapshot will probably not be obtained because no changes have occurred to the system.

Let's now issue scrconfig for vPar 1 with the -l option to list the details for vPar 1:

root@actappd1[/] > scrconfig -n actappd1 -l NODE SCHEDULE TIME INTERVAL EXPIRATION TIMEOUT actappd1 09/06/2001 13:05 EDT 1 week 3 months 15 minutes

The output shows our scheduled collection for node vPar 1. If we had other scheduled collections, they would show up in this output as well.

Next, we'll check the data collection status of all nodes that have been registered to see what collections have taken place and what collections are scheduled with scrstatus:

root@actappd1[/] > scrstatus TIME (START - STOP) NODE STATUS DETAIL 09/06/2001 13:05 - EDT actappd1 Scheduled

This output shows our scheduled collection. Let's run the command again after the scheduled collection has taken place:

root@actappd1[/] > scrstatus TIME (START - STOP) NODE STATUS DETAIL 09/06/2001 13:05 - 13:06 EDT actappd1 Completed 09/13/2001 13:05 - EDT actappd1 Scheduled root@actappd1[/] >

This shows that our collection is complete and that a collection has automatically been scheduled for same time one week later. The status of the collection already run is Completed and the status of the upcoming collection is Scheduled.

Next, we'll use the command scrviewer to see data that has been collected for system l1. We specify the system for which we want the file produced as well as collection we want to view. Because the output is long (very long) I have also redirected the output to a file:

root@actappd1[/] > scrviewer actappd1:latest > /tmp/actappd1_scr.txt & [1] 10871

You'll be amazed at the amount of data that has been collected for your system. The following is a very small subset of the data collected by SCR for vPar 1:

Example of software information produced by SCR:

COMPONENT NAME VALUE GROUP NAME ATTRIBUTE NAME "HP-UX Installed Software Definition" "Bundle Contents" "scr dmi class" HPUX_BundleContents_ "scr dmi version" 001 "scr dmi key" "Bundle Software Specification,Index" [Bundle Software Specification] B9788AA,r=1.3.0.01,a=HP-UX_B.11.00_32/ 64,v=HP [Index] 1 [Content] Java2-JDK13_base,r=1.3.0.01,a=HP- UX_B.11.00_32/64,v=HP [Bundle Software Specification] B9788AA,r=1.3.0.01,a=HP-UX_B.11.00_32/ 64,v=HP [Index] 2 [Content] Java2-JDK13_perf,r=1.3.0.01,a=HP- UX_B.11.00_32/64,v=HP [Bundle Software Specification] B9788AA,r=1.3.0.01,a=HP-UX_B.11.00_32/ 64,v=HP

Example of device information produced by SCR:

"Host Processor" "scr dmi class" "HPUX_Host Processor_" "scr dmi version" 001 "scr dmi key" "Host Processor Index" [Host Processor Index] 1 [Processor Firmware ID] "HP PA_RISC2.0" [Processor Allocated] 1:True [Host Processor Index] 2 [Processor Firmware ID] "HP PA_RISC2.0" [Processor Allocated] 1:True "Host Storage" "scr dmi class" "HPUX_Host Storage_" "scr dmi version" 001 "scr dmi key" "Host Storage Index" [Host Storage Index] 1 [Storage Type] 4:FixedDisk [Description] " SEAGATE ST336704LC " [Allocation Unit Size] 1024 [Total Allocation Units] 34732 [Allocation Units Used] 0 [Storage Allocation Failures] 0 [Host Storage Index] 2 [Storage Type] 4:FixedDisk [Description] " SEAGATE ST318404LC " [Allocation Unit Size] 1024 [Total Allocation Units] 17366 [Allocation Units Used] 11580 [Storage Allocation Failures] 0 [Host Storage Index] 3 [Storage Type] 4:FixedDisk [Description] " SEAGATE ST336704LC " [Allocation Unit Size] 1024 [Total Allocation Units] 34732 [Allocation Units Used] 0 [Storage Allocation Failures] 0 [Host Storage Index] 4 [Storage Type] 4:FixedDisk [Description] " SEAGATE ST318404LC " [Allocation Unit Size] 1024 [Total Allocation Units] 17366 [Allocation Units Used] 11580 [Storage Allocation Failures] 0

Example of kernel information produced by SCR:

"Kernel Configure Group" "scr dmi class" "HPUX_Kernel Configure Group_" "scr dmi version" 001 "scr dmi key" "Kernel Configure Group Index" [Kernel Configure Group Index] 1 [Parameter Name] STRMSGSZ [Parameter Value] 65535 [Kernel Configure Group Index] 2 [Parameter Name] nstrpty [Parameter Value] 60 [Kernel Configure Group Index] 3 [Parameter Name] maxswapchunks [Parameter Value] 4096 [Kernel Configure Group Index] 4 [Parameter Name] bufpages [Parameter Value] 0 [Kernel Configure Group Index] 5 [Parameter Name] dbc_max_pct [Parameter Value] 15 [Kernel Configure Group Index] 6 [Parameter Name] dbc_min_pct [Parameter Value] 2 [Kernel Configure Group Index] 7 [Parameter Name] max_thread_proc [Parameter Value] 256 [Kernel Configure Group Index] 8 [Parameter Name] maxdsiz [Parameter Value] 0x20000000

Among the data produced for vPar 1 is extensive software-related information early in the listing, logical volume-related information, and hardware-related information at the end of the listing. There is information produced for many categories. The scrfilter command is used to control what is collected or to manipulate the view of information already collected. Issuing scrfilter -l shows that the following information can be filtered as part of the SCR output:

# scrfilter -l

Disk

FileSystem

LV M

Network

Patch

Probe

Software

SystemProperty

This is the type of information system administrators want to know about their system.

There are several other SCR-related commands and options to commands we've covered that you can issue. Among the most useful commands is scrdiff, which produces a report of differences between collections. The following command would produce a report of differences between the latest and oldest collections for vPar 1:

root@actappd1[/] > scrdiff actappd1:oldest actappd1:latest [1] 2728

Table 11-1 summarizes SCR-related commands. There are manual pages loaded for these commands along with SCR.

SCR uses the Desktop Management Interface (DMI) to obtain collection data from nodes. DMI provides the Application Programming Interfaces (APIs) that are called by SCR to obtain data. The central management system, which is vPar 1 in our examples, requires both DMI and SCR.

There is no additional background material at the end of this chapter on SCR since we covered this product thoroughly in this section.