boot path confusion for vpars and npar

[Ravi-Joshi]

Hello All,

I have some doubts about vPars. If anyone has worked on it, appreciate if you can reply.

We have rx8640 server. This has one internal hard disk. There is one npar which npar 0 and this npar comprises

all 4 cells. Within this npar, there are 2 vpars.

The vppar ver is 04.04.04 and hp-ux is 11.23.

We are having issues with boot paths.

On vpar, if I do vparstatus -v -p prd000  it displays the boot paths which are in vpdb.

When I do parstatus -V -p 0 this shows

[Partition]
Partition Number       : 0
Partition Name         : Partition 0
Status                 : Active
IP Address             :
Primary Boot Path      : 0/0/14/1/0/4/1.9.0.15.0.1.4
Alternate Boot Path    : 0/0/14/1/0/4/1.9.0.15.0.1.4
HA Alternate Boot Path :
PDC Revision           : 9.48
IODCH Version          : ffff
Cell Architecture      : Itanium(R)-based
CPU Compatibility      : CDH-640
CPU Speed              : 1598 MHz
Core Cell              : cab0,cell0
Core Cell Choice [0]   : cab0,cell0
Total Good Memory Size : 256.0 GB
Total Interleave Memory: 256.0 GB
Total Requested CLM    : 0.0 GB
Total Allocated CLM    : 0.0 GB
Hyperthreading Enabled : no

......

What do the primary/alt boot path mean ? Are these the boot paths for npar OR are these boot paths for this vpar.

The parstatus -V -p 0 on both vpars shows different boot paths. I believe this comes from stable storage.

The vparstatus -m shows

Console path:  No path as console is virtual
Monitor boot disk path:  0.0.10.1.0.4.0.9.0.16.0.3.2
Monitor boot filename:  /stand/vpmon
Database filename:  /stand/vpdb
Memory ranges used:  0x0/214679552 monitor
                     0xccbc000/303104 firmware
                     0xcd06000/614400 monitor
                     0xcd9c000/925696 firmware
                     0xce7e000/1327104 monitor
                     0xcfc2000/50585600 firmware
                     0x10000000/134213632 monitor
                     0x3ffec000/81920 firmware
                     0x70ffc000000/67108864 firmware
                     0x78ffc000000/67108864 firmware
                     0x80ffc000000/67108864 firmware
                     0x88ffc000000/67108864 firmware

If you look at the Monitor disk boot path, doesn't this and boot paths in parstatus -V -p 0 should be same.

Thank you all

Ravi

[Matti_Kurkela]

"parstatus -V -p 0" definitely reports the currently-configured nPar-level boot paths. If you reboot the entire nPar, this is what the system will use when it starts up - unless you use the nPar EFI boot menu to override them.

The length of the boot paths indicate these are FibreChannel LUNs, which might have multiple paths to the same disk. The nPar firmware is not multipath-aware, so it uses the exact specified path. But I guess the vPar monitor might be multipath-aware, and vparstatus -m might show the first path to the boot LUN it can find.

You should check it: run "ioscan -fnkCdisk", find the hardware path that matches the path in the "vparstatus -m" listing and see which disk device it is. Do the same for the paths listed by "parstatus -V -p 0". Then check if the disk devices you found are all alternate paths of your vg00 PV(s).

Alternatively, the "monitor boot disk path" might be historical information: i.e. "when the vPar monitor was started, it was loaded from this disk". If there has been an on-line SAN migration after the vPar monitor was started, the vparstatus output might display a hardware path to a LUN that no longer exists, as it was mirrored to another LUN in a different storage system and then the original was removed. If that is true, the monitor boot disk path will update automatically the next time you restart the vPar monitor (=reboot the nPar).

The "primary path", "alternate path" and "HA alternate path" in the parstatus output are the three boot paths the system will try in turn. The primary path will be tried first: if it does not exist or is not bootable, the other configured paths will be tried. If your system disk is multipathed, you might want to find any other hardware paths corresponding to the system LUN, and configure them as alternate boot paths for the nPar. This would enable the system to reboot automatically even in a situation where one of the FC links has failed.

[Ravi-Joshi]

Thank you MK.

I checked both vpars. The monitor boot path is same on both vpars. Irrelevant output trucated.

prd001@root:/root> vparstatus -m
Console path:  No path as console is virtual
Monitor boot disk path:  0.0.10.1.0.4.0.9.0.16.0.3.2
Monitor boot filename:  /stand/vpmon

prd003@root:/root> vparstatus -m
Console path:  No path as console is virtual
Monitor boot disk path:  0.0.10.1.0.4.0.9.0.16.0.3.2
Monitor boot filename:  /stand/vpmon

However parstatus -V -p 0 on each vpar shows different boot paths

prd001@root:/root> parstatus -V -p 0|grep -i boot
Primary Boot Path      : 0/0/2/1/0/4/1.9.0.16.0.3.2
Alternate Boot Path    : 0/0/2/1/0/4/1.9.0.16.0.3.2
HA Alternate Boot Path : 0/0/2/1/0/4/1.9.0.16.0.3.2

prd003@root:/root> parstatus -V -p 0|grep -i boot
Primary Boot Path      : 0/0/4/1/0/4/1.9.0.15.0.0.5
Alternate Boot Path    : 1/0/4/1/0/4/1.9.0.11.0.0.5
HA Alternate Boot Path :

parstatus picks up boot paths from vpar and not from stable storage. In our case, prd001 is primary

vpar which was the first vpar carved out of npar 0. So this prd001 sees the npar's

monitor boot disks as the LBA  is assigned to it. The prd002 cannot sees this monitor disk.

setboot is another thing which worries me. On a vpar, it changes the vpdb and not stable storage.

However if I modified boot paths via setboot, it reflects in parstatus  command also.

prd001@root:/root> setboot
Primary bootpath : 0/0/2/1/0/4/1.9.0.16.0.3.2
HA Alternate bootpath : 0/0/2/1/0/4/1.9.0.16.0.3.2
Alternate bootpath : 0/0/2/1/0/4/1.9.0.16.0.3.2

prd003@root:/root> setboot
Primary bootpath : 0/0/4/1/0/4/1.9.0.15.0.0.5
HA Alternate bootpath : <none>
Alternate bootpath : 1/0/4/1/0/4/1.9.0.11.0.0.5

It appears that the monitor boot path (from vparstatus -m) is the correct boot path of the nPar.

The parstatus and setboot on vpars pertain to the vpar where this command is run. It is

confusing because I thought parstatus should be same on all vpars. The parstatus command

on vpar, probably pulls the boot path data from the vpdb. But the same command when run on

npar, it pulls data from the complex profile I think.

[Matti_Kurkela]

I think you're right about parstatus on your systems.

I was working off my memory and some old documentation, since we no longer have many vPar systems around (some things moved to HPVM, others completely obsoleted). Maybe the parstatus was later changed to read the actual nPar stable storage in some version or other... or my memory might be failing me altogether?