Answers to Chapter Review Questions

     

A1:	By default, HP-UX will follow the same naming convention from server to server. If all the servers have the exact same hardware configuration at the time of installation and all shared devices are visible to all servers, the IO tree will be the same for each server. One example of how the naming convention could be different is if the hardware convention and/or some shared devices were not visible at the time of installation, in which case the Instance numbers for some non-visible devices would be different because HP-UX assigns Instance numbers in the order in which the devices become visible to HP-UX. For example, some disk configured on a disk array may not be visible due to SAN /disk array security. Instance numbers intended for these devices will be assigned to other devices, causing the disruption alluded to in the question. Other factors include: Interface cards not being in the same hardware slots from server to server. Interface cards being removed without the old device files and Instance numbers being removed as well. These Instance numbers will not be available for reuse. Devices added after the initial installation, causing Instance numbers to be assigned in a different sequence to machines with different initial hardware configurations.
A2:	The problem is that the /etc/lvmtab file has the old disk device file names recorded in it. The steps we need to undertake to rectify this situation are: Deactivate any affected Volume Group (although they shouldn't be active due to the underlying problem). Export the affected volume groups. Make a directory to hold the Volume Group device files. Make a device file called /dev/<vg name >/group with the appropriate major/minor numbers. Import the volume group using the new disk device file names. Activate the volume group. Mount all of the affected filesystems. No changes are necessary to the /etc/fstab file if all of the filesystems are under the control of LVM and we haven't changed the name of the volume group. This problem would not have manifested itself if we had utilized VxVM, because the device file name is irrelevant to VxVM; it is the logical Disk Media name that is important to VxVM.
A3:	The problem could have been caused by the firmware upgrade changing the behavior of the Core Switch PID Format from OFF to ON (or vice versa). This would change the hardware path seen by HP-UX and hence change the device files associated with the attached devices. Two solutions include: Have the SAN administrator change the Core Switch PID Format setting on all of the switches in the SAN back to the old setting. The existing device files will then be encoded with the appropriate information to refer to the original hardware paths. Create the new device files for the new hardware paths. Then: If the disks are under the control of LVM, we will export and then import the affected Volume Groups. If the disks are under the control of VxVM, we can simply run vxdctl enable and then start the affected volumes .
A4:	One of the main points to note is that the hardware path includes the Domain and Port Number of the switch closest to the disk drives , i.e., the switch that constitutes the exit-point from the SAN : all other switch- related information is superfluous. Red line : Hardware path = 0/2/0/0.3.3.0.4.6.0 HBA = 0/2/0/0 Port ID = 3.3.0 (3=Domain: switch closest to the disk array, 3=Port Number, 0=Loop ID hence 0 in a Switched Fabric SAN) SCSI Address = 4.6.0 (4=VSB: each VSB can accommodate 128 LUNS hence 560/128=4 remainder 48, 6=Target ID: 48/8, 0= SCSI LUN: remainder of last division calculation: 48/8=6 remainder 0). Device File = /dev/*dsk/c14t6d0 (c14 as VSB=0 is Instance 9 hence VSB=1 - I=11 (other interface card has instance 10), VSB=2 - I=12, VSB=3 - I=13, VSB=4 - I =14) t=6 (Target Address), d=0 (SCSI LUN). Blue line : Hardware path = 0/4/0/0.4.8.0.4.6.0 HBA = 0/2/0/0 Port ID = 4.8.0 (4=Domain: switch closest to the disk array, 8=Port Number on the switch, 0=Loop ID hence 0 in a Switched Fabric SAN) SCSI Address = 4.6.0 (4=VSB: each VSB can accommodate 128 LUNS hence 560/128=4 remainder 48, 6=Target ID: 48/8, 0= SCSI LUN: remainder of last division calculation: 48/8=6 remainder 0). Device File = /dev/*dsk/c18t6d0 (c18 as VSB=0 is Instance 11 - 14 have been used already by other VSB on other interface cards, hence VSB=1 - I=15, VSB=2 - I=16, VSB=3 - I=17, VSB=4 - I =18) t=6 (Target Address), d=0 (SCSI LUN).
A5:	Part of the process of replacing an interface card using OLA /R commands is to locate any associated scripts/programs supplied by the driver developer under the directory /usr/sbin/olrad.d , e.g., driver c270 has an associated script /usr/sbin/olrad.d/c720 . This script/program must be run before the driver is suspended and before the driver is resumed. The scripts are run with an associated command line argument, i.e., prep_replace and post_replace respectively. This script/program allows the driver to perform any necessary functions before deactivating /activating the driver.