EVA 3000 + RHEL4 U8

[Peter Draksler]

I've been having a heck of a time configuring a LUN in RHEL4 U8 for a few days. Spent a couple hours with HP support on Friday and after confirming everything was configured properly they suggest it is a software (using HPs QLogic driver), not EVA issue as the OS sees the paths to the disk. I'll give them a call Monday but thought I'd try this forum as I've already found tonnes of useful info here.

Here's the output of a few commands:

lssg:
sg0 0,0,0,0 HP HSV100 3110
sg1 0,0,0,2 HP HSV100 3110
sg2 0,0,1,0 HP HSV100 3110
sg3 0,0,1,2 HP HSV100 3110
sg4 1,0,0,0 HP HSV100 3110
sg5 1,0,0,2 HP HSV100 3110
sg6 1,0,1,0 HP HSV100 3110
sg7 1,0,1,2 HP HSV100 3110

lssd:
sda 0,0,0,2 HP HSV100 3110
sdb 0,0,1,2 HP HSV100 3110
sdc 1,0,0,2 HP HSV100 3110
sdd 1,0,1,2 HP HSV100 3110

All looks well but I get numerous errors on /dev/sdb and /dev/sdd when running sfdisk -l

Disk /dev/sda: 10240 cylinders, 64 heads, 32 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/sda: unrecognized partition
No partitions found

Disk /dev/sdb: 10240 cylinders, 64 heads, 32 sectors/track
read: Input/output error

sfdisk: read error on /dev/sdb - cannot read sector 0
/dev/sdb: unrecognized partition
No partitions found

Disk /dev/sdc: 10240 cylinders, 64 heads, 32 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/sdc: unrecognized partition
No partitions found

Disk /dev/sdd: 10240 cylinders, 64 heads, 32 sectors/track
read: Input/output error

sfdisk: read error on /dev/sdd - cannot read sector 0
/dev/sdd: unrecognized partition
No partitions found

In the past (on an EVA 4400 running on RHEL5) there haven't been any issues with the OS seeing all the paths (without the i/o and cannot read sector 0 errors).

Possibly and issue with 3000? The OS Type is set to Sun Solaris for the host in CommandView, as read here on the forums and confirmed by HP support.

Errors in the system logs include:

kernel: Device sdb not ready.
kernel: end_request: I/O error, dev sdb, sector 0
kernel: Buffer I/O error on device sdb, logical block 0

kernel: Device sdd not ready.
kernel: end_request: I/O error, dev sdd, sector 0
kernel: Buffer I/O error on device sdd, logical block 0

Configuring multipath and running 'multipath -ll' provides the following which is somewhat expected given the above errors but I have no idea why.

hptest01 (3600508b4001081640000a00000320000)

\_ round-robin 0
\_ 0:0:0:2 sda 8:0
\_ 0:0:1:2 sdb 8:16
\_ 1:0:0:2 sdc 8:32
\_ 1:0:1:2 sdd 8:48


Anyone with any thoughts or suggestions?

Many thanks in advance.

Peter

P.S. This thread ahs been moved from Disk, Disk Arrays (Retired Discussion Board) to Storage Area Networks (SAN) (Enterprise). - Hp Forum Modetator

[Uwe Zessin · Accepted solution]

Controller firmware V3.110 offers an "active/passive" mode. One controller provides read/write access (sda + sdc) to a virtual disk. The other controller presents SCSI LUNs so that the multipath feature in the operating system understands that there are additional redundancy paths, but it does not allow read/write I/O (those are sdb + sdd).

A QLogic driver should understand how to properly deal with all paths if you tell it to do the path handling.

I've read that the device-mapper -can- deal with active/passive arrays if it is told how to handle the array, but last time I checked, HP does only supports and supplies the setup files for the DM for active/active arrays.

You would have to upgrade to VCS4.100, but be warned that it requires CAREFUL PLANNING, because it affects the multipath handlers in most other operating systems and most likely requires a new cabeling of your EVA (which could require zoning changes, ...).

[Peter Draksler]

Thanks Uwe, I tested the failover using device mapper multipath and it worked but in read-only as you mentioned.

I reconfigured the HP QLogic driver to use failover instead of single path and testing was much better. Failover worked correctly with each switch port and controller disabled.

Thanks for clarifying. It's not working as is currently configured with our RHEL 5 implementation but the result is basically what we want; failover is working.