vPar reboot landed in "crash" state... help!

[Kevin_31]

Hello, the first time this happened I thought it was a one off, but now it's happened for the second time.

We're running T1335AC A.01.01.00 HP-UX Virtual Partitions on hpux11.11.

We have successfully testing rebooting one vPar and seen it to not affect any others. However, when a pfsmount got confused and we needed to reboot the box, instead of going down and back up happily, it ended up in the state of "crash" according to vparstatus (see attached)

Last time this happened we got a hardware error through to the console and when we tried to issue the vparreset command, it crashed all the vPars! This is bad, not what the vPar product "says on the tin".

In that scenario we had to actually power down the N-class server because otherwise it was failing to see the disks (internal to the N).

Anyone have any experience with vPars landing in "crash" mode or resetting all vPars instead of the one requested? I looked at the vPar manual and can't find it mentioning the mode of "crash" at all.

I know there's a newer version of vPars, but I'd like to know that it addresses my problem specifically, rather than go through all the work to upgrade it in blind hopes that it'll help.

cheers for any help,
Kevin

[harry d brown jr · Accepted solution]

Kevin,

I had this happen in earlier versions and with servers connected to a SAN. Upgrade vpars to A.02.01.00, http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=VPARS




And if you don't already have it, get Marty Poniatowski's "HP-ux Virtual Partitions", a BIBLE on Partitioning:

http://www.hp.com/hpbooks/prentice/ptr_0130352128.html

live free or die
harry