The hwmgr command is a new tool that is akin to "one-stop shopping" when it comes to hardware management. It replaces the scsimgr(8) utility and can perform many functions that the scu(8) utility does – although scu is not obsolete. The hwmgr command is cluster-aware, and many of its options can be directed on a specified member or on the entire cluster. The hwmgr command manages three hardware subsystems:
component
The component subsystem maintains information about all hardware components on the system. This information is stored in two databases: dec_hwc_ldb (local) and dec_hwc_cdb (cluster).
name
The name subsystem maintains hardware persistence information for hardware components such as buses and controllers. This information is stored in dec_hw_db.
scsi
The scsi subsystem maintains information about SCSI devices. This information is stored in dec_scsi_db.
For additional information on the various hardware databases, see section 7.3 earlier in this chapter.
The absolute best information regarding the hwmgr command, as of this writing, is the hwmgr command itself.
# hwmgr -help | grep –E "^Usage|^ *or" Usage: hwmgr -flash light or: hwmgr -get attribute [ saved | default | current ] or: hwmgr -get category or: hwmgr -help [ <command> ] [ <subsystem> ] or: hwmgr -set attribute [ saved | current ] -a <attribute>=<value> or: hwmgr -view cluster or: hwmgr -view devices or: hwmgr -view hierarchy or: hwmgr -view env or: hwmgr -view timestamps or: hwmgr -view transaction or: hwmgr <command> <subsystem> <args>
We only included the basic command usage using the grep(1) command, although the last hwmgr command usage, "or: hwmgr <command> <subsystem> <args>", actually has many permutations.
# hwmgr -help | grep -p -E "(^Where <command>)" Where <command> is: -add -delete -edit -locate -online -offline -power -redirect -refresh -reload -remove -scan -show -status -unconfigure -unindict -unload
We will not attempt to show you every possible option to the hwmgr command but will focus instead on a few of the more useful options.
For further information see the hwmgr(8) reference page on V5.0A and V5.1. In V5.1A the hwmgr(8) reference page is augmented by four additional reference pages:
| – reference page for the get and set command options. |
| – reference page for the show commands options. |
| – reference page for the view commands options. |
| – reference page for the other commands options: add, delete, edit, locate, offline, online, power, redirect, refresh, reload, remove, scan, status, unconfigure, unindict, unload. |
# hwmgr -view devices HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 4: /dev/kevm 30: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0 40: /dev/disk/dsk0c COMPAQ BB009235B6 bus-2-targ-0-lun-0 41: /dev/disk/dsk1c COMPAQ BB009235B6 bus-2-targ-1-lun-0 45: /dev/disk/cdrom0c COMPAQ CRD-8402B bus-0-targ-0-lun-0
Note | The hwmgr command options can be abbreviated to uniqueness. For example: |
# hwmgr –view devices
This can be abbreviated to:
# hwmgr –v d
Also, note that the main keyword does not require a hyphen (-) although subsequent options do. For example, "view" is equivalent to "-view", the "-dsf" option must contain a "-".
# hwmgr view device -dsf dsk3
You can just show specific devices too. For example, let's search for only tape devices on a system:
# hwmgr -v d -category tape HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 75: /dev/ntape/tape0 COMPAQ SDT-9000 bus-6-targ-0-lun-0
As stated earlier, many command options can be focused on a member or the entire cluster. How do you know which options can be focused on another member or the entire cluster? Ask hwmgr.
# hwmgr -help view dev Usage: hwmgr -view devices [ -dsf <device-special-filename> ] [ -category <hardware-category> ] [ -member <cluster-member-name> ] [ -cluster ]
Another way to show devices using hwmgr is to look at the scsi subsystem.
# hwmgr -show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ----------------------------------------------------------------------------------------- 0: 0 sheridan cdrom none 0 1 (null) 40: 1 sheridan disk none 2 1 dsk0 [2/0/0] 41: 2 sheridan disk none 2 1 dsk1 [2/1/0] 45: 3 sheridan cdrom none 0 1 cdrom0 [0/0/0] 53: 4 sheridan disk none 0 1 (null) 54: 5 sheridan disk none 0 1 (null) 55: 6 sheridan disk none 0 1 (null) 56: 7 sheridan disk none 0 1 (null) 57: 8 sheridan disk none 0 1 (null) 59: 9 sheridan disk none 0 1 (null)
Notice the "(null)" in the output above. This indicates that there is no active path to some of the devices that were previously seen by the system. In this particular instance, the storage cabinet is not powered on. Let's give the storage some juice and rerun the command. First, let's scan the bus.
# hwmgr -scan scsi hwmgr: Scan request successfully initiated
Now, let's see what has changed.
# hwmgr -show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------ ------------------------------------------------------------------------- 0: 0 sheridan cdrom none 0 1 (null) 40: 1 sheridan disk none 2 1 dsk0 [2/0/0] 41: 2 sheridan disk none 2 1 dsk1 [2/1/0] 45: 3 sheridan cdrom none 0 1 cdrom0 [0/0/0] 53: 4 sheridan disk none 0 1 dsk2 [3/0/0] 54: 5 sheridan disk none 0 1 (null) [3/1/0] 55: 6 sheridan disk none 0 1 (null) [3/2/0] 56: 7 sheridan disk none 0 1 (null) [3/3/0] 57: 8 sheridan disk none 0 1 (null) [3/4/0] 59: 9 sheridan disk none 0 1 (null) [3/5/0]
Notice that we now see an active path but still do not see a device name. This is where we can have the dsfmgr command give us a hand. The dsfmgr command with the "-K" option creates all newly detected devices. Note: this additional step should be unnecessary (and is unnecessary in V5.1A). In V5.1 (where this example was created), however, it was necessary.
# dsfmgr -K
Now rerun the original command.
# hwmgr -show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH ------ ------------------------------------------------------------------------- 0: 0 sheridan cdrom none 0 1 (null) 40: 1 sheridan disk none 2 1 dsk0 [2/0/0] 41: 2 sheridan disk none 2 1 dsk1 [2/1/0] 45: 3 sheridan cdrom none 0 1 cdrom0 [0/0/0] 53: 4 sheridan disk none 0 1 dsk2 [3/0/0] 54: 5 sheridan disk none 0 1 dsk3 [3/1/0] 55: 6 sheridan disk none 0 1 dsk4 [3/2/0] 56: 7 sheridan disk none 0 1 dsk5 [3/3/0] 57: 8 sheridan disk none 0 1 dsk6 [3/4/0] 59: 9 sheridan disk none 0 1 dsk7 [3/5/0]
Notice that the "-view devices" option to the hwmgr command (abbreviated to "-v d") now sees the devices as well.
# hwmgr -v d HWID: Device Name Mfg Model Location ------------------------------------------------------------------------------ 4: /dev/kevm 30: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0 40: /dev/disk/dsk0c COMPAQ BB009235B6 bus-2-targ-0-lun-0 41: /dev/disk/dsk1c COMPAQ BB009235B6 bus-2-targ-1-lun-0 45: /dev/disk/cdrom0c COMPAQ CRD-8402B bus-0-targ-0-lun-0 53: /dev/disk/dsk2c COMPAQ BD009635C3 bus-3-targ-0-lun-0 54: /dev/disk/dsk3c COMPAQ BD009635C3 bus-3-targ-1-lun-0 55: /dev/disk/dsk4c COMPAQ BD009635C3 bus-3-targ-2-lun-0 56: /dev/disk/dsk5c COMPAQ BD009635C3 bus-3-targ-3-lun-0 57: /dev/disk/dsk6c COMPAQ BD009635C3 bus-3-targ-4-lun-0 59: /dev/disk/dsk7c COMPAQ BD009635C3 bus-3-targ-5-lun-0
Let's get back to the "-show scsi" option for a moment. If the system contains multiple paths to a device, adding an additional qualifier to the command "-full" will show the paths to you. Although it is not necessary, it is often cleaner if you only look at one device at a time. For example:
# hwmgr -show scsi -full -id 65 SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH -------------------------------------------------------------------------------------- 65: 6 jaffa disk none 0 4 dsk5 [5/0/9] WWID:01000010:6060-1aa1-000f-1a40-0009-0361-3888-0007 BUS TARGET LUN PATH STATE --------------------------------- 5 0 9 valid 5 1 9 valid 6 0 9 valid 6 1 9 valid
Note the output from the last command was taken from a different system that contained a multi-path/multi-bus configuration. As you can see, there are actually four paths to the device. This system has two adapters connected to two Fibre Channel switches, each connected to two Fibre Channel RAID controllers (with dual ports) – in other words, "No Single Point of Failure" (NSPOF).
# hwmgr –view hierarchy HWID: hardware component hierarchy ----------------------------------------------------------- 46: platform COMPAQ AlphaServer DS10 466 MHz 2: cpu CPU0 5: bus pci0 6: connection pci0slot7 18: bus isa0 19: connection isa0slot0 20: keyboard keyboard0 21: pointer mouse0 22: connection isa0slot2 23: serial_port tty00 24: connection isa0slot3 25: serial_port tty01 26: connection isa0slot4 27: parallel_port lp0 28: connection isa0slot5 29: fdi_controller fdi0 30: disk fdi0-unit-0 floppy0 8: connection pci0slot9 31: network tu0 10: connection pci0slot11 32: network tu1 12: connection pci0slot13 33: ide_adapter ata0 34: scsi_bus scsi0 45: disk bus-0-targ-0-lun-0 cdrom0 35: scsi_bus scsi1 42: connection pci0slot14 44: scsi_adapter itpsa1 37: scsi_bus scsi2 40: disk bus-2-targ-0-lun-0 dsk0 41: disk bus-2-targ-1-lun-0 dsk1 14: connection pci0slot15 49: scsi_adapter isp0 50: scsi_bus scsi3 53: disk BA356 Slot 1 (top) cluster-common 54: disk BA356 Slot 2 sheridan boot 55: disk BA356 Slot 3 molari boot 56: disk BA356 Slot 4 quorum 57: disk bus-3-targ-4-lun-0 dsk6 59: disk bus-3-targ-5-lun-0 dsk7 47: connection pci0slot16 51: cluster_interconnect mchan0 52: legacy_driver Legacy-driver-(mchan0) 16: connection pci0slot17 38: graphics_controller comet0
Identify the bad component, such as a bad disk.
# hwmgr -show scsi SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH --------------------------------------------------------------------------------------- ... 56: 7 sheridan disk none 0 1 (null) ...
Delete the component.
# hwmgr –delete component –id 56 hwmgr: Delete operation was successful
If you have added a device while the system was up, you will need to scan the bus.
# hwmgr -scan scsi hwmgr: Scan request successfully initiated
Note | In a cluster environment, the "hwmgr –scan scsi" command will need to be performed cluster-wide. There is not a "–cluster" option to the command. There is, however, a "-member" option that can be used to direct the command to a specific member. We have written a script (clu_scan_scsi) to dispatch hwmgr commands to all cluster members. |
# ./clu_scan_scsi molari: "/sbin/hwmgr scan scsi" hwmgr: Scan request successfully initiated sheridan: "/sbin/hwmgr scan scsi" hwmgr: Scan request successfully initiated
The clu_scan_scsi script is available on the web (see Appendix B for the URL).
# hwmgr -get attribute -id 46 46: name = COMPAQ AlphaServer DS10 466 MHz category = platform memory_size_MB = 256 registration_time = Tue Mar 20 12:39:23 2001 user_name = (null) (settable) location = (null) (settable) software_module = (null) state = available state_previous = unknown state_change_time = none event_count = 0 last_event_time = none
You can see as little as one attribute by specifying that particular attribute with the "-a attribute" option.
# hwmgr -get attribute -a dev_base_name -id 59 59: dev_base_name = dsk7
Here is an example showing several attributes, including searching for an attribute NOT containing a certain value.
# hwmgr get a -a name -a dev_base_name -a power_mgmt_capable!=1 2: name = CPU0 power_mgmt_capable = 0 30: name = FDI-fdi0-unit-0 dev_base_name = floppy0 power_mgmt_capable = 0 45: name = SCSI-WWID:0710002c:"COMPAQ CRD-8402B :d05b000t00000l00000" dev_base_name = cdrom0 power_mgmt_capable = 0
Here is a similar example where we are searching for an attribute that contains a particular value. We are also limiting our search to the "disk" category.
# hwmgr -get a -a dev_base_name -a cluster_disables=1 -cat disk 45: dev_base_name = cdrom0 cluster_disables = 1
Note that some of the conditional parsing does not work as expected. For example, the component at HWID 40 has "COMPAQ" listed as the manufacturer.
# hwmgr -get a -a manufacturer -id 40 40: manufacturer = COMPAQ
Yet, when we specifically state "manufacturer!=COMPAQ", we get the opposite of what we would expect.
# hwmgr -get a -a manufacturer!=COMPAQ 40: manufacturer = COMPAQ ...
If we look for "manufacturer=COMPAQ", we do not see any output.
# hwmgr -get a -a manufacturer=COMPAQ <no output>
We considered that it might be a string parsing problem, but:
# hwmgr -get a -a dev_base_name -a state=available -cat disk 30: dev_base_name = floppy0 state = available 40: dev_base_name = dsk0 state = available ...
This appears to be a bug, and we have notified COMPAQ's Customer Support Center.
Some components have user settable attributes like a name (user_name) or physical location (phys_location). In a large configuration, the ability to give a device a name that is meaningful to you, such as "my boot disk" or its location, can be very useful. First, let's find the "settable" attributes for a particular device.
# hwmgr –get attr –id 46 | grep "(settable)" user_name = (null) (settable) location = (null) (settable)
What device is this?
# hwmgr -get attr -id 46 -a name 46: name = COMPAQ AlphaServer DS10 466 MHz
It's the system. Well, let's set the "user_name" to the system's hostname. Note that the "user_name" attribute is currently limited to fifteen characters. For example:
# hostname | wc -c 17
Notice that the fully qualified hostname of this system is sixteen characters ("wc -c" returns an extra character, probably the newline character). So let's try to set the attribute with more than fifteen characters.
# hwmgr -set attr -a user_name=$(hostname) -id 46 hwmgr: 46: Attribute "user_name" value is too large.
Now let's set the "user_name" attribute by using only the base hostname.
# hwmgr -set attr -a user_name=$(hostname –s) -id 46 46: user_name = sheridan (settable)
Verify that the change has taken place.
# hwmgr -get attr -id 46 -a name -a user_name 46: name = COMPAQ AlphaServer DS10 466 MHz user_name = sheridan (settable)
If you happen to have a large cabinet with a bunch of disks in it, wouldn't it be nice to be able to find the device you are looking for quickly? Well, it can be. Try this:
# hwmgr –flash light –dsf dsk3
Although this only works on SCSI disks, most disks are currently still SCSI, so for the immediate future, this is a useful command. By the way, if the flashing is too slow or fast due to other disk activity in the cabinet, try the "-nopause" option.
You can use the "hwmgr show component" command with the "-inconsistencies" command to locate software inconsistencies in the hardware component database files. An "inconsistency" is a possible internal error in the dec_hwc_cdb and dec_hwc_ldb files.
# hwmgr show comp -i HWID: HOSTNAME FLAGS SERVICE COMPONENT NAME ------------------------------------------------------------ 106: molari rcd-i iomap SCSI-WWID:0c000008:0000-0e11-0018-9f1f
You can obtain additional information by adding the "-full" option.