From: Richard Jackson (rjackson@portal.gmu.edu)
Date: Tue Jul 09 2002 - 07:53:36 EDT
Hello,
I have a few questions related to the KZPCC-CE (3-port PCI RAID)
controller and the 'new' Tru64 UNIX 5.x hardware component management.
The KZPCC-CE is installed in a ES45 running Tru64 UNIX 5.1A patch kit #2.
1. Is it possible to print the KZPCC-CE configuration (e.g., for disaster
recovery)? The KZPAC-CB/KZESC-BA/KZPSC-BA RAID Configuration Utility (RCU)
allowed me to 'print' the configuration to a text file on a floppy to be
printed later. The Compaq StorageWorks KZPCC-CE and KZPCC-AC User Guide,
dated Aug 2001, on page 3-1 states the use of SMOR is restricted to
Compaq AlphaServers with graphics console setting and it is not supported
under a serial console.
2. Is it possible to save the KZPCC-CE configuration (e.g., for disaster
recovery)? The KZPAC-CB/KZESC-BA/KZPSC-BA RAID Configuration Utility (RCU)
allowed me to save the configuration to a floppy.
3. If the KZPCC-CE fails and must be replaced or the configuration is lost,
how do I quickly restore the configuration? If the configuration must be
re-applied via SMOR, doesn't the SMOR 'Set System Config' initialize the
devices (i.e., the user data is lost)?
4. How in the world is the KZPCC logical device defined in the SRM
console? That is, SMOR may report the RAID devices as ID 0, 1, and 2.
However, SRM may report dza526.0.0.2004.1, dza528.0.0.2004.1, and
dza532.0.0.2004.1. I understand if I have DZXabc, X is the controller
ID. How is the abc defined. For example, I had a RAID 1 (ID 0), JBOD
(ID 1), and RAID 0+1 (ID 2) devices. I purchased another disk drive
and converted the JBOD into RAID 1. SMOR reported the new RAID 1
device as ID 1 (HBA:0 Channel:0 Id:1 LUN:0) (this is good and what I
expected) but the SRM console and operating system treated the new RAID
device as ID/LUN 3. The SMOR ID appears to be ignored by the SRM and
Tru64 UNIX 5.1A.
5. Tru64 UNIX 5.1A pk #2 dsfmgr man page example 5 has
/sbin/dsfmgr -R delete hwid 25
Shouldn't this be
/sbin/dsfmgr -R hwid 25
6. Under Tru64 UNIX 4.0G or lower the DEC/Compaq/HP Field Service Engineers
would replace failed external SCSI tape drives (DLT) while the system is
running (no reboot, no system change). Under Tru64 UNIX 5.1A, must we now
do the following to retain the same device special file;
-------------
replace the tape drive
reboot
hwmgr -delete component -id XX
hwmgr -refresh component
dn_setup -init
dsfmgr -K
reboot
-------------
That is, if the same SCSI target is used, then is the hardware component
gymnastics and reboots necessary?
7. What value does hardware component management add that justifies the
added aggravation for the system administrator? Is the value the
ability to move a device from one target ID to another target ID and
continue to use the same device special file? If so, do system
administrators perform that task more often than replacing hardware?
-- Regards, /~\ The ASCII Richard Jackson \ / Ribbon Campaign Computer Systems Engineer, X Against HTML Information Technology Unit, Technology Systems Division / \ Email! Enterprise Servers and Operations Department George Mason University, Fairfax, Virginia
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:48:46 EDT