I have a server with 2 boot disk but in the bootlist there are 5 paths of one disk but no path of the other.
How can I remove paths from one disk to insert paths from the other disk?
How are your disks provided and connected? It would be good to know how you have generated 5 paths. It's not necessarily a problem, just a little unusual.
If these are SAN/VIO etc provided, then there may not be a need to mirror and assign the bootlist to both (or all)
VOLUME GROUP: rootvg VG IDENTIFIER: 00f8138d00004c000000013c6dd59129
VG STATE: active PP SIZE: 512 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 198 (101376 megabytes)
MAX LVs: 256 FREE PPs: 42 (21504 megabytes)
LVs: 12 USED PPs: 156 (79872 megabytes)
OPEN LVs: 11 QUORUM: 1 (Disabled)
TOTAL PVs: 2 VG DESCRIPTORS: 3
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 2 AUTO ON: yes
MAX PPs per VG: 32512
MAX PPs per PV: 1016 MAX PVs: 32
LTG size (Dynamic): 256 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable
PV RESTRICTION: none INFINITE RETRY: no
rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk0 active 99 25 13..00..00..00..12
hdisk3 active 99 17 00..00..00..00..17
server074:root:/# lsdev -Cc disk
hdisk0 Available 02-T1-01 HP HSV450 Enterprise Virtual Array
hdisk1 Available 12-T1-01 HP HSV450 Enterprise Virtual Array
hdisk2 Available 12-T1-01 HP HSV450 Enterprise Virtual Array
hdisk3 Available 12-T1-01 HP HSV450 Enterprise Virtual Array
The 5 paths were generated when the rootvg wasn't mirrorred.
We have just mirrored the rootvg, and added the bosboot.
[*] bootlist -m normal hdisk0 pathid=0,2
[*] bootlist -m normal hdisk0 pathid=0 hdisk0 pathid=2
It is IBM's (?) OpenFirmware limitation, that you can have up to 5 devices in the boot list. Every path is seen as a separate device in OF. Check your paths with lspath command, but in a general case you don't need to many paths to each device. 2 or 4 paths are enough most of times. Remove unnecessary paths with rmpath command.
I notice that you have the following in the output of lsvg -l rootvg
lg_dumplv1 sysdump 8 8 1 open/syncd N/A
Is this intentional? I have seen both a mirror on the dump device and a secondary dump device allocated on the 'other' disk in rootvg. I'm not sure which one is more sensible, but if hdisk0 failed, you would ungracefully lose your dump device and might have trouble recreating it.
Actually, I'm not sure why. This is the dump configuration:
server074:root:/# sysdumpdev -l
primary /dev/lg_dumplv1
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag FALSE
always allow dump TRUE
dump compression ON
type of dump traditional
I found this article and it suggests you have it set up in the preferred configuration now. Mirroring is slightly discouraged for the system dump device in case a crash is caused by mirroring software.