SAN DISK Identification process

[Robert Jacobs]

Hi All


I have been working with various SAN disks and technologies during the last three months as my forum history my show. I have what I hope is an easy question.

Is the SYSMAN command

SYSMAN> io auto

suposed to return newly discovered SAN disks in the manner that the INIT command does at the CONSOLE Prompt >>>


This has not worked for me in the past. My associate wants to know if there is a way we can discover new SAN attached disks WITHOUT having to bring down the system and do an INIT.

He indicates a command in Tru-64 Unix called

#hwmgr scan scsi

discovers on the fly the new SAN attached storage disks.

#hwmgr show scsi

will verify the storage is there.


So is there an equivalent command when OpenVMS system is up and running.



Thank you

Robert J.

[Andy Bustamante]

I'm not sure what your problem is. wwidmgr is used to define a disk for boot or writing a dump file (dump off system disk). Once VMS has booted you use SYSMAN to detect any new disks added to the SAN without downtime.

If you dismount and delete a disk you can use
SYSMAN> IO SCSI_PATH_VERIFY
SYSMAN> IO AUTOCONFIGURE

The first command verifies SCSI and fibre channel devices and disconnects any which have changed. The second detects new devices.


Andy

[Robert Jacobs]

Thank you for your response

When I issue the sysman commands

SYSMAN> IO SCSI_PATH_VERIFY

or > IO FIND_WWID

or > IO AUTO

The system just does not pick up the SAN device on the fly!.


When I do an INIT at the console >>> prompt then things are fine! So I guess the issues is why does the system fail to get these devices on the fly!! So does anybody have an idea why certain scaning would not work until an


A side note:

I view the UDID # via the ww -sh ww.

Numbers within the SAN storage product I use get translated to for example $1$dga12 if I set a # 12 within the SAN storage utility.

[Uwe Zessin · Accepted solution]

Can you provide some background info:
- what storage array is involved?
- version of OpenVMS?
- output of ">>> wwidmgr -show wwid -full" attached as a .TXT file?

[Andy Bustamante]

Use
SYSMAN> IO SCSI_PATH_VERIFY
to remove any deleted units and validate connections.

SYSMAN> IO AUTOCONFIGURE will detect new units.

If this fails at the operating system level and works at the console, I'd suspect a hardware issue.

Your original post states "various SAN disks and technologies" can you be more specific? What HBAs are you using and have you loaded recent firmware? What version of VMS and what patches are installed?

Andy

[Mike Reznak]

Hi,

use SYSMAN> IO AUTO/ LOG to see whats going on.
And please take time to answer Uwe questins. It could be helpfull.

Mike

[Mike Reznak]

Sorry for typing mistake

SYSMAN> IO AUTO /LOG

[Robert Jacobs]

Hi


We are running V7.3-2 with Firmware

AlphaServer Console V6.9-1, built on Nov 18 2004 at 09:46:43

The patches and ww output are in an attached MS-word doc file.

The storage we are using is IBM DS6000/DS8000 with SVC (TotalStorage SAN Volume Controller

Thank you for looking into this issue.

Robert J.

[Peter Zeiszler]

Since you post that you have worked with SAN environments for the past few months all of this should already be second knowledge to you.

In our environment we use HP XP1024 SAN environments and EMCs. So for the VMS it really doesn't matter the frame - as long as they remember to setup an unused LUN 0 (might be part of the XP1024 requirement for servicing VMS).

I will try to explain as best as I can some of these numbers.

"[16] UDID: 1 WWID:01000010:6005-0768-0183-8032-6000-0000-0000-004e"

The ITEM is 16
UDID is 1
The WWID contains your WWN (world wide number) of the device accessing the disks. So its one of your Fiber cards.
The very last part 004e should actually map to the CU:LDEV. This is very important for the SAN configuration.

On the VMS system the very most important number is the UDID. This will make the device show up as DGA1:

It appears that you have already gone through the steps of:
set mode diag
wwidmgr -show wwid
wwidmgr -set wwid -item (#) -unit (###)
(example: wwidmgr -set wwid -item 16 -unit 1)

Now at the boot prompt you should see devices setup in the wwid and n# locations. These are limited to only 4 devices. So the most important ones to setup in there are the system disk and the dump device. Those need to be understood from the boot prompt.

As we add new devices I do not have to set the UDID on each device. By default the devices will inherit the defined LUN. On the XP1024 however the LUN means nothing. Its all in the CU:LDEV.

The CU:LDEV is converted to a number that is presented to the VMS. The CU is multipled by 256 and then added to the LDEV. We also have multiple SAN frames accessible from each VMS system. These numbers need to be unique when presented to the VMS.

So using 004E we would see as a device DGA78. We could NOT see any other devices with the same number from other frames or if we forced a device to a UDID.

When we add disks we always verify that information prior to adding it to the VMS group.

Once the device is added all we have to do is force a scan of the devices:
mc sysman io auto
The new DGA devices are then visible to us.

[Robert Jacobs]

Yes Peter this is great information.


In my case The SYSMAN IO auto or any SYSMAN commands DO NOT return the expected results.

I am NOT seeing the devices on the fly.
without bringing down the system, When I issue the command $ show dev d

That is the problem I have.

I was hoping to get to this root cause.

Why is this happening.

I can issue an INIT at the Console >>> prompt and then I do see the new devices I just presented to the SAN.

Any thoughts

Thank you Robert J.