Connecting W2K3 Servers to MSA3000

[Rob Leadbeater]

Hi,

The host presentation looks OK to me...

A couple of things from the registry output and screen grabs however.

This bit:
"Identifier"="HP HSV101 3010"

would appear to suggest VCS 3.010 rather than 4.007 which you mentioned earlier. I'm guessing that's a red herring, but it's worth sanity checking, as the difference between v3 and v4 is the move from Active/Passive to Active/Active controllers, which may have an impact when you've only got one connection to the server.

The other thing I noticed was the warning triangle in Command View for the Hardware. Can you drill down there and see what's wrong... If it happens to be something to do with the cache batteries that may well explain everything... Bad batteries = No LUNs.

Cheers,

Rob

[WCzar]

From CommandView:
Initialized System Properties shows;
Type: HSV100
Version: 4007
Software: SR0045runp-4007

Checked the hardware. There is 1 failed drive, which we knew about before the cabinet was moved. Sometime after we started to configure for our test server (hpsansrv) a failed battery appeared on one of the controllers. Checking this afternoon we see two failed cache batteries - 1 on each controller (A & B). Each controller has two batteries - there is 1 good battery remaining on each.

[Uwe Zessin]

> This bit:
> "Identifier"="HP HSV101 3010"
>
> would appear to suggest VCS 3.010 rather than 4.007

No, you will see this on other EVAs as well - WCzar's box apparently has some history ;-)

The EVA keeps the SCSI inquiry string (at least for Windows systems) even after an update of the controller firmware to prevent Windows 'hotplug' events from happening.

[Rob Leadbeater]

Hi,

> there is 1 good battery remaining on each

OK that shouldn't affect things, but I'd be more convinced if all the batteries were good. EVAs seem to do odd things when batteries go bad...

Another thought, have you tried restarting the EVA itself ?

Cheers,

Rob

[WCzar]

Completely powered down and restarted everything yesterday.
Attached is a screen print from the emulex hbanywhere utility installed on the w2k3 server that can't see the san from Disk Management. It shows the 50: addresses. We can echo back to those addresses successfully from the server (LUN 0). That should equate to having a connection from purely a Emulex hba standpoint. So if that works, then back to the original issue - why can't Disk Management in Windows see it after doing a re-scan. What should the LUN assignment on the host (hpsansrv) in CommandView be if the physical box for hpsansrv shows LUN 0?

[Uwe Zessin]

The existence of LUN 0 (the green 'card' icon suggests it is a controller device, not a presented disk) shows that we have basic fabric connectivity. That's good so far.

But you should see a LUN 1 (and a disk icon left to it). As long as that is not the case - you won't see a disk in Windows disk management.

This really sounds like the EVA is not presenting the disk due to a problem with the cache batteries - can you put an intact pair into one controller? The output from HBAnywhere shows that the adapter has access to both controllers.
If Rob's guess is correct you should now see a disk icon and "LUN 1" on one of the paths.

[WCzar]

The problem has been resolved! We replaced all 4 cache batteries and now see the SAN from the Windows test server. We created a new zone and were able to connect a VMWare host. Everything seems to be working as expected. Many thanks to all of you who responded with such great support and most of all your patience. Thanks again.

[WCzar]

When we started to work on resurrecting the EVA3000 all the cache batteries were OK. However, shortly thereafter one of the 146 GB drives failed and then the cache batteries, one by one. Not sure when the first battery failure occurred, but the W2K3 test server was only able to see the SAN after we replaced all 4 failed batteries (rather expensive). Since the hardware is active\active we thought there would still be some redundancy - not sure if that was ever the case.