| The motivation for reorganizing your IO tree is normally to standardize the configuration of a collection of servers. Managing a multitude of machines that are fundamentally the same type of machine and with the same number and type of interface cards is hard enough. When we throw into the mix a different IO tree, we are introducing multiple sets of device files which all need interpreting. Take a situation where we have 16 servers all sharing a set of LUNs configured on a disk array. If each server has a different IO tree, we will have 16 sets of different device files all relating to the same devices. Standardizing device files can make managing a large collection of machines much easier. Some administrators I know will simply create a device file with mknod that reflects a device file on another node. There is nothing wrong with this except it is another task we need to remember whenever we add another interface card or device onto our systems. A better approach would be to standardize the underlying Instance numbers for interfaces. In this way when we add another device, HP-UX will automatically create the correct device files on all nodes. As well as standardizing the IO tree, we will probably want to standardize the process of modifying a given hardware configuration in the future. It is usually the process of adding and removing hardware components that causes disruption in an orderly grouping of Instance numbers. The case for standardizing your IO tree is when we fundamentally have the same hardware configuration on each server. This is not absolutely essential, but it does make life slightly easier when we have the same amount of Instance numbers to manage. With dissimilar numbers of devices, we will be standardizing the common devices between the machines. Unique devices on a given server will follow their own convention for Instance numbers; as you can see, having similar hardware configurations is desirable. The process itself is not difficult. The consequences of the change can be quite dramatic. When we reassign Instance numbers, we are creating a whole new list of device files. We need to document VERY CAREFULLY the current device files and which hardware paths they map to. We also need to map which device files are currently in use, e.g., which disk device files are currently members of volume groups. After the new configuration has taken place, we will need to rework any applications, e.g., LVM, networking, and so on, to reference the new device files. Ideally we would perform the remapping of Instance number/device files before performing any system configuration, but life isn't always that easy. Here's a cookbook of the steps involved to reorganize your IO tree and hence remap your Instance numbers: -
Consider making a System Recovery Tape.
-
Collect IO trees from all nodes concerned .
-
Decide on the format of the standardized IO tree.
-
Document the current device file ”hardware path mapping.
-
Establish which system and user applications use current device files.
-
Create an ASCII file representing the new IO tree.
-
Shut down the system(s) to single user mode.
-
Apply the new IO tree configuration with the ioinit command.
-
Reboot the system to single user mode.
-
Check that all new device files are created correctly.
-
Rework any user or system applications affected by the change in device file names .
-
Remove all old device files.
I have (only) two systems that have mismatched IO trees. They both have identical hardware configurations; it's just that one of them has had numerous interface cards inserted and removed over the years . Consequently, the sequence of Instance numbers is dissimilar. Both nodes are connected to the same disk array, so I am going to attempt to ensure they have the same IO tree by the end of this process and hence the same device files mapping to the same devices. 4.1.1 Consider making a System Recovery Tape As with any major operating system configuration change, it is worthwhile to have a consistent backup of your operating system just in case. It is worth considering using commands like make_[tapenet]_recovery in order to be able to re-establish the current system configuration as quickly as possible, should something unexpected and catastrophic happen. 4.1.2 Collect IO trees from all nodes concerned This can simply be a simple ioscan “f command. What we are trying to establish is which system(s) have dissimilar IO trees. On my systems, the problem lies with my interface cards and the disk attached to them. This part of the investigation can take some time on large systems, as you have to wade through the output from multiple ioscan commands. On node hpeos004 , the sequence of Instance numbers is simple and straightforward:
root@hpeos004[] ioscan -fknC ext_bus Class I H/W Path Driver S/W State H/W Type Description ================================================================= ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD ext_bus 1 0/0/1/1 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide Single-Ended ext_bus 2 0/0/2/0 c720 CLAIMED INTERFACE SCSI C87x Fast Wide Single-Ended ext_bus 3 0/0/2/1 c720 CLAIMED INTERFACE SCSI C87x Ultra Wide Single-Ended ext_bus 4 0/6/0/0 c720 CLAIMED INTERFACE SCSI C896 Ultra2 Wide LVD ext_bus 5 0/6/0/1 c720 CLAIMED INTERFACE SCSI C896 Ultra2 Wide LVD root@hpeos004[]
I am using the “k option to ioscan throughout, as I am not expecting to see any new devices appear during this process, and it is much quicker than actually probing every hardware path; especially if you have fibre channel attached disk arrays. On our other node, hpeos003 , the IO tree is somewhat in a mess:
root@hpeos003[] ioscan -fknC ext_bus Class I H/W Path Driver S/W State H/W Type Description ================================================================= ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD ext_bus 1 0/0/1/1 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide Single-Ended ext_bus 6 0/0/2/0 c720 CLAIMED INTERFACE SCSI C87x Fast Wide Single-Ended ext_bus 7 0/0/2/1 c720 CLAIMED INTERFACE SCSI C87x Ultra Wide Single-Ended ext_bus 5 0/6/0/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD ext_bus 4 0/6/0/1 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD root@hpeos003[]
We should also check how the devices connected to each of these interfaces have been configured. We know through our knowledge of these systems that they are connected to a shared disk array. There is nothing to say that one system was able to access more devices on that array due to some form of LUN security. If we are attempting to standardize the Instance numbers in the IO tree, we should at least perform the task for every affected device, not only the interface cards.
root@hpeos004[] ioscan -fkH 0/6/0/0 Class I H/W Path Driver S/W State H/W Type Description ====================================================================== ext_bus 4 0/6/0/0 c720 CLAIMED INTERFACE SCSI C896 Ultra2 Wide LVD target 6 0/6/0/0.7 tgt CLAIMED DEVICE ctl 4 0/6/0/0.7.0 sctl CLAIMED DEVICE Initiator target 15 0/6/0/0.8 tgt CLAIMED DEVICE disk 2 0/6/0/0.8.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 16 0/6/0/0.9 tgt CLAIMED DEVICE disk 3 0/6/0/0.9.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 17 0/6/0/0.10 tgt CLAIMED DEVICE disk 4 0/6/0/0.10.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 18 0/6/0/0.11 tgt CLAIMED DEVICE disk 5 0/6/0/0.11.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 19 0/6/0/0.12 tgt CLAIMED DEVICE disk 6 0/6/0/0.12.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 20 0/6/0/0.13 tgt CLAIMED DEVICE disk 7 0/6/0/0.13.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 21 0/6/0/0.14 tgt CLAIMED DEVICE disk 8 0/6/0/0.14.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 22 0/6/0/0.15 tgt CLAIMED DEVICE ctl 6 0/6/0/0.15.0 sctl CLAIMED DEVICE HP A6491A root@hpeos004[]
In the case of disk drives , the Instance number of the disk itself is not used in the device file name , but I think we should standardize this part of the IO tree as well. Here are the Instance numbers for the attached disk on node hpeos003 :
root@hpeos003[] ioscan -fkH 0/6/0/0 Class I H/W Path Driver S/W State H/W Type Description ====================================================================== ext_bus 5 0/6/0/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD target 14 0/6/0/0.6 tgt CLAIMED DEVICE ctl 5 0/6/0/0.6.0 sctl CLAIMED DEVICE Initiator target 15 0/6/0/0.8 tgt CLAIMED DEVICE disk 2 0/6/0/0.8.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 16 0/6/0/0.9 tgt CLAIMED DEVICE disk 3 0/6/0/0.9.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 17 0/6/0/0.10 tgt CLAIMED DEVICE disk 24 0/6/0/0.10.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 18 0/6/0/0.11 tgt CLAIMED DEVICE disk 25 0/6/0/0.11.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 19 0/6/0/0.12 tgt CLAIMED DEVICE disk 26 0/6/0/0.12.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 20 0/6/0/0.13 tgt CLAIMED DEVICE disk 27 0/6/0/0.13.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 21 0/6/0/0.14 tgt CLAIMED DEVICE disk 28 0/6/0/0.14.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC target 22 0/6/0/0.15 tgt CLAIMED DEVICE ctl 6 0/6/0/0.15.0 sctl CLAIMED DEVICE HP A6491A root@hpeos003[]
As you can see, they are somewhat different to the Instance numbers on node hpeos004 . This disparity is simply due to the fact that this machine was used for testing new interface cards and devices. When we added a new card, we simply installed it and never worried about the consequences of device file names. 4.1.3 Decide on the format of the standardized IO tree In our case, the answer is relatively simple: We are going to use the sequence of Instance numbers we find on node hpeos004 . Where you have significant differences between different nodes, the process of establishing a consistent numbering sequence can be somewhat time consuming. When remapping Instance numbers, we cannot use an Instance number that is currently being used by an existing device. This can significantly increase the number of affected devices. 4.1.4 Document current device file  hardware path mapping When we apply our new configuration, we will have a plethora of new device files created. It is a good idea to print out a complete listing from ioscan “fn to ensure that you know exactly what you had before you started. Another good idea is to keep a backup copy of the files /etc/ ioconfig and /stand/ioconfig , which hold your current IO tree with hardware to Instance number mappings. Both files should be the same. The file /stand/ioconfig is accessible at boot time even for NFS-diskless clients . The kernel IO tree is initialized from this file. Once booted , the kernel IO tree is updated from /etc/ioconfig . If this file is missing at boot time, the sysinit (from /etc/inittab ) process /sbin/ioinitrc will bring the system to single user mode whereby we can restore /etc/ioconfig from a backup tape or recreate it by using /sbin/ioinit “c . 4.1.5 Establish which system and user applications use current device files This part of the process can be very time consuming and the scariest . In my case, we will be recreating device files for LVM disks. This means I need to establish which disks are affected because when the system tries to activate a particular volume group , it will need to know about the new device files. In the case of LVM, I am going to have to vgexport and then vgimport all affected volume groups once the new device files have been created. Ensure that you consider every possible system and user application that might refer to a device file. I suppose if you forget one, you will know soon enough as that particular application stops working, but it doesn't do your r sum any good if you make changes to a system which cause catastrophic consequences for user applications. Here I can see that a particular disk device files does relate to the same device as I can read the LVM header of the disk.
root@hpeos004[] echo "0x2008?4D" adb /dev/dsk/c4t8d0 2008: 2007116332 1016986841 2007116332 1016986870 root@hpeos004[]
If this is a disk used by both systems, when I read the LVM header off the disk from the other node, I should see the same information even though it uses a different device file.
root@hpeos003[] echo "0x2008?4D" adb /dev/dsk/c5t8d0 2008: 2007116332 1016986841 2007116332 1016986870 root@hpeos003[]
Remember that we could quite happily exist like this with different device files pointing to the same hardware; it's just that it might make our ever-busier lives easier if they were the same. 4.1.6 Create an ASCII file representing the new IO tree This is where we need to work out which devices are affected and construct a file that reflects the new configuration. First, we construct a file in the correct format for the job. The format of this file needs to be:
<hardware path> <class> <instance number>
This is relatively simply to do with an ioscan command and some fancy footwork with awk :
root@hpeos003[] ioscan -kf tail +3 awk '{print "\t""\t"}' > /tmp/iotree root@hpeos003[]
We can now edit this file so that it contains only the devices with Instance numbers we want to change. Here's the file I constructed for node hpeos003 :
root@hpeos003[] cat /tmp/iotree 0/0/2/0 ext_bus 2 0/0/2/1 ext_bus 3 0/6/0/0 ext_bus 4 0/6/0/0.10.0 disk 4 0/6/0/0.11.0 disk 5 0/6/0/0.12.0 disk 6 0/6/0/0.13.0 disk 7 0/6/0/0.14.0 disk 8 0/6/0/1 ext_bus 5 root@hpeos003[]
The order of individual lines is not important; just ensure that you include all affected devices. We will need to perform the same task on all affected nodes. 4.1.7 Shut down the system(s) to single user mode It's a good idea to shut the system down to single user mode to ensure that all user and non-essential system applications are not running. Technically this is not necessary, but the command that actually applies the new configuration may have to reboot the system for the changes to take effect. In doing so, it will issue a reboot command, so being in single user mode is probably a wise move. 4.1.8 Apply the new IO tree configuration with the ioinit command Now the moment of truth: The ioinit command will attempt to remap our Instance numbers listed in the file /etc/ioconfig based on the content of our file /tmp/iotree . For these changes to take effect, we may have to perform a reboot. In reality, we will probably have to perform a reboot in every case, as the kernel IO tree has not been directly affected by these changes yet. This is why we are using the “r option to ioinit command that will perform the reboot if the changes we make warrant a reboot. We can see the changes made by ioinit if we can decipher the binary nonsense that is the /etc/ioconfig file. I have included a program called dump_ioconfig in Appendix B that reads the ioconfig file. I will use it in this demonstration: Let's run the ioinit command with the /tmp/iotree file we created earlier:
root@hpeos003[] ioscan -fnkC ext_bus Class I H/W Path Driver S/W State H/W Type Description ================================================================= ext_bus 0 0/0/1/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD ext_bus 1 0/0/1/1 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide Single-Ended ext_bus 6 0/0/2/0 c720 CLAIMED INTERFACE SCSI C87x Fast Wide Single-Ended ext_bus 7 0/0/2/1 c720 CLAIMED INTERFACE SCSI C87x Ultra Wide Single-Ended ext_bus 5 0/6/0/0 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD ext_bus 4 0/6/0/1 c720 CLAIMED INTERFACE SCSI C896 Ultra Wide LVD root@hpeos003[] ioinit -f /tmp/iotree root@hpeos003[] ~/dump_ioconfig grep ext_bus ext_bus 0 0 0 1 0 c720 ext_bus 1 0 0 1 1 c720 ext_bus 2 0 0 2 0 c720 ext_bus 3 0 0 2 1 c720 ext_bus 4 0 6 0 0 c720 ext_bus 5 0 6 0 1 c720 root@hpeos003[]
As we can see from the output of dump_ioconfig , the Instance numbers in the /etc/ioconfig file has changed; the Instance number is the second field from the left. Now if we run ioinit again, first it will realize that the changes in the file /tmp/iotree have already been made, but this time with the “r option ioinit , it will realize that the kernel is not consistent with the /etc/ioconfig file and call a reboot:
root@hpeos003[] ioinit -r -f /tmp/iotree ioinit: Input is identical to kernel, line ignored Input line 1: 0/0/2/0 ext_bus 2 ioinit: Input is identical to kernel, line ignored Input line 2: 0/0/2/1 ext_bus 3 ioinit: Input is identical to kernel, line ignored Input line 3: 0/6/0/0 ext_bus 4 ioinit: Input is identical to kernel, line ignored Input line 4: 0/6/0/0.10.0 disk 4 ioinit: Input is identical to kernel, line ignored Input line 5: 0/6/0/0.11.0 disk 5 ioinit: Input is identical to kernel, line ignored Input line 6: 0/6/0/0.12.0 disk 6 ioinit: Input is identical to kernel, line ignored Input line 7: 0/6/0/0.13.0 disk 7 ioinit: Input is identical to kernel, line ignored Input line 8: 0/6/0/0.14.0 disk 8 ioinit: Input is identical to kernel, line ignored Input line 9: 0/6/0/1 ext_bus 5 ioinit:Rebooting the system to reassign instance numbers Shutdown at 14:46 (in 0 minutes) *** FINAL System shutdown message from root@hpeos003 *** System going down IMMEDIATELY System shutdown time has arrived reboot: redirecting error messages to /dev/console
4.1.9 Reboot the system to single user mode The reason I am suggesting rebooting to single user mode is simply to check that all necessary device files have been created. In our case, I would suspect that insf would not create our new device files, as the hardware paths for these devices already exist, i.e., they are not new devices. It also gives us the opportunity to rework any user and system applications before they start up and consequently fail due to the change in device file names. 4.1.10 Check that all new device files are created correctly As part of the /sbin/ioinitrc startup script, ioinit “i “r is run, which invokes insf to create any new device files. These devices exist as far as a hardware path is concerned, so they are not regarded as new devices. We have to supply the “e option to insf to create device files for devices that existed previously, i.e., that already have an Instance number.
root@hpeos003[] ioscan -fnkC disk Class I H/W Path Driver S/W State H/W Type Description ====================================================================== disk 9 0/0/1/0.0.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t0d0 /dev/rdsk/c0t0d0 disk 10 0/0/1/0.1.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t1d0 /dev/rdsk/c0t1d0 disk 11 0/0/1/0.2.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t2d0 /dev/rdsk/c0t2d0 disk 12 0/0/1/0.3.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t3d0 /dev/rdsk/c0t3d0 disk 13 0/0/1/0.4.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t4d0 /dev/rdsk/c0t4d0 disk 14 0/0/1/0.5.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t5d0 /dev/rdsk/c0t5d0 disk 15 0/0/1/0.6.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t6d0 /dev/rdsk/c0t6d0 disk 0 0/0/1/1.15.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC /dev/dsk/c1t15d0 /dev/rdsk/c1t15d0 disk 1 0/0/2/1.15.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC disk 2 0/6/0/0.8.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 3 0/6/0/0.9.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 4 0/6/0/0.10.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 5 0/6/0/0.11.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 6 0/6/0/0.12.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 7 0/6/0/0.13.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC disk 8 0/6/0/0.14.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC root@hpeos003[]
You can see that we are missing our device files. We will create them manually with insf “ve :
root@hpeos003[] insf -ve insf: Installing special files for btlan instance 0 address 0/0/0/0 insf: Installing special files for sdisk instance 9 address 0/0/1/0.0.0 insf: Installing special files for sdisk instance 10 address 0/0/1/0.1.0 insf: Installing special files for sdisk instance 11 address 0/0/1/0.2.0 insf: Installing special files for sdisk instance 12 address 0/0/1/0.3.0 insf: Installing special files for sdisk instance 13 address 0/0/1/0.4.0 insf: Installing special files for sdisk instance 14 address 0/0/1/0.5.0 insf: Installing special files for sdisk instance 15 address 0/0/1/0.6.0 insf: Installing special files for sctl instance 0 address 0/0/1/0.7.0 insf: Installing special files for sctl instance 7 address 0/0/1/0.15.0 insf: Installing special files for sctl instance 1 address 0/0/1/1.7.0 insf: Installing special files for sdisk instance 0 address 0/0/1/1.15.0 insf: Installing special files for sctl instance 4 address 0/0/2/0.7.0 making rscsi/c2t7d0 c 203 0x027000 insf: Installing special files for sctl instance 5 address 0/0/2/1.7.0 making rscsi/c3t7d0 c 203 0x037000 insf: Installing special files for sdisk instance 8 address 0/0/2/1.15.0 making dsk/c3t15d0 b 31 0x03f000 making rdsk/c3t15d0 c 188 0x03f000 insf: Installing special files for asio0 instance 0 address 0/0/4/1 insf: Installing special files for btlan instance 1 address 0/2/0/0/4/0 insf: Installing special files for btlan instance 2 address 0/2/0/0/5/0 insf: Installing special files for btlan instance 3 address 0/2/0/0/6/0 insf: Installing special files for btlan instance 4 address 0/2/0/0/7/0 insf: Installing special files for sctl instance 2 address 0/6/0/0.6.0 making rscsi/c4t6d0 c 203 0x046000 insf: Installing special files for sdisk instance 1 address 0/6/0/0.8.0 making dsk/c4t8d0 b 31 0x048000 making rdsk/c4t8d0 c 188 0x048000 insf: Installing special files for sdisk instance 2 address 0/6/0/0.9.0 making dsk/c4t9d0 b 31 0x049000 making rdsk/c4t9d0 c 188 0x049000 insf: Installing special files for sdisk instance 3 address 0/6/0/0.10.0 making dsk/c4t10d0 b 31 0x04a000 making rdsk/c4t10d0 c 188 0x04a000 insf: Installing special files for sdisk instance 4 address 0/6/0/0.11.0 making dsk/c4t11d0 b 31 0x04b000 making rdsk/c4t11d0 c 188 0x04b000 insf: Installing special files for sdisk instance 5 address 0/6/0/0.12.0 making dsk/c4t12d0 b 31 0x04c000 making rdsk/c4t12d0 c 188 0x04c000 insf: Installing special files for sdisk instance 6 address 0/6/0/0.13.0 making dsk/c4t13d0 b 31 0x04d000 making rdsk/c4t13d0 c 188 0x04d000 insf: Installing special files for sdisk instance 7 address 0/6/0/0.14.0 making dsk/c4t14d0 b 31 0x04e000 making rdsk/c4t14d0 c 188 0x04e000 insf: Installing special files for sctl instance 6 address 0/6/0/0.15.0 making rscsi/c4t15d0 c 203 0x04f000 insf: Installing special files for sctl instance 3 address 0/6/0/1.6.0 making rscsi/c5t6d0 c 203 0x056000 insf: Installing special files for pseudo driver cn insf: Installing special files for pseudo driver mm insf: Installing special files for pseudo driver devkrs insf: Installing special files for pseudo driver ptym insf: Installing special files for pseudo driver ptys insf: Installing special files for pseudo driver ip insf: Installing special files for pseudo driver arp insf: Installing special files for pseudo driver rawip insf: Installing special files for pseudo driver tcp insf: Installing special files for pseudo driver udp insf: Installing special files for pseudo driver stcpmap insf: Installing special files for pseudo driver nuls insf: Installing special files for pseudo driver netqa insf: Installing special files for pseudo driver dmem insf: Installing special files for pseudo driver diag0 insf: Installing special files for pseudo driver telm insf: Installing special files for pseudo driver tels insf: Installing special files for pseudo driver tlclts insf: Installing special files for pseudo driver tlcots insf: Installing special files for pseudo driver iomem insf: Installing special files for pseudo driver tlcotsod insf: Installing special files for pseudo driver dev_config insf: Installing special files for pseudo driver strlog insf: Installing special files for pseudo driver sad insf: Installing special files for pseudo driver echo insf: Installing special files for pseudo driver dlpi insf: Installing special files for pseudo driver ptm insf: Installing special files for pseudo driver pts insf: Installing special files for pseudo driver diag1 insf: Installing special files for pseudo driver klog insf: Installing special files for pseudo driver sy insf: Installing special files for pseudo driver kepd insf: Installing special files for pseudo driver diag2 insf: Installing special files for pseudo driver root making rroot c 255 0xffffff making root b 255 0xffffff root@hpeos003[]
We now have our device files. We can check this with another ioscan :
root@hpeos003[]root@hpeos003[] ioscan -fnkC disk Class I H/W Path Driver S/W State H/W Type Description ====================================================================== disk 9 0/0/1/0.0.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t0d0 /dev/rdsk/c0t0d0 disk 10 0/0/1/0.1.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t1d0 /dev/rdsk/c0t1d0 disk 11 0/0/1/0.2.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t2d0 /dev/rdsk/c0t2d0 disk 12 0/0/1/0.3.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t3d0 /dev/rdsk/c0t3d0 disk 13 0/0/1/0.4.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t4d0 /dev/rdsk/c0t4d0 disk 14 0/0/1/0.5.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t5d0 /dev/rdsk/c0t5d0 disk 15 0/0/1/0.6.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c0t6d0 /dev/rdsk/c0t6d0 disk 0 0/0/1/1.15.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC /dev/dsk/c1t15d0 /dev/rdsk/c1t15d0 disk 1 0/0/2/1.15.0 sdisk CLAIMED DEVICE HP 36.4GST336753LC /dev/dsk/c3t15d0 /dev/rdsk/c3t15d0 disk 2 0/6/0/0.8.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t8d0 /dev/rdsk/c4t8d0 disk 3 0/6/0/0.9.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t9d0 /dev/rdsk/c4t9d0 disk 4 0/6/0/0.10.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t10d0 /dev/rdsk/c4t10d0 disk 5 0/6/0/0.11.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t11d0 /dev/rdsk/c4t11d0 disk 6 0/6/0/0.12.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t12d0 /dev/rdsk/c4t12d0 disk 7 0/6/0/0.13.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t13d0 /dev/rdsk/c4t13d0 disk 8 0/6/0/0.14.0 sdisk CLAIMED DEVICE HP 73.4GST373307LC /dev/dsk/c4t14d0 /dev/rdsk/c4t14d0 root@hpeos003[]
4.1.11 Rework any user or system applications affected by the change in device file names This is where our previous documentation is important. Our user and system applications will need reworking to reference the newly created device files. We need to be able to reference the new device file name back to the old one in order to update our user and system applications. It is crucial that we get this right because a mistake here can render entire applications unusable. In my case, I need to vgexport and vgimport my existing volume groups as the /etc/lvmtab file currently references the old device file names. root@hpeos003[] strings /etc/lvmtab /dev/vg00 /dev/dsk/c1t15d0 /dev/vgora /dev/dsk/c5t8d0 root@hpeos003[] root@hpeos003[] vgchange -a y /dev/vgora vgchange: Warning: Couldn't attach to the volume group physical volume "/dev/dsk/c5t8d0": The path of the physical volume refers to a device that does not exist, or is not configured into the kernel. vgchange: Warning: couldn't query physical volume "/dev/dsk/c5t8d0": The specified path does not correspond to physical volume attached to this volume group vgchange: Warning: couldn't query all of the physical volumes. vgchange: Couldn't activate volume group "/dev/vgora": Quorum not present, or some physical volume(s) are missing. root@hpeos003[] In my case, there isn't much work to do. First, I could check the LVM headers on what I think is the new disk. If I had recorded this information as part of my documentation stage, this would assist in identifying the new device files.
root@hpeos003[] echo "0x2008?4D" adb /dev/dsk/c4t8d0 2008: 2007116332 1016986841 2007116332 1016986870 root@hpeos003[]
If we compare this with the LVM header we can read from our other node, we will discover whether we have correctly identified the new device file name.
root@hpeos004[] echo "0x2008?4D" adb /dev/dsk/c4t8d0 2008: 2007116332 1016986841 2007116332 1016986870 root@hpeos004[]
All I need to do now is perform the vgexport and vgimport :
root@hpeos003[] ll /dev/vgora total 0 crw-rw-rw- 1 root sys 64 0x010000 May 2 09:37 group brw-r----- 1 root sys 64 0x010001 May 2 09:37 ora1 brw-r----- 1 root sys 64 0x010002 May 2 09:37 ora2 crw-r----- 1 root sys 64 0x010001 May 2 09:37 rora1 crw-r----- 1 root sys 64 0x010002 May 2 09:37 rora2 root@hpeos003[] vgexport m /tmp/vgora.map /dev/vgora root@hpeos003[] root@hpeos003[] mkdir /dev/vgora root@hpeos003[] mknod /dev/vgora/group c 64 0x010000 root@hpeos003[] vgimport -m /tmp/vgora.map /dev/vgora /dev/dsk/c4t8d0 Warning: A backup of this volume group may not exist on this machine. Please remember to take a backup using the vgcfgbackup command after activating the volume  group. root@hpeos003[] ll /dev/vgora total 0 crw-rw-rw- 1 root sys 64 0x010000 Sep 20 16:22 group brw-r----- 1 root sys 64 0x010001 Sep 20 16:23 ora1 brw-r----- 1 root sys 64 0x010002 Sep 20 16:23 ora2 crw-r----- 1 root sys 64 0x010001 Sep 20 16:23 rora1 crw-r----- 1 root sys 64 0x010002 Sep 20 16:23 rora2 root@hpeos003[] root@hpeos003[] vgchange -a y /dev/vgora Activated volume group Volume group "/dev/vgora" has been successfully changed. root@hpeos003[] vgcfgbackup /dev/vgora Volume Group configuration for /dev/vgora has been saved in /etc/lvmconf/vgora.conf root@hpeos003[] vgdisplay /dev/vgora --- Volume groups --- VG Name /dev/vgora VG Write Access read/write VG Status available Max LV 255 Cur LV 2 Open LV 2 Max PV 16 Cur PV 1 Act PV 1 Max PE per PV 1016 VGDA 2 PE Size (Mbytes) 4 Total PE 250 Alloc PE 200 Free PE 50 Total PVG 0 Total Spare PVs 0 Total Spare PVs in use 0 root@hpeos003[]
This process can take quite some considerable time when a number of devices are involved. 4.1.12 Remove all old device files Technically, you don't need to remove the old device files, but I consider the job complete when we have completely rid ourselves of all vestiges of the old IO tree. There is also the issue of you or a new colleague finding the old device files and wondering why they are there. Here we can see some of the old device files; notice the address they refer to is now " ? ".
root@hpeos003[] lssf /dev/dsk/c5t* sdisk card instance 5 SCSI target 10 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t10d0 sdisk card instance 5 SCSI target 11 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t11d0 sdisk card instance 5 SCSI target 12 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t12d0 sdisk card instance 5 SCSI target 13 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t13d0 sdisk card instance 5 SCSI target 14 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t14d0 sdisk card instance 5 SCSI target 8 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t8d0 sdisk card instance 5 SCSI target 9 SCSI LUN 0 section 0 at address ? /dev/dsk/c5t9d0 root@hpeos003[]
Because there is no device associated with these device files, we could simply remove them with the rm command. I will use rmsf , which can give me a message if I delete a device file with no device associated with it. This is a sanity check to ensure that I don't accidentally delete real device files:
root@hpeos003[] rmsf -a /dev/dsk/c5* Warning: No device associated with "/dev/dsk/c5t10d0" Warning: No device associated with "/dev/dsk/c5t11d0" Warning: No device associated with "/dev/dsk/c5t12d0" Warning: No device associated with "/dev/dsk/c5t13d0" Warning: No device associated with "/dev/dsk/c5t14d0" Warning: No device associated with "/dev/dsk/c5t8d0" Warning: No device associated with "/dev/dsk/c5t9d0" root@hpeos003[]
I would continue with this process until I have cleaned up all the old device files. | 