HP9000 and EMC Disk array

[Sreejith Kaliyam]

We have a HP9000 V class server connected to an EMC diskarray. Now we want to move few disk chunks from the V class and allocate them to an N class server connected to the same array.

The issue is that, at present the LUNS are allocated in a sequential odrer from say lunA to lunG and customer want to move the disks with lunB to lunD. This will leave a gap in the lun addressing. EMC guys have raised an issue that it could be a problem and the chunks after the address gap may not be accessible from HP after the change.

Is this a problem with in a setup with HP and EMC ?? We know that in normal conditions it shouldnt matter. anyone has experienced any probs ?? comments ??

Thanks

Naveen

[Duncan Edmonstone]

This *was* a problem with HP systems - you used to have to check that all your LUNs were in order sequentially (with no gaps) but as long as you are fully patched up, there won't be a problem.

Patch PHKL_21607 fixed this, but the latest patch containing the fix is PHKL_26542. You should check dependencies of course.

HTH

Duncan

[Stefan Farrelly]

We had this exact problem a few weeks ago when we moved some EMC LUN's and this created non-sequential LUN's on the same channel - which made some of our LUN's not visible to the HP server. EMC recommended we install patch;
PHKL_23259 (SCSI cumulative patch)

which fixed our problem. I recommend you install it also if you are going to have non-sequential LUN's.

[Sreejith Kaliyam]

Thanks Duncan and Stefan..

Just one more quick question.

In our case, we have EMC connected to HP servers using Fiber channel.Do you have the EMC Disk Array on Fibre Channel or SCSI ?

Thanks again...

[Duncan Edmonstone]

Either way it doesn't matter - Fibre Channel still uses the SCSI protocol for presenting devices to the OS, so it's the same patches (& problem) on both.

HTH

Duncan

[MANOJ SRIVASTAVA]

Hi Neil


We have a combination of both to teh same frame. The Fibre doesnt a have the 128 lun limiation where as the SCSI has and the patch
PHKL_26542 resolves the problem of lun mistmatch .


Manoj Srivastava

[Stefan Farrelly]

We have fibre connected EMC's.

[Sreejith Kaliyam]

Thanks for all the help Guys,

I will apply this patche before I go ahead and do the changes in the EMC.

Thank again

[Johannes Seippel]

Just to clarify a typo and give a hint to the patch warning of PHKL_21607.

PHKL_21607 can introduce symptoms that include longer boot times and longer ioscan times. These symptoms have only been seen on V-Class systems with a large number (900+) LUNs on EMC disk arrays attached via Fibre Channel. With the patch installed, a typical boot time increases from 30 to 60 minutes; and ioscan(1M) takes up to 20 minutes (with or without the '-k' option).

We have the following SCSI IO Subsystem Cumulative Patches available:

PHKL_25938 Rating=2 20.12.2001
or
PHKL_26452 Rating=1 02.04.2002


As PHKL_26452 is very new and therefor has only a rating of 1 I would prefer the PHKL_25938.

[Mark van Hassel]

Hi,

Installing the mentioned patch will create dummy luns in order to keep the sequential order in tact. However when you have downtime. I would prefer to export the vgs, reassign Target/Lun adresses and then import the vgs again on the V class and N class. This way you have a clean environment without dummy luns.

HtH,

Mark

[Kirby A. Joss]

Yes, It could be a problem. The specifics will probably determine just how. On a 10.20 system we had to install the SCSI cumulative patch (and several pre-requisites) to handle a similar gap in the LUN sequence (HP problem). On an 11.00 system, additional volumes couldn't be found on one occassion, at least not without a reboot (which we couldn't afford). We had to allocate other volumes to contiguous LUNs to keep going.

-Kirb