Boot Disk from SuperDome xferred to RP8400 Works but...

[Alzhy]

Over the weekend, we attempted to transfer an OS disk from a SuperDome nPar to a RP8400 nPar).. Procedure used was:

1.\ Boot off the disk in LVM Maintenance mode "hpux -lm"
2.\ remove /etc/ioconfig
3.\ reboot again, run ioinit...
4.\ insf/ioscan verify all disks are visible
5.\ Fix VG's -- vg00 to adapt to new HW
6.\ Verify lvlnboot is fine, fix boot path "setboot", etc...
7.\ reboot, complains that /stand/ioconfig and /etc/ioconfig are not in agreement.. reboots again and boots up fine.

8.\ Fix networking... okay..

BTW, the old nPar (SuperDome) and the new nPar (rp8400) have identical SCSI HBA (for the boot disks) and all other cards (NIC/FC-HBA's).. the rp8400 nPar takes on the same hostname and IP of old nPar on SD...

Everyting works fine, I was able to reimport all the other VG's off of the SAN, restarted applications, etc... with one quirk:

I cannot see the internal SCSI disks, DDS4 drive and DVD off of the coreIO on the rp8400 nPar that I brought up the disk.. no amount of insf -e's or ioscan's would make them "appear".. I have not done any explicit insf with HW path though.. So what's wrong? Is there a driver needed for the rp8400's coreIO SCSI subsystem?

However, if I do an Ignite Recovery of the server (I created a ignite recovery while the OS disk was still on the SD) on the rp8400.. everything works fine, and I can see the DVD drive, internal SCSI disks and DDS tape drive off of the coreIO..

The local HP site engineer says transporting a boot disk from a SuperDome to an rp8400 is not supported even one is able to make it work.. He did not comment if an Ignite recovery is acecptable. Is this a true statement?

[melvyn burnard]

What you have done is move something from one system that has NO internal devices, to a system that does have them, and therefore needs specific drivers and other information.
The steps you have taken, although it may appear to work, are certainly not supported.

[Jakes Louw]

Appropriate drivers enable in the kernel?

[Alzhy]

Okay.. but why is it that an Ignite Recovery of the backup of the nPar while it was on a SD (that has "NO Internal" devices) works and was able to build the devices off of the coreIO's on the rp8400?

Are you saying that such method is as well unsupported?

I have compared the Ignite approach and the transported disk approach (where the coreIO devices where manually rebuilt via insf - yes it worked!) and THERE IS NO DIFFERENCE.. Besides, I forgot to mention that I was able to get to (plumb and use) the coreIO's 1000bt NIC on the transported disk -- so what driver(s) are we talking about here.. AFAIK, there is no specific driver for the coreIO devices...??

[Alzhy]

Jakes, That's what I've been trying to find out if ther indeed is a "driver" for the rp8400 coreIO devices.. but the thing is, on 1st boot off of the transported OS disk, the kernel did recognize my coreIO GigEther port and I was actually able to plumb it up and user it...

[Jakes Louw]

Here's a QUICK driver compare for discrepancies between our SD and RP:

Tpi2Dlpi
caam
cip
clicd
clicdlpi
disc3
eavesdrop
el
esctl
esdisk
func0
hd_fabric
ha_drv
iether
ipmi
ipmi_psm
krio
pci_mux0
scsi1
scsi3
sigatm
target
vxdmp_q4
vxvm_q4

Hope this helps a little...

[Alzhy]

Jakes.. that was precisely what I looked at 1st.. no glaring differences that I could find or a driver to pinpoints specifically to an rp8400....

My experience with HP systems have been "limited" -- in fact just spanning 7 months (Fastracked...).

Am I to assume that an install on one server might not include all the device drivers necessary for all HW combinations? All my installs always pick all the available device drivers.

But the thing is, why is it that my Ignite Restore (of the SD Ignite backups) worked on the rp8400 -- if supposedly the SD installs do not contain "drivers" for the rp8400? It sees all the internal devices -- in fact I have restored the OS on the internal drives..

[Sridhar Bhaskarla]

Hi Nelson,

How many cells were there in SD?. Can you bring up "parmgr". Looks like this RP8400 is acting as if Cell 0 is not part of the partition.

Run parstatus and see if you get any information out of it.

-Sri

[Alzhy]

Sridhar, the target rp8400 nPar comprises of Cells 0 and 1 (Both Core Capable).. BCH sees the internal disks, DVD and DDS4 devices as bootable devices so there is no question that the nPar cannot see the coreIO -- which is in fact a baseless Question sine you cannot have an nPar without a CoreIO capable cell...

Thanks anyway..

I have been able to transport the server environment via Ignite Restore. Using the transported approach - I am ablet to restore using external disks AND have been able to build the PATHS to the CoreIO devices manually via insf specifying the actual HW paths... case closed. I was just wondering why under "-lm" mode and while fully booted, ioscan and insf cannot build the coreIO devices.. but manually creating the devices did the trick..

[Sridhar Bhaskarla]

Nelson,

That's why I said it was acting as if. Can you post your "parstatus" output?. Is it clean?.

-Sri

[Alzhy]

Attached Sire..

This rp8400 actually has only one nPar consisting of the 2 Cell boards that are bot CoreIO capable...

[Sridhar Bhaskarla]

Nelson,

You could have tried removing both /stand/ioconfig and /etc/ioconfig in LVM maintenance mode.

Anyway good that you could get your RP8400 working yourself.

-Sri

[Todd McDaniel_1]

Nelson,

Regarding your statement about what HP said about your disk move being unsupported...

Many things are possible to be done, but are considered too risky to be covered by HP. The problems that you have encountered will make your box unstable in my opinion. Although what you did seems reasonable it was indeed very risky. For one thing you have a different H/w setup on the two boxes. Sure the architecture is the the same as are many things on these cell-based boxes, but the effort you have expended would have been better spent doing it the safe and correct way, imho.

You could have avoided all this headache with the drivers by doing a clean install on the Keystone and then vgimport all your volumes there...

IF you use the vgexport -s -v -m options namely the -s it places an identifier VGID in there which makes it easy to vgimport to a new host without naming the Luns....

That was a great experimennt you did, in moving the OS disk. However, we all have visions of things that can be done, but HP is very particular on what is considered "supported" activity. There are things I would have done in the past had they been supported.

That Keystone you have configured in this manner will most likely not be supported for future problems, because of the way you created it and now most likely it wont be since HP is aware of it now.

Something to consider, my friend.

[Alzhy]

Sridhar.. that's what I did firstly.. no avail.

Todd, no I did not use the transported disk even if it works.. I used the Ignite tape restore environment which I think is "more supported" - EVEN if there is no difference byte for byte between the transported disk with rebuilt CoreIO device paths AND the Ignite Tape restored environment...